This serie adds support for SMBus Alert on the STM32F7.
A new binding st,smbus-alert is added in order to differenciate
with the existing smbus binding.
SMBA alert control and status logic must be enabled along with
SMBALERT# pin configured via pinctrl in the device tree. This is the
rational for adding "st,smbus-alert" property.
---
v3:
use lore.kernel.org links instead of marc.info
v2:
When SMBUS alert isn't available on the board (SMBA unused), this
logic musn't be enabled. Enabling it unconditionally wrongly lead to get
SMBA interrupts.
So, add "st,smbus-alert" dedicated binding to have a smbus alert with a
consistent pin configuration in DT.
Alain Volmat (2):
dt-bindings: i2c: stm32f7: add st,smbus-alert binding for SMBus Alert
i2c: stm32f7: add SMBus-Alert support
.../devicetree/bindings/i2c/st,stm32-i2c.yaml | 5 ++
drivers/i2c/busses/i2c-stm32f7.c | 73 +++++++++++++++++++
2 files changed, 78 insertions(+)
--
2.17.1
Based on the SMBus specification, SMBus Alert active state is low.
As often on SoC, the SMBus Alert pin is not only dedicated to this
feature and can also be used for another purpose (by configuring it
as alternate function for other functions via pinctrl).
"smbus" dt-binding has been introduced recently [1], however it is also
used to indicate usage of host-notify feature.
Relying on 'smbus' binding for SMBus-Alert as well as it was discussed
previously [2] would lead to requiring the SMBALERT# pin to be configured
as alternate function for i2c/smbus controller even if only host-notify is
needed.
Indeed, not doing so would lead to spurious SMBus Alert interrupts since
the i2c/smbus controller would see the (not configured) SMBA pin as low
level.
For that reason, SMBus-Alert needs to have its own binding in order
to only be enabled whenever SMBALERT# pin is configured as alternate
function for i2c/smbus controller.
[1] https://lore.kernel.org/linux-i2c/20200721062217.GA1044@kunai/
[2] https://lore.kernel.org/linux-i2c/[email protected]/
Signed-off-by: Alain Volmat <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
---
v3: use lore.kernel.org links
v2: introduce st,smbus-alert property
---
Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
index d747f4990ad8..0d45ead7d835 100644
--- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
+++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml
@@ -36,6 +36,11 @@ allOf:
minItems: 3
maxItems: 3
+ st,smbus-alert:
+ description: Enable the SMBus-Alert via SMBA pin, note SMBA pin
+ must also be configured via pinctrl.
+ type: boolean
+
- if:
properties:
compatible:
--
2.17.1
Add support for the SMBus-Alert protocol to the STM32F7 that has
dedicated control and status logic.
If SMBus-Alert is used, the SMBALERT# pin must be configured as alternate
function for I2C Alert.
Signed-off-by: Alain Volmat <[email protected]>
Reviewed-by: Pierre-Yves MORDRET <[email protected]>
---
v2: - rely on st,smbus-alert binding instead of smbus
---
drivers/i2c/busses/i2c-stm32f7.c | 73 ++++++++++++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index c62c815b88eb..bd840cd2b9e4 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -51,6 +51,7 @@
/* STM32F7 I2C control 1 */
#define STM32F7_I2C_CR1_PECEN BIT(23)
+#define STM32F7_I2C_CR1_ALERTEN BIT(22)
#define STM32F7_I2C_CR1_SMBHEN BIT(20)
#define STM32F7_I2C_CR1_WUPEN BIT(18)
#define STM32F7_I2C_CR1_SBC BIT(16)
@@ -125,6 +126,7 @@
(((n) & STM32F7_I2C_ISR_ADDCODE_MASK) >> 17)
#define STM32F7_I2C_ISR_DIR BIT(16)
#define STM32F7_I2C_ISR_BUSY BIT(15)
+#define STM32F7_I2C_ISR_ALERT BIT(13)
#define STM32F7_I2C_ISR_PECERR BIT(11)
#define STM32F7_I2C_ISR_ARLO BIT(9)
#define STM32F7_I2C_ISR_BERR BIT(8)
@@ -138,6 +140,7 @@
#define STM32F7_I2C_ISR_TXE BIT(0)
/* STM32F7 I2C Interrupt Clear */
+#define STM32F7_I2C_ICR_ALERTCF BIT(13)
#define STM32F7_I2C_ICR_PECCF BIT(11)
#define STM32F7_I2C_ICR_ARLOCF BIT(9)
#define STM32F7_I2C_ICR_BERRCF BIT(8)
@@ -283,6 +286,17 @@ struct stm32f7_i2c_msg {
u8 smbus_buf[I2C_SMBUS_BLOCK_MAX + 3] __aligned(4);
};
+/**
+ * struct stm32f7_i2c_alert - SMBus alert specific data
+ * @setup: platform data for the smbus_alert i2c client
+ * @ara: I2C slave device used to respond to the SMBus Alert with Alert
+ * Response Address
+ */
+struct stm32f7_i2c_alert {
+ struct i2c_smbus_alert_setup setup;
+ struct i2c_client *ara;
+};
+
/**
* struct stm32f7_i2c_dev - private data of the controller
* @adap: I2C adapter for this controller
@@ -312,6 +326,7 @@ struct stm32f7_i2c_msg {
* @wakeup_src: boolean to know if the device is a wakeup source
* @smbus_mode: states that the controller is configured in SMBus mode
* @host_notify_client: SMBus host-notify client
+ * @alert: SMBus alert specific data
*/
struct stm32f7_i2c_dev {
struct i2c_adapter adap;
@@ -340,6 +355,7 @@ struct stm32f7_i2c_dev {
bool wakeup_src;
bool smbus_mode;
struct i2c_client *host_notify_client;
+ struct stm32f7_i2c_alert *alert;
};
/*
@@ -1616,6 +1632,13 @@ static irqreturn_t stm32f7_i2c_isr_error(int irq, void *data)
f7_msg->result = -EINVAL;
}
+ if (status & STM32F7_I2C_ISR_ALERT) {
+ dev_dbg(dev, "<%s>: SMBus alert received\n", __func__);
+ writel_relaxed(STM32F7_I2C_ICR_ALERTCF, base + STM32F7_I2C_ICR);
+ i2c_handle_smbus_alert(i2c_dev->alert->ara);
+ return IRQ_HANDLED;
+ }
+
if (!i2c_dev->slave_running) {
u32 mask;
/* Disable interrupts */
@@ -1982,6 +2005,42 @@ static void stm32f7_i2c_disable_smbus_host(struct stm32f7_i2c_dev *i2c_dev)
}
}
+static int stm32f7_i2c_enable_smbus_alert(struct stm32f7_i2c_dev *i2c_dev)
+{
+ struct stm32f7_i2c_alert *alert;
+ struct i2c_adapter *adap = &i2c_dev->adap;
+ struct device *dev = i2c_dev->dev;
+ void __iomem *base = i2c_dev->base;
+
+ alert = devm_kzalloc(dev, sizeof(*alert), GFP_KERNEL);
+ if (!alert)
+ return -ENOMEM;
+
+ alert->ara = i2c_new_smbus_alert_device(adap, &alert->setup);
+ if (IS_ERR(alert->ara))
+ return PTR_ERR(alert->ara);
+
+ i2c_dev->alert = alert;
+
+ /* Enable SMBus Alert */
+ stm32f7_i2c_set_bits(base + STM32F7_I2C_CR1, STM32F7_I2C_CR1_ALERTEN);
+
+ return 0;
+}
+
+static void stm32f7_i2c_disable_smbus_alert(struct stm32f7_i2c_dev *i2c_dev)
+{
+ struct stm32f7_i2c_alert *alert = i2c_dev->alert;
+ void __iomem *base = i2c_dev->base;
+
+ if (alert) {
+ /* Disable SMBus Alert */
+ stm32f7_i2c_clr_bits(base + STM32F7_I2C_CR1,
+ STM32F7_I2C_CR1_ALERTEN);
+ i2c_unregister_device(alert->ara);
+ }
+}
+
static u32 stm32f7_i2c_func(struct i2c_adapter *adap)
{
struct stm32f7_i2c_dev *i2c_dev = i2c_get_adapdata(adap);
@@ -2169,6 +2228,16 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
}
}
+ if (of_property_read_bool(pdev->dev.of_node, "st,smbus-alert")) {
+ ret = stm32f7_i2c_enable_smbus_alert(i2c_dev);
+ if (ret) {
+ dev_err(i2c_dev->dev,
+ "failed to enable SMBus alert protocol (%d)\n",
+ ret);
+ goto i2c_disable_smbus_host;
+ }
+ }
+
dev_info(i2c_dev->dev, "STM32F7 I2C-%d bus adapter\n", adap->nr);
pm_runtime_mark_last_busy(i2c_dev->dev);
@@ -2176,6 +2245,9 @@ static int stm32f7_i2c_probe(struct platform_device *pdev)
return 0;
+i2c_disable_smbus_host:
+ stm32f7_i2c_disable_smbus_host(i2c_dev);
+
i2c_adapter_remove:
i2c_del_adapter(adap);
@@ -2210,6 +2282,7 @@ static int stm32f7_i2c_remove(struct platform_device *pdev)
{
struct stm32f7_i2c_dev *i2c_dev = platform_get_drvdata(pdev);
+ stm32f7_i2c_disable_smbus_alert(i2c_dev);
stm32f7_i2c_disable_smbus_host(i2c_dev);
i2c_del_adapter(&i2c_dev->adap);
--
2.17.1
Hi Wolfram,
Gentle reminder about this serie about SMBus-Alert. Could you have
a look at it ?
Thanks
Alain
On Mon, Mar 29, 2021 at 08:09:03AM +0200, Alain Volmat wrote:
> This serie adds support for SMBus Alert on the STM32F7.
> A new binding st,smbus-alert is added in order to differenciate
> with the existing smbus binding.
>
> SMBA alert control and status logic must be enabled along with
> SMBALERT# pin configured via pinctrl in the device tree. This is the
> rational for adding "st,smbus-alert" property.
>
> ---
> v3:
> use lore.kernel.org links instead of marc.info
>
> v2:
> When SMBUS alert isn't available on the board (SMBA unused), this
> logic musn't be enabled. Enabling it unconditionally wrongly lead to get
> SMBA interrupts.
> So, add "st,smbus-alert" dedicated binding to have a smbus alert with a
> consistent pin configuration in DT.
>
> Alain Volmat (2):
> dt-bindings: i2c: stm32f7: add st,smbus-alert binding for SMBus Alert
> i2c: stm32f7: add SMBus-Alert support
>
> .../devicetree/bindings/i2c/st,stm32-i2c.yaml | 5 ++
> drivers/i2c/busses/i2c-stm32f7.c | 73 +++++++++++++++++++
> 2 files changed, 78 insertions(+)
>
> --
> 2.17.1
>
> Gentle reminder about this serie about SMBus-Alert. Could you have
> a look at it ?
Yes. I first thought to do this after increasing SMBus Block length to
255. But because of the userspace ABI problems, it probably makes sense
to work on this first. Here, no userspace is involved.
> + st,smbus-alert:
After reading the specs again, I think we can make this a generic
binding. SMBusAlert is optional. So, we can say it is not covered by the
"smbus" binding and needs a seperate one. Makes sense?
Hi Wolfram,
On Tue, May 04, 2021 at 09:53:48PM +0200, Wolfram Sang wrote:
>
> > + st,smbus-alert:
>
> After reading the specs again, I think we can make this a generic
> binding. SMBusAlert is optional. So, we can say it is not covered by the
> "smbus" binding and needs a seperate one. Makes sense?
Indeed, SMBus Spec [1] mentions about SMBALERT#:
An optional signal that a slave device can use to notify the system
master that it has information for the master
Hence it does make sense to separate it from the smbus binding. I will
post a v4 of this serie with the addition of a generic binding 'smbus-alert'.
Alain
[1] http://www.smbus.org/specs/SMBus_3_1_20180319.pdf