From: Wolfgang Grandegger <wg@grandegger.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: linuxppc-dev@ozlabs.org, devicetree-discuss@ozlabs.org
Subject: Re: [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable
Date: Wed, 01 Apr 2009 09:51:57 +0200 [thread overview]
Message-ID: <49D31D1D.6020004@grandegger.com> (raw)
In-Reply-To: <fa686aa40903310841x42876819rafe3e8bf24b8646e@mail.gmail.com>
Grant Likely wrote:
> On Tue, Mar 31, 2009 at 6:37 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> This patch makes the I2C bus speed configurable by using the I2C node
>> property "clock-frequency". If the property is not defined, the old
>> fixed clock settings will be used for backward comptibility.
>>
>> The generic I2C clock properties, especially the CPU-specific source
>> clock pre-scaler are defined via the OF match table:
>>
>> static const struct of_device_id mpc_i2c_of_match[] = {
>> {.compatible = "fsl,mpc5200b-i2c",
>> .data = (void *)FSL_I2C_DEV_CLOCK_5200, },
>> {.compatible = "fsl,mpc5200-i2c",
>> .data = (void *)FSL_I2C_DEV_CLOCK_5200, },
>> {.compatible = "fsl,mpc8313-i2c",
>> .data = (void *)FSL_I2C_DEV_SEPARATE_DFSRR, },
>> {.compatible = "fsl,mpc8543-i2c",
>> .data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
>> FSL_I2C_DEV_CLOCK_DIV2), },
>> {.compatible = "fsl,mpc8544-i2c",
>> .data = (void *)(FSL_I2C_DEV_SEPARATE_DFSRR |
>> FSL_I2C_DEV_CLOCK_DIV23), },
>> /* Backward compatibility */
>> {.compatible = "fsl-i2c", },
>> {},
>> };
>
>
> Instead passing in a flag (and using an ugly cast to do it) which is
> then checked inside the mpc_i2c_setclock(), you should do this
> instead:
>
> struct fsl_i2c_match_data {
> int static void *(setclock)(struct device_node *node, struct
> mpc_i2c *i2c, u32 clock);
> int flags;
> /* Other stuff can go here */
> };
>
> static const struct of_device_id mpc_i2c_of_match[] = {
> {.compatible = "fsl,mpc5200b-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_mpc5200, },
> },
> {.compatible = "fsl,mpc5200-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_mpc5200, },
> },
> {.compatible = "fsl,mpc8313-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> },
> {.compatible = "fsl,mpc8543-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> .flags = FSL_I2C_DEV_CLOCK_DIV2,
> },
> {.compatible = "fsl,mpc8544-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock_separate_dfsrr, },
> .flags = FSL_I2C_DEV_CLOCK_DIV23,
> },
> /* Backward compatibility */
> {.compatible = "fsl-i2c",
> .data = (struct fsl_i2c_match_data[]) { .setclock =
> mpc_i2c_setclock, },
> },
> {},
> };
>
> The table definition is more verbose this way, but I think it results
> in more understandable and easier to extend code. It also adds lets
> the compiler do more type checking for you.
OK but I don't like the callback function to do the settings. We need
backward compatibility with old DTS files including the ugly "dfsrr"
property, right? Then it seems consequent to continue using i2c->flags
for that purpose and not to introduce another method. If we don't need
backward compatibility, we could drop the flags completely and just use
callback functions.
> Also, this ...
>
>> --- linux-2.6.orig/arch/powerpc/sysdev/fsl_soc.c 2009-03-31 13:25:08.000000000 +0200
>> +++ linux-2.6/arch/powerpc/sysdev/fsl_soc.c 2009-03-31 13:34:40.531721011 +0200
>> +int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
>> +{
>> [...]
>> +}
>> +EXPORT_SYMBOL(fsl_i2c_get_fdr);
>
> ... and this ...
>
>> --- linux-2.6.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31 13:25:08.000000000 +0200
>> +++ linux-2.6/arch/powerpc/platforms/52xx/mpc52xx_common.c 2009-03-31 13:28:54.309718526 +0200
>> +int fsl_i2c_get_fdr(struct device_node *node, u32 i2c_clock, u32 i2c_flags)
>> +{
>> [...]
>> +}
>> +EXPORT_SYMBOL(fsl_i2c_get_fdr);
>
> does not work on a multiplatform kernel. Both 8xxx and 52xx support
> can be selected at the same time.
OK, then we need different functions including stubs.
Wolfgang.
next prev parent reply other threads:[~2009-04-01 7:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-31 12:37 [PATCH 0/8] powerpc: i2c-mpc: make I2C bus speed configurable Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 1/8] [PATCH 3/4] powerpc/85xx: Move gianfar mdio nodes under the Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 2/8] [PATCH 01/28] RTC: Add support for RX8025 chip Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 3/8] powerpc/85xx: Add support for the "socrates" board (MPC8544) Wolfgang Grandegger
2009-03-31 15:57 ` Grant Likely
2009-03-31 19:20 ` Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 4/8] powerpc: i2c-mpc: preserve I2C clocking Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 5/8] powerpc: i2c-mpc: make I2C bus speed configurable Wolfgang Grandegger
2009-03-31 15:41 ` Grant Likely
2009-04-01 7:51 ` Wolfgang Grandegger [this message]
2009-04-01 13:30 ` Grant Likely
2009-04-01 13:41 ` Wolfgang Grandegger
2009-04-01 13:55 ` Wolfgang Grandegger
2009-04-01 13:55 ` Grant Likely
2009-04-02 6:55 ` Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 6/8] --- arch/powerpc/boot/dts/socrates.dts | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) Wolfgang Grandegger
2009-03-31 23:04 ` David Gibson
2009-04-01 7:31 ` Wolfgang Grandegger
2009-04-01 11:09 ` David Gibson
2009-04-01 11:59 ` Wolfgang Grandegger
2009-04-01 23:57 ` David Gibson
2009-04-01 12:30 ` Anton Vorontsov
2009-04-01 23:58 ` David Gibson
2009-03-31 12:37 ` [PATCH 7/8] Re: [PATCH 1/2] NAND: Add support for oob size 128 Wolfgang Grandegger
2009-03-31 12:37 ` [PATCH 8/8] NAND: Add support for NAND on the Socrates board Wolfgang Grandegger
2009-03-31 12:49 ` [PATCH 0/8] powerpc: i2c-mpc: make I2C bus speed configurable Wolfgang Grandegger
2009-03-31 16:23 ` 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=49D31D1D.6020004@grandegger.com \
--to=wg@grandegger.com \
--cc=devicetree-discuss@ozlabs.org \
--cc=grant.likely@secretlab.ca \
--cc=linuxppc-dev@ozlabs.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).