All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
@ 2021-06-25 13:25 Naveen Krishna Chatradhi
  2021-06-25 13:25 ` [PATCH 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
                   ` (5 more replies)
  0 siblings, 6 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-06-25 13:25 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

On AMD platforms the Out-of-band access is provided by Advanced Platform Management
Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
APML is also referred as the sideband interface (SBI).

APML is used to communicate with the Remote Management Interface
(SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox messages
to report power consumption and power limits of the CPU socket.

- This module add support to read power consumption,
  power limit & max power limit and write power limit.
- To instantiate this driver on an AMD CPU with SB-RMI support,
  the i2c bus number would be the bus connected from the board
  management controller (BMC) to the CPU.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
 drivers/hwmon/Kconfig  |  10 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 405 insertions(+)
 create mode 100644 drivers/hwmon/sbrmi.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 87624902ea80..d1813ea8382c 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi_temp.
 
+config SENSORS_SBRMI
+	tristate "Emulated SB-RMI sensor"
+	depends on I2C
+	help
+	  If you say yes here you get support for emulated RMI
+	  sensors on AMD SoCs with APML interface connected to a BMC device.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sbrmi.
+
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 59e78bc212cf..8031acf58936 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
 obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
 obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
+obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
 obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
new file mode 100644
index 000000000000..c35829513459
--- /dev/null
+++ b/drivers/hwmon/sbrmi.c
@@ -0,0 +1,394 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sbrmi.c - hwmon driver for a SB-RMI mailbox
+ *           compliant AMD SoC device.
+ *
+ * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <asm-generic/ioctl.h>
+#include <linux/delay.h>
+
+/* Do not allow setting negative power limit */
+#define SBRMI_PWR_MIN 0
+/* Mask for Status Register bit[1] */
+#define SW_ALERT_MASK 0x2
+
+/* Software Interrupt for triggering */
+#define START_CMD	0x80
+#define TRIGGER_MAILBOX	0x01
+
+/*
+ * SB-RMI supports soft mailbox service request to MP1 (power management
+ * firmware) through SBRMI inbound/outbound message registers.
+ * SB-RMI message IDs
+ */
+enum sbrmi_msg_id {
+	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
+	SBRMI_WRITE_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_MAX_PWR_LIMIT,
+};
+
+/* SB-RMI registers */
+enum sbrmi_reg {
+	SBRMI_CTRL		= 0x01,
+	SBRMI_STATUS,
+	SBRMI_OUTBNDMSG0	= 0x30,
+	SBRMI_OUTBNDMSG1,
+	SBRMI_OUTBNDMSG2,
+	SBRMI_OUTBNDMSG3,
+	SBRMI_OUTBNDMSG4,
+	SBRMI_OUTBNDMSG5,
+	SBRMI_OUTBNDMSG6,
+	SBRMI_OUTBNDMSG7,
+	SBRMI_INBNDMSG0,
+	SBRMI_INBNDMSG1,
+	SBRMI_INBNDMSG2,
+	SBRMI_INBNDMSG3,
+	SBRMI_INBNDMSG4,
+	SBRMI_INBNDMSG5,
+	SBRMI_INBNDMSG6,
+	SBRMI_INBNDMSG7,
+	SBRMI_SW_INTERRUPT,
+};
+
+/*
+ * Each client has this additional data
+ */
+struct sbrmi_data {
+	struct i2c_client *client;
+	struct mutex lock;
+};
+
+/* Mailbox message data format */
+union mailbox_word {
+	u8 bytes[4];
+	u32 value;
+};
+
+struct sbrmi_mailbox_msg {
+	u8 cmd;
+	bool read;
+	union mailbox_word data_in;
+	union mailbox_word data_out;
+};
+
+static int print_mailbox_error(struct sbrmi_data *data)
+{
+	int status;
+
+	/* Mailbox error code will be written by Firmware in
+	 * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
+	 */
+	status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
+	if (status < 0) {
+		pr_err("SMBUS translation failed\n");
+		return status;
+	}
+
+	switch (status) {
+	case 0x0:	/* Success */
+		break;
+	case 0x1:
+		pr_err("Mailbox message command is aborted\n");
+		break;
+	case 0x2:
+		pr_err("Unknown mailbox message\n");
+		break;
+	case 0x3:
+		pr_err("Invalid core is specified in mailbox message parameters\n");
+		break;
+	default:
+		pr_err("Unknown Error\n");
+	}
+
+	return status;
+}
+
+static int sbrmi_enable_alert(struct sbrmi_data *data)
+{
+	int ctrl;
+
+	/* Enable the SB-RMI Software alert status
+	 * by writing 0 to bit 4 of Control register(0x1)
+	 */
+	ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
+	if (ctrl < 0)
+		return ctrl;
+
+	if (ctrl & 0x10) {
+		ctrl &= ~0x10;
+		return i2c_smbus_write_byte_data(data->client,
+						 SBRMI_CTRL, ctrl);
+	}
+
+	return 0;
+}
+
+static int rmi_mailbox_xfer(struct sbrmi_data *data,
+			    struct sbrmi_mailbox_msg *msg)
+{
+	union mailbox_word output, input;
+	int i, err = 0, retry = 10;
+	int sw_status;
+
+	mutex_lock(&data->lock);
+
+	err = sbrmi_enable_alert(data);
+	if (err < 0)
+		goto exit_unlock;
+
+	/* Indicate firmware a command is to be serviced */
+	err = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG7, START_CMD);
+	if (err < 0)
+		goto exit_unlock;
+
+	/* Write the command to SBRMI::InBndMsg_inst0 */
+	err = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG0, msg->cmd);
+	if (err < 0)
+		goto exit_mod;
+
+	/*
+	 * For both read and write the initiator (BMC) writes
+	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
+	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
+	 */
+	input = msg->data_in;
+	for (i = 0; i < 3; i++) {
+		err = i2c_smbus_write_byte_data(data->client,
+						(SBRMI_INBNDMSG1 + i),
+						input.bytes[i]);
+		if (err < 0)
+			goto exit_mod;
+	}
+
+	/*
+	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
+	 * perform the requested read or write command
+	 */
+	err = i2c_smbus_write_byte_data(data->client,
+					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
+	if (err < 0)
+		goto exit_mod;
+
+	/*
+	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
+	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
+	 * of the requested command
+	 */
+	do {
+		sw_status = i2c_smbus_read_byte_data(data->client,
+						     SBRMI_STATUS);
+		if (sw_status < 0) {
+			err = sw_status;
+			goto exit_mod;
+		}
+		if (sw_status & SW_ALERT_MASK)
+			break;
+		usleep_range(50, 100);
+	} while (retry--);
+
+	if (retry < 0) {
+		pr_err("Firmware fail to indicate command colmpletion\n");
+		err = -1;
+		goto exit_mod;
+	}
+
+	/*
+	 * For a read operation, the initiator (BMC) reads the firmware response
+	 * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
+	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
+	 */
+	if (msg->read) {
+		for (i = 0; i < 4; i++) {
+			output.bytes[i] = i2c_smbus_read_byte_data(data->client,
+								   (SBRMI_OUTBNDMSG1 + i));
+			if (output.bytes[i] < 0) {
+				err = output.bytes[i];
+				goto exit_mod;
+			}
+		}
+	}
+	msg->data_out = output;
+
+	/*
+	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
+	 * ALERT to initiator
+	 */
+	err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
+					(sw_status | SW_ALERT_MASK));
+
+exit_mod:
+	if (err < 0)
+		pr_err("SMBUS translation failed\n");
+	else
+		err = print_mailbox_error(data);
+exit_unlock:
+	mutex_unlock(&data->lock);
+	return err;
+}
+
+static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
+		      u32 attr, int channel, long *val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	if (type != hwmon_power)
+		return -EINVAL;
+
+	msg.read = true;
+	switch (attr) {
+	case hwmon_power_input:
+		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap:
+		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap_max:
+		msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	default:
+		return -EINVAL;
+	}
+	/*
+	 * hwmon power attributes are in microWatt
+	 */
+	*val = (long)msg.data_out.value * 1000;
+	return ret;
+}
+
+static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
+		       u32 attr, int channel, long val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+
+	if (type != hwmon_power && attr != hwmon_power_cap)
+		return -EINVAL;
+	/*
+	 * hwmon power attributes are in microWatt
+	 * mailbox read/write is in mWatt
+	 */
+	val /= 1000;
+
+	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+	msg.data_in.value = 0;
+	msg.read = true;
+	rmi_mailbox_xfer(data, &msg);
+
+	val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
+
+	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
+	msg.data_in.value = val;
+	msg.read = false;
+
+	return rmi_mailbox_xfer(data, &msg);
+}
+
+static umode_t sbrmi_is_visible(const void *data,
+				enum hwmon_sensor_types type,
+				u32 attr, int channel)
+{
+	switch (type) {
+	case hwmon_power:
+		switch (attr) {
+		case hwmon_power_input:
+		case hwmon_power_cap_max:
+			return 0444;
+		case hwmon_power_cap:
+			return 0644;
+		}
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static const struct hwmon_channel_info *sbrmi_info[] = {
+	HWMON_CHANNEL_INFO(power,
+			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
+	NULL
+};
+
+static const struct hwmon_ops sbrmi_hwmon_ops = {
+	.is_visible = sbrmi_is_visible,
+	.read = sbrmi_read,
+	.write = sbrmi_write,
+};
+
+static const struct hwmon_chip_info sbrmi_chip_info = {
+	.ops = &sbrmi_hwmon_ops,
+	.info = sbrmi_info,
+};
+
+static int sbrmi_probe(struct i2c_client *client,
+		       const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct device *hwmon_dev;
+	struct sbrmi_data *data;
+
+	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
+		dev_err(&client->dev, "adapter does not support true I2C\n");
+		return -ENODEV;
+	}
+
+	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->client = client;
+	mutex_init(&data->lock);
+
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+							 &sbrmi_chip_info, NULL);
+
+	return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id sbrmi_id[] = {
+	{"sbrmi", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sbrmi_id);
+
+static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
+	{
+		.compatible = "amd,sbrmi",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sbrmi_of_match);
+
+static struct i2c_driver sbrmi_driver = {
+	.class = I2C_CLASS_HWMON,
+	.driver = {
+		.name = "sbrmi",
+		.of_match_table = of_match_ptr(sbrmi_of_match),
+	},
+	.probe = sbrmi_probe,
+	.id_table = sbrmi_id,
+};
+
+module_i2c_driver(sbrmi_driver);
+
+MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
+MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
+MODULE_LICENSE("GPL");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 2/3] hwmon: sbrmi: Add Documentation
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
@ 2021-06-25 13:25 ` Naveen Krishna Chatradhi
  2021-06-28 15:01   ` Guenter Roeck
  2021-06-25 13:25 ` [PATCH 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-06-25 13:25 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Add documentation for sbrmi module

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
 Documentation/hwmon/index.rst |  1 +
 Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/hwmon/sbrmi.rst

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 9ed60fa84cbe..5cd4798fe193 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
    q54sj108a2
    raspberrypi-hwmon
    sbtsi_temp
+   sbrmi
    sch5627
    sch5636
    scpi-hwmon
diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
new file mode 100644
index 000000000000..db50393167bb
--- /dev/null
+++ b/Documentation/hwmon/sbrmi.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver sbrmi
+===================
+
+Supported hardware:
+
+  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
+    device connected to the BMC via the APML.
+
+    Prefix: 'sbrmi'
+
+    Addresses scanned: This driver doesn't support address scanning.
+
+    To instantiate this driver on an AMD CPU with SB-RMI
+    support, the i2c bus number would be the bus connected from the board
+    management controller (BMC) to the CPU.
+    The SMBus address is really 7 bits. Some vendors and the SMBus
+    specification show the address as 8 bits, left justified with the R/W
+    bit as a write (0) making bit 0. Some vendors use only the 7 bits
+    to describe the address.
+    As mentioned in AMD's APML specification, The SB-RMI address is
+    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
+    or 38h(011 1000) for socket 1, but it could vary based on hardware
+    address select pins.
+
+    Datasheet: The SB-RMI interface and protocol along with the Advanced
+               Platform Management Link (APML) Specification is available
+               as part of the open source SoC register reference at:
+
+               https://www.amd.com/en/support/tech-docs?keyword=55898
+
+Author: Akshay Gupta <akshay.gupta@amd.com>
+
+Description
+-----------
+
+The APML provides a way to communicate with the SB Remote Management interface
+(SB-RMI) module from the external SMBus master that can be used to report socket
+power on AMD platforms using mailbox command and resembles a typical 8-pin remote
+power sensor's I2C interface to BMC.
+
+This driver implements current power with power cap and power cap max.
+
+sysfs-Interface
+---------------
+Power sensors can be queried and set via the standard ``hwmon`` interface
+on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
+of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
+content ``sbrmi``)
+
+================ ===== ========================================================
+Name             Perm   Description
+================ ===== ========================================================
+power#_input     RO    Current Power consumed
+power#_cap       RW    Power limit can be set between 0 and power#_cap_max
+power#_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
+================ ===== ========================================================
+
+The following example show how the 'Power' attribute from the i2c-addresses
+can be monitored using the userspace utilities like ``sensors`` binary::
+
+  # sensors
+  sbrmi-i2c-1-38
+  Adapter: bcm2835 I2C adapter
+  power1:       61.00 W (cap = 225.00 W)
+
+  sbrmi-i2c-1-3c
+  Adapter: bcm2835 I2C adapter
+  power1:       28.39 W (cap = 224.77 W)
+  #
+
+Also, Below shows how get and set the values from sysfs entries individually::
+  # cat /sys/class/hwmon/hwmon1/power1_cap_max
+  225000000
+
+  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
+  # cat /sys/class/hwmon/hwmon1/power1_cap
+  180000000
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
  2021-06-25 13:25 ` [PATCH 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-06-25 13:25 ` Naveen Krishna Chatradhi
  2021-06-28 14:58 ` [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-06-25 13:25 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Document device tree bindings for AMD SB-RMI emulated service.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
 .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
new file mode 100644
index 000000000000..7598b083979c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: >
+  Sideband Remote Management Interface (SB-RMI) compliant
+  AMD SoC power device.
+
+maintainers:
+  - Akshay Gupta <Akshay.Gupta@amd.com>
+
+description: |
+  SB Remote Management Interface (SB-RMI) is an SMBus compatible
+  interface that reports AMD SoC's Power (normalized Power) using,
+  Mailbox Service Request and resembles a typical 8-pin remote power
+  sensor's I2C interface to BMC. The power attributes in hwmon
+  reports power in microwatts.
+
+properties:
+  compatible:
+    enum:
+      - amd,sbrmi
+
+  reg:
+    maxItems: 1
+    description: |
+      I2C bus address of the device as specified in Section SBI SMBus Address
+      of the SoC register reference. The SB-RMI address is normally 78h for
+      socket 0 and 70h for socket 1, but it could vary based on hardware
+      address select pins.
+      \[open source SoC register reference\]
+        https://www.amd.com/en/support/tech-docs?keyword=55898
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c0 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sbrmi@3c {
+                compatible = "amd,sbrmi";
+                reg = <0x3c>;
+        };
+    };
+...
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
  2021-06-25 13:25 ` [PATCH 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
  2021-06-25 13:25 ` [PATCH 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-06-28 14:58 ` Guenter Roeck
  2021-06-29 15:05   ` Chatradhi, Naveen Krishna
  2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 28+ messages in thread
From: Guenter Roeck @ 2021-06-28 14:58 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi, linux-hwmon; +Cc: Akshay Gupta

On 6/25/21 6:25 AM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> On AMD platforms the Out-of-band access is provided by Advanced Platform Management

This is a bit too long for checkpatch.

> Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
> 
> APML is used to communicate with the Remote Management Interface
> (SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox messages
> to report power consumption and power limits of the CPU socket.
> 
> - This module add support to read power consumption,
>    power limit & max power limit and write power limit.
> - To instantiate this driver on an AMD CPU with SB-RMI support,
>    the i2c bus number would be the bus connected from the board
>    management controller (BMC) to the CPU.
> 

This is a bit vague. Would this driver be instantiated on the host CPU or on the BMC ?

> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
>   drivers/hwmon/Kconfig  |  10 ++
>   drivers/hwmon/Makefile |   1 +
>   drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 405 insertions(+)
>   create mode 100644 drivers/hwmon/sbrmi.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 87624902ea80..d1813ea8382c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>   	  This driver can also be built as a module. If so, the module will
>   	  be called sbtsi_temp.
>   
> +config SENSORS_SBRMI
> +	tristate "Emulated SB-RMI sensor"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for emulated RMI
> +	  sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called sbrmi.
> +
>   config SENSORS_SHT15
>   	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>   	depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
>   obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
>   obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>   obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
>   obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
> new file mode 100644
> index 000000000000..c35829513459
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>

I don't immediately see why this include is needed.

> +#include <asm-generic/ioctl.h>

This looks wrong, and I don't immediately see why it would be needed.

> +#include <linux/delay.h>

Alphabetic include file order, please.

> +
> +/* Do not allow setting negative power limit */
> +#define SBRMI_PWR_MIN 0
> +/* Mask for Status Register bit[1] */
> +#define SW_ALERT_MASK 0x2
> +

Please always use

#define<space>DEFINITION<tab>value
                         ^^^^^

> +/* Software Interrupt for triggering */
> +#define START_CMD	0x80
> +#define TRIGGER_MAILBOX	0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +	SBRMI_WRITE_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +	SBRMI_CTRL		= 0x01,
> +	SBRMI_STATUS,
> +	SBRMI_OUTBNDMSG0	= 0x30,
> +	SBRMI_OUTBNDMSG1,
> +	SBRMI_OUTBNDMSG2,
> +	SBRMI_OUTBNDMSG3,
> +	SBRMI_OUTBNDMSG4,
> +	SBRMI_OUTBNDMSG5,
> +	SBRMI_OUTBNDMSG6,
> +	SBRMI_OUTBNDMSG7,
> +	SBRMI_INBNDMSG0,
> +	SBRMI_INBNDMSG1,
> +	SBRMI_INBNDMSG2,
> +	SBRMI_INBNDMSG3,
> +	SBRMI_INBNDMSG4,
> +	SBRMI_INBNDMSG5,
> +	SBRMI_INBNDMSG6,
> +	SBRMI_INBNDMSG7,
> +	SBRMI_SW_INTERRUPT,
> +};
> +
> +/*
> + * Each client has this additional data
> + */

Please be consistent with comments: This does not really need to be
a multi-line comment. While that does not really matter, you use
a single-line comment to describe the next structure. Please make it
both either single-line or multi-line.

> +struct sbrmi_data {
> +	struct i2c_client *client;
> +	struct mutex lock;
> +};
> +
> +/* Mailbox message data format */
> +union mailbox_word {
> +	u8 bytes[4];
> +	u32 value;

That strongly suggests that the driver will only work on either little-endian
or big-endian systems, depending on the byte order of transfers. Please restrict
it accordingly.

> +};
> +
> +struct sbrmi_mailbox_msg {
> +	u8 cmd;
> +	bool read;
> +	union mailbox_word data_in;
> +	union mailbox_word data_out;
> +};
> +
> +static int print_mailbox_error(struct sbrmi_data *data)
> +{

Nit> Many functions only use data>client and, in some cases, dereference it
several times. It might be easier to just pass 'client'.

> +	int status;
> +
> +	/* Mailbox error code will be written by Firmware in
> +	 * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
> +	 */

/*
  * Please use standard multi-line comments. Applies to entire driver.
  */

> +	status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
> +	if (status < 0) {
> +		pr_err("SMBUS translation failed\n");
> +		return status;
> +	}
> +
> +	switch (status) {
> +	case 0x0:	/* Success */
> +		break;
> +	case 0x1:
> +		pr_err("Mailbox message command is aborted\n");
> +		break;
> +	case 0x2:
> +		pr_err("Unknown mailbox message\n");
> +		break;
> +	case 0x3:
> +		pr_err("Invalid core is specified in mailbox message parameters\n");
> +		break;
> +	default:
> +		pr_err("Unknown Error\n");
> +	}

Is this noise necessary ? I am concerned that, if it occurs, it would be persistent
and fill up the kernel log with noise.

> +
> +	return status;

Error codes are supposed to be negative and standard Linux error codes.
Please convert the above errors to standard Linux error codes.

> +}
> +
> +static int sbrmi_enable_alert(struct sbrmi_data *data)
> +{
> +	int ctrl;
> +
> +	/* Enable the SB-RMI Software alert status
> +	 * by writing 0 to bit 4 of Control register(0x1)
> +	 */
> +	ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
> +	if (ctrl < 0)
> +		return ctrl;
> +
> +	if (ctrl & 0x10) {
> +		ctrl &= ~0x10;
> +		return i2c_smbus_write_byte_data(data->client,
> +						 SBRMI_CTRL, ctrl);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +			    struct sbrmi_mailbox_msg *msg)
> +{
> +	union mailbox_word output, input;
> +	int i, err = 0, retry = 10;

Initializing 'err' is unnecessary.

> +	int sw_status;
> +
> +	mutex_lock(&data->lock);
> +
> +	err = sbrmi_enable_alert(data);
> +	if (err < 0)
> +		goto exit_unlock;
> +
> +	/* Indicate firmware a command is to be serviced */
> +	err = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG7, START_CMD);
> +	if (err < 0)
> +		goto exit_unlock;
> +
> +	/* Write the command to SBRMI::InBndMsg_inst0 */
> +	err = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG0, msg->cmd);
> +	if (err < 0)
> +		goto exit_mod;
> +
> +	/*
> +	 * For both read and write the initiator (BMC) writes
> +	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +	 */
> +	input = msg->data_in;
> +	for (i = 0; i < 3; i++) {

This writes 3 bytes. Is that on purpose ? If so please explain since the above
suggests that 4 bytes should be written.

> +		err = i2c_smbus_write_byte_data(data->client,
> +						(SBRMI_INBNDMSG1 + i),

Unnecessary ( )

> +						input.bytes[i]);
> +		if (err < 0)
> +			goto exit_mod;
> +	}
> +
> +	/*
> +	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +	 * perform the requested read or write command
> +	 */
> +	err = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +	if (err < 0)
> +		goto exit_mod;
> +
> +	/*
> +	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +	 * of the requested command
> +	 */
> +	do {
> +		sw_status = i2c_smbus_read_byte_data(data->client,
> +						     SBRMI_STATUS);
> +		if (sw_status < 0) {
> +			err = sw_status;
> +			goto exit_mod;
> +		}
> +		if (sw_status & SW_ALERT_MASK)
> +			break;
> +		usleep_range(50, 100);
> +	} while (retry--);
> +
> +	if (retry < 0) {
> +		pr_err("Firmware fail to indicate command colmpletion\n");

completion

> +		err = -1;
> +		goto exit_mod;
> +	}
> +
> +	/*
> +	 * For a read operation, the initiator (BMC) reads the firmware response
> +	 * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +	 */
> +	if (msg->read) {
> +		for (i = 0; i < 4; i++) {
> +			output.bytes[i] = i2c_smbus_read_byte_data(data->client,
> +								   (SBRMI_OUTBNDMSG1 + i));

Unnecessary ().

> +			if (output.bytes[i] < 0) {

output.bytes is defined as u8. This will not catch errors.

> +				err = output.bytes[i];
> +				goto exit_mod;
> +			}
> +		}
> +	}
> +	msg->data_out = output;
> +
> +	/*
> +	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +	 * ALERT to initiator
> +	 */
> +	err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +					(sw_status | SW_ALERT_MASK));

Unnecessary ().

> +
> +exit_mod:
> +	if (err < 0)
> +		pr_err("SMBUS translation failed\n");
> +	else
> +		err = print_mailbox_error(data);
> +exit_unlock:
> +	mutex_unlock(&data->lock);
> +	return err;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +		      u32 attr, int channel, long *val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	if (type != hwmon_power)
> +		return -EINVAL;
> +
> +	msg.read = true;
> +	switch (attr) {
> +	case hwmon_power_input:
> +		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap:
> +		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap_max:
> +		msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	/*
> +	 * hwmon power attributes are in microWatt
> +	 */
> +	*val = (long)msg.data_out.value * 1000;
> +	return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +		       u32 attr, int channel, long val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +
> +	if (type != hwmon_power && attr != hwmon_power_cap)
> +		return -EINVAL;
> +	/*
> +	 * hwmon power attributes are in microWatt
> +	 * mailbox read/write is in mWatt
> +	 */
> +	val /= 1000;
> +
> +	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +	msg.data_in.value = 0;
> +	msg.read = true;
> +	rmi_mailbox_xfer(data, &msg);
> +
> +	val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
> +
> +	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +	msg.data_in.value = val;
> +	msg.read = false;
> +
> +	return rmi_mailbox_xfer(data, &msg);
> +}
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +				enum hwmon_sensor_types type,
> +				u32 attr, int channel)
> +{
> +	switch (type) {
> +	case hwmon_power:
> +		switch (attr) {
> +		case hwmon_power_input:
> +		case hwmon_power_cap_max:
> +			return 0444;
> +		case hwmon_power_cap:
> +			return 0644;
> +		}
> +		break;
> +	default:
> +		break;
> +	}
> +	return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +	HWMON_CHANNEL_INFO(power,
> +			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +	NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +	.is_visible = sbrmi_is_visible,
> +	.read = sbrmi_read,
> +	.write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +	.ops = &sbrmi_hwmon_ops,
> +	.info = sbrmi_info,
> +};
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +		       const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct device *hwmon_dev;
> +	struct sbrmi_data *data;
> +
> +	if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> +		dev_err(&client->dev, "adapter does not support true I2C\n");

Why would that matter? It only uses SMBus functions.

> +		return -ENODEV;
> +	}
> +
> +	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->client = client;
> +	mutex_init(&data->lock);
> +
> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +							 &sbrmi_chip_info, NULL);
> +
> +	return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +	{"sbrmi", 0},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +	{
> +		.compatible = "amd,sbrmi",
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +	.class = I2C_CLASS_HWMON,
> +	.driver = {
> +		.name = "sbrmi",
> +		.of_match_table = of_match_ptr(sbrmi_of_match),
> +	},
> +	.probe = sbrmi_probe,
> +	.id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
> +MODULE_LICENSE("GPL");
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 2/3] hwmon: sbrmi: Add Documentation
  2021-06-25 13:25 ` [PATCH 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-06-28 15:01   ` Guenter Roeck
  0 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-06-28 15:01 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi; +Cc: linux-hwmon, Akshay Gupta

On Fri, Jun 25, 2021 at 06:55:43PM +0530, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> - Add documentation for sbrmi module
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
>  Documentation/hwmon/index.rst |  1 +
>  Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
>  2 files changed, 80 insertions(+)
>  create mode 100644 Documentation/hwmon/sbrmi.rst
> 
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 9ed60fa84cbe..5cd4798fe193 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
>     q54sj108a2
>     raspberrypi-hwmon
>     sbtsi_temp
> +   sbrmi
>     sch5627
>     sch5636
>     scpi-hwmon
> diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
> new file mode 100644
> index 000000000000..db50393167bb
> --- /dev/null
> +++ b/Documentation/hwmon/sbrmi.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +Kernel driver sbrmi
> +===================
> +
> +Supported hardware:
> +
> +  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
> +    device connected to the BMC via the APML.
> +
> +    Prefix: 'sbrmi'
> +
> +    Addresses scanned: This driver doesn't support address scanning.
> +
> +    To instantiate this driver on an AMD CPU with SB-RMI
> +    support, the i2c bus number would be the bus connected from the board
> +    management controller (BMC) to the CPU.
> +    The SMBus address is really 7 bits. Some vendors and the SMBus
> +    specification show the address as 8 bits, left justified with the R/W
> +    bit as a write (0) making bit 0. Some vendors use only the 7 bits
> +    to describe the address.
> +    As mentioned in AMD's APML specification, The SB-RMI address is
> +    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
> +    or 38h(011 1000) for socket 1, but it could vary based on hardware
> +    address select pins.
> +
> +    Datasheet: The SB-RMI interface and protocol along with the Advanced
> +               Platform Management Link (APML) Specification is available
> +               as part of the open source SoC register reference at:
> +
> +               https://www.amd.com/en/support/tech-docs?keyword=55898
> +
> +Author: Akshay Gupta <akshay.gupta@amd.com>
> +
> +Description
> +-----------
> +
> +The APML provides a way to communicate with the SB Remote Management interface
> +(SB-RMI) module from the external SMBus master that can be used to report socket
> +power on AMD platforms using mailbox command and resembles a typical 8-pin remote
> +power sensor's I2C interface to BMC.
> +
> +This driver implements current power with power cap and power cap max.
> +
> +sysfs-Interface
> +---------------
> +Power sensors can be queried and set via the standard ``hwmon`` interface
> +on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
> +of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
> +content ``sbrmi``)
> +
> +================ ===== ========================================================
> +Name             Perm   Description
> +================ ===== ========================================================
> +power#_input     RO    Current Power consumed
> +power#_cap       RW    Power limit can be set between 0 and power#_cap_max
> +power#_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW

'#' is always '1', so just say so.

> +================ ===== ========================================================
> +
> +The following example show how the 'Power' attribute from the i2c-addresses
> +can be monitored using the userspace utilities like ``sensors`` binary::
> +
> +  # sensors
> +  sbrmi-i2c-1-38
> +  Adapter: bcm2835 I2C adapter
> +  power1:       61.00 W (cap = 225.00 W)
> +
> +  sbrmi-i2c-1-3c
> +  Adapter: bcm2835 I2C adapter
> +  power1:       28.39 W (cap = 224.77 W)
> +  #
> +
> +Also, Below shows how get and set the values from sysfs entries individually::
> +  # cat /sys/class/hwmon/hwmon1/power1_cap_max
> +  225000000
> +
> +  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
> +  # cat /sys/class/hwmon/hwmon1/power1_cap
> +  180000000

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-28 14:58 ` [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
@ 2021-06-29 15:05   ` Chatradhi, Naveen Krishna
  2021-07-07 14:14     ` Chatradhi, Naveen Krishna
  0 siblings, 1 reply; 28+ messages in thread
From: Chatradhi, Naveen Krishna @ 2021-06-29 15:05 UTC (permalink / raw)
  To: Guenter Roeck, linux-hwmon; +Cc: Gupta, Akshay

[AMD Official Use Only]

Hi Guenter,

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Monday, June 28, 2021 8:29 PM
To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module

[CAUTION: External Email]

On 6/25/21 6:25 AM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
>
> On AMD platforms the Out-of-band access is provided by Advanced 
> Platform Management

This is a bit too long for checkpatch.

> Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
>
> APML is used to communicate with the Remote Management Interface 
> (SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox 
> messages to report power consumption and power limits of the CPU socket.
>
> - This module add support to read power consumption,
>    power limit & max power limit and write power limit.
> - To instantiate this driver on an AMD CPU with SB-RMI support,
>    the i2c bus number would be the bus connected from the board
>    management controller (BMC) to the CPU.
>

This is a bit vague. Would this driver be instantiated on the host CPU or on the BMC ?

> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
>   drivers/hwmon/Kconfig  |  10 ++
>   drivers/hwmon/Makefile |   1 +
>   drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 405 insertions(+)
>   create mode 100644 drivers/hwmon/sbrmi.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
> 87624902ea80..d1813ea8382c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>         This driver can also be built as a module. If so, the module will
>         be called sbtsi_temp.
>
> +config SENSORS_SBRMI
> +     tristate "Emulated SB-RMI sensor"
> +     depends on I2C
> +     help
> +       If you say yes here you get support for emulated RMI
> +       sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +       This driver can also be built as a module. If so, the module will
> +       be called sbrmi.
> +
>   config SENSORS_SHT15
>       tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>       depends on GPIOLIB || COMPILE_TEST diff --git 
> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 
> 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)     += raspberrypi-hwmon.o
>   obj-$(CONFIG_SENSORS_S3C)   += s3c-hwmon.o
>   obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>   obj-$(CONFIG_SENSORS_SCH5627)       += sch5627.o
>   obj-$(CONFIG_SENSORS_SCH5636)       += sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file 
> mode 100644 index 000000000000..c35829513459
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>

I don't immediately see why this include is needed.

> +#include <asm-generic/ioctl.h>

This looks wrong, and I don't immediately see why it would be needed.

> +#include <linux/delay.h>

Alphabetic include file order, please.

> +
> +/* Do not allow setting negative power limit */ #define SBRMI_PWR_MIN 
> +0
> +/* Mask for Status Register bit[1] */ #define SW_ALERT_MASK 0x2
> +

Please always use

#define<space>DEFINITION<tab>value
                         ^^^^^

> +/* Software Interrupt for triggering */
> +#define START_CMD    0x80
> +#define TRIGGER_MAILBOX      0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power 
> +management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +     SBRMI_WRITE_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +     SBRMI_CTRL              = 0x01,
> +     SBRMI_STATUS,
> +     SBRMI_OUTBNDMSG0        = 0x30,
> +     SBRMI_OUTBNDMSG1,
> +     SBRMI_OUTBNDMSG2,
> +     SBRMI_OUTBNDMSG3,
> +     SBRMI_OUTBNDMSG4,
> +     SBRMI_OUTBNDMSG5,
> +     SBRMI_OUTBNDMSG6,
> +     SBRMI_OUTBNDMSG7,
> +     SBRMI_INBNDMSG0,
> +     SBRMI_INBNDMSG1,
> +     SBRMI_INBNDMSG2,
> +     SBRMI_INBNDMSG3,
> +     SBRMI_INBNDMSG4,
> +     SBRMI_INBNDMSG5,
> +     SBRMI_INBNDMSG6,
> +     SBRMI_INBNDMSG7,
> +     SBRMI_SW_INTERRUPT,
> +};
> +
> +/*
> + * Each client has this additional data  */

Please be consistent with comments: This does not really need to be a multi-line comment. While that does not really matter, you use a single-line comment to describe the next structure. Please make it both either single-line or multi-line.

> +struct sbrmi_data {
> +     struct i2c_client *client;
> +     struct mutex lock;
> +};
> +
> +/* Mailbox message data format */
> +union mailbox_word {
> +     u8 bytes[4];
> +     u32 value;

That strongly suggests that the driver will only work on either little-endian or big-endian systems, depending on the byte order of transfers. Please restrict it accordingly.

> +};
> +
> +struct sbrmi_mailbox_msg {
> +     u8 cmd;
> +     bool read;
> +     union mailbox_word data_in;
> +     union mailbox_word data_out;
> +};
> +
> +static int print_mailbox_error(struct sbrmi_data *data) {

Nit> Many functions only use data>client and, in some cases, dereference 
Nit> it
several times. It might be easier to just pass 'client'.

> +     int status;
> +
> +     /* Mailbox error code will be written by Firmware in
> +      * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
> +      */

/*
  * Please use standard multi-line comments. Applies to entire driver.
  */

> +     status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
> +     if (status < 0) {
> +             pr_err("SMBUS translation failed\n");
> +             return status;
> +     }
> +
> +     switch (status) {
> +     case 0x0:       /* Success */
> +             break;
> +     case 0x1:
> +             pr_err("Mailbox message command is aborted\n");
> +             break;
> +     case 0x2:
> +             pr_err("Unknown mailbox message\n");
> +             break;
> +     case 0x3:
> +             pr_err("Invalid core is specified in mailbox message parameters\n");
> +             break;
> +     default:
> +             pr_err("Unknown Error\n");
> +     }

Is this noise necessary ? I am concerned that, if it occurs, it would be persistent and fill up the kernel log with noise.

> +
> +     return status;

Error codes are supposed to be negative and standard Linux error codes.
Please convert the above errors to standard Linux error codes.

> +}
> +
> +static int sbrmi_enable_alert(struct sbrmi_data *data) {
> +     int ctrl;
> +
> +     /* Enable the SB-RMI Software alert status
> +      * by writing 0 to bit 4 of Control register(0x1)
> +      */
> +     ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
> +     if (ctrl < 0)
> +             return ctrl;
> +
> +     if (ctrl & 0x10) {
> +             ctrl &= ~0x10;
> +             return i2c_smbus_write_byte_data(data->client,
> +                                              SBRMI_CTRL, ctrl);
> +     }
> +
> +     return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +                         struct sbrmi_mailbox_msg *msg) {
> +     union mailbox_word output, input;
> +     int i, err = 0, retry = 10;

Initializing 'err' is unnecessary.

> +     int sw_status;
> +
> +     mutex_lock(&data->lock);
> +
> +     err = sbrmi_enable_alert(data);
> +     if (err < 0)
> +             goto exit_unlock;
> +
> +     /* Indicate firmware a command is to be serviced */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG7, START_CMD);
> +     if (err < 0)
> +             goto exit_unlock;
> +
> +     /* Write the command to SBRMI::InBndMsg_inst0 */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG0, msg->cmd);
> +     if (err < 0)
> +             goto exit_mod;
> +
> +     /*
> +      * For both read and write the initiator (BMC) writes
> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +      */
> +     input = msg->data_in;
> +     for (i = 0; i < 3; i++) {

This writes 3 bytes. Is that on purpose ? If so please explain since the above suggests that 4 bytes should be written.

> +             err = i2c_smbus_write_byte_data(data->client,
> +                                             (SBRMI_INBNDMSG1 + i),

Unnecessary ( )

> +                                             input.bytes[i]);
> +             if (err < 0)
> +                     goto exit_mod;
> +     }
> +
> +     /*
> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +      * perform the requested read or write command
> +      */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +     if (err < 0)
> +             goto exit_mod;
> +
> +     /*
> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +      * of the requested command
> +      */
> +     do {
> +             sw_status = i2c_smbus_read_byte_data(data->client,
> +                                                  SBRMI_STATUS);
> +             if (sw_status < 0) {
> +                     err = sw_status;
> +                     goto exit_mod;
> +             }
> +             if (sw_status & SW_ALERT_MASK)
> +                     break;
> +             usleep_range(50, 100);
> +     } while (retry--);
> +
> +     if (retry < 0) {
> +             pr_err("Firmware fail to indicate command 
> + colmpletion\n");

completion

> +             err = -1;
> +             goto exit_mod;
> +     }
> +
> +     /*
> +      * For a read operation, the initiator (BMC) reads the firmware response
> +      * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +      */
> +     if (msg->read) {
> +             for (i = 0; i < 4; i++) {
> +                     output.bytes[i] = i2c_smbus_read_byte_data(data->client,
> +                                                                
> + (SBRMI_OUTBNDMSG1 + i));

Unnecessary ().

> +                     if (output.bytes[i] < 0) {

output.bytes is defined as u8. This will not catch errors.

> +                             err = output.bytes[i];
> +                             goto exit_mod;
> +                     }
> +             }
> +     }
> +     msg->data_out = output;
> +
> +     /*
> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +      * ALERT to initiator
> +      */
> +     err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +                                     (sw_status | SW_ALERT_MASK));

Unnecessary ().

> +
> +exit_mod:
> +     if (err < 0)
> +             pr_err("SMBUS translation failed\n");
> +     else
> +             err = print_mailbox_error(data);
> +exit_unlock:
> +     mutex_unlock(&data->lock);
> +     return err;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +                   u32 attr, int channel, long *val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +     int ret;
> +
> +     if (type != hwmon_power)
> +             return -EINVAL;
> +
> +     msg.read = true;
> +     switch (attr) {
> +     case hwmon_power_input:
> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap:
> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap_max:
> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +     /*
> +      * hwmon power attributes are in microWatt
> +      */
> +     *val = (long)msg.data_out.value * 1000;
> +     return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +                    u32 attr, int channel, long val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +
> +     if (type != hwmon_power && attr != hwmon_power_cap)
> +             return -EINVAL;
> +     /*
> +      * hwmon power attributes are in microWatt
> +      * mailbox read/write is in mWatt
> +      */
> +     val /= 1000;
> +
> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +     msg.data_in.value = 0;
> +     msg.read = true;
> +     rmi_mailbox_xfer(data, &msg);
> +
> +     val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
> +
> +     msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +     msg.data_in.value = val;
> +     msg.read = false;
> +
> +     return rmi_mailbox_xfer(data, &msg); }
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +                             enum hwmon_sensor_types type,
> +                             u32 attr, int channel) {
> +     switch (type) {
> +     case hwmon_power:
> +             switch (attr) {
> +             case hwmon_power_input:
> +             case hwmon_power_cap_max:
> +                     return 0444;
> +             case hwmon_power_cap:
> +                     return 0644;
> +             }
> +             break;
> +     default:
> +             break;
> +     }
> +     return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +     HWMON_CHANNEL_INFO(power,
> +                        HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +     NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +     .is_visible = sbrmi_is_visible,
> +     .read = sbrmi_read,
> +     .write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +     .ops = &sbrmi_hwmon_ops,
> +     .info = sbrmi_info,
> +};
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +                    const struct i2c_device_id *id) {
> +     struct device *dev = &client->dev;
> +     struct device *hwmon_dev;
> +     struct sbrmi_data *data;
> +
> +     if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> +             dev_err(&client->dev, "adapter does not support true 
> + I2C\n");

Why would that matter? It only uses SMBus functions.

> +             return -ENODEV;
> +     }
> +
> +     data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +     if (!data)
> +             return -ENOMEM;
> +
> +     data->client = client;
> +     mutex_init(&data->lock);
> +
> +     hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +                                                      
> + &sbrmi_chip_info, NULL);
> +
> +     return PTR_ERR_OR_ZERO(hwmon_dev); }
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +     {"sbrmi", 0},
> +     {}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +     {
> +             .compatible = "amd,sbrmi",
> +     },
> +     { },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +     .class = I2C_CLASS_HWMON,
> +     .driver = {
> +             .name = "sbrmi",
> +             .of_match_table = of_match_ptr(sbrmi_of_match),
> +     },
> +     .probe = sbrmi_probe,
> +     .id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>"); 
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor"); 
> +MODULE_LICENSE("GPL");
[naveenk:] Thank you for your comments, we will address your comments and submit v2 soon.
>
[naveenk:] 
Regards,
Naveenk

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-29 15:05   ` Chatradhi, Naveen Krishna
@ 2021-07-07 14:14     ` Chatradhi, Naveen Krishna
  2021-07-07 14:21       ` Guenter Roeck
  0 siblings, 1 reply; 28+ messages in thread
From: Chatradhi, Naveen Krishna @ 2021-07-07 14:14 UTC (permalink / raw)
  To: Chatradhi, Naveen Krishna, Guenter Roeck, linux-hwmon; +Cc: Gupta, Akshay

[Public]

Hi Guenter,

Couple of questions inline before we submit the next version. Could you answer them.

Regards,
Naveenk

-----Original Message-----
From: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com> 
Sent: Tuesday, June 29, 2021 8:36 PM
To: Guenter Roeck <linux@roeck-us.net>; linux-hwmon@vger.kernel.org
Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module

[CAUTION: External Email]

[AMD Official Use Only]

Hi Guenter,

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Monday, June 28, 2021 8:29 PM
To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module

[CAUTION: External Email]

On 6/25/21 6:25 AM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
>
> On AMD platforms the Out-of-band access is provided by Advanced 
> Platform Management

This is a bit too long for checkpatch.
[naveenk:] Sure

> Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
>
> APML is used to communicate with the Remote Management Interface 
> (SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox 
> messages to report power consumption and power limits of the CPU socket.
>
> - This module add support to read power consumption,
>    power limit & max power limit and write power limit.
> - To instantiate this driver on an AMD CPU with SB-RMI support,
>    the i2c bus number would be the bus connected from the board
>    management controller (BMC) to the CPU.
>

This is a bit vague. Would this driver be instantiated on the host CPU or on the BMC ?
[naveenk:] This driver is to be instantiated on a BMC connected to AMD CPU. Will correct the comment.

> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
>   drivers/hwmon/Kconfig  |  10 ++
>   drivers/hwmon/Makefile |   1 +
>   drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 405 insertions(+)
>   create mode 100644 drivers/hwmon/sbrmi.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
> 87624902ea80..d1813ea8382c 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>         This driver can also be built as a module. If so, the module will
>         be called sbtsi_temp.
>
> +config SENSORS_SBRMI
> +     tristate "Emulated SB-RMI sensor"
> +     depends on I2C
> +     help
> +       If you say yes here you get support for emulated RMI
> +       sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +       This driver can also be built as a module. If so, the module will
> +       be called sbrmi.
> +
>   config SENSORS_SHT15
>       tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>       depends on GPIOLIB || COMPILE_TEST diff --git 
> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index
> 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)     += raspberrypi-hwmon.o
>   obj-$(CONFIG_SENSORS_S3C)   += s3c-hwmon.o
>   obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>   obj-$(CONFIG_SENSORS_SCH5627)       += sch5627.o
>   obj-$(CONFIG_SENSORS_SCH5636)       += sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file 
> mode 100644 index 000000000000..c35829513459
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,394 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>

I don't immediately see why this include is needed.

> +#include <asm-generic/ioctl.h>

This looks wrong, and I don't immediately see why it would be needed.

> +#include <linux/delay.h>

Alphabetic include file order, please.
[naveenk:] Sure
> +
> +/* Do not allow setting negative power limit */ #define SBRMI_PWR_MIN
> +0
> +/* Mask for Status Register bit[1] */ #define SW_ALERT_MASK 0x2
> +

Please always use

#define<space>DEFINITION<tab>value
                         ^^^^^

> +/* Software Interrupt for triggering */
> +#define START_CMD    0x80
> +#define TRIGGER_MAILBOX      0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power 
> +management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +     SBRMI_WRITE_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +     SBRMI_CTRL              = 0x01,
> +     SBRMI_STATUS,
> +     SBRMI_OUTBNDMSG0        = 0x30,
> +     SBRMI_OUTBNDMSG1,
> +     SBRMI_OUTBNDMSG2,
> +     SBRMI_OUTBNDMSG3,
> +     SBRMI_OUTBNDMSG4,
> +     SBRMI_OUTBNDMSG5,
> +     SBRMI_OUTBNDMSG6,
> +     SBRMI_OUTBNDMSG7,
> +     SBRMI_INBNDMSG0,
> +     SBRMI_INBNDMSG1,
> +     SBRMI_INBNDMSG2,
> +     SBRMI_INBNDMSG3,
> +     SBRMI_INBNDMSG4,
> +     SBRMI_INBNDMSG5,
> +     SBRMI_INBNDMSG6,
> +     SBRMI_INBNDMSG7,
> +     SBRMI_SW_INTERRUPT,
> +};
> +
> +/*
> + * Each client has this additional data  */

Please be consistent with comments: This does not really need to be a multi-line comment. While that does not really matter, you use a single-line comment to describe the next structure. Please make it both either single-line or multi-line.

> +struct sbrmi_data {
> +     struct i2c_client *client;
> +     struct mutex lock;
> +};
> +
> +/* Mailbox message data format */
> +union mailbox_word {
> +     u8 bytes[4];
> +     u32 value;

That strongly suggests that the driver will only work on either little-endian or big-endian systems, depending on the byte order of transfers. Please restrict it accordingly.

> +};
> +
> +struct sbrmi_mailbox_msg {
> +     u8 cmd;
> +     bool read;
> +     union mailbox_word data_in;
> +     union mailbox_word data_out;
> +};
> +
> +static int print_mailbox_error(struct sbrmi_data *data) {

Nit> Many functions only use data>client and, in some cases, dereference 
Nit> it
several times. It might be easier to just pass 'client'.
[naveenk:] Sure

> +     int status;
> +
> +     /* Mailbox error code will be written by Firmware in
> +      * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
> +      */

/*
  * Please use standard multi-line comments. Applies to entire driver.
  */
[naveenk:] Sure

> +     status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
> +     if (status < 0) {
> +             pr_err("SMBUS translation failed\n");
> +             return status;
> +     }
> +
> +     switch (status) {
> +     case 0x0:       /* Success */
> +             break;
> +     case 0x1:
> +             pr_err("Mailbox message command is aborted\n");
> +             break;
> +     case 0x2:
> +             pr_err("Unknown mailbox message\n");
> +             break;
> +     case 0x3:
> +             pr_err("Invalid core is specified in mailbox message parameters\n");
> +             break;
> +     default:
> +             pr_err("Unknown Error\n");
> +     }

Is this noise necessary ? I am concerned that, if it occurs, it would be persistent and fill up the kernel log with noise.
[naveenk:] These are firmware defined error codes, can we change them to pr_debug and keep them ?

> +
> +     return status;

Error codes are supposed to be negative and standard Linux error codes.
Please convert the above errors to standard Linux error codes.

> +}
> +
> +static int sbrmi_enable_alert(struct sbrmi_data *data) {
> +     int ctrl;
> +
> +     /* Enable the SB-RMI Software alert status
> +      * by writing 0 to bit 4 of Control register(0x1)
> +      */
> +     ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
> +     if (ctrl < 0)
> +             return ctrl;
> +
> +     if (ctrl & 0x10) {
> +             ctrl &= ~0x10;
> +             return i2c_smbus_write_byte_data(data->client,
> +                                              SBRMI_CTRL, ctrl);
> +     }
> +
> +     return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +                         struct sbrmi_mailbox_msg *msg) {
> +     union mailbox_word output, input;
> +     int i, err = 0, retry = 10;

Initializing 'err' is unnecessary.

> +     int sw_status;
> +
> +     mutex_lock(&data->lock);
> +
> +     err = sbrmi_enable_alert(data);
> +     if (err < 0)
> +             goto exit_unlock;
> +
> +     /* Indicate firmware a command is to be serviced */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG7, START_CMD);
> +     if (err < 0)
> +             goto exit_unlock;
> +
> +     /* Write the command to SBRMI::InBndMsg_inst0 */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG0, msg->cmd);
> +     if (err < 0)
> +             goto exit_mod;
> +
> +     /*
> +      * For both read and write the initiator (BMC) writes
> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +      */
> +     input = msg->data_in;
> +     for (i = 0; i < 3; i++) {

This writes 3 bytes. Is that on purpose ? If so please explain since the above suggests that 4 bytes should be written.
[naveenk:] this was a mistake, it has to be 4. 

> +             err = i2c_smbus_write_byte_data(data->client,
> +                                             (SBRMI_INBNDMSG1 + i),

Unnecessary ( )

> +                                             input.bytes[i]);
> +             if (err < 0)
> +                     goto exit_mod;
> +     }
> +
> +     /*
> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +      * perform the requested read or write command
> +      */
> +     err = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +     if (err < 0)
> +             goto exit_mod;
> +
> +     /*
> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +      * of the requested command
> +      */
> +     do {
> +             sw_status = i2c_smbus_read_byte_data(data->client,
> +                                                  SBRMI_STATUS);
> +             if (sw_status < 0) {
> +                     err = sw_status;
> +                     goto exit_mod;
> +             }
> +             if (sw_status & SW_ALERT_MASK)
> +                     break;
> +             usleep_range(50, 100);
> +     } while (retry--);
> +
> +     if (retry < 0) {
> +             pr_err("Firmware fail to indicate command 
> + colmpletion\n");

completion

> +             err = -1;
> +             goto exit_mod;
> +     }
> +
> +     /*
> +      * For a read operation, the initiator (BMC) reads the firmware response
> +      * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +      */
> +     if (msg->read) {
> +             for (i = 0; i < 4; i++) {
> +                     output.bytes[i] = 
> + i2c_smbus_read_byte_data(data->client,
> +
> + (SBRMI_OUTBNDMSG1 + i));

Unnecessary ().

> +                     if (output.bytes[i] < 0) {

output.bytes is defined as u8. This will not catch errors.

> +                             err = output.bytes[i];
> +                             goto exit_mod;
> +                     }
> +             }
> +     }
> +     msg->data_out = output;
> +
> +     /*
> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +      * ALERT to initiator
> +      */
> +     err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +                                     (sw_status | SW_ALERT_MASK));

Unnecessary ().

> +
> +exit_mod:
> +     if (err < 0)
> +             pr_err("SMBUS translation failed\n");
> +     else
> +             err = print_mailbox_error(data);
> +exit_unlock:
> +     mutex_unlock(&data->lock);
> +     return err;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +                   u32 attr, int channel, long *val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +     int ret;
> +
> +     if (type != hwmon_power)
> +             return -EINVAL;
> +
> +     msg.read = true;
> +     switch (attr) {
> +     case hwmon_power_input:
> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap:
> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap_max:
> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +     /*
> +      * hwmon power attributes are in microWatt
> +      */
> +     *val = (long)msg.data_out.value * 1000;
> +     return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +                    u32 attr, int channel, long val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +
> +     if (type != hwmon_power && attr != hwmon_power_cap)
> +             return -EINVAL;
> +     /*
> +      * hwmon power attributes are in microWatt
> +      * mailbox read/write is in mWatt
> +      */
> +     val /= 1000;
> +
> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +     msg.data_in.value = 0;
> +     msg.read = true;
> +     rmi_mailbox_xfer(data, &msg);
> +
> +     val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
> +
> +     msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +     msg.data_in.value = val;
> +     msg.read = false;
> +
> +     return rmi_mailbox_xfer(data, &msg); }
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +                             enum hwmon_sensor_types type,
> +                             u32 attr, int channel) {
> +     switch (type) {
> +     case hwmon_power:
> +             switch (attr) {
> +             case hwmon_power_input:
> +             case hwmon_power_cap_max:
> +                     return 0444;
> +             case hwmon_power_cap:
> +                     return 0644;
> +             }
> +             break;
> +     default:
> +             break;
> +     }
> +     return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +     HWMON_CHANNEL_INFO(power,
> +                        HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +     NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +     .is_visible = sbrmi_is_visible,
> +     .read = sbrmi_read,
> +     .write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +     .ops = &sbrmi_hwmon_ops,
> +     .info = sbrmi_info,
> +};
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +                    const struct i2c_device_id *id) {
> +     struct device *dev = &client->dev;
> +     struct device *hwmon_dev;
> +     struct sbrmi_data *data;
> +
> +     if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
> +             dev_err(&client->dev, "adapter does not support true 
> + I2C\n");

Why would that matter? It only uses SMBus functions.
[naveenk:] yes, will remove this.

> +             return -ENODEV;
> +     }
> +
> +     data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +     if (!data)
> +             return -ENOMEM;
> +
> +     data->client = client;
> +     mutex_init(&data->lock);
> +
> +     hwmon_dev = devm_hwmon_device_register_with_info(dev, 
> + client->name, data,
> +
> + &sbrmi_chip_info, NULL);
> +
> +     return PTR_ERR_OR_ZERO(hwmon_dev); }
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +     {"sbrmi", 0},
> +     {}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +     {
> +             .compatible = "amd,sbrmi",
> +     },
> +     { },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +     .class = I2C_CLASS_HWMON,
> +     .driver = {
> +             .name = "sbrmi",
> +             .of_match_table = of_match_ptr(sbrmi_of_match),
> +     },
> +     .probe = sbrmi_probe,
> +     .id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>"); 
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor"); 
> +MODULE_LICENSE("GPL");
[naveenk:] Thank you for your comments, we will address your comments and submit v2 soon.
>
[naveenk:]
Regards,
Naveenk

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-07 14:14     ` Chatradhi, Naveen Krishna
@ 2021-07-07 14:21       ` Guenter Roeck
  2021-07-07 15:58         ` Chatradhi, Naveen Krishna
  0 siblings, 1 reply; 28+ messages in thread
From: Guenter Roeck @ 2021-07-07 14:21 UTC (permalink / raw)
  To: Chatradhi, Naveen Krishna, linux-hwmon; +Cc: Gupta, Akshay

On 7/7/21 7:14 AM, Chatradhi, Naveen Krishna wrote:
> [Public]
> 
> Hi Guenter,
> 
> Couple of questions inline before we submit the next version. Could you answer them.
> 
> Regards,
> Naveenk
> 
> -----Original Message-----
> From: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>
> Sent: Tuesday, June 29, 2021 8:36 PM
> To: Guenter Roeck <linux@roeck-us.net>; linux-hwmon@vger.kernel.org
> Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
> 
> [CAUTION: External Email]
> 
> [AMD Official Use Only]
> 
> Hi Guenter,
> 
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Monday, June 28, 2021 8:29 PM
> To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
> Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
> 
> [CAUTION: External Email]
> 
> On 6/25/21 6:25 AM, Naveen Krishna Chatradhi wrote:
>> From: Akshay Gupta <Akshay.Gupta@amd.com>
>>
>> On AMD platforms the Out-of-band access is provided by Advanced
>> Platform Management
> 
> This is a bit too long for checkpatch.
> [naveenk:] Sure
> 
>> Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
>> APML is also referred as the sideband interface (SBI).
>>
>> APML is used to communicate with the Remote Management Interface
>> (SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox
>> messages to report power consumption and power limits of the CPU socket.
>>
>> - This module add support to read power consumption,
>>     power limit & max power limit and write power limit.
>> - To instantiate this driver on an AMD CPU with SB-RMI support,
>>     the i2c bus number would be the bus connected from the board
>>     management controller (BMC) to the CPU.
>>
> 
> This is a bit vague. Would this driver be instantiated on the host CPU or on the BMC ?
> [naveenk:] This driver is to be instantiated on a BMC connected to AMD CPU. Will correct the comment.
> 
>> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
>> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
>> ---
>>    drivers/hwmon/Kconfig  |  10 ++
>>    drivers/hwmon/Makefile |   1 +
>>    drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
>>    3 files changed, 405 insertions(+)
>>    create mode 100644 drivers/hwmon/sbrmi.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index
>> 87624902ea80..d1813ea8382c 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>>          This driver can also be built as a module. If so, the module will
>>          be called sbtsi_temp.
>>
>> +config SENSORS_SBRMI
>> +     tristate "Emulated SB-RMI sensor"
>> +     depends on I2C
>> +     help
>> +       If you say yes here you get support for emulated RMI
>> +       sensors on AMD SoCs with APML interface connected to a BMC device.
>> +
>> +       This driver can also be built as a module. If so, the module will
>> +       be called sbrmi.
>> +
>>    config SENSORS_SHT15
>>        tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>>        depends on GPIOLIB || COMPILE_TEST diff --git
>> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index
>> 59e78bc212cf..8031acf58936 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>>    obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)     += raspberrypi-hwmon.o
>>    obj-$(CONFIG_SENSORS_S3C)   += s3c-hwmon.o
>>    obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
>> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>>    obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>>    obj-$(CONFIG_SENSORS_SCH5627)       += sch5627.o
>>    obj-$(CONFIG_SENSORS_SCH5636)       += sch5636.o
>> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file
>> mode 100644 index 000000000000..c35829513459
>> --- /dev/null
>> +++ b/drivers/hwmon/sbrmi.c
>> @@ -0,0 +1,394 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
>> + *           compliant AMD SoC device.
>> + *
>> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/i2c.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
> 
> I don't immediately see why this include is needed.
> 
>> +#include <asm-generic/ioctl.h>
> 
> This looks wrong, and I don't immediately see why it would be needed.
> 
>> +#include <linux/delay.h>
> 
> Alphabetic include file order, please.
> [naveenk:] Sure
>> +
>> +/* Do not allow setting negative power limit */ #define SBRMI_PWR_MIN
>> +0
>> +/* Mask for Status Register bit[1] */ #define SW_ALERT_MASK 0x2
>> +
> 
> Please always use
> 
> #define<space>DEFINITION<tab>value
>                           ^^^^^
> 
>> +/* Software Interrupt for triggering */
>> +#define START_CMD    0x80
>> +#define TRIGGER_MAILBOX      0x01
>> +
>> +/*
>> + * SB-RMI supports soft mailbox service request to MP1 (power
>> +management
>> + * firmware) through SBRMI inbound/outbound message registers.
>> + * SB-RMI message IDs
>> + */
>> +enum sbrmi_msg_id {
>> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
>> +     SBRMI_WRITE_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
>> +};
>> +
>> +/* SB-RMI registers */
>> +enum sbrmi_reg {
>> +     SBRMI_CTRL              = 0x01,
>> +     SBRMI_STATUS,
>> +     SBRMI_OUTBNDMSG0        = 0x30,
>> +     SBRMI_OUTBNDMSG1,
>> +     SBRMI_OUTBNDMSG2,
>> +     SBRMI_OUTBNDMSG3,
>> +     SBRMI_OUTBNDMSG4,
>> +     SBRMI_OUTBNDMSG5,
>> +     SBRMI_OUTBNDMSG6,
>> +     SBRMI_OUTBNDMSG7,
>> +     SBRMI_INBNDMSG0,
>> +     SBRMI_INBNDMSG1,
>> +     SBRMI_INBNDMSG2,
>> +     SBRMI_INBNDMSG3,
>> +     SBRMI_INBNDMSG4,
>> +     SBRMI_INBNDMSG5,
>> +     SBRMI_INBNDMSG6,
>> +     SBRMI_INBNDMSG7,
>> +     SBRMI_SW_INTERRUPT,
>> +};
>> +
>> +/*
>> + * Each client has this additional data  */
> 
> Please be consistent with comments: This does not really need to be a multi-line comment. While that does not really matter, you use a single-line comment to describe the next structure. Please make it both either single-line or multi-line.
> 
>> +struct sbrmi_data {
>> +     struct i2c_client *client;
>> +     struct mutex lock;
>> +};
>> +
>> +/* Mailbox message data format */
>> +union mailbox_word {
>> +     u8 bytes[4];
>> +     u32 value;
> 
> That strongly suggests that the driver will only work on either little-endian or big-endian systems, depending on the byte order of transfers. Please restrict it accordingly.
> 
>> +};
>> +
>> +struct sbrmi_mailbox_msg {
>> +     u8 cmd;
>> +     bool read;
>> +     union mailbox_word data_in;
>> +     union mailbox_word data_out;
>> +};
>> +
>> +static int print_mailbox_error(struct sbrmi_data *data) {
> 
> Nit> Many functions only use data>client and, in some cases, dereference
> Nit> it
> several times. It might be easier to just pass 'client'.
> [naveenk:] Sure
> 
>> +     int status;
>> +
>> +     /* Mailbox error code will be written by Firmware in
>> +      * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
>> +      */
> 
> /*
>    * Please use standard multi-line comments. Applies to entire driver.
>    */
> [naveenk:] Sure
> 
>> +     status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
>> +     if (status < 0) {
>> +             pr_err("SMBUS translation failed\n");
>> +             return status;
>> +     }
>> +
>> +     switch (status) {
>> +     case 0x0:       /* Success */
>> +             break;
>> +     case 0x1:
>> +             pr_err("Mailbox message command is aborted\n");
>> +             break;
>> +     case 0x2:
>> +             pr_err("Unknown mailbox message\n");
>> +             break;
>> +     case 0x3:
>> +             pr_err("Invalid core is specified in mailbox message parameters\n");
>> +             break;
>> +     default:
>> +             pr_err("Unknown Error\n");
>> +     }
> 
> Is this noise necessary ? I am concerned that, if it occurs, it would be persistent and fill up the kernel log with noise.
> [naveenk:] These are firmware defined error codes, can we change them to pr_debug and keep them ?
> 

pr_debug is ok, but ...

>> +
>> +     return status;
> 
> Error codes are supposed to be negative and standard Linux error codes.
> Please convert the above errors to standard Linux error codes.
> 
you'll still need to convert the error codes to standard
error codes.

This is the only question I found. Please let me know if I missed something.

Thanks,
Guenter

>> +}
>> +
>> +static int sbrmi_enable_alert(struct sbrmi_data *data) {
>> +     int ctrl;
>> +
>> +     /* Enable the SB-RMI Software alert status
>> +      * by writing 0 to bit 4 of Control register(0x1)
>> +      */
>> +     ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
>> +     if (ctrl < 0)
>> +             return ctrl;
>> +
>> +     if (ctrl & 0x10) {
>> +             ctrl &= ~0x10;
>> +             return i2c_smbus_write_byte_data(data->client,
>> +                                              SBRMI_CTRL, ctrl);
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
>> +                         struct sbrmi_mailbox_msg *msg) {
>> +     union mailbox_word output, input;
>> +     int i, err = 0, retry = 10;
> 
> Initializing 'err' is unnecessary.
> 
>> +     int sw_status;
>> +
>> +     mutex_lock(&data->lock);
>> +
>> +     err = sbrmi_enable_alert(data);
>> +     if (err < 0)
>> +             goto exit_unlock;
>> +
>> +     /* Indicate firmware a command is to be serviced */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG7, START_CMD);
>> +     if (err < 0)
>> +             goto exit_unlock;
>> +
>> +     /* Write the command to SBRMI::InBndMsg_inst0 */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG0, msg->cmd);
>> +     if (err < 0)
>> +             goto exit_mod;
>> +
>> +     /*
>> +      * For both read and write the initiator (BMC) writes
>> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
>> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
>> +      */
>> +     input = msg->data_in;
>> +     for (i = 0; i < 3; i++) {
> 
> This writes 3 bytes. Is that on purpose ? If so please explain since the above suggests that 4 bytes should be written.
> [naveenk:] this was a mistake, it has to be 4.
> 
>> +             err = i2c_smbus_write_byte_data(data->client,
>> +                                             (SBRMI_INBNDMSG1 + i),
> 
> Unnecessary ( )
> 
>> +                                             input.bytes[i]);
>> +             if (err < 0)
>> +                     goto exit_mod;
>> +     }
>> +
>> +     /*
>> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
>> +      * perform the requested read or write command
>> +      */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
>> +     if (err < 0)
>> +             goto exit_mod;
>> +
>> +     /*
>> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
>> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
>> +      * of the requested command
>> +      */
>> +     do {
>> +             sw_status = i2c_smbus_read_byte_data(data->client,
>> +                                                  SBRMI_STATUS);
>> +             if (sw_status < 0) {
>> +                     err = sw_status;
>> +                     goto exit_mod;
>> +             }
>> +             if (sw_status & SW_ALERT_MASK)
>> +                     break;
>> +             usleep_range(50, 100);
>> +     } while (retry--);
>> +
>> +     if (retry < 0) {
>> +             pr_err("Firmware fail to indicate command
>> + colmpletion\n");
> 
> completion
> 
>> +             err = -1;
>> +             goto exit_mod;
>> +     }
>> +
>> +     /*
>> +      * For a read operation, the initiator (BMC) reads the firmware response
>> +      * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
>> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
>> +      */
>> +     if (msg->read) {
>> +             for (i = 0; i < 4; i++) {
>> +                     output.bytes[i] =
>> + i2c_smbus_read_byte_data(data->client,
>> +
>> + (SBRMI_OUTBNDMSG1 + i));
> 
> Unnecessary ().
> 
>> +                     if (output.bytes[i] < 0) {
> 
> output.bytes is defined as u8. This will not catch errors.
> 
>> +                             err = output.bytes[i];
>> +                             goto exit_mod;
>> +                     }
>> +             }
>> +     }
>> +     msg->data_out = output;
>> +
>> +     /*
>> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
>> +      * ALERT to initiator
>> +      */
>> +     err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
>> +                                     (sw_status | SW_ALERT_MASK));
> 
> Unnecessary ().
> 
>> +
>> +exit_mod:
>> +     if (err < 0)
>> +             pr_err("SMBUS translation failed\n");
>> +     else
>> +             err = print_mailbox_error(data);
>> +exit_unlock:
>> +     mutex_unlock(&data->lock);
>> +     return err;
>> +}
>> +
>> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
>> +                   u32 attr, int channel, long *val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +     int ret;
>> +
>> +     if (type != hwmon_power)
>> +             return -EINVAL;
>> +
>> +     msg.read = true;
>> +     switch (attr) {
>> +     case hwmon_power_input:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap_max:
>> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +     /*
>> +      * hwmon power attributes are in microWatt
>> +      */
>> +     *val = (long)msg.data_out.value * 1000;
>> +     return ret;
>> +}
>> +
>> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
>> +                    u32 attr, int channel, long val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +
>> +     if (type != hwmon_power && attr != hwmon_power_cap)
>> +             return -EINVAL;
>> +     /*
>> +      * hwmon power attributes are in microWatt
>> +      * mailbox read/write is in mWatt
>> +      */
>> +     val /= 1000;
>> +
>> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +     msg.data_in.value = 0;
>> +     msg.read = true;
>> +     rmi_mailbox_xfer(data, &msg);
>> +
>> +     val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
>> +
>> +     msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
>> +     msg.data_in.value = val;
>> +     msg.read = false;
>> +
>> +     return rmi_mailbox_xfer(data, &msg); }
>> +
>> +static umode_t sbrmi_is_visible(const void *data,
>> +                             enum hwmon_sensor_types type,
>> +                             u32 attr, int channel) {
>> +     switch (type) {
>> +     case hwmon_power:
>> +             switch (attr) {
>> +             case hwmon_power_input:
>> +             case hwmon_power_cap_max:
>> +                     return 0444;
>> +             case hwmon_power_cap:
>> +                     return 0644;
>> +             }
>> +             break;
>> +     default:
>> +             break;
>> +     }
>> +     return 0;
>> +}
>> +
>> +static const struct hwmon_channel_info *sbrmi_info[] = {
>> +     HWMON_CHANNEL_INFO(power,
>> +                        HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
>> +     NULL
>> +};
>> +
>> +static const struct hwmon_ops sbrmi_hwmon_ops = {
>> +     .is_visible = sbrmi_is_visible,
>> +     .read = sbrmi_read,
>> +     .write = sbrmi_write,
>> +};
>> +
>> +static const struct hwmon_chip_info sbrmi_chip_info = {
>> +     .ops = &sbrmi_hwmon_ops,
>> +     .info = sbrmi_info,
>> +};
>> +
>> +static int sbrmi_probe(struct i2c_client *client,
>> +                    const struct i2c_device_id *id) {
>> +     struct device *dev = &client->dev;
>> +     struct device *hwmon_dev;
>> +     struct sbrmi_data *data;
>> +
>> +     if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
>> +             dev_err(&client->dev, "adapter does not support true
>> + I2C\n");
> 
> Why would that matter? It only uses SMBus functions.
> [naveenk:] yes, will remove this.
> 
>> +             return -ENODEV;
>> +     }
>> +
>> +     data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
>> +     if (!data)
>> +             return -ENOMEM;
>> +
>> +     data->client = client;
>> +     mutex_init(&data->lock);
>> +
>> +     hwmon_dev = devm_hwmon_device_register_with_info(dev,
>> + client->name, data,
>> +
>> + &sbrmi_chip_info, NULL);
>> +
>> +     return PTR_ERR_OR_ZERO(hwmon_dev); }
>> +
>> +static const struct i2c_device_id sbrmi_id[] = {
>> +     {"sbrmi", 0},
>> +     {}
>> +};
>> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
>> +
>> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
>> +     {
>> +             .compatible = "amd,sbrmi",
>> +     },
>> +     { },
>> +};
>> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
>> +
>> +static struct i2c_driver sbrmi_driver = {
>> +     .class = I2C_CLASS_HWMON,
>> +     .driver = {
>> +             .name = "sbrmi",
>> +             .of_match_table = of_match_ptr(sbrmi_of_match),
>> +     },
>> +     .probe = sbrmi_probe,
>> +     .id_table = sbrmi_id,
>> +};
>> +
>> +module_i2c_driver(sbrmi_driver);
>> +
>> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
>> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
>> +MODULE_LICENSE("GPL");
> [naveenk:] Thank you for your comments, we will address your comments and submit v2 soon.
>>
> [naveenk:]
> Regards,
> Naveenk
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-07 14:21       ` Guenter Roeck
@ 2021-07-07 15:58         ` Chatradhi, Naveen Krishna
  0 siblings, 0 replies; 28+ messages in thread
From: Chatradhi, Naveen Krishna @ 2021-07-07 15:58 UTC (permalink / raw)
  To: Guenter Roeck, linux-hwmon; +Cc: Gupta, Akshay

[Public]

Hi Guenter

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Wednesday, July 7, 2021 7:52 PM
To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module

[CAUTION: External Email]

On 7/7/21 7:14 AM, Chatradhi, Naveen Krishna wrote:
> [Public]
>
> Hi Guenter,
>
> Couple of questions inline before we submit the next version. Could you answer them.
[naveenk:] Yes, that was the one. Submitting the next version. Thank you.
>
> Regards,
> Naveenk
>
> -----Original Message-----
> From: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>
> Sent: Tuesday, June 29, 2021 8:36 PM
> To: Guenter Roeck <linux@roeck-us.net>; linux-hwmon@vger.kernel.org
> Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: RE: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power 
> module
>
> [CAUTION: External Email]
>
> [AMD Official Use Only]
>
> Hi Guenter,
>
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Monday, June 28, 2021 8:29 PM
> To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; 
> linux-hwmon@vger.kernel.org
> Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: Re: [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power 
> module
>
> [CAUTION: External Email]
>
> On 6/25/21 6:25 AM, Naveen Krishna Chatradhi wrote:
>> From: Akshay Gupta <Akshay.Gupta@amd.com>
>>
>> On AMD platforms the Out-of-band access is provided by Advanced 
>> Platform Management
>
> This is a bit too long for checkpatch.
> [naveenk:] Sure
>
>> Link (APML), APML is a SMBus v2.0 compatible 2-wire processor client interface.
>> APML is also referred as the sideband interface (SBI).
>>
>> APML is used to communicate with the Remote Management Interface 
>> (SB-Remote Management Interface (SB-RMI) which provides Soft Mailbox 
>> messages to report power consumption and power limits of the CPU socket.
>>
>> - This module add support to read power consumption,
>>     power limit & max power limit and write power limit.
>> - To instantiate this driver on an AMD CPU with SB-RMI support,
>>     the i2c bus number would be the bus connected from the board
>>     management controller (BMC) to the CPU.
>>
>
> This is a bit vague. Would this driver be instantiated on the host CPU or on the BMC ?
> [naveenk:] This driver is to be instantiated on a BMC connected to AMD CPU. Will correct the comment.
>
>> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
>> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
>> ---
>>    drivers/hwmon/Kconfig  |  10 ++
>>    drivers/hwmon/Makefile |   1 +
>>    drivers/hwmon/sbrmi.c  | 394 +++++++++++++++++++++++++++++++++++++++++
>>    3 files changed, 405 insertions(+)
>>    create mode 100644 drivers/hwmon/sbrmi.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
>> 87624902ea80..d1813ea8382c 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>>          This driver can also be built as a module. If so, the module will
>>          be called sbtsi_temp.
>>
>> +config SENSORS_SBRMI
>> +     tristate "Emulated SB-RMI sensor"
>> +     depends on I2C
>> +     help
>> +       If you say yes here you get support for emulated RMI
>> +       sensors on AMD SoCs with APML interface connected to a BMC device.
>> +
>> +       This driver can also be built as a module. If so, the module will
>> +       be called sbrmi.
>> +
>>    config SENSORS_SHT15
>>        tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>>        depends on GPIOLIB || COMPILE_TEST diff --git 
>> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index
>> 59e78bc212cf..8031acf58936 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>>    obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)     += raspberrypi-hwmon.o
>>    obj-$(CONFIG_SENSORS_S3C)   += s3c-hwmon.o
>>    obj-$(CONFIG_SENSORS_SBTSI) += sbtsi_temp.o
>> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>>    obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>>    obj-$(CONFIG_SENSORS_SCH5627)       += sch5627.o
>>    obj-$(CONFIG_SENSORS_SCH5636)       += sch5636.o
>> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file 
>> mode 100644 index 000000000000..c35829513459
>> --- /dev/null
>> +++ b/drivers/hwmon/sbrmi.c
>> @@ -0,0 +1,394 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
>> + *           compliant AMD SoC device.
>> + *
>> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/i2c.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>
> I don't immediately see why this include is needed.
>
>> +#include <asm-generic/ioctl.h>
>
> This looks wrong, and I don't immediately see why it would be needed.
>
>> +#include <linux/delay.h>
>
> Alphabetic include file order, please.
> [naveenk:] Sure
>> +
>> +/* Do not allow setting negative power limit */ #define 
>> +SBRMI_PWR_MIN
>> +0
>> +/* Mask for Status Register bit[1] */ #define SW_ALERT_MASK 0x2
>> +
>
> Please always use
>
> #define<space>DEFINITION<tab>value
>                           ^^^^^
>
>> +/* Software Interrupt for triggering */
>> +#define START_CMD    0x80
>> +#define TRIGGER_MAILBOX      0x01
>> +
>> +/*
>> + * SB-RMI supports soft mailbox service request to MP1 (power 
>> +management
>> + * firmware) through SBRMI inbound/outbound message registers.
>> + * SB-RMI message IDs
>> + */
>> +enum sbrmi_msg_id {
>> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
>> +     SBRMI_WRITE_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
>> +};
>> +
>> +/* SB-RMI registers */
>> +enum sbrmi_reg {
>> +     SBRMI_CTRL              = 0x01,
>> +     SBRMI_STATUS,
>> +     SBRMI_OUTBNDMSG0        = 0x30,
>> +     SBRMI_OUTBNDMSG1,
>> +     SBRMI_OUTBNDMSG2,
>> +     SBRMI_OUTBNDMSG3,
>> +     SBRMI_OUTBNDMSG4,
>> +     SBRMI_OUTBNDMSG5,
>> +     SBRMI_OUTBNDMSG6,
>> +     SBRMI_OUTBNDMSG7,
>> +     SBRMI_INBNDMSG0,
>> +     SBRMI_INBNDMSG1,
>> +     SBRMI_INBNDMSG2,
>> +     SBRMI_INBNDMSG3,
>> +     SBRMI_INBNDMSG4,
>> +     SBRMI_INBNDMSG5,
>> +     SBRMI_INBNDMSG6,
>> +     SBRMI_INBNDMSG7,
>> +     SBRMI_SW_INTERRUPT,
>> +};
>> +
>> +/*
>> + * Each client has this additional data  */
>
> Please be consistent with comments: This does not really need to be a multi-line comment. While that does not really matter, you use a single-line comment to describe the next structure. Please make it both either single-line or multi-line.
>
>> +struct sbrmi_data {
>> +     struct i2c_client *client;
>> +     struct mutex lock;
>> +};
>> +
>> +/* Mailbox message data format */
>> +union mailbox_word {
>> +     u8 bytes[4];
>> +     u32 value;
>
> That strongly suggests that the driver will only work on either little-endian or big-endian systems, depending on the byte order of transfers. Please restrict it accordingly.
>
>> +};
>> +
>> +struct sbrmi_mailbox_msg {
>> +     u8 cmd;
>> +     bool read;
>> +     union mailbox_word data_in;
>> +     union mailbox_word data_out;
>> +};
>> +
>> +static int print_mailbox_error(struct sbrmi_data *data) {
>
> Nit> Many functions only use data>client and, in some cases, 
> Nit> dereference it
> several times. It might be easier to just pass 'client'.
> [naveenk:] Sure
>
>> +     int status;
>> +
>> +     /* Mailbox error code will be written by Firmware in
>> +      * SBRMI::OutBndMsg_inst7 (SBRMI_x37)
>> +      */
>
> /*
>    * Please use standard multi-line comments. Applies to entire driver.
>    */
> [naveenk:] Sure
>
>> +     status = i2c_smbus_read_byte_data(data->client, SBRMI_OUTBNDMSG7);
>> +     if (status < 0) {
>> +             pr_err("SMBUS translation failed\n");
>> +             return status;
>> +     }
>> +
>> +     switch (status) {
>> +     case 0x0:       /* Success */
>> +             break;
>> +     case 0x1:
>> +             pr_err("Mailbox message command is aborted\n");
>> +             break;
>> +     case 0x2:
>> +             pr_err("Unknown mailbox message\n");
>> +             break;
>> +     case 0x3:
>> +             pr_err("Invalid core is specified in mailbox message parameters\n");
>> +             break;
>> +     default:
>> +             pr_err("Unknown Error\n");
>> +     }
>
> Is this noise necessary ? I am concerned that, if it occurs, it would be persistent and fill up the kernel log with noise.
> [naveenk:] These are firmware defined error codes, can we change them to pr_debug and keep them ?
>

pr_debug is ok, but ...

>> +
>> +     return status;
>
> Error codes are supposed to be negative and standard Linux error codes.
> Please convert the above errors to standard Linux error codes.
>
you'll still need to convert the error codes to standard error codes.

This is the only question I found. Please let me know if I missed something.

Thanks,
Guenter

>> +}
>> +
>> +static int sbrmi_enable_alert(struct sbrmi_data *data) {
>> +     int ctrl;
>> +
>> +     /* Enable the SB-RMI Software alert status
>> +      * by writing 0 to bit 4 of Control register(0x1)
>> +      */
>> +     ctrl = i2c_smbus_read_byte_data(data->client, SBRMI_CTRL);
>> +     if (ctrl < 0)
>> +             return ctrl;
>> +
>> +     if (ctrl & 0x10) {
>> +             ctrl &= ~0x10;
>> +             return i2c_smbus_write_byte_data(data->client,
>> +                                              SBRMI_CTRL, ctrl);
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
>> +                         struct sbrmi_mailbox_msg *msg) {
>> +     union mailbox_word output, input;
>> +     int i, err = 0, retry = 10;
>
> Initializing 'err' is unnecessary.
>
>> +     int sw_status;
>> +
>> +     mutex_lock(&data->lock);
>> +
>> +     err = sbrmi_enable_alert(data);
>> +     if (err < 0)
>> +             goto exit_unlock;
>> +
>> +     /* Indicate firmware a command is to be serviced */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG7, START_CMD);
>> +     if (err < 0)
>> +             goto exit_unlock;
>> +
>> +     /* Write the command to SBRMI::InBndMsg_inst0 */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG0, msg->cmd);
>> +     if (err < 0)
>> +             goto exit_mod;
>> +
>> +     /*
>> +      * For both read and write the initiator (BMC) writes
>> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
>> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
>> +      */
>> +     input = msg->data_in;
>> +     for (i = 0; i < 3; i++) {
>
> This writes 3 bytes. Is that on purpose ? If so please explain since the above suggests that 4 bytes should be written.
> [naveenk:] this was a mistake, it has to be 4.
>
>> +             err = i2c_smbus_write_byte_data(data->client,
>> +                                             (SBRMI_INBNDMSG1 + i),
>
> Unnecessary ( )
>
>> +                                             input.bytes[i]);
>> +             if (err < 0)
>> +                     goto exit_mod;
>> +     }
>> +
>> +     /*
>> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
>> +      * perform the requested read or write command
>> +      */
>> +     err = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
>> +     if (err < 0)
>> +             goto exit_mod;
>> +
>> +     /*
>> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
>> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
>> +      * of the requested command
>> +      */
>> +     do {
>> +             sw_status = i2c_smbus_read_byte_data(data->client,
>> +                                                  SBRMI_STATUS);
>> +             if (sw_status < 0) {
>> +                     err = sw_status;
>> +                     goto exit_mod;
>> +             }
>> +             if (sw_status & SW_ALERT_MASK)
>> +                     break;
>> +             usleep_range(50, 100);
>> +     } while (retry--);
>> +
>> +     if (retry < 0) {
>> +             pr_err("Firmware fail to indicate command 
>> + colmpletion\n");
>
> completion
>
>> +             err = -1;
>> +             goto exit_mod;
>> +     }
>> +
>> +     /*
>> +      * For a read operation, the initiator (BMC) reads the firmware response
>> +      * Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
>> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
>> +      */
>> +     if (msg->read) {
>> +             for (i = 0; i < 4; i++) {
>> +                     output.bytes[i] = 
>> + i2c_smbus_read_byte_data(data->client,
>> +
>> + (SBRMI_OUTBNDMSG1 + i));
>
> Unnecessary ().
>
>> +                     if (output.bytes[i] < 0) {
>
> output.bytes is defined as u8. This will not catch errors.
>
>> +                             err = output.bytes[i];
>> +                             goto exit_mod;
>> +                     }
>> +             }
>> +     }
>> +     msg->data_out = output;
>> +
>> +     /*
>> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
>> +      * ALERT to initiator
>> +      */
>> +     err = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
>> +                                     (sw_status | SW_ALERT_MASK));
>
> Unnecessary ().
>
>> +
>> +exit_mod:
>> +     if (err < 0)
>> +             pr_err("SMBUS translation failed\n");
>> +     else
>> +             err = print_mailbox_error(data);
>> +exit_unlock:
>> +     mutex_unlock(&data->lock);
>> +     return err;
>> +}
>> +
>> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
>> +                   u32 attr, int channel, long *val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +     int ret;
>> +
>> +     if (type != hwmon_power)
>> +             return -EINVAL;
>> +
>> +     msg.read = true;
>> +     switch (attr) {
>> +     case hwmon_power_input:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap_max:
>> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +     /*
>> +      * hwmon power attributes are in microWatt
>> +      */
>> +     *val = (long)msg.data_out.value * 1000;
>> +     return ret;
>> +}
>> +
>> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
>> +                    u32 attr, int channel, long val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +
>> +     if (type != hwmon_power && attr != hwmon_power_cap)
>> +             return -EINVAL;
>> +     /*
>> +      * hwmon power attributes are in microWatt
>> +      * mailbox read/write is in mWatt
>> +      */
>> +     val /= 1000;
>> +
>> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +     msg.data_in.value = 0;
>> +     msg.read = true;
>> +     rmi_mailbox_xfer(data, &msg);
>> +
>> +     val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out.value);
>> +
>> +     msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
>> +     msg.data_in.value = val;
>> +     msg.read = false;
>> +
>> +     return rmi_mailbox_xfer(data, &msg); }
>> +
>> +static umode_t sbrmi_is_visible(const void *data,
>> +                             enum hwmon_sensor_types type,
>> +                             u32 attr, int channel) {
>> +     switch (type) {
>> +     case hwmon_power:
>> +             switch (attr) {
>> +             case hwmon_power_input:
>> +             case hwmon_power_cap_max:
>> +                     return 0444;
>> +             case hwmon_power_cap:
>> +                     return 0644;
>> +             }
>> +             break;
>> +     default:
>> +             break;
>> +     }
>> +     return 0;
>> +}
>> +
>> +static const struct hwmon_channel_info *sbrmi_info[] = {
>> +     HWMON_CHANNEL_INFO(power,
>> +                        HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
>> +     NULL
>> +};
>> +
>> +static const struct hwmon_ops sbrmi_hwmon_ops = {
>> +     .is_visible = sbrmi_is_visible,
>> +     .read = sbrmi_read,
>> +     .write = sbrmi_write,
>> +};
>> +
>> +static const struct hwmon_chip_info sbrmi_chip_info = {
>> +     .ops = &sbrmi_hwmon_ops,
>> +     .info = sbrmi_info,
>> +};
>> +
>> +static int sbrmi_probe(struct i2c_client *client,
>> +                    const struct i2c_device_id *id) {
>> +     struct device *dev = &client->dev;
>> +     struct device *hwmon_dev;
>> +     struct sbrmi_data *data;
>> +
>> +     if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
>> +             dev_err(&client->dev, "adapter does not support true 
>> + I2C\n");
>
> Why would that matter? It only uses SMBus functions.
> [naveenk:] yes, will remove this.
>
>> +             return -ENODEV;
>> +     }
>> +
>> +     data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
>> +     if (!data)
>> +             return -ENOMEM;
>> +
>> +     data->client = client;
>> +     mutex_init(&data->lock);
>> +
>> +     hwmon_dev = devm_hwmon_device_register_with_info(dev,
>> + client->name, data,
>> +
>> + &sbrmi_chip_info, NULL);
>> +
>> +     return PTR_ERR_OR_ZERO(hwmon_dev); }
>> +
>> +static const struct i2c_device_id sbrmi_id[] = {
>> +     {"sbrmi", 0},
>> +     {}
>> +};
>> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
>> +
>> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
>> +     {
>> +             .compatible = "amd,sbrmi",
>> +     },
>> +     { },
>> +};
>> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
>> +
>> +static struct i2c_driver sbrmi_driver = {
>> +     .class = I2C_CLASS_HWMON,
>> +     .driver = {
>> +             .name = "sbrmi",
>> +             .of_match_table = of_match_ptr(sbrmi_of_match),
>> +     },
>> +     .probe = sbrmi_probe,
>> +     .id_table = sbrmi_id,
>> +};
>> +
>> +module_i2c_driver(sbrmi_driver);
>> +
>> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>"); 
>> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor"); 
>> +MODULE_LICENSE("GPL");
> [naveenk:] Thank you for your comments, we will address your comments and submit v2 soon.
>>
> [naveenk:]
> Regards,
> Naveenk
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
                   ` (2 preceding siblings ...)
  2021-06-28 14:58 ` [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
@ 2021-07-07 15:58 ` Naveen Krishna Chatradhi
  2021-07-07 15:58   ` [PATCH v2 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
                     ` (2 more replies)
  2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
  2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
  5 siblings, 3 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-07 15:58 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

On AMD platforms the Out-of-band access is provided by
Advanced Platform Management Link (APML), APML is a
SMBus v2.0 compatible 2-wire processor client interface.
APML is also referred as the sideband interface (SBI).

APML is used to communicate with the
Side-Band Remote Management Interface (SB-RMI) which provides
Soft Mailbox messages to manage power consumption and
power limits of the CPU socket.

- This module add support to read power consumption,
  power limit & max power limit and write power limit.
- To instantiate this driver on a Board Management Controller (BMC)
  connected to an AMD CPU with SB-RMI support, the i2c bus number
  would be the bus connected from the BMC to the CPU.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---

Changes since v1:
1. remove header file and move in alphabetical order
2. make all comments multiline
3. remove the pr_err, needed for debugging only
4. fix #define tab issue
5. uninitailize err,
  - correct spelling & remove extra ()
  - remove extra i2c functionality check
6. reduce call to data->client
7. remove usage of union

 drivers/hwmon/Kconfig  |  10 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/sbrmi.c  | 341 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 352 insertions(+)
 create mode 100644 drivers/hwmon/sbrmi.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 87624902ea80..f489972a6309 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi_temp.
 
+config SENSORS_SBRMI
+	tristate "Emulated SB-RMI sensor"
+	depends on I2C
+	help
+	  If you say yes here you get support for emulated RMI
+	  sensors on AMD SoCs with APML interface connected to a BMC device.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sbrmi.
+
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 59e78bc212cf..8031acf58936 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
 obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
 obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
+obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
 obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
new file mode 100644
index 000000000000..10622b1f23f2
--- /dev/null
+++ b/drivers/hwmon/sbrmi.c
@@ -0,0 +1,341 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sbrmi.c - hwmon driver for a SB-RMI mailbox
+ *           compliant AMD SoC device.
+ *
+ * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+
+/* Do not allow setting negative power limit */
+#define SBRMI_PWR_MIN	0
+/* Mask for Status Register bit[1] */
+#define SW_ALERT_MASK	0x2
+
+/* Software Interrupt for triggering */
+#define START_CMD	0x80
+#define TRIGGER_MAILBOX	0x01
+
+/*
+ * SB-RMI supports soft mailbox service request to MP1 (power management
+ * firmware) through SBRMI inbound/outbound message registers.
+ * SB-RMI message IDs
+ */
+enum sbrmi_msg_id {
+	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
+	SBRMI_WRITE_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_MAX_PWR_LIMIT,
+};
+
+/* SB-RMI registers */
+enum sbrmi_reg {
+	SBRMI_CTRL		= 0x01,
+	SBRMI_STATUS,
+	SBRMI_OUTBNDMSG0	= 0x30,
+	SBRMI_OUTBNDMSG1,
+	SBRMI_OUTBNDMSG2,
+	SBRMI_OUTBNDMSG3,
+	SBRMI_OUTBNDMSG4,
+	SBRMI_OUTBNDMSG5,
+	SBRMI_OUTBNDMSG6,
+	SBRMI_OUTBNDMSG7,
+	SBRMI_INBNDMSG0,
+	SBRMI_INBNDMSG1,
+	SBRMI_INBNDMSG2,
+	SBRMI_INBNDMSG3,
+	SBRMI_INBNDMSG4,
+	SBRMI_INBNDMSG5,
+	SBRMI_INBNDMSG6,
+	SBRMI_INBNDMSG7,
+	SBRMI_SW_INTERRUPT,
+};
+
+/* Each client has this additional data */
+struct sbrmi_data {
+	struct i2c_client *client;
+	struct mutex lock;
+};
+
+struct sbrmi_mailbox_msg {
+	u8 cmd;
+	bool read;
+	u32 data_in;
+	u32 data_out;
+};
+
+static int sbrmi_enable_alert(struct i2c_client *client)
+{
+	int ctrl;
+
+	/*
+	 * Enable the SB-RMI Software alert status
+	 * by writing 0 to bit 4 of Control register(0x1)
+	 */
+	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
+	if (ctrl < 0)
+		return ctrl;
+
+	if (ctrl & 0x10) {
+		ctrl &= ~0x10;
+		return i2c_smbus_write_byte_data(client,
+						 SBRMI_CTRL, ctrl);
+	}
+
+	return 0;
+}
+
+static int rmi_mailbox_xfer(struct sbrmi_data *data,
+			    struct sbrmi_mailbox_msg *msg)
+{
+	int i, ret, retry = 10;
+	int sw_status;
+	u8 byte;
+
+	mutex_lock(&data->lock);
+
+	ret = sbrmi_enable_alert(data->client);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/* Indicate firmware a command is to be serviced */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG7, START_CMD);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/* Write the command to SBRMI::InBndMsg_inst0 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG0, msg->cmd);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * For both read and write the initiator (BMC) writes
+	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
+	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
+	 */
+	for (i = 0; i < 4; i++) {
+		byte = (msg->data_in >> i * 8) & 0xff;
+		ret = i2c_smbus_write_byte_data(data->client,
+						SBRMI_INBNDMSG1 + i, byte);
+		if (ret < 0)
+			goto exit_unlock;
+	}
+
+	/*
+	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
+	 * perform the requested read or write command
+	 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
+	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
+	 * of the requested command
+	 */
+	do {
+		sw_status = i2c_smbus_read_byte_data(data->client,
+						     SBRMI_STATUS);
+		if (sw_status < 0) {
+			ret = sw_status;
+			goto exit_unlock;
+		}
+		if (sw_status & SW_ALERT_MASK)
+			break;
+		usleep_range(50, 100);
+	} while (retry--);
+
+	if (retry < 0) {
+		pr_err("Firmware fail to indicate command completion\n");
+		ret = -1;
+		goto exit_unlock;
+	}
+
+	/*
+	 * For a read operation, the initiator (BMC) reads the firmware
+	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
+	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
+	 */
+	if (msg->read) {
+		for (i = 0; i < 4; i++) {
+			ret = i2c_smbus_read_byte_data(data->client,
+						       SBRMI_OUTBNDMSG1 + i);
+			if (ret < 0)
+				goto exit_unlock;
+			msg->data_out |= (ret & 0xff) << i * 8;
+		}
+	}
+
+	/*
+	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
+	 * ALERT to initiator
+	 */
+	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
+					sw_status | SW_ALERT_MASK);
+
+exit_unlock:
+	if (ret < 0)
+		pr_err("SMBUS translation failed\n");
+
+	mutex_unlock(&data->lock);
+	return ret;
+}
+
+static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
+		      u32 attr, int channel, long *val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	if (type != hwmon_power)
+		return -EINVAL;
+
+	msg.read = true;
+	switch (attr) {
+	case hwmon_power_input:
+		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap:
+		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap_max:
+		msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	default:
+		return -EINVAL;
+	}
+	/* hwmon power attributes are in microWatt */
+	*val = (long)msg.data_out * 1000;
+	return ret;
+}
+
+static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
+		       u32 attr, int channel, long val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+
+	if (type != hwmon_power && attr != hwmon_power_cap)
+		return -EINVAL;
+	/*
+	 * hwmon power attributes are in microWatt
+	 * mailbox read/write is in mWatt
+	 */
+	val /= 1000;
+
+	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+	msg.data_in = 0;
+	msg.read = true;
+	rmi_mailbox_xfer(data, &msg);
+
+	val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out);
+
+	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
+	msg.data_in = val;
+	msg.read = false;
+
+	return rmi_mailbox_xfer(data, &msg);
+}
+
+static umode_t sbrmi_is_visible(const void *data,
+				enum hwmon_sensor_types type,
+				u32 attr, int channel)
+{
+	switch (type) {
+	case hwmon_power:
+		switch (attr) {
+		case hwmon_power_input:
+		case hwmon_power_cap_max:
+			return 0444;
+		case hwmon_power_cap:
+			return 0644;
+		}
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static const struct hwmon_channel_info *sbrmi_info[] = {
+	HWMON_CHANNEL_INFO(power,
+			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
+	NULL
+};
+
+static const struct hwmon_ops sbrmi_hwmon_ops = {
+	.is_visible = sbrmi_is_visible,
+	.read = sbrmi_read,
+	.write = sbrmi_write,
+};
+
+static const struct hwmon_chip_info sbrmi_chip_info = {
+	.ops = &sbrmi_hwmon_ops,
+	.info = sbrmi_info,
+};
+
+static int sbrmi_probe(struct i2c_client *client,
+		       const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct device *hwmon_dev;
+	struct sbrmi_data *data;
+
+	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->client = client;
+	mutex_init(&data->lock);
+
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+							 &sbrmi_chip_info, NULL);
+
+	return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id sbrmi_id[] = {
+	{"sbrmi", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sbrmi_id);
+
+static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
+	{
+		.compatible = "amd,sbrmi",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sbrmi_of_match);
+
+static struct i2c_driver sbrmi_driver = {
+	.class = I2C_CLASS_HWMON,
+	.driver = {
+		.name = "sbrmi",
+		.of_match_table = of_match_ptr(sbrmi_of_match),
+	},
+	.probe = sbrmi_probe,
+	.id_table = sbrmi_id,
+};
+
+module_i2c_driver(sbrmi_driver);
+
+MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
+MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
+MODULE_LICENSE("GPL");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 2/3] hwmon: sbrmi: Add Documentation
  2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
@ 2021-07-07 15:58   ` Naveen Krishna Chatradhi
  2021-07-07 15:58   ` [PATCH v2 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
  2021-07-16  5:58   ` [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 0 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-07 15:58 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Add documentation for sbrmi module

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v1:
- correct power# to power1

 Documentation/hwmon/index.rst |  1 +
 Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/hwmon/sbrmi.rst

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 9ed60fa84cbe..5cd4798fe193 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
    q54sj108a2
    raspberrypi-hwmon
    sbtsi_temp
+   sbrmi
    sch5627
    sch5636
    scpi-hwmon
diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
new file mode 100644
index 000000000000..296049e13ac9
--- /dev/null
+++ b/Documentation/hwmon/sbrmi.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver sbrmi
+===================
+
+Supported hardware:
+
+  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
+    device connected to the BMC via the APML.
+
+    Prefix: 'sbrmi'
+
+    Addresses scanned: This driver doesn't support address scanning.
+
+    To instantiate this driver on an AMD CPU with SB-RMI
+    support, the i2c bus number would be the bus connected from the board
+    management controller (BMC) to the CPU.
+    The SMBus address is really 7 bits. Some vendors and the SMBus
+    specification show the address as 8 bits, left justified with the R/W
+    bit as a write (0) making bit 0. Some vendors use only the 7 bits
+    to describe the address.
+    As mentioned in AMD's APML specification, The SB-RMI address is
+    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
+    or 38h(011 1000) for socket 1, but it could vary based on hardware
+    address select pins.
+
+    Datasheet: The SB-RMI interface and protocol along with the Advanced
+               Platform Management Link (APML) Specification is available
+               as part of the open source SoC register reference at:
+
+               https://www.amd.com/en/support/tech-docs?keyword=55898
+
+Author: Akshay Gupta <akshay.gupta@amd.com>
+
+Description
+-----------
+
+The APML provides a way to communicate with the SB Remote Management interface
+(SB-RMI) module from the external SMBus master that can be used to report socket
+power on AMD platforms using mailbox command and resembles a typical 8-pin remote
+power sensor's I2C interface to BMC.
+
+This driver implements current power with power cap and power cap max.
+
+sysfs-Interface
+---------------
+Power sensors can be queried and set via the standard ``hwmon`` interface
+on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
+of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
+content ``sbrmi``)
+
+================ ===== ========================================================
+Name             Perm   Description
+================ ===== ========================================================
+power1_input     RO    Current Power consumed
+power1_cap       RW    Power limit can be set between 0 and power1_cap_max
+power1_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
+================ ===== ========================================================
+
+The following example show how the 'Power' attribute from the i2c-addresses
+can be monitored using the userspace utilities like ``sensors`` binary::
+
+  # sensors
+  sbrmi-i2c-1-38
+  Adapter: bcm2835 I2C adapter
+  power1:       61.00 W (cap = 225.00 W)
+
+  sbrmi-i2c-1-3c
+  Adapter: bcm2835 I2C adapter
+  power1:       28.39 W (cap = 224.77 W)
+  #
+
+Also, Below shows how get and set the values from sysfs entries individually::
+  # cat /sys/class/hwmon/hwmon1/power1_cap_max
+  225000000
+
+  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
+  # cat /sys/class/hwmon/hwmon1/power1_cap
+  180000000
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v2 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
  2021-07-07 15:58   ` [PATCH v2 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-07-07 15:58   ` Naveen Krishna Chatradhi
  2021-07-16  5:58   ` [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 0 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-07 15:58 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Document device tree bindings for AMD SB-RMI emulated service.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v1:
None

 .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
new file mode 100644
index 000000000000..7598b083979c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: >
+  Sideband Remote Management Interface (SB-RMI) compliant
+  AMD SoC power device.
+
+maintainers:
+  - Akshay Gupta <Akshay.Gupta@amd.com>
+
+description: |
+  SB Remote Management Interface (SB-RMI) is an SMBus compatible
+  interface that reports AMD SoC's Power (normalized Power) using,
+  Mailbox Service Request and resembles a typical 8-pin remote power
+  sensor's I2C interface to BMC. The power attributes in hwmon
+  reports power in microwatts.
+
+properties:
+  compatible:
+    enum:
+      - amd,sbrmi
+
+  reg:
+    maxItems: 1
+    description: |
+      I2C bus address of the device as specified in Section SBI SMBus Address
+      of the SoC register reference. The SB-RMI address is normally 78h for
+      socket 0 and 70h for socket 1, but it could vary based on hardware
+      address select pins.
+      \[open source SoC register reference\]
+        https://www.amd.com/en/support/tech-docs?keyword=55898
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c0 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sbrmi@3c {
+                compatible = "amd,sbrmi";
+                reg = <0x3c>;
+        };
+    };
+...
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
  2021-07-07 15:58   ` [PATCH v2 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
  2021-07-07 15:58   ` [PATCH v2 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-07-16  5:58   ` Guenter Roeck
  2021-07-19 15:50     ` Chatradhi, Naveen Krishna
  2 siblings, 1 reply; 28+ messages in thread
From: Guenter Roeck @ 2021-07-16  5:58 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi; +Cc: linux-hwmon, Akshay Gupta

On Wed, Jul 07, 2021 at 09:28:57PM +0530, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> On AMD platforms the Out-of-band access is provided by
> Advanced Platform Management Link (APML), APML is a
> SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
> 
> APML is used to communicate with the
> Side-Band Remote Management Interface (SB-RMI) which provides
> Soft Mailbox messages to manage power consumption and
> power limits of the CPU socket.
> 
> - This module add support to read power consumption,
>   power limit & max power limit and write power limit.
> - To instantiate this driver on a Board Management Controller (BMC)
>   connected to an AMD CPU with SB-RMI support, the i2c bus number
>   would be the bus connected from the BMC to the CPU.
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
> 
> Changes since v1:
> 1. remove header file and move in alphabetical order
> 2. make all comments multiline
> 3. remove the pr_err, needed for debugging only
> 4. fix #define tab issue
> 5. uninitailize err,
>   - correct spelling & remove extra ()
>   - remove extra i2c functionality check
> 6. reduce call to data->client
> 7. remove usage of union
> 
>  drivers/hwmon/Kconfig  |  10 ++
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/sbrmi.c  | 341 +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 352 insertions(+)
>  create mode 100644 drivers/hwmon/sbrmi.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 87624902ea80..f489972a6309 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>  	  This driver can also be built as a module. If so, the module will
>  	  be called sbtsi_temp.
>  
> +config SENSORS_SBRMI
> +	tristate "Emulated SB-RMI sensor"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for emulated RMI
> +	  sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called sbrmi.
> +
>  config SENSORS_SHT15
>  	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>  	depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
>  obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
>  obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
>  obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
>  obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>  obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
>  obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
> new file mode 100644
> index 000000000000..10622b1f23f2
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,341 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +
> +/* Do not allow setting negative power limit */
> +#define SBRMI_PWR_MIN	0
> +/* Mask for Status Register bit[1] */
> +#define SW_ALERT_MASK	0x2
> +
> +/* Software Interrupt for triggering */
> +#define START_CMD	0x80
> +#define TRIGGER_MAILBOX	0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +	SBRMI_WRITE_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +	SBRMI_CTRL		= 0x01,
> +	SBRMI_STATUS,
> +	SBRMI_OUTBNDMSG0	= 0x30,
> +	SBRMI_OUTBNDMSG1,
> +	SBRMI_OUTBNDMSG2,
> +	SBRMI_OUTBNDMSG3,
> +	SBRMI_OUTBNDMSG4,
> +	SBRMI_OUTBNDMSG5,
> +	SBRMI_OUTBNDMSG6,
> +	SBRMI_OUTBNDMSG7,
> +	SBRMI_INBNDMSG0,
> +	SBRMI_INBNDMSG1,
> +	SBRMI_INBNDMSG2,
> +	SBRMI_INBNDMSG3,
> +	SBRMI_INBNDMSG4,
> +	SBRMI_INBNDMSG5,
> +	SBRMI_INBNDMSG6,
> +	SBRMI_INBNDMSG7,
> +	SBRMI_SW_INTERRUPT,
> +};
> +
> +/* Each client has this additional data */
> +struct sbrmi_data {
> +	struct i2c_client *client;
> +	struct mutex lock;
> +};
> +
> +struct sbrmi_mailbox_msg {
> +	u8 cmd;
> +	bool read;
> +	u32 data_in;
> +	u32 data_out;
> +};
> +
> +static int sbrmi_enable_alert(struct i2c_client *client)
> +{
> +	int ctrl;
> +
> +	/*
> +	 * Enable the SB-RMI Software alert status
> +	 * by writing 0 to bit 4 of Control register(0x1)
> +	 */
> +	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
> +	if (ctrl < 0)
> +		return ctrl;
> +
> +	if (ctrl & 0x10) {
> +		ctrl &= ~0x10;
> +		return i2c_smbus_write_byte_data(client,
> +						 SBRMI_CTRL, ctrl);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +			    struct sbrmi_mailbox_msg *msg)
> +{
> +	int i, ret, retry = 10;
> +	int sw_status;
> +	u8 byte;
> +
> +	mutex_lock(&data->lock);
> +
> +	ret = sbrmi_enable_alert(data->client);
> +	if (ret < 0)
> +		goto exit_unlock;
> +

Is it really necessary to call this for every command (instead
of once during probe) ?

> +	/* Indicate firmware a command is to be serviced */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG7, START_CMD);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/* Write the command to SBRMI::InBndMsg_inst0 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG0, msg->cmd);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * For both read and write the initiator (BMC) writes
> +	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +	 */
> +	for (i = 0; i < 4; i++) {
> +		byte = (msg->data_in >> i * 8) & 0xff;
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						SBRMI_INBNDMSG1 + i, byte);
> +		if (ret < 0)
> +			goto exit_unlock;
> +	}
> +
> +	/*
> +	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +	 * perform the requested read or write command
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +	 * of the requested command
> +	 */
> +	do {
> +		sw_status = i2c_smbus_read_byte_data(data->client,
> +						     SBRMI_STATUS);
> +		if (sw_status < 0) {
> +			ret = sw_status;
> +			goto exit_unlock;
> +		}
> +		if (sw_status & SW_ALERT_MASK)
> +			break;
> +		usleep_range(50, 100);

I don't have the interface specification, but is ~600 uS guaranteed
to be sufficient time for the firmware to respond ?

> +	} while (retry--);
> +
> +	if (retry < 0) {
> +		pr_err("Firmware fail to indicate command completion\n");

Please use dev_err(). Also, does this really warrant an error message ?
I am concerned that it may fill up the log if there is an issue with
the client, eg if it hangs. On top of that, there is already an error
message below. Please no more than one message per error.

> +		ret = -1;

Please use standard error codes (-ETIMEDOUT ? -EIO ? -EPROTO ?).
-1 translates to -EPERM which is presumably not what you want.

> +		goto exit_unlock;
> +	}
> +
> +	/*
> +	 * For a read operation, the initiator (BMC) reads the firmware
> +	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +	 */
> +	if (msg->read) {
> +		for (i = 0; i < 4; i++) {
> +			ret = i2c_smbus_read_byte_data(data->client,
> +						       SBRMI_OUTBNDMSG1 + i);
> +			if (ret < 0)
> +				goto exit_unlock;

This is a concern in conjunction with the ignored error in sbrmi_write().
If there is an error after reading a number of bytes, the returned
value will be partial/random.

> +			msg->data_out |= (ret & 0xff) << i * 8;

The mask is unnecessary here. A byte read will never return a value > 0xff.

> +		}
> +	}
> +
> +	/*
> +	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +	 * ALERT to initiator
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +					sw_status | SW_ALERT_MASK);
> +
> +exit_unlock:
> +	if (ret < 0)
> +		pr_err("SMBUS translation failed\n");

dev_err(). Also, please consider that this may fill the log
if the client or the i2c controller/bus has a problem.

> +
> +	mutex_unlock(&data->lock);
> +	return ret;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +		      u32 attr, int channel, long *val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	if (type != hwmon_power)
> +		return -EINVAL;
> +
> +	msg.read = true;
> +	switch (attr) {
> +	case hwmon_power_input:
> +		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap:
> +		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap_max:
> +		msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	/* hwmon power attributes are in microWatt */
> +	*val = (long)msg.data_out * 1000;
> +	return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +		       u32 attr, int channel, long val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +
> +	if (type != hwmon_power && attr != hwmon_power_cap)
> +		return -EINVAL;
> +	/*
> +	 * hwmon power attributes are in microWatt
> +	 * mailbox read/write is in mWatt
> +	 */
> +	val /= 1000;
> +
> +	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +	msg.data_in = 0;

Unnecessary (already initialized above).

> +	msg.read = true;
> +	rmi_mailbox_xfer(data, &msg);

Not sure if it is a good idea to ignore an error return here.
As far as I can see in rmi_mailbox_xfer(), the returned value
is more or less random if there is an error.

If the maximum power limit is static, it might make sense
to read it only once in the prob function and cache the
limit in struct sbrmi_data instead of reading it repeatedly.

If the limit is not static and it is indeed necessary to re-read
the limit, isn't this racy if there are multiple write requests
in parallel ?

> +
> +	val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out);
> +
> +	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +	msg.data_in = val;
> +	msg.read = false;
> +
> +	return rmi_mailbox_xfer(data, &msg);
> +}
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +				enum hwmon_sensor_types type,
> +				u32 attr, int channel)
> +{
> +	switch (type) {
> +	case hwmon_power:
> +		switch (attr) {
> +		case hwmon_power_input:
> +		case hwmon_power_cap_max:
> +			return 0444;
> +		case hwmon_power_cap:
> +			return 0644;
> +		}
> +		break;
> +	default:
> +		break;
> +	}
> +	return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +	HWMON_CHANNEL_INFO(power,
> +			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +	NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +	.is_visible = sbrmi_is_visible,
> +	.read = sbrmi_read,
> +	.write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +	.ops = &sbrmi_hwmon_ops,
> +	.info = sbrmi_info,
> +};
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +		       const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct device *hwmon_dev;
> +	struct sbrmi_data *data;
> +
> +	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->client = client;
> +	mutex_init(&data->lock);
> +
> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +							 &sbrmi_chip_info, NULL);
> +
> +	return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +	{"sbrmi", 0},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +	{
> +		.compatible = "amd,sbrmi",
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +	.class = I2C_CLASS_HWMON,
> +	.driver = {
> +		.name = "sbrmi",
> +		.of_match_table = of_match_ptr(sbrmi_of_match),
> +	},
> +	.probe = sbrmi_probe,
> +	.id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
> +MODULE_LICENSE("GPL");
> -- 
> 2.17.1
> 

^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-16  5:58   ` [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
@ 2021-07-19 15:50     ` Chatradhi, Naveen Krishna
  2021-07-19 16:21       ` Guenter Roeck
  0 siblings, 1 reply; 28+ messages in thread
From: Chatradhi, Naveen Krishna @ 2021-07-19 15:50 UTC (permalink / raw)
  To: Guenter Roeck; +Cc: linux-hwmon, Gupta, Akshay

[AMD Official Use Only]

Hi Guenter,

Thank you for your review, will submit revised version shortly.

Regards,
Naveenk

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Friday, July 16, 2021 11:28 AM
To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>
Cc: linux-hwmon@vger.kernel.org; Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: Re: [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module

[CAUTION: External Email]

On Wed, Jul 07, 2021 at 09:28:57PM +0530, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
>
> On AMD platforms the Out-of-band access is provided by Advanced 
> Platform Management Link (APML), APML is a SMBus v2.0 compatible 
> 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
>
> APML is used to communicate with the
> Side-Band Remote Management Interface (SB-RMI) which provides Soft 
> Mailbox messages to manage power consumption and power limits of the 
> CPU socket.
>
> - This module add support to read power consumption,
>   power limit & max power limit and write power limit.
> - To instantiate this driver on a Board Management Controller (BMC)
>   connected to an AMD CPU with SB-RMI support, the i2c bus number
>   would be the bus connected from the BMC to the CPU.
>
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
>
> Changes since v1:
> 1. remove header file and move in alphabetical order 2. make all 
> comments multiline 3. remove the pr_err, needed for debugging only 4. 
> fix #define tab issue 5. uninitailize err,
>   - correct spelling & remove extra ()
>   - remove extra i2c functionality check 6. reduce call to 
> data->client 7. remove usage of union
>
>  drivers/hwmon/Kconfig  |  10 ++
>  drivers/hwmon/Makefile |   1 +
>  drivers/hwmon/sbrmi.c  | 341 
> +++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 352 insertions(+)
>  create mode 100644 drivers/hwmon/sbrmi.c
>
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index 
> 87624902ea80..f489972a6309 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>         This driver can also be built as a module. If so, the module will
>         be called sbtsi_temp.
>
> +config SENSORS_SBRMI
> +     tristate "Emulated SB-RMI sensor"
> +     depends on I2C
> +     help
> +       If you say yes here you get support for emulated RMI
> +       sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +       This driver can also be built as a module. If so, the module will
> +       be called sbrmi.
> +
>  config SENSORS_SHT15
>       tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>       depends on GPIOLIB || COMPILE_TEST diff --git 
> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index 
> 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>  obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)      += raspberrypi-hwmon.o
>  obj-$(CONFIG_SENSORS_S3C)    += s3c-hwmon.o
>  obj-$(CONFIG_SENSORS_SBTSI)  += sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>  obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>  obj-$(CONFIG_SENSORS_SCH5627)        += sch5627.o
>  obj-$(CONFIG_SENSORS_SCH5636)        += sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file 
> mode 100644 index 000000000000..10622b1f23f2
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,341 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +
> +/* Do not allow setting negative power limit */
> +#define SBRMI_PWR_MIN        0
> +/* Mask for Status Register bit[1] */
> +#define SW_ALERT_MASK        0x2
> +
> +/* Software Interrupt for triggering */
> +#define START_CMD    0x80
> +#define TRIGGER_MAILBOX      0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power 
> +management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +     SBRMI_WRITE_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_PWR_LIMIT,
> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +     SBRMI_CTRL              = 0x01,
> +     SBRMI_STATUS,
> +     SBRMI_OUTBNDMSG0        = 0x30,
> +     SBRMI_OUTBNDMSG1,
> +     SBRMI_OUTBNDMSG2,
> +     SBRMI_OUTBNDMSG3,
> +     SBRMI_OUTBNDMSG4,
> +     SBRMI_OUTBNDMSG5,
> +     SBRMI_OUTBNDMSG6,
> +     SBRMI_OUTBNDMSG7,
> +     SBRMI_INBNDMSG0,
> +     SBRMI_INBNDMSG1,
> +     SBRMI_INBNDMSG2,
> +     SBRMI_INBNDMSG3,
> +     SBRMI_INBNDMSG4,
> +     SBRMI_INBNDMSG5,
> +     SBRMI_INBNDMSG6,
> +     SBRMI_INBNDMSG7,
> +     SBRMI_SW_INTERRUPT,
> +};
> +
> +/* Each client has this additional data */ struct sbrmi_data {
> +     struct i2c_client *client;
> +     struct mutex lock;
> +};
> +
> +struct sbrmi_mailbox_msg {
> +     u8 cmd;
> +     bool read;
> +     u32 data_in;
> +     u32 data_out;
> +};
> +
> +static int sbrmi_enable_alert(struct i2c_client *client) {
> +     int ctrl;
> +
> +     /*
> +      * Enable the SB-RMI Software alert status
> +      * by writing 0 to bit 4 of Control register(0x1)
> +      */
> +     ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
> +     if (ctrl < 0)
> +             return ctrl;
> +
> +     if (ctrl & 0x10) {
> +             ctrl &= ~0x10;
> +             return i2c_smbus_write_byte_data(client,
> +                                              SBRMI_CTRL, ctrl);
> +     }
> +
> +     return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +                         struct sbrmi_mailbox_msg *msg) {
> +     int i, ret, retry = 10;
> +     int sw_status;
> +     u8 byte;
> +
> +     mutex_lock(&data->lock);
> +
> +     ret = sbrmi_enable_alert(data->client);
> +     if (ret < 0)
> +             goto exit_unlock;
> +

Is it really necessary to call this for every command (instead of once during probe) ?
[naveenk:] Will move it

> +     /* Indicate firmware a command is to be serviced */
> +     ret = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG7, START_CMD);
> +     if (ret < 0)
> +             goto exit_unlock;
> +
> +     /* Write the command to SBRMI::InBndMsg_inst0 */
> +     ret = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_INBNDMSG0, msg->cmd);
> +     if (ret < 0)
> +             goto exit_unlock;
> +
> +     /*
> +      * For both read and write the initiator (BMC) writes
> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +      */
> +     for (i = 0; i < 4; i++) {
> +             byte = (msg->data_in >> i * 8) & 0xff;
> +             ret = i2c_smbus_write_byte_data(data->client,
> +                                             SBRMI_INBNDMSG1 + i, byte);
> +             if (ret < 0)
> +                     goto exit_unlock;
> +     }
> +
> +     /*
> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +      * perform the requested read or write command
> +      */
> +     ret = i2c_smbus_write_byte_data(data->client,
> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +     if (ret < 0)
> +             goto exit_unlock;
> +
> +     /*
> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +      * of the requested command
> +      */
> +     do {
> +             sw_status = i2c_smbus_read_byte_data(data->client,
> +                                                  SBRMI_STATUS);
> +             if (sw_status < 0) {
> +                     ret = sw_status;
> +                     goto exit_unlock;
> +             }
> +             if (sw_status & SW_ALERT_MASK)
> +                     break;
> +             usleep_range(50, 100);

I don't have the interface specification, but is ~600 uS guaranteed to be sufficient time for the firmware to respond ?
[naveenk:] The SB-RMI is explained in the APML chapter of the reference manual available https://www.amd.com/en/support/tech-docs?keyword=55898 
I did not find any mention of the response time, we ran several times and never seen the loop execute twice. Do you have any recommendation here ?

> +     } while (retry--);
> +
> +     if (retry < 0) {
> +             pr_err("Firmware fail to indicate command 
> + completion\n");

Please use dev_err(). Also, does this really warrant an error message ?
I am concerned that it may fill up the log if there is an issue with the client, eg if it hangs. On top of that, there is already an error message below. Please no more than one message per error.
[naveenk:] Sure will change to dev_err and remove one of the prints

> +             ret = -1;

Please use standard error codes (-ETIMEDOUT ? -EIO ? -EPROTO ?).
-1 translates to -EPERM which is presumably not what you want.
[naveenk:] Will use -EIO

> +             goto exit_unlock;
> +     }
> +
> +     /*
> +      * For a read operation, the initiator (BMC) reads the firmware
> +      * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +      */
> +     if (msg->read) {
> +             for (i = 0; i < 4; i++) {
> +                     ret = i2c_smbus_read_byte_data(data->client,
> +                                                    SBRMI_OUTBNDMSG1 + i);
> +                     if (ret < 0)
> +                             goto exit_unlock;

This is a concern in conjunction with the ignored error in sbrmi_write().
If there is an error after reading a number of bytes, the returned value will be partial/random.
[naveenk:] Will address the return value

> +                     msg->data_out |= (ret & 0xff) << i * 8;

The mask is unnecessary here. A byte read will never return a value > 0xff.
[naveenk:] Sure will remove

> +             }
> +     }
> +
> +     /*
> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +      * ALERT to initiator
> +      */
> +     ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +                                     sw_status | SW_ALERT_MASK);
> +
> +exit_unlock:
> +     if (ret < 0)
> +             pr_err("SMBUS translation failed\n");

dev_err(). Also, please consider that this may fill the log if the client or the i2c controller/bus has a problem.
[naveenk:] Will remove this print

> +
> +     mutex_unlock(&data->lock);
> +     return ret;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +                   u32 attr, int channel, long *val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +     int ret;
> +
> +     if (type != hwmon_power)
> +             return -EINVAL;
> +
> +     msg.read = true;
> +     switch (attr) {
> +     case hwmon_power_input:
> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap:
> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     case hwmon_power_cap_max:
> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +             ret = rmi_mailbox_xfer(data, &msg);
> +             break;
> +     default:
> +             return -EINVAL;
> +     }
> +     /* hwmon power attributes are in microWatt */
> +     *val = (long)msg.data_out * 1000;
> +     return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +                    u32 attr, int channel, long val) {
> +     struct sbrmi_data *data = dev_get_drvdata(dev);
> +     struct sbrmi_mailbox_msg msg = { 0 };
> +
> +     if (type != hwmon_power && attr != hwmon_power_cap)
> +             return -EINVAL;
> +     /*
> +      * hwmon power attributes are in microWatt
> +      * mailbox read/write is in mWatt
> +      */
> +     val /= 1000;
> +
> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +     msg.data_in = 0;

Unnecessary (already initialized above).

> +     msg.read = true;
> +     rmi_mailbox_xfer(data, &msg);

Not sure if it is a good idea to ignore an error return here.
As far as I can see in rmi_mailbox_xfer(), the returned value is more or less random if there is an error.

If the maximum power limit is static, it might make sense to read it only once in the prob function and cache the limit in struct sbrmi_data instead of reading it repeatedly.
[naveenk:] The maximum limit is fixed, will cache during probe.
If the limit is not static and it is indeed necessary to re-read the limit, isn't this racy if there are multiple write requests in parallel ?
[naveenk:] the operating limit value can be set to a value below the max_limit

> +
> +     val = clamp_val(val, SBRMI_PWR_MIN, msg.data_out);
> +
> +     msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +     msg.data_in = val;
> +     msg.read = false;
> +
> +     return rmi_mailbox_xfer(data, &msg); }
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +                             enum hwmon_sensor_types type,
> +                             u32 attr, int channel) {
> +     switch (type) {
> +     case hwmon_power:
> +             switch (attr) {
> +             case hwmon_power_input:
> +             case hwmon_power_cap_max:
> +                     return 0444;
> +             case hwmon_power_cap:
> +                     return 0644;
> +             }
> +             break;
> +     default:
> +             break;
> +     }
> +     return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +     HWMON_CHANNEL_INFO(power,
> +                        HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +     NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +     .is_visible = sbrmi_is_visible,
> +     .read = sbrmi_read,
> +     .write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +     .ops = &sbrmi_hwmon_ops,
> +     .info = sbrmi_info,
> +};
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +                    const struct i2c_device_id *id) {
> +     struct device *dev = &client->dev;
> +     struct device *hwmon_dev;
> +     struct sbrmi_data *data;
> +
> +     data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +     if (!data)
> +             return -ENOMEM;
> +
> +     data->client = client;
> +     mutex_init(&data->lock);
> +
> +     hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +                                                      
> + &sbrmi_chip_info, NULL);
> +
> +     return PTR_ERR_OR_ZERO(hwmon_dev); }
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +     {"sbrmi", 0},
> +     {}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +     {
> +             .compatible = "amd,sbrmi",
> +     },
> +     { },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +     .class = I2C_CLASS_HWMON,
> +     .driver = {
> +             .name = "sbrmi",
> +             .of_match_table = of_match_ptr(sbrmi_of_match),
> +     },
> +     .probe = sbrmi_probe,
> +     .id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>"); 
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor"); 
> +MODULE_LICENSE("GPL");
> --
> 2.17.1
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-19 15:50     ` Chatradhi, Naveen Krishna
@ 2021-07-19 16:21       ` Guenter Roeck
  0 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-07-19 16:21 UTC (permalink / raw)
  To: Chatradhi, Naveen Krishna; +Cc: linux-hwmon, Gupta, Akshay

On 7/19/21 8:50 AM, Chatradhi, Naveen Krishna wrote:
> [AMD Official Use Only]
> 
> Hi Guenter,
> 
> Thank you for your review, will submit revised version shortly.
> 
> Regards,
> Naveenk
> 
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Friday, July 16, 2021 11:28 AM
> To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>
> Cc: linux-hwmon@vger.kernel.org; Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: Re: [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module
> 
> [CAUTION: External Email]
> 
> On Wed, Jul 07, 2021 at 09:28:57PM +0530, Naveen Krishna Chatradhi wrote:
>> From: Akshay Gupta <Akshay.Gupta@amd.com>
>>
>> On AMD platforms the Out-of-band access is provided by Advanced
>> Platform Management Link (APML), APML is a SMBus v2.0 compatible
>> 2-wire processor client interface.
>> APML is also referred as the sideband interface (SBI).
>>
>> APML is used to communicate with the
>> Side-Band Remote Management Interface (SB-RMI) which provides Soft
>> Mailbox messages to manage power consumption and power limits of the
>> CPU socket.
>>
>> - This module add support to read power consumption,
>>    power limit & max power limit and write power limit.
>> - To instantiate this driver on a Board Management Controller (BMC)
>>    connected to an AMD CPU with SB-RMI support, the i2c bus number
>>    would be the bus connected from the BMC to the CPU.
>>
>> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
>> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
>> ---
>>
>> Changes since v1:
>> 1. remove header file and move in alphabetical order 2. make all
>> comments multiline 3. remove the pr_err, needed for debugging only 4.
>> fix #define tab issue 5. uninitailize err,
>>    - correct spelling & remove extra ()
>>    - remove extra i2c functionality check 6. reduce call to
>> data->client 7. remove usage of union
>>
>>   drivers/hwmon/Kconfig  |  10 ++
>>   drivers/hwmon/Makefile |   1 +
>>   drivers/hwmon/sbrmi.c  | 341
>> +++++++++++++++++++++++++++++++++++++++++
>>   3 files changed, 352 insertions(+)
>>   create mode 100644 drivers/hwmon/sbrmi.c
>>
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig index
>> 87624902ea80..f489972a6309 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>>          This driver can also be built as a module. If so, the module will
>>          be called sbtsi_temp.
>>
>> +config SENSORS_SBRMI
>> +     tristate "Emulated SB-RMI sensor"
>> +     depends on I2C
>> +     help
>> +       If you say yes here you get support for emulated RMI
>> +       sensors on AMD SoCs with APML interface connected to a BMC device.
>> +
>> +       This driver can also be built as a module. If so, the module will
>> +       be called sbrmi.
>> +
>>   config SENSORS_SHT15
>>        tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>>        depends on GPIOLIB || COMPILE_TEST diff --git
>> a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile index
>> 59e78bc212cf..8031acf58936 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)     += pwm-fan.o
>>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)      += raspberrypi-hwmon.o
>>   obj-$(CONFIG_SENSORS_S3C)    += s3c-hwmon.o
>>   obj-$(CONFIG_SENSORS_SBTSI)  += sbtsi_temp.o
>> +obj-$(CONFIG_SENSORS_SBRMI)  += sbrmi.o
>>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>>   obj-$(CONFIG_SENSORS_SCH5627)        += sch5627.o
>>   obj-$(CONFIG_SENSORS_SCH5636)        += sch5636.o
>> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c new file
>> mode 100644 index 000000000000..10622b1f23f2
>> --- /dev/null
>> +++ b/drivers/hwmon/sbrmi.c
>> @@ -0,0 +1,341 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
>> + *           compliant AMD SoC device.
>> + *
>> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
>> + */
>> +
>> +#include <linux/delay.h>
>> +#include <linux/err.h>
>> +#include <linux/hwmon.h>
>> +#include <linux/i2c.h>
>> +#include <linux/init.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +
>> +/* Do not allow setting negative power limit */
>> +#define SBRMI_PWR_MIN        0
>> +/* Mask for Status Register bit[1] */
>> +#define SW_ALERT_MASK        0x2
>> +
>> +/* Software Interrupt for triggering */
>> +#define START_CMD    0x80
>> +#define TRIGGER_MAILBOX      0x01
>> +
>> +/*
>> + * SB-RMI supports soft mailbox service request to MP1 (power
>> +management
>> + * firmware) through SBRMI inbound/outbound message registers.
>> + * SB-RMI message IDs
>> + */
>> +enum sbrmi_msg_id {
>> +     SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
>> +     SBRMI_WRITE_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_PWR_LIMIT,
>> +     SBRMI_READ_PKG_MAX_PWR_LIMIT,
>> +};
>> +
>> +/* SB-RMI registers */
>> +enum sbrmi_reg {
>> +     SBRMI_CTRL              = 0x01,
>> +     SBRMI_STATUS,
>> +     SBRMI_OUTBNDMSG0        = 0x30,
>> +     SBRMI_OUTBNDMSG1,
>> +     SBRMI_OUTBNDMSG2,
>> +     SBRMI_OUTBNDMSG3,
>> +     SBRMI_OUTBNDMSG4,
>> +     SBRMI_OUTBNDMSG5,
>> +     SBRMI_OUTBNDMSG6,
>> +     SBRMI_OUTBNDMSG7,
>> +     SBRMI_INBNDMSG0,
>> +     SBRMI_INBNDMSG1,
>> +     SBRMI_INBNDMSG2,
>> +     SBRMI_INBNDMSG3,
>> +     SBRMI_INBNDMSG4,
>> +     SBRMI_INBNDMSG5,
>> +     SBRMI_INBNDMSG6,
>> +     SBRMI_INBNDMSG7,
>> +     SBRMI_SW_INTERRUPT,
>> +};
>> +
>> +/* Each client has this additional data */ struct sbrmi_data {
>> +     struct i2c_client *client;
>> +     struct mutex lock;
>> +};
>> +
>> +struct sbrmi_mailbox_msg {
>> +     u8 cmd;
>> +     bool read;
>> +     u32 data_in;
>> +     u32 data_out;
>> +};
>> +
>> +static int sbrmi_enable_alert(struct i2c_client *client) {
>> +     int ctrl;
>> +
>> +     /*
>> +      * Enable the SB-RMI Software alert status
>> +      * by writing 0 to bit 4 of Control register(0x1)
>> +      */
>> +     ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
>> +     if (ctrl < 0)
>> +             return ctrl;
>> +
>> +     if (ctrl & 0x10) {
>> +             ctrl &= ~0x10;
>> +             return i2c_smbus_write_byte_data(client,
>> +                                              SBRMI_CTRL, ctrl);
>> +     }
>> +
>> +     return 0;
>> +}
>> +
>> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
>> +                         struct sbrmi_mailbox_msg *msg) {
>> +     int i, ret, retry = 10;
>> +     int sw_status;
>> +     u8 byte;
>> +
>> +     mutex_lock(&data->lock);
>> +
>> +     ret = sbrmi_enable_alert(data->client);
>> +     if (ret < 0)
>> +             goto exit_unlock;
>> +
> 
> Is it really necessary to call this for every command (instead of once during probe) ?
> [naveenk:] Will move it
> 
>> +     /* Indicate firmware a command is to be serviced */
>> +     ret = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG7, START_CMD);
>> +     if (ret < 0)
>> +             goto exit_unlock;
>> +
>> +     /* Write the command to SBRMI::InBndMsg_inst0 */
>> +     ret = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_INBNDMSG0, msg->cmd);
>> +     if (ret < 0)
>> +             goto exit_unlock;
>> +
>> +     /*
>> +      * For both read and write the initiator (BMC) writes
>> +      * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
>> +      * SBRMI_x3C(MSB):SBRMI_x39(LSB)
>> +      */
>> +     for (i = 0; i < 4; i++) {
>> +             byte = (msg->data_in >> i * 8) & 0xff;
>> +             ret = i2c_smbus_write_byte_data(data->client,
>> +                                             SBRMI_INBNDMSG1 + i, byte);
>> +             if (ret < 0)
>> +                     goto exit_unlock;
>> +     }
>> +
>> +     /*
>> +      * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
>> +      * perform the requested read or write command
>> +      */
>> +     ret = i2c_smbus_write_byte_data(data->client,
>> +                                     SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
>> +     if (ret < 0)
>> +             goto exit_unlock;
>> +
>> +     /*
>> +      * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
>> +      * an ALERT (if enabled) to initiator (BMC) to indicate completion
>> +      * of the requested command
>> +      */
>> +     do {
>> +             sw_status = i2c_smbus_read_byte_data(data->client,
>> +                                                  SBRMI_STATUS);
>> +             if (sw_status < 0) {
>> +                     ret = sw_status;
>> +                     goto exit_unlock;
>> +             }
>> +             if (sw_status & SW_ALERT_MASK)
>> +                     break;
>> +             usleep_range(50, 100);
> 
> I don't have the interface specification, but is ~600 uS guaranteed to be sufficient time for the firmware to respond ?
> [naveenk:] The SB-RMI is explained in the APML chapter of the reference manual available https://www.amd.com/en/support/tech-docs?keyword=55898
> I did not find any mention of the response time, we ran several times and never seen the loop execute twice. Do you have any recommendation here ?
> 
Not really. The code is good enough for me if it is good enough for you,
especially if the timeout is not well defined.

>> +     } while (retry--);
>> +
>> +     if (retry < 0) {
>> +             pr_err("Firmware fail to indicate command
>> + completion\n");
> 
> Please use dev_err(). Also, does this really warrant an error message ?
> I am concerned that it may fill up the log if there is an issue with the client, eg if it hangs. On top of that, there is already an error message below. Please no more than one message per error.
> [naveenk:] Sure will change to dev_err and remove one of the prints
> 
>> +             ret = -1;
> 
> Please use standard error codes (-ETIMEDOUT ? -EIO ? -EPROTO ?).
> -1 translates to -EPERM which is presumably not what you want.
> [naveenk:] Will use -EIO
> 
>> +             goto exit_unlock;
>> +     }
>> +
>> +     /*
>> +      * For a read operation, the initiator (BMC) reads the firmware
>> +      * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
>> +      * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
>> +      */
>> +     if (msg->read) {
>> +             for (i = 0; i < 4; i++) {
>> +                     ret = i2c_smbus_read_byte_data(data->client,
>> +                                                    SBRMI_OUTBNDMSG1 + i);
>> +                     if (ret < 0)
>> +                             goto exit_unlock;
> 
> This is a concern in conjunction with the ignored error in sbrmi_write().
> If there is an error after reading a number of bytes, the returned value will be partial/random.
> [naveenk:] Will address the return value
> 
>> +                     msg->data_out |= (ret & 0xff) << i * 8;
> 
> The mask is unnecessary here. A byte read will never return a value > 0xff.
> [naveenk:] Sure will remove
> 
>> +             }
>> +     }
>> +
>> +     /*
>> +      * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
>> +      * ALERT to initiator
>> +      */
>> +     ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
>> +                                     sw_status | SW_ALERT_MASK);
>> +
>> +exit_unlock:
>> +     if (ret < 0)
>> +             pr_err("SMBUS translation failed\n");
> 
> dev_err(). Also, please consider that this may fill the log if the client or the i2c controller/bus has a problem.
> [naveenk:] Will remove this print
> 
>> +
>> +     mutex_unlock(&data->lock);
>> +     return ret;
>> +}
>> +
>> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
>> +                   u32 attr, int channel, long *val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +     int ret;
>> +
>> +     if (type != hwmon_power)
>> +             return -EINVAL;
>> +
>> +     msg.read = true;
>> +     switch (attr) {
>> +     case hwmon_power_input:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap:
>> +             msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     case hwmon_power_cap_max:
>> +             msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +             ret = rmi_mailbox_xfer(data, &msg);
>> +             break;
>> +     default:
>> +             return -EINVAL;
>> +     }
>> +     /* hwmon power attributes are in microWatt */
>> +     *val = (long)msg.data_out * 1000;
>> +     return ret;
>> +}
>> +
>> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
>> +                    u32 attr, int channel, long val) {
>> +     struct sbrmi_data *data = dev_get_drvdata(dev);
>> +     struct sbrmi_mailbox_msg msg = { 0 };
>> +
>> +     if (type != hwmon_power && attr != hwmon_power_cap)
>> +             return -EINVAL;
>> +     /*
>> +      * hwmon power attributes are in microWatt
>> +      * mailbox read/write is in mWatt
>> +      */
>> +     val /= 1000;
>> +
>> +     msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
>> +     msg.data_in = 0;
> 
> Unnecessary (already initialized above).
> 
>> +     msg.read = true;
>> +     rmi_mailbox_xfer(data, &msg);
> 
> Not sure if it is a good idea to ignore an error return here.
> As far as I can see in rmi_mailbox_xfer(), the returned value is more or less random if there is an error.
> 
> If the maximum power limit is static, it might make sense to read it only once in the prob function and cache the limit in struct sbrmi_data instead of reading it repeatedly.
> [naveenk:] The maximum limit is fixed, will cache during probe.
> If the limit is not static and it is indeed necessary to re-read the limit, isn't this racy if there are multiple write requests in parallel ?
> [naveenk:] the operating limit value can be set to a value below the max_limit
> 

Yes, I understand. My concern was potential race if the first mailbox transfer
would not return a constant. This is not an issue if there is only one
mailbox transfer.

Thanks,
Guenter

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v3 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
                   ` (3 preceding siblings ...)
  2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
@ 2021-07-20  5:57 ` Naveen Krishna Chatradhi
  2021-07-20  5:57   ` [PATCH v3 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
                     ` (2 more replies)
  2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
  5 siblings, 3 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-20  5:57 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

On AMD platforms the Out-of-band access is provided by
Advanced Platform Management Link (APML), APML is a
SMBus v2.0 compatible 2-wire processor client interface.
APML is also referred as the sideband interface (SBI).

APML is used to communicate with the
Side-Band Remote Management Interface (SB-RMI) which provides
Soft Mailbox messages to manage power consumption and
power limits of the CPU socket.

- This module add support to read power consumption,
  power limit & max power limit and write power limit.
- To instantiate this driver on a Board Management Controller (BMC)
  connected to an AMD CPU with SB-RMI support, the i2c bus number
  would be the bus connected from the BMC to the CPU.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v2:
1. Modify to cache the power_limi_max during probe
2. Enable alert during probe
3. Use dev_err instead of pr_err
4. Remove unnecessry bit mask
5. Checking rmi_mailbox_xfer retrun value

 drivers/hwmon/Kconfig  |  10 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/sbrmi.c  | 358 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 369 insertions(+)
 create mode 100644 drivers/hwmon/sbrmi.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 87624902ea80..f489972a6309 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi_temp.
 
+config SENSORS_SBRMI
+	tristate "Emulated SB-RMI sensor"
+	depends on I2C
+	help
+	  If you say yes here you get support for emulated RMI
+	  sensors on AMD SoCs with APML interface connected to a BMC device.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sbrmi.
+
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 59e78bc212cf..8031acf58936 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
 obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
 obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
+obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
 obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
new file mode 100644
index 000000000000..372b099c04a0
--- /dev/null
+++ b/drivers/hwmon/sbrmi.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sbrmi.c - hwmon driver for a SB-RMI mailbox
+ *           compliant AMD SoC device.
+ *
+ * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+
+/* Do not allow setting negative power limit */
+#define SBRMI_PWR_MIN	0
+/* Mask for Status Register bit[1] */
+#define SW_ALERT_MASK	0x2
+
+/* Software Interrupt for triggering */
+#define START_CMD	0x80
+#define TRIGGER_MAILBOX	0x01
+
+/*
+ * SB-RMI supports soft mailbox service request to MP1 (power management
+ * firmware) through SBRMI inbound/outbound message registers.
+ * SB-RMI message IDs
+ */
+enum sbrmi_msg_id {
+	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
+	SBRMI_WRITE_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_MAX_PWR_LIMIT,
+};
+
+/* SB-RMI registers */
+enum sbrmi_reg {
+	SBRMI_CTRL		= 0x01,
+	SBRMI_STATUS,
+	SBRMI_OUTBNDMSG0	= 0x30,
+	SBRMI_OUTBNDMSG1,
+	SBRMI_OUTBNDMSG2,
+	SBRMI_OUTBNDMSG3,
+	SBRMI_OUTBNDMSG4,
+	SBRMI_OUTBNDMSG5,
+	SBRMI_OUTBNDMSG6,
+	SBRMI_OUTBNDMSG7,
+	SBRMI_INBNDMSG0,
+	SBRMI_INBNDMSG1,
+	SBRMI_INBNDMSG2,
+	SBRMI_INBNDMSG3,
+	SBRMI_INBNDMSG4,
+	SBRMI_INBNDMSG5,
+	SBRMI_INBNDMSG6,
+	SBRMI_INBNDMSG7,
+	SBRMI_SW_INTERRUPT,
+};
+
+/* Each client has this additional data */
+struct sbrmi_data {
+	struct i2c_client *client;
+	struct mutex lock;
+	u32 pwr_limit_max;
+};
+
+struct sbrmi_mailbox_msg {
+	u8 cmd;
+	bool read;
+	u32 data_in;
+	u32 data_out;
+};
+
+static int sbrmi_enable_alert(struct i2c_client *client)
+{
+	int ctrl;
+
+	/*
+	 * Enable the SB-RMI Software alert status
+	 * by writing 0 to bit 4 of Control register(0x1)
+	 */
+	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
+	if (ctrl < 0)
+		return ctrl;
+
+	if (ctrl & 0x10) {
+		ctrl &= ~0x10;
+		return i2c_smbus_write_byte_data(client,
+						 SBRMI_CTRL, ctrl);
+	}
+
+	return 0;
+}
+
+static int rmi_mailbox_xfer(struct sbrmi_data *data,
+			    struct sbrmi_mailbox_msg *msg)
+{
+	int i, ret, retry = 10;
+	int sw_status;
+	u8 byte;
+
+	mutex_lock(&data->lock);
+
+	/* Indicate firmware a command is to be serviced */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG7, START_CMD);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/* Write the command to SBRMI::InBndMsg_inst0 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG0, msg->cmd);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * For both read and write the initiator (BMC) writes
+	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
+	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
+	 */
+	for (i = 0; i < 4; i++) {
+		byte = (msg->data_in >> i * 8) & 0xff;
+		ret = i2c_smbus_write_byte_data(data->client,
+						SBRMI_INBNDMSG1 + i, byte);
+		if (ret < 0)
+			goto exit_unlock;
+	}
+
+	/*
+	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
+	 * perform the requested read or write command
+	 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
+	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
+	 * of the requested command
+	 */
+	do {
+		sw_status = i2c_smbus_read_byte_data(data->client,
+						     SBRMI_STATUS);
+		if (sw_status < 0) {
+			ret = sw_status;
+			goto exit_unlock;
+		}
+		if (sw_status & SW_ALERT_MASK)
+			break;
+		usleep_range(50, 100);
+	} while (retry--);
+
+	if (retry < 0) {
+		dev_err(&data->client->dev,
+			"Firmware fail to indicate command completion\n");
+		ret = -EIO;
+		goto exit_unlock;
+	}
+
+	/*
+	 * For a read operation, the initiator (BMC) reads the firmware
+	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
+	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
+	 */
+	if (msg->read) {
+		for (i = 0; i < 4; i++) {
+			ret = i2c_smbus_read_byte_data(data->client,
+						       SBRMI_OUTBNDMSG1 + i);
+			if (ret < 0)
+				goto exit_unlock;
+			msg->data_out |= ret << i * 8;
+		}
+	}
+
+	/*
+	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
+	 * ALERT to initiator
+	 */
+	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
+					sw_status | SW_ALERT_MASK);
+
+exit_unlock:
+	mutex_unlock(&data->lock);
+	return ret;
+}
+
+static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
+		      u32 attr, int channel, long *val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	if (type != hwmon_power)
+		return -EINVAL;
+
+	msg.read = true;
+	switch (attr) {
+	case hwmon_power_input:
+		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap:
+		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap_max:
+		msg.data_out = data->pwr_limit_max;
+		break;
+	default:
+		return -EINVAL;
+	}
+	if (ret < 0)
+		return ret;
+	/* hwmon power attributes are in microWatt */
+	*val = (long)msg.data_out * 1000;
+	return ret;
+}
+
+static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
+		       u32 attr, int channel, long val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+
+	if (type != hwmon_power && attr != hwmon_power_cap)
+		return -EINVAL;
+	/*
+	 * hwmon power attributes are in microWatt
+	 * mailbox read/write is in mWatt
+	 */
+	val /= 1000;
+
+	val = clamp_val(val, SBRMI_PWR_MIN, data->pwr_limit_max);
+
+	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
+	msg.data_in = val;
+	msg.read = false;
+
+	return rmi_mailbox_xfer(data, &msg);
+}
+
+static umode_t sbrmi_is_visible(const void *data,
+				enum hwmon_sensor_types type,
+				u32 attr, int channel)
+{
+	switch (type) {
+	case hwmon_power:
+		switch (attr) {
+		case hwmon_power_input:
+		case hwmon_power_cap_max:
+			return 0444;
+		case hwmon_power_cap:
+			return 0644;
+		}
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static const struct hwmon_channel_info *sbrmi_info[] = {
+	HWMON_CHANNEL_INFO(power,
+			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
+	NULL
+};
+
+static const struct hwmon_ops sbrmi_hwmon_ops = {
+	.is_visible = sbrmi_is_visible,
+	.read = sbrmi_read,
+	.write = sbrmi_write,
+};
+
+static const struct hwmon_chip_info sbrmi_chip_info = {
+	.ops = &sbrmi_hwmon_ops,
+	.info = sbrmi_info,
+};
+
+static int sbrmi_get_max_pwr_limit(struct sbrmi_data *data)
+{
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+	msg.read = true;
+	ret = rmi_mailbox_xfer(data, &msg);
+	if (ret < 0)
+		return ret;
+	data->pwr_limit_max = msg.data_out;
+
+	return ret;
+}
+
+static int sbrmi_probe(struct i2c_client *client,
+		       const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct device *hwmon_dev;
+	struct sbrmi_data *data;
+	int ret;
+
+	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->client = client;
+	mutex_init(&data->lock);
+
+	/* Enable alert for SB-RMI sequence */
+	ret = sbrmi_enable_alert(client);
+	if (ret < 0)
+		return ret;
+
+	/* Cache maximum power limit */
+	ret = sbrmi_get_max_pwr_limit(data);
+	if (ret < 0)
+		return ret;
+
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+							 &sbrmi_chip_info, NULL);
+
+	return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id sbrmi_id[] = {
+	{"sbrmi", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sbrmi_id);
+
+static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
+	{
+		.compatible = "amd,sbrmi",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sbrmi_of_match);
+
+static struct i2c_driver sbrmi_driver = {
+	.class = I2C_CLASS_HWMON,
+	.driver = {
+		.name = "sbrmi",
+		.of_match_table = of_match_ptr(sbrmi_of_match),
+	},
+	.probe = sbrmi_probe,
+	.id_table = sbrmi_id,
+};
+
+module_i2c_driver(sbrmi_driver);
+
+MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
+MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
+MODULE_LICENSE("GPL");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v3 2/3] hwmon: sbrmi: Add Documentation
  2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
@ 2021-07-20  5:57   ` Naveen Krishna Chatradhi
  2021-07-25 21:40     ` Guenter Roeck
  2021-07-20  5:57   ` [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
  2021-07-25 21:38   ` [PATCH v3 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 1 reply; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-20  5:57 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Add documentation for sbrmi module

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v2:
None

 Documentation/hwmon/index.rst |  1 +
 Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/hwmon/sbrmi.rst

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 9ed60fa84cbe..5cd4798fe193 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
    q54sj108a2
    raspberrypi-hwmon
    sbtsi_temp
+   sbrmi
    sch5627
    sch5636
    scpi-hwmon
diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
new file mode 100644
index 000000000000..296049e13ac9
--- /dev/null
+++ b/Documentation/hwmon/sbrmi.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver sbrmi
+===================
+
+Supported hardware:
+
+  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
+    device connected to the BMC via the APML.
+
+    Prefix: 'sbrmi'
+
+    Addresses scanned: This driver doesn't support address scanning.
+
+    To instantiate this driver on an AMD CPU with SB-RMI
+    support, the i2c bus number would be the bus connected from the board
+    management controller (BMC) to the CPU.
+    The SMBus address is really 7 bits. Some vendors and the SMBus
+    specification show the address as 8 bits, left justified with the R/W
+    bit as a write (0) making bit 0. Some vendors use only the 7 bits
+    to describe the address.
+    As mentioned in AMD's APML specification, The SB-RMI address is
+    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
+    or 38h(011 1000) for socket 1, but it could vary based on hardware
+    address select pins.
+
+    Datasheet: The SB-RMI interface and protocol along with the Advanced
+               Platform Management Link (APML) Specification is available
+               as part of the open source SoC register reference at:
+
+               https://www.amd.com/en/support/tech-docs?keyword=55898
+
+Author: Akshay Gupta <akshay.gupta@amd.com>
+
+Description
+-----------
+
+The APML provides a way to communicate with the SB Remote Management interface
+(SB-RMI) module from the external SMBus master that can be used to report socket
+power on AMD platforms using mailbox command and resembles a typical 8-pin remote
+power sensor's I2C interface to BMC.
+
+This driver implements current power with power cap and power cap max.
+
+sysfs-Interface
+---------------
+Power sensors can be queried and set via the standard ``hwmon`` interface
+on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
+of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
+content ``sbrmi``)
+
+================ ===== ========================================================
+Name             Perm   Description
+================ ===== ========================================================
+power1_input     RO    Current Power consumed
+power1_cap       RW    Power limit can be set between 0 and power1_cap_max
+power1_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
+================ ===== ========================================================
+
+The following example show how the 'Power' attribute from the i2c-addresses
+can be monitored using the userspace utilities like ``sensors`` binary::
+
+  # sensors
+  sbrmi-i2c-1-38
+  Adapter: bcm2835 I2C adapter
+  power1:       61.00 W (cap = 225.00 W)
+
+  sbrmi-i2c-1-3c
+  Adapter: bcm2835 I2C adapter
+  power1:       28.39 W (cap = 224.77 W)
+  #
+
+Also, Below shows how get and set the values from sysfs entries individually::
+  # cat /sys/class/hwmon/hwmon1/power1_cap_max
+  225000000
+
+  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
+  # cat /sys/class/hwmon/hwmon1/power1_cap
+  180000000
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
  2021-07-20  5:57   ` [PATCH v3 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-07-20  5:57   ` Naveen Krishna Chatradhi
  2021-07-25 21:36     ` Guenter Roeck
  2021-07-25 21:38   ` [PATCH v3 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 1 reply; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-20  5:57 UTC (permalink / raw)
  To: linux-hwmon; +Cc: linux, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Document device tree bindings for AMD SB-RMI emulated service.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v2:
None

 .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
new file mode 100644
index 000000000000..7598b083979c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: >
+  Sideband Remote Management Interface (SB-RMI) compliant
+  AMD SoC power device.
+
+maintainers:
+  - Akshay Gupta <Akshay.Gupta@amd.com>
+
+description: |
+  SB Remote Management Interface (SB-RMI) is an SMBus compatible
+  interface that reports AMD SoC's Power (normalized Power) using,
+  Mailbox Service Request and resembles a typical 8-pin remote power
+  sensor's I2C interface to BMC. The power attributes in hwmon
+  reports power in microwatts.
+
+properties:
+  compatible:
+    enum:
+      - amd,sbrmi
+
+  reg:
+    maxItems: 1
+    description: |
+      I2C bus address of the device as specified in Section SBI SMBus Address
+      of the SoC register reference. The SB-RMI address is normally 78h for
+      socket 0 and 70h for socket 1, but it could vary based on hardware
+      address select pins.
+      \[open source SoC register reference\]
+        https://www.amd.com/en/support/tech-docs?keyword=55898
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c0 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sbrmi@3c {
+                compatible = "amd,sbrmi";
+                reg = <0x3c>;
+        };
+    };
+...
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-20  5:57   ` [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-07-25 21:36     ` Guenter Roeck
  2021-07-26  4:36       ` Chatradhi, Naveen Krishna
  0 siblings, 1 reply; 28+ messages in thread
From: Guenter Roeck @ 2021-07-25 21:36 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi, linux-hwmon; +Cc: Akshay Gupta

On 7/19/21 10:57 PM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> - Document device tree bindings for AMD SB-RMI emulated service.
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>

Devicetree files need to be approved by a dt maintainer.
They can't do that if they are not copied on devicetree patches.

Guenter

> ---
> Changes since v2:
> None
> 
>   .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
>   1 file changed, 53 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> new file mode 100644
> index 000000000000..7598b083979c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: >
> +  Sideband Remote Management Interface (SB-RMI) compliant
> +  AMD SoC power device.
> +
> +maintainers:
> +  - Akshay Gupta <Akshay.Gupta@amd.com>
> +
> +description: |
> +  SB Remote Management Interface (SB-RMI) is an SMBus compatible
> +  interface that reports AMD SoC's Power (normalized Power) using,
> +  Mailbox Service Request and resembles a typical 8-pin remote power
> +  sensor's I2C interface to BMC. The power attributes in hwmon
> +  reports power in microwatts.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - amd,sbrmi
> +
> +  reg:
> +    maxItems: 1
> +    description: |
> +      I2C bus address of the device as specified in Section SBI SMBus Address
> +      of the SoC register reference. The SB-RMI address is normally 78h for
> +      socket 0 and 70h for socket 1, but it could vary based on hardware
> +      address select pins.
> +      \[open source SoC register reference\]
> +        https://www.amd.com/en/support/tech-docs?keyword=55898
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c0 {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        sbrmi@3c {
> +                compatible = "amd,sbrmi";
> +                reg = <0x3c>;
> +        };
> +    };
> +...
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
  2021-07-20  5:57   ` [PATCH v3 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
  2021-07-20  5:57   ` [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-07-25 21:38   ` Guenter Roeck
  2 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-07-25 21:38 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi, linux-hwmon; +Cc: Akshay Gupta

On 7/19/21 10:57 PM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> On AMD platforms the Out-of-band access is provided by
> Advanced Platform Management Link (APML), APML is a
> SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
> 
> APML is used to communicate with the
> Side-Band Remote Management Interface (SB-RMI) which provides
> Soft Mailbox messages to manage power consumption and
> power limits of the CPU socket.
> 
> - This module add support to read power consumption,
>    power limit & max power limit and write power limit.
> - To instantiate this driver on a Board Management Controller (BMC)
>    connected to an AMD CPU with SB-RMI support, the i2c bus number
>    would be the bus connected from the BMC to the CPU.
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>

For my reference:

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

I can only apply the patch series after the bindings have been approved
by a devicetree maintainer.

Guenter

> ---
> Changes since v2:
> 1. Modify to cache the power_limi_max during probe
> 2. Enable alert during probe
> 3. Use dev_err instead of pr_err
> 4. Remove unnecessry bit mask
> 5. Checking rmi_mailbox_xfer retrun value
> 
>   drivers/hwmon/Kconfig  |  10 ++
>   drivers/hwmon/Makefile |   1 +
>   drivers/hwmon/sbrmi.c  | 358 +++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 369 insertions(+)
>   create mode 100644 drivers/hwmon/sbrmi.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 87624902ea80..f489972a6309 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>   	  This driver can also be built as a module. If so, the module will
>   	  be called sbtsi_temp.
>   
> +config SENSORS_SBRMI
> +	tristate "Emulated SB-RMI sensor"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for emulated RMI
> +	  sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called sbrmi.
> +
>   config SENSORS_SHT15
>   	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>   	depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
>   obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
>   obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>   obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
>   obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
> new file mode 100644
> index 000000000000..372b099c04a0
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +
> +/* Do not allow setting negative power limit */
> +#define SBRMI_PWR_MIN	0
> +/* Mask for Status Register bit[1] */
> +#define SW_ALERT_MASK	0x2
> +
> +/* Software Interrupt for triggering */
> +#define START_CMD	0x80
> +#define TRIGGER_MAILBOX	0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +	SBRMI_WRITE_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +	SBRMI_CTRL		= 0x01,
> +	SBRMI_STATUS,
> +	SBRMI_OUTBNDMSG0	= 0x30,
> +	SBRMI_OUTBNDMSG1,
> +	SBRMI_OUTBNDMSG2,
> +	SBRMI_OUTBNDMSG3,
> +	SBRMI_OUTBNDMSG4,
> +	SBRMI_OUTBNDMSG5,
> +	SBRMI_OUTBNDMSG6,
> +	SBRMI_OUTBNDMSG7,
> +	SBRMI_INBNDMSG0,
> +	SBRMI_INBNDMSG1,
> +	SBRMI_INBNDMSG2,
> +	SBRMI_INBNDMSG3,
> +	SBRMI_INBNDMSG4,
> +	SBRMI_INBNDMSG5,
> +	SBRMI_INBNDMSG6,
> +	SBRMI_INBNDMSG7,
> +	SBRMI_SW_INTERRUPT,
> +};
> +
> +/* Each client has this additional data */
> +struct sbrmi_data {
> +	struct i2c_client *client;
> +	struct mutex lock;
> +	u32 pwr_limit_max;
> +};
> +
> +struct sbrmi_mailbox_msg {
> +	u8 cmd;
> +	bool read;
> +	u32 data_in;
> +	u32 data_out;
> +};
> +
> +static int sbrmi_enable_alert(struct i2c_client *client)
> +{
> +	int ctrl;
> +
> +	/*
> +	 * Enable the SB-RMI Software alert status
> +	 * by writing 0 to bit 4 of Control register(0x1)
> +	 */
> +	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
> +	if (ctrl < 0)
> +		return ctrl;
> +
> +	if (ctrl & 0x10) {
> +		ctrl &= ~0x10;
> +		return i2c_smbus_write_byte_data(client,
> +						 SBRMI_CTRL, ctrl);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +			    struct sbrmi_mailbox_msg *msg)
> +{
> +	int i, ret, retry = 10;
> +	int sw_status;
> +	u8 byte;
> +
> +	mutex_lock(&data->lock);
> +
> +	/* Indicate firmware a command is to be serviced */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG7, START_CMD);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/* Write the command to SBRMI::InBndMsg_inst0 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG0, msg->cmd);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * For both read and write the initiator (BMC) writes
> +	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +	 */
> +	for (i = 0; i < 4; i++) {
> +		byte = (msg->data_in >> i * 8) & 0xff;
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						SBRMI_INBNDMSG1 + i, byte);
> +		if (ret < 0)
> +			goto exit_unlock;
> +	}
> +
> +	/*
> +	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +	 * perform the requested read or write command
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +	 * of the requested command
> +	 */
> +	do {
> +		sw_status = i2c_smbus_read_byte_data(data->client,
> +						     SBRMI_STATUS);
> +		if (sw_status < 0) {
> +			ret = sw_status;
> +			goto exit_unlock;
> +		}
> +		if (sw_status & SW_ALERT_MASK)
> +			break;
> +		usleep_range(50, 100);
> +	} while (retry--);
> +
> +	if (retry < 0) {
> +		dev_err(&data->client->dev,
> +			"Firmware fail to indicate command completion\n");
> +		ret = -EIO;
> +		goto exit_unlock;
> +	}
> +
> +	/*
> +	 * For a read operation, the initiator (BMC) reads the firmware
> +	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +	 */
> +	if (msg->read) {
> +		for (i = 0; i < 4; i++) {
> +			ret = i2c_smbus_read_byte_data(data->client,
> +						       SBRMI_OUTBNDMSG1 + i);
> +			if (ret < 0)
> +				goto exit_unlock;
> +			msg->data_out |= ret << i * 8;
> +		}
> +	}
> +
> +	/*
> +	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +	 * ALERT to initiator
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +					sw_status | SW_ALERT_MASK);
> +
> +exit_unlock:
> +	mutex_unlock(&data->lock);
> +	return ret;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +		      u32 attr, int channel, long *val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	if (type != hwmon_power)
> +		return -EINVAL;
> +
> +	msg.read = true;
> +	switch (attr) {
> +	case hwmon_power_input:
> +		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap:
> +		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap_max:
> +		msg.data_out = data->pwr_limit_max;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	if (ret < 0)
> +		return ret;
> +	/* hwmon power attributes are in microWatt */
> +	*val = (long)msg.data_out * 1000;
> +	return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +		       u32 attr, int channel, long val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +
> +	if (type != hwmon_power && attr != hwmon_power_cap)
> +		return -EINVAL;
> +	/*
> +	 * hwmon power attributes are in microWatt
> +	 * mailbox read/write is in mWatt
> +	 */
> +	val /= 1000;
> +
> +	val = clamp_val(val, SBRMI_PWR_MIN, data->pwr_limit_max);
> +
> +	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +	msg.data_in = val;
> +	msg.read = false;
> +
> +	return rmi_mailbox_xfer(data, &msg);
> +}
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +				enum hwmon_sensor_types type,
> +				u32 attr, int channel)
> +{
> +	switch (type) {
> +	case hwmon_power:
> +		switch (attr) {
> +		case hwmon_power_input:
> +		case hwmon_power_cap_max:
> +			return 0444;
> +		case hwmon_power_cap:
> +			return 0644;
> +		}
> +		break;
> +	default:
> +		break;
> +	}
> +	return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +	HWMON_CHANNEL_INFO(power,
> +			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +	NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +	.is_visible = sbrmi_is_visible,
> +	.read = sbrmi_read,
> +	.write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +	.ops = &sbrmi_hwmon_ops,
> +	.info = sbrmi_info,
> +};
> +
> +static int sbrmi_get_max_pwr_limit(struct sbrmi_data *data)
> +{
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +	msg.read = true;
> +	ret = rmi_mailbox_xfer(data, &msg);
> +	if (ret < 0)
> +		return ret;
> +	data->pwr_limit_max = msg.data_out;
> +
> +	return ret;
> +}
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +		       const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct device *hwmon_dev;
> +	struct sbrmi_data *data;
> +	int ret;
> +
> +	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->client = client;
> +	mutex_init(&data->lock);
> +
> +	/* Enable alert for SB-RMI sequence */
> +	ret = sbrmi_enable_alert(client);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Cache maximum power limit */
> +	ret = sbrmi_get_max_pwr_limit(data);
> +	if (ret < 0)
> +		return ret;
> +
> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +							 &sbrmi_chip_info, NULL);
> +
> +	return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +	{"sbrmi", 0},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +	{
> +		.compatible = "amd,sbrmi",
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +	.class = I2C_CLASS_HWMON,
> +	.driver = {
> +		.name = "sbrmi",
> +		.of_match_table = of_match_ptr(sbrmi_of_match),
> +	},
> +	.probe = sbrmi_probe,
> +	.id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
> +MODULE_LICENSE("GPL");
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 2/3] hwmon: sbrmi: Add Documentation
  2021-07-20  5:57   ` [PATCH v3 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-07-25 21:40     ` Guenter Roeck
  0 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-07-25 21:40 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi, linux-hwmon; +Cc: Akshay Gupta

On 7/19/21 10:57 PM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> - Add documentation for sbrmi module
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
> Changes since v2:
> None
> 
>   Documentation/hwmon/index.rst |  1 +
>   Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
>   2 files changed, 80 insertions(+)
>   create mode 100644 Documentation/hwmon/sbrmi.rst
> 
> diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
> index 9ed60fa84cbe..5cd4798fe193 100644
> --- a/Documentation/hwmon/index.rst
> +++ b/Documentation/hwmon/index.rst
> @@ -158,6 +158,7 @@ Hardware Monitoring Kernel Drivers
>      q54sj108a2
>      raspberrypi-hwmon
>      sbtsi_temp
> +   sbrmi

alphabetic order, please.

Other than that, for my reference,

Reviewed-by: Guenter Roeck <linux@roeck-us.net>

>      sch5627
>      sch5636
>      scpi-hwmon
> diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
> new file mode 100644
> index 000000000000..296049e13ac9
> --- /dev/null
> +++ b/Documentation/hwmon/sbrmi.rst
> @@ -0,0 +1,79 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +Kernel driver sbrmi
> +===================
> +
> +Supported hardware:
> +
> +  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
> +    device connected to the BMC via the APML.
> +
> +    Prefix: 'sbrmi'
> +
> +    Addresses scanned: This driver doesn't support address scanning.
> +
> +    To instantiate this driver on an AMD CPU with SB-RMI
> +    support, the i2c bus number would be the bus connected from the board
> +    management controller (BMC) to the CPU.
> +    The SMBus address is really 7 bits. Some vendors and the SMBus
> +    specification show the address as 8 bits, left justified with the R/W
> +    bit as a write (0) making bit 0. Some vendors use only the 7 bits
> +    to describe the address.
> +    As mentioned in AMD's APML specification, The SB-RMI address is
> +    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
> +    or 38h(011 1000) for socket 1, but it could vary based on hardware
> +    address select pins.
> +
> +    Datasheet: The SB-RMI interface and protocol along with the Advanced
> +               Platform Management Link (APML) Specification is available
> +               as part of the open source SoC register reference at:
> +
> +               https://www.amd.com/en/support/tech-docs?keyword=55898
> +
> +Author: Akshay Gupta <akshay.gupta@amd.com>
> +
> +Description
> +-----------
> +
> +The APML provides a way to communicate with the SB Remote Management interface
> +(SB-RMI) module from the external SMBus master that can be used to report socket
> +power on AMD platforms using mailbox command and resembles a typical 8-pin remote
> +power sensor's I2C interface to BMC.
> +
> +This driver implements current power with power cap and power cap max.
> +
> +sysfs-Interface
> +---------------
> +Power sensors can be queried and set via the standard ``hwmon`` interface
> +on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
> +of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
> +content ``sbrmi``)
> +
> +================ ===== ========================================================
> +Name             Perm   Description
> +================ ===== ========================================================
> +power1_input     RO    Current Power consumed
> +power1_cap       RW    Power limit can be set between 0 and power1_cap_max
> +power1_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
> +================ ===== ========================================================
> +
> +The following example show how the 'Power' attribute from the i2c-addresses
> +can be monitored using the userspace utilities like ``sensors`` binary::
> +
> +  # sensors
> +  sbrmi-i2c-1-38
> +  Adapter: bcm2835 I2C adapter
> +  power1:       61.00 W (cap = 225.00 W)
> +
> +  sbrmi-i2c-1-3c
> +  Adapter: bcm2835 I2C adapter
> +  power1:       28.39 W (cap = 224.77 W)
> +  #
> +
> +Also, Below shows how get and set the values from sysfs entries individually::
> +  # cat /sys/class/hwmon/hwmon1/power1_cap_max
> +  225000000
> +
> +  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
> +  # cat /sys/class/hwmon/hwmon1/power1_cap
> +  180000000
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

* RE: [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-25 21:36     ` Guenter Roeck
@ 2021-07-26  4:36       ` Chatradhi, Naveen Krishna
  2021-07-26  4:58         ` Guenter Roeck
  0 siblings, 1 reply; 28+ messages in thread
From: Chatradhi, Naveen Krishna @ 2021-07-26  4:36 UTC (permalink / raw)
  To: Guenter Roeck, linux-hwmon; +Cc: Gupta, Akshay

[AMD Official Use Only]

Hi Guenter,

Regards,
Naveenk

-----Original Message-----
From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
Sent: Monday, July 26, 2021 3:07 AM
To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
Subject: Re: [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings

[CAUTION: External Email]

On 7/19/21 10:57 PM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
>
> - Document device tree bindings for AMD SB-RMI emulated service.
>
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>

Devicetree files need to be approved by a dt maintainer.
They can't do that if they are not copied on devicetree patches.
[naveenk:] Yes, my bad. Can I add the devicetree list now here or should I submit v4
of the patch-set with your reviewed-by on other 2 patches and copying the devicetree list.

Guenter

> ---
> Changes since v2:
> None
>
>   .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
>   1 file changed, 53 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
>
> diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml 
> b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> new file mode 100644
> index 000000000000..7598b083979c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> +---
> +$id: 
> +https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fschemas%2Fhwmon%2Famd%2Csbrmi.yaml%23&amp;data=04%7C01%7
> +CNaveenKrishna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94fb456ac
> +%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637628458245183191%7CUn
> +known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> +WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Xwsc2G6T34oiV4aTzYLEb%2FLpoTj%2BW%
> +2B6LmRkAFyeauQ8%3D&amp;reserved=0
> +$schema: 
> +https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=04%7C01%7CNaveenKri
> +shna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94fb456ac%7C3dd8961
> +fe4884e608e11a82d994e183d%7C0%7C0%7C637628458245183191%7CUnknown%7CTW
> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> +6Mn0%3D%7C1000&amp;sdata=ieeFYJjYCyDzHrcGjvHWkkU6QHqXcBqOa4Kfsmqk3Ek%
> +3D&amp;reserved=0
> +
> +title: >
> +  Sideband Remote Management Interface (SB-RMI) compliant
> +  AMD SoC power device.
> +
> +maintainers:
> +  - Akshay Gupta <Akshay.Gupta@amd.com>
> +
> +description: |
> +  SB Remote Management Interface (SB-RMI) is an SMBus compatible
> +  interface that reports AMD SoC's Power (normalized Power) using,
> +  Mailbox Service Request and resembles a typical 8-pin remote power
> +  sensor's I2C interface to BMC. The power attributes in hwmon
> +  reports power in microwatts.
> +
> +properties:
> +  compatible:
> +    enum:
> +      - amd,sbrmi
> +
> +  reg:
> +    maxItems: 1
> +    description: |
> +      I2C bus address of the device as specified in Section SBI SMBus Address
> +      of the SoC register reference. The SB-RMI address is normally 78h for
> +      socket 0 and 70h for socket 1, but it could vary based on hardware
> +      address select pins.
> +      \[open source SoC register reference\]
> +        
> + https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> + w.amd.com%2Fen%2Fsupport%2Ftech-docs%3Fkeyword%3D55898&amp;data=04%7
> + C01%7CNaveenKrishna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94f
> + b456ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6376284582451831
> + 91%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
> + iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eG384k%2FtNMNJD17u7qdIhjI
> + p2sz%2B6Qs5PpAprL54saU%3D&amp;reserved=0
> +
> +required:
> +  - compatible
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    i2c0 {
> +        #address-cells = <1>;
> +        #size-cells = <0>;
> +
> +        sbrmi@3c {
> +                compatible = "amd,sbrmi";
> +                reg = <0x3c>;
> +        };
> +    };
> +...
>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-26  4:36       ` Chatradhi, Naveen Krishna
@ 2021-07-26  4:58         ` Guenter Roeck
  0 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-07-26  4:58 UTC (permalink / raw)
  To: Chatradhi, Naveen Krishna, linux-hwmon; +Cc: Gupta, Akshay

On 7/25/21 9:36 PM, Chatradhi, Naveen Krishna wrote:
> [AMD Official Use Only]
> 

You really should get rid of this...

> Hi Guenter,
> 
> Regards,
> Naveenk
> 
> -----Original Message-----
> From: Guenter Roeck <groeck7@gmail.com> On Behalf Of Guenter Roeck
> Sent: Monday, July 26, 2021 3:07 AM
> To: Chatradhi, Naveen Krishna <NaveenKrishna.Chatradhi@amd.com>; linux-hwmon@vger.kernel.org
> Cc: Gupta, Akshay <Akshay.Gupta@amd.com>
> Subject: Re: [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
> 
> [CAUTION: External Email]
> 
> On 7/19/21 10:57 PM, Naveen Krishna Chatradhi wrote:
>> From: Akshay Gupta <Akshay.Gupta@amd.com>
>>
>> - Document device tree bindings for AMD SB-RMI emulated service.
>>
>> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
>> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> 
> Devicetree files need to be approved by a dt maintainer.
> They can't do that if they are not copied on devicetree patches.
> [naveenk:] Yes, my bad. Can I add the devicetree list now here or should I submit v4
> of the patch-set with your reviewed-by on other 2 patches and copying the devicetree list.
> 

Probably better to submit v4

Guenter

> Guenter
> 
>> ---
>> Changes since v2:
>> None
>>
>>    .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
>>    1 file changed, 53 insertions(+)
>>    create mode 100644
>> Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
>> b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
>> new file mode 100644
>> index 000000000000..7598b083979c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
>> @@ -0,0 +1,53 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
>> +---
>> +$id:
>> +https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
>> +cetree.org%2Fschemas%2Fhwmon%2Famd%2Csbrmi.yaml%23&amp;data=04%7C01%7
>> +CNaveenKrishna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94fb456ac
>> +%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637628458245183191%7CUn
>> +known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> +WwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Xwsc2G6T34oiV4aTzYLEb%2FLpoTj%2BW%
>> +2B6LmRkAFyeauQ8%3D&amp;reserved=0
>> +$schema:
>> +https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
>> +cetree.org%2Fmeta-schemas%2Fcore.yaml%23&amp;data=04%7C01%7CNaveenKri
>> +shna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94fb456ac%7C3dd8961
>> +fe4884e608e11a82d994e183d%7C0%7C0%7C637628458245183191%7CUnknown%7CTW
>> +FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
>> +6Mn0%3D%7C1000&amp;sdata=ieeFYJjYCyDzHrcGjvHWkkU6QHqXcBqOa4Kfsmqk3Ek%
>> +3D&amp;reserved=0
>> +
>> +title: >
>> +  Sideband Remote Management Interface (SB-RMI) compliant
>> +  AMD SoC power device.
>> +
>> +maintainers:
>> +  - Akshay Gupta <Akshay.Gupta@amd.com>
>> +
>> +description: |
>> +  SB Remote Management Interface (SB-RMI) is an SMBus compatible
>> +  interface that reports AMD SoC's Power (normalized Power) using,
>> +  Mailbox Service Request and resembles a typical 8-pin remote power
>> +  sensor's I2C interface to BMC. The power attributes in hwmon
>> +  reports power in microwatts.
>> +
>> +properties:
>> +  compatible:
>> +    enum:
>> +      - amd,sbrmi
>> +
>> +  reg:
>> +    maxItems: 1
>> +    description: |
>> +      I2C bus address of the device as specified in Section SBI SMBus Address
>> +      of the SoC register reference. The SB-RMI address is normally 78h for
>> +      socket 0 and 70h for socket 1, but it could vary based on hardware
>> +      address select pins.
>> +      \[open source SoC register reference\]
>> +
>> + https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>> + w.amd.com%2Fen%2Fsupport%2Ftech-docs%3Fkeyword%3D55898&amp;data=04%7
>> + C01%7CNaveenKrishna.Chatradhi%40amd.com%7C8a8332e2358f4c37030d08d94f
>> + b456ac%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6376284582451831
>> + 91%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBT
>> + iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=eG384k%2FtNMNJD17u7qdIhjI
>> + p2sz%2B6Qs5PpAprL54saU%3D&amp;reserved=0
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    i2c0 {
>> +        #address-cells = <1>;
>> +        #size-cells = <0>;
>> +
>> +        sbrmi@3c {
>> +                compatible = "amd,sbrmi";
>> +                reg = <0x3c>;
>> +        };
>> +    };
>> +...
>>


^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH v4 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
                   ` (4 preceding siblings ...)
  2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
@ 2021-07-26 13:36 ` Naveen Krishna Chatradhi
  2021-07-26 13:36   ` [PATCH v4 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
                     ` (2 more replies)
  5 siblings, 3 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-26 13:36 UTC (permalink / raw)
  To: linux-hwmon, devicetree
  Cc: linux, robh, jdelvare, broonie, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

On AMD platforms the Out-of-band access is provided by
Advanced Platform Management Link (APML), APML is a
SMBus v2.0 compatible 2-wire processor client interface.
APML is also referred as the sideband interface (SBI).

APML is used to communicate with the
Side-Band Remote Management Interface (SB-RMI) which provides
Soft Mailbox messages to manage power consumption and
power limits of the CPU socket.

- This module add support to read power consumption,
  power limit & max power limit and write power limit.
- To instantiate this driver on a Board Management Controller (BMC)
  connected to an AMD CPU with SB-RMI support, the i2c bus number
  would be the bus connected from the BMC to the CPU.

Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v3:
Added reviewed by Guenter Roeck

 drivers/hwmon/Kconfig  |  10 ++
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/sbrmi.c  | 358 +++++++++++++++++++++++++++++++++++++++++
 3 files changed, 369 insertions(+)
 create mode 100644 drivers/hwmon/sbrmi.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 87624902ea80..f489972a6309 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
 	  This driver can also be built as a module. If so, the module will
 	  be called sbtsi_temp.
 
+config SENSORS_SBRMI
+	tristate "Emulated SB-RMI sensor"
+	depends on I2C
+	help
+	  If you say yes here you get support for emulated RMI
+	  sensors on AMD SoCs with APML interface connected to a BMC device.
+
+	  This driver can also be built as a module. If so, the module will
+	  be called sbrmi.
+
 config SENSORS_SHT15
 	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
 	depends on GPIOLIB || COMPILE_TEST
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 59e78bc212cf..8031acf58936 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
 obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
 obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
 obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
+obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
 obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
 obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
 obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
new file mode 100644
index 000000000000..372b099c04a0
--- /dev/null
+++ b/drivers/hwmon/sbrmi.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sbrmi.c - hwmon driver for a SB-RMI mailbox
+ *           compliant AMD SoC device.
+ *
+ * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
+ */
+
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+
+/* Do not allow setting negative power limit */
+#define SBRMI_PWR_MIN	0
+/* Mask for Status Register bit[1] */
+#define SW_ALERT_MASK	0x2
+
+/* Software Interrupt for triggering */
+#define START_CMD	0x80
+#define TRIGGER_MAILBOX	0x01
+
+/*
+ * SB-RMI supports soft mailbox service request to MP1 (power management
+ * firmware) through SBRMI inbound/outbound message registers.
+ * SB-RMI message IDs
+ */
+enum sbrmi_msg_id {
+	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
+	SBRMI_WRITE_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_PWR_LIMIT,
+	SBRMI_READ_PKG_MAX_PWR_LIMIT,
+};
+
+/* SB-RMI registers */
+enum sbrmi_reg {
+	SBRMI_CTRL		= 0x01,
+	SBRMI_STATUS,
+	SBRMI_OUTBNDMSG0	= 0x30,
+	SBRMI_OUTBNDMSG1,
+	SBRMI_OUTBNDMSG2,
+	SBRMI_OUTBNDMSG3,
+	SBRMI_OUTBNDMSG4,
+	SBRMI_OUTBNDMSG5,
+	SBRMI_OUTBNDMSG6,
+	SBRMI_OUTBNDMSG7,
+	SBRMI_INBNDMSG0,
+	SBRMI_INBNDMSG1,
+	SBRMI_INBNDMSG2,
+	SBRMI_INBNDMSG3,
+	SBRMI_INBNDMSG4,
+	SBRMI_INBNDMSG5,
+	SBRMI_INBNDMSG6,
+	SBRMI_INBNDMSG7,
+	SBRMI_SW_INTERRUPT,
+};
+
+/* Each client has this additional data */
+struct sbrmi_data {
+	struct i2c_client *client;
+	struct mutex lock;
+	u32 pwr_limit_max;
+};
+
+struct sbrmi_mailbox_msg {
+	u8 cmd;
+	bool read;
+	u32 data_in;
+	u32 data_out;
+};
+
+static int sbrmi_enable_alert(struct i2c_client *client)
+{
+	int ctrl;
+
+	/*
+	 * Enable the SB-RMI Software alert status
+	 * by writing 0 to bit 4 of Control register(0x1)
+	 */
+	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
+	if (ctrl < 0)
+		return ctrl;
+
+	if (ctrl & 0x10) {
+		ctrl &= ~0x10;
+		return i2c_smbus_write_byte_data(client,
+						 SBRMI_CTRL, ctrl);
+	}
+
+	return 0;
+}
+
+static int rmi_mailbox_xfer(struct sbrmi_data *data,
+			    struct sbrmi_mailbox_msg *msg)
+{
+	int i, ret, retry = 10;
+	int sw_status;
+	u8 byte;
+
+	mutex_lock(&data->lock);
+
+	/* Indicate firmware a command is to be serviced */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG7, START_CMD);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/* Write the command to SBRMI::InBndMsg_inst0 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_INBNDMSG0, msg->cmd);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * For both read and write the initiator (BMC) writes
+	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
+	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
+	 */
+	for (i = 0; i < 4; i++) {
+		byte = (msg->data_in >> i * 8) & 0xff;
+		ret = i2c_smbus_write_byte_data(data->client,
+						SBRMI_INBNDMSG1 + i, byte);
+		if (ret < 0)
+			goto exit_unlock;
+	}
+
+	/*
+	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
+	 * perform the requested read or write command
+	 */
+	ret = i2c_smbus_write_byte_data(data->client,
+					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
+	if (ret < 0)
+		goto exit_unlock;
+
+	/*
+	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
+	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
+	 * of the requested command
+	 */
+	do {
+		sw_status = i2c_smbus_read_byte_data(data->client,
+						     SBRMI_STATUS);
+		if (sw_status < 0) {
+			ret = sw_status;
+			goto exit_unlock;
+		}
+		if (sw_status & SW_ALERT_MASK)
+			break;
+		usleep_range(50, 100);
+	} while (retry--);
+
+	if (retry < 0) {
+		dev_err(&data->client->dev,
+			"Firmware fail to indicate command completion\n");
+		ret = -EIO;
+		goto exit_unlock;
+	}
+
+	/*
+	 * For a read operation, the initiator (BMC) reads the firmware
+	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
+	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
+	 */
+	if (msg->read) {
+		for (i = 0; i < 4; i++) {
+			ret = i2c_smbus_read_byte_data(data->client,
+						       SBRMI_OUTBNDMSG1 + i);
+			if (ret < 0)
+				goto exit_unlock;
+			msg->data_out |= ret << i * 8;
+		}
+	}
+
+	/*
+	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
+	 * ALERT to initiator
+	 */
+	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
+					sw_status | SW_ALERT_MASK);
+
+exit_unlock:
+	mutex_unlock(&data->lock);
+	return ret;
+}
+
+static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
+		      u32 attr, int channel, long *val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	if (type != hwmon_power)
+		return -EINVAL;
+
+	msg.read = true;
+	switch (attr) {
+	case hwmon_power_input:
+		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap:
+		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
+		ret = rmi_mailbox_xfer(data, &msg);
+		break;
+	case hwmon_power_cap_max:
+		msg.data_out = data->pwr_limit_max;
+		break;
+	default:
+		return -EINVAL;
+	}
+	if (ret < 0)
+		return ret;
+	/* hwmon power attributes are in microWatt */
+	*val = (long)msg.data_out * 1000;
+	return ret;
+}
+
+static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
+		       u32 attr, int channel, long val)
+{
+	struct sbrmi_data *data = dev_get_drvdata(dev);
+	struct sbrmi_mailbox_msg msg = { 0 };
+
+	if (type != hwmon_power && attr != hwmon_power_cap)
+		return -EINVAL;
+	/*
+	 * hwmon power attributes are in microWatt
+	 * mailbox read/write is in mWatt
+	 */
+	val /= 1000;
+
+	val = clamp_val(val, SBRMI_PWR_MIN, data->pwr_limit_max);
+
+	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
+	msg.data_in = val;
+	msg.read = false;
+
+	return rmi_mailbox_xfer(data, &msg);
+}
+
+static umode_t sbrmi_is_visible(const void *data,
+				enum hwmon_sensor_types type,
+				u32 attr, int channel)
+{
+	switch (type) {
+	case hwmon_power:
+		switch (attr) {
+		case hwmon_power_input:
+		case hwmon_power_cap_max:
+			return 0444;
+		case hwmon_power_cap:
+			return 0644;
+		}
+		break;
+	default:
+		break;
+	}
+	return 0;
+}
+
+static const struct hwmon_channel_info *sbrmi_info[] = {
+	HWMON_CHANNEL_INFO(power,
+			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
+	NULL
+};
+
+static const struct hwmon_ops sbrmi_hwmon_ops = {
+	.is_visible = sbrmi_is_visible,
+	.read = sbrmi_read,
+	.write = sbrmi_write,
+};
+
+static const struct hwmon_chip_info sbrmi_chip_info = {
+	.ops = &sbrmi_hwmon_ops,
+	.info = sbrmi_info,
+};
+
+static int sbrmi_get_max_pwr_limit(struct sbrmi_data *data)
+{
+	struct sbrmi_mailbox_msg msg = { 0 };
+	int ret;
+
+	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
+	msg.read = true;
+	ret = rmi_mailbox_xfer(data, &msg);
+	if (ret < 0)
+		return ret;
+	data->pwr_limit_max = msg.data_out;
+
+	return ret;
+}
+
+static int sbrmi_probe(struct i2c_client *client,
+		       const struct i2c_device_id *id)
+{
+	struct device *dev = &client->dev;
+	struct device *hwmon_dev;
+	struct sbrmi_data *data;
+	int ret;
+
+	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
+	if (!data)
+		return -ENOMEM;
+
+	data->client = client;
+	mutex_init(&data->lock);
+
+	/* Enable alert for SB-RMI sequence */
+	ret = sbrmi_enable_alert(client);
+	if (ret < 0)
+		return ret;
+
+	/* Cache maximum power limit */
+	ret = sbrmi_get_max_pwr_limit(data);
+	if (ret < 0)
+		return ret;
+
+	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+							 &sbrmi_chip_info, NULL);
+
+	return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id sbrmi_id[] = {
+	{"sbrmi", 0},
+	{}
+};
+MODULE_DEVICE_TABLE(i2c, sbrmi_id);
+
+static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
+	{
+		.compatible = "amd,sbrmi",
+	},
+	{ },
+};
+MODULE_DEVICE_TABLE(of, sbrmi_of_match);
+
+static struct i2c_driver sbrmi_driver = {
+	.class = I2C_CLASS_HWMON,
+	.driver = {
+		.name = "sbrmi",
+		.of_match_table = of_match_ptr(sbrmi_of_match),
+	},
+	.probe = sbrmi_probe,
+	.id_table = sbrmi_id,
+};
+
+module_i2c_driver(sbrmi_driver);
+
+MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
+MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
+MODULE_LICENSE("GPL");
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 2/3] hwmon: sbrmi: Add Documentation
  2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
@ 2021-07-26 13:36   ` Naveen Krishna Chatradhi
  2021-07-26 13:36   ` [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
  2021-07-28 16:57   ` [PATCH v4 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 0 replies; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-26 13:36 UTC (permalink / raw)
  To: linux-hwmon, devicetree
  Cc: linux, robh, jdelvare, broonie, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Add documentation for sbrmi module

Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v3:
1. Maintain alphabetical order
2. Added reviewed by Guenter Roeck

 Documentation/hwmon/index.rst |  1 +
 Documentation/hwmon/sbrmi.rst | 79 +++++++++++++++++++++++++++++++++++
 2 files changed, 80 insertions(+)
 create mode 100644 Documentation/hwmon/sbrmi.rst

diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index bc01601ea81a..470f2c50ecc2 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -160,6 +160,7 @@ Hardware Monitoring Kernel Drivers
    pwm-fan
    q54sj108a2
    raspberrypi-hwmon
+   sbrmi
    sbtsi_temp
    sch5627
    sch5636
diff --git a/Documentation/hwmon/sbrmi.rst b/Documentation/hwmon/sbrmi.rst
new file mode 100644
index 000000000000..296049e13ac9
--- /dev/null
+++ b/Documentation/hwmon/sbrmi.rst
@@ -0,0 +1,79 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver sbrmi
+===================
+
+Supported hardware:
+
+  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
+    device connected to the BMC via the APML.
+
+    Prefix: 'sbrmi'
+
+    Addresses scanned: This driver doesn't support address scanning.
+
+    To instantiate this driver on an AMD CPU with SB-RMI
+    support, the i2c bus number would be the bus connected from the board
+    management controller (BMC) to the CPU.
+    The SMBus address is really 7 bits. Some vendors and the SMBus
+    specification show the address as 8 bits, left justified with the R/W
+    bit as a write (0) making bit 0. Some vendors use only the 7 bits
+    to describe the address.
+    As mentioned in AMD's APML specification, The SB-RMI address is
+    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
+    or 38h(011 1000) for socket 1, but it could vary based on hardware
+    address select pins.
+
+    Datasheet: The SB-RMI interface and protocol along with the Advanced
+               Platform Management Link (APML) Specification is available
+               as part of the open source SoC register reference at:
+
+               https://www.amd.com/en/support/tech-docs?keyword=55898
+
+Author: Akshay Gupta <akshay.gupta@amd.com>
+
+Description
+-----------
+
+The APML provides a way to communicate with the SB Remote Management interface
+(SB-RMI) module from the external SMBus master that can be used to report socket
+power on AMD platforms using mailbox command and resembles a typical 8-pin remote
+power sensor's I2C interface to BMC.
+
+This driver implements current power with power cap and power cap max.
+
+sysfs-Interface
+---------------
+Power sensors can be queried and set via the standard ``hwmon`` interface
+on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
+of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
+content ``sbrmi``)
+
+================ ===== ========================================================
+Name             Perm   Description
+================ ===== ========================================================
+power1_input     RO    Current Power consumed
+power1_cap       RW    Power limit can be set between 0 and power1_cap_max
+power1_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
+================ ===== ========================================================
+
+The following example show how the 'Power' attribute from the i2c-addresses
+can be monitored using the userspace utilities like ``sensors`` binary::
+
+  # sensors
+  sbrmi-i2c-1-38
+  Adapter: bcm2835 I2C adapter
+  power1:       61.00 W (cap = 225.00 W)
+
+  sbrmi-i2c-1-3c
+  Adapter: bcm2835 I2C adapter
+  power1:       28.39 W (cap = 224.77 W)
+  #
+
+Also, Below shows how get and set the values from sysfs entries individually::
+  # cat /sys/class/hwmon/hwmon1/power1_cap_max
+  225000000
+
+  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
+  # cat /sys/class/hwmon/hwmon1/power1_cap
+  180000000
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
  2021-07-26 13:36   ` [PATCH v4 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
@ 2021-07-26 13:36   ` Naveen Krishna Chatradhi
  2021-07-26 22:43     ` Rob Herring
  2021-07-28 16:57   ` [PATCH v4 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
  2 siblings, 1 reply; 28+ messages in thread
From: Naveen Krishna Chatradhi @ 2021-07-26 13:36 UTC (permalink / raw)
  To: linux-hwmon, devicetree
  Cc: linux, robh, jdelvare, broonie, Akshay Gupta, Naveen Krishna Chatradhi

From: Akshay Gupta <Akshay.Gupta@amd.com>

- Document device tree bindings for AMD SB-RMI emulated service.

Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
---
Changes since v3:
None

 .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml

diff --git a/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
new file mode 100644
index 000000000000..7598b083979c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/amd,sbrmi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: >
+  Sideband Remote Management Interface (SB-RMI) compliant
+  AMD SoC power device.
+
+maintainers:
+  - Akshay Gupta <Akshay.Gupta@amd.com>
+
+description: |
+  SB Remote Management Interface (SB-RMI) is an SMBus compatible
+  interface that reports AMD SoC's Power (normalized Power) using,
+  Mailbox Service Request and resembles a typical 8-pin remote power
+  sensor's I2C interface to BMC. The power attributes in hwmon
+  reports power in microwatts.
+
+properties:
+  compatible:
+    enum:
+      - amd,sbrmi
+
+  reg:
+    maxItems: 1
+    description: |
+      I2C bus address of the device as specified in Section SBI SMBus Address
+      of the SoC register reference. The SB-RMI address is normally 78h for
+      socket 0 and 70h for socket 1, but it could vary based on hardware
+      address select pins.
+      \[open source SoC register reference\]
+        https://www.amd.com/en/support/tech-docs?keyword=55898
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+    i2c0 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        sbrmi@3c {
+                compatible = "amd,sbrmi";
+                reg = <0x3c>;
+        };
+    };
+...
-- 
2.17.1


^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings
  2021-07-26 13:36   ` [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-07-26 22:43     ` Rob Herring
  0 siblings, 0 replies; 28+ messages in thread
From: Rob Herring @ 2021-07-26 22:43 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi
  Cc: devicetree, jdelvare, Akshay Gupta, broonie, linux, linux-hwmon

On Mon, 26 Jul 2021 19:06:15 +0530, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> - Document device tree bindings for AMD SB-RMI emulated service.
> 
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>
> ---
> Changes since v3:
> None
> 
>  .../devicetree/bindings/hwmon/amd,sbrmi.yaml  | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/amd,sbrmi.yaml
> 

Reviewed-by: Rob Herring <robh@kernel.org>

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH v4 1/3] hwmon: sbrmi: Add support for sbrmi power module
  2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
  2021-07-26 13:36   ` [PATCH v4 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
  2021-07-26 13:36   ` [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
@ 2021-07-28 16:57   ` Guenter Roeck
  2 siblings, 0 replies; 28+ messages in thread
From: Guenter Roeck @ 2021-07-28 16:57 UTC (permalink / raw)
  To: Naveen Krishna Chatradhi, linux-hwmon, devicetree
  Cc: robh, jdelvare, broonie, Akshay Gupta

On 7/26/21 6:36 AM, Naveen Krishna Chatradhi wrote:
> From: Akshay Gupta <Akshay.Gupta@amd.com>
> 
> On AMD platforms the Out-of-band access is provided by
> Advanced Platform Management Link (APML), APML is a
> SMBus v2.0 compatible 2-wire processor client interface.
> APML is also referred as the sideband interface (SBI).
> 
> APML is used to communicate with the
> Side-Band Remote Management Interface (SB-RMI) which provides
> Soft Mailbox messages to manage power consumption and
> power limits of the CPU socket.
> 
> - This module add support to read power consumption,
>    power limit & max power limit and write power limit.
> - To instantiate this driver on a Board Management Controller (BMC)
>    connected to an AMD CPU with SB-RMI support, the i2c bus number
>    would be the bus connected from the BMC to the CPU.
> 
> Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Akshay Gupta <Akshay.Gupta@amd.com>
> Signed-off-by: Naveen Krishna Chatradhi <nchatrad@amd.com>

Series applied.

Thanks,
Guenter

> ---
> Changes since v3:
> Added reviewed by Guenter Roeck
> 
>   drivers/hwmon/Kconfig  |  10 ++
>   drivers/hwmon/Makefile |   1 +
>   drivers/hwmon/sbrmi.c  | 358 +++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 369 insertions(+)
>   create mode 100644 drivers/hwmon/sbrmi.c
> 
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 87624902ea80..f489972a6309 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1551,6 +1551,16 @@ config SENSORS_SBTSI
>   	  This driver can also be built as a module. If so, the module will
>   	  be called sbtsi_temp.
>   
> +config SENSORS_SBRMI
> +	tristate "Emulated SB-RMI sensor"
> +	depends on I2C
> +	help
> +	  If you say yes here you get support for emulated RMI
> +	  sensors on AMD SoCs with APML interface connected to a BMC device.
> +
> +	  This driver can also be built as a module. If so, the module will
> +	  be called sbrmi.
> +
>   config SENSORS_SHT15
>   	tristate "Sensiron humidity and temperature sensors. SHT15 and compat."
>   	depends on GPIOLIB || COMPILE_TEST
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index 59e78bc212cf..8031acf58936 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -164,6 +164,7 @@ obj-$(CONFIG_SENSORS_PWM_FAN)	+= pwm-fan.o
>   obj-$(CONFIG_SENSORS_RASPBERRYPI_HWMON)	+= raspberrypi-hwmon.o
>   obj-$(CONFIG_SENSORS_S3C)	+= s3c-hwmon.o
>   obj-$(CONFIG_SENSORS_SBTSI)	+= sbtsi_temp.o
> +obj-$(CONFIG_SENSORS_SBRMI)	+= sbrmi.o
>   obj-$(CONFIG_SENSORS_SCH56XX_COMMON)+= sch56xx-common.o
>   obj-$(CONFIG_SENSORS_SCH5627)	+= sch5627.o
>   obj-$(CONFIG_SENSORS_SCH5636)	+= sch5636.o
> diff --git a/drivers/hwmon/sbrmi.c b/drivers/hwmon/sbrmi.c
> new file mode 100644
> index 000000000000..372b099c04a0
> --- /dev/null
> +++ b/drivers/hwmon/sbrmi.c
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * sbrmi.c - hwmon driver for a SB-RMI mailbox
> + *           compliant AMD SoC device.
> + *
> + * Copyright (C) 2020-2021 Advanced Micro Devices, Inc.
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hwmon.h>
> +#include <linux/i2c.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +
> +/* Do not allow setting negative power limit */
> +#define SBRMI_PWR_MIN	0
> +/* Mask for Status Register bit[1] */
> +#define SW_ALERT_MASK	0x2
> +
> +/* Software Interrupt for triggering */
> +#define START_CMD	0x80
> +#define TRIGGER_MAILBOX	0x01
> +
> +/*
> + * SB-RMI supports soft mailbox service request to MP1 (power management
> + * firmware) through SBRMI inbound/outbound message registers.
> + * SB-RMI message IDs
> + */
> +enum sbrmi_msg_id {
> +	SBRMI_READ_PKG_PWR_CONSUMPTION = 0x1,
> +	SBRMI_WRITE_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_PWR_LIMIT,
> +	SBRMI_READ_PKG_MAX_PWR_LIMIT,
> +};
> +
> +/* SB-RMI registers */
> +enum sbrmi_reg {
> +	SBRMI_CTRL		= 0x01,
> +	SBRMI_STATUS,
> +	SBRMI_OUTBNDMSG0	= 0x30,
> +	SBRMI_OUTBNDMSG1,
> +	SBRMI_OUTBNDMSG2,
> +	SBRMI_OUTBNDMSG3,
> +	SBRMI_OUTBNDMSG4,
> +	SBRMI_OUTBNDMSG5,
> +	SBRMI_OUTBNDMSG6,
> +	SBRMI_OUTBNDMSG7,
> +	SBRMI_INBNDMSG0,
> +	SBRMI_INBNDMSG1,
> +	SBRMI_INBNDMSG2,
> +	SBRMI_INBNDMSG3,
> +	SBRMI_INBNDMSG4,
> +	SBRMI_INBNDMSG5,
> +	SBRMI_INBNDMSG6,
> +	SBRMI_INBNDMSG7,
> +	SBRMI_SW_INTERRUPT,
> +};
> +
> +/* Each client has this additional data */
> +struct sbrmi_data {
> +	struct i2c_client *client;
> +	struct mutex lock;
> +	u32 pwr_limit_max;
> +};
> +
> +struct sbrmi_mailbox_msg {
> +	u8 cmd;
> +	bool read;
> +	u32 data_in;
> +	u32 data_out;
> +};
> +
> +static int sbrmi_enable_alert(struct i2c_client *client)
> +{
> +	int ctrl;
> +
> +	/*
> +	 * Enable the SB-RMI Software alert status
> +	 * by writing 0 to bit 4 of Control register(0x1)
> +	 */
> +	ctrl = i2c_smbus_read_byte_data(client, SBRMI_CTRL);
> +	if (ctrl < 0)
> +		return ctrl;
> +
> +	if (ctrl & 0x10) {
> +		ctrl &= ~0x10;
> +		return i2c_smbus_write_byte_data(client,
> +						 SBRMI_CTRL, ctrl);
> +	}
> +
> +	return 0;
> +}
> +
> +static int rmi_mailbox_xfer(struct sbrmi_data *data,
> +			    struct sbrmi_mailbox_msg *msg)
> +{
> +	int i, ret, retry = 10;
> +	int sw_status;
> +	u8 byte;
> +
> +	mutex_lock(&data->lock);
> +
> +	/* Indicate firmware a command is to be serviced */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG7, START_CMD);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/* Write the command to SBRMI::InBndMsg_inst0 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_INBNDMSG0, msg->cmd);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * For both read and write the initiator (BMC) writes
> +	 * Command Data In[31:0] to SBRMI::InBndMsg_inst[4:1]
> +	 * SBRMI_x3C(MSB):SBRMI_x39(LSB)
> +	 */
> +	for (i = 0; i < 4; i++) {
> +		byte = (msg->data_in >> i * 8) & 0xff;
> +		ret = i2c_smbus_write_byte_data(data->client,
> +						SBRMI_INBNDMSG1 + i, byte);
> +		if (ret < 0)
> +			goto exit_unlock;
> +	}
> +
> +	/*
> +	 * Write 0x01 to SBRMI::SoftwareInterrupt to notify firmware to
> +	 * perform the requested read or write command
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client,
> +					SBRMI_SW_INTERRUPT, TRIGGER_MAILBOX);
> +	if (ret < 0)
> +		goto exit_unlock;
> +
> +	/*
> +	 * Firmware will write SBRMI::Status[SwAlertSts]=1 to generate
> +	 * an ALERT (if enabled) to initiator (BMC) to indicate completion
> +	 * of the requested command
> +	 */
> +	do {
> +		sw_status = i2c_smbus_read_byte_data(data->client,
> +						     SBRMI_STATUS);
> +		if (sw_status < 0) {
> +			ret = sw_status;
> +			goto exit_unlock;
> +		}
> +		if (sw_status & SW_ALERT_MASK)
> +			break;
> +		usleep_range(50, 100);
> +	} while (retry--);
> +
> +	if (retry < 0) {
> +		dev_err(&data->client->dev,
> +			"Firmware fail to indicate command completion\n");
> +		ret = -EIO;
> +		goto exit_unlock;
> +	}
> +
> +	/*
> +	 * For a read operation, the initiator (BMC) reads the firmware
> +	 * response Command Data Out[31:0] from SBRMI::OutBndMsg_inst[4:1]
> +	 * {SBRMI_x34(MSB):SBRMI_x31(LSB)}.
> +	 */
> +	if (msg->read) {
> +		for (i = 0; i < 4; i++) {
> +			ret = i2c_smbus_read_byte_data(data->client,
> +						       SBRMI_OUTBNDMSG1 + i);
> +			if (ret < 0)
> +				goto exit_unlock;
> +			msg->data_out |= ret << i * 8;
> +		}
> +	}
> +
> +	/*
> +	 * BMC must write 1'b1 to SBRMI::Status[SwAlertSts] to clear the
> +	 * ALERT to initiator
> +	 */
> +	ret = i2c_smbus_write_byte_data(data->client, SBRMI_STATUS,
> +					sw_status | SW_ALERT_MASK);
> +
> +exit_unlock:
> +	mutex_unlock(&data->lock);
> +	return ret;
> +}
> +
> +static int sbrmi_read(struct device *dev, enum hwmon_sensor_types type,
> +		      u32 attr, int channel, long *val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	if (type != hwmon_power)
> +		return -EINVAL;
> +
> +	msg.read = true;
> +	switch (attr) {
> +	case hwmon_power_input:
> +		msg.cmd = SBRMI_READ_PKG_PWR_CONSUMPTION;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap:
> +		msg.cmd = SBRMI_READ_PKG_PWR_LIMIT;
> +		ret = rmi_mailbox_xfer(data, &msg);
> +		break;
> +	case hwmon_power_cap_max:
> +		msg.data_out = data->pwr_limit_max;
> +		break;
> +	default:
> +		return -EINVAL;
> +	}
> +	if (ret < 0)
> +		return ret;
> +	/* hwmon power attributes are in microWatt */
> +	*val = (long)msg.data_out * 1000;
> +	return ret;
> +}
> +
> +static int sbrmi_write(struct device *dev, enum hwmon_sensor_types type,
> +		       u32 attr, int channel, long val)
> +{
> +	struct sbrmi_data *data = dev_get_drvdata(dev);
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +
> +	if (type != hwmon_power && attr != hwmon_power_cap)
> +		return -EINVAL;
> +	/*
> +	 * hwmon power attributes are in microWatt
> +	 * mailbox read/write is in mWatt
> +	 */
> +	val /= 1000;
> +
> +	val = clamp_val(val, SBRMI_PWR_MIN, data->pwr_limit_max);
> +
> +	msg.cmd = SBRMI_WRITE_PKG_PWR_LIMIT;
> +	msg.data_in = val;
> +	msg.read = false;
> +
> +	return rmi_mailbox_xfer(data, &msg);
> +}
> +
> +static umode_t sbrmi_is_visible(const void *data,
> +				enum hwmon_sensor_types type,
> +				u32 attr, int channel)
> +{
> +	switch (type) {
> +	case hwmon_power:
> +		switch (attr) {
> +		case hwmon_power_input:
> +		case hwmon_power_cap_max:
> +			return 0444;
> +		case hwmon_power_cap:
> +			return 0644;
> +		}
> +		break;
> +	default:
> +		break;
> +	}
> +	return 0;
> +}
> +
> +static const struct hwmon_channel_info *sbrmi_info[] = {
> +	HWMON_CHANNEL_INFO(power,
> +			   HWMON_P_INPUT | HWMON_P_CAP | HWMON_P_CAP_MAX),
> +	NULL
> +};
> +
> +static const struct hwmon_ops sbrmi_hwmon_ops = {
> +	.is_visible = sbrmi_is_visible,
> +	.read = sbrmi_read,
> +	.write = sbrmi_write,
> +};
> +
> +static const struct hwmon_chip_info sbrmi_chip_info = {
> +	.ops = &sbrmi_hwmon_ops,
> +	.info = sbrmi_info,
> +};
> +
> +static int sbrmi_get_max_pwr_limit(struct sbrmi_data *data)
> +{
> +	struct sbrmi_mailbox_msg msg = { 0 };
> +	int ret;
> +
> +	msg.cmd = SBRMI_READ_PKG_MAX_PWR_LIMIT;
> +	msg.read = true;
> +	ret = rmi_mailbox_xfer(data, &msg);
> +	if (ret < 0)
> +		return ret;
> +	data->pwr_limit_max = msg.data_out;
> +
> +	return ret;
> +}
> +
> +static int sbrmi_probe(struct i2c_client *client,
> +		       const struct i2c_device_id *id)
> +{
> +	struct device *dev = &client->dev;
> +	struct device *hwmon_dev;
> +	struct sbrmi_data *data;
> +	int ret;
> +
> +	data = devm_kzalloc(dev, sizeof(struct sbrmi_data), GFP_KERNEL);
> +	if (!data)
> +		return -ENOMEM;
> +
> +	data->client = client;
> +	mutex_init(&data->lock);
> +
> +	/* Enable alert for SB-RMI sequence */
> +	ret = sbrmi_enable_alert(client);
> +	if (ret < 0)
> +		return ret;
> +
> +	/* Cache maximum power limit */
> +	ret = sbrmi_get_max_pwr_limit(data);
> +	if (ret < 0)
> +		return ret;
> +
> +	hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
> +							 &sbrmi_chip_info, NULL);
> +
> +	return PTR_ERR_OR_ZERO(hwmon_dev);
> +}
> +
> +static const struct i2c_device_id sbrmi_id[] = {
> +	{"sbrmi", 0},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(i2c, sbrmi_id);
> +
> +static const struct of_device_id __maybe_unused sbrmi_of_match[] = {
> +	{
> +		.compatible = "amd,sbrmi",
> +	},
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, sbrmi_of_match);
> +
> +static struct i2c_driver sbrmi_driver = {
> +	.class = I2C_CLASS_HWMON,
> +	.driver = {
> +		.name = "sbrmi",
> +		.of_match_table = of_match_ptr(sbrmi_of_match),
> +	},
> +	.probe = sbrmi_probe,
> +	.id_table = sbrmi_id,
> +};
> +
> +module_i2c_driver(sbrmi_driver);
> +
> +MODULE_AUTHOR("Akshay Gupta <akshay.gupta@amd.com>");
> +MODULE_DESCRIPTION("Hwmon driver for AMD SB-RMI emulated sensor");
> +MODULE_LICENSE("GPL");
> 


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-07-28 16:57 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-25 13:25 [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Naveen Krishna Chatradhi
2021-06-25 13:25 ` [PATCH 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
2021-06-28 15:01   ` Guenter Roeck
2021-06-25 13:25 ` [PATCH 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
2021-06-28 14:58 ` [PATCH 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
2021-06-29 15:05   ` Chatradhi, Naveen Krishna
2021-07-07 14:14     ` Chatradhi, Naveen Krishna
2021-07-07 14:21       ` Guenter Roeck
2021-07-07 15:58         ` Chatradhi, Naveen Krishna
2021-07-07 15:58 ` [PATCH v2 " Naveen Krishna Chatradhi
2021-07-07 15:58   ` [PATCH v2 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
2021-07-07 15:58   ` [PATCH v2 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
2021-07-16  5:58   ` [PATCH v2 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
2021-07-19 15:50     ` Chatradhi, Naveen Krishna
2021-07-19 16:21       ` Guenter Roeck
2021-07-20  5:57 ` [PATCH v3 " Naveen Krishna Chatradhi
2021-07-20  5:57   ` [PATCH v3 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
2021-07-25 21:40     ` Guenter Roeck
2021-07-20  5:57   ` [PATCH v3 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
2021-07-25 21:36     ` Guenter Roeck
2021-07-26  4:36       ` Chatradhi, Naveen Krishna
2021-07-26  4:58         ` Guenter Roeck
2021-07-25 21:38   ` [PATCH v3 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck
2021-07-26 13:36 ` [PATCH v4 " Naveen Krishna Chatradhi
2021-07-26 13:36   ` [PATCH v4 2/3] hwmon: sbrmi: Add Documentation Naveen Krishna Chatradhi
2021-07-26 13:36   ` [PATCH v4 3/3] dt-bindings: sbrmi: Add SB-RMI hwmon driver bindings Naveen Krishna Chatradhi
2021-07-26 22:43     ` Rob Herring
2021-07-28 16:57   ` [PATCH v4 1/3] hwmon: sbrmi: Add support for sbrmi power module Guenter Roeck

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.