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 _mov
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, 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 M
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 OpenFirmwar
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.
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
___
Linu
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
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
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 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
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
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.
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, b
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 stu
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 mpc8xxx
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, ins
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 th
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, 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:
> > 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 fro
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
> >
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 defi
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 PROT
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, 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 jus
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 severa
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
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 po
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 i
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 clock-f
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 possible fo
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
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-Bo
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 depe
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 lo
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
>
>
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 "s
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.
--
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():
>> > >
>> > >
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
> > >
> >
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
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
_
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 "I
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 w
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] {
#address-c
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 (mpc8610_hpcd.
Grant Likely wrote:
> Ugh. This is specifically related to the i2c device, so please place
> the property in the i2c device. Remember, device tree design is not
> about what will make the implementation simplest, but rather about what
> describes the hardware in the best way.
His proposal would
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
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>;
Timur Tabi wrote:
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 rea
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
Scott Wood wrote:
> Timur Tabi wrote:
>> True, but I'd rather we have a real clock-frequency property that contains
>> the
>> calculated I2C input frequency, than a divider. It's more consistent with
>> other
>> properties,
>
> Right, I wasn't saying i2c should be different from serial, pci, et
Timur Tabi wrote:
True, but I'd rather we have a real clock-frequency property that contains the
calculated I2C input frequency, than a divider. It's more consistent with other
properties,
Right, I wasn't saying i2c should be different from serial, pci, etc.
It was more of a side comment abou
Scott Wood wrote:
> 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
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>;
> >
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 as
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 s
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
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 al
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
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 compa
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 s
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]
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
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 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, ye
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'
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
> characteris
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
On Thu, Jul 31, 2008 at 12:54:02PM -0500, 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_fre
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 th
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",
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 = fsl_i2c_mp
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 k
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 c
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 depending on which
>> architectures are compiled in.
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;
> >charres
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:
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,
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 ha
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 machin
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 t
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 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 tru
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 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 agre
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 (instea
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
__
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
correspondi
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 stil
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
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 alrea
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
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] {
comp
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-
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 0
96 matches
Mail list logo
