From: Wolfgang Grandegger <wg@grandegger•com>
To: Jon Smirl <jonsmirl@gmail•com>
Cc: Scott Wood <scottwood@freescale•com>,
Timur Tabi <timur@freescale•com>, Linux I2C <i2c@lm-sensors•org>,
Linuxppc-dev@ozlabs•org
Subject: Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Date: Thu, 31 Jul 2008 19:22:32 +0200 [thread overview]
Message-ID: <4891F4D8.9090905@grandegger.com> (raw)
In-Reply-To: <9e4733910807310849g7e5612dbk9536733e061af8ad@mail.gmail.com>
Jon Smirl wrote:
> On 7/31/08, Wolfgang Grandegger <wg@grandegger•com> wrote:
>> Grant Likely wrote:
>>
>>> On Fri, Jul 25, 2008 at 11:19:41AM -0500, Timur Tabi wrote:
>>>
>>>> Wolfgang Grandegger wrote:
>>>>
>>>>
>>>>> I know but we still need an algorithm for MPC52xx and MPC82xx as well.
>>>>>
>>>> That's true, but I still think hard-coding values of DFSR and FDR in the
>> device
>>>> tree is not a good way to do this.
>>>>
>>> I agree, it should encode real frequencies, not raw register values.
>>>
>> Digging deeper I'm frightened by plenty of platform specific code. We would
>> need:
>>
>> - one table of divider,fdr,dfsr values for the MPC82/3/5/6xx processors
>> (already available from Timur's U-Boot implementation)
>>
>> - one table of divider,fdr values for the MPC5200 rev A.
>>
>> - one table of divider,fdr values for the MPC5200 rev B.
>> (the Rev. B has two more pre-scaler bits).
>
> Aren't the tables in the manual there just to make it easy for a human
> to pick out the line they want? For a computer you'd program the
> formula that was used to create the tables.
I have the formulas to create the tables, also for the MPC5200 Rev. A
and B. That was not my point. I'm worried about arch specific code in
i2c-mpc.c. It should go somewhere to arch/powerpc.
> I agree that it took me half an hour to figure out the formula that
> was needed to compute the i2s clocks, but once you figure out the
> formula it solves all of the cases and no one needs to read the manual
> any more. The i2c formula may even need a small loop which compares
> different solutions looking for the smallest error term. But it's a
> small space to search.
>
> These device tree flags should be removed, the driver can ask the
> platform code what CPU it is running on.
>
> if (of_get_property(op->node, "dfsrr", NULL))
> i2c->flags |= FSL_I2C_DEV_SEPARATE_DFSRR;
>
> if (of_device_is_compatible(op->node, "fsl,mpc5200-i2c") ||
> of_device_is_compatible(op->node, "mpc5200-i2c"))
> i2c->flags |= FSL_I2C_DEV_CLOCK_5200;
>
> static void mpc_i2c_setclock(struct mpc_i2c *i2c)
> {
> /* Set clock and filters */
> if (i2c->flags & FSL_I2C_DEV_SEPARATE_DFSRR) {
> writeb(0x31, i2c->base + MPC_I2C_FDR);
> writeb(0x10, i2c->base + MPC_I2C_DFSRR);
> } else if (i2c->flags & FSL_I2C_DEV_CLOCK_5200)
> writeb(0x3f, i2c->base + MPC_I2C_FDR);
> else
> writel(0x1031, i2c->base + MPC_I2C_FDR);
> }
>
> These defines shouldn't be here, they should get the offset from the
> right header file for the CPU. But it appears that structures for the
> i2c memory map haven't been done for the various CPUs.
>
> #define MPC_I2C_FDR 0x04
> #define MPC_I2C_CR 0x08
> #define MPC_I2C_SR 0x0c
> #define MPC_I2C_DR 0x10
> #define MPC_I2C_DFSRR 0x14
>
> There appears to be one for i2x8xxx but not the other CPUs.
>
> /* I2C
> */
> typedef struct i2c {
> u_char i2c_i2mod;
> char res1[3];
> u_char i2c_i2add;
> char res2[3];
> u_char i2c_i2brg;
> char res3[3];
> u_char i2c_i2com;
> char res4[3];
> u_char i2c_i2cer;
> char res5[3];
> u_char i2c_i2cmr;
> char res6[0x8b];
> } i2c8xx_t;
The I2C interface for the MPC5200 is not compatible with the one for the
MPC83/4/5/6xx, AFAIK.
Wolfgang.
next prev parent reply other threads:[~2008-07-31 17:22 UTC|newest]
Thread overview: 96+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-25 7:37 [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT Wolfgang Grandegger
2008-07-25 8:51 ` Jochen Friedrich
2008-07-25 9:04 ` Wolfgang Grandegger
2008-07-25 13:12 ` Grant Likely
2008-07-25 14:21 ` Timur Tabi
2008-07-25 15:04 ` Jon Smirl
2008-07-25 15:23 ` Wolfgang Grandegger
2008-07-25 16:19 ` Timur Tabi
2008-07-27 1:27 ` Grant Likely
2008-07-31 11:51 ` Wolfgang Grandegger
2008-07-31 15:49 ` Jon Smirl
2008-07-31 15:55 ` Timur Tabi
2008-07-31 23:32 ` [i2c] " Trent Piepho
2008-08-01 13:17 ` Timur Tabi
2008-08-01 15:47 ` Scott Wood
2008-08-01 19:47 ` Trent Piepho
2008-08-01 19:50 ` Timur Tabi
2008-07-31 17:22 ` Wolfgang Grandegger [this message]
2008-07-31 17:31 ` Grant Likely
2008-07-31 17:51 ` Wolfgang Grandegger
2008-07-31 17:54 ` Timur Tabi
2008-07-31 18:07 ` Wolfgang Grandegger
2008-07-31 18:06 ` Timur Tabi
2008-07-31 18:07 ` Grant Likely
2008-07-31 18:10 ` Timur Tabi
2008-07-31 18:21 ` Grant Likely
2008-07-31 18:09 ` Grant Likely
2008-07-31 18:13 ` Timur Tabi
2008-07-31 18:28 ` Grant Likely
2008-07-31 18:35 ` Timur Tabi
2008-07-31 18:57 ` Jon Smirl
2008-07-31 19:01 ` Timur Tabi
2008-07-31 19:25 ` Grant Likely
2008-08-01 0:22 ` [i2c] " Trent Piepho
2008-08-01 1:19 ` Jon Smirl
2008-08-01 1:36 ` Trent Piepho
2008-08-01 1:44 ` Jon Smirl
2008-08-01 15:02 ` Timur Tabi
2008-08-01 16:05 ` Jon Smirl
2008-08-01 7:29 ` Wolfgang Grandegger
2008-08-01 2:03 ` Grant Likely
2008-08-01 2:35 ` Jon Smirl
2008-08-01 13:25 ` Timur Tabi
2008-08-01 14:28 ` Jon Smirl
2008-08-01 14:32 ` Jon Smirl
2008-08-01 21:14 ` Trent Piepho
2008-08-01 7:25 ` Wolfgang Grandegger
2008-08-01 14:38 ` Grant Likely
2008-07-31 19:01 ` Scott Wood
2008-07-31 19:08 ` Timur Tabi
2008-07-31 19:15 ` Scott Wood
2008-07-31 19:19 ` Timur Tabi
2008-07-31 19:21 ` Scott Wood
2008-07-31 19:22 ` Timur Tabi
2008-07-31 19:11 ` Jon Smirl
2008-07-31 19:14 ` Grant Likely
2008-07-31 19:24 ` Wolfgang Grandegger
2008-07-31 19:24 ` Timur Tabi
2008-07-31 19:54 ` Wolfgang Grandegger
2008-07-31 19:58 ` Timur Tabi
2008-07-31 20:17 ` Wolfgang Grandegger
2008-07-31 20:19 ` Timur Tabi
2008-07-31 20:28 ` Wolfgang Grandegger
2008-07-31 20:28 ` Timur Tabi
2008-07-31 20:30 ` Grant Likely
2008-07-31 20:32 ` Jon Smirl
2008-07-31 20:35 ` Grant Likely
2008-07-31 20:37 ` Timur Tabi
2008-07-31 20:48 ` Grant Likely
2008-07-31 20:55 ` Jon Smirl
2008-07-31 20:56 ` Scott Wood
2008-07-31 20:56 ` Timur Tabi
2008-07-31 21:03 ` Jon Smirl
2008-07-31 21:10 ` Timur Tabi
2008-07-31 21:14 ` Wolfgang Grandegger
2008-07-31 21:17 ` Timur Tabi
2008-08-01 1:16 ` [i2c] " Trent Piepho
2008-08-01 0:57 ` Trent Piepho
2008-07-31 20:35 ` Timur Tabi
2008-07-31 20:43 ` Jon Smirl
2008-07-31 20:44 ` Timur Tabi
2008-07-31 19:59 ` Grant Likely
2008-07-31 20:00 ` Timur Tabi
2008-07-31 20:20 ` Wolfgang Grandegger
2008-07-31 20:19 ` Timur Tabi
2008-08-01 0:46 ` [i2c] " Trent Piepho
2008-08-01 14:34 ` Grant Likely
2008-08-01 14:48 ` Geert Uytterhoeven
2008-07-31 17:35 ` Jon Smirl
2008-07-31 16:51 ` Grant Likely
2008-07-31 17:06 ` Jon Smirl
2008-07-31 17:36 ` Grant Likely
2008-07-31 17:47 ` Jon Smirl
2008-07-31 17:24 ` Wolfgang Grandegger
2008-07-25 15:34 ` Wolfgang Grandegger
2008-07-27 1:25 ` Grant Likely
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=4891F4D8.9090905@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=Linuxppc-dev@ozlabs$(echo .)org \
--cc=i2c@lm-sensors$(echo .)org \
--cc=jonsmirl@gmail$(echo .)com \
--cc=scottwood@freescale$(echo .)com \
--cc=timur@freescale$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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