* [PATCH RFC] power/mpc85xx: Add delay after enabling I2C master
@ 2013-05-13 21:27 York Sun
2013-07-23 0:33 ` [RFC] " Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: York Sun @ 2013-05-13 21:27 UTC (permalink / raw)
To: albrecht.dress; +Cc: linuxppc-dev
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>
---
I'd like to get rid of the #ifdef if mpc5121 is OK with the longer delay.
drivers/i2c/busses/i2c-mpc.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index a69459e..3e540ca 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -105,7 +105,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;
@@ -115,7 +120,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
}
}
--
1.7.9.5
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [RFC] power/mpc85xx: Add delay after enabling I2C master
2013-05-13 21:27 [PATCH RFC] power/mpc85xx: Add delay after enabling I2C master York Sun
@ 2013-07-23 0:33 ` Scott Wood
2013-07-23 15:37 ` York Sun
0 siblings, 1 reply; 5+ messages in thread
From: Scott Wood @ 2013-07-23 0:33 UTC (permalink / raw)
To: York Sun; +Cc: albrecht.dress, linuxppc-dev
On Mon, May 13, 2013 at 02:27:08PM -0700, 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>
>
> ---
> I'd like to get rid of the #ifdef if mpc5121 is OK with the longer delay.
Are mpc5121 and mpc85xx the only things that use this?
Are you sure the delay always works out to be longer? What is the
relationship between fsl_get_sys_freq() and i2c->real_clk?
In any case, you should send this patch to the i2c maintainer and list.
-Scott
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] power/mpc85xx: Add delay after enabling I2C master
2013-07-23 0:33 ` [RFC] " Scott Wood
@ 2013-07-23 15:37 ` York Sun
2013-07-23 18:43 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: York Sun @ 2013-07-23 15:37 UTC (permalink / raw)
To: Scott Wood; +Cc: albrecht.dress, linuxppc-dev
On 07/22/2013 05:33 PM, Scott Wood wrote:
> On Mon, May 13, 2013 at 02:27:08PM -0700, 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>
>>
>> ---
>> I'd like to get rid of the #ifdef if mpc5121 is OK with the longer delay.
>
> Are mpc5121 and mpc85xx the only things that use this?
No. 83xx and 86xx also uses this file. But I am only unsure if mpc52xx
is OK with this extended delay. I guess they are but I don't have a
proof, or someone to confirm.
>
> Are you sure the delay always works out to be longer? What is the
> relationship between fsl_get_sys_freq() and i2c->real_clk?
Yes. The max divider from sys clock to i2c clcok is 32K. i2c->real_clk
is the clock I2C controller pumps out, not its internal operation clock.
>
> In any case, you should send this patch to the i2c maintainer and list.
>
I don't have the name on top of my head. Is that linux-i2c@vger.kernel.org?
York
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] power/mpc85xx: Add delay after enabling I2C master
2013-07-23 15:37 ` York Sun
@ 2013-07-23 18:43 ` Scott Wood
2013-07-23 20:32 ` York Sun
0 siblings, 1 reply; 5+ messages in thread
From: Scott Wood @ 2013-07-23 18:43 UTC (permalink / raw)
To: York Sun; +Cc: albrecht.dress, linuxppc-dev
On 07/23/2013 10:37:46 AM, York Sun wrote:
> On 07/22/2013 05:33 PM, Scott Wood wrote:
> > On Mon, May 13, 2013 at 02:27:08PM -0700, York Sun wrote:
> >> Erratum A-006037 indicates I2C controller executes the write to =20
> I2CCR only
> >> after it sees SCL idle for 64K cycle of internal I2C controller =20
> clocks. If
> >> during this waiting period, I2C controller is disabled (I2CCR[MEN] =20
> set to
> >> 0), then the controller could end in bad state, and hang the =20
> future access
> >> to I2C register.
> >>
> >> The mpc_i2c_fixup() function tries to recover the bus from a =20
> stalled state
> >> where the 9th clock pulse wasn't generated. However, this =20
> workaround
> >> disables and enables I2C controller without meeting waiting =20
> requirement of
> >> this erratum.
> >>
> >> This erratum applies to some 85xx SoCs. It is safe to apply to all =20
> of them
> >> for mpc_i2c_fixup().
> >>
> >> Signed-off-by: York Sun <yorksun@freescale.com>
> >>
> >> ---
> >> I'd like to get rid of the #ifdef if mpc5121 is OK with the longer =20
> delay.
> >
> > Are mpc5121 and mpc85xx the only things that use this?
>=20
> No. 83xx and 86xx also uses this file. But I am only unsure if mpc52xx
> is OK with this extended delay. I guess they are but I don't have a
> proof, or someone to confirm.
>=20
> >
> > Are you sure the delay always works out to be longer? What is the
> > relationship between fsl_get_sys_freq() and i2c->real_clk?
>=20
> Yes. The max divider from sys clock to i2c clcok is 32K.
> i2c->real_clk is the clock I2C controller pumps out, not its internal =20
> operation clock.
32K is the max for all implementations?
BTW, Where does the "2000000" come from? Shouldn't it be 1000000 if =20
you're converting to usec? If you're trying to add some slack, say so =20
rather than having a comment suggest that the output of that formula is =20
64K cycles. Or is there an implicit assumption that i2c runs at half =20
the system frequency? Is that assumption true for all implementations =20
that have this erratum?
> > In any case, you should send this patch to the i2c maintainer and =20
> list.
> >
>=20
> I don't have the name on top of my head. Is that =20
> linux-i2c@vger.kernel.org?
Yes, and Wolfram Sang <wsa@the-dreams.de> is the maintainer. This is =20
listed in the MAINTAINERS file.
-Scott=
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC] power/mpc85xx: Add delay after enabling I2C master
2013-07-23 18:43 ` Scott Wood
@ 2013-07-23 20:32 ` York Sun
0 siblings, 0 replies; 5+ messages in thread
From: York Sun @ 2013-07-23 20:32 UTC (permalink / raw)
To: Scott Wood; +Cc: albrecht.dress, linuxppc-dev
On 07/23/2013 11:43 AM, Scott Wood wrote:
>>
>> Yes. The max divider from sys clock to i2c clcok is 32K.
>> i2c->real_clk is the clock I2C controller pumps out, not its internal
>> operation clock.
>
> 32K is the max for all implementations?
Yes, according to application note 2919 (published).
>
> BTW, Where does the "2000000" come from? Shouldn't it be 1000000 if
> you're converting to usec? If you're trying to add some slack, say so
> rather than having a comment suggest that the output of that formula is
> 64K cycles. Or is there an implicit assumption that i2c runs at half
> the system frequency? Is that assumption true for all implementations
> that have this erratum?
The clock source is half the sysclk. This erratum applies to selected
85xx SoCs. I have confirmed with application team that it is safe to
apply the delay to all 85xx.
>
>> > In any case, you should send this patch to the i2c maintainer and list.
>> >
>>
>> I don't have the name on top of my head. Is that
>> linux-i2c@vger.kernel.org?
>
> Yes, and Wolfram Sang <wsa@the-dreams.de> is the maintainer. This is
> listed in the MAINTAINERS file.
>
I can resubmit this patch after the feedback is addressed.
York
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-07-23 20:33 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-05-13 21:27 [PATCH RFC] power/mpc85xx: Add delay after enabling I2C master York Sun
2013-07-23 0:33 ` [RFC] " Scott Wood
2013-07-23 15:37 ` York Sun
2013-07-23 18:43 ` Scott Wood
2013-07-23 20:32 ` York Sun
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).