On Fri, Aug 01, 2008 at 12:37:25AM -0400, Jon Smirl wrote:
> On 8/1/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrot
On Fri, 1 Aug 2008 15:29:36 +1000 Tony Breeds <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> > Hi Andrew,
> >
> > make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with build
> > error
>
>
>
> Turning off GCOV "fixes" this. Not re
On Thu, Jul 31, 2008 at 06:13:28PM +0530, Kamalesh Babulal wrote:
> Hi Andrew,
>
> make allyesconfig with 2.6.27-rc1-mm1 kernel on powerpc fails with build error
Turning off GCOV "fixes" this. Not really the best solution but at
least it narrows doen the search effort.
Peter,
Can you
On 8/1/08, David Gibson <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> > > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
>
About this whole generic board mumbo-jumbo: not happening. It's a pipe
dream, it doesn't work, and it leads to the sort of mess we have in chrp
where we end up having hacks to identify what exact sort of chrp we have
and do things differently etc...
NOT HAPPENING.
Now, there are two approaches he
On Fri, 1 Aug 2008 08:51:23 +0900 FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
>
> Ingo has a patch to fix this problem in the x86 tree:
>
> http://marc.info/?l=linux-kernel&m=121754062325903&w=2
Then consider this a poke (to the appropriate person) to get something
merged to fix the breakage.
--
On Fri, Aug 01, 2008 at 12:00:01AM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> > > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
[snip]
> > > That is what I'm doing now. But it requires every
On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> > On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> > > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
>
On Thu, Jul 31, 2008 at 09:25:33PM -0600, Grant Likely wrote:
> On Fri, Aug 01, 2008 at 12:54:39PM +1000, David Gibson wrote:
> > On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
[snip]
> > > - Add a property to the device tree that explicitly specifies the SoC
> > > that the board is
On Thu, Jul 31, 2008 at 11:06:20PM -0400, Jon Smirl wrote:
> On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wro
On Fri, Aug 01, 2008 at 12:54:39PM +1000, David Gibson wrote:
> On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> > This topic keeps coming up, so it is probably time to address it once
> > and for all.
> >
> > When it comes to machine level support in arch/powerpc, there seems to
>
On Thu, Jul 31, 2008 at 05:28:09PM -0500, Kumar Gala wrote:
>
> On Jul 31, 2008, at 5:18 PM, Jon Loeliger wrote:
>
>> Kumar Gala wrote:
>>> When we coverted the .dts to v1 we lost a space between the irq
>>> and its polarity/sense information. This causes a bit of chaos
>>> as the reset of the blo
On 7/31/08, David Gibson <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> > > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
>
On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> This topic keeps coming up, so it is probably time to address it once
> and for all.
>
> When it comes to machine level support in arch/powerpc, there seems to
> me that there are two levels or machine support.
>
> Level 1 is the boa
On Thu, Jul 31, 2008 at 04:58:34PM -0400, Jon Smirl wrote:
> On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> > > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > > This topic keeps coming up, so it is probably time to a
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, Jul 31, 2008 at 01:54:13AM -0500, Milton Miller wrote:
> But please, cast the result of the shift. Otherwise it will print 0MB
> instead of 4096MB.
Done, patch (v3) on the way. One day I'll get better at this "trivial"
stuff.
Yours Tony
linux.conf.auhttp://www.marchsouth.org/
total_memory is a 'phys_addr_t', Which can be either 64 or 32 bits.
Force printing as unsigned long long to silence the warning.
Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
---
Changes since v1:
- correctly use 64bit type as phys_addr_t wont always be 32bits. Thanks to
sfr for showing me t
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, Jul 31, 2008 at 01:48:31PM -0500, Kumar Gala wrote:
> Implement _PAGE_SPECIAL and pte_special() for 32-bit powerpc. This bit will
> be used by the fast get_user_pages() to differenciate PTEs that correspond
> to a valid struct page from special mappings that don't such as IO mappings
> obta
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 Fri, 1 Aug 2008 09:43:23 +1000
Stephen Rothwell <[EMAIL PROTECTED]> wrote:
> This reverts commit 29111f579f4f3f2a07385f931854ab0527ae7ea5.
>
> This undoes the hasty addition of a global version of iommu_num_pages()
> that broke both the powerpc and sparc builds. This function can be
> revisit
This reverts commit 29111f579f4f3f2a07385f931854ab0527ae7ea5.
This undoes the hasty addition of a global version of iommu_num_pages()
that broke both the powerpc and sparc builds. This function can be
revisited later.
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
arch/x86/kernel/amd_i
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
Kumar Gala wrote:
np. It would be nice to see dtc warn about it, but that would probably
be a bit difficult.
One thing that macros may bring besides clarity and elimination of
redundancy is the ability to put some semantic checks in the macro
itself (rather than hardcoding it into dtc). At
On Jul 31, 2008, at 5:18 PM, Jon Loeliger wrote:
Kumar Gala wrote:
When we coverted the .dts to v1 we lost a space between the irq
and its polarity/sense information. This causes a bit of chaos
as the reset of the blob is off by one cell.
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts b
Kumar Gala wrote:
When we coverted the .dts to v1 we lost a space between the irq
and its polarity/sense information. This causes a bit of chaos
as the reset of the blob is off by one cell.
diff --git a/arch/powerpc/boot/dts/mpc8641_hpcn.dts
b/arch/powerpc/boot/dts/mpc8641_hpcn.dts
index ae08
When we coverted the .dts to v1 we lost a space between the irq
and its polarity/sense information. This causes a bit of chaos
as the reset of the blob is off by one cell.
This was noticed by booting and getting errors w/ATA due to
lock of interrupts.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]
I figured out the issue. Its related to the interrupt routing being
conveyed to the code from the device tree. We have a missing 'space'
causing issues.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/
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
On Thu, Jul 31, 2008 at 03:59:06PM -0500, Scott Wood wrote:
> On Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> > - Add a property to the device tree that explicitly specifies the SoC
> > that the board is based on. Something like 'soc-model =
> > "fsl,mpc5200b"' would be appropriate
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 Thu, Jul 31, 2008 at 01:53:45PM -0500, Kumar Gala wrote:
> I'm getting the following badness with top of tree on a embedded PowerPC
> w/a ULI 1575 bridge (M5229 IDE):
>
> 02:1f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c8)
Just to be sure that I didn't break the ULi for your
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 Thu, Jul 31, 2008 at 02:19:57PM -0600, Grant Likely wrote:
> - Add a property to the device tree that explicitly specifies the SoC
> that the board is based on. Something like 'soc-model =
> "fsl,mpc5200b"' would be appropriate.
Shouldn't that go in the compatible property of the soc node?
>
On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> > On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > > This topic keeps coming up, so it is probably time to address it once
> > > and for all.
> > >
> > > When it comes to
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
On Thu, Jul 31, 2008 at 04:49:49PM -0400, Jon Smirl wrote:
> On 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> > This topic keeps coming up, so it is probably time to address it once
> > and for all.
> >
> > When it comes to machine level support in arch/powerpc, there seems to
> > me that t
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 7/31/08, Grant Likely <[EMAIL PROTECTED]> wrote:
> This topic keeps coming up, so it is probably time to address it once
> and for all.
>
> When it comes to machine level support in arch/powerpc, there seems to
> me that there are two levels or machine support.
>
..
>
> Thoughts?
> g.
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
Grant Likely wrote:
Doing so should simplify adding new board ports. In many cases it
would just involve dropping in a new .dts file. However, it retains
the flexability of overriding generic code with platform specific
fixups as the need arises.
If it makes it easier for board vendors to do
On Thu, Jul 31, 2008 at 03:24:31PM -0500, Kumar Gala wrote:
> >it would be helpful to compile a kernel with verbose fault information
> >turned on.
>
> Doesn't seem to provide too much more info on ppc.
I'm pretty sure it does the same thing on ppc as on all the other
architectures.
> just says
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
On Jul 31, 2008, at 2:02 PM, Ben Dooks wrote:
On Thu, Jul 31, 2008 at 01:53:45PM -0500, Kumar Gala wrote:
I'm getting the following badness with top of tree on a embedded
PowerPC w/a ULI 1575 bridge (M5229 IDE):
02:1f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev
c8)
If you
This topic keeps coming up, so it is probably time to address it once
and for all.
When it comes to machine level support in arch/powerpc, there seems to
me that there are two levels or machine support.
Level 1 is the board specific stuff. Board X has a, b, and c things
that need to be done for
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
On Thu, Jul 31, 2008 at 01:53:45PM -0500, Kumar Gala wrote:
> I'm getting the following badness with top of tree on a embedded
> PowerPC w/a ULI 1575 bridge (M5229 IDE):
>
> 02:1f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c8)
>
> If you need more info let me know.
>
> - k
>
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 Jul 31, 2008, at 1:48 PM, Kumar Gala wrote:
Implement _PAGE_SPECIAL and pte_special() for 32-bit powerpc. This
bit will
be used by the fast get_user_pages() to differenciate PTEs that
correspond
to a valid struct page from special mappings that don't such as IO
mappings
obtained via io
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]
I'm getting the following badness with top of tree on a embedded
PowerPC w/a ULI 1575 bridge (M5229 IDE):
02:1f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c8)
If you need more info let me know.
- k
ahci :02:1f.1: AHCI 0001. 32 slots 4 ports 3 Gbps 0xf impl
SATA mo
Implement _PAGE_SPECIAL and pte_special() for 32-bit powerpc. This bit will
be used by the fast get_user_pages() to differenciate PTEs that correspond
to a valid struct page from special mappings that don't such as IO mappings
obtained via io_remap_pfn_ranges().
We currently only implement this on
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.
1 - 100 of 144 matches
Mail list logo
