| Message ID | 20210422090843.4614-1-quan@os.amperecomputing.com |
|---|---|
| Headers | show |
| Series | Add Ampere's Altra SMPro hwmon driver | expand |
On Thu, Apr 22, 2021 at 04:08:42PM +0700, Quan Nguyen wrote: > This commit adds support for Ampere SMpro hwmon driver. This driver > supports accessing various CPU sensors provided by the SMpro co-processor > including temperature, power, voltages, and current. > > Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> For my reference: Reviewed-by: Guenter Roeck <linux@roeck-us.net> We'll need to wait for dt approval. Thanks, Guenter > --- > Changes in v4: > + Returned regmap_read() error code [Guenter] > > Changes in v3: > + Handled negative temperature value [Guenter] > + Returned -ENODEV if Manufacturer ID is wrong [Guenter] > + Refactored smpro_read_string() and smpro_temp_read() [Guenter] > + Removed smpro_write() function [Guenter] > + Added minor refactor changes [Quan] > > Changes in v2: > + Removed "virtual" sensors [Guenter] > + Reported SOC_TDP as "Socket TDP" using max attributes [Guenter] > + Corrected return error code when host is turn off [Guenter] > + Reported MEM HOT Threshold for all DIMMs as temp*_crit [Guenter] > + Removed license info as SPDX-License-Identifier existed [Guenter] > + Added is_visible() support [Guenter] > + Used HWMON_CHANNEL_INFO() macro and LABEL attributes [Guenter] > + Made is_valid_id() return boolean [Guenter] > + Returned -EPROBE_DEFER when smpro reg inaccessible [Guenter] > + Removed unnecessary error message when dev register fail [Guenter] > + Removed Socket TDP sensor [Quan] > + Included sensor type and channel in labels [Quan] > + Refactorized code to fix checkpatch.pl --strict complaint [Quan] > > drivers/hwmon/Kconfig | 8 + > drivers/hwmon/Makefile | 1 + > drivers/hwmon/smpro-hwmon.c | 491 ++++++++++++++++++++++++++++++++++++ > 3 files changed, 500 insertions(+) > create mode 100644 drivers/hwmon/smpro-hwmon.c > > diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig > index 0ddc974b102e..ba4b5a911baf 100644 > --- a/drivers/hwmon/Kconfig > +++ b/drivers/hwmon/Kconfig > @@ -67,6 +67,14 @@ config SENSORS_ABITUGURU3 > This driver can also be built as a module. If so, the module > will be called abituguru3. > > +config SENSORS_SMPRO > + tristate "Ampere's Altra SMpro hardware monitoring driver" > + depends on MFD_SMPRO > + help > + If you say yes here you get support for the thermal, voltage, > + current and power sensors of Ampere's Altra processor family SoC > + with SMpro co-processor. > + > config SENSORS_AD7314 > tristate "Analog Devices AD7314 and compatibles" > depends on SPI > diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile > index 59e78bc212cf..b25391f9c651 100644 > --- a/drivers/hwmon/Makefile > +++ b/drivers/hwmon/Makefile > @@ -174,6 +174,7 @@ obj-$(CONFIG_SENSORS_SHT3x) += sht3x.o > obj-$(CONFIG_SENSORS_SHTC1) += shtc1.o > obj-$(CONFIG_SENSORS_SIS5595) += sis5595.o > obj-$(CONFIG_SENSORS_SMM665) += smm665.o > +obj-$(CONFIG_SENSORS_SMPRO) += smpro-hwmon.o > obj-$(CONFIG_SENSORS_SMSC47B397)+= smsc47b397.o > obj-$(CONFIG_SENSORS_SMSC47M1) += smsc47m1.o > obj-$(CONFIG_SENSORS_SMSC47M192)+= smsc47m192.o > diff --git a/drivers/hwmon/smpro-hwmon.c b/drivers/hwmon/smpro-hwmon.c > new file mode 100644 > index 000000000000..1be3d98e73c7 > --- /dev/null > +++ b/drivers/hwmon/smpro-hwmon.c > @@ -0,0 +1,491 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Ampere Computing SoC's SMPro Hardware Monitoring Driver > + * > + * Copyright (c) 2021, Ampere Computing LLC > + */ > +#include <linux/bitfield.h> > +#include <linux/bitops.h> > +#include <linux/hwmon.h> > +#include <linux/hwmon-sysfs.h> > +#include <linux/kernel.h> > +#include <linux/mod_devicetable.h> > +#include <linux/module.h> > +#include <linux/platform_device.h> > +#include <linux/property.h> > +#include <linux/regmap.h> > + > +/* Identification Registers */ > +#define MANUFACTURER_ID_REG 0x02 > +#define AMPERE_MANUFACTURER_ID 0xCD3A > + > +/* Logical Power Sensor Registers */ > +#define SOC_TEMP 0x00 > +#define SOC_VRD_TEMP 0x01 > +#define DIMM_VRD_TEMP 0x02 > +#define CORE_VRD_TEMP 0x03 > +#define CH0_DIMM_TEMP 0x04 > +#define CH1_DIMM_TEMP 0x05 > +#define CH2_DIMM_TEMP 0x06 > +#define CH3_DIMM_TEMP 0x07 > +#define CH4_DIMM_TEMP 0x08 > +#define CH5_DIMM_TEMP 0x09 > +#define CH6_DIMM_TEMP 0x0A > +#define CH7_DIMM_TEMP 0x0B > +#define RCA_VRD_TEMP 0x0C > + > +#define CORE_VRD_PWR 0x10 > +#define SOC_PWR 0x11 > +#define DIMM_VRD1_PWR 0x12 > +#define DIMM_VRD2_PWR 0x13 > +#define CORE_VRD_PWR_MW 0x16 > +#define SOC_PWR_MW 0x17 > +#define DIMM_VRD1_PWR_MW 0x18 > +#define DIMM_VRD2_PWR_MW 0x19 > +#define RCA_VRD_PWR 0x1A > +#define RCA_VRD_PWR_MW 0x1B > + > +#define MEM_HOT_THRESHOLD 0x22 > +#define SOC_VR_HOT_THRESHOLD 0x23 > +#define CORE_VRD_VOLT 0x24 > +#define SOC_VRD_VOLT 0x25 > +#define DIMM_VRD1_VOLT 0x26 > +#define DIMM_VRD2_VOLT 0x27 > +#define RCA_VRD_VOLT 0x28 > + > +#define CORE_VRD_CURR 0x29 > +#define SOC_VRD_CURR 0x2A > +#define DIMM_VRD1_CURR 0x2B > +#define DIMM_VRD2_CURR 0x2C > +#define RCA_VRD_CURR 0x2D > + > +struct smpro_hwmon { > + struct regmap *regmap; > + u32 offset; > +}; > + > +struct smpro_sensor { > + const u8 reg; > + const u8 reg_ext; > + const char *label; > +}; > + > +static const struct smpro_sensor temperature[] = { > + { > + .reg = SOC_TEMP, > + .label = "temp1 SoC" > + }, > + { > + .reg = SOC_VRD_TEMP, > + .reg_ext = SOC_VR_HOT_THRESHOLD, > + .label = "temp2 SoC VRD" > + }, > + { > + .reg = DIMM_VRD_TEMP, > + .label = "temp3 DIMM VRD" > + }, > + { > + .reg = CORE_VRD_TEMP, > + .label = "temp4 CORE VRD" > + }, > + { > + .reg = CH0_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp5 CH0 DIMM" > + }, > + { > + .reg = CH1_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp6 CH1 DIMM" > + }, > + { > + .reg = CH2_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp7 CH2 DIMM" > + }, > + { > + .reg = CH3_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp8 CH3 DIMM" > + }, > + { > + .reg = CH4_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp9 CH4 DIMM" > + }, > + { > + .reg = CH5_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp10 CH5 DIMM" > + }, > + { > + .reg = CH6_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp11 CH6 DIMM" > + }, > + { > + .reg = CH7_DIMM_TEMP, > + .reg_ext = MEM_HOT_THRESHOLD, > + .label = "temp12 CH7 DIMM" > + }, > + { > + .reg = RCA_VRD_TEMP, > + .label = "temp13 RCA VRD" > + }, > +}; > + > +static const struct smpro_sensor voltage[] = { > + { > + .reg = CORE_VRD_VOLT, > + .label = "vout0 CORE VRD" > + }, > + { > + .reg = SOC_VRD_VOLT, > + .label = "vout1 SoC VRD" > + }, > + { > + .reg = DIMM_VRD1_VOLT, > + .label = "vout2 DIMM VRD1" > + }, > + { > + .reg = DIMM_VRD2_VOLT, > + .label = "vout3 DIMM VRD2" > + }, > + { > + .reg = RCA_VRD_VOLT, > + .label = "vout4 RCA VRD" > + }, > +}; > + > +static const struct smpro_sensor curr_sensor[] = { > + { > + .reg = CORE_VRD_CURR, > + .label = "iout1 CORE VRD" > + }, > + { > + .reg = SOC_VRD_CURR, > + .label = "iout2 SoC VRD" > + }, > + { > + .reg = DIMM_VRD1_CURR, > + .label = "iout3 DIMM VRD1" > + }, > + { > + .reg = DIMM_VRD2_CURR, > + .label = "iout4 DIMM VRD2" > + }, > + { > + .reg = RCA_VRD_CURR, > + .label = "iout5 RCA VRD" > + }, > +}; > + > +static const struct smpro_sensor power[] = { > + { > + .reg = CORE_VRD_PWR, > + .reg_ext = CORE_VRD_PWR_MW, > + .label = "power1 CORE VRD" > + }, > + { > + .reg = SOC_PWR, > + .reg_ext = SOC_PWR_MW, > + .label = "power2 SoC" > + }, > + { > + .reg = DIMM_VRD1_PWR, > + .reg_ext = DIMM_VRD1_PWR_MW, > + .label = "power3 DIMM VRD1" > + }, > + { > + .reg = DIMM_VRD2_PWR, > + .reg_ext = DIMM_VRD2_PWR_MW, > + .label = "power4 DIMM VRD2" > + }, > + { > + .reg = RCA_VRD_PWR, > + .reg_ext = RCA_VRD_PWR_MW, > + .label = "power5 RCA VRD" > + }, > +}; > + > +static int smpro_read_temp(struct device *dev, u32 attr, int channel, long *val) > +{ > + struct smpro_hwmon *hwmon = dev_get_drvdata(dev); > + unsigned int value; > + int ret; > + > + switch (attr) { > + case hwmon_temp_input: > + ret = regmap_read(hwmon->regmap, hwmon->offset + temperature[channel].reg, &value); > + if (ret) > + return ret; > + break; > + case hwmon_temp_crit: > + ret = regmap_read(hwmon->regmap, > + hwmon->offset + temperature[channel].reg_ext, &value); > + if (ret) > + return ret; > + break; > + default: > + return -EOPNOTSUPP; > + } > + > + *val = sign_extend32(value, 8) * 1000; > + return 0; > +} > + > +static int smpro_read_in(struct device *dev, u32 attr, int channel, long *val) > +{ > + struct smpro_hwmon *hwmon = dev_get_drvdata(dev); > + unsigned int value; > + int ret; > + > + switch (attr) { > + case hwmon_in_input: > + ret = regmap_read(hwmon->regmap, hwmon->offset + voltage[channel].reg, &value); > + if (ret < 0) > + return ret; > + /* 15-bit value in 1mV */ > + *val = value & 0x7fff; > + return 0; > + default: > + return -EOPNOTSUPP; > + } > +} > + > +static int smpro_read_curr(struct device *dev, u32 attr, int channel, long *val) > +{ > + struct smpro_hwmon *hwmon = dev_get_drvdata(dev); > + unsigned int value; > + int ret; > + > + switch (attr) { > + case hwmon_curr_input: > + ret = regmap_read(hwmon->regmap, hwmon->offset + curr_sensor[channel].reg, &value); > + if (ret < 0) > + return ret; > + /* Scale reported by the hardware is 1mA */ > + *val = value & 0x7fff; > + return 0; > + default: > + return -EOPNOTSUPP; > + } > +} > + > +static int smpro_read_power(struct device *dev, u32 attr, int channel, long *val_pwr) > +{ > + struct smpro_hwmon *hwmon = dev_get_drvdata(dev); > + unsigned int val = 0, val_mw = 0; > + int ret; > + > + switch (attr) { > + case hwmon_power_input: > + ret = regmap_read(hwmon->regmap, hwmon->offset + power[channel].reg, &val); > + if (ret) > + return ret; > + > + ret = regmap_read(hwmon->regmap, hwmon->offset + power[channel].reg_ext, &val_mw); > + if (ret) > + return ret; > + > + *val_pwr = val * 1000000 + val_mw * 1000; > + return 0; > + > + default: > + return -EOPNOTSUPP; > + } > +} > + > +static int smpro_read(struct device *dev, enum hwmon_sensor_types type, > + u32 attr, int channel, long *val) > +{ > + switch (type) { > + case hwmon_temp: > + return smpro_read_temp(dev, attr, channel, val); > + case hwmon_in: > + return smpro_read_in(dev, attr, channel, val); > + case hwmon_power: > + return smpro_read_power(dev, attr, channel, val); > + case hwmon_curr: > + return smpro_read_curr(dev, attr, channel, val); > + default: > + return -EOPNOTSUPP; > + } > +} > + > +static int smpro_read_string(struct device *dev, enum hwmon_sensor_types type, > + u32 attr, int channel, const char **str) > +{ > + switch (type) { > + case hwmon_temp: > + switch (attr) { > + case hwmon_temp_label: > + *str = temperature[channel].label; > + return 0; > + default: > + break; > + } > + break; > + > + case hwmon_in: > + switch (attr) { > + case hwmon_in_label: > + *str = voltage[channel].label; > + return 0; > + default: > + break; > + } > + break; > + > + case hwmon_curr: > + switch (attr) { > + case hwmon_curr_label: > + *str = curr_sensor[channel].label; > + return 0; > + default: > + break; > + } > + break; > + > + case hwmon_power: > + switch (attr) { > + case hwmon_power_label: > + *str = power[channel].label; > + return 0; > + default: > + break; > + } > + break; > + default: > + break; > + } > + > + return -EOPNOTSUPP; > +} > + > +static umode_t smpro_is_visible(const void *data, enum hwmon_sensor_types type, > + u32 attr, int channel) > +{ > + const struct smpro_hwmon *hwmon = data; > + unsigned int value; > + int ret; > + > + switch (type) { > + case hwmon_temp: > + switch (attr) { > + case hwmon_temp_input: > + case hwmon_temp_label: > + case hwmon_temp_crit: > + ret = regmap_read(hwmon->regmap, > + hwmon->offset + temperature[channel].reg, &value); > + if (ret || value == 0xFFFF) > + return 0; > + break; > + } > + default: > + break; > + } > + > + return 0444; > +} > + > +static const struct hwmon_channel_info *smpro_info[] = { > + HWMON_CHANNEL_INFO(temp, > + HWMON_T_INPUT | HWMON_T_LABEL, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL, > + HWMON_T_INPUT | HWMON_T_LABEL, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL | HWMON_T_CRIT, > + HWMON_T_INPUT | HWMON_T_LABEL), > + HWMON_CHANNEL_INFO(in, > + HWMON_I_INPUT | HWMON_I_LABEL, > + HWMON_I_INPUT | HWMON_I_LABEL, > + HWMON_I_INPUT | HWMON_I_LABEL, > + HWMON_I_INPUT | HWMON_I_LABEL, > + HWMON_I_INPUT | HWMON_I_LABEL), > + HWMON_CHANNEL_INFO(power, > + HWMON_P_INPUT | HWMON_P_LABEL, > + HWMON_P_INPUT | HWMON_P_LABEL, > + HWMON_P_INPUT | HWMON_P_LABEL, > + HWMON_P_INPUT | HWMON_P_LABEL, > + HWMON_P_INPUT | HWMON_P_LABEL), > + HWMON_CHANNEL_INFO(curr, > + HWMON_C_INPUT | HWMON_C_LABEL, > + HWMON_C_INPUT | HWMON_C_LABEL, > + HWMON_C_INPUT | HWMON_C_LABEL, > + HWMON_C_INPUT | HWMON_C_LABEL, > + HWMON_C_INPUT | HWMON_C_LABEL), > + NULL > +}; > + > +static const struct hwmon_ops smpro_hwmon_ops = { > + .is_visible = smpro_is_visible, > + .read = smpro_read, > + .read_string = smpro_read_string, > +}; > + > +static const struct hwmon_chip_info smpro_chip_info = { > + .ops = &smpro_hwmon_ops, > + .info = smpro_info, > +}; > + > +static int smpro_hwmon_probe(struct platform_device *pdev) > +{ > + struct smpro_hwmon *hwmon; > + struct device *hwmon_dev; > + unsigned int val; > + int ret; > + > + hwmon = devm_kzalloc(&pdev->dev, sizeof(struct smpro_hwmon), GFP_KERNEL); > + if (!hwmon) > + return -ENOMEM; > + > + hwmon->regmap = dev_get_regmap(pdev->dev.parent, NULL); > + if (!hwmon->regmap) > + return -ENODEV; > + > + ret = device_property_read_u32(&pdev->dev, "reg", &hwmon->offset); > + if (ret) > + return -EINVAL; > + > + /* Check for valid ID */ > + ret = regmap_read(hwmon->regmap, MANUFACTURER_ID_REG, &val); > + if (ret) > + return ret; > + > + if (val != AMPERE_MANUFACTURER_ID) > + return -ENODEV; > + > + hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev, "smpro_hwmon", > + hwmon, &smpro_chip_info, NULL); > + > + return PTR_ERR_OR_ZERO(hwmon_dev); > +} > + > +static const struct of_device_id smpro_hwmon_of_match[] = { > + { .compatible = "ampere,ac01-hwmon" }, > + {} > +}; > +MODULE_DEVICE_TABLE(of, smpro_hwmon_of_match); > + > +static struct platform_driver smpro_hwmon_driver = { > + .probe = smpro_hwmon_probe, > + .driver = { > + .name = "smpro-hwmon", > + .of_match_table = smpro_hwmon_of_match, > + }, > +}; > + > +module_platform_driver(smpro_hwmon_driver); > + > +MODULE_AUTHOR("Thu Nguyen <thu@os.amperecomputing.com>"); > +MODULE_AUTHOR("Quan Nguyen <quan@os.amperecomputing.com>"); > +MODULE_DESCRIPTION("Ampere Altra SMPro hwmon driver"); > +MODULE_LICENSE("GPL v2");
On Thu, Apr 22, 2021 at 04:08:40PM +0700, Quan Nguyen wrote: > Adds device tree bindings for SMPro driver found on the Mt.Jade hardware > reference platform with Ampere's Altra Processor family. > > The SMpro co-processor on Ampere Altra processor family is to monitor > and report various data included hwmon-related info, RAS errors, and > other miscellaneous information. This parent SMPro MFD driver creates > a single simple register map to be shared by all sub-devices and leave > all the specific to be handled by the child drivers. Again, just because you have multiple functions aka MFD, that doesn't mean you need child nodes for each function. The only thing you have in DT is a register address. Does this vary? If so, how often? How many different versions of a DT do you currently or expect to have? > > Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> > --- > Changes in v4: > + Revised the commit message to clarify how the specific info will > be handled commented by Rob. > > Changes in v3: > + Supported list of compatible string [Rob] > + Introduced reg property in DT to specify reg offset [Rob] > + Updated description and other minor changes in yaml file [Rob] > > Changes in v2: > + Changed "ampere,ac01-smpro" to "ampere,smpro" [Quan] > > .../bindings/hwmon/ampere,ac01-hwmon.yaml | 28 +++++ > .../devicetree/bindings/mfd/ampere,smpro.yaml | 105 ++++++++++++++++++ > 2 files changed, 133 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml > create mode 100644 Documentation/devicetree/bindings/mfd/ampere,smpro.yaml > > diff --git a/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml > new file mode 100644 > index 000000000000..fbf7ec754160 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml > @@ -0,0 +1,28 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwmon/ampere,ac01-hwmon.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Hardware monitoring driver for the Ampere Altra SMPro > + > +maintainers: > + - Quan Nguyen <quan@os.amperecomputing.com> > + > +description: | > + This module is part of the Ampere Altra SMPro multi-function device. For more > + details see ../mfd/ampere,smpro.yaml. > + > +properties: > + compatible: > + enum: > + - ampere,ac01-hwmon > + > + reg: > + maxItems: 1 > + > +required: > + - compatible > + - reg > + > +additionalProperties: false > diff --git a/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml > new file mode 100644 > index 000000000000..5613c420869e > --- /dev/null > +++ b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml > @@ -0,0 +1,105 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/mfd/ampere,smpro.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Ampere Altra SMPro firmware driver > + > +maintainers: > + - Quan Nguyen <quan@os.amperecomputing.com> > + > +description: | > + Ampere Altra SMPro firmware may contain different blocks like hardware > + monitoring, error monitoring and other miscellaneous features. > + > +properties: > + compatible: > + enum: > + - ampere,smpro > + > + reg: > + description: > + I2C device address. > + maxItems: 1 > + > + "#address-cells": > + const: 1 > + > + "#size-cells": > + const: 0 > + > +patternProperties: > + "^hwmon(@[0-9a-f]+)?$": > + $ref: ../hwmon/ampere,ac01-hwmon.yaml > + > + "^misc(@[0-9a-f]+)?$": > + type: object > + description: | > + This module is part of the Ampere Altra SMPro multi-function device > + to support miscellaneous features > + properties: > + compatible: > + enum: > + - ampere,ac01-misc > + reg: > + maxItems: 1 > + > + required: > + - compatible > + - reg > + > + "^errmon(@[0-9a-f]+)?$": > + type: object > + description: | > + This module is part of the Ampere Altra SMPro multi-function device > + that supports error monitoring feature. > + > + properties: > + compatible: > + enum: > + - ampere,ac01-errmon > + reg: > + maxItems: 1 > + > + required: > + - compatible > + - reg > + > +required: > + - "#address-cells" > + - "#size-cells" > + - compatible > + - reg > + > +additionalProperties: false > + > +examples: > + - | > + i2c { > + #address-cells = <1>; > + #size-cells = <0>; > + > + smpro@4f { > + compatible = "ampere,smpro"; > + reg = <0x4f>; > + #address-cells = <1>; > + #size-cells = <0>; > + > + hwmon@10 { > + compatible = "ampere,ac01-hwmon"; > + reg = <0x10>; > + }; > + > + misc@b0 { > + compatible = "ampere,ac01-misc"; > + reg = <0xb0>; > + }; > + > + errmon@80 { > + compatible = "ampere,ac01-errmon"; > + reg = <0x80>; > + }; > + > + }; > + }; > -- > 2.28.0 >
On 01/05/2021 03:19, Rob Herring wrote: > On Thu, Apr 22, 2021 at 04:08:40PM +0700, Quan Nguyen wrote: >> Adds device tree bindings for SMPro driver found on the Mt.Jade hardware >> reference platform with Ampere's Altra Processor family. >> >> The SMpro co-processor on Ampere Altra processor family is to monitor >> and report various data included hwmon-related info, RAS errors, and >> other miscellaneous information. This parent SMPro MFD driver creates >> a single simple register map to be shared by all sub-devices and leave >> all the specific to be handled by the child drivers. > > Again, just because you have multiple functions aka MFD, that doesn't > mean you need child nodes for each function. The only thing you have > in DT is a register address. Does this vary? If so, how often? How many > different versions of a DT do you currently or expect to have? > Hi Rob, Thank you for your review. I will try to explain what I think below and expect to receive more comments to improve these patches. And if any misundertood, please help correct me. The idea is to keep the SMPro MFD as a simple generic register map and expect not to change or to handle any specific in this parent device driver. This is why we see the simple_mfd_i2c fit in this case. And so, all the specific details will be handled in child devices driver and we expect to have child nodes for these child devices. If the child node exist we can then add any specific if necessary later. One case is that, each socket (ie: the Ampere Altra processor) has it own SMPro co-processor instance in form of register map and each socket could be either slave or master. Some function may not available in slave socket but exist in master socket and we simply choose not to define the child node if that function not existed. The other case is that if there are multi instances of the same function in one SMPro MFD register map, then each instance might need to be differentiated by using is own register address or maybe a DT property. Then we can simply add them to the node of these instance. For your specific questions: + Does this vary ? yes, I think so. The register address in each child nodes may vary if the SMPro co-processor firmware change its register map layout or maybe other instances of a function added. Child device drivers are expected to handle these changes if necessary. + About how often ? I actually can't say how often but the purpose of this SMPro register map is to provide the info to the BMC. The BMC will need more info from the host so I think changes will be unavoidable. Please help with your comments Thank you, - Quan >> >> Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com> >> --- >> Changes in v4: >> + Revised the commit message to clarify how the specific info will >> be handled commented by Rob. >> >> Changes in v3: >> + Supported list of compatible string [Rob] >> + Introduced reg property in DT to specify reg offset [Rob] >> + Updated description and other minor changes in yaml file [Rob] >> >> Changes in v2: >> + Changed "ampere,ac01-smpro" to "ampere,smpro" [Quan] >> >> .../bindings/hwmon/ampere,ac01-hwmon.yaml | 28 +++++ >> .../devicetree/bindings/mfd/ampere,smpro.yaml | 105 ++++++++++++++++++ >> 2 files changed, 133 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml >> create mode 100644 Documentation/devicetree/bindings/mfd/ampere,smpro.yaml >> >> diff --git a/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml >> new file mode 100644 >> index 000000000000..fbf7ec754160 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/hwmon/ampere,ac01-hwmon.yaml >> @@ -0,0 +1,28 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/hwmon/ampere,ac01-hwmon.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Hardware monitoring driver for the Ampere Altra SMPro >> + >> +maintainers: >> + - Quan Nguyen <quan@os.amperecomputing.com> >> + >> +description: | >> + This module is part of the Ampere Altra SMPro multi-function device. For more >> + details see ../mfd/ampere,smpro.yaml. >> + >> +properties: >> + compatible: >> + enum: >> + - ampere,ac01-hwmon >> + >> + reg: >> + maxItems: 1 >> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false >> diff --git a/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml >> new file mode 100644 >> index 000000000000..5613c420869e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mfd/ampere,smpro.yaml >> @@ -0,0 +1,105 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/mfd/ampere,smpro.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Ampere Altra SMPro firmware driver >> + >> +maintainers: >> + - Quan Nguyen <quan@os.amperecomputing.com> >> + >> +description: | >> + Ampere Altra SMPro firmware may contain different blocks like hardware >> + monitoring, error monitoring and other miscellaneous features. >> + >> +properties: >> + compatible: >> + enum: >> + - ampere,smpro >> + >> + reg: >> + description: >> + I2C device address. >> + maxItems: 1 >> + >> + "#address-cells": >> + const: 1 >> + >> + "#size-cells": >> + const: 0 >> + >> +patternProperties: >> + "^hwmon(@[0-9a-f]+)?$": >> + $ref: ../hwmon/ampere,ac01-hwmon.yaml >> + >> + "^misc(@[0-9a-f]+)?$": >> + type: object >> + description: | >> + This module is part of the Ampere Altra SMPro multi-function device >> + to support miscellaneous features >> + properties: >> + compatible: >> + enum: >> + - ampere,ac01-misc >> + reg: >> + maxItems: 1 >> + >> + required: >> + - compatible >> + - reg >> + >> + "^errmon(@[0-9a-f]+)?$": >> + type: object >> + description: | >> + This module is part of the Ampere Altra SMPro multi-function device >> + that supports error monitoring feature. >> + >> + properties: >> + compatible: >> + enum: >> + - ampere,ac01-errmon >> + reg: >> + maxItems: 1 >> + >> + required: >> + - compatible >> + - reg >> + >> +required: >> + - "#address-cells" >> + - "#size-cells" >> + - compatible >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + i2c { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + smpro@4f { >> + compatible = "ampere,smpro"; >> + reg = <0x4f>; >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + hwmon@10 { >> + compatible = "ampere,ac01-hwmon"; >> + reg = <0x10>; >> + }; >> + >> + misc@b0 { >> + compatible = "ampere,ac01-misc"; >> + reg = <0xb0>; >> + }; >> + >> + errmon@80 { >> + compatible = "ampere,ac01-errmon"; >> + reg = <0x80>; >> + }; >> + >> + }; >> + }; >> -- >> 2.28.0 >>
On 05/05/2021 15:44, Quan Nguyen wrote: > On 01/05/2021 03:19, Rob Herring wrote: >> On Thu, Apr 22, 2021 at 04:08:40PM +0700, Quan Nguyen wrote: >>> Adds device tree bindings for SMPro driver found on the Mt.Jade hardware >>> reference platform with Ampere's Altra Processor family. >>> >>> The SMpro co-processor on Ampere Altra processor family is to monitor >>> and report various data included hwmon-related info, RAS errors, and >>> other miscellaneous information. This parent SMPro MFD driver creates >>> a single simple register map to be shared by all sub-devices and leave >>> all the specific to be handled by the child drivers. >> >> Again, just because you have multiple functions aka MFD, that doesn't >> mean you need child nodes for each function. The only thing you have >> in DT is a register address. Does this vary? If so, how often? How many >> different versions of a DT do you currently or expect to have? >> > Hi Rob, > > Thank you for your review. > I will try to explain what I think below and expect to receive more > comments to improve these patches. And if any misundertood, please help > correct me. > > The idea is to keep the SMPro MFD as a simple generic register map and > expect not to change or to handle any specific in this parent device > driver. This is why we see the simple_mfd_i2c fit in this case. > > And so, all the specific details will be handled in child devices driver > and we expect to have child nodes for these child devices. If the child > node exist we can then add any specific if necessary later. > > One case is that, each socket (ie: the Ampere Altra processor) has it > own SMPro co-processor instance in form of register map and each socket > could be either slave or master. Some function may not available in > slave socket but exist in master socket and we simply choose not to > define the child node if that function not existed. > > The other case is that if there are multi instances of the same function > in one SMPro MFD register map, then each instance might need to be > differentiated by using is own register address or maybe a DT property. > Then we can simply add them to the node of these instance. > > For your specific questions: > > + Does this vary ? > yes, I think so. The register address in each child nodes may vary if > the SMPro co-processor firmware change its register map layout or maybe > other instances of a function added. Child device drivers are expected > to handle these changes if necessary. > > + About how often ? > I actually can't say how often but the purpose of this SMPro register > map is to provide the info to the BMC. The BMC will need more info from > the host so I think changes will be unavoidable. > > Please help with your comments > Thank you, > - Quan > Dear Rob, do you have any suggestion to improve this patch? - Quan
On 18/05/2021 06:36, Quan Nguyen wrote: > On 05/05/2021 15:44, Quan Nguyen wrote: >> On 01/05/2021 03:19, Rob Herring wrote: >>> On Thu, Apr 22, 2021 at 04:08:40PM +0700, Quan Nguyen wrote: >>>> Adds device tree bindings for SMPro driver found on the Mt.Jade >>>> hardware >>>> reference platform with Ampere's Altra Processor family. >>>> >>>> The SMpro co-processor on Ampere Altra processor family is to monitor >>>> and report various data included hwmon-related info, RAS errors, and >>>> other miscellaneous information. This parent SMPro MFD driver creates >>>> a single simple register map to be shared by all sub-devices and leave >>>> all the specific to be handled by the child drivers. >>> >>> Again, just because you have multiple functions aka MFD, that doesn't >>> mean you need child nodes for each function. The only thing you have >>> in DT is a register address. Does this vary? If so, how often? How many >>> different versions of a DT do you currently or expect to have? >>> >> Hi Rob, >> >> Thank you for your review. >> I will try to explain what I think below and expect to receive more >> comments to improve these patches. And if any misundertood, please >> help correct me. >> >> The idea is to keep the SMPro MFD as a simple generic register map and >> expect not to change or to handle any specific in this parent device >> driver. This is why we see the simple_mfd_i2c fit in this case. >> >> And so, all the specific details will be handled in child devices >> driver and we expect to have child nodes for these child devices. If >> the child node exist we can then add any specific if necessary later. >> >> One case is that, each socket (ie: the Ampere Altra processor) has it >> own SMPro co-processor instance in form of register map and each >> socket could be either slave or master. Some function may not >> available in slave socket but exist in master socket and we simply >> choose not to define the child node if that function not existed. >> >> The other case is that if there are multi instances of the same >> function in one SMPro MFD register map, then each instance might need >> to be differentiated by using is own register address or maybe a DT >> property. Then we can simply add them to the node of these instance. >> >> For your specific questions: >> >> + Does this vary ? >> yes, I think so. The register address in each child nodes may vary if >> the SMPro co-processor firmware change its register map layout or >> maybe other instances of a function added. Child device drivers are >> expected to handle these changes if necessary. >> >> + About how often ? >> I actually can't say how often but the purpose of this SMPro register >> map is to provide the info to the BMC. The BMC will need more info >> from the host so I think changes will be unavoidable. >> >> Please help with your comments >> Thank you, >> - Quan >> > Dear Rob, > > do you have any suggestion to improve this patch? > > - Quan Dear Rob, I'm sorry it's me again, I'm just hope you could share your thoughts on the DT node for sub-devices using simple-mfd-i2c drivers. In commit 3abee4579484 ("mfd: Add simple regmap based I2C driver"), there is note that "Once the register map has been successfully initialised, any sub-devices represented by child nodes in Device Tree will be subsequently registered". So it seems unavoidable to have DT nodes for sub-devices which uses simple-mfd-i2c. I'm a bit confused if DT nodes in this case should be avoided. Please see https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/patch?id=3abee4579484c554961bb0af92a77adc0ebd791d Thank you, - Quan PS: Below is for quick reference: From 3abee4579484c554961bb0af92a77adc0ebd791d Mon Sep 17 00:00:00 2001 From: Michael Walle <michael@walle.cc> Date: Mon, 14 Sep 2020 23:43:29 +0200 Subject: mfd: Add simple regmap based I2C driver There are I2C devices which contain several different functions but doesn't require any special access functions. For these kind of drivers an I2C regmap should be enough. Create an I2C driver which creates an I2C regmap and enumerates its children. If a device wants to use this as its MFD core driver, it has to add an individual compatible string. It may provide its own regmap configuration. Subdevices can use dev_get_regmap() on the parent to get their regmap instance. Signed-off-by: Michael Walle <michael@walle.cc> Signed-off-by: Lee Jones <lee.jones@linaro.org> --- drivers/mfd/Kconfig | 12 ++++++++++ drivers/mfd/Makefile | 1 + drivers/mfd/simple-mfd-i2c.c | 56 ++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+) create mode 100644 drivers/mfd/simple-mfd-i2c.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index 33df0837ab415..6e1a38944d282 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1162,6 +1162,18 @@ config MFD_SI476X_CORE To compile this driver as a module, choose M here: the module will be called si476x-core. +config MFD_SIMPLE_MFD_I2C + tristate + depends on I2C + select REGMAP_I2C + help + This driver creates a single register map with the intention for it + to be shared by all sub-devices. + + Once the register map has been successfully initialised, any + sub-devices represented by child nodes in Device Tree will be + subsequently registered. + config MFD_SM501 tristate "Silicon Motion SM501" depends on HAS_DMA diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index a60e5f835283e..78d24a3e7c9e5 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -264,3 +264,4 @@ obj-$(CONFIG_MFD_STMFX) += stmfx.o obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o +obj-$(CONFIG_MFD_SIMPLE_MFD_I2C) += simple-mfd-i2c.o diff --git a/drivers/mfd/simple-mfd-i2c.c b/drivers/mfd/simple-mfd-i2c.c new file mode 100644 index 0000000000000..28e96a246be11 --- /dev/null +++ b/drivers/mfd/simple-mfd-i2c.c @@ -0,0 +1,56 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Simple MFD - I2C + * + * This driver creates a single register map with the intention for it to be + * shared by all sub-devices. Children can use their parent's device structure + * (dev.parent) in order to reference it. + * + * Once the register map has been successfully initialised, any sub-devices + * represented by child nodes in Device Tree will be subsequently registered. + */ +