Jon Smirl wrote:
On 7/31/08, Trent Piepho [EMAIL PROTECTED] wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
right clock value into the variable. For mpc8
Trent Piepho wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
[...snip...]
I don't see why we want to go through the trouble of having uboot tell
us things about a chip that are fixed in stone. Obviously something
like the frequency of the external crystal needs to be passed up, but
why pass up
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho [EMAIL PROTECTED] wrote:
The real problem, which kept me from making a patch to do this months ago,
is that the source clock that the I2C freq divider applies to is different
for just about every MPC8xxx platform. Not just a different value, but a
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl [EMAIL PROTECTED] wrote:
I've having trouble with whether these clocks are a system resource or
something that belongs to i2c. If they are a system resource then we
should make nodes in the root and use a phandle in the i2c node to
link to them.
I
On 8/1/08, Timur Tabi [EMAIL PROTECTED] wrote:
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl [EMAIL PROTECTED] wrote:
I've having trouble with whether these clocks are a system resource or
something that belongs to i2c. If they are a system resource then we
should make nodes in the root
On 8/1/08, Timur Tabi [EMAIL PROTECTED] wrote:
On Thu, Jul 31, 2008 at 9:35 PM, Jon Smirl [EMAIL PROTECTED] wrote:
I've having trouble with whether these clocks are a system resource or
something that belongs to i2c. If they are a system resource then we
should make nodes in the root
On Thu, Jul 31, 2008 at 6:46 PM, Trent Piepho [EMAIL PROTECTED] wrote:
The i2c controller just uses some system clock that was handy. For each
chip, the designers consult tea leaves to choose a system clock at random
to connect to the i2c controller.
heh; I thought it was the phase of the
On Fri, Aug 1, 2008 at 1:25 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/31/08, Trent Piepho [EMAIL PROTECTED] wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The
On Thu, 31 Jul 2008, Trent Piepho wrote:
The i2c controller just uses some system clock that was handy. For each
chip, the designers consult tea leaves to choose a system clock at random
to connect to the i2c controller.
Oh, they decided which clock to choose at design time, not at power-on
Jon Smirl wrote:
What about the Efika which is mpc5200 based and doesn't use uboot?
How does the Efika handle the dozen other properties that U-Boot normally
initializes in the device tree?
--
Timur Tabi
Linux Kernel Developer @ Freescale
___
On Fri, Aug 01, 2008 at 08:17:25AM -0500, Timur Tabi wrote:
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho [EMAIL PROTECTED] wrote:
Sometimes the two i2c controllers don't even
have the same clock.
On which platform is that the case? I thought I had all 8[356]xx
boards covered. Did I
On 8/1/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
What about the Efika which is mpc5200 based and doesn't use uboot?
How does the Efika handle the dozen other properties that U-Boot normally
initializes in the device tree?
Efika is like the original OpenFirmware. It has a
On Fri, 1 Aug 2008, Timur Tabi wrote:
On Thu, Jul 31, 2008 at 6:32 PM, Trent Piepho [EMAIL PROTECTED] wrote:
The real problem, which kept me from making a patch to do this months ago,
is that the source clock that the I2C freq divider applies to is different
for just about every MPC8xxx
Trent Piepho wrote:
All 83xx other than 832x.
Never mind, I forgot that 83xx support for i2c1_clk was already in U-Boot:
#if defined(CONFIG_MPC834X)
i2c1_clk = tsec2_clk;
#elif defined(CONFIG_MPC8360)
i2c1_clk = csb_clk;
#elif defined(CONFIG_MPC832X)
i2c1_clk = enc_clk;
On Fri, 1 Aug 2008, Jon Smirl wrote:
I don't like the third choice. Keep a simple Linux driver for i2c and
the platform, and then move all of the messy code into uboot. BTW,
the messy code is about 10 lines. It's going to take more than 10
lines to hide those 10 lines.
It's not being _moved_
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.
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] 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
Jon Smirl wrote:
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.
Actually, the tables in the manuals are just an example of what can be
programmed. They don't
On Thu, Jul 31, 2008 at 5:51 AM, Wolfgang Grandegger [EMAIL PROTECTED] 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
On 7/31/08, Grant Likely [EMAIL PROTECTED] wrote:
If you're careful, the table doesn't need to be huge. It can be
marked as initdata and conditionally compiled depending on which
architectures are compiled in. You should use .data in the driver's
of_device_id table to provide machine
Jon Smirl wrote:
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] 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
Grant Likely wrote:
On Thu, Jul 31, 2008 at 5:51 AM, Wolfgang Grandegger [EMAIL PROTECTED] 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,
On Thu, Jul 31, 2008 at 11:22 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] 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
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
There appears to be one for i2x8xxx but not the other CPUs.
/* I2C
*/
typedef struct i2c {
u_char i2c_i2mod;
charres1[3];
u_char i2c_i2add;
charres2[3];
On 7/31/08, Grant Likely [EMAIL PROTECTED] wrote:
On Thu, Jul 31, 2008 at 11:06 AM, Jon Smirl [EMAIL PROTECTED] wrote:
On 7/31/08, Grant Likely [EMAIL PROTECTED] wrote:
If you're careful, the table doesn't need to be huge. It can be
marked as initdata and conditionally compiled
Grant Likely wrote:
On Thu, Jul 31, 2008 at 11:22 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Grant Likely wrote:
On Fri, Jul 25, 2008 at 11:19:41AM -0500, Timur Tabi wrote:
Wolfgang Grandegger wrote:
I know
Grant Likely wrote:
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 =
Timur Tabi wrote:
Grant Likely wrote:
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,
On Thu, Jul 31, 2008 at 12:07 PM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
We could add a property source-clock-divider = 2/3 if it's needed!?
fsl,source-clock-divider
But, yes, this is a good solution (assuming that it is a board or SoC
characteristic, and not just a choice that the
Wolfgang Grandegger wrote:
We could add a property source-clock-divider = 2/3 if it's needed!?
How about we just get U-Boot to put the core frequency in the device tree?
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Grant Likely wrote:
On Thu, Jul 31, 2008 at 12:07 PM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote:
We could add a property source-clock-divider = 2/3 if it's needed!?
fsl,source-clock-divider
But, yes, this is a good solution (assuming that it is a board or SoC
characteristic, and not
Grant Likely wrote:
This is a solved problem. The device tree simple claims compatibility
with an older part that has the identical register-level interface.
That would assume that the clock frequency is the only thing that decides
compatibility, which may technically be true now, but I don't
On Thu, Jul 31, 2008 at 01:10:30PM -0500, Timur Tabi wrote:
Grant Likely wrote:
On Thu, Jul 31, 2008 at 12:07 PM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote:
We could add a property source-clock-divider = 2/3 if it's needed!?
fsl,source-clock-divider
But, yes, this is a good
On Thu, Jul 31, 2008 at 01:13:10PM -0500, Timur Tabi wrote:
Grant Likely wrote:
This is a solved problem. The device tree simple claims compatibility
with an older part that has the identical register-level interface.
That would assume that the clock frequency is the only thing that
On 7/31/08, Timur Tabi [EMAIL PROTECTED] 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.
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
Jon Smirl wrote:
The existence of the dfsrr and fsl,mpc5200-i2c attributes imply to me
that the compatible strings were not done correctly. If these devices
really were compatible we wouldn't need extra attributes to tell them
apart.
I agree with that.
So I'm with Grant on adding
On 7/31/08, Scott Wood [EMAIL PROTECTED] wrote:
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
On Thu, Jul 31, 2008 at 01:35:51PM -0500, 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
Scott Wood wrote:
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
Timur Tabi wrote:
Scott Wood wrote:
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
On Thu, Jul 31, 2008 at 02:57:25PM -0400, Jon Smirl wrote:
On 7/31/08, Timur Tabi [EMAIL PROTECTED] wrote:
Grant Likely wrote:
I propose the property clock-frequency, like this:
[EMAIL PROTECTED] {
#address-cells = 1;
Wolfgang Grandegger wrote:
No, the source clock is not identical for all 8[356]xx. Some use half or
even a third of the SOC clock frequency.
The platform clock divided by 2 or 3 *is* the source clock to the I2C. That's
what I'm talking about.
Linux must determine the real
source clock
On Thu, Jul 31, 2008 at 09:54:48PM +0200, Wolfgang Grandegger wrote:
Thinking more about it, it would be best to add the property
i2c-clock-divider to the soc node and implement fsl_get_i2c_freq() in
a similar way:
[EMAIL PROTECTED] {
#address-cells = 1;
Wolfgang Grandegger wrote:
But clock-frequency, aka bus-frequency, is already used by
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.26/arch/powerpc/sysdev/fsl_soc.c#L80
So? clock-frequency is a per-node property. I use it in the codec node on the
8610 (mpc8610_hpcd.dts). It does
Timur Tabi wrote:
Wolfgang Grandegger wrote:
But clock-frequency, aka bus-frequency, is already used by
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.26/arch/powerpc/sysdev/fsl_soc.c#L80
So? clock-frequency is a per-node property. I use it in the codec node on the
8610
Grant Likely wrote:
On Thu, Jul 31, 2008 at 09:54:48PM +0200, Wolfgang Grandegger wrote:
Thinking more about it, it would be best to add the property
i2c-clock-divider to the soc node and implement fsl_get_i2c_freq() in
a similar way:
[EMAIL PROTECTED] {
Timur Tabi wrote:
Wolfgang Grandegger wrote:
I'm a bit confused. The frequency of the I2C source clock and the real
I2C clock frequency are two different things.
There are two frequencies:
1) The frequency of the input clock to the I2C device, after it has gone through
a divider. This is
Wolfgang Grandegger wrote:
I'm a bit confused. The frequency of the I2C source clock and the real
I2C clock frequency are two different things.
There are two frequencies:
1) The frequency of the input clock to the I2C device, after it has gone through
a divider. This is what I call the I2C
Wolfgang Grandegger wrote:
Is it not exactly that? For me it's not a per I2C device property, at least.
Of course it's a per-I2C device property. The input frequency to the I2C device
is only seen by the I2C device, and no other device.
--
Timur Tabi
Linux kernel developer at Freescale
On Thu, Jul 31, 2008 at 2:19 PM, Timur Tabi [EMAIL PROTECTED] wrote:
Wolfgang Grandegger wrote:
I'm a bit confused. The frequency of the I2C source clock and the real
I2C clock frequency are two different things.
There are two frequencies:
1) The frequency of the input clock to the I2C
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Timur Tabi wrote:
Wolfgang Grandegger wrote:
But clock-frequency, aka bus-frequency, is already used by
fsl_get_sys_freq():
http://lxr.linux.no/linux+v2.6.26/arch/powerpc/sysdev/fsl_soc.c#L80
So? clock-frequency is
On Thu, Jul 31, 2008 at 2:32 PM, Jon Smirl [EMAIL PROTECTED] wrote:
On 7/31/08, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Timur Tabi wrote:
Wolfgang Grandegger wrote:
But clock-frequency, aka bus-frequency, is already used by
fsl_get_sys_freq():
Wolfgang Grandegger wrote:
2) The speed of the I2C bus, as seen by devices on that bus. This is usually
400KHz.
Which should be defined with the property current-speed, right?
I would use something like bus-speed, but yes. The word current shouldn't
be in a property string.
--
Timur
Jon Smirl wrote:
For mpc5200 it is easy, mpc52xx_find_ipb_freq() already exists to get
the source clock for the i2c devices. Each i2c node in the device tree
can then specify clock-frequency = 40; or let it default. You
400KHz is the *speed* of the I2C bus, so let's be sure to use speed
On 7/31/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
For mpc5200 it is easy, mpc52xx_find_ipb_freq() already exists to get
the source clock for the i2c devices. Each i2c node in the device tree
can then specify clock-frequency = 40; or let it default. You
400KHz is
Grant Likely wrote:
How is the divider controlled? Is it a fixed property of the SoC?
Yes. The divider is either 1, 2, or 3, and the only way to know which one it is
is to look up the specific SOC model number. And depending on the SOC model,
there may also be a register that needs to be
On Thu, Jul 31, 2008 at 03:37:07PM -0500, Timur Tabi wrote:
Grant Likely wrote:
How is the divider controlled? Is it a fixed property of the SoC?
Yes. The divider is either 1, 2, or 3, and the only way to know which one
it is is to look up the specific SOC model number. And depending
Jon Smirl wrote:
It wouldn't go into the i2c driver, it would go into the mpc8xxx
platform driver. Why is it bad to put it into the mpc8xxx platform
driver? It is an accurate description of the mpc8xxx platform isn't
it?
There's no need to put that code in the platform driver because U-Boot
On 7/31/08, Grant Likely [EMAIL PROTECTED] wrote:
On Thu, Jul 31, 2008 at 03:37:07PM -0500, Timur Tabi wrote:
Grant Likely wrote:
How is the divider controlled? Is it a fixed property of the SoC?
Yes. The divider is either 1, 2, or 3, and the only way to know which one
it is
Jon Smirl wrote:
Isn't there a single global divider that generates all the i2c source
clocks? You don't want to copy a global value into each i2c node.
Why not? The compatible is pretty much always going to be the same
for the i2c node, but we copy that, as well.
Likewise for the
Jon Smirl wrote:
Isn't there a single global divider that generates all the i2c source
clocks? You don't want to copy a global value into each i2c node.
Why not? There are only two I2C devices, and it's theoretically possible for
them to have different input clock frequencies. Keeping it in
Jon Smirl wrote:
On 7/31/08, Timur Tabi [EMAIL PROTECTED] wrote:
Jon Smirl wrote:
Isn't there a single global divider that generates all the i2c source
clocks? You don't want to copy a global value into each i2c node.
Why not? There are only two I2C devices, and it's theoretically
Jon Smirl wrote:
But that's the same as saying we should copy the system clock
frequency into all of the PSC nodes because we might implement
hardware where they aren't all clocked off from the same input clock
source.
The I2C clock is only visible to the I2C devices. The system clock is
Wolfgang Grandegger wrote:
U-Boot does not (yet) use the FDT and it has therefore to use that ugly
code to derive the I2C input clock frequency. I think its completely
legal to put that hardware specific information into the FDT and get rid
of such code.
Huh? U-Boot initializes several
On Thu, 31 Jul 2008, Timur Tabi wrote:
Jon Smirl wrote:
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.
Actually, the tables in the manuals are just an
On Thu, 31 Jul 2008, Jon Smirl wrote:
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
right clock value into the variable. For mpc8 get it from uboot.
mpc5200 can easily compute it from ppc_proc_freq and
On Thu, 31 Jul 2008, Grant Likely wrote:
On Thu, Jul 31, 2008 at 09:54:48PM +0200, Wolfgang Grandegger wrote:
Thinking more about it, it would be best to add the property
i2c-clock-divider to the soc node and implement fsl_get_i2c_freq() in
a similar way:
[EMAIL PROTECTED] {
On Thu, 31 Jul 2008, Grant Likely wrote:
I'm a bit confused. The frequency of the I2C source clock and the real I2C
clock frequency are two different things. The first one is common for all
I2C devices, the second can be different. What properties would you like to
use for defining both?
On Thu, 31 Jul 2008, Timur Tabi wrote:
Wolfgang Grandegger wrote:
U-Boot does not (yet) use the FDT and it has therefore to use that ugly
code to derive the I2C input clock frequency. I think its completely
legal to put that hardware specific information into the FDT and get rid
of such
On 7/31/08, Trent Piepho [EMAIL PROTECTED] wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
right clock value into the variable. For mpc8 get it from uboot.
On Thu, 31 Jul 2008, Jon Smirl wrote:
Here's my idea:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
bus-frequency = 10;
/* Either */
source-clock-frequency = 0;
/* OR */
On 7/31/08, Trent Piepho [EMAIL PROTECTED] wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
Here's my idea:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
bus-frequency = 10;
/* Either */
On Thu, Jul 31, 2008 at 09:19:51PM -0400, Jon Smirl wrote:
On 7/31/08, Trent Piepho [EMAIL PROTECTED] wrote:
On Thu, 31 Jul 2008, Jon Smirl wrote:
As for the source clock, how about creating a new global like
ppc_proc_freq called ppc_ipb_freq. The platform code can then set the
On 7/31/08, Grant Likely [EMAIL PROTECTED] wrote:
Your mixing up device tree layout with implementation details. Device
tree layout must come first. mpc52xx_find_ipb_freq() is just a
convenience function that walks up the device tree looking for a
bus-frequency property.
So, instead of
On Fri, Jul 25, 2008 at 05:34:49PM +0200, Wolfgang Grandegger wrote:
Grant Likely wrote:
On Fri, Jul 25, 2008 at 5:04 AM, Wolfgang Grandegger [EMAIL PROTECTED]
wrote:
I was also thinking to just overtake the U-Boot settings if fdt and dfsrr is
not defined for the I2C node (instead of the
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
The I2C driver for the MPC currently uses a fixed speed hard-coded into
the driver. This patch adds the FDT properties fdr and dfsrr for the
corresponding I2C registers to make the speed configurable via FDT,
e.g.:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
reg = 0x3100 0x100;
Hi Wolfgang,
The I2C driver for the MPC currently uses a fixed speed hard-coded into
the driver. This patch adds the FDT properties fdr and dfsrr for the
corresponding I2C registers to make the speed configurable via FDT,
e.g.:
[EMAIL PROTECTED] {
compatible = fsl-i2c;
Jochen Friedrich wrote:
Hi Wolfgang,
The I2C driver for the MPC currently uses a fixed speed hard-coded into
the driver. This patch adds the FDT properties fdr and dfsrr for the
corresponding I2C registers to make the speed configurable via FDT,
e.g.:
[EMAIL PROTECTED] {
On Fri, Jul 25, 2008 at 5:04 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jochen Friedrich wrote:
Hi Wolfgang,
The I2C driver for the MPC currently uses a fixed speed hard-coded into
the driver. This patch adds the FDT properties fdr and dfsrr for the
corresponding I2C registers to make
On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely [EMAIL PROTECTED] wrote:
Yes, please use something like clock-frequency or current-speed and do
the calculation.
Ditto. I already wrote the code that does that for U-Boot, so all you
need to do is port it.
Although I'm curious, if U-Boot already
On 7/25/08, Timur Tabi [EMAIL PROTECTED] wrote:
On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely [EMAIL PROTECTED] wrote:
Yes, please use something like clock-frequency or current-speed and do
the calculation.
Ditto. I already wrote the code that does that for U-Boot, so all you
need to
Timur Tabi wrote:
On Fri, Jul 25, 2008 at 8:12 AM, Grant Likely [EMAIL PROTECTED] wrote:
Yes, please use something like clock-frequency or current-speed and do
the calculation.
Ditto. I already wrote the code that does that for U-Boot, so all you
need to do is port it.
I know but we still
Grant Likely wrote:
On Fri, Jul 25, 2008 at 5:04 AM, Wolfgang Grandegger [EMAIL PROTECTED] wrote:
Jochen Friedrich wrote:
Hi Wolfgang,
The I2C driver for the MPC currently uses a fixed speed hard-coded into
the driver. This patch adds the FDT properties fdr and dfsrr for the
corresponding
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.
--
Timur Tabi
Linux kernel developer at Freescale
86 matches
Mail list logo
