i2c-mv64xxx: Various fixes

Hello,

This series contains a real fix for the I2C controller of the Armada XP SoC and a patch closer to a improvement than a fix.

They are independent and are only in the same series because they are kind of fixes.

I kept the test on the compatible string "armadaxp" because I am not convinced that we have to introduce a new property in the binding for this. If latter another SoC got the same issue on this IP then it will still be time to add a new property. However I don't have a strong opinion on it, so if you really want it, I can send a new version with it.

Changelog:
v1->v2:
- Move the flag for the timing issue from global scope to per device scope
- Assignment is no more done in if condition

Thanks,

Zbigniew Bodek (2):
i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)
i2c-mv64xxx: Abort the mv64xxx_of_config if clock-frequency is not
provided

 drivers/i2c/busses/i2c-mv64xxx.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

1.8.1.2

From: Zbigniew Bodek <[email protected]>

All the Armada XP (mv78230, mv78260 and mv78460) have a silicon issue in the I2C controller which violate the i2c repeated start timing. The I2C standard requires a minimum of 4.7us for the repeated start condition whereas the I2C controller of the Armada XP this time is 2.9us.

So this patch adds a 5us delay for the start case only if the mv64xxx_i2c_errata_delay flag is set.

[gregory.clement at free-electrons.com: Use the delay flasg as per-I2C controller variable]
[gregory.clement at free-electrons.com: Merge the incoming commits into this single one]
[gregory.clement at free-electrons.com: Reword the commit log]

---
 drivers/i2c/busses/i2c-mv64xxx.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

index 1a3abd6..74f8fcb 100644
@@ -23,6 +23,7 @@
 #include <linux/of_i2c.h>
 #include <linux/clk.h>
 #include <linux/err.h>
+#include <linux/delay.h>
 
 /* Register defines */
 #define	MV64XXX_I2C_REG_SLAVE_ADDR			0x00

@@ -103,6 +104,10 @@ struct mv64xxx_i2c_data {
 	int			rc;
 	u32			freq_m;
 	u32			freq_n;
+
+/* 5us delay in order to avoid repeated start timing violation */
+	bool mv64xxx_i2c_errata_delay;
+
 #if defined(CONFIG_HAVE_CLK)
 	struct clk              *clk;
 #endif

@@ -252,6 +257,9 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 		writel(drv_data->cntl_bits,
 			drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
 		drv_data->block = 0;
+		if (drv_data->mv64xxx_i2c_errata_delay)
+			udelay(5);
+
 		wake_up(&drv_data->waitq);
 		break;
 

@@ -300,6 +308,9 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 		writel(drv_data->cntl_bits | MV64XXX_I2C_REG_CONTROL_STOP,
 			drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
 		drv_data->block = 0;
+		if (drv_data->mv64xxx_i2c_errata_delay)
+			udelay(5);
+
 		wake_up(&drv_data->waitq);
 		break;
 

@@ -592,6 +603,9 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
 	 * So hard code the value to 1 second.
 	 */
 	drv_data->adapter.timeout = HZ;
+
+	if (of_machine_is_compatible("marvell,armadaxp"))
+		drv_data->mv64xxx_i2c_errata_delay = 1;
 out:
 	return rc;
 #endif

1.8.1.2

You are correct that this does not need a seperate property since this is a flaw of this specific controller. So, it needs a new compatible entry ('mv78230-i2c' for example) and this entry should then have the workaround enabled.

Thanks,

Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130619/e92d3c7b/attachment.sig>

From: Zbigniew Bodek <[email protected]>

This commit adds checking whether clock-frequency property acquisition has succeeded. Do not waste time to find baud factors if there is no information about the desired bus frequency in dts.

[gregory.clement at free-electrons.com: Reword the commit log]

---
 drivers/i2c/busses/i2c-mv64xxx.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

index 74f8fcb..de384a1 100644
@@ -591,7 +591,11 @@ mv64xxx_of_config(struct mv64xxx_i2c_data *drv_data,
 		goto out;
 	}
 	tclk = clk_get_rate(drv_data->clk);
-	of_property_read_u32(np, "clock-frequency", &bus_freq);
+
+	rc = of_property_read_u32(np, "clock-frequency", &bus_freq);
+	if (rc)
+		goto out;
+
 	if (!mv64xxx_find_baud_factors(bus_freq, tclk,
 				       &drv_data->freq_n, &drv_data->freq_m)) {
 		rc = -EINVAL;

1.8.1.2

What about setting it to 100kHz when not defined (and marking the property optional in the docs)? That's convenient and common I'd say.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130619/c84df02f/attachment.sig>