From: Aaro Koskinen <aaro.koskinen-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
To: "ext balajitk-l0cyMroinI0@public.gmane.org"
<balajitk-l0cyMroinI0@public.gmane.org>
Cc: "linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org"
<ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>,
"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"nm-l0cyMroinI0@public.gmane.org"
<nm-l0cyMroinI0@public.gmane.org>
Subject: Re: [PATCH]i2c-omap: pass scll, sclh through board file for Errata i585
Date: Fri, 07 May 2010 12:28:22 +0300 [thread overview]
Message-ID: <4BE3DD36.10308@nokia.com> (raw)
In-Reply-To: <1273214105-22894-1-git-send-email-balajitk-l0cyMroinI0@public.gmane.org>
Hi,
balajitk-l0cyMroinI0@public.gmane.org wrote:
> From: Balaji T K <balajitk-l0cyMroinI0@public.gmane.org>
>
> Errata ID: i535 - I2C1 to 3 SCL low period is shorter in FS mode
> Due to IO cell influence, I2C1 to 3 SCL low period can be shorter than expected.
> As a result, I2C AC timing (SCL minimum low period) in FS mode may not meet
> the timing configured by software.
>
> I2C1 to 3, SCL low period is programmable and proper adjustments
> to the SCLL/HSSCLL values can avoid the issue.
>
> This patch provides flexibility to control tLOW, tHIGH for different boards.
> scll, sclh values are to be provide in board data
> for differents modes (standard, fast and high speed mode)
> as the scl rate (I2C bus speed) can be changed by bootargs.
This patch is very much needed, because these values are highly board specific.
At the moment we are forced to patch the i2c bus driver when finetuning the I2C
timings for a certain board, which is ugly.
However, I have comment one about the implementation:
> @@ -451,24 +458,47 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>
> /* For first phase of HS mode */
> scl = internal_clk / 400;
> - fsscll = scl - (scl / 3) - 7;
> - fssclh = (scl / 3) - 5;
> + if ((pdata->hs_phase1.scll > 7) &&
> + (pdata->hs_phase1.sclh > 5)) {
> + fsscll = pdata->hs_phase1.scll - 7;
> + fssclh = pdata->hs_phase1.sclh - 5;
> + } else {
> + fsscll = scl - (scl / 3) - 7;
> + fssclh = (scl / 3) - 5;
> + }
> /* For second phase of HS mode */
> scl = fclk_rate / dev->speed;
> - hsscll = scl - (scl / 3) - 7;
> - hssclh = (scl / 3) - 5;
> + if ((pdata->hs_phase2.scll > 7) &&
> + (pdata->hs_phase2.sclh > 5)) {
> + hsscll = pdata->hs_phase2.scll - 7;
> + hssclh = pdata->hs_phase2.sclh - 5;
> + } else {
> + hsscll = scl - (scl / 3) - 7;
> + hssclh = (scl / 3) - 5;
> + }
> } else if (dev->speed > 100) {
> unsigned long scl;
>
> /* Fast mode */
> scl = internal_clk / dev->speed;
> - fsscll = scl - (scl / 3) - 7;
> - fssclh = (scl / 3) - 5;
> + if ((pdata->fast.scll > 7) && (pdata->fast.sclh > 5)) {
> + fsscll = pdata->fast.scll - 7;
> + fssclh = pdata->fast.sclh - 5;
> + } else {
> + fsscll = scl - (scl / 3) - 7;
> + fssclh = (scl / 3) - 5;
> + }
> } else {
> /* Standard mode */
> - fsscll = internal_clk / (dev->speed * 2) - 7;
> - fssclh = internal_clk / (dev->speed * 2) - 5;
> + if ((pdata->standard.scll > 7) &&
> + (pdata->standard.sclh > 5)) {
> + fsscll = pdata->standard.scll - 7;
> + fssclh = pdata->standard.sclh - 5;
> + } else {
> + fsscll = internal_clk / (dev->speed * 2) - 7;
> + fssclh = internal_clk / (dev->speed * 2) - 5;
> + }
I think it would be simpler if we move these calcuations into a function.
E.g. something like:
if (dev->speed > 400) {
/* HS mode */
pdata->set_scl(internal_clk, 400, &fsscll, &fssclh);
pdata->set_scl(fclk_rate, dev->speed, &hsscll, &hssclh);
} else {
/* Fast & standard mode */
pdata->set_scl(internal_clk, dev->speed, &fsscll, &fssclh);
}
Then the default function would be something like:
static void omap_i2c_default_scl(unsigned clk, unsigned speed, u16 *scll, u16 *sclh)
{
if (speed > 100) {
/* Fast & HS modes */
unsigned scl = clk / speed;
*scll = scl - (scl / 3) - 7;
*sclh = (scl / 3) - 5;
} else {
/* Standard mode */
*scll = clk / (speed * 2) - 7;
*scll = clk / (speed * 2) - 5;
}
}
And the platform data would just provide a board-specific function if needed.
A.
next prev parent reply other threads:[~2010-05-07 9:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-07 6:35 [PATCH]i2c-omap: pass scll, sclh through board file for Errata i585 balajitk-l0cyMroinI0
[not found] ` <1273214105-22894-1-git-send-email-balajitk-l0cyMroinI0@public.gmane.org>
2010-05-07 9:28 ` Aaro Koskinen [this message]
2010-05-10 15:02 ` Krishnamoorthy, Balaji T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BE3DD36.10308@nokia.com \
--to=aaro.koskinen-xnzwkgviw5gavxtiumwx3w@public.gmane.org \
--cc=balajitk-l0cyMroinI0@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=nm-l0cyMroinI0@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).