linux-kernel - Re: [PATCH] OMAP: I2C driver for TI OMAP boards #3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060807145832.GF10387@atomide.com>
Date:	Mon, 7 Aug 2006 17:58:33 +0300
From:	Tony Lindgren <tony@...mide.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	Komal Shah <komal_shah802003@...oo.com>,
	David Brownell <david-b@...bell.net>, r-woodruff2@...com,
	linux-kernel@...r.kernel.org, Andrew Morton <akpm@...l.org>,
	Greg KH <gregkh@...e.de>, i2c@...sensors.org
Subject: Re: [PATCH] OMAP: I2C driver for TI OMAP boards #3

Hi,

* Jean Delvare <khali@...ux-fr.org> [060805 11:31]:
> 
> > >> +		if (armxor_rate > 16000000)
> > >> +			psc = (armxor_rate + 8000000) / 12000000;
> > >> +		else
> > >> +			psc = 0;
> > 
> > >Can you please explain this formula?
> > 
> > The OMAP core uses 8-bit value to divide the system clock (SCLK) and
> > generates its own sampling clock (ICLK), and the core logic is sampled
> > at clock rate of the system clock for the module, divided by (prescaler value + 1)
> 
> I should have been more precise, I guess. What surprises me are the
> numbers themselves. It's frequent to see forumlae of the form
> "a = (b + c/2) / c" to divide with proper rounding, but here you have
> 2c/3 instread of c/2. My question was more like: is it intentional, or a
> typo? Also, with the code above, psc will never have value 1. The "if"
> part will always compute to at least 2, and the "else" part to 0. Is
> this OK?
> 

Hmmm, this sounds like a bug somewhere. TRM for 5912 says the I2C clock
must be prescaled to be between 7 - 12 MHz [1]. The XOR input clock is
typically 12, 13 or 19.2 MHz. So we should have code that produces:

XOR Mhz	Divider	Prescaler
12	1	0
13	2	1
19.2	2	1

Then again the original old code produces something different too [2]...

I suspect the original code had some hw workarounds and and later code
may have a conversion bug somewhere :)

I suggest we keep the code as is for now since it's known to work on
all omaps, and then submit a follow-up patch later once we have
verified that that code based on the TRM works on all omaps.

Regards,

Tony

[1] http://focus.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spru681
[2] http://linux-omap.bkbits.net:8080/main/diffs/drivers/i2c/busses/i2c-omap.c@...2?nav=index.html|src/|src/drivers|src/drivers/i2c|src/drivers/i2c/busses|hist/drivers/i2c/busses/i2c-omap.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/