* [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 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 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
* 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
* 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 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 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 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] dt-bindings: display: renesas,du: Convert binding to YAML
From: Laurent Pinchart @ 2020-05-28 23:04 UTC (permalink / raw)
To: Rob Herring
Cc: Laurent Pinchart, dri-devel, devicetree, linux-renesas-soc,
Kieran Bingham
In-Reply-To: <20200528185244.GA400585@bogus>
Hi Rob,
On Thu, May 28, 2020 at 12:52:44PM -0600, Rob Herring wrote:
> On Fri, May 15, 2020 at 03:33:40AM +0300, Laurent Pinchart wrote:
> > Convert the Renesas R-Car DU text binding to YAML.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > .../bindings/display/renesas,du.txt | 139 ---
> > .../bindings/display/renesas,du.yaml | 915 ++++++++++++++++++
>
> A 'normal' conversion is about double the lines. I guess this is a sign
> that the original was not well specified.
The original was specified in a much more compressed form (for instance
there was a table with one line per SoC to describe the port node, the
YAML equivalent has to be longer).
> Maybe this can be split to reduce some of the if/then? One way is define
> a common 'include' file that each specific instance can reference
With your recommendation of using pattern instead of enum for the dclkin
clock names, we're down to 848 lines, it's already a bit better :-)
I could indeed split the file, but I'll then run into naming issues. If
you look at the compatible strings for each of the if...then...else,
they don't have easy patterns that could be used to name files. I could
name the files based on one arbitrarily chosen compat string among the
multiple values that are supported, but I think that would become
confusing. I could also have one file per SoC, but we'll then end up
with lots of files, several of them being totally identical except for
the compatible string. Would you mind keeping it as-is, or do you think
it really needs to be split ?
> [...]
>
> > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > new file mode 100644
> > index 000000000000..ca48065afe1f
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> > @@ -0,0 +1,915 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/renesas,du.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Renesas R-Car Display Unit (DU)
> > +
> > +maintainers:
> > + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > +
> > +description: |
> > + These DT bindings describe the Display Unit embedded in the Renesas R-Car
> > + Gen1, R-Car Gen2, R-Car Gen3, RZ/G1 and RZ/G2 SoCs.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - renesas,du-r8a7743 # for RZ/G1M compatible DU
> > + - renesas,du-r8a7744 # for RZ/G1N compatible DU
> > + - renesas,du-r8a7745 # for RZ/G1E compatible DU
> > + - renesas,du-r8a77470 # for RZ/G1C compatible DU
> > + - renesas,du-r8a774a1 # for RZ/G2M compatible DU
> > + - renesas,du-r8a774b1 # for RZ/G2N compatible DU
> > + - renesas,du-r8a774c0 # for RZ/G2E compatible DU
> > + - renesas,du-r8a7779 # for R-Car H1 compatible DU
> > + - renesas,du-r8a7790 # for R-Car H2 compatible DU
> > + - renesas,du-r8a7791 # for R-Car M2-W compatible DU
> > + - renesas,du-r8a7792 # for R-Car V2H compatible DU
> > + - renesas,du-r8a7793 # for R-Car M2-N compatible DU
> > + - renesas,du-r8a7794 # for R-Car E2 compatible DU
> > + - renesas,du-r8a7795 # for R-Car H3 compatible DU
> > + - renesas,du-r8a7796 # for R-Car M3-W compatible DU
> > + - renesas,du-r8a77965 # for R-Car M3-N compatible DU
> > + - renesas,du-r8a77970 # for R-Car V3M compatible DU
> > + - renesas,du-r8a77980 # for R-Car V3H compatible DU
> > + - renesas,du-r8a77990 # for R-Car E3 compatible DU
> > + - renesas,du-r8a77995 # for R-Car D3 compatible DU
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + # See compatible-specific constraints below.
> > + clocks: true
> > + clock-names: true
> > + interrupts: true
> > + resets: true
> > + reset-names: true
> > +
> > + ports:
> > + type: object
> > + description: |
> > + The connections to the DU output video ports are modeled using the OF
> > + graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> > + The number of ports and their assignment are model-dependent. Each port
> > + shall have a single endpoint.
> > +
> > + properties:
> > + '#address-cells':
> > + const: 1
> > +
> > + '#size-cells':
> > + const: 0
> > +
> > + patternProperties:
> > + "^port@[0-3]$":
> > + type: object
> > +
> > + properties:
> > + reg:
> > + maxItems: 1
> > +
> > + endpoint:
> > + type: object
> > +
> > + properties:
> > + remote-endpoint:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + required:
> > + - remote-endpoint
> > +
> > + additionalProperties: false
> > +
> > + additionalProperties: false
>
> You can drop this and assume there's a generic check for this. Though I
> guess this does ensure only 'remote-endpoint' is present which a generic
> schema couldn't do.
When you say I can drop "this", which part do you mean exactly ? I
indeed wanted to specify that no other property than remote-endpoint can
be present. What's your recommendation ?
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + additionalProperties: false
> > +
> > + renesas,cmms:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > + description:
> > + A list of phandles to the CMM instances present in the SoC, one for each
> > + available DU channel.
> > +
> > + renesas,vsps:
> > + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> > + description:
> > + A list of phandle and channel index tuples to the VSPs that handle the
> > + memory interfaces for the DU channels. The phandle identifies the VSP
> > + instance that serves the DU channel, and the channel index identifies
> > + the LIF instance in that VSP.
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > + - interrupts
> > + - resets
> > + - ports
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: renesas,du-r8a7779
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + - description: Functional clock
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 1
> > + maxItems: 3
> > + items:
> > + - const: du.0
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
>
> Here and elsewhere:
>
> - pattern: "^dclkin\.[01]$"
I assume you meant
- pattern: "^dclkin\\.[01]$"
Will fix.
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + # port@2 is TCON, not supported yet
>
> Does that matter?
It's a nice reminder that we should add support for it. And I don't
meant in the driver, even if that part is also required, but in the DT
bindings. I don't want to blindly state
port@2:
description: TCON
without working on TCON support on the driver side to validate that the
DT binding is fine and that I haven't overlooked something. Do you mind
keeping the comment for now ?
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - interrupts
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7743
> > + - renesas,du-r8a7744
> > + - renesas,du-r8a7791
> > + - renesas,du-r8a7793
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + # port@2 is TCON, not supported yet
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7745
> > + - renesas,du-r8a7792
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7794
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + # port@2 is TCON, not supported yet
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a77470
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: DPAD 1
> > + port@2:
> > + description: LVDS 0
> > + # port@3 is DVENC, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7790
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2:
> > + description: LVDS 1
> > + # port@3 is TCON, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a7795
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 4
> > + maxItems: 8
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: Functional clock for DU4
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > + - description: DU_DOTCLKIN3 input clock
> > +
> > + clock-names:
> > + minItems: 4
> > + maxItems: 8
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - const: du.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - dclkin.3
> > +
> > + interrupts:
> > + maxItems: 4
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.2
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: HDMI 1
> > + port@3:
> > + description: LVDS 0
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > + - port@3
> > +
> > + renesas,cmms:
> > + minItems: 4
> > +
> > + renesas,vsps:
> > + minItems: 4
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774a1
> > + - renesas,du-r8a7796
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU2
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN2 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.2
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.2
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: LVDS 0
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 3
> > +
> > + renesas,vsps:
> > + minItems: 3
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774b1
> > + - renesas,du-r8a77965
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: Functional clock for DU3
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > + - description: DU_DOTCLKIN3 input clock
> > +
> > + clock-names:
> > + minItems: 3
> > + maxItems: 6
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - const: du.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - dclkin.3
> > +
> > + interrupts:
> > + maxItems: 3
> > +
> > + resets:
> > + maxItems: 2
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > + - const: du.3
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: HDMI 0
> > + port@2:
> > + description: LVDS 0
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 3
> > +
> > + renesas,vsps:
> > + minItems: 3
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a77970
> > + - renesas,du-r8a77980
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - description: Functional clock for DU0
> > + - description: DU_DOTCLKIN0 input clock
> > +
> > + clock-names:
> > + minItems: 1
> > + maxItems: 2
> > + items:
> > + - const: du.0
> > + - const: dclkin.0
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2: false
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > +
> > + renesas,vsps:
> > + minItems: 1
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - renesas,du-r8a774c0
> > + - renesas,du-r8a77990
> > + - renesas,du-r8a77995
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - description: Functional clock for DU0
> > + - description: Functional clock for DU1
> > + - description: DU_DOTCLKIN0 input clock
> > + - description: DU_DOTCLKIN1 input clock
> > +
> > + clock-names:
> > + minItems: 2
> > + maxItems: 4
> > + items:
> > + - const: du.0
> > + - const: du.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > + - enum:
> > + - dclkin.0
> > + - dclkin.1
> > +
> > + interrupts:
> > + maxItems: 2
> > +
> > + resets:
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: du.0
> > +
> > + ports:
> > + properties:
> > + port@0:
> > + description: DPAD 0
> > + port@1:
> > + description: LVDS 0
> > + port@2:
> > + description: LVDS 1
> > + # port@3 is TCON, not supported yet
> > + port@3: false
> > +
> > + required:
> > + - port@0
> > + - port@1
> > + - port@2
> > +
> > + renesas,cmms:
> > + minItems: 2
> > +
> > + renesas,vsps:
> > + minItems: 2
> > +
> > + required:
> > + - clock-names
> > + - interrupts
> > + - resets
> > + - reset-names
> > + - renesas,vsps
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + # R-Car H3 ES2.0 DU
> > + - |
> > + #include <dt-bindings/clock/renesas-cpg-mssr.h>
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +
> > + display@feb00000 {
> > + compatible = "renesas,du-r8a7795";
> > + reg = <0xfeb00000 0x80000>;
> > + interrupts = <GIC_SPI 256 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 268 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 269 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 270 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&cpg CPG_MOD 724>,
> > + <&cpg CPG_MOD 723>,
> > + <&cpg CPG_MOD 722>,
> > + <&cpg CPG_MOD 721>;
> > + clock-names = "du.0", "du.1", "du.2", "du.3";
> > + resets = <&cpg 724>, <&cpg 722>;
> > + reset-names = "du.0", "du.2";
> > +
> > + renesas,cmms = <&cmm0>, <&cmm1>, <&cmm2>, <&cmm3>;
> > + renesas,vsps = <&vspd0 0>, <&vspd1 0>, <&vspd2 0>, <&vspd0 1>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + endpoint {
> > + remote-endpoint = <&adv7123_in>;
> > + };
> > + };
> > + port@1 {
> > + reg = <1>;
> > + endpoint {
> > + remote-endpoint = <&dw_hdmi0_in>;
> > + };
> > + };
> > + port@2 {
> > + reg = <2>;
> > + endpoint {
> > + remote-endpoint = <&dw_hdmi1_in>;
> > + };
> > + };
> > + port@3 {
> > + reg = <3>;
> > + endpoint {
> > + remote-endpoint = <&lvds0_in>;
> > + };
> > + };
> > + };
> > + };
> > +
> > +...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 9/9] dt-bindings: usb: Convert ehci-mv to json-schema
From: Rob Herring @ 2020-05-28 23:05 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Linus Walleij, Marc Zyngier, Thomas Gleixner, Daniel Lezcano,
Rob Herring, Alessandro Zummo, devicetree, Bartosz Golaszewski,
Alexandre Belloni, linux-kernel, Ulf Hansson, Jason Cooper
In-Reply-To: <20200521091356.2211020-10-lkundrak@v3.sk>
On Thu, 21 May 2020 11:13:56 +0200, Lubomir Rintel wrote:
> A straightforward conversion of the ehci-mv binding to DT schema format
> using json-schema.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
>
> ---
> Changes since v1:
> - s/GPL-2.0-or-later/GPL-2.0-only/
>
> .../devicetree/bindings/usb/ehci-mv.txt | 23 -------
> .../bindings/usb/marvell,pxau2o-ehci.yaml | 60 +++++++++++++++++++
> 2 files changed, 60 insertions(+), 23 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/usb/ehci-mv.txt
> create mode 100644 Documentation/devicetree/bindings/usb/marvell,pxau2o-ehci.yaml
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: timer: Add CLINT bindings
From: Rob Herring @ 2020-05-28 23:18 UTC (permalink / raw)
To: Palmer Dabbelt
Cc: seanga2, anup, Anup Patel, Paul Walmsley, aou, daniel.lezcano,
tglx, devicetree, Damien Le Moal, linux-kernel, Atish Patra,
Alistair Francis, linux-riscv
In-Reply-To: <mhng-0995a264-b39c-4790-9aa5-b8c598b43ffd@palmerdabbelt-glaptop1>
On Tue, May 26, 2020 at 05:32:30PM -0700, Palmer Dabbelt wrote:
> On Thu, 21 May 2020 23:29:36 PDT (-0700), seanga2@gmail.com wrote:
> > On 5/22/20 1:54 AM, Anup Patel wrote:
> > > On Fri, May 22, 2020 at 1:35 AM Sean Anderson <seanga2@gmail.com> wrote:
> > > >
> > > > On 5/21/20 9:45 AM, Anup Patel wrote:
> > > > > +Required properties:
> > > > > +- compatible : "sifive,clint-1.0.0" and a string identifying the actual
> > > > > + detailed implementation in case that specific bugs need to be worked around.
> > > >
> > > > Should the "riscv,clint0" compatible string be documented here? This
> > >
> > > Yes, I forgot to add this compatible string. I will add in v2.
> > >
> > > > peripheral is not really specific to sifive, as it is present in most
> > > > rocket-chip cores.
> > >
> > > I agree that CLINT is present in a lot of non-SiFive RISC-V SOCs and
> > > FPGAs but this IP is only documented as part of SiFive FU540 SOC.
> > > (Refer, https://static.dev.sifive.com/FU540-C000-v1.0.pdf)
> > >
> > > The RISC-V foundation should host the CLINT spec independently
> > > under https://github.com/riscv and make CLINT spec totally open.
> > >
> > > For now, I have documented it just like PLIC DT bindings found at:
> > > Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
> >
> > The PLIC seems to have its own RISC-V-sponsored documentation [1] which
> > was split off from the older privileged specs. By your logic above,
> > should it be renamed to riscv,plic0.txt (with a corresponding change in
> > the documented compatible strings)?
> >
> > [1] https://github.com/riscv/riscv-plic-spec
>
> Let's propose tagging that PLIC spec as v1.0.0 in the platform spec group, but
> I don't see a reason why that wouldn't be viable. Assuming that's all OK, we
> can start calling this a RISC-V PLIC (in addition to a SiFive PLIC, as they'll
> be compatible).
>
> > >
> > > If RISC-V maintainers agree then I will document it as "RISC-V CLINT".
> > >
> > > @Palmer ?? @Paul ??
>
> The CLINT is a SiFive spec. It has open source RTL so it's been implemented in
> other designs, but it's not a RISC-V spec. The CLIC, which is a superset of
> the CLINT, is a RISC-V spec. IIRC it's not finished yet (it's the fast
> interrupts task group), but presumably we should have a "riscv,clic-2.0.0" (or
> whatever it ends up being called) compat string to go along with the
> specification.
Whatever you all decide on, note that "sifive,<block><num>" is a SiFive
thing (as it is documented) and <num> corresponds to tag of the IP
implmentation (at least it is supposed to). So you can't just copy that
with 'riscv,<block><num>' unless you have the same IP versioning
and update the documentation.
Using a spec version is fine, but not standalone. You need
implementation specific compatible too because no one perfectly
implements any spec and/or there details a spec may not cover.
Rob
^ permalink raw reply
* Re: [PATCH V2 1/3] dt-bindings: mmc: Supply max load for mmc supplies
From: Rob Herring @ 2020-05-28 23:23 UTC (permalink / raw)
To: Veerabhadrarao Badiganti
Cc: adrian.hunter, ulf.hansson, bjorn.andersson, linux-mmc,
linux-kernel, linux-arm-msm, devicetree
In-Reply-To: <1590074615-10787-2-git-send-email-vbadigan@codeaurora.org>
On Thu, May 21, 2020 at 08:53:33PM +0530, Veerabhadrarao Badiganti wrote:
> Supply the max load needed for driving the mmc supplies.
>
> Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
> ---
> .../devicetree/bindings/mmc/mmc-controller.yaml | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> index acc9f10..9058b82 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-controller.yaml
> @@ -290,6 +290,22 @@ properties:
> description:
> Supply for the bus IO line power
>
> + vmmc-max-load-microamp:
Seems like this should be a common regulator property (it would have to
be a suffix to match up with *-supply).
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
Properties with unit suffix already have a type.
> + - minimum: 0
> + - maximum: 1000000
> + description:
> + Maximum load for the card power.
> +
> + vqmmc-max-load-microamp:
> + allOf:
> + - $ref: /schemas/types.yaml#/definitions/uint32
> + - minimum: 0
> + - maximum: 1000000
> + description:
> + Maximum load for the bus IO line power.
> +
> mmc-pwrseq:
> $ref: /schemas/types.yaml#/definitions/phandle
> description:
> --
> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
^ permalink raw reply
* Re: [PATCH 5/6] gnss: motmdm: Add support for Motorola Mapphone MDM6600 modem
From: Tony Lindgren @ 2020-05-28 23:38 UTC (permalink / raw)
To: Johan Hovold
Cc: Greg Kroah-Hartman, Rob Herring, Lee Jones, Jiri Slaby,
Merlijn Wajer, Pavel Machek, Peter Hurley, Sebastian Reichel,
linux-serial, devicetree, linux-kernel, linux-omap
In-Reply-To: <20200528130653.GG10358@localhost>
Hi,
* Johan Hovold <johan@kernel.org> [200528 13:07]:
> On Tue, May 12, 2020 at 02:47:12PM -0700, Tony Lindgren wrote:
> > +/*
> > + * Motorola MDM GNSS device communicates over a dedicated TS 27.010 channel
> > + * using custom data packets. The packets look like AT commands embedded into
> > + * a Motorola invented packet using format like "U1234AT+MPDSTART=0,1,100,0".
> > + * But it's not an AT compatible serial interface, it's a packet interface
> > + * using AT like commands.
> > + */
>
> So this shouldn't depend on TS 27.010 and instead be a generic gnss
> serial driver.
Hmm not sure if it makes sense to try to represent packet data as
a virtual serial port :) But sure let's at least investigate it.
> What does the interface look like over the corresponding USB port?
> AT-commands without the U1234 prefix?
I don't know if it's using the same commands as the ttyUSB* GNSS device
seems disabled. From what I understand, gobi2000 has just $gps_start and
$gps_stop commands for the ttyUSB* GNSS device. Those don't exist
here. Also the command style seems to follow the modem firmware for
various other devices on the modem.
> No module parameters please. Either pick a good default or we need to
> come up with a generic (sysfs) interface for polled drivers like this
> one.
OK yeah this could be a generic sysfs option.
> How does your "aggressive pm" gsmmux implementation work with the gps if
> there are no other clients keeping the modem awake? It seems the modem
> would be suspended after 600 milliseconds after being woken up every 10
> seconds or so by the polling gnss driver?
Well we still have /dev/gnss open, so GNSS stays active and won't get
disabled until the device is closed. The shared GPIOs with the USB PHY
are used to signal port traffic.
> What happens to the satellite lock in between? Does the request block
> until the gps has an updated position?
It seems to regain the lock in about one or two seconds, so it's some
kind of modem PM state for allowing the SoC to idle it seems.
Regards,
Tony
^ permalink raw reply
* Re: [Patch 1/2] dt-binbings: media: ti-vpe: Document the VIP driver
From: Rob Herring @ 2020-05-28 23:39 UTC (permalink / raw)
To: Benoit Parrot; +Cc: Hans Verkuil, linux-media, devicetree, linux-kernel
In-Reply-To: <20200522225412.29440-2-bparrot@ti.com>
On Fri, May 22, 2020 at 05:54:11PM -0500, Benoit Parrot wrote:
> Device Tree bindings for the Video Input Port (VIP) driver.
Bindings document h/w, not drivers.
>
> Signed-off-by: Benoit Parrot <bparrot@ti.com>
> ---
> .../devicetree/bindings/media/ti,vip.yaml | 394 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 395 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,vip.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/ti,vip.yaml b/Documentation/devicetree/bindings/media/ti,vip.yaml
> new file mode 100644
> index 000000000000..8a9084e42329
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/ti,vip.yaml
> @@ -0,0 +1,394 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/ti,vip.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments DRA7x VIDEO INPUT PORT (VIP) Device Tree Bindings
> +
> +maintainers:
> + - Benoit Parrot <bparrot@ti.com>
> +
> +description: |-
> + The Video Input Port (VIP) is a key component for image capture
> + applications. The capture module provides the system interface and the
> + processing capability to connect parallel image-sensor as well as
> + BT.656/1120 capable encoder chip to DRA7x device.
> +
> + Each VIP instance supports 2 independently configurable external video
> + input capture slices (Slice 0 and Slice 1) each providing up to two video
> + input ports (Port A and Port B) where Port A can be configured as
> + 24/16/8-bit port and Port B is fixed as 8-bit port.
> + Here these ports a represented as follows
> + port@0 -> Slice 0 Port A
> + port@1 -> Slice 0 Port B
> + port@2 -> Slice 1 Port A
> + port@3 -> Slice 1 Port B
> +
> + Each camera port nodes should contain a 'port' child node with child
> + 'endpoint' node. Please refer to the bindings defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +properties:
> + compatible:
> + const: ti,dra7-vip
> +
> + label:
> + description: Instance name
Kind of odd for this type of binding. Are there a define set or pattern
of values.
> +
> + reg:
> + items:
> + - description: The VIP main register region
> + - description: Video Data Parser (PARSER) register region for Slice0
> + - description: Color Space Conversion (CSC) register region for Slice0
> + - description: Scaler (SC) register region for Slice0
> + - description: Video Data Parser (PARSER) register region for Slice1
> + - description: Color Space Conversion (CSC) register region for Slice1
> + - description: Scaler (SC) register region for Slice1
> + - description: Video Port Direct Memory Access (VPDMA) register region
> +
> + reg-names:
> + items:
> + - const: vip
> + - const: parser0
> + - const: csc0
> + - const: sc0
> + - const: parser1
> + - const: csc1
> + - const: sc1
> + - const: vpdma
> +
> + interrupts:
> + minItems: 2
> + description:
> + IRQ index 0 is used for Slice0 interrupts
> + IRQ index 1 is used for Slice1 interrupts
> +
> + ti,vip-clk-polarity:
> + $ref: "/schemas/types.yaml#/definitions/phandle-array"
> + description:
> + phandle to the device control module. The 1st argument should
> + contain the register offset to the CTRL_CORE_SMA_SW_1 register.
> + 2nd argument contains the bit field to slice 0 port A,
> + 3rd argument contains the bit field to slice 0 port B,
> + 4th argument contains the bit field to slice 1 port A,
> + 5th argument contains the bit field to slice 1 port B.
> +
> + # See ./video-interfaces.txt for details
> + ports:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + port@0:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 0
> + description: Slice 0 Port A
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
Not an array. Just:
hsync-active: true
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
Not an array. What subset of values are allowed?
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description: |-
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@1:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 1
> + description: Slice 0 Port B
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@2:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 2
> + description: Slice 1 Port A
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
> +
> + required:
> + - reg
> + - label
> +
> + port@3:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + reg:
> + const: 3
> + description: Slice 1 Port B
> +
> + label:
> + description: Port name. Usually the pin group name
> +
> + patternProperties:
> + endpoint:
> + type: object
> + additionalProperties: false
> +
> + properties:
> + hsync-active:
> + maxItems: 1
> +
> + vsync-active:
> + maxItems: 1
> +
> + pclk-sample:
> + maxItems: 1
> +
> + bus-width:
> + maxItems: 1
> +
> + ti,vip-pixel-mux:
> + type: boolean
> + description:
> + In BT656/1120 mode, this enable pixel-muxing if
> + the number of channels is either 1, 2 or 4. If this
> + property is present then pixel-muxing is enabled
> + otherwise it will use line-muxing.
> +
> + ti,vip-channels:
> + $ref: "/schemas/types.yaml#definitions/uint8-array"
> + minItems: 1
> + maxItems: 16
> + description:
> + In BT656/1120 mode, list of channel ids to be captured.
> + If the property is not present then 1 channel is assumed.
> +
> + remote-endpoint: true
If all the properties are the same across ports, then do a
patternProperties with '^port@' and define them there. You'll still need
'port@0', etc. to define what each port is.
> +
> + required:
> + - reg
> + - label
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> + - port@0
> +
> +required:
> + - compatible
> + - label
> + - reg
> + - reg-names
> + - interrupts
> + - ti,vip-clk-polarity
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + vip1: vip@48970000 {
> + compatible = "ti,dra7-vip";
> + label = "vip1";
> + reg = <0x48970000 0x114>,
> + <0x48975500 0xD8>,
> + <0x48975700 0x18>,
> + <0x48975800 0x80>,
> + <0x48975a00 0xD8>,
> + <0x48975c00 0x18>,
> + <0x48975d00 0x80>,
> + <0x4897d000 0x400>;
> + reg-names = "vip",
> + "parser0",
> + "csc0",
> + "sc0",
> + "parser1",
> + "csc1",
> + "sc1",
> + "vpdma";
> + interrupts = <GIC_SPI 351 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 392 IRQ_TYPE_LEVEL_HIGH>;
> + ti,vip-clk-polarity = <&scm_conf 0x534 0x1 0x4 0x2 0x8>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + vin1a: port@0 {
> + reg = <0>;
> + label = "vin1a";
> +
> + vin1a_ep: endpoint {
> + remote-endpoint = <&camera1>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <0>;
> + bus-width = <8>;
> + };
> + };
> + vin1b: port@1 {
> + reg = <1>;
> + label = "vin1b";
> + };
> + vin2a: port@2 {
> + reg = <2>;
> + label = "vin2a";
> + };
> + vin2b: port@3 {
> + reg = <3>;
> + label = "vin2b";
> + };
> + };
> + };
> +
> + i2c {
> + clock-frequency = <400000>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + camera@37 {
> + compatible = "ovti,ov10633";
> + reg = <0x37>;
> +
> + clocks = <&fixed_clock>;
> + clocks-names = "xvclk";
> +
> + port {
> + camera1: endpoint {
> + remote-endpoint = <&vin1a_ep>;
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2e9a5f6e4ff7..06856d05b53b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16947,6 +16947,7 @@ S: Maintained
> W: http://linuxtv.org/
> Q: http://patchwork.linuxtv.org/project/linux-media/list/
> F: Documentation/devicetree/bindings/media/ti,cal.yaml
> +F: Documentation/devicetree/bindings/media/ti,vip.yaml
> F: Documentation/devicetree/bindings/media/ti,vpe.yaml
> F: drivers/media/platform/ti-vpe/
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: uart: mtk: fix example
From: Rob Herring @ 2020-05-28 23:40 UTC (permalink / raw)
To: matthias.bgg
Cc: matthias.bgg, Matthias Brugger, dmaengine, linux-arm-kernel,
sean.wang, robh+dt, devicetree, linux-kernel, linux-mediatek,
vkoul
In-Reply-To: <20200523201530.18225-1-matthias.bgg@kernel.org>
On Sat, 23 May 2020 22:15:30 +0200, matthias.bgg@kernel.org wrote:
> From: Matthias Brugger <mbrugger@suse.com>
>
> The binding example is missing the fallback compatible.
> This is needed as the driver only matches against mt6577.
>
> Signed-off-by: Matthias Brugger <mbrugger@suse.com>
> ---
> Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v12 1/4] power_supply: Add additional health properties to the header
From: Andrew F. Davis @ 2020-05-28 23:34 UTC (permalink / raw)
To: Ricardo Rivera-Matos, sre, pali, robh
Cc: dmurphy, linux-pm, linux-kernel, devicetree, sspatil,
Guru Das Srinagesh
In-Reply-To: <20200528225350.661-2-r-rivera-matos@ti.com>
On 5/28/20 6:53 PM, 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 JEITA specification JISC8712:2015
>
> Tested-by: Guru Das Srinagesh <gurus@codeaurora.org>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
You should collect the acks and such you have received in previous
versions here, like mine from v11:
Acked-by: Andrew F. Davis <afd@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 05/10] dt-bindings: clock: Introduce SM8150 QCOM Graphics clock bindings
From: Rob Herring @ 2020-05-28 23:41 UTC (permalink / raw)
To: Jonathan Marek
Cc: linux-arm-msm, Andy Gross, Bjorn Andersson, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <20200524210615.17035-6-jonathan@marek.ca>
On Sun, May 24, 2020 at 05:06:06PM -0400, Jonathan Marek wrote:
> Add device tree bindings for graphics clock controller for
> Qualcomm Technology Inc's SM8150 SoCs.
Where's the schema?
>
> Signed-off-by: Jonathan Marek <jonathan@marek.ca>
> ---
> include/dt-bindings/clock/qcom,gpucc-sm8150.h | 40 +++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 include/dt-bindings/clock/qcom,gpucc-sm8150.h
^ permalink raw reply
* Re: [PATCH 1/8] dt-bindings: phy: rcar-gen2: Add r8a7742 support
From: Rob Herring @ 2020-05-28 23:43 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Rob Herring, linux-usb, linux-pci, Prabhakar, Vinod Koul,
Bjorn Helgaas, Kishon Vijay Abraham I, Greg Kroah-Hartman,
devicetree, linux-renesas-soc, linux-kernel, Magnus Damm,
dmaengine, Geert Uytterhoeven
In-Reply-To: <1590356277-19993-2-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:50 +0100, Lad Prabhakar wrote:
> Add USB PHY support for r8a7742 SoC. Renesas RZ/G1H (R8A7742)
> USB PHY is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: PCI: pci-rcar-gen2: Add device tree support for r8a7742
From: Rob Herring @ 2020-05-28 23:43 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, linux-pci, linux-usb, Rob Herring, Magnus Damm,
linux-renesas-soc, Geert Uytterhoeven, Bjorn Helgaas, Prabhakar,
Vinod Koul, Kishon Vijay Abraham I, dmaengine, linux-kernel,
Greg Kroah-Hartman
In-Reply-To: <1590356277-19993-3-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:51 +0100, Lad Prabhakar wrote:
> Add internal PCI bridge support for r8a7742 SoC. The Renesas RZ/G1H
> (R8A7742) internal PCI bridge is identical to the R-Car Gen2 family.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 3/8] dt-bindings: usb: renesas,usbhs: Add support for r8a7742
From: Rob Herring @ 2020-05-28 23:44 UTC (permalink / raw)
To: Lad Prabhakar
Cc: devicetree, Rob Herring, Geert Uytterhoeven, linux-pci,
Kishon Vijay Abraham I, dmaengine, Bjorn Helgaas, linux-kernel,
Greg Kroah-Hartman, Prabhakar, linux-renesas-soc, Magnus Damm,
Vinod Koul, linux-usb
In-Reply-To: <1590356277-19993-4-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:52 +0100, Lad Prabhakar wrote:
> Document support for RZ/G1H (R8A7742) SoC.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/usb/renesas,usbhs.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH 4/8] dt-bindings: dmaengine: renesas,usb-dmac: Add binding for r8a7742
From: Rob Herring @ 2020-05-28 23:45 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Geert Uytterhoeven, devicetree, Rob Herring, dmaengine,
Vinod Koul, linux-renesas-soc, Kishon Vijay Abraham I,
Magnus Damm, linux-kernel, Prabhakar, Greg Kroah-Hartman,
linux-pci, linux-usb, Bjorn Helgaas
In-Reply-To: <1590356277-19993-5-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:53 +0100, Lad Prabhakar wrote:
> Document RZ/G1H (R8A7742) SoC bindings.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/dma/renesas,usb-dmac.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Doesn't apply to my tree, so
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 5/8] dt-bindings: usb: usb-xhci: Document r8a7742 support
From: Rob Herring @ 2020-05-28 23:46 UTC (permalink / raw)
To: Lad Prabhakar
Cc: Kishon Vijay Abraham I, Geert Uytterhoeven, linux-renesas-soc,
Prabhakar, Greg Kroah-Hartman, linux-kernel, devicetree,
linux-pci, linux-usb, dmaengine, Bjorn Helgaas, Magnus Damm,
Rob Herring, Vinod Koul
In-Reply-To: <1590356277-19993-6-git-send-email-prabhakar.mahadev-lad.rj@bp.renesas.com>
On Sun, 24 May 2020 22:37:54 +0100, Lad Prabhakar wrote:
> Document r8a7742 xhci support. The driver will use the fallback
> compatible string "renesas,rcar-gen2-xhci", therefore no driver
> change is needed.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Reviewed-by: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> ---
> Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v6 15/18] mtd: nand: Introduce the ECC engine abstraction
From: Miquel Raynal @ 2020-05-28 23:46 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Julien Su, Weijie Gao,
Paul Cercueil, Thomas Petazzoni, Mason Yang, Chuanhong Guo,
linux-arm-kernel
In-Reply-To: <20200528205251.5e8abdd1@collabora.com>
Hi Boris,
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 20:52:51 +0200:
> On Thu, 28 May 2020 13:31:10 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Create a generic ECC engine object.
> >
> > Later the ecc.c file will receive more generic code coming from
> > the raw NAND specific part. This is a base to instantiate ECC engine
> > objects.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > ---
> > drivers/mtd/nand/Kconfig | 7 ++
> > drivers/mtd/nand/Makefile | 2 +
> > drivers/mtd/nand/ecc.c | 138 ++++++++++++++++++++++++++++++++++++++
> > include/linux/mtd/nand.h | 67 ++++++++++++++++++
> > 4 files changed, 214 insertions(+)
> > create mode 100644 drivers/mtd/nand/ecc.c
> >
> > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> > index c1a45b071165..a4478ffa279d 100644
> > --- a/drivers/mtd/nand/Kconfig
> > +++ b/drivers/mtd/nand/Kconfig
> > @@ -9,4 +9,11 @@ source "drivers/mtd/nand/onenand/Kconfig"
> > source "drivers/mtd/nand/raw/Kconfig"
> > source "drivers/mtd/nand/spi/Kconfig"
> >
> > +menu "ECC engine support"
> > +
> > +config MTD_NAND_ECC
> > + bool
> > +
> > +endmenu
> > +
> > endmenu
> > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
> > index 7ecd80c0a66e..981372953b56 100644
> > --- a/drivers/mtd/nand/Makefile
> > +++ b/drivers/mtd/nand/Makefile
> > @@ -6,3 +6,5 @@ obj-$(CONFIG_MTD_NAND_CORE) += nandcore.o
> > obj-y += onenand/
> > obj-y += raw/
> > obj-y += spi/
> > +
> > +nandcore-$(CONFIG_MTD_NAND_ECC) += ecc.o
> > diff --git a/drivers/mtd/nand/ecc.c b/drivers/mtd/nand/ecc.c
> > new file mode 100644
> > index 000000000000..e4f2b6fcbb12
> > --- /dev/null
> > +++ b/drivers/mtd/nand/ecc.c
> > @@ -0,0 +1,138 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Generic Error-Correcting Code (ECC) engine
> > + *
> > + * Copyright (C) 2019 Macronix
> > + * Author:
> > + * Miquèl RAYNAL <miquel.raynal@bootlin.com>
> > + *
> > + *
> > + * This file describes the abstraction of any NAND ECC engine. It has been
> > + * designed to fit most cases, including parallel NANDs and SPI-NANDs.
> > + *
> > + * There are three main situations where instantiating this ECC engine makes
> > + * sense:
> > + * - "external": The ECC engine is outside the NAND pipeline, typically this
>
> I'm not sure why you put quotes around those names.
>
> > + * is a software ECC engine. One can also imagine a generic
>
> ^ or an hardware
> engine that's outside the NAND controller pipeline.
>
> You can the drop the "One can also imagine ..." since it's more than a
> theoretical use case, we already have a few engines that fall in this
> category.
>
> > + * hardware ECC engine which would be an IP itself. Interacting
> > + * with a SPI-NAND device without on-die ECC could be achieved
>
> ^can
>
> > + * thanks to the use of such external engine.
>
> But I think I would simply drop this last sentence.
>
> > + * - "pipelined": The ECC engine is inside the NAND pipeline, ie. on the
> > + * controller's side. This is the case of most of the raw NAND
> > + * controllers. These controllers usually embed an hardware ECC
> > + * engine which is managed thanks to the same register set as
> > + * the controller's.
>
> Again, I would drop the last sentence here. I think saying the ECC
> bytes are generated/data corrected on the fly when a page is
> written/read would be more useful.
>
> > + * - "ondie": The ECC engine is inside the NAND pipeline, on the chip's side.
> > + * Some NAND chips can correct themselves the data. The on-die
> > + * correction can be enabled, disabled and the status of the
> > + * correction after a read may be retrieved with a NAND command
> > + * (may be vendor specific).
>
> "The on-die correction can be enabled, disabled" -> this is true for
> any kind of ECC engine :P.
>
> > + *
> > + * Besides the initial setup and final cleanups, the interfaces are rather
> > + * simple:
> > + * - "prepare": Prepare an I/O request, check the ECC engine is enabled or
>
> ^if/whether
>
> > + * disabled as requested before the I/O. In case of software
>
> How about "Enable/disable the ECC engine based on the I/O request type."
>
> > + * correction, this step may involve to derive the ECC bytes and
> > + * place them in the OOB area before a write.
>
> This is also true for external hardware ECC engines.
>
> > + * - "finish": Finish an I/O request, check the status of the operation ie.
> > + * the data validity in case of a read (report to the upper layer
> > + * any bitflip/errors).
>
> It's all about correcting/reporting errors, right. Let's try to put
> that into simple words: "Correct the data in case of a read request and
> report the number of corrected bits/uncorrectable errors. Most likely
> empty for write operations, unless you have hardware specific stuff to
> do, like shutting down the engine to save some power"
>
> > + *
> > + * Both prepare/finish callbacks are supposed to enclose I/O request and will
>
> "The I/O request should be enclosed in a prepare()/finish() pair of
> calls" or "The prepare/finish call should surround the I/O request".
>
> > + * behave differently depending on the desired correction:
>
> ^requested I/O type
>
> > + * - "raw": Correction disabled
> > + * - "ecc": Correction enabled
> > + *
> > + * The request direction is impacting the logic as well:
> > + * - "read": Load data from the NAND chip
> > + * - "write": Store data in the NAND chip
> > + *
> > + * Mixing all this combinations together gives the following behavior.
>
> Mention that those are just examples, and drivers are free to add
> custom steps in their prepare/finish hooks.
>
> > + *
> > + * ["external" ECC engine]
> > + * - external + prepare + raw + read: do nothing
> > + * - external + finish + raw + read: do nothing
> > + * - external + prepare + raw + write: do nothing
> > + * - external + finish + raw + write: do nothing
> > + * - external + prepare + ecc + read: do nothing
> > + * - external + finish + ecc + read: calculate expected ECC bytes, extract
> > + * ECC bytes from OOB buffer, correct
> > + * and report any bitflip/error
> > + * - external + prepare + ecc + write: calculate ECC bytes and store them at
> > + * the right place in the OOB buffer based
> > + * on the OOB layout
> > + * - external + finish + ecc + write: do nothing
> > + *
> > + * ["pipelined" ECC engine]
> > + * - pipelined + prepare + raw + read: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + read: do nothing
> > + * - pipelined + prepare + raw + write: disable the controller's ECC engine if
> > + * activated
> > + * - pipelined + finish + raw + write: do nothing
> > + * - pipelined + prepare + ecc + read: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + read: check the status, report any
> > + * error/bitflip
> > + * - pipelined + prepare + ecc + write: enable the controller's ECC engine if
> > + * deactivated
> > + * - pipelined + finish + ecc + write: do nothing
> > + *
> > + * ["ondie" ECC engine]
> > + * - ondie + prepare + raw + read: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + read: do nothing
> > + * - ondie + prepare + raw + write: send commands to disable the on-chip ECC
> > + * engine if activated
> > + * - ondie + finish + raw + write: do nothing
> > + * - ondie + prepare + ecc + read: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + read: send commands to check the status, report
> > + * any error/bitflip
> > + * - ondie + prepare + ecc + write: send commands to enable the on-chip ECC
> > + * engine if deactivated
> > + * - ondie + finish + ecc + write: do nothing
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/mtd/nand.h>
> > +
>
> Shouldn't we have kernel-docs for those functions?
>
> > +int nand_ecc_init_ctx(struct nand_device *nand)
> > +{
> > + if (!nand->ecc.engine->ops->init_ctx)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->init_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_init_ctx);
> > +
> > +void nand_ecc_cleanup_ctx(struct nand_device *nand)
> > +{
> > + if (nand->ecc.engine->ops->cleanup_ctx)
> > + nand->ecc.engine->ops->cleanup_ctx(nand);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_cleanup_ctx);
> > +
> > +int nand_ecc_prepare_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->prepare_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->prepare_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_prepare_io_req);
> > +
> > +int nand_ecc_finish_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req)
> > +{
> > + if (!nand->ecc.engine->ops->finish_io_req)
> > + return 0;
> > +
> > + return nand->ecc.engine->ops->finish_io_req(nand, req);
> > +}
> > +EXPORT_SYMBOL(nand_ecc_finish_io_req);
> > +
> > +MODULE_LICENSE("GPL");
> > +MODULE_AUTHOR("Miquel Raynal <miquel.raynal@bootlin.com>");
> > +MODULE_DESCRIPTION("Generic ECC engine");
> > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> > index 2e9af24936cd..0be260fd2f86 100644
> > --- a/include/linux/mtd/nand.h
> > +++ b/include/linux/mtd/nand.h
> > @@ -221,6 +221,73 @@ struct nand_ops {
> > bool (*isbad)(struct nand_device *nand, const struct nand_pos *pos);
> > };
> >
> > +/**
> > + * struct nand_ecc_context - Context for the ECC engine
> > + * @conf: basic ECC engine parameters
> > + * @total: Total number of bytes used for storing ECC codes, this is used by
>
> Sometimes you start your description with an uppercase, sometimes not.
>
> > + * generic OOB layouts
> > + * @priv: ECC engine driver private data
> > + */
> > +struct nand_ecc_context {
> > + struct nand_ecc_props conf;
> > + unsigned int total;
> > + void *priv;
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine_ops - Generic ECC engine operations
>
> ^s/Generic//
>
> > + * @init_ctx: given a desired user configuration for the pointed NAND device,
> > + * requests the ECC engine driver to setup a configuration with
> > + * values it supports.
> > + * @cleanup_ctx: clean the context initialized by @init_ctx.
> > + * @prepare_io_req: is called before reading/writing a page to prepare the I/O
> > + * request to be performed with ECC correction.
> > + * @finish_io_req: is called after reading/writing a page to terminate the I/O
> > + * request and ensure proper ECC correction.
> > + */
> > +struct nand_ecc_engine_ops {
> > + int (*init_ctx)(struct nand_device *nand);
> > + void (*cleanup_ctx)(struct nand_device *nand);
> > + int (*prepare_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > + int (*finish_io_req)(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +};
> > +
> > +/**
> > + * struct nand_ecc_engine - Generic ECC engine abstraction for NAND devices
>
> ^s/Generic//
>
> > + * @ops: ECC engine operations
> > + */
> > +struct nand_ecc_engine {
> > + struct nand_ecc_engine_ops *ops;
> > +};
> > +
> > +int nand_ecc_init_ctx(struct nand_device *nand);
> > +void nand_ecc_cleanup_ctx(struct nand_device *nand);
> > +int nand_ecc_prepare_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +int nand_ecc_finish_io_req(struct nand_device *nand,
> > + struct nand_page_io_req *req);
> > +
> > +/**
> > + * struct nand_ecc - High-level ECC object
>
> I think you can drop the "High-level" and just say "Information
> relative to the ECC"
>
> > + * @defaults: Default values, depend on the underlying subsystem
> > + * @requirements: ECC requirements from the NAND chip perspective
> > + * @user_conf: User desires in terms of ECC parameters
> > + * @ctx: ECC context for the ECC engine, derived from the device @requirements
> > + * the @user_conf and the @defaults
> > + * @ondie_engine: On-die ECC engine reference, if any
> > + * @engine: ECC engine actually bound
> > + */
> > +struct nand_ecc {
> > + struct nand_ecc_props defaults;
> > + struct nand_ecc_props requirements;
> > + struct nand_ecc_props user_conf;
> > + struct nand_ecc_context ctx;
> > + struct nand_ecc_engine *ondie_engine;
> > + struct nand_ecc_engine *engine;
> > +};
> > +
> > /**
> > * struct nand_device - NAND device
> > * @mtd: MTD instance attached to the NAND device
>
All comments applied.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH v6 16/18] mtd: nand: Convert generic NAND bits to use the ECC framework
From: Miquel Raynal @ 2020-05-28 23:48 UTC (permalink / raw)
To: Boris Brezillon
Cc: Richard Weinberger, Vignesh Raghavendra, Tudor Ambarus, linux-mtd,
Rob Herring, Mark Rutland, devicetree, Thomas Petazzoni,
Paul Cercueil, Chuanhong Guo, Weijie Gao, linux-arm-kernel,
Mason Yang, Julien Su
In-Reply-To: <20200528180003.0f682e6f@collabora.com>
Boris Brezillon <boris.brezillon@collabora.com> wrote on Thu, 28 May
2020 18:00:03 +0200:
> On Thu, 28 May 2020 13:31:11 +0200
> Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> > Embed a generic NAND ECC high-level object in the nand_device
> > structure to carry all the ECC engine configuration/data. Adapt the
> > raw NAND and SPI-NAND cores to fit the change.
>
> I would also split that one:
>
> 1/ s/nand_ecc_props/nand_ecc/ in the core + change the spi nand
> framework accordingly
>
> 2/ update rawnand to use the generic layer
This one I honestly don't understand how to split it. As long as I
change the NAND device object content, I have to update all
raw/spi-NAND devices in the same patch, or I would break the build. As
it there are already many many changes, I did not split this patch.
^ permalink raw reply
* Re: [PATCH v2 3/9] dt-bindings: irq: Add a compatible for the H3 R_INTC
From: Rob Herring @ 2020-05-28 23:50 UTC (permalink / raw)
To: Samuel Holland
Cc: Maxime Ripard, Chen-Yu Tsai, Jason Cooper, linux-arm-kernel,
Russell King, Marc Zyngier, Rob Herring, Thomas Gleixner,
devicetree, Will Deacon, Catalin Marinas, linux-sunxi,
linux-kernel
In-Reply-To: <20200525041302.51213-4-samuel@sholland.org>
On Sun, 24 May 2020 23:12:56 -0500, Samuel Holland wrote:
> The Allwinner H3 SoC contains an R_INTC that is, as far as we know,
> compatible with the R_INTC present in other sun8i/sun50i SoCs starting
> with the A31. Since the R_INTC hardware is undocumented, introduce a new
> compatible for the R_INTC variant in this SoC, in case there turns out
> to be some difference.
>
> Signed-off-by: Samuel Holland <samuel@sholland.org>
> ---
> .../allwinner,sun7i-a20-sc-nmi.yaml | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox