From: Wolfgang Grandegger <wg@grandegger•com>
To: Grant Likely <grant.likely@secretlab•ca>
Cc: Scott Wood <scottwood@freescale•com>,
Linuxppc-dev@ozlabs•org, Linux I2C <i2c@lm-sensors•org>,
Timur Tabi <timur@freescale•com>
Subject: Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Date: Thu, 31 Jul 2008 19:51:48 +0200 [thread overview]
Message-ID: <4891FBB4.9090901@grandegger.com> (raw)
In-Reply-To: <fa686aa40807311031r66f6451aw206faf54509c14d9@mail.gmail.com>
Grant Likely wrote:
> On Thu, Jul 31, 2008 at 11:22 AM, Wolfgang Grandegger <wg@grandegger•com> wrote:
>> 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.
>
> Oh, hey, even better.
>
>> That was not my point. I'm worried about arch specific code in i2c-mpc.c. It
>> should go somewhere to arch/powerpc.
>
> i2c-mpc *is* arch specific. I really don't think you need to worry
> about adding a block of code for each supported SoC family. Just
> change the of_match table to look something like this:
>
> static const struct of_device_id mpc_i2c_of_match[] = {
> {.compatible = "fsl,mpc5200b-i2c", .data = fsl_i2c_mpc5200b_set_freq, },
> {.compatible = "fsl,mpc5200-i2c", .data = fsl_i2c_mpc5200_set_freq, },
> {.compatible = "fsl,mpc8260-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8349-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8540-i2c", .data = fsl_i2c_mpc8xxx_set_freq, },
> {.compatible = "fsl,mpc8543-i2c", .data = fsl_i2c_mpc8xxx_div2_set_freq, },
> {.compatible = "fsl,mpc8544-i2c", .data = fsl_i2c_mpc8xxx_div3_set_freq, },
>
> /* keep this only for older device trees with some support
> code to figure out
> what .data should have pointed to. */
> {.compatible = "fsl-i2c", },
> {},
> };
> MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
Cool, this would also make the "dfsrr" property obsolete. Just the
MPC8544 needs more attention because the I2C clock can be programmed to
be freq/2 or freq/3.
Wolfgang.
next prev parent reply other threads:[~2008-07-31 17:51 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
2008-07-31 17:31 ` Grant Likely
2008-07-31 17:51 ` Wolfgang Grandegger [this message]
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=4891FBB4.9090901@grandegger.com \
--to=wg@grandegger$(echo .)com \
--cc=Linuxppc-dev@ozlabs$(echo .)org \
--cc=grant.likely@secretlab$(echo .)ca \
--cc=i2c@lm-sensors$(echo .)org \
--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