Patchwork [v2] power/mpc85xx: Add delay after enabling I2C master

login
register
mail settings
Submitter York Sun
Date Sept. 16, 2013, 10:06 p.m.
Message ID <1379369185-14590-1-git-send-email-yorksun@freescale.com>
Download mbox | patch
Permalink /patch/275294/
State Changes Requested
Headers show

Comments

York Sun - Sept. 16, 2013, 10:06 p.m.
Erratum A-006037 indicates I2C controller executes the write to I2CCR only
after it sees SCL idle for 64K cycle of internal I2C controller clocks. If
during this waiting period, I2C controller is disabled (I2CCR[MEN] set to
0), then the controller could end in bad state, and hang the future access
to I2C register.

The mpc_i2c_fixup() function tries to recover the bus from a stalled state
where the 9th clock pulse wasn't generated. However, this workaround
disables and enables I2C controller without meeting waiting requirement of
this erratum.

This erratum applies to some 85xx SoCs. It is safe to apply to all of them
for mpc_i2c_fixup().

Signed-off-by: York Sun <yorksun@freescale.com>
---
Change log:
 v2: remote reviewed-by and tested-by lines added by gerrit
     send to proper mailing list

 drivers/i2c/busses/i2c-mpc.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)
York Sun - Sept. 16, 2013, 11:40 p.m.
On 09/16/2013 03:06 PM, York Sun wrote:
> Erratum A-006037 indicates I2C controller executes the write to I2CCR only
> after it sees SCL idle for 64K cycle of internal I2C controller clocks. If
> during this waiting period, I2C controller is disabled (I2CCR[MEN] set to
> 0), then the controller could end in bad state, and hang the future access
> to I2C register.
> 
> The mpc_i2c_fixup() function tries to recover the bus from a stalled state
> where the 9th clock pulse wasn't generated. However, this workaround
> disables and enables I2C controller without meeting waiting requirement of
> this erratum.
> 
> This erratum applies to some 85xx SoCs. It is safe to apply to all of them
> for mpc_i2c_fixup().
> 
> Signed-off-by: York Sun <yorksun@freescale.com>
> ---
> Change log:
>  v2: remote reviewed-by and tested-by lines added by gerrit
>      send to proper mailing list

Pardon my typo. I meant to type "remove", instead of "remote".

York


--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang - Sept. 23, 2013, 7:10 a.m.
> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
> index b80c768..55dce43 100644
> --- a/drivers/i2c/busses/i2c-mpc.c
> +++ b/drivers/i2c/busses/i2c-mpc.c
> @@ -106,7 +106,12 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
>  static void mpc_i2c_fixup(struct mpc_i2c *i2c)
>  {
>  	int k;
> -	u32 delay_val = 1000000 / i2c->real_clk + 1;
> +	u32 delay_val;
> +#ifdef CONFIG_PPC_85xx
> +	delay_val = 65536 / (fsl_get_sys_freq() / 2000000);	/* 64K cycle */
> +#else
> +	delay_val = 1000000 / i2c->real_clk + 1;
> +#endif

Please, no unnecessary #ifdefs in code. We have 'struct mpc_i2c_data'
already.
York Sun - Sept. 23, 2013, 9:44 p.m.
On 09/23/2013 12:10 AM, Wolfram Sang wrote:
> 
>> diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
>> index b80c768..55dce43 100644
>> --- a/drivers/i2c/busses/i2c-mpc.c
>> +++ b/drivers/i2c/busses/i2c-mpc.c
>> @@ -106,7 +106,12 @@ static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
>>  static void mpc_i2c_fixup(struct mpc_i2c *i2c)
>>  {
>>  	int k;
>> -	u32 delay_val = 1000000 / i2c->real_clk + 1;
>> +	u32 delay_val;
>> +#ifdef CONFIG_PPC_85xx
>> +	delay_val = 65536 / (fsl_get_sys_freq() / 2000000);	/* 64K cycle */
>> +#else
>> +	delay_val = 1000000 / i2c->real_clk + 1;
>> +#endif
> 
> Please, no unnecessary #ifdefs in code. We have 'struct mpc_i2c_data'
> already.
> 

I am not pround of this change. Please elaborate how to use mpc_i2c_data
to separate the mpc85xx from the rest.

York


--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang - Sept. 23, 2013, 10:09 p.m.
> > Please, no unnecessary #ifdefs in code. We have 'struct mpc_i2c_data'
> > already.
> > 
> 
> I am not pround of this change. Please elaborate how to use mpc_i2c_data
> to separate the mpc85xx from the rest.

Search for 'match->data' and see how the custom setup function and
custom prescaler value is used.
York Sun - Sept. 23, 2013, 10:16 p.m.
On 09/23/2013 03:09 PM, Wolfram Sang wrote:
> 
>>> Please, no unnecessary #ifdefs in code. We have 'struct mpc_i2c_data'
>>> already.
>>>
>>
>> I am not pround of this change. Please elaborate how to use mpc_i2c_data
>> to separate the mpc85xx from the rest.
> 
> Search for 'match->data' and see how the custom setup function and
> custom prescaler value is used.
> 
I see. It is using device tree to match. But the device tree doesn't
have enough information. Many platforms don't specifiy if compatible
with mpc85xx, so they fall into .compatible = "fsl-i2c". Please advise.

York


--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang - Sept. 23, 2013, 10:32 p.m.
> I see. It is using device tree to match. But the device tree doesn't
> have enough information. Many platforms don't specifiy if compatible
> with mpc85xx, so they fall into .compatible = "fsl-i2c". 

:( Can those be fixed to use proper "fsl,mpc8544-i2c"?

> Please advise.

My PPC knowledge is a bit dusty: What about SVR/PVR to detect the 8544
at runtime?

Regards,

   Wolfram
York Sun - Sept. 23, 2013, 10:38 p.m.
On 09/23/2013 03:32 PM, Wolfram Sang wrote:
> 
>> I see. It is using device tree to match. But the device tree doesn't
>> have enough information. Many platforms don't specifiy if compatible
>> with mpc85xx, so they fall into .compatible = "fsl-i2c". 
> 
> :( Can those be fixed to use proper "fsl,mpc8544-i2c"?
> 
>> Please advise.
> 
> My PPC knowledge is a bit dusty: What about SVR/PVR to detect the 8544
> at runtime?
> 
Wolfram,

It is not only about 8544. I wrote this patch to address a timing issue
when a workaround is applied. This timing issue applies to many mpc85xx
parts, but not all of them. But it is safe to all. So checking one
SVR/PVR doesn't work.

York



--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Wolfram Sang - Sept. 24, 2013, 7:36 a.m.
> I see. It is using device tree to match. But the device tree doesn't
> have enough information. Many platforms don't specifiy if compatible
> with mpc85xx, so they fall into .compatible = "fsl-i2c". Please advise.

The 'if (match->data)' block has an else branch which will call
'mpc_i2c_setup_8xxx' for fsl-i2c. You should be able to make use of
that?

Patch

diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index b80c768..55dce43 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -106,7 +106,12 @@  static irqreturn_t mpc_i2c_isr(int irq, void *dev_id)
 static void mpc_i2c_fixup(struct mpc_i2c *i2c)
 {
 	int k;
-	u32 delay_val = 1000000 / i2c->real_clk + 1;
+	u32 delay_val;
+#ifdef CONFIG_PPC_85xx
+	delay_val = 65536 / (fsl_get_sys_freq() / 2000000);	/* 64K cycle */
+#else
+	delay_val = 1000000 / i2c->real_clk + 1;
+#endif
 
 	if (delay_val < 2)
 		delay_val = 2;
@@ -116,7 +121,11 @@  static void mpc_i2c_fixup(struct mpc_i2c *i2c)
 		writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
 		udelay(delay_val);
 		writeccr(i2c, CCR_MEN);
+#ifdef CONFIG_PPC_85xx
+		udelay(delay_val);
+#else
 		udelay(delay_val << 1);
+#endif
 	}
 }