* [PATCH v25 04/16] leds: lp50xx: Add the LP50XX family of the RGB LED driver
From: Dan Murphy @ 2020-05-26 16:46 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200526164652.2331-1-dmurphy@ti.com>
Introduce the LP5036/30/24/18/12/9 RGB LED driver.
The difference in these parts are the number of
LED outputs where the:
LP5036 can control 36 LEDs
LP5030 can control 30 LEDs
LP5024 can control 24 LEDs
LP5018 can control 18 LEDs
LP5012 can control 12 LEDs
LP5009 can control 9 LEDs
The device has the ability to group LED output into control banks
so that multiple LED banks can be controlled with the same mixing and
brightness. Inversely the LEDs can also be controlled independently.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
drivers/leds/Kconfig | 11 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-lp50xx.c | 778 +++++++++++++++++++++++++++++++++++++
3 files changed, 790 insertions(+)
create mode 100644 drivers/leds/leds-lp50xx.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index fe7d90d4fa23..07dde638b23d 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -374,6 +374,17 @@ config LEDS_LP3952
To compile this driver as a module, choose M here: the
module will be called leds-lp3952.
+config LEDS_LP50XX
+ tristate "LED Support for TI LP5036/30/24/18/12/9 LED driver chip"
+ depends on LEDS_CLASS && REGMAP_I2C
+ depends on LEDS_CLASS_MULTI_COLOR || !LEDS_CLASS_MULTI_COLOR
+ help
+ If you say yes here you get support for the Texas Instruments
+ LP5036, LP5030, LP5024, LP5018, LP5012 and LP5009 LED driver.
+
+ To compile this driver as a module, choose M here: the
+ module will be called leds-lp50xx.
+
config LEDS_LP55XX_COMMON
tristate "Common Driver for TI/National LP5521/5523/55231/5562/8501"
depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 53bf92f30258..5ac6ed3ed075 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_LEDS_LM3697) += leds-lm3697.o
obj-$(CONFIG_LEDS_LOCOMO) += leds-locomo.o
obj-$(CONFIG_LEDS_LP3944) += leds-lp3944.o
obj-$(CONFIG_LEDS_LP3952) += leds-lp3952.o
+obj-$(CONFIG_LEDS_LP50XX) += leds-lp50xx.o
obj-$(CONFIG_LEDS_LP5521) += leds-lp5521.o
obj-$(CONFIG_LEDS_LP5523) += leds-lp5523.o
obj-$(CONFIG_LEDS_LP5562) += leds-lp5562.o
diff --git a/drivers/leds/leds-lp50xx.c b/drivers/leds/leds-lp50xx.c
new file mode 100644
index 000000000000..888bb54be55f
--- /dev/null
+++ b/drivers/leds/leds-lp50xx.c
@@ -0,0 +1,778 @@
+// SPDX-License-Identifier: GPL-2.0
+// TI LP50XX LED chip family driver
+// Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/leds.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+#include <uapi/linux/uleds.h>
+
+#include <linux/led-class-multicolor.h>
+
+#include "leds.h"
+
+#define LP50XX_DEV_CFG0 0x00
+#define LP50XX_DEV_CFG1 0x01
+#define LP50XX_LED_CFG0 0x02
+
+/* LP5009 and LP5012 registers */
+#define LP5012_BNK_BRT 0x03
+#define LP5012_BNKA_CLR 0x04
+#define LP5012_BNKB_CLR 0x05
+#define LP5012_BNKC_CLR 0x06
+#define LP5012_LED0_BRT 0x07
+#define LP5012_LED1_BRT 0x08
+#define LP5012_LED2_BRT 0x09
+#define LP5012_LED3_BRT 0x0a
+#define LP5012_OUT0_CLR 0x0b
+#define LP5012_OUT1_CLR 0x0c
+#define LP5012_OUT2_CLR 0x0d
+#define LP5012_OUT3_CLR 0x0e
+#define LP5012_OUT4_CLR 0x0f
+#define LP5012_OUT5_CLR 0x10
+#define LP5012_OUT6_CLR 0x11
+#define LP5012_OUT7_CLR 0x12
+#define LP5012_OUT8_CLR 0x13
+#define LP5012_OUT9_CLR 0x14
+#define LP5012_OUT10_CLR 0x15
+#define LP5012_OUT11_CLR 0x16
+#define LP5012_RESET 0x17
+
+/* LP5018 and LP5024 registers */
+#define LP5024_BNK_BRT 0x03
+#define LP5024_BNKA_CLR 0x04
+#define LP5024_BNKB_CLR 0x05
+#define LP5024_BNKC_CLR 0x06
+#define LP5024_LED0_BRT 0x07
+#define LP5024_LED1_BRT 0x08
+#define LP5024_LED2_BRT 0x09
+#define LP5024_LED3_BRT 0x0a
+#define LP5024_LED4_BRT 0x0b
+#define LP5024_LED5_BRT 0x0c
+#define LP5024_LED6_BRT 0x0d
+#define LP5024_LED7_BRT 0x0e
+
+#define LP5024_OUT0_CLR 0x0f
+#define LP5024_OUT1_CLR 0x10
+#define LP5024_OUT2_CLR 0x11
+#define LP5024_OUT3_CLR 0x12
+#define LP5024_OUT4_CLR 0x13
+#define LP5024_OUT5_CLR 0x14
+#define LP5024_OUT6_CLR 0x15
+#define LP5024_OUT7_CLR 0x16
+#define LP5024_OUT8_CLR 0x17
+#define LP5024_OUT9_CLR 0x18
+#define LP5024_OUT10_CLR 0x19
+#define LP5024_OUT11_CLR 0x1a
+#define LP5024_OUT12_CLR 0x1b
+#define LP5024_OUT13_CLR 0x1c
+#define LP5024_OUT14_CLR 0x1d
+#define LP5024_OUT15_CLR 0x1e
+#define LP5024_OUT16_CLR 0x1f
+#define LP5024_OUT17_CLR 0x20
+#define LP5024_OUT18_CLR 0x21
+#define LP5024_OUT19_CLR 0x22
+#define LP5024_OUT20_CLR 0x23
+#define LP5024_OUT21_CLR 0x24
+#define LP5024_OUT22_CLR 0x25
+#define LP5024_OUT23_CLR 0x26
+#define LP5024_RESET 0x27
+
+/* LP5030 and LP5036 registers */
+#define LP5036_LED_CFG1 0x03
+#define LP5036_BNK_BRT 0x04
+#define LP5036_BNKA_CLR 0x05
+#define LP5036_BNKB_CLR 0x06
+#define LP5036_BNKC_CLR 0x07
+#define LP5036_LED0_BRT 0x08
+#define LP5036_LED1_BRT 0x09
+#define LP5036_LED2_BRT 0x0a
+#define LP5036_LED3_BRT 0x0b
+#define LP5036_LED4_BRT 0x0c
+#define LP5036_LED5_BRT 0x0d
+#define LP5036_LED6_BRT 0x0e
+#define LP5036_LED7_BRT 0x0f
+#define LP5036_LED8_BRT 0x10
+#define LP5036_LED9_BRT 0x11
+#define LP5036_LED10_BRT 0x12
+#define LP5036_LED11_BRT 0x13
+
+#define LP5036_OUT0_CLR 0x14
+#define LP5036_OUT1_CLR 0x15
+#define LP5036_OUT2_CLR 0x16
+#define LP5036_OUT3_CLR 0x17
+#define LP5036_OUT4_CLR 0x18
+#define LP5036_OUT5_CLR 0x19
+#define LP5036_OUT6_CLR 0x1a
+#define LP5036_OUT7_CLR 0x1b
+#define LP5036_OUT8_CLR 0x1c
+#define LP5036_OUT9_CLR 0x1d
+#define LP5036_OUT10_CLR 0x1e
+#define LP5036_OUT11_CLR 0x1f
+#define LP5036_OUT12_CLR 0x20
+#define LP5036_OUT13_CLR 0x21
+#define LP5036_OUT14_CLR 0x22
+#define LP5036_OUT15_CLR 0x23
+#define LP5036_OUT16_CLR 0x24
+#define LP5036_OUT17_CLR 0x25
+#define LP5036_OUT18_CLR 0x26
+#define LP5036_OUT19_CLR 0x27
+#define LP5036_OUT20_CLR 0x28
+#define LP5036_OUT21_CLR 0x29
+#define LP5036_OUT22_CLR 0x2a
+#define LP5036_OUT23_CLR 0x2b
+#define LP5036_OUT24_CLR 0x2c
+#define LP5036_OUT25_CLR 0x2d
+#define LP5036_OUT26_CLR 0x2e
+#define LP5036_OUT27_CLR 0x2f
+#define LP5036_OUT28_CLR 0x30
+#define LP5036_OUT29_CLR 0x31
+#define LP5036_OUT30_CLR 0x32
+#define LP5036_OUT31_CLR 0x33
+#define LP5036_OUT32_CLR 0x34
+#define LP5036_OUT33_CLR 0x35
+#define LP5036_OUT34_CLR 0x36
+#define LP5036_OUT35_CLR 0x37
+#define LP5036_RESET 0x38
+
+#define LP50XX_SW_RESET 0xff
+#define LP50XX_CHIP_EN BIT(6)
+
+/* There are 3 LED outputs per bank */
+#define LP50XX_LEDS_PER_MODULE 3
+
+#define LP5009_MAX_LED_MODULES 2
+#define LP5012_MAX_LED_MODULES 4
+#define LP5018_MAX_LED_MODULES 6
+#define LP5024_MAX_LED_MODULES 8
+#define LP5030_MAX_LED_MODULES 10
+#define LP5036_MAX_LED_MODULES 12
+
+#define LP5009_MAX_LEDS (LP5009_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5012_MAX_LEDS (LP5012_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5018_MAX_LEDS (LP5018_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5024_MAX_LEDS (LP5024_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5030_MAX_LEDS (LP5030_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+#define LP5036_MAX_LEDS (LP5036_MAX_LED_MODULES * LP50XX_LEDS_PER_MODULE)
+
+static const struct reg_default lp5012_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5012_BNK_BRT, 0xff},
+ {LP5012_BNKA_CLR, 0x0f},
+ {LP5012_BNKB_CLR, 0x0f},
+ {LP5012_BNKC_CLR, 0x0f},
+ {LP5012_LED0_BRT, 0x0f},
+ {LP5012_LED1_BRT, 0xff},
+ {LP5012_LED2_BRT, 0xff},
+ {LP5012_LED3_BRT, 0xff},
+ {LP5012_OUT0_CLR, 0x0f},
+ {LP5012_OUT1_CLR, 0x00},
+ {LP5012_OUT2_CLR, 0x00},
+ {LP5012_OUT3_CLR, 0x00},
+ {LP5012_OUT4_CLR, 0x00},
+ {LP5012_OUT5_CLR, 0x00},
+ {LP5012_OUT6_CLR, 0x00},
+ {LP5012_OUT7_CLR, 0x00},
+ {LP5012_OUT8_CLR, 0x00},
+ {LP5012_OUT9_CLR, 0x00},
+ {LP5012_OUT10_CLR, 0x00},
+ {LP5012_OUT11_CLR, 0x00},
+ {LP5012_RESET, 0x00}
+};
+
+static const struct reg_default lp5024_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5024_BNK_BRT, 0xff},
+ {LP5024_BNKA_CLR, 0x0f},
+ {LP5024_BNKB_CLR, 0x0f},
+ {LP5024_BNKC_CLR, 0x0f},
+ {LP5024_LED0_BRT, 0x0f},
+ {LP5024_LED1_BRT, 0xff},
+ {LP5024_LED2_BRT, 0xff},
+ {LP5024_LED3_BRT, 0xff},
+ {LP5024_LED4_BRT, 0xff},
+ {LP5024_LED5_BRT, 0xff},
+ {LP5024_LED6_BRT, 0xff},
+ {LP5024_LED7_BRT, 0xff},
+ {LP5024_OUT0_CLR, 0x0f},
+ {LP5024_OUT1_CLR, 0x00},
+ {LP5024_OUT2_CLR, 0x00},
+ {LP5024_OUT3_CLR, 0x00},
+ {LP5024_OUT4_CLR, 0x00},
+ {LP5024_OUT5_CLR, 0x00},
+ {LP5024_OUT6_CLR, 0x00},
+ {LP5024_OUT7_CLR, 0x00},
+ {LP5024_OUT8_CLR, 0x00},
+ {LP5024_OUT9_CLR, 0x00},
+ {LP5024_OUT10_CLR, 0x00},
+ {LP5024_OUT11_CLR, 0x00},
+ {LP5024_OUT12_CLR, 0x00},
+ {LP5024_OUT13_CLR, 0x00},
+ {LP5024_OUT14_CLR, 0x00},
+ {LP5024_OUT15_CLR, 0x00},
+ {LP5024_OUT16_CLR, 0x00},
+ {LP5024_OUT17_CLR, 0x00},
+ {LP5024_OUT18_CLR, 0x00},
+ {LP5024_OUT19_CLR, 0x00},
+ {LP5024_OUT20_CLR, 0x00},
+ {LP5024_OUT21_CLR, 0x00},
+ {LP5024_OUT22_CLR, 0x00},
+ {LP5024_OUT23_CLR, 0x00},
+ {LP5024_RESET, 0x00}
+};
+
+static const struct reg_default lp5036_reg_defs[] = {
+ {LP50XX_DEV_CFG0, 0x0},
+ {LP50XX_DEV_CFG1, 0x3c},
+ {LP50XX_LED_CFG0, 0x0},
+ {LP5036_LED_CFG1, 0x0},
+ {LP5036_BNK_BRT, 0xff},
+ {LP5036_BNKA_CLR, 0x0f},
+ {LP5036_BNKB_CLR, 0x0f},
+ {LP5036_BNKC_CLR, 0x0f},
+ {LP5036_LED0_BRT, 0x0f},
+ {LP5036_LED1_BRT, 0xff},
+ {LP5036_LED2_BRT, 0xff},
+ {LP5036_LED3_BRT, 0xff},
+ {LP5036_LED4_BRT, 0xff},
+ {LP5036_LED5_BRT, 0xff},
+ {LP5036_LED6_BRT, 0xff},
+ {LP5036_LED7_BRT, 0xff},
+ {LP5036_OUT0_CLR, 0x0f},
+ {LP5036_OUT1_CLR, 0x00},
+ {LP5036_OUT2_CLR, 0x00},
+ {LP5036_OUT3_CLR, 0x00},
+ {LP5036_OUT4_CLR, 0x00},
+ {LP5036_OUT5_CLR, 0x00},
+ {LP5036_OUT6_CLR, 0x00},
+ {LP5036_OUT7_CLR, 0x00},
+ {LP5036_OUT8_CLR, 0x00},
+ {LP5036_OUT9_CLR, 0x00},
+ {LP5036_OUT10_CLR, 0x00},
+ {LP5036_OUT11_CLR, 0x00},
+ {LP5036_OUT12_CLR, 0x00},
+ {LP5036_OUT13_CLR, 0x00},
+ {LP5036_OUT14_CLR, 0x00},
+ {LP5036_OUT15_CLR, 0x00},
+ {LP5036_OUT16_CLR, 0x00},
+ {LP5036_OUT17_CLR, 0x00},
+ {LP5036_OUT18_CLR, 0x00},
+ {LP5036_OUT19_CLR, 0x00},
+ {LP5036_OUT20_CLR, 0x00},
+ {LP5036_OUT21_CLR, 0x00},
+ {LP5036_OUT22_CLR, 0x00},
+ {LP5036_OUT23_CLR, 0x00},
+ {LP5036_OUT24_CLR, 0x00},
+ {LP5036_OUT25_CLR, 0x00},
+ {LP5036_OUT26_CLR, 0x00},
+ {LP5036_OUT27_CLR, 0x00},
+ {LP5036_OUT28_CLR, 0x00},
+ {LP5036_OUT29_CLR, 0x00},
+ {LP5036_OUT30_CLR, 0x00},
+ {LP5036_OUT31_CLR, 0x00},
+ {LP5036_OUT32_CLR, 0x00},
+ {LP5036_OUT33_CLR, 0x00},
+ {LP5036_OUT34_CLR, 0x00},
+ {LP5036_OUT35_CLR, 0x00},
+ {LP5036_RESET, 0x00}
+};
+
+static const struct regmap_config lp5012_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5012_RESET,
+ .reg_defaults = lp5012_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5012_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5024_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5024_RESET,
+ .reg_defaults = lp5024_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5024_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+static const struct regmap_config lp5036_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+
+ .max_register = LP5036_RESET,
+ .reg_defaults = lp5036_reg_defs,
+ .num_reg_defaults = ARRAY_SIZE(lp5036_reg_defs),
+ .cache_type = REGCACHE_RBTREE,
+};
+
+enum lp50xx_model {
+ LP5009,
+ LP5012,
+ LP5018,
+ LP5024,
+ LP5030,
+ LP5036,
+};
+
+/*
+ * struct lp50xx_chip_info -
+ * @num_leds: number of LED outputs available on the device
+ * @led_brightness0_reg: first brightness register of the device
+ * @mix_out0_reg: first color mix register of the device
+ * @bank_brt_reg: bank brightness register
+ * @bank_mix_reg: color mix register
+ * @reset_reg: device reset register
+ */
+struct lp50xx_chip_info {
+ const struct regmap_config *lp50xx_regmap_config;
+ int model_id;
+ u8 max_modules;
+ u8 num_leds;
+ u8 led_brightness0_reg;
+ u8 mix_out0_reg;
+ u8 bank_brt_reg;
+ u8 bank_mix_reg;
+ u8 reset_reg;
+};
+
+static const struct lp50xx_chip_info lp50xx_chip_info_tbl[] = {
+ [LP5009] = {
+ .model_id = LP5009,
+ .max_modules = LP5009_MAX_LED_MODULES,
+ .num_leds = LP5009_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5012] = {
+ .model_id = LP5012,
+ .max_modules = LP5012_MAX_LED_MODULES,
+ .num_leds = LP5012_MAX_LEDS,
+ .led_brightness0_reg = LP5012_LED0_BRT,
+ .mix_out0_reg = LP5012_OUT0_CLR,
+ .bank_brt_reg = LP5012_BNK_BRT,
+ .bank_mix_reg = LP5012_BNKA_CLR,
+ .reset_reg = LP5012_RESET,
+ .lp50xx_regmap_config = &lp5012_regmap_config,
+ },
+ [LP5018] = {
+ .model_id = LP5018,
+ .max_modules = LP5018_MAX_LED_MODULES,
+ .num_leds = LP5018_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5024] = {
+ .model_id = LP5024,
+ .max_modules = LP5024_MAX_LED_MODULES,
+ .num_leds = LP5024_MAX_LEDS,
+ .led_brightness0_reg = LP5024_LED0_BRT,
+ .mix_out0_reg = LP5024_OUT0_CLR,
+ .bank_brt_reg = LP5024_BNK_BRT,
+ .bank_mix_reg = LP5024_BNKA_CLR,
+ .reset_reg = LP5024_RESET,
+ .lp50xx_regmap_config = &lp5024_regmap_config,
+ },
+ [LP5030] = {
+ .model_id = LP5030,
+ .max_modules = LP5030_MAX_LED_MODULES,
+ .num_leds = LP5030_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+ [LP5036] = {
+ .model_id = LP5036,
+ .max_modules = LP5036_MAX_LED_MODULES,
+ .num_leds = LP5036_MAX_LEDS,
+ .led_brightness0_reg = LP5036_LED0_BRT,
+ .mix_out0_reg = LP5036_OUT0_CLR,
+ .bank_brt_reg = LP5036_BNK_BRT,
+ .bank_mix_reg = LP5036_BNKA_CLR,
+ .reset_reg = LP5036_RESET,
+ .lp50xx_regmap_config = &lp5036_regmap_config,
+ },
+};
+
+struct lp50xx_led {
+ struct led_classdev led_dev;
+ struct led_classdev_mc mc_cdev;
+ struct lp50xx *priv;
+ unsigned long bank_modules;
+ int led_intensity[LP50XX_LEDS_PER_MODULE];
+ u8 ctrl_bank_enabled;
+ int led_number;
+};
+
+/**
+ * struct lp50xx -
+ * @enable_gpio: hardware enable gpio
+ * @regulator: LED supply regulator pointer
+ * @client: pointer to the I2C client
+ * @regmap: device register map
+ * @dev: pointer to the devices device struct
+ * @lock: lock for reading/writing the device
+ * @chip_info: chip specific information (ie num_leds)
+ * @num_of_banked_leds: holds the number of banked LEDs
+ * @leds: array of LED strings
+ */
+struct lp50xx {
+ struct gpio_desc *enable_gpio;
+ struct regulator *regulator;
+ struct i2c_client *client;
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutex lock;
+ const struct lp50xx_chip_info *chip_info;
+ int num_of_banked_leds;
+
+ /* This needs to be at the end of the struct */
+ struct lp50xx_led leds[];
+};
+
+static struct lp50xx_led *mcled_cdev_to_led(struct led_classdev_mc *mc_cdev)
+{
+ return container_of(mc_cdev, struct lp50xx_led, mc_cdev);
+}
+
+static int lp50xx_brightness_set(struct led_classdev *cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev_mc *mc_dev = lcdev_to_mccdev(cdev);
+ struct lp50xx_led *led = mcled_cdev_to_led(mc_dev);
+ const struct lp50xx_chip_info *led_chip = led->priv->chip_info;
+ u8 led_offset, reg_val;
+ int ret = 0;
+ int i;
+
+ mutex_lock(&led->priv->lock);
+ if (led->ctrl_bank_enabled)
+ reg_val = led_chip->bank_brt_reg;
+ else
+ reg_val = led_chip->led_brightness0_reg +
+ led->led_number;
+
+ ret = regmap_write(led->priv->regmap, reg_val, brightness);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write brightness value %d\n", ret);
+ goto out;
+ }
+
+ for (i = 0; i < led->mc_cdev.num_colors; i++) {
+ if (led->ctrl_bank_enabled) {
+ reg_val = led_chip->bank_mix_reg + i;
+ } else {
+ led_offset = (led->led_number * 3) + i;
+ reg_val = led_chip->mix_out0_reg + led_offset;
+ }
+
+ ret = regmap_write(led->priv->regmap, reg_val,
+ mc_dev->subled_info[i].intensity);
+ if (ret) {
+ dev_err(&led->priv->client->dev,
+ "Cannot write intensity value %d\n", ret);
+ goto out;
+ }
+ }
+out:
+ mutex_unlock(&led->priv->lock);
+ return ret;
+}
+
+static int lp50xx_set_banks(struct lp50xx *priv, u32 led_banks[])
+{
+ u8 led_config_lo, led_config_hi;
+ u32 bank_enable_mask = 0;
+ int ret;
+ int i;
+
+ for (i = 0; i < priv->chip_info->max_modules; i++) {
+ if (led_banks[i])
+ bank_enable_mask |= (1 << led_banks[i]);
+ }
+
+ led_config_lo = (u8)(bank_enable_mask & 0xff);
+ led_config_hi = (u8)(bank_enable_mask >> 8) & 0xff;
+
+ ret = regmap_write(priv->regmap, LP50XX_LED_CFG0, led_config_lo);
+ if (ret)
+ return ret;
+
+ if (priv->chip_info->model_id >= LP5030)
+ ret = regmap_write(priv->regmap, LP5036_LED_CFG1,
+ led_config_hi);
+
+ return ret;
+}
+
+static int lp50xx_reset(struct lp50xx *priv)
+{
+ if (priv->enable_gpio)
+ return gpiod_direction_output(priv->enable_gpio, 1);
+ else
+ return regmap_write(priv->regmap, priv->chip_info->reset_reg,
+ LP50XX_SW_RESET);
+}
+
+static int lp50xx_enable_disable(struct lp50xx *priv, u8 enable_disable)
+{
+ return regmap_write(priv->regmap, LP50XX_DEV_CFG0, enable_disable);
+}
+
+static int lp50xx_probe_dt(struct lp50xx *priv)
+{
+ u32 led_banks[LP5036_MAX_LED_MODULES] = {0};
+ struct fwnode_handle *child = NULL;
+ struct fwnode_handle *led_node = NULL;
+ struct led_init_data init_data = {};
+ struct led_classdev *led_cdev;
+ struct mc_subled *mc_led_info;
+ struct lp50xx_led *led;
+ int num_colors;
+ u32 color_id;
+ int led_number;
+ size_t i = 0;
+ int ret = -EINVAL;
+
+ priv->enable_gpio = devm_gpiod_get_optional(priv->dev,
+ "enable", GPIOD_OUT_LOW);
+ if (IS_ERR(priv->enable_gpio)) {
+ ret = PTR_ERR(priv->enable_gpio);
+ dev_err(&priv->client->dev, "Failed to get enable gpio: %d\n",
+ ret);
+ return ret;
+ }
+
+ priv->regulator = devm_regulator_get(priv->dev, "vled");
+ if (IS_ERR(priv->regulator))
+ priv->regulator = NULL;
+
+ device_for_each_child_node(priv->dev, child) {
+ led = &priv->leds[i];
+ if (fwnode_property_present(child, "ti,led-bank")) {
+ ret = fwnode_property_count_u32(child, "ti,led-bank");
+ priv->num_of_banked_leds = ret;
+ if (priv->num_of_banked_leds >
+ priv->chip_info->max_modules) {
+ dev_err(&priv->client->dev,
+ "led-bank property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = fwnode_property_read_u32_array(child,
+ "ti,led-bank",
+ led_banks,
+ ret);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "led-bank property is missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ ret = lp50xx_set_banks(priv, led_banks);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "Cannot setup banked LEDs\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ led->ctrl_bank_enabled = 1;
+
+ } else {
+ ret = fwnode_property_read_u32(child, "reg",
+ &led_number);
+ if (ret) {
+ dev_err(&priv->client->dev,
+ "led reg property missing\n");
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ if (led_number > priv->chip_info->num_leds) {
+ dev_err(&priv->client->dev,
+ "led-sources property is invalid\n");
+ ret = -EINVAL;
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+
+ led->led_number = led_number;
+ }
+
+ init_data.fwnode = child;
+ fwnode_property_read_string(child, "linux,default-trigger",
+ &led->led_dev.default_trigger);
+ num_colors = 0;
+
+ /* There are only 3 LEDs per module otherwise they should be
+ * banked which also is presented as 3 LEDs
+ */
+ mc_led_info = devm_kcalloc(priv->dev, LP50XX_LEDS_PER_MODULE,
+ sizeof(*mc_led_info), GFP_KERNEL);
+ if (!mc_led_info)
+ return -ENOMEM;
+
+ fwnode_for_each_child_node(child, led_node) {
+ ret = fwnode_property_read_u32(led_node, "color",
+ &color_id);
+ if (ret)
+ dev_err(priv->dev, "Cannot read color\n");
+
+ mc_led_info[num_colors].color_index = color_id;
+ num_colors++;
+ }
+
+ led->priv = priv;
+ led->mc_cdev.num_colors = num_colors;
+ led->mc_cdev.subled_info = mc_led_info;
+ led_cdev = &led->mc_cdev.led_cdev;
+ led_cdev->brightness_set_blocking = lp50xx_brightness_set;
+ ret = devm_led_classdev_multicolor_register_ext(&priv->client->dev,
+ &led->mc_cdev,
+ &init_data);
+ if (ret) {
+ dev_err(&priv->client->dev, "led register err: %d\n",
+ ret);
+ fwnode_handle_put(child);
+ goto child_out;
+ }
+ i++;
+ }
+
+child_out:
+ return ret;
+}
+
+static int lp50xx_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct lp50xx *led;
+ int count;
+ int ret;
+
+ count = device_get_child_node_count(&client->dev);
+ if (!count) {
+ dev_err(&client->dev, "LEDs are not defined in device tree!");
+ return -ENODEV;
+ }
+
+ led = devm_kzalloc(&client->dev, struct_size(led, leds, count),
+ GFP_KERNEL);
+ if (!led)
+ return -ENOMEM;
+
+ mutex_init(&led->lock);
+ led->client = client;
+ led->dev = &client->dev;
+ led->chip_info = &lp50xx_chip_info_tbl[id->driver_data];
+ i2c_set_clientdata(client, led);
+ led->regmap = devm_regmap_init_i2c(client,
+ led->chip_info->lp50xx_regmap_config);
+ if (IS_ERR(led->regmap)) {
+ ret = PTR_ERR(led->regmap);
+ dev_err(&client->dev, "Failed to allocate register map: %d\n",
+ ret);
+ return ret;
+ }
+
+ ret = lp50xx_reset(led);
+ if (ret)
+ return ret;
+
+ ret = lp50xx_probe_dt(led);
+ if (ret)
+ return ret;
+
+ return lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+}
+
+static int lp50xx_remove(struct i2c_client *client)
+{
+ struct lp50xx *led = i2c_get_clientdata(client);
+ int ret;
+
+ ret = lp50xx_enable_disable(led, LP50XX_CHIP_EN);
+ if (ret) {
+ dev_err(&led->client->dev, "Failed to disable regulator\n");
+ return ret;
+ }
+
+ if (led->enable_gpio)
+ gpiod_direction_output(led->enable_gpio, 0);
+
+ if (led->regulator) {
+ ret = regulator_disable(led->regulator);
+ if (ret)
+ dev_err(&led->client->dev,
+ "Failed to disable regulator\n");
+ }
+
+ mutex_destroy(&led->lock);
+
+ return 0;
+}
+
+static const struct i2c_device_id lp50xx_id[] = {
+ { "lp5009", LP5009 },
+ { "lp5012", LP5012 },
+ { "lp5018", LP5018 },
+ { "lp5024", LP5024 },
+ { "lp5030", LP5030 },
+ { "lp5036", LP5036 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, lp50xx_id);
+
+static const struct of_device_id of_lp50xx_leds_match[] = {
+ { .compatible = "ti,lp5009", .data = (void *)LP5009 },
+ { .compatible = "ti,lp5012", .data = (void *)LP5012 },
+ { .compatible = "ti,lp5018", .data = (void *)LP5018 },
+ { .compatible = "ti,lp5024", .data = (void *)LP5024 },
+ { .compatible = "ti,lp5030", .data = (void *)LP5030 },
+ { .compatible = "ti,lp5036", .data = (void *)LP5036 },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_lp50xx_leds_match);
+
+static struct i2c_driver lp50xx_driver = {
+ .driver = {
+ .name = "lp50xx",
+ .of_match_table = of_lp50xx_leds_match,
+ },
+ .probe = lp50xx_probe,
+ .remove = lp50xx_remove,
+ .id_table = lp50xx_id,
+};
+module_i2c_driver(lp50xx_driver);
+
+MODULE_DESCRIPTION("Texas Instruments LP50XX LED driver");
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_LICENSE("GPL v2");
--
2.25.1
^ permalink raw reply related
* [PATCH v25 02/16] leds: multicolor: Introduce a multicolor class definition
From: Dan Murphy @ 2020-05-26 16:46 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200526164652.2331-1-dmurphy@ti.com>
Introduce a multicolor class that groups colored LEDs
within a LED node.
The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../ABI/testing/sysfs-class-led-multicolor | 34 +++
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++++++++
MAINTAINERS | 8 +
drivers/leds/Kconfig | 10 +
drivers/leds/Makefile | 1 +
drivers/leds/led-class-multicolor.c | 210 ++++++++++++++++++
include/linux/led-class-multicolor.h | 121 ++++++++++
8 files changed, 473 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 include/linux/led-class-multicolor.h
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor b/Documentation/ABI/testing/sysfs-class-led-multicolor
new file mode 100644
index 000000000000..7d33a82a4b07
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -0,0 +1,34 @@
+What: /sys/class/leds/<led>/brightness
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read/write
+ Writing to this file will update all LEDs within the group to a
+ calculated percentage of what each color LED intensity is set
+ to. The percentage is calculated for each grouped LED via the
+ equation below:
+
+ led_brightness = brightness * multi_intensity/max_brightness
+
+ For additional details please refer to
+ Documentation/leds/leds-class-multicolor.rst.
+
+ The value of the color is from 0 to
+ /sys/class/leds/<led>/max_brightness.
+
+What: /sys/class/leds/<led>/multi_index
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read
+ The multi_index array, when read, will output the LED colors
+ by name as they are indexed in the multi_intensity file.
+
+What: /sys/class/leds/<led>/multi_intensity
+Date: March 2020
+KernelVersion: 5.8
+Contact: Dan Murphy <dmurphy@ti.com>
+Description: read/write
+ Intensity level for the LED color within the array.
+ The intensities for each color must be entered based on the
+ multi_index array.
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index 060f4e485897..bc70c6aa7138 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -9,6 +9,7 @@ LEDs
leds-class
leds-class-flash
+ leds-class-multicolor
ledtrig-oneshot
ledtrig-transient
ledtrig-usbport
diff --git a/Documentation/leds/leds-class-multicolor.rst b/Documentation/leds/leds-class-multicolor.rst
new file mode 100644
index 000000000000..2dcde711c51c
--- /dev/null
+++ b/Documentation/leds/leds-class-multicolor.rst
@@ -0,0 +1,88 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================================
+MultiColor LED handling under Linux
+====================================
+
+Description
+===========
+The multicolor class groups monochrome LEDs and allows controlling two
+aspects of the final combined color: hue and lightness. The former is
+controlled via the multi_intensity array file and the latter is controlled
+via brightness file.
+
+Multicolor Class Control
+========================
+The multicolor class presents files that groups the colors as indexes in an
+array. These files are children under the LED parent node created by the
+led_class framework. The led_class framework is documented in led-class.rst
+within this documentation directory.
+
+Each colored LED will be indexed under the multi_* files. The order of the
+colors will be arbitrary. The multi_index file can be read to determine the
+color name to indexed value.
+
+The multi_index file is an array that contains the string list of the colors as
+they are defined in each multi_* array file.
+
+The multi_intensity is an array that can be read or written to for the
+individual color intensities. All elements within this array must be written in
+order for the color LED intensities to be updated.
+
+Directory Layout Example
+========================
+root:/sys/class/leds/multicolor:status# ls -lR
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 max_brightness
+-r--r--r-- 1 root root 4096 Oct 19 16:16 multi_index
+-rw-r--r-- 1 root root 4096 Oct 19 16:16 multi_intensity
+
+Multicolor Class Brightness Control
+===================================
+The multicolor class framework will calculate each monochrome LEDs intensity.
+
+The brightness level for each LED is calculated based on the color LED
+intensity setting divided by the global max_brightness setting multiplied by
+the requested brightness.
+
+led_brightness = brightness * multi_intensity/max_brightness
+
+Example:
+A user first writes the multi_intensity file with the brightness levels
+for each LED that are necessary to achieve a certain color output from a
+multicolor LED group.
+
+cat /sys/class/leds/multicolor:status/multi_index
+green blue red
+
+echo 43 226 138 > /sys/class/leds/multicolor:status/multi_intensity
+
+red -
+ intensity = 138
+ max_brightness = 255
+green -
+ intensity = 43
+ max_brightness = 255
+blue -
+ intensity = 226
+ max_brightness = 255
+
+The user can control the brightness of that multicolor LED group by writing the
+global 'brightness' control. Assuming a max_brightness of 255 the user
+may want to dim the LED color group to half. The user would write a value of
+128 to the global brightness file then the values written to each LED will be
+adjusted base on this value.
+
+cat /sys/class/leds/multicolor:status/max_brightness
+255
+echo 128 > /sys/class/leds/multicolor:status/brightness
+
+adjusted_red_value = 128 * 138/255 = 69
+adjusted_green_value = 128 * 43/255 = 21
+adjusted_blue_value = 128 * 226/255 = 113
+
+Reading the global brightness file will return the current brightness value of
+the color LED group.
+
+cat /sys/class/leds/multicolor:status/brightness
+128
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db31497..e5f0c3c17bea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,14 @@ F: Documentation/devicetree/bindings/leds/
F: drivers/leds/
F: include/linux/leds.h
+LED MULTICOLOR FRAMEWORK
+M: Dan Murphy <dmurphy@ti.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+F: Documentation/leds/leds-class-multicolor.rst
+F: drivers/leds/led-class-multicolor.c
+F: include/linux/led-class-multicolor.h
+
LEGACY EEPROM DRIVER
M: Jean Delvare <jdelvare@suse.com>
S: Maintained
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9cdc4cfc5d11..fe7d90d4fa23 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
for the flash related features of a LED device. It can be built
as a module.
+config LEDS_CLASS_MULTI_COLOR
+ tristate "LED MultiColor LED Class Support"
+ depends on LEDS_CLASS
+ help
+ This option enables the multicolor LED sysfs class in /sys/class/leds.
+ It wraps LED class and adds multicolor LED specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for multicolor LEDs that are grouped together. This class is not
+ intended for single color LEDs. It can be built as a module.
+
config LEDS_BRIGHTNESS_HW_CHANGED
bool "LED Class brightness_hw_changed attribute support"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index d0dff504f108..53bf92f30258 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -4,6 +4,7 @@
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
+obj-$(CONFIG_LEDS_CLASS_MULTI_COLOR) += led-class-multicolor.o
obj-$(CONFIG_LEDS_TRIGGERS) += led-triggers.o
# LED Platform Drivers (keep this sorted, M-| sort)
diff --git a/drivers/leds/led-class-multicolor.c b/drivers/leds/led-class-multicolor.c
new file mode 100644
index 000000000000..c108f4860fd7
--- /dev/null
+++ b/drivers/leds/led-class-multicolor.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0
+// LED Multi Color class interface
+// Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+// Author: Dan Murphy <dmurphy@ti.com>
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/led-class-multicolor.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/uaccess.h>
+
+#include "leds.h"
+
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ struct led_classdev *led_cdev = &mcled_cdev->led_cdev;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].brightness = brightness *
+ mcled_cdev->subled_info[i].intensity /
+ led_cdev->max_brightness;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(led_mc_calc_color_components);
+
+static ssize_t multi_intensity_store(struct device *dev,
+ struct device_attribute *intensity_attr,
+ const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int nrchars, offset = 0;
+ int intensity_value[LED_COLOR_ID_MAX];
+ int i;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ ret = sscanf(buf + offset, "%i%n",
+ &intensity_value[i], &nrchars);
+ if (ret != 1) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+ offset += nrchars;
+ }
+
+ /* account for the space at the end of the buffer */
+ offset++;
+ if (offset < size) {
+ dev_dbg(led_cdev->dev,
+ "Incorrect number of LEDs expected %i values intensity was not applied\n",
+ mcled_cdev->num_colors);
+ ret = -EINVAL;
+ goto err_out;
+ }
+
+ for (i = 0; i < mcled_cdev->num_colors; i++)
+ mcled_cdev->subled_info[i].intensity = intensity_value[i];
+
+ led_set_brightness(led_cdev, led_cdev->brightness);
+ ret = size;
+err_out:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t multi_intensity_show(struct device *dev,
+ struct device_attribute *intensity_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ len += sprintf(buf + len, "%d",
+ mcled_cdev->subled_info[i].intensity);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RW(multi_intensity);
+
+static ssize_t multi_index_show(struct device *dev,
+ struct device_attribute *multi_index_attr,
+ char *buf)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_mc *mcled_cdev = lcdev_to_mccdev(led_cdev);
+ int len = 0;
+ int index;
+ int i;
+
+ for (i = 0; i < mcled_cdev->num_colors; i++) {
+ index = mcled_cdev->subled_info[i].color_index;
+ len += sprintf(buf + len, "%s", led_colors[index]);
+ if (i < mcled_cdev->num_colors)
+ len += sprintf(buf + len, " ");
+ }
+
+ len += sprintf(buf + len, "\n");
+ return len;
+}
+static DEVICE_ATTR_RO(multi_index);
+
+static struct attribute *led_multicolor_attrs[] = {
+ &dev_attr_multi_intensity.attr,
+ &dev_attr_multi_index.attr,
+ NULL,
+};
+ATTRIBUTE_GROUPS(led_multicolor);
+
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev *led_cdev;
+
+ if (!mcled_cdev)
+ return -EINVAL;
+
+ if (!mcled_cdev->num_colors)
+ return -EINVAL;
+
+ if (mcled_cdev->num_colors > LED_COLOR_ID_MAX)
+ return -EINVAL;
+
+ led_cdev = &mcled_cdev->led_cdev;
+ mcled_cdev->led_cdev.groups = led_multicolor_groups;
+
+ return led_classdev_register_ext(parent, led_cdev, init_data);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_register_ext);
+
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev)
+{
+ if (!mcled_cdev)
+ return;
+
+ led_classdev_unregister(&mcled_cdev->led_cdev);
+}
+EXPORT_SYMBOL_GPL(led_classdev_multicolor_unregister);
+
+static void devm_led_classdev_multicolor_release(struct device *dev, void *res)
+{
+ led_classdev_multicolor_unregister(*(struct led_classdev_mc **)res);
+}
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ struct led_classdev_mc **dr;
+ int ret;
+
+ dr = devres_alloc(devm_led_classdev_multicolor_release,
+ sizeof(*dr), GFP_KERNEL);
+ if (!dr)
+ return -ENOMEM;
+
+ ret = led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ init_data);
+ if (ret) {
+ devres_free(dr);
+ return ret;
+ }
+
+ *dr = mcled_cdev;
+ devres_add(parent, dr);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_register_ext);
+
+static int devm_led_classdev_multicolor_match(struct device *dev,
+ void *res, void *data)
+{
+ struct led_classdev_mc **p = res;
+
+ if (WARN_ON(!p || !*p))
+ return 0;
+
+ return *p == data;
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *dev,
+ struct led_classdev_mc *mcled_cdev)
+{
+ WARN_ON(devres_release(dev,
+ devm_led_classdev_multicolor_release,
+ devm_led_classdev_multicolor_match, mcled_cdev));
+}
+EXPORT_SYMBOL_GPL(devm_led_classdev_multicolor_unregister);
+
+MODULE_AUTHOR("Dan Murphy <dmurphy@ti.com>");
+MODULE_DESCRIPTION("Multi Color LED class interface");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/led-class-multicolor.h b/include/linux/led-class-multicolor.h
new file mode 100644
index 000000000000..50bd986497f0
--- /dev/null
+++ b/include/linux/led-class-multicolor.h
@@ -0,0 +1,121 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* LED Multicolor class interface
+ * Copyright (C) 2019-20 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#ifndef _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+#define _LINUX_MULTICOLOR_LEDS_H_INCLUDED
+
+#include <linux/leds.h>
+#include <dt-bindings/leds/common.h>
+
+struct mc_subled {
+ int color_index;
+ int brightness;
+ int intensity;
+ int channel;
+};
+
+struct led_classdev_mc {
+ /* led class device */
+ struct led_classdev led_cdev;
+ int num_colors;
+
+ struct mc_subled *subled_info;
+};
+
+static inline struct led_classdev_mc *lcdev_to_mccdev(
+ struct led_classdev *led_cdev)
+{
+ return container_of(led_cdev, struct led_classdev_mc, led_cdev);
+}
+
+#if IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR)
+/**
+ * led_classdev_multicolor_register_ext - register a new object of led_classdev
+ * class with support for multicolor LEDs
+ * @parent: the multicolor LED to register
+ * @mcled_cdev: the led_classdev_mc structure for this device
+ * @init_data: the LED class Multi color device initialization data
+ *
+ * Returns: 0 on success or negative error value on failure
+ */
+int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+/**
+ * led_classdev_multicolor_unregister - unregisters an object of led_classdev
+ * class with support for multicolor LEDs
+ * @mcled_cdev: the multicolor LED to unregister
+ *
+ * Unregister a previously registered via led_classdev_multicolor_register
+ * object
+ */
+void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev);
+
+/* Calculate brightness for the monochrome LED cluster */
+int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness);
+
+int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data);
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev);
+#else
+
+static inline int led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return led_classdev_multicolor_register_ext(parent, mcled_cdev, NULL);
+}
+
+static inline void led_classdev_multicolor_unregister(struct led_classdev_mc *mcled_cdev) {};
+static inline int led_mc_calc_color_components(struct led_classdev_mc *mcled_cdev,
+ enum led_brightness brightness)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register_ext(struct device *parent,
+ struct led_classdev_mc *mcled_cdev,
+ struct led_init_data *init_data)
+{
+ return -EINVAL;
+}
+
+static inline int devm_led_classdev_multicolor_register(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{
+ return devm_led_classdev_multicolor_register_ext(parent, mcled_cdev,
+ NULL);
+}
+
+static inline void devm_led_classdev_multicolor_unregister(struct device *parent,
+ struct led_classdev_mc *mcled_cdev)
+{};
+
+#endif /* IS_ENABLED(CONFIG_LEDS_CLASS_MULTI_COLOR) */
+#endif /* _LINUX_MULTICOLOR_LEDS_H_INCLUDED */
--
2.25.1
^ permalink raw reply related
* [PATCH v25 03/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
From: Dan Murphy @ 2020-05-26 16:46 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200526164652.2331-1-dmurphy@ti.com>
Introduce the bindings for the Texas Instruments LP5036, LP5030, LP5024,
LP5018, LP5012 and LP5009 RGB LED device driver. The LP5036/30/24/18/12/9
can control RGB LEDs individually or as part of a control bank group.
These devices have the ability to adjust the mixing control for the RGB
LEDs to obtain different colors independent of the overall brightness of
the LED grouping.
Datasheet:
http://www.ti.com/lit/ds/symlink/lp5012.pdf
http://www.ti.com/lit/ds/symlink/lp5024.pdf
http://www.ti.com/lit/ds/symlink/lp5036.pdf
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++++++++++++++++
1 file changed, 180 insertions(+)
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
new file mode 100644
index 000000000000..a2ea03e07f6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -0,0 +1,180 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-lp50xx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: LED driver for LP50XX RGB LED from Texas Instruments.
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ The LP50XX is multi-channel, I2C RGB LED Drivers that can group RGB LEDs into
+ a LED group or control them individually.
+
+ The difference in these RGB LED drivers is the number of supported RGB
+ modules.
+
+ For more product information please see the link below:
+ http://www.ti.com/lit/ds/symlink/lp5012.pdf
+ http://www.ti.com/lit/ds/symlink/lp5024.pdf
+ http://www.ti.com/lit/ds/symlink/lp5036.pdf
+
+properties:
+ compatible:
+ oneOf:
+ - const: ti,lp5009
+ - const: ti,lp5012
+ - const: ti,lp5018
+ - const: ti,lp5024
+ - const: ti,lp5030
+ - const: ti,lp5036
+
+ reg:
+ maxItems: 1
+ description:
+ I2C slave address
+ lp5009/12 - 0x14, 0x15, 0x16, 0x17
+ lp5018/24 - 0x28, 0x29, 0x2a, 0x2b
+ lp5030/36 - 0x30, 0x31, 0x32, 0x33
+
+ enable-gpios:
+ description: GPIO pin to enable/disable the device.
+
+ vled-supply:
+ description: LED supply.
+
+ child-node:
+ type: object
+ properties:
+ reg:
+ description: This is the LED module number.
+
+ color:
+ description: Must be LED_COLOR_ID_MULTI
+
+ function:
+ description: see Documentation/devicetree/bindings/leds/common.txt
+
+ ti,led-bank:
+ description:
+ This property denotes the LED module numbers that will be controlled as
+ a single RGB cluster. Each LED module number will be controlled by a
+ single LED class instance.
+ There can only be one instance of the ti,led-bank
+ property for each device node. This is a required node is the LED
+ modules are to be backed.
+ $ref: /schemas/types.yaml#definitions/uint32-array
+
+ required:
+ - reg
+ - color
+ - function
+
+ grandchild-node:
+ type: object
+ properties:
+ reg:
+ description:
+ A single entry denoting the LED output that controls the monochrome LED.
+
+ color:
+ description:
+ see Documentation/devicetree/bindings/leds/common.txt
+
+ led-sources:
+ description:
+ see Documentation/devicetree/bindings/leds/common.txt
+ The LED outputs associated with the LED modules are defined in Table 1
+ of the corresponding data sheets.
+ LP5009 - 3 Total RGB cluster LED outputs 0-2
+ LP5012 - 4 Total RGB cluster LED outputs 0-3
+ LP5018 - 6 Total RGB cluster LED outputs 0-5
+ LP5024 - 8 Total RGB cluster LED outputs 0-7
+ LP5030 - 10 Total RGB cluster LED outputs 0-9
+ LP5036 - 12 Total RGB cluster LED outputs 0-11
+
+ label:
+ description: |
+ Optional node - see Documentation/devicetree/bindings/leds/common.txt
+
+ linux,default-trigger:
+ description: |
+ Optional node - see Documentation/devicetree/bindings/leds/common.txt
+
+ required:
+ - reg
+ - color
+
+required:
+ - compatible
+ - reg
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@14 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lp5009";
+ reg = <0x14>;
+ enable-gpios = <&gpio1 16>;
+ multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_CHARGING;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+
+ multi-led@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_STANDBY;
+ ti,led-bank = <2 3 5>;
+
+ led@6 {
+ reg = <0x6>;
+ color = <LED_COLOR_ID_RED>;
+ led-sources = <6 9 15>;
+ };
+
+ led@7 {
+ reg = <0x7>;
+ color = <LED_COLOR_ID_GREEN>;
+ led-sources = <7 10 16>;
+ };
+
+ led@8 {
+ reg = <0x8>;
+ color = <LED_COLOR_ID_BLUE>;
+ led-sources = <8 11 17>;
+ };
+ };
+ };
+ };
+
+...
--
2.25.1
^ permalink raw reply related
* [PATCH v25 00/16] Multicolor Framework v25
From: Dan Murphy @ 2020-05-26 16:46 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
Hello
This is the multi color LED framework. This framework presents clustered
colored LEDs into an array and allows the user space to adjust the brightness
of the cluster using a single file write. The individual colored LEDs
intensities are controlled via a single file that is an array of LEDs
Dan
Dan Murphy (16):
dt: bindings: Add multicolor class dt bindings documention
leds: multicolor: Introduce a multicolor class definition
dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers
leds: lp50xx: Add the LP50XX family of the RGB LED driver
dt: bindings: lp55xx: Be consistent in the document with LED acronym
dt: bindings: lp55xx: Update binding for Multicolor Framework
ARM: dts: n900: Add reg property to the LP5523 channel node
ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 channel node
ARM: dts: ste-href: Add reg property to the LP5521 channel nodes
leds: lp55xx: Convert LED class registration to devm_*
leds: lp55xx: Add multicolor framework support to lp55xx
leds: lp5523: Update the lp5523 code to add multicolor brightness
function
leds: lp5521: Add multicolor framework multicolor brightness support
leds: lp55xx: Fix checkpatch file permissions issues
leds: lp5523: Fix checkpatch issues in the code
dt: bindings: Update lp55xx binding to recommended LED naming
.../ABI/testing/sysfs-class-led-multicolor | 34 +
.../bindings/leds/leds-class-multicolor.yaml | 71 ++
.../devicetree/bindings/leds/leds-lp50xx.yaml | 180 ++++
.../devicetree/bindings/leds/leds-lp55xx.txt | 163 +++-
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-class-multicolor.rst | 88 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/imx6dl-yapp4-common.dtsi | 14 +-
arch/arm/boot/dts/omap3-n900.dts | 29 +-
arch/arm/boot/dts/ste-href.dtsi | 22 +-
drivers/leds/Kconfig | 24 +
drivers/leds/Makefile | 2 +
drivers/leds/led-class-multicolor.c | 210 +++++
drivers/leds/led-core.c | 1 +
drivers/leds/leds-lp50xx.c | 778 ++++++++++++++++++
drivers/leds/leds-lp5521.c | 43 +-
drivers/leds/leds-lp5523.c | 62 +-
drivers/leds/leds-lp5562.c | 22 +-
drivers/leds/leds-lp55xx-common.c | 213 +++--
drivers/leds/leds-lp55xx-common.h | 16 +-
drivers/leds/leds-lp8501.c | 23 +-
include/dt-bindings/leds/common.h | 3 +-
include/linux/led-class-multicolor.h | 121 +++
include/linux/platform_data/leds-lp55xx.h | 8 +
24 files changed, 1977 insertions(+), 159 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-led-multicolor
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
create mode 100644 Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
create mode 100644 Documentation/leds/leds-class-multicolor.rst
create mode 100644 drivers/leds/led-class-multicolor.c
create mode 100644 drivers/leds/leds-lp50xx.c
create mode 100644 include/linux/led-class-multicolor.h
--
2.25.1
^ permalink raw reply
* [PATCH v25 01/16] dt: bindings: Add multicolor class dt bindings documention
From: Dan Murphy @ 2020-05-26 16:46 UTC (permalink / raw)
To: jacek.anaszewski, pavel, robh
Cc: devicetree, linux-leds, linux-kernel, Dan Murphy
In-Reply-To: <20200526164652.2331-1-dmurphy@ti.com>
Add DT bindings for the LEDs multicolor class framework.
Add multicolor ID to the color ID list for device tree bindings.
CC: Rob Herring <robh@kernel.org>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Dan Murphy <dmurphy@ti.com>
---
.../bindings/leds/leds-class-multicolor.yaml | 71 +++++++++++++++++++
drivers/leds/led-core.c | 1 +
include/dt-bindings/leds/common.h | 3 +-
3 files changed, 74 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
new file mode 100644
index 000000000000..fa6ea8e5c46b
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/leds-class-multicolor.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Common properties for the multicolor LED class.
+
+maintainers:
+ - Dan Murphy <dmurphy@ti.com>
+
+description: |
+ Bindings for multi color LEDs show how to describe current outputs of
+ either integrated multi-color LED elements (like RGB, RGBW, RGBWA-UV
+ etc.) or standalone LEDs, to achieve logically grouped multi-color LED
+ modules. This is achieved by adding multi-led nodes layer to the
+ monochrome LED bindings.
+ The nodes and properties defined in this document are unique to the multicolor
+ LED class. Common LED nodes and properties are inherited from the common.txt
+ within this documentation directory.
+
+properties:
+ color:
+ description: |
+ For multicolor LED support this property should be defined as
+ LED_COLOR_ID_MULTI and further definition can be found in
+ include/linux/leds/common.h.
+
+required:
+ - color
+
+examples:
+ - |
+ #include <dt-bindings/leds/common.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@14 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "ti,lp5009";
+ reg = <0x14>;
+
+ multi-led@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ color = <LED_COLOR_ID_MULTI>;
+ function = LED_FUNCTION_CHARGING;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_RED>;
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_BLUE>;
+ };
+ };
+ };
+ };
+
+additionalProperties: false
+...
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index f1f718dbe0f8..846248a0693d 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -34,6 +34,7 @@ const char * const led_colors[LED_COLOR_ID_MAX] = {
[LED_COLOR_ID_VIOLET] = "violet",
[LED_COLOR_ID_YELLOW] = "yellow",
[LED_COLOR_ID_IR] = "ir",
+ [LED_COLOR_ID_MULTI] = "multicolor",
};
EXPORT_SYMBOL_GPL(led_colors);
diff --git a/include/dt-bindings/leds/common.h b/include/dt-bindings/leds/common.h
index 0ce7dfc00dcb..a463ce6a8794 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -30,7 +30,8 @@
#define LED_COLOR_ID_VIOLET 5
#define LED_COLOR_ID_YELLOW 6
#define LED_COLOR_ID_IR 7
-#define LED_COLOR_ID_MAX 8
+#define LED_COLOR_ID_MULTI 8
+#define LED_COLOR_ID_MAX 9
/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 3/6] dt-bindings: memory: Add Baikal-T1 L2-cache Control Block binding
From: Serge Semin @ 2020-05-26 16:12 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Thomas Bogendoerfer, linux-kernel, Rob Herring,
Alexey Malahov, Greg Kroah-Hartman, linux-mips, Arnd Bergmann,
Olof Johansson, soc, Paul Burton, devicetree
In-Reply-To: <20200526160915.GA4042264@bogus>
On Tue, May 26, 2020 at 10:09:15AM -0600, Rob Herring wrote:
> On Tue, 26 May 2020 15:59:25 +0300, Serge Semin wrote:
> > There is a single register provided by the SoC system controller,
> > which can be used to tune the L2-cache RAM up. It only provides a way
> > to change the L2-RAM access latencies. So aside from "be,bt1-l2-ctl"
> > compatible string the device node can be optionally equipped with the
> > properties of Tag/Data/WS latencies.
> >
> > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > Cc: Paul Burton <paulburton@kernel.org>
> > Cc: Olof Johansson <olof@lixom.net>
> > Cc: linux-mips@vger.kernel.org
> > Cc: soc@kernel.org
> >
> > ---
> >
> > Changelog v2:
> > - Move driver to the memory subsystem.
> > - Use dual GPL/BSD license.
> > - Use single lined copyright header.
> > - Move "allOf" restrictions to the root level of the properties.
> > - Discard syscon compatible string and reg property.
> > - The DT node is supposed to be a child of the Baikal-T1 system controller
> > node.
> >
> > Changelog v3:
> > - Get the reg property back even though the driver is using the parental
> > syscon regmap.
> > - The DT schema will live separately from the system controller, but the
> > corresponding sub-node of the later DT schema will $ref this one.
> > - Set non-default latencies in the example.
> > ---
> > .../memory-controllers/baikal,bt1-l2-ctl.yaml | 63 +++++++++++++++++++
> > 1 file changed, 63 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
> >
>
> Reviewed-by: Rob Herring <robh@kernel.org>
Great! Thanks.
-Sergey
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: memory: Add Baikal-T1 L2-cache Control Block binding
From: Rob Herring @ 2020-05-26 16:09 UTC (permalink / raw)
To: Serge Semin
Cc: Thomas Bogendoerfer, linux-kernel, Rob Herring, Serge Semin,
Alexey Malahov, Greg Kroah-Hartman, linux-mips, Arnd Bergmann,
Olof Johansson, soc, Paul Burton, devicetree
In-Reply-To: <20200526125928.17096-4-Sergey.Semin@baikalelectronics.ru>
On Tue, 26 May 2020 15:59:25 +0300, Serge Semin wrote:
> There is a single register provided by the SoC system controller,
> which can be used to tune the L2-cache RAM up. It only provides a way
> to change the L2-RAM access latencies. So aside from "be,bt1-l2-ctl"
> compatible string the device node can be optionally equipped with the
> properties of Tag/Data/WS latencies.
>
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> Cc: Paul Burton <paulburton@kernel.org>
> Cc: Olof Johansson <olof@lixom.net>
> Cc: linux-mips@vger.kernel.org
> Cc: soc@kernel.org
>
> ---
>
> Changelog v2:
> - Move driver to the memory subsystem.
> - Use dual GPL/BSD license.
> - Use single lined copyright header.
> - Move "allOf" restrictions to the root level of the properties.
> - Discard syscon compatible string and reg property.
> - The DT node is supposed to be a child of the Baikal-T1 system controller
> node.
>
> Changelog v3:
> - Get the reg property back even though the driver is using the parental
> syscon regmap.
> - The DT schema will live separately from the system controller, but the
> corresponding sub-node of the later DT schema will $ref this one.
> - Set non-default latencies in the example.
> ---
> .../memory-controllers/baikal,bt1-l2-ctl.yaml | 63 +++++++++++++++++++
> 1 file changed, 63 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/baikal,bt1-l2-ctl.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 07/10] media: i2c: imx290: Add RAW12 mode support
From: Dave Stevenson @ 2020-05-26 16:05 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mauro Carvalho Chehab, Sakari Ailus, manivannan.sadhasivam,
Linux Media Mailing List, LKML, devicetree, linux-arm-kernel,
c.barrett, a.brela, Peter Griffin
In-Reply-To: <20200524192505.20682-8-andrey.konovalov@linaro.org>
Hi Andrey
Thanks for the patch.
On Sun, 24 May 2020 at 20:26, Andrey Konovalov
<andrey.konovalov@linaro.org> wrote:
>
> From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>
> IMX290 is capable of outputting frames in both Raw Bayer (packed) 10 and
> 12 bit formats. Since the driver already supports RAW10 mode, let's add
> the missing RAW12 mode as well.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> Signed-off-by: Andrey Konovalov <andrey.konovalov@linaro.org>
> ---
> drivers/media/i2c/imx290.c | 36 +++++++++++++++++++++++++++++++++---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 162c345fffac..6e70ff22bc5f 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -71,6 +71,7 @@ struct imx290 {
> struct clk *xclk;
> struct regmap *regmap;
> u8 nlanes;
> + u8 bpp;
>
> struct v4l2_subdev sd;
> struct v4l2_fwnode_endpoint ep;
> @@ -90,10 +91,12 @@ struct imx290 {
>
> struct imx290_pixfmt {
> u32 code;
> + u8 bpp;
> };
>
> static const struct imx290_pixfmt imx290_formats[] = {
> - { MEDIA_BUS_FMT_SRGGB10_1X10 },
> + { MEDIA_BUS_FMT_SRGGB10_1X10, 10 },
> + { MEDIA_BUS_FMT_SRGGB12_1X12, 12 },
> };
>
> static const struct regmap_config imx290_regmap_config = {
> @@ -261,6 +264,18 @@ static const struct imx290_regval imx290_10bit_settings[] = {
> { 0x300b, 0x00},
> };
>
> +static const struct imx290_regval imx290_12bit_settings[] = {
> + { 0x3005, 0x01 },
> + { 0x3046, 0x01 },
> + { 0x3129, 0x00 },
> + { 0x317c, 0x00 },
> + { 0x31ec, 0x0e },
> + { 0x3441, 0x0c },
> + { 0x3442, 0x0c },
> + { 0x300a, 0xf0 },
> + { 0x300b, 0x00 },
> +};
> +
> /* supported link frequencies */
> static const s64 imx290_link_freq_2lanes[] = {
> 891000000, /* 1920x1080 - 2 lane */
> @@ -421,7 +436,12 @@ static int imx290_set_ctrl(struct v4l2_ctrl *ctrl)
> } else {
> imx290_write_reg(imx290, IMX290_PGCTRL, 0x00);
> msleep(10);
> - imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW, 0x3c);
> + if (imx290->bpp == 10)
> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
> + 0x3c);
> + else /* 12 bits per pixel */
> + imx290_write_reg(imx290, IMX290_BLKLEVEL_LOW,
> + 0xf0);
> imx290_write_reg(imx290, IMX290_BLKLEVEL_HIGH, 0x00);
> }
> break;
> @@ -496,7 +516,7 @@ static u64 imx290_calc_pixel_rate(struct imx290 *imx290)
> u8 nlanes = imx290->nlanes;
>
> /* pixel rate = link_freq * 2 * nr_of_lanes / bits_per_sample */
> - return (link_freq * 2 * nlanes / 10);
> + return (link_freq * 2 * nlanes / imx290->bpp);
This doesn't link on a 32bit system as it's a 64bit divide:
ERROR: "__aeabi_ldivmod" [drivers/media/i2c/imx290.ko] undefined!
It ought to be using do_div().
Admittedly it didn't compile before as you still had a s64 divide by
10, but I hadn't tried that :-)
Dave
> }
>
> static int imx290_set_fmt(struct v4l2_subdev *sd,
> @@ -533,6 +553,7 @@ static int imx290_set_fmt(struct v4l2_subdev *sd,
> } else {
> format = &imx290->current_format;
> imx290->current_mode = mode;
> + imx290->bpp = imx290_formats[i].bpp;
>
> if (imx290->link_freq)
> __v4l2_ctrl_s_ctrl(imx290->link_freq,
> @@ -577,6 +598,15 @@ static int imx290_write_current_format(struct imx290 *imx290)
> return ret;
> }
> break;
> + case MEDIA_BUS_FMT_SRGGB12_1X12:
> + ret = imx290_set_register_array(imx290, imx290_12bit_settings,
> + ARRAY_SIZE(
> + imx290_12bit_settings));
> + if (ret < 0) {
> + dev_err(imx290->dev, "Could not set format registers\n");
> + return ret;
> + }
> + break;
> default:
> dev_err(imx290->dev, "Unknown pixel format\n");
> return -EINVAL;
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v3 03/16] mfd: mfd-core: match device tree node against reg property
From: Andy Shevchenko @ 2020-05-26 16:03 UTC (permalink / raw)
To: Michael Walle
Cc: Lee Jones, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Jean Delvare, Guenter Roeck, Thierry Reding,
Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Brown,
Greg Kroah-Hartman, linux-gpio, devicetree, linux-kernel,
linux-hwmon, linux-pwm, linux-watchdog, linux-arm-kernel
In-Reply-To: <f5704ce5a3e280f63c81fe35efb08234@walle.cc>
On Tue, May 26, 2020 at 05:54:38PM +0200, Michael Walle wrote:
> Am 2020-05-26 09:24, schrieb Lee Jones:
...
> Like I said, in the long term I would like to have support for
> different versions of the board management controller
> without having to change the device tree and have device tree bindings for the
> subdevices at the same time.
But isn't device tree to describe *very specific platform* rather than *class
of platforms*?
> But it seems, that this is not possible
> and I guess I have to bite the bullet and may need to provide another
> device tree if the controller might be updated.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v3 03/16] mfd: mfd-core: match device tree node against reg property
From: Michael Walle @ 2020-05-26 15:54 UTC (permalink / raw)
To: Lee Jones
Cc: Andy Shevchenko, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Jean Delvare, Guenter Roeck, Thierry Reding,
Uwe Kleine-König, Wim Van Sebroeck, Shawn Guo, Li Yang,
Thomas Gleixner, Jason Cooper, Marc Zyngier, Mark Brown,
Greg Kroah-Hartman, linux-gpio, devicetree, linux-kernel,
linux-hwmon, linux-pwm, linux-watchdog, linux-arm-kernel
In-Reply-To: <20200526072427.GC3628@dell>
Am 2020-05-26 09:24, schrieb Lee Jones:
> On Mon, 25 May 2020, Michael Walle wrote:
>
>> Am 2020-05-15 12:28, schrieb Lee Jones:
>> > On Thu, 30 Apr 2020, Michael Walle wrote:
>> >
>> > > Hi Lee,
>> > >
>> > > Am 2020-04-23 19:45, schrieb Michael Walle:
>> > > > There might be multiple children with the device tree compatible, for
>> > > > example if a MFD has multiple instances of the same function. In this
>> > > > case only the first is matched and the other children get a wrong
>> > > > of_node reference.
>> > > > Add a new option to match also against the unit address of the child
>> > > > node. Additonally, a new helper OF_MFD_CELL_REG is added.
>> > >
>> > >
>> > > Do you think this is feasible? I guess this is the biggest uncertainty
>> > > for me at the moment in this patch series.
>> >
>> > I think it sounds fine in principle. So long as it doesn't change the
>> > existing behaviour when of_reg isn't set.
>> >
>> > > > Signed-off-by: Michael Walle <michael@walle.cc>
>> > > > ---
>> > > > drivers/mfd/mfd-core.c | 29 ++++++++++++++++++++---------
>> > > > include/linux/mfd/core.h | 26 ++++++++++++++++++++------
>> > > > 2 files changed, 40 insertions(+), 15 deletions(-)
>
> [...]
>
>> > > > diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
>> > > > index d01d1299e49d..c2c0ad6b14f3 100644
>> > > > --- a/include/linux/mfd/core.h
>> > > > +++ b/include/linux/mfd/core.h
>> > > > @@ -13,8 +13,11 @@
>> > > > #include <linux/platform_device.h>
>> > > >
>> > > > #define MFD_RES_SIZE(arr) (sizeof(arr) / sizeof(struct resource))
>> > > > +#define MFD_OF_REG_VALID BIT(31)
>> >
>> > What about 64bit platforms?
>>
>> The idea was to have this as a logical number. I.e. for now you may
>> only
>> have one subdevice per unique compatible string. In fact, if you have
>> a
>> look at the ab8500.c, there are multiple "stericsson,ab8500-pwm"
>> subdevices. But there is only one DT node for all three of it. I guess
>> this works as long as you don't use phandles to reference the pwm node
>> in the device tree. Or you don't want to use device tree properties
>> per subdevice (for example the "timeout-sec" of a watchdog device).
>>
>> So to circumvent this, I thought of having the unit-address (and thus
>> the "reg" property) to differentiate between multiple subdevices. Now
>> there is one special case for me: this board management controller
>> might be upgradable and it might change internally. Thus I came up
>> with that logical numbering of subdevices. Rob doesn't seem to be a
>> fan of that, though. Therefore, having bit 31 as a valid indicator
>> leaves you with 2^31 logical devices, which should be enough ;)
>>
>> Rob proposed to have the internal offset as the unit-address. But
>> in that case I can also use devm_of_platform_populate() and don't
>> need the OF_MFD_CELL_REG; I'd just parse the reg offset in each
>> individual subdevice driver. But like I said, I wanted to keep the
>> internal offsets out of the device tree.
>
> Oh, I see what you're doing.
>
> So you're adding an arbitrary ID to the device's reg property in DT?
Yes.
> How is this not a hack?
Well IMHO this is not more or less a hack as the current of_node
handling of MFD devices, which happens to work only because there
is only one device per compatible string (or it doesn't really work,
like in the stericsson,ab8500-pwm case). The of_node is assigned
according to the compatible string, just like in my case, only that
I have two subdevices with the same compatible string.
> Why don't you use the full address for identification?
Like I said, in the long term I would like to have support for
different versions of the board management controller without having
to change the device tree and have device tree bindings for the
subdevices at the same time. But it seems, that this is not possible
and I guess I have to bite the bullet and may need to provide another
device tree if the controller might be updated.
-michael
^ permalink raw reply
* [PATCH 0/2] mmc: mmci_sdmmc: fix dma api warnings
From: Ludovic Barre @ 2020-05-26 15:51 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
This patch series fixes warnings see with DMA_API_DEBUG_SG=y
Ludovic Barre (2):
mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
mmc: mmci_sdmmc: fix DMA API warning max segment size
drivers/mmc/host/mmci_stm32_sdmmc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
From: Ludovic Barre @ 2020-05-26 15:51 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
In-Reply-To: <20200526155103.12514-1-ludovic.barre@st.com>
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
WARNING: CPU: 1 PID: 20 at kernel/dma/debug.c:500 add_dma_entry+0x16c/0x17c
DMA-API: exceeded 7 overlapping mappings of cacheline 0x031d2645
Modules linked in:
CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.5.0-rc2-00021-gdeda30999c2b-dirty #49
Hardware name: STM32 (Device Tree Support)
Workqueue: events_freezable mmc_rescan
[<c03138c0>] (unwind_backtrace) from [<c030d760>] (show_stack+0x10/0x14)
[<c030d760>] (show_stack) from [<c0f2eb28>] (dump_stack+0xc0/0xd4)
[<c0f2eb28>] (dump_stack) from [<c034a14c>] (__warn+0xd0/0xf8)
[<c034a14c>] (__warn) from [<c034a530>] (warn_slowpath_fmt+0x94/0xb8)
[<c034a530>] (warn_slowpath_fmt) from [<c03bca0c>] (add_dma_entry+0x16c/0x17c)
[<c03bca0c>] (add_dma_entry) from [<c03bdf54>] (debug_dma_map_sg+0xe4/0x3d4)
[<c03bdf54>] (debug_dma_map_sg) from [<c0d09244>] (sdmmc_idma_prep_data+0x94/0xf8)
[<c0d09244>] (sdmmc_idma_prep_data) from [<c0d05a2c>] (mmci_prep_data+0x2c/0xb0)
[<c0d05a2c>] (mmci_prep_data) from [<c0d073ec>] (mmci_start_data+0x134/0x2f0)
[<c0d073ec>] (mmci_start_data) from [<c0d078d0>] (mmci_request+0xe8/0x154)
[<c0d078d0>] (mmci_request) from [<c0cecb44>] (mmc_start_request+0x94/0xbc)
DMA api debug brings to light leaking dma-mappings, dma_map_sg and
dma_unmap_sg are not correctly balanced.
If a request is prepared, the dma_map/unmap are done in asynchronous
call pre_req (prep_data) and post_req (unprep_data). In this case
the dma-mapping is right balanced.
But if the request was not prepared, the data->host_cookie is
define to zero and the dma_map/unmap must be done in the request.
The dma_map is called by mmci_dma_start (prep_data), but there is
no dma_unmap in this case.
This patch adds dma_unmap_sg when the dma is finalized and
the data cookie is zero (request not prepared).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci_stm32_sdmmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
index 14f99d8aa3f0..2965b1c062e1 100644
--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
+++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
@@ -188,6 +188,9 @@ static int sdmmc_idma_start(struct mmci_host *host, unsigned int *datactrl)
static void sdmmc_idma_finalize(struct mmci_host *host, struct mmc_data *data)
{
writel_relaxed(0, host->base + MMCI_STM32_IDMACTRLR);
+
+ if (!data->host_cookie)
+ sdmmc_idma_unprep_data(host, data, 0);
}
static void mmci_sdmmc_set_clkreg(struct mmci_host *host, unsigned int desired)
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] mmc: mmci_sdmmc: fix DMA API warning max segment size
From: Ludovic Barre @ 2020-05-26 15:51 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: srinivas.kandagatla, Maxime Coquelin, Alexandre Torgue,
linux-arm-kernel, linux-kernel, devicetree, linux-mmc,
linux-stm32, Ludovic Barre
In-Reply-To: <20200526155103.12514-1-ludovic.barre@st.com>
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
WARNING: CPU: 1 PID: 85 at kernel/dma/debug.c:1302 debug_dma_map_sg+0x2a0/0x3cc
mmci-pl18x 58005000.sdmmc: DMA-API: mapping sg segment longer than device claims to support [len=126976] [max=65536]
dma api debug checks and compares the segment size to
dma_get_max_seg_size (dev->dma_parms->max_segment_size),
the sdmmc variant has an internal DMA and should define
its max_segment_size constraint to avoid this warning.
This Patch defines the dev->dma_parms->max_segment_size
with the constraint already set for mmc core
(host->mmc->max_seg_size).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
---
drivers/mmc/host/mmci_stm32_sdmmc.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/mmci_stm32_sdmmc.c b/drivers/mmc/host/mmci_stm32_sdmmc.c
index 2965b1c062e1..51db30acf4dc 100644
--- a/drivers/mmc/host/mmci_stm32_sdmmc.c
+++ b/drivers/mmc/host/mmci_stm32_sdmmc.c
@@ -119,20 +119,19 @@ static void sdmmc_idma_unprep_data(struct mmci_host *host,
static int sdmmc_idma_setup(struct mmci_host *host)
{
struct sdmmc_idma *idma;
+ struct device *dev = mmc_dev(host->mmc);
- idma = devm_kzalloc(mmc_dev(host->mmc), sizeof(*idma), GFP_KERNEL);
+ idma = devm_kzalloc(dev, sizeof(*idma), GFP_KERNEL);
if (!idma)
return -ENOMEM;
host->dma_priv = idma;
if (host->variant->dma_lli) {
- idma->sg_cpu = dmam_alloc_coherent(mmc_dev(host->mmc),
- SDMMC_LLI_BUF_LEN,
+ idma->sg_cpu = dmam_alloc_coherent(dev, SDMMC_LLI_BUF_LEN,
&idma->sg_dma, GFP_KERNEL);
if (!idma->sg_cpu) {
- dev_err(mmc_dev(host->mmc),
- "Failed to alloc IDMA descriptor\n");
+ dev_err(dev, "Failed to alloc IDMA descriptor\n");
return -ENOMEM;
}
host->mmc->max_segs = SDMMC_LLI_BUF_LEN /
@@ -143,7 +142,7 @@ static int sdmmc_idma_setup(struct mmci_host *host)
host->mmc->max_seg_size = host->mmc->max_req_size;
}
- return 0;
+ return dma_set_max_seg_size(dev, host->mmc->max_seg_size);
}
static int sdmmc_idma_start(struct mmci_host *host, unsigned int *datactrl)
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 01/20] dt-bindings: arm: gic: Allow combining arm,gic-400 compatible strings
From: Rob Herring @ 2020-05-26 15:49 UTC (permalink / raw)
To: André Przywara
Cc: Geert Uytterhoeven, Liviu Dudau, Sudeep Holla, Lorenzo Pieralisi,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Linux ARM, Mark Rutland, Marc Zyngier
In-Reply-To: <6e2cc3e9-b14f-2b50-0390-addcc82389e0@arm.com>
On Tue, May 19, 2020 at 3:20 AM André Przywara <andre.przywara@arm.com> wrote:
>
> On 19/05/2020 08:39, Geert Uytterhoeven wrote:
>
> Hi Geert,
>
>
> > On Wed, May 13, 2020 at 12:31 PM Andre Przywara <andre.przywara@arm.com> wrote:
> >> The arm,gic-400 compatible is probably the best matching string for the
> >> GIC in most modern SoCs, but was only introduced later into the kernel.
> >> For historic reasons and to keep compatibility, some SoC DTs were thus
> >> using a combination of this name and one of the older strings, which
> >> currently the binding denies.
> >>
> >> Add a stanza to the DT binding to allow "arm,gic-400", followed by
> >> either "arm,cortex-a15-gic" or "arm,cortex-a7-gic". This fixes binding
> >> compliance for quite some SoC .dtsi files in the kernel tree.
> >>
> >> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> >
> > Thanks for your patch, I was just looking into this issue ;-)
> >
> >> --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> >> +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml
> >> @@ -39,6 +39,12 @@ properties:
> >> - qcom,msm-8660-qgic
> >> - qcom,msm-qgic2
> >>
> >> + - items:
> >> + - const: arm,gic-400
> >> + - enum:
> >> + - arm,cortex-a15-gic
> >> + - arm,cortex-a7-gic
> >> +
> >> - items:
> >> - const: arm,arm1176jzf-devchip-gic
> >> - const: arm,arm11mp-gic
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/r9a06g032.dtsi#n177
> > has them in the other order.
> >
> > What do you think is the preferred solution: reverting the order, or dropping
> > one or the other?
>
> Reverting the order would be the right thing. Theoretically this might
> change what the drivers match against, but there should be no difference
> between those strings anyway. And certainly Linux does not care which of
> the many strings it sees.
>
> The proper order is not really obvious here, but the cortex-a{15,7}-gic
> names serve as the missing "arm,gic-v2" generic fallback string here, I
> think just for historical reasons.
Really, they probably should have been mutually exclusive given an
implementation has one or the other. Since we have both, the order in
the schema is correct given gic-400 is a superset (multi-cluster) and
the compatible came later in time.
Rob
^ permalink raw reply
* [PATCH v3 1/7] dt-bindings: watchdog: Convert DW WDT binding to DT schema
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring
Cc: Serge Semin, Serge Semin, Rob Herring, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, linux-mips, linux-watchdog,
devicetree, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces the DW Watchdog
legacy bare text bindings with YAML file. As before the binding states
that the corresponding dts node is supposed to have a registers
range, a watchdog timer references clock source, optional reset line and
pre-timeout interrupt.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Discard BE copyright header.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property.
- Discard interrupts property from the required properties list.
- Remove a label definition from the binding example.
- Move the asynchronous APB3 clock support into a dedicated patch.
---
.../devicetree/bindings/watchdog/dw_wdt.txt | 24 ---------
.../bindings/watchdog/snps,dw-wdt.yaml | 50 +++++++++++++++++++
2 files changed, 50 insertions(+), 24 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/dw_wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/dw_wdt.txt b/Documentation/devicetree/bindings/watchdog/dw_wdt.txt
deleted file mode 100644
index eb0914420c7c..000000000000
--- a/Documentation/devicetree/bindings/watchdog/dw_wdt.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Synopsys Designware Watchdog Timer
-
-Required Properties:
-
-- compatible : Should contain "snps,dw-wdt"
-- reg : Base address and size of the watchdog timer registers.
-- clocks : phandle + clock-specifier for the clock that drives the
- watchdog timer.
-
-Optional Properties:
-
-- interrupts : The interrupt used for the watchdog timeout warning.
-- resets : phandle pointing to the system reset controller with
- line index for the watchdog.
-
-Example:
-
- watchdog0: wd@ffd02000 {
- compatible = "snps,dw-wdt";
- reg = <0xffd02000 0x1000>;
- interrupts = <0 171 4>;
- clocks = <&per_base_clk>;
- resets = <&rst WDT0_RESET>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
new file mode 100644
index 000000000000..4f6944756ab4
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/snps,dw-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys Designware Watchdog Timer
+
+allOf:
+ - $ref: "watchdog.yaml#"
+
+maintainers:
+ - Jamie Iles <jamie@jamieiles.com>
+
+properties:
+ compatible:
+ const: snps,dw-wdt
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ description: DW Watchdog pre-timeout interrupt
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: Watchdog timer reference clock
+
+ resets:
+ description: Phandle to the DW Watchdog reset lane
+ maxItems: 1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+examples:
+ - |
+ watchdog@ffd02000 {
+ compatible = "snps,dw-wdt";
+ reg = <0xffd02000 0x1000>;
+ interrupts = <0 171 4>;
+ clocks = <&per_base_clk>;
+ resets = <&wdt_rst>;
+ };
+...
--
2.26.2
^ permalink raw reply related
* [PATCH v3 0/7] watchdog: dw_wdt: Take Baikal-T1 DW WDT peculiarities into account
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Serge Semin, Serge Semin, Alexey Malahov, Maxim Kaurkin,
Pavel Parkhomenko, Ramil Zaripov, Ekaterina Skachko, Vadim Vlasov,
Alexey Kolotnikov, Thomas Bogendoerfer, Arnd Bergmann,
Rob Herring, linux-mips, linux-watchdog, devicetree, linux-kernel
Merge window is upon us. Please review/merge in/whatever the rest of the
patches.
There were a few features enabled at the time of the Baikal-T1 SoC DW WDT
IP synthesis, which weren't taken into account in the DW WDT driver available
in the kernel. First of all the SoC engineers synthesized the watchdog core
with WDT_USE_FIX_TOP set to false (don't really know why, but they did).
Due to this the timer reset values weren't fixed as the driver expected
but were initialized with a pre-defined values selected by the engineers.
Secondly the driver expected that the watchdog APB bus and the timer had
synchronous reference clocks, while Baikal-T1 SoC DW WDT was created with
asynchronous ones. So the driver should enable two clock devices: APB bus
clocks and a separate timer reference clock. Finally DW Watchdog Timer is
capable of generating a pre-timeout interrupt if corresponding config is
enabled. The problem was that the pre-timeout IRQ happens when the set
timeout elapses, while the actual WDT expiration and subsequent reboot take
place in the next timeout. This makes the pre-timeout functionality
implementation a bit tricky, since in this case we would have to find a
WDT timeout twice smaller the requested timeout. All of the changes described
above are provided by the patches in this patchset.
In addition traditionally we replaced the legacy plain text-based dt-binding
file with yaml-based one and added the controller registers dump DebugFS node
to ease the driver debug procedure.
This patchset is rebased and tested on the mainline Linux kernel 5.6-rc4:
base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
tag: v5.7-rc4
Changelog v2:
- Rearrange SoBs.
- Discard BE copyright header from the binding file.
- Replace "additionalProperties: false" with "unevaluatedProperties: false"
property in the binding.
- Move the APB3 clocks support declared in the dt binding file into a
dedicated patch.
- Move $ref to the root level of the "snps,watchdog-tops" property
so does the constraints.
- Make Pre-timeout IRQs support being optional.
- Add "ms" suffix to the methods returning msec and convert the methods
with no "ms" suffix to return a timeout in sec.
- Make sure minimum timeout is at least 1 sec.
- Refactor the timeouts calculation procedure to to retain the timeouts in
the ascending order.
- Make sure there is no integer overflow in milliseconds calculation. It
is saved in a dedicated uint field of the timeout structure.
- Discard timeout/pretimeout/ping/enable DebugFS nodes. Registers state
dump node is only left.
Link: https://lore.kernel.org/linux-watchdog/20200510105807.880-1-Sergey.Semin@baikalelectronics.ru/
Changelog v3:
- Add Rob's Reviewed-by tag to the DT-related patches.
- Remove items from the "snps,watchdog-tops" property and move the
minItems and maxItems constraints to the root level of it.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Maxim Kaurkin <Maxim.Kaurkin@baikalelectronics.ru>
Cc: Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Ekaterina Skachko <Ekaterina.Skachko@baikalelectronics.ru>
Cc: Vadim Vlasov <V.Vlasov@baikalelectronics.ru>
Cc: Alexey Kolotnikov <Alexey.Kolotnikov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Serge Semin (7):
dt-bindings: watchdog: Convert DW WDT binding to DT schema
dt-bindings: watchdog: dw-wdt: Support devices with asynch clocks
dt-bindings: watchdog: dw-wdt: Add watchdog TOPs array property
watchdog: dw_wdt: Support devices with non-fixed TOP values
watchdog: dw_wdt: Support devices with asynch clocks
watchdog: dw_wdt: Add pre-timeouts support
watchdog: dw_wdt: Add DebugFS files
.../devicetree/bindings/watchdog/dw_wdt.txt | 24 -
.../bindings/watchdog/snps,dw-wdt.yaml | 90 ++++
drivers/watchdog/dw_wdt.c | 437 ++++++++++++++++--
3 files changed, 494 insertions(+), 57 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/dw_wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
--
2.26.2
^ permalink raw reply
* [PATCH v3 4/7] watchdog: dw_wdt: Support devices with non-fixed TOP values
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree,
linux-watchdog, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
In case if the DW Watchdog IP core is synthesised with
WDT_USE_FIX_TOP == false, the TOP interval indexes make the device
to load a custom periods to the counter. These periods are hardwired
at the IP synthesis stage and can be within [2^8, 2^(WDT_CNT_WIDTH - 1)].
Alas their values can't be detected at runtime and must be somehow
supplied to the driver so one could properly determine the watchdog
timeout intervals. For this purpose we suggest to have a vendor-
specific dts property "snps,watchdog-tops" utilized, which would
provide an array of sixteen counter values. At device probe stage they
will be used to initialize the watchdog device timeouts determined
from the array values and current clocks source rate.
In order to have custom TOP values supported the driver must be
altered in the following way. First of all the fixed-top values
ready-to-use array must be determined for compatibility with currently
supported devices, which were synthesised with WDT_USE_FIX_TOP == true.
It will be used if either fixed TOP feature is detected being enabled or
no custom TOPs are fetched from the device dt node. Secondly at the probe
stage we must initialize an array of the watchdog timeouts corresponding
to the detected TOPs list and the reference clock rate. For generality the
procedure of initialization is designed in a way to support the TOPs array
with no limitations on the items order or value. Finally the watchdog
period search methods should be altered to support the new timeouts data
structure.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Add "ms" suffix to the methods returning msec and convert the methods
with no "ms" suffix to return a timeout in sec.
- Make sure minimum timeout is at least 1 sec.
- Refactor the timeouts calculation procedure to retain the timeouts in
the ascending order.
- Make sure there is no integer overflow in milliseconds calculation. It
is saved in a dedicated uint field of the timeout structure.
---
drivers/watchdog/dw_wdt.c | 191 +++++++++++++++++++++++++++++++++-----
1 file changed, 167 insertions(+), 24 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index fba21de2bbad..693c0d1fd796 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -13,6 +13,8 @@
*/
#include <linux/bitops.h>
+#include <linux/limits.h>
+#include <linux/kernel.h>
#include <linux/clk.h>
#include <linux/delay.h>
#include <linux/err.h>
@@ -34,21 +36,40 @@
#define WDOG_CURRENT_COUNT_REG_OFFSET 0x08
#define WDOG_COUNTER_RESTART_REG_OFFSET 0x0c
#define WDOG_COUNTER_RESTART_KICK_VALUE 0x76
+#define WDOG_COMP_PARAMS_1_REG_OFFSET 0xf4
+#define WDOG_COMP_PARAMS_1_USE_FIX_TOP BIT(6)
-/* The maximum TOP (timeout period) value that can be set in the watchdog. */
-#define DW_WDT_MAX_TOP 15
+/* There are sixteen TOPs (timeout periods) that can be set in the watchdog. */
+#define DW_WDT_NUM_TOPS 16
+#define DW_WDT_FIX_TOP(_idx) (1U << (16 + _idx))
#define DW_WDT_DEFAULT_SECONDS 30
+static const u32 dw_wdt_fix_tops[DW_WDT_NUM_TOPS] = {
+ DW_WDT_FIX_TOP(0), DW_WDT_FIX_TOP(1), DW_WDT_FIX_TOP(2),
+ DW_WDT_FIX_TOP(3), DW_WDT_FIX_TOP(4), DW_WDT_FIX_TOP(5),
+ DW_WDT_FIX_TOP(6), DW_WDT_FIX_TOP(7), DW_WDT_FIX_TOP(8),
+ DW_WDT_FIX_TOP(9), DW_WDT_FIX_TOP(10), DW_WDT_FIX_TOP(11),
+ DW_WDT_FIX_TOP(12), DW_WDT_FIX_TOP(13), DW_WDT_FIX_TOP(14),
+ DW_WDT_FIX_TOP(15)
+};
+
static bool nowayout = WATCHDOG_NOWAYOUT;
module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+struct dw_wdt_timeout {
+ u32 top_val;
+ unsigned int sec;
+ unsigned int msec;
+};
+
struct dw_wdt {
void __iomem *regs;
struct clk *clk;
unsigned long rate;
+ struct dw_wdt_timeout timeouts[DW_WDT_NUM_TOPS];
struct watchdog_device wdd;
struct reset_control *rst;
/* Save/restore */
@@ -64,20 +85,66 @@ static inline int dw_wdt_is_enabled(struct dw_wdt *dw_wdt)
WDOG_CONTROL_REG_WDT_EN_MASK;
}
-static inline int dw_wdt_top_in_seconds(struct dw_wdt *dw_wdt, unsigned top)
+static unsigned int dw_wdt_find_best_top(struct dw_wdt *dw_wdt,
+ unsigned int timeout, u32 *top_val)
{
+ int idx;
+
/*
- * There are 16 possible timeout values in 0..15 where the number of
- * cycles is 2 ^ (16 + i) and the watchdog counts down.
+ * Find a TOP with timeout greater or equal to the requested number.
+ * Note we'll select a TOP with maximum timeout if the requested
+ * timeout couldn't be reached.
*/
- return (1U << (16 + top)) / dw_wdt->rate;
+ for (idx = 0; idx < DW_WDT_NUM_TOPS; ++idx) {
+ if (dw_wdt->timeouts[idx].sec >= timeout)
+ break;
+ }
+
+ if (idx == DW_WDT_NUM_TOPS)
+ --idx;
+
+ *top_val = dw_wdt->timeouts[idx].top_val;
+
+ return dw_wdt->timeouts[idx].sec;
}
-static int dw_wdt_get_top(struct dw_wdt *dw_wdt)
+static unsigned int dw_wdt_get_min_timeout(struct dw_wdt *dw_wdt)
{
- int top = readl(dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET) & 0xF;
+ int idx;
+
+ /*
+ * We'll find a timeout greater or equal to one second anyway because
+ * the driver probe would have failed if there was none.
+ */
+ for (idx = 0; idx < DW_WDT_NUM_TOPS; ++idx) {
+ if (dw_wdt->timeouts[idx].sec)
+ break;
+ }
- return dw_wdt_top_in_seconds(dw_wdt, top);
+ return dw_wdt->timeouts[idx].sec;
+}
+
+static unsigned int dw_wdt_get_max_timeout_ms(struct dw_wdt *dw_wdt)
+{
+ struct dw_wdt_timeout *timeout = &dw_wdt->timeouts[DW_WDT_NUM_TOPS - 1];
+ u64 msec;
+
+ msec = (u64)timeout->sec * MSEC_PER_SEC + timeout->msec;
+
+ return msec < UINT_MAX ? msec : UINT_MAX;
+}
+
+static unsigned int dw_wdt_get_timeout(struct dw_wdt *dw_wdt)
+{
+ int top_val = readl(dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET) & 0xF;
+ int idx;
+
+ for (idx = 0; idx < DW_WDT_NUM_TOPS; ++idx) {
+ if (dw_wdt->timeouts[idx].top_val == top_val)
+ break;
+ }
+
+ return dw_wdt->timeouts[idx].sec;
}
static int dw_wdt_ping(struct watchdog_device *wdd)
@@ -93,17 +160,10 @@ static int dw_wdt_ping(struct watchdog_device *wdd)
static int dw_wdt_set_timeout(struct watchdog_device *wdd, unsigned int top_s)
{
struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
- int i, top_val = DW_WDT_MAX_TOP;
+ unsigned int timeout;
+ u32 top_val;
- /*
- * Iterate over the timeout values until we find the closest match. We
- * always look for >=.
- */
- for (i = 0; i <= DW_WDT_MAX_TOP; ++i)
- if (dw_wdt_top_in_seconds(dw_wdt, i) >= top_s) {
- top_val = i;
- break;
- }
+ timeout = dw_wdt_find_best_top(dw_wdt, top_s, &top_val);
/*
* Set the new value in the watchdog. Some versions of dw_wdt
@@ -120,7 +180,7 @@ static int dw_wdt_set_timeout(struct watchdog_device *wdd, unsigned int top_s)
* wdd->max_hw_heartbeat_ms
*/
if (top_s * 1000 <= wdd->max_hw_heartbeat_ms)
- wdd->timeout = dw_wdt_top_in_seconds(dw_wdt, top_val);
+ wdd->timeout = timeout;
else
wdd->timeout = top_s;
@@ -238,6 +298,86 @@ static int dw_wdt_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(dw_wdt_pm_ops, dw_wdt_suspend, dw_wdt_resume);
+/*
+ * In case if DW WDT IP core is synthesized with fixed TOP feature disabled the
+ * TOPs array can be arbitrary ordered with nearly any sixteen uint numbers
+ * depending on the system engineer imagination. The next method handles the
+ * passed TOPs array to pre-calculate the effective timeouts and to sort the
+ * TOP items out in the ascending order with respect to the timeouts.
+ */
+
+static void dw_wdt_handle_tops(struct dw_wdt *dw_wdt, const u32 *tops)
+{
+ struct dw_wdt_timeout tout, *dst;
+ int val, tidx;
+ u64 msec;
+
+ /*
+ * We walk over the passed TOPs array and calculate corresponding
+ * timeouts in seconds and milliseconds. The milliseconds granularity
+ * is needed to distinguish the TOPs with very close timeouts and to
+ * set the watchdog max heartbeat setting further.
+ */
+ for (val = 0; val < DW_WDT_NUM_TOPS; ++val) {
+ tout.top_val = val;
+ tout.sec = tops[val] / dw_wdt->rate;
+ msec = (u64)tops[val] * MSEC_PER_SEC;
+ do_div(msec, dw_wdt->rate);
+ tout.msec = msec - ((u64)tout.sec * MSEC_PER_SEC);
+
+ /*
+ * Find a suitable place for the current TOP in the timeouts
+ * array so that the list is remained in the ascending order.
+ */
+ for (tidx = 0; tidx < val; ++tidx) {
+ dst = &dw_wdt->timeouts[tidx];
+ if (tout.sec > dst->sec || (tout.sec == dst->sec &&
+ tout.msec >= dst->msec))
+ continue;
+ else
+ swap(*dst, tout);
+ }
+
+ dw_wdt->timeouts[val] = tout;
+ }
+}
+
+static int dw_wdt_init_timeouts(struct dw_wdt *dw_wdt, struct device *dev)
+{
+ u32 data, of_tops[DW_WDT_NUM_TOPS];
+ const u32 *tops;
+ int ret;
+
+ /*
+ * Retrieve custom or fixed counter values depending on the
+ * WDT_USE_FIX_TOP flag found in the component specific parameters
+ * #1 register.
+ */
+ data = readl(dw_wdt->regs + WDOG_COMP_PARAMS_1_REG_OFFSET);
+ if (data & WDOG_COMP_PARAMS_1_USE_FIX_TOP) {
+ tops = dw_wdt_fix_tops;
+ } else {
+ ret = of_property_read_variable_u32_array(dev_of_node(dev),
+ "snps,watchdog-tops", of_tops, DW_WDT_NUM_TOPS,
+ DW_WDT_NUM_TOPS);
+ if (ret < 0) {
+ dev_warn(dev, "No valid TOPs array specified\n");
+ tops = dw_wdt_fix_tops;
+ } else {
+ tops = of_tops;
+ }
+ }
+
+ /* Convert the specified TOPs into an array of watchdog timeouts. */
+ dw_wdt_handle_tops(dw_wdt, tops);
+ if (!dw_wdt->timeouts[DW_WDT_NUM_TOPS - 1].sec) {
+ dev_err(dev, "No any valid TOP detected\n");
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int dw_wdt_drv_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -275,12 +415,15 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
reset_control_deassert(dw_wdt->rst);
+ ret = dw_wdt_init_timeouts(dw_wdt, dev);
+ if (ret)
+ goto out_disable_clk;
+
wdd = &dw_wdt->wdd;
wdd->info = &dw_wdt_ident;
wdd->ops = &dw_wdt_ops;
- wdd->min_timeout = 1;
- wdd->max_hw_heartbeat_ms =
- dw_wdt_top_in_seconds(dw_wdt, DW_WDT_MAX_TOP) * 1000;
+ wdd->min_timeout = dw_wdt_get_min_timeout(dw_wdt);
+ wdd->max_hw_heartbeat_ms = dw_wdt_get_max_timeout_ms(dw_wdt);
wdd->parent = dev;
watchdog_set_drvdata(wdd, dw_wdt);
@@ -293,7 +436,7 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
* devicetree.
*/
if (dw_wdt_is_enabled(dw_wdt)) {
- wdd->timeout = dw_wdt_get_top(dw_wdt);
+ wdd->timeout = dw_wdt_get_timeout(dw_wdt);
set_bit(WDOG_HW_RUNNING, &wdd->status);
} else {
wdd->timeout = DW_WDT_DEFAULT_SECONDS;
--
2.26.2
^ permalink raw reply related
* [PATCH v3 5/7] watchdog: dw_wdt: Support devices with asynch clocks
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree,
linux-watchdog, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
DW Watchdog IP core can be synthesised with asynchronous timer/APB
clocks support (WDT_ASYNC_CLK_MODE_ENABLE == 1). In this case
separate clock signals are supposed to be used to feed watchdog timer
and APB interface of the device. Currently the driver supports
the synchronous mode only. Since there is no way to determine which
mode was actually activated for device from its registers, we have to
rely on the platform device configuration data. If optional "pclk"
clock source is supplied, we consider the device working in asynchronous
mode, otherwise the driver falls back to the synchronous configuration.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
---
drivers/watchdog/dw_wdt.c | 48 +++++++++++++++++++++++++++++++++++----
1 file changed, 43 insertions(+), 5 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 693c0d1fd796..efbc36872670 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -68,6 +68,7 @@ struct dw_wdt_timeout {
struct dw_wdt {
void __iomem *regs;
struct clk *clk;
+ struct clk *pclk;
unsigned long rate;
struct dw_wdt_timeout timeouts[DW_WDT_NUM_TOPS];
struct watchdog_device wdd;
@@ -274,6 +275,7 @@ static int dw_wdt_suspend(struct device *dev)
dw_wdt->control = readl(dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
dw_wdt->timeout = readl(dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+ clk_disable_unprepare(dw_wdt->pclk);
clk_disable_unprepare(dw_wdt->clk);
return 0;
@@ -287,6 +289,12 @@ static int dw_wdt_resume(struct device *dev)
if (err)
return err;
+ err = clk_prepare_enable(dw_wdt->pclk);
+ if (err) {
+ clk_disable_unprepare(dw_wdt->clk);
+ return err;
+ }
+
writel(dw_wdt->timeout, dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
writel(dw_wdt->control, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
@@ -393,9 +401,18 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
if (IS_ERR(dw_wdt->regs))
return PTR_ERR(dw_wdt->regs);
- dw_wdt->clk = devm_clk_get(dev, NULL);
- if (IS_ERR(dw_wdt->clk))
- return PTR_ERR(dw_wdt->clk);
+ /*
+ * Try to request the watchdog dedicated timer clock source. It must
+ * be supplied if asynchronous mode is enabled. Otherwise fallback
+ * to the common timer/bus clocks configuration, in which the very
+ * first found clock supply both timer and APB signals.
+ */
+ dw_wdt->clk = devm_clk_get(dev, "tclk");
+ if (IS_ERR(dw_wdt->clk)) {
+ dw_wdt->clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(dw_wdt->clk))
+ return PTR_ERR(dw_wdt->clk);
+ }
ret = clk_prepare_enable(dw_wdt->clk);
if (ret)
@@ -407,10 +424,27 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
goto out_disable_clk;
}
+ /*
+ * Request APB clock if device is configured with async clocks mode.
+ * In this case both tclk and pclk clocks are supposed to be specified.
+ * Alas we can't know for sure whether async mode was really activated,
+ * so the pclk phandle reference is left optional. If it couldn't be
+ * found we consider the device configured in synchronous clocks mode.
+ */
+ dw_wdt->pclk = devm_clk_get_optional(dev, "pclk");
+ if (IS_ERR(dw_wdt->pclk)) {
+ ret = PTR_ERR(dw_wdt->pclk);
+ goto out_disable_clk;
+ }
+
+ ret = clk_prepare_enable(dw_wdt->pclk);
+ if (ret)
+ goto out_disable_clk;
+
dw_wdt->rst = devm_reset_control_get_optional_shared(&pdev->dev, NULL);
if (IS_ERR(dw_wdt->rst)) {
ret = PTR_ERR(dw_wdt->rst);
- goto out_disable_clk;
+ goto out_disable_pclk;
}
reset_control_deassert(dw_wdt->rst);
@@ -449,10 +483,13 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
ret = watchdog_register_device(wdd);
if (ret)
- goto out_disable_clk;
+ goto out_disable_pclk;
return 0;
+out_disable_pclk:
+ clk_disable_unprepare(dw_wdt->pclk);
+
out_disable_clk:
clk_disable_unprepare(dw_wdt->clk);
return ret;
@@ -464,6 +501,7 @@ static int dw_wdt_drv_remove(struct platform_device *pdev)
watchdog_unregister_device(&dw_wdt->wdd);
reset_control_assert(dw_wdt->rst);
+ clk_disable_unprepare(dw_wdt->pclk);
clk_disable_unprepare(dw_wdt->clk);
return 0;
--
2.26.2
^ permalink raw reply related
* [PATCH v3 6/7] watchdog: dw_wdt: Add pre-timeouts support
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree,
linux-watchdog, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
DW Watchdog can rise an interrupt in case if IRQ request mode is enabled
and timer reaches the zero value. In this case the IRQ lane is left
pending until either the next watchdog kick event (watchdog restart) or
until the WDT_EOI register is read or the device/system reset. This
interface can be used to implement the pre-timeout functionality
optionally provided by the Linux kernel watchdog devices.
IRQ mode provides a two stages timeout interface. It means the IRQ is
raised when the counter reaches zero, while the system reset occurs only
after subsequent timeout if the timer restart is not performed. Due to
this peculiarity the pre-timeout value is actually set to the achieved
hardware timeout, while the real watchdog timeout is considered to be
twice as much of it. This applies a significant limitation on the
pre-timeout values, so current implementation supports either zero value,
which disables the pre-timeout events, or non-zero values, which imply
the pre-timeout to be at least half of the current watchdog timeout.
Note that we ask the interrupt controller to detect the rising-edge
pre-timeout interrupts to prevent the high-level-IRQs flood, since
if the pre-timeout happens, the IRQ lane will be left pending until
it's cleared by the timer restart.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Make the Pre-timeout IRQ being optionally supported.
---
drivers/watchdog/dw_wdt.c | 138 +++++++++++++++++++++++++++++++++++---
1 file changed, 130 insertions(+), 8 deletions(-)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index efbc36872670..3cd7c485cd70 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -22,6 +22,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/moduleparam.h>
+#include <linux/interrupt.h>
#include <linux/of.h>
#include <linux/pm.h>
#include <linux/platform_device.h>
@@ -36,6 +37,8 @@
#define WDOG_CURRENT_COUNT_REG_OFFSET 0x08
#define WDOG_COUNTER_RESTART_REG_OFFSET 0x0c
#define WDOG_COUNTER_RESTART_KICK_VALUE 0x76
+#define WDOG_INTERRUPT_STATUS_REG_OFFSET 0x10
+#define WDOG_INTERRUPT_CLEAR_REG_OFFSET 0x14
#define WDOG_COMP_PARAMS_1_REG_OFFSET 0xf4
#define WDOG_COMP_PARAMS_1_USE_FIX_TOP BIT(6)
@@ -59,6 +62,11 @@ module_param(nowayout, bool, 0);
MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started "
"(default=" __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+enum dw_wdt_rmod {
+ DW_WDT_RMOD_RESET = 1,
+ DW_WDT_RMOD_IRQ = 2
+};
+
struct dw_wdt_timeout {
u32 top_val;
unsigned int sec;
@@ -70,6 +78,7 @@ struct dw_wdt {
struct clk *clk;
struct clk *pclk;
unsigned long rate;
+ enum dw_wdt_rmod rmod;
struct dw_wdt_timeout timeouts[DW_WDT_NUM_TOPS];
struct watchdog_device wdd;
struct reset_control *rst;
@@ -86,6 +95,20 @@ static inline int dw_wdt_is_enabled(struct dw_wdt *dw_wdt)
WDOG_CONTROL_REG_WDT_EN_MASK;
}
+static void dw_wdt_update_mode(struct dw_wdt *dw_wdt, enum dw_wdt_rmod rmod)
+{
+ u32 val;
+
+ val = readl(dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
+ if (rmod == DW_WDT_RMOD_IRQ)
+ val |= WDOG_CONTROL_REG_RESP_MODE_MASK;
+ else
+ val &= ~WDOG_CONTROL_REG_RESP_MODE_MASK;
+ writel(val, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
+
+ dw_wdt->rmod = rmod;
+}
+
static unsigned int dw_wdt_find_best_top(struct dw_wdt *dw_wdt,
unsigned int timeout, u32 *top_val)
{
@@ -145,7 +168,11 @@ static unsigned int dw_wdt_get_timeout(struct dw_wdt *dw_wdt)
break;
}
- return dw_wdt->timeouts[idx].sec;
+ /*
+ * In IRQ mode due to the two stages counter, the actual timeout is
+ * twice greater than the TOP setting.
+ */
+ return dw_wdt->timeouts[idx].sec * dw_wdt->rmod;
}
static int dw_wdt_ping(struct watchdog_device *wdd)
@@ -164,7 +191,20 @@ static int dw_wdt_set_timeout(struct watchdog_device *wdd, unsigned int top_s)
unsigned int timeout;
u32 top_val;
- timeout = dw_wdt_find_best_top(dw_wdt, top_s, &top_val);
+ /*
+ * Note IRQ mode being enabled means having a non-zero pre-timeout
+ * setup. In this case we try to find a TOP as close to the half of the
+ * requested timeout as possible since DW Watchdog IRQ mode is designed
+ * in two stages way - first timeout rises the pre-timeout interrupt,
+ * second timeout performs the system reset. So basically the effective
+ * watchdog-caused reset happens after two watchdog TOPs elapsed.
+ */
+ timeout = dw_wdt_find_best_top(dw_wdt, DIV_ROUND_UP(top_s, dw_wdt->rmod),
+ &top_val);
+ if (dw_wdt->rmod == DW_WDT_RMOD_IRQ)
+ wdd->pretimeout = timeout;
+ else
+ wdd->pretimeout = 0;
/*
* Set the new value in the watchdog. Some versions of dw_wdt
@@ -175,25 +215,47 @@ static int dw_wdt_set_timeout(struct watchdog_device *wdd, unsigned int top_s)
writel(top_val | top_val << WDOG_TIMEOUT_RANGE_TOPINIT_SHIFT,
dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+ /* Kick new TOP value into the watchdog counter if activated. */
+ if (watchdog_active(wdd))
+ dw_wdt_ping(wdd);
+
/*
* In case users set bigger timeout value than HW can support,
* kernel(watchdog_dev.c) helps to feed watchdog before
* wdd->max_hw_heartbeat_ms
*/
if (top_s * 1000 <= wdd->max_hw_heartbeat_ms)
- wdd->timeout = timeout;
+ wdd->timeout = timeout * dw_wdt->rmod;
else
wdd->timeout = top_s;
return 0;
}
+static int dw_wdt_set_pretimeout(struct watchdog_device *wdd, unsigned int req)
+{
+ struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
+
+ /*
+ * We ignore actual value of the timeout passed from user-space
+ * using it as a flag whether the pretimeout functionality is intended
+ * to be activated.
+ */
+ dw_wdt_update_mode(dw_wdt, req ? DW_WDT_RMOD_IRQ : DW_WDT_RMOD_RESET);
+ dw_wdt_set_timeout(wdd, wdd->timeout);
+
+ return 0;
+}
+
static void dw_wdt_arm_system_reset(struct dw_wdt *dw_wdt)
{
u32 val = readl(dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
- /* Disable interrupt mode; always perform system reset. */
- val &= ~WDOG_CONTROL_REG_RESP_MODE_MASK;
+ /* Disable/enable interrupt mode depending on the RMOD flag. */
+ if (dw_wdt->rmod == DW_WDT_RMOD_IRQ)
+ val |= WDOG_CONTROL_REG_RESP_MODE_MASK;
+ else
+ val &= ~WDOG_CONTROL_REG_RESP_MODE_MASK;
/* Enable watchdog. */
val |= WDOG_CONTROL_REG_WDT_EN_MASK;
writel(val, dw_wdt->regs + WDOG_CONTROL_REG_OFFSET);
@@ -231,6 +293,7 @@ static int dw_wdt_restart(struct watchdog_device *wdd,
struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
writel(0, dw_wdt->regs + WDOG_TIMEOUT_RANGE_REG_OFFSET);
+ dw_wdt_update_mode(dw_wdt, DW_WDT_RMOD_RESET);
if (dw_wdt_is_enabled(dw_wdt))
writel(WDOG_COUNTER_RESTART_KICK_VALUE,
dw_wdt->regs + WDOG_COUNTER_RESTART_REG_OFFSET);
@@ -246,9 +309,19 @@ static int dw_wdt_restart(struct watchdog_device *wdd,
static unsigned int dw_wdt_get_timeleft(struct watchdog_device *wdd)
{
struct dw_wdt *dw_wdt = to_dw_wdt(wdd);
+ unsigned int sec;
+ u32 val;
+
+ val = readl(dw_wdt->regs + WDOG_CURRENT_COUNT_REG_OFFSET);
+ sec = val / dw_wdt->rate;
- return readl(dw_wdt->regs + WDOG_CURRENT_COUNT_REG_OFFSET) /
- dw_wdt->rate;
+ if (dw_wdt->rmod == DW_WDT_RMOD_IRQ) {
+ val = readl(dw_wdt->regs + WDOG_INTERRUPT_STATUS_REG_OFFSET);
+ if (!val)
+ sec += wdd->pretimeout;
+ }
+
+ return sec;
}
static const struct watchdog_info dw_wdt_ident = {
@@ -257,16 +330,41 @@ static const struct watchdog_info dw_wdt_ident = {
.identity = "Synopsys DesignWare Watchdog",
};
+static const struct watchdog_info dw_wdt_pt_ident = {
+ .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT |
+ WDIOF_PRETIMEOUT | WDIOF_MAGICCLOSE,
+ .identity = "Synopsys DesignWare Watchdog",
+};
+
static const struct watchdog_ops dw_wdt_ops = {
.owner = THIS_MODULE,
.start = dw_wdt_start,
.stop = dw_wdt_stop,
.ping = dw_wdt_ping,
.set_timeout = dw_wdt_set_timeout,
+ .set_pretimeout = dw_wdt_set_pretimeout,
.get_timeleft = dw_wdt_get_timeleft,
.restart = dw_wdt_restart,
};
+static irqreturn_t dw_wdt_irq(int irq, void *devid)
+{
+ struct dw_wdt *dw_wdt = devid;
+ u32 val;
+
+ /*
+ * We don't clear the IRQ status. It's supposed to be done by the
+ * following ping operations.
+ */
+ val = readl(dw_wdt->regs + WDOG_INTERRUPT_STATUS_REG_OFFSET);
+ if (!val)
+ return IRQ_NONE;
+
+ watchdog_notify_pretimeout(&dw_wdt->wdd);
+
+ return IRQ_HANDLED;
+}
+
#ifdef CONFIG_PM_SLEEP
static int dw_wdt_suspend(struct device *dev)
{
@@ -447,6 +545,31 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
goto out_disable_pclk;
}
+ /* Enable normal reset without pre-timeout by default. */
+ dw_wdt_update_mode(dw_wdt, DW_WDT_RMOD_RESET);
+
+ /*
+ * Pre-timeout IRQ is optional, since some hardware may lack support
+ * of it. Note we must request rising-edge IRQ, since the lane is left
+ * pending either until the next watchdog kick event or up to the
+ * system reset.
+ */
+ ret = platform_get_irq_optional(pdev, 0);
+ if (ret >= 0) {
+ ret = devm_request_irq(dev, ret, dw_wdt_irq,
+ IRQF_SHARED | IRQF_TRIGGER_RISING,
+ pdev->name, dw_wdt);
+ if (ret)
+ goto out_disable_pclk;
+
+ dw_wdt->wdd.info = &dw_wdt_pt_ident;
+ } else {
+ if (ret == -EPROBE_DEFER)
+ goto out_disable_pclk;
+
+ dw_wdt->wdd.info = &dw_wdt_ident;
+ }
+
reset_control_deassert(dw_wdt->rst);
ret = dw_wdt_init_timeouts(dw_wdt, dev);
@@ -454,7 +577,6 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
goto out_disable_clk;
wdd = &dw_wdt->wdd;
- wdd->info = &dw_wdt_ident;
wdd->ops = &dw_wdt_ops;
wdd->min_timeout = dw_wdt_get_min_timeout(dw_wdt);
wdd->max_hw_heartbeat_ms = dw_wdt_get_max_timeout_ms(dw_wdt);
--
2.26.2
^ permalink raw reply related
* [PATCH v3 7/7] watchdog: dw_wdt: Add DebugFS files
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Serge Semin, Serge Semin, Alexey Malahov, Thomas Bogendoerfer,
Arnd Bergmann, Rob Herring, linux-mips, devicetree,
linux-watchdog, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
For the sake of the easier device-driver debug procedure, we added a
DebugFS file with the controller registers state. It's available only if
kernel is configured with DebugFS support.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-mips@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Discard timeout/pretimeout/ping/enable DebugFS nodes. Registers state
dump node is only left.
---
drivers/watchdog/dw_wdt.c | 68 +++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/drivers/watchdog/dw_wdt.c b/drivers/watchdog/dw_wdt.c
index 3cd7c485cd70..012681baaa6d 100644
--- a/drivers/watchdog/dw_wdt.c
+++ b/drivers/watchdog/dw_wdt.c
@@ -28,6 +28,7 @@
#include <linux/platform_device.h>
#include <linux/reset.h>
#include <linux/watchdog.h>
+#include <linux/debugfs.h>
#define WDOG_CONTROL_REG_OFFSET 0x00
#define WDOG_CONTROL_REG_WDT_EN_MASK 0x01
@@ -39,8 +40,14 @@
#define WDOG_COUNTER_RESTART_KICK_VALUE 0x76
#define WDOG_INTERRUPT_STATUS_REG_OFFSET 0x10
#define WDOG_INTERRUPT_CLEAR_REG_OFFSET 0x14
+#define WDOG_COMP_PARAMS_5_REG_OFFSET 0xe4
+#define WDOG_COMP_PARAMS_4_REG_OFFSET 0xe8
+#define WDOG_COMP_PARAMS_3_REG_OFFSET 0xec
+#define WDOG_COMP_PARAMS_2_REG_OFFSET 0xf0
#define WDOG_COMP_PARAMS_1_REG_OFFSET 0xf4
#define WDOG_COMP_PARAMS_1_USE_FIX_TOP BIT(6)
+#define WDOG_COMP_VERSION_REG_OFFSET 0xf8
+#define WDOG_COMP_TYPE_REG_OFFSET 0xfc
/* There are sixteen TOPs (timeout periods) that can be set in the watchdog. */
#define DW_WDT_NUM_TOPS 16
@@ -85,6 +92,10 @@ struct dw_wdt {
/* Save/restore */
u32 control;
u32 timeout;
+
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *dbgfs_dir;
+#endif
};
#define to_dw_wdt(wdd) container_of(wdd, struct dw_wdt, wdd)
@@ -484,6 +495,59 @@ static int dw_wdt_init_timeouts(struct dw_wdt *dw_wdt, struct device *dev)
return 0;
}
+#ifdef CONFIG_DEBUG_FS
+
+#define DW_WDT_DBGFS_REG(_name, _off) \
+{ \
+ .name = _name, \
+ .offset = _off \
+}
+
+static const struct debugfs_reg32 dw_wdt_dbgfs_regs[] = {
+ DW_WDT_DBGFS_REG("cr", WDOG_CONTROL_REG_OFFSET),
+ DW_WDT_DBGFS_REG("torr", WDOG_TIMEOUT_RANGE_REG_OFFSET),
+ DW_WDT_DBGFS_REG("ccvr", WDOG_CURRENT_COUNT_REG_OFFSET),
+ DW_WDT_DBGFS_REG("crr", WDOG_COUNTER_RESTART_REG_OFFSET),
+ DW_WDT_DBGFS_REG("stat", WDOG_INTERRUPT_STATUS_REG_OFFSET),
+ DW_WDT_DBGFS_REG("param5", WDOG_COMP_PARAMS_5_REG_OFFSET),
+ DW_WDT_DBGFS_REG("param4", WDOG_COMP_PARAMS_4_REG_OFFSET),
+ DW_WDT_DBGFS_REG("param3", WDOG_COMP_PARAMS_3_REG_OFFSET),
+ DW_WDT_DBGFS_REG("param2", WDOG_COMP_PARAMS_2_REG_OFFSET),
+ DW_WDT_DBGFS_REG("param1", WDOG_COMP_PARAMS_1_REG_OFFSET),
+ DW_WDT_DBGFS_REG("version", WDOG_COMP_VERSION_REG_OFFSET),
+ DW_WDT_DBGFS_REG("type", WDOG_COMP_TYPE_REG_OFFSET)
+};
+
+static void dw_wdt_dbgfs_init(struct dw_wdt *dw_wdt)
+{
+ struct device *dev = dw_wdt->wdd.parent;
+ struct debugfs_regset32 *regset;
+
+ regset = devm_kzalloc(dev, sizeof(*regset), GFP_KERNEL);
+ if (!regset)
+ return;
+
+ regset->regs = dw_wdt_dbgfs_regs;
+ regset->nregs = ARRAY_SIZE(dw_wdt_dbgfs_regs);
+ regset->base = dw_wdt->regs;
+
+ dw_wdt->dbgfs_dir = debugfs_create_dir(dev_name(dev), NULL);
+
+ debugfs_create_regset32("registers", 0444, dw_wdt->dbgfs_dir, regset);
+}
+
+static void dw_wdt_dbgfs_clear(struct dw_wdt *dw_wdt)
+{
+ debugfs_remove_recursive(dw_wdt->dbgfs_dir);
+}
+
+#else /* !CONFIG_DEBUG_FS */
+
+static void dw_wdt_dbgfs_init(struct dw_wdt *dw_wdt) {}
+static void dw_wdt_dbgfs_clear(struct dw_wdt *dw_wdt) {}
+
+#endif /* !CONFIG_DEBUG_FS */
+
static int dw_wdt_drv_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -607,6 +671,8 @@ static int dw_wdt_drv_probe(struct platform_device *pdev)
if (ret)
goto out_disable_pclk;
+ dw_wdt_dbgfs_init(dw_wdt);
+
return 0;
out_disable_pclk:
@@ -621,6 +687,8 @@ static int dw_wdt_drv_remove(struct platform_device *pdev)
{
struct dw_wdt *dw_wdt = platform_get_drvdata(pdev);
+ dw_wdt_dbgfs_clear(dw_wdt);
+
watchdog_unregister_device(&dw_wdt->wdd);
reset_control_assert(dw_wdt->rst);
clk_disable_unprepare(dw_wdt->pclk);
--
2.26.2
^ permalink raw reply related
* [PATCH v3 3/7] dt-bindings: watchdog: dw-wdt: Add watchdog TOPs array property
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring
Cc: Serge Semin, Serge Semin, Rob Herring, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, linux-mips, linux-watchdog,
devicetree, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
In case if DW Watchdog IP core is built with WDT_USE_FIX_TOP == false,
a custom timeout periods are used to preset the timer counter. In
this case that periods should be specified in a new "snps,watchdog-tops"
property of the DW watchdog dts node.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- Rearrange SoBs.
- Move $ref to the root level of the "snps,watchdog-tops" property
so does the constraints.
- Add default TOP values array.
- Discard the label definition from the new bindings example.
Changelog v3:
- Remove items property and move the minItems and maxItems constraints to
the root level of the snps,watchdog-tops property.
---
.../bindings/watchdog/snps,dw-wdt.yaml | 32 +++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index 5bf6dc6377f3..d9fc7bb851b1 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -39,6 +39,23 @@ properties:
description: Phandle to the DW Watchdog reset lane
maxItems: 1
+ snps,watchdog-tops:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: |
+ DW APB Watchdog custom timer intervals - Timeout Period ranges (TOPs).
+ Each TOP is a number loaded into the watchdog counter at the moment of
+ the timer restart. The counter decrementing happens each tick of the
+ reference clock. Therefore the TOPs array is equivalent to an array of
+ the timer expiration intervals supported by the DW APB Watchdog. Note
+ DW APB Watchdog IP-core might be synthesized with fixed TOP values,
+ in which case this property is unnecessary with default TOPs utilized.
+ default: [0x0001000 0x0002000 0x0004000 0x0008000
+ 0x0010000 0x0020000 0x0040000 0x0080000
+ 0x0100000 0x0200000 0x0400000 0x0800000
+ 0x1000000 0x2000000 0x4000000 0x8000000]
+ minItems: 16
+ maxItems: 16
+
unevaluatedProperties: false
required:
@@ -55,4 +72,19 @@ examples:
clocks = <&per_base_clk>;
resets = <&wdt_rst>;
};
+
+ - |
+ watchdog@ffd02000 {
+ compatible = "snps,dw-wdt";
+ reg = <0xffd02000 0x1000>;
+ interrupts = <0 171 4>;
+ clocks = <&per_base_clk>;
+ clock-names = "tclk";
+ snps,watchdog-tops = <0x000000FF 0x000001FF 0x000003FF
+ 0x000007FF 0x0000FFFF 0x0001FFFF
+ 0x0003FFFF 0x0007FFFF 0x000FFFFF
+ 0x001FFFFF 0x003FFFFF 0x007FFFFF
+ 0x00FFFFFF 0x01FFFFFF 0x03FFFFFF
+ 0x07FFFFFF>;
+ };
...
--
2.26.2
^ permalink raw reply related
* [PATCH v3 2/7] dt-bindings: watchdog: dw-wdt: Support devices with asynch clocks
From: Serge Semin @ 2020-05-26 15:41 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck, Rob Herring
Cc: Serge Semin, Serge Semin, Rob Herring, Alexey Malahov,
Thomas Bogendoerfer, Arnd Bergmann, linux-mips, linux-watchdog,
devicetree, linux-kernel
In-Reply-To: <20200526154123.24402-1-Sergey.Semin@baikalelectronics.ru>
DW Watchdog IP core can be synthesised with asynchronous timer/APB
clocks support (WDT_ASYNC_CLK_MODE_ENABLE == 1). In this case
separate clock signals are supposed to be used to feed watchdog timer
and APB interface of the device. Let's update the DW Watchdog DT node
schema so it would support the optional APB3 bus clock specified along
with the mandatory watchdog timer reference clock.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@vger.kernel.org
---
Changelog v2:
- It's a new patch unpinned from the previous one.
---
.../devicetree/bindings/watchdog/snps,dw-wdt.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
index 4f6944756ab4..5bf6dc6377f3 100644
--- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
+++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml
@@ -24,8 +24,16 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
items:
- description: Watchdog timer reference clock
+ - description: APB3 interface clock
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: tclk
+ - const: pclk
resets:
description: Phandle to the DW Watchdog reset lane
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v8 3/3] PM / AVS: SVS: Introduce SVS engine
From: Matthias Brugger @ 2020-05-26 15:29 UTC (permalink / raw)
To: Roger Lu
Cc: Enric Balletbo Serra, Kevin Hilman, Rob Herring, Nicolas Boichat,
Stephen Boyd, Mark Rutland, Nishanth Menon, Angus Lin,
devicetree@vger.kernel.org, Linux PM list, linux-kernel,
Xiaoqing Liu, YT Lee, Fan Chen,
moderated list:ARM/Mediatek SoC support, HenryC Chen,
Charles Yang, Linux ARM
In-Reply-To: <1590484328.4392.44.camel@mtksdaap41>
On 26/05/2020 11:12, Roger Lu wrote:
> Hi Matthias,
>
> Thanks for the feedback.
>
> On Fri, 2020-05-22 at 17:38 +0200, Matthias Brugger wrote:
>>
>> On 22/05/2020 11:40, Roger Lu wrote:
>>>
>>> Hi Enric,
>>>
>>> On Tue, 2020-05-19 at 17:30 +0200, Enric Balletbo Serra wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for your patch. I have the feeling that this driver is
>>>> complex and difficult to follow and I am wondering if it wouldn't be
>>>> better if you can send a version that simply adds basic functionality
>>>> for now. Some comments below.
>>>
>>> Thanks for the advices. I'll submit SVS v9 with basic functionality
>>> patch + step by step functionalities' patches.
>>>
>>>>
>>>> Missatge de Roger Lu <roger.lu@mediatek.com> del dia dl., 18 de maig
>>>> 2020 a les 11:25:
>>>>>
>>>>> The SVS (Smart Voltage Scaling) engine is a piece
>>>>> of hardware which is used to calculate optimized
>>>>> voltage values of several power domains,
>>>>> e.g. CPU/GPU/CCI, according to chip process corner,
>>>>> temperatures, and other factors. Then DVFS driver
>>>>> could apply those optimized voltage values to reduce
>>>>> power consumption.
>>>>>
>>>>> Signed-off-by: Roger Lu <roger.lu@mediatek.com>
>>>>> ---
>>>>> drivers/power/avs/Kconfig | 10 +
>>>>> drivers/power/avs/Makefile | 1 +
>>>>> drivers/power/avs/mtk_svs.c | 2119 +++++++++++++++++++++++++++++++++
>>>>> include/linux/power/mtk_svs.h | 23 +
>>>>> 4 files changed, 2153 insertions(+)
>>>>> create mode 100644 drivers/power/avs/mtk_svs.c
>>>>> create mode 100644 include/linux/power/mtk_svs.h
>>>>>
>>>>> diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig
>>>>> index cdb4237bfd02..67089ac6040e 100644
>>>>> --- a/drivers/power/avs/Kconfig
>>>>> +++ b/drivers/power/avs/Kconfig
>>>>> @@ -35,3 +35,13 @@ config ROCKCHIP_IODOMAIN
>>>>> Say y here to enable support io domains on Rockchip SoCs. It is
>>>>> necessary for the io domain setting of the SoC to match the
>>>>> voltage supplied by the regulators.
>>>>> +
>>>>> +config MTK_SVS
>>>>> + bool "MediaTek Smart Voltage Scaling(SVS)"
>>>>
>>>> Can't be this a module? Why? In such case, you should use tristate option
>>>
>>> Generally, MTK_SVS is needed in MTK SoC(mt81xx) products. So, we don't provide
>>> module option in config. If, somehow, SVS isn't needed, we suggest
>>> CONFIG_MTK_SVS=n to be set.
>>>
>>
>> The question here is if it needs to be probed before we probe the modules. If
>> not, we should add a Kconfig option for MT81xx SoCs to select MTK_SVS.
>
> Excuse me to make you confuse. MT81xx SoCs is the subset MTK ICs that
> will use CONFIG_MTK_SVS. In other words, CONFIG_MTK_SVS will be used
> with other MTK ICs as well. So, MTK_SVS is the general naming for MTK IC
> to enable SVS power feature. Anyway, back to Enric's question, I'll make
> MTK_SVS become a tristate feature in the next patch. Thanks.
>
>>
[...]
>>>>> +
>>>>> +static const u32 svs_regs_v2[] = {
>>>>
>>>> Is this SoC specific or shared between SoCs?
>>>
>>> Shared between SoCs. Some SVS in MTK SoCs use v2 register map.
>>>
>>
>> And which silicon uses v1 then? Is v2 a MediaTek internal naming you want to keep?
>
> 1. MT8173 IC uses v1 register map.
> 2. Yes, I'll keep v2 postfix.
>
Sounds good, thanks for clarification.
Regards,
Matthias
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: sram: add documentation for reserved-only flag
From: Mian Yousaf Kaukab @ 2020-05-26 15:28 UTC (permalink / raw)
To: Thierry Reding
Cc: Rob Herring, Stephen Warren, robin.murphy, devicetree, talho,
jonathanh, linux-tegra, linux-kernel, linux-arm-kernel, afaerber,
arnd, gregkh
In-Reply-To: <20200520085558.GB2136208@ulmo>
On Wed, May 20, 2020 at 10:55:58AM +0200, Thierry Reding wrote:
> On Tue, May 19, 2020 at 05:03:26PM -0600, Rob Herring wrote:
> > On Tue, May 19, 2020 at 10:16:43AM -0600, Stephen Warren wrote:
> > > On 5/13/20 4:41 AM, Mian Yousaf Kaukab wrote:
> > > > On Tue, May 12, 2020 at 01:45:28PM -0600, Stephen Warren wrote:
> > > >> On 5/12/20 8:48 AM, Mian Yousaf Kaukab wrote:
> > > >>> Add documentation for the new optional flag added for SRAM driver.
> > > >>
> > > >>> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> > > >>
> > > >>> + reserved-only:
> > > >>> + description:
> > > >>> + The flag indicating, that only SRAM reserved regions have to be remapped.
> > > >>> + remapping type is selected depending upon no-memory-wc as usual.
> > > >>> + type: boolean
> > > >>
> > > >> This feels a bit like a SW flag rather than a HW description, so I'm not
> > > >> sure it's appropriate to put it into DT.
> > > >
> > > > Reserved regions themselves are software descriptions, no? Then we have 'pool'
> > > > flag which is again a software flag and so on. This flag falls into same
> > > > category and nothing out of ordinary.
> > >
> > > I suppose that's true to some extent. This is indeed a description of
> > > the system environment presented to the SW that consumes the DT, which
> > > is a bit more than pure HW description but still a description of
> > > something imposed externally rather than describing something that's up
> > > to the discretion of the consuming SW. So, go ahead.
> > >
> > > >> Are there any cases where the SW should map all of the SRAM, i.e. where
> > > >> we wouldn't expect to set reserved-only? [...]
> > > >
> > > > Yes, here are a few examples:
> > > > arch/arm/boot/dts/aspeed-g*.dtsi
> > > > arch/arm/boot/dts/at91*.dtsi
> > > > arch/arm/boot/dts/bcm7445.dtsi
> > > > Then arch/arm/boot/dts/dra7.dtsi is an example where we should map everything
> > > > except the reserved region.
> > > >
> > > >> [...] I'd expect reserved-only to be
> > > >> the default, and perhaps only, mode of operation for the SRAM driver.
> > > >
> > > > It will break compatibility with existing dtbs.
> > > >
> > > >> If we can't do that because some SW currently expects to be able to map
> > > >> arbitrary portions of the SRAM, shouldn't that SW be fixed to tell the
> > > >> SRAM driver which parts it's using, hence still allowing the driver to
> > > >> only map in-use portions?
> > > >
> > > > User doesn’t need sram driver in that case. It can use genalloc api directly.
> > >
> > > This sounds a bit odd. Without a driver for the reserved region, nothing
> > > should be touching it, since otherwise there's no code that owns an
> > > manages the region. If any code needs to consume the region, it should
> > > obtain info about the region from some form of provider code that can
> > > handle both the allocation and mapping. Anything else sounds like some
> > > consumer code directly making use of DT nodes it doesn't own. But since
> > > I'm not familiar enough with the SRAM driver and genalloc code that you
> > > mention to fully understand the allocation paths I guess I won't object
> > > for now, although it does still sound fishy.
> >
> > I'm fine with the concept, but I don't think a single flag is adequate.
> > If there are reserved regions within the SRAM, then define child nodes
> > to mark those regions reserved. I don't think you need a new flag. Just
> > a 'reg' property and nothing else.
>
> It sounds to me like there are two different interpretations of SRAM and
> reserved regions. On one hand, as you suggest, we have one SRAM that's
> made available as genalloc pool and then individual regions can be
> marked as reserved so that they aren't added to that pool.
>
> At the same time, each reserved region is also exposed as a separate
> pool and that's in fact used by many consumers as a way of getting a
> specific chunk of the SRAM for their own use (via phandle to the region
> from the consumer's device tree node).
>
> In addition to that, the reserved region code doesn't actually fully do
> its job because while the reserved region isn't actually added to the
> "top-level" SRAM pool, the memory is still mapped. At the same time this
> is something that we actually want because, like I mentioned, some of
> the consumers do want to get at their SRAM chunks via references to the
> partitions.
>
> The problem that this patch series is really trying to solve is another
> still: the complete SRAM is always mapped to kernel memory, irrespective
> of whether any regions are marked reserved or not and that can cause
> speculative accesses to memory outside of the defined regions.
>
> Stephen's suggestion is to default to only mapping memory for which a
> partition has been defined in the SRAM and assuming that all SRAM
> outside of those partitions is off limits. I think that's a sensible
> default and it's unambiguous.
>
> But as Yousaf points out that would break compatibility with existing
> device trees. Depending on how you interpret the bindings one could
> argue that those device trees are buggy and should have partitions
> defined (in the cases I've looked at they end up using a fixed region
> anyway, so that could've just been made explicit in the device tree).
>
> However, it also looks like all of the users that rely on the original
> behaviour where they can just access the full pool are those that don't
> define any reserved regions, whereas all users that do reserve regions
> will actually use those reserved regions.
>
> So I think we can make use of this by differentiating in the driver
> between SRAM nodes with or without children and change the behaviour
> accordingly. I think that has the big advantage that it makes things
> work as (I think) most people would expect and doesn't further
> complicate the binding with extra flags.
I tend to agree on mapping partitions only if they exist. So far I could
only find one exception. It is arch/arm/boot/dts/armada-370.dtsi which is
using the top level pool as well as a partition to reserve 32 bytes at the
bottom of sram. This can be fixed along with the sram driver change, by
adding another partition for the rest of the sram and using its handle in
the crypto@90000 instead of top-level sram node handle. Do you see anymore
exceptions where both top level pool and the partitions both are being used?
Then on the backward compatibility topic, another issue is that boot code
could add sram nodes dynamically. For example arch/arm/mach-k3/common.c in
u-boot does it. This particular case will not break after the suggested change
because it is not adding any partitions. However, there could be other
boot-loaders which are not this lucky.
>
> Thierry
/Yousaf
^ permalink raw reply
* Re: [PATCHv2 1/2] spi: dw: add reset control
From: Andy Shevchenko @ 2020-05-26 15:21 UTC (permalink / raw)
To: Dinh Nguyen
Cc: linux-kernel, devicetree, broonie, robh+dt, linux-spi,
Sergey.Semin, fancer.lancer, lars.povlsen, Liang Jin J
In-Reply-To: <20200526151218.6186-1-dinguyen@kernel.org>
On Tue, May 26, 2020 at 10:12:17AM -0500, Dinh Nguyen wrote:
> Add mechanism to get the reset control and deassert it in order to bring
> the IP out of reset.
...
> struct clk *clk;
> struct clk *pclk;
> void *priv;
> + struct reset_control *rstc;
I think either you make it one space or you align all the rest members
accordingly. I would rather go with former.
...
> + /* find an optional reset controller */
> + dwsmmio->rstc = devm_reset_control_get_optional_exclusive(&pdev->dev, "spi");
> + if (IS_ERR(dwsmmio->rstc)) {
> + if (PTR_ERR(dwsmmio->rstc) == -EPROBE_DEFER)
> + return PTR_ERR(dwsmmio->rstc);
If it's other type of errors when reset control, we ignore them...
Why?!
> + }
--
With Best Regards,
Andy Shevchenko
^ 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