Skip to contentSkip to conversation

i2c: i2c-omap: Fix standard and fast mode prescalers

PATCH In review [email protected] 6 participants 10 messages Nov 14, 2008 – Nov 21, 2008

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 i2c: i2c-omap: Fix standard and fast mode prescalers

From: Eero Nurkkala <[email protected]>

The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications.

---
 drivers/i2c/busses/i2c-omap.c |   21 ++++++++++++++++++---
 1 files changed, 18 insertions(+), 3 deletions(-)
drivers/i2c/busses/i2c-omap.c +18 -3
index e708ebd..a42003a 100644
@@ -288,7 +288,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 	if (cpu_is_omap2430() || cpu_is_omap34xx()) {
 
 		/* HSI2C controller internal clk rate should be 19.2 Mhz */
-		internal_clk = 19200;
+		if (cpu_is_omap34xx()) {
+			if (dev->speed > 400)
+				internal_clk = 19200;
+			else if (dev->speed > 100)
+				internal_clk = 9600;
+			else
+				internal_clk = 4000;
+		} else {
+			internal_clk = 19200;
+		}
+
 		fclk_rate = clk_get_rate(dev->fclk) / 1000;
 
 		/* Compute prescaler divisor */
@@ -306,8 +316,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 			hssclh = fclk_rate / (dev->speed * 2) - 6;
 		} else {
 			/* To handle F/S modes */
-			fsscll = internal_clk / (dev->speed * 2) - 6;
-			fssclh = internal_clk / (dev->speed * 2) - 6;
+			if (cpu_is_omap34xx()) {
+				fsscll = internal_clk / (dev->speed * 2) - 7;
+				fssclh = internal_clk / (dev->speed * 2) - 5;
+			} else {
+				fsscll = internal_clk / (dev->speed * 2) - 6;
+				fssclh = internal_clk / (dev->speed * 2) - 6;
+			}
 		}
 		scll = (hsscll << OMAP_I2C_SCLL_HSSCLL) | fsscll;
 		sclh = (hssclh << OMAP_I2C_SCLH_HSSCLH) | fssclh;
Signature · 1 line
1.6.0
#1 lore raw
Quoted 10 lines · On Friday 14 November 2008, [email protected] wrote:

The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications.

Should this fix the bug causing the need for that recent ZOOM patch slowing down twl4030 communication to 400 MHz?

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

- Dave

#2 lore raw
Quoted 5 lines · David Brownell

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

I think it came from board-3430sdp.c

All other board files are based on that so is kind of a brainless change.

Just change a few stuff in the MACHINE_START and some function names. Remove some unneded functions and that's about it ;-)

Signature · 1 line
balbi
#3 lore raw
Quoted 8 lines · Felipe Balbi
Quoted 5 lines · David Brownell

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

I think it came from board-3430sdp.c

So you're saying there was *never* a need for that slowdown, and everyone was just copying an existing buglet?

I know I didn't make time to test whether faster speeds would work ... but had expected there was a reason, at some point, for that detuning.

Quoted 5 lines

All other board files are based on that so is kind of a brainless change.

Just change a few stuff in the MACHINE_START and some function names. Remove some unneded functions and that's about it ;-)

#4 lore raw
Quoted 8 lines · David Brownell
Quoted 7 lines · Felipe Balbi
Quoted 5 lines · David Brownell

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

Quoted 8 lines
Quoted 1 line

I think it came from board-3430sdp.c

So you're saying there was *never* a need for that slowdown, and everyone was just copying an existing buglet?

I know I didn't make time to test whether faster speeds would work ... but had expected there was a reason, at some point, for that detuning.

There was a need. But I think it should be fixed by now. I shall test tw5030 with 3.4Mbit/sec on monday. Will report.

Signature · 1 line
balbi
#5 lore raw

I had tested twl4030 at 3.4 Mbps couple of months back and it was working fine with current settings. It wasn't a rigorous testing though.

----- Original Message ----- From: "Felipe Balbi" <[email protected]>
To: "David Brownell" <[email protected]>
Cc: <[email protected]>; <[email protected]>; <[email protected]>
Sent: Saturday, November 15, 2008 3:16 AM
Subject: Re: [PATCH] i2c: i2c-omap: Fix standard and fast mode prescalers

Quoted 28 lines · David Brownell
Quoted 8 lines · Felipe Balbi
Quoted 7 lines · David Brownell
Quoted 5 lines

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

Quoted 8 lines
Quoted 1 line

I think it came from board-3430sdp.c

So you're saying there was *never* a need for that slowdown, and everyone was just copying an existing buglet?

I know I didn't make time to test whether faster speeds would work ... but had expected there was a reason, at some point, for that detuning.

There was a need. But I think it should be fixed by now. I shall test tw5030 with 3.4Mbit/sec on monday. Will report.

Signature · 5 lines
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#6 lore raw
Quoted 2 lines · chandra

I had tested twl4030 at 3.4 Mbps couple of months back and it was working fine with current settings. It wasn't a rigorous testing though.

My Beagle booted 2.6.28-rc5-omap with that speed, and it worked fine too. No errors even though I'm using the pmu_stat LED (on a TWL LED) for the MMC activity indicator ... so it got a decent amount of traffic.

(Oh, and this is *with* the $SUBJECT patch too.)

- Dave

#7 lore raw
In reply to David Brownell
Quoted 16 lines · David Brownell
Quoted 10 lines · On Friday 14 November 2008, [email protected] wrote:

The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications.

Should this fix the bug causing the need for that recent ZOOM patch slowing down twl4030 communication to 400 MHz?

Quoted 5 lines

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

When I put a scope to Beagle and Overo a couple of months back it looked to me like the i2c signals were just *barely* in spec for 2.6Mbit/sec, so I think that hardware might have been the limiting factor in the decision to choose 2.6 Mit/sec

Steve

#8 lore raw
In reply to David Brownell
Quoted 16 lines · ext David Brownell
Quoted 10 lines · On Friday 14 November 2008, [email protected] wrote:

The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications.

Should this fix the bug causing the need for that recent ZOOM patch slowing down twl4030 communication to 400 MHz?

Quoted 8 lines

And should it let at least some boards talk to their TWL chips at 3.4 MBit/sec (top speed for standard highspeed I2C) instead of 2.6 Mbit/sec (pokey slow)? I've always wondered why all the boards configured those links to be seemingly slower than allowed ...

- Dave

Well, this should not affect the High speed I2C at all. Only fast and slow I2C (100 and 400 khz).

maintainer
#9 lore raw
In reply to [email protected]
Quoted 12 lines · * [email protected] <[email protected]> [081114 00:43]:

From: Eero Nurkkala <[email protected]>

The prescalers for 100 kHz and 400 kHz mode are wrong. The internal clock is the fclock divided by the prescaler. The PSC is an 8 bit field in omap3430. Moreover, the scll and sclh values should be adjusted properly. Having the correct prescaler is important in the process of getting a finite i2c clock. In addition, the prescaler is used in the process of activating the correct noise filter and thus, lets more error resilient i2c communications.

I guess this should be also updated to use dev->rev so it works on 2430 too?

Tony

Quoted 51 lines
---
 drivers/i2c/busses/i2c-omap.c |   21 ++++++++++++++++++---
 1 files changed, 18 insertions(+), 3 deletions(-)
drivers/i2c/busses/i2c-omap.c +18 -3
index e708ebd..a42003a 100644
@@ -288,7 +288,17 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 	if (cpu_is_omap2430() || cpu_is_omap34xx()) {
 
 		/* HSI2C controller internal clk rate should be 19.2 Mhz */
-		internal_clk = 19200;
+		if (cpu_is_omap34xx()) {
+			if (dev->speed > 400)
+				internal_clk = 19200;
+			else if (dev->speed > 100)
+				internal_clk = 9600;
+			else
+				internal_clk = 4000;
+		} else {
+			internal_clk = 19200;
+		}
+
 		fclk_rate = clk_get_rate(dev->fclk) / 1000;
 
 		/* Compute prescaler divisor */
@@ -306,8 +316,13 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
 			hssclh = fclk_rate / (dev->speed * 2) - 6;
 		} else {
 			/* To handle F/S modes */
-			fsscll = internal_clk / (dev->speed * 2) - 6;
-			fssclh = internal_clk / (dev->speed * 2) - 6;
+			if (cpu_is_omap34xx()) {
+				fsscll = internal_clk / (dev->speed * 2) - 7;
+				fssclh = internal_clk / (dev->speed * 2) - 5;
+			} else {
+				fsscll = internal_clk / (dev->speed * 2) - 6;
+				fssclh = internal_clk / (dev->speed * 2) - 6;
+			}
 		}
 		scll = (hsscll << OMAP_I2C_SCLL_HSSCLL) | fsscll;
 		sclh = (hssclh << OMAP_I2C_SCLH_HSSCLH) | fssclh;
Signature · 6 lines
1.6.0

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html