[PATCH v2 0/2] i2c-mv64xxx: Various fixes

[PATCH v2 0/2] i2c-mv64xxx: Various fixes

[Gregory CLEMENT]

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

[PATCH v2 1/2] i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)

[Gregory CLEMENT]

From: Zbigniew Bodek <zbb@semihalf.com>

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]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Zbigniew Bodek <zbb@semihalf.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 1a3abd6..74f8fcb 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -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

[PATCH v2 1/2] i2c-mv64xxx: Fix timing issue on Armada XP (errata FE-8471889)

[Wolfram Sang]

On Tue, Jun 18, 2013 at 05:40:23PM +0200, Gregory CLEMENT wrote:
> From: Zbigniew Bodek <zbb@semihalf.com>
> 
> 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.

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>

[PATCH v2 2/2] i2c-mv64xxx: Abort the mv64xxx_of_config if clock-frequency is not provided

[Gregory CLEMENT]

From: Zbigniew Bodek <zbb@semihalf.com>

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]

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Zbigniew Bodek <zbb@semihalf.com>
---
 drivers/i2c/busses/i2c-mv64xxx.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 74f8fcb..de384a1 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -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

[PATCH v2 2/2] i2c-mv64xxx: Abort the mv64xxx_of_config if clock-frequency is not provided

[Wolfram Sang]

On Tue, Jun 18, 2013 at 05:40:24PM +0200, Gregory CLEMENT wrote:
> From: Zbigniew Bodek <zbb@semihalf.com>
> 
> 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]
> 
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> Signed-off-by: Zbigniew Bodek <zbb@semihalf.com>

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.

> ---
>  drivers/i2c/busses/i2c-mv64xxx.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
> index 74f8fcb..de384a1 100644
> --- a/drivers/i2c/busses/i2c-mv64xxx.c
> +++ b/drivers/i2c/busses/i2c-mv64xxx.c
> @@ -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
> 
-------------- 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>