From: Scott Wood <scottwood@freescale.com>
To: Timur Tabi <timur@freescale.com>
Cc: Linuxppc-dev@ozlabs.org, Linux I2C <i2c@lm-sensors.org>
Subject: Re: [PATCH] powerpc: i2c-mpc: make speed registers configurable via FDT
Date: Thu, 31 Jul 2008 14:01:46 -0500 [thread overview]
Message-ID: <48920C1A.7010605@freescale.com> (raw)
In-Reply-To: <48920607.5040606@freescale.com>
Timur Tabi wrote:
> Grant Likely wrote:
>
>> No it doesn't, it depends on the register interface to decide
>> compatibility. Clock interface is part of that.
>
> I don't think so. The interface for programming the clock registers is
> identical on all 8[356]xx parts. The only thing that matters is what specific
> values to put in the FDR and DFSR registers to get a desired I2C bus speed.
If it affects the values you need to write to the registers to achieve a
given result, how is it not a difference in the register interface?
> I propose the property "clock-frequency", like this:
>
> i2c@3000 {
> #address-cells = <1>;
> #size-cells = <0>;
> cell-index = <0>;
> compatible = "fsl-i2c";
> reg = <0x3000 0x100>;
> interrupts = <14 0x8>;
> interrupt-parent = <&ipic>;
> dfsrr;
> clock-frequency = <0xblablabla>; <-- added by U-Boot
> };
A clock-frequency property is OK, and is in line with what we do in
other types of nodes. However, in the long run it might be nice to
introduce some sort of clock binding where, for example, the i2c node
can point to a clock elsewhere in the device tree as an input clock.
That way, less knowledge is required by the firmware to poke values all
over the place, and it also allows one to describe situations where the
frequency of the input clock can change (such as in low-power modes).
-Scott
next prev parent reply other threads:[~2008-07-31 19:01 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
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 [this message]
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=48920C1A.7010605@freescale.com \
--to=scottwood@freescale.com \
--cc=Linuxppc-dev@ozlabs.org \
--cc=i2c@lm-sensors.org \
--cc=timur@freescale.com \
/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).