On Thursday 31 July 2008 03:34, Andrew Morton wrote:
On Wed, 30 Jul 2008 18:23:18 +0100 Mel Gorman [EMAIL PROTECTED] wrote:
On (30/07/08 01:43), Andrew Morton didst pronounce:
On Mon, 28 Jul 2008 12:17:10 -0700 Eric Munson [EMAIL PROTECTED]
wrote:
Certain workloads benefit if their data
On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin [EMAIL PROTECTED] wrote:
Do we expect that this change will be replicated in other
memory-intensive apps? (I do).
Such as what? It would be nice to see some numbers with some HPC or java
or DBMS workload using this. Not that I dispute it
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 30 Jul 2008 23:18:04 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11185
Summary: Device/host RESET in SCSI
Product: Platform
On Thursday 31 July 2008 16:14, Andrew Morton wrote:
On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
Do we expect that this change will be replicated in other
memory-intensive apps? (I do).
Such as what? It would be nice to see some numbers with some HPC or
On Wed, 2008-07-30 at 23:24 -0700, Andrew Morton wrote:
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Wed, 30 Jul 2008 23:18:04 -0700 (PDT) [EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=11185
This patch fixes the /dev/oldmem interface for kdump on ppc64.
The patch originally came from Michael Ellerman hence have
retained the signed-off line. I just rediffed/tested against
latest git. Michael has ack'ed this patch.
Ben this is not a must for 2.6.27 but would be good if it's
included.
On Thu Jul 31 at 15:21:25 EST in 2008, Stephen Rothwell wrote:
On Thu, 31 Jul 2008 13:51:43 +1000 (EST) Tony Breeds tony at
bakeyournoodle.com wrote:
total_memory is a 'phys_addr_t', cast to unsigned long to silence
warning.
diff --git a/arch/powerpc/mm/ppc_mmu_32.c
Currently print_device_node_tree() isn't called but it can be usful for
debuging. Leave the function there but hide it behind '#if 0' to save
it being rewritten. If you want to call it you're already editing this
file anyway ;P
Signed-off-by: Tony Breeds [EMAIL PROTECTED]
---
Changes since v1:
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 the
On Thu, Jul 31, 2008 at 03:21:25PM +1000, Stephen Rothwell wrote:
Hi Tony,
Rusty has forever ruined 'Hi $name' ;P
snip
Will this ever be built with CONFIG_PHYS_64BIT?
Updated patch follows.
Yours Tony
linux.conf.auhttp://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux
On Thu, 2008-07-31 at 12:24 +0530, Sachin P. Sant wrote:
This patch fixes the /dev/oldmem interface for kdump on ppc64.
The patch originally came from Michael Ellerman hence have
retained the signed-off line. I just rediffed/tested against
latest git. Michael has ack'ed this patch.
Ben this
On Wed, Jul 30, 2008 at 11:24:09PM -0700, Andrew Morton wrote:
Why do you describe this regression as a powerpc problem rather than a
scsi one?
(It could be either or both, I'm just wondering...)
This seems quite astute of the reporter. The error messages from sym2
are consistent with an
On Thu, 2008-07-31 at 01:21 -0600, Matthew Wilcox wrote:
On Wed, Jul 30, 2008 at 11:24:09PM -0700, Andrew Morton wrote:
Why do you describe this regression as a powerpc problem rather than a
scsi one?
(It could be either or both, I'm just wondering...)
This seems quite astute of the
There seems to be some confusion between warm-plugging of IDE devices
and hot-plugging of IDE devices.
not a single piece of HW to exercise those code path ? I don't ask you
to get a powermac with a media-bay, but ide_cs seems to be a pretty
important one that's part of what the ide
On Thu, 2008-07-31 at 09:49 +0100, Alan Cox wrote:
There seems to be some confusion between warm-plugging of IDE devices
and hot-plugging of IDE devices.
not a single piece of HW to exercise those code path ? I don't ask you
to get a powermac with a media-bay, but ide_cs seems to be a
Michael Ellerman wrote:
Heh, do I get a prize for being neurotic? ;) .. Or just stupid, ahem.
I think you should also sign off on it Sachin, see clause (c) of the
developers cert (http://lwn.net/Articles/139918/)
Here is a signed-off from me. Let me know if i need to resubmit
the patch
I could make the media-bay look like a controller hotplug if it was
going to make things easier...
I'm not sure it will. It may do nowdays, but the older IDE code
historically was fairly broken for both cases except in 2.4. Also faking
it as controller hotplug is the wrong path for libata which
The radix tree used for fast irq reverse mapping by the XICS is initialized
late in the boot process, after the first interrupt (IPI) gets registered
and after the first IPI is received.
This patch moves the initialization of the XICS radix tree earlier into
the boot process in
irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
and insertion which happen in interrupt and process context respectively.
Separate the function into its 2 components, one for lookup only and one
for insertion only.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc:
Hi ,
here is a respin of the patches I posted last week for the RT kernel now
targeted
for mainline (http://lkml.org/lkml/2008/7/24/98). Thomas, steven, a note for you
at the end.
The goal of this patchset is to simplify the locking constraints on the radix
tree used for IRQ reverse
The radix trees used by interrupt controllers for their irq reverse mapping
(currently only the XICS found on pSeries) have a complex locking scheme
dating back to before the advent of the lockless radix tree.
Take advantage of this and of the fact that the items of the tree are
pointers to a
On Thu, 2008-07-31 at 10:13 +0100, Alan Cox wrote:
I could make the media-bay look like a controller hotplug if it was
going to make things easier...
I'm not sure it will. It may do nowdays, but the older IDE code
historically was fairly broken for both cases except in 2.4. Also faking
it
OK, I goofed up with git-format-patch, forgot the --numbered option.
The patches subjects should read:
[PATCH 1/3] powerpc - Initialize the irq radix tree earlier
[PATCH 2/3] powerpc - Separate the irq radix tree insertion and lookup
[PATCH 3/3] powerpc - Make the
On (30/07/08 13:07), Andrew Morton didst pronounce:
On Wed, 30 Jul 2008 20:30:10 +0100
Mel Gorman [EMAIL PROTECTED] wrote:
With Erics patch and libhugetlbfs, we can automatically back text/data[1],
malloc[2] and stacks without source modification. Fairly soon, libhugetlbfs
will also be
On Thursday 31 July 2008, Benjamin Herrenschmidt wrote:
Is it actually caused by additional reference counting on drive-gendev?
IOW if you reverse the patch below instead of applying the previous fix
do things work OK again?
Note that there shouldn't be anything fundamentally
On (31/07/08 16:26), Nick Piggin didst pronounce:
On Thursday 31 July 2008 16:14, Andrew Morton wrote:
On Thu, 31 Jul 2008 16:04:14 +1000 Nick Piggin [EMAIL PROTECTED]
wrote:
Do we expect that this change will be replicated in other
memory-intensive apps? (I do).
Such as what?
On Thu, 2008-07-31 at 11:40 +0200, Sebastien Dugue wrote:
The radix tree used for fast irq reverse mapping by the XICS is initialized
late in the boot process, after the first interrupt (IPI) gets registered
and after the first IPI is received.
This patch moves the initialization of the
On Thursday 31 July 2008 21:27, Mel Gorman wrote:
On (31/07/08 16:26), Nick Piggin didst pronounce:
I imagine it should be, unless you're using a CPU with seperate TLBs for
small and huge pages, and your large data set is mapped with huge pages,
in which case you might now introduce *new*
Hi Michael,
On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman [EMAIL PROTECTED] wrote:
On Thu, 2008-07-31 at 11:40 +0200, Sebastien Dugue wrote:
The radix tree used for fast irq reverse mapping by the XICS is initialized
late in the boot process, after the first interrupt (IPI) gets
On Thu, 31 Jul 2008 14:00:02 +0200 Sebastien Dugue [EMAIL PROTECTED] wrote:
Hi Michael,
On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman [EMAIL PROTECTED] wrote:
On Thu, 2008-07-31 at 11:40 +0200, Sebastien Dugue wrote:
The radix tree used for fast irq reverse mapping by the
On Thu, 2008-07-31 at 14:00 +0200, Sebastien Dugue wrote:
On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman [EMAIL PROTECTED] wrote:
This boot ordering stuff is pretty hairy, so I might have missed
something, but this is how the code is ordered AFAICT:
start_kernel()
The ePAPR 1.0 spec is officially published and available
on the power.org website.
http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf
One purpose of the spec is to more formally specify in one place the
flat device tree concept defined booting_without_of.txt plus the
On Thu, 2008-07-31 at 22:58 +1000, Michael Ellerman wrote:
On Thu, 2008-07-31 at 14:00 +0200, Sebastien Dugue wrote:
On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman [EMAIL PROTECTED]
wrote:
This boot ordering stuff is pretty hairy, so I might have missed
something, but this is
Hello All,
I'm using the latest 2.2.26 kernel image from
linux/kernel/git/benh/powerpc.git on a mpc8349mITX, and trying to get
Compact Flash to work. The kernel booted fine, but I was surprised to
see Compact Flash IRQ was not being handled. Does irq polling need to be
used for compact flash to
On Thu, 31 Jul 2008 23:01:39 +1000 Michael Ellerman [EMAIL PROTECTED] wrote:
On Thu, 2008-07-31 at 22:58 +1000, Michael Ellerman wrote:
On Thu, 2008-07-31 at 14:00 +0200, Sebastien Dugue wrote:
On Thu, 31 Jul 2008 21:40:56 +1000 Michael Ellerman [EMAIL PROTECTED]
wrote:
This
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 (31/07/08 21:51), Nick Piggin didst pronounce:
On Thursday 31 July 2008 21:27, Mel Gorman wrote:
On (31/07/08 16:26), Nick Piggin didst pronounce:
I imagine it should be, unless you're using a CPU with seperate TLBs for
small and huge pages, and your large data set is mapped with
On Thu, 31 Jul 2008 23:39:26 +1000 Michael Ellerman [EMAIL PROTECTED] wrote:
On Thu, 2008-07-31 at 15:26 +0200, Sebastien Dugue wrote:
On Thu, 31 Jul 2008 23:01:39 +1000 Michael Ellerman [EMAIL PROTECTED]
wrote:
On Thu, 2008-07-31 at 22:58 +1000, Michael Ellerman wrote:
On Thu,
From: Sparks, Sam
Sent: Thursday, July 31, 2008 8:15 AM
Does irq polling need to be used for compact flash to work
with this version of the kernel on this board?
When I remove the interrupt definition from the DTS (to cause
irqpolling), the ata driver gets stuck in a loop displaying the
On Thu, 2008-07-31 at 14:50 +0100, Mel Gorman wrote:
On (31/07/08 21:51), Nick Piggin didst pronounce:
On Thursday 31 July 2008 21:27, Mel Gorman wrote:
On (31/07/08 16:26), Nick Piggin didst pronounce:
I imagine it should be, unless you're using a CPU with seperate TLBs for
small
* Vivek Goyal [EMAIL PROTECTED] wrote:
o Move elfcorehdr_addr definition in arch dependent crash dump file. This is
equivalent to defining elfcorehdr_addr under CONFIG_CRASH_DUMP instead of
CONFIG_PROC_VMCORE. This is needed by is_kdump_kernel() which can be
used irrespective of the
In commit b6d80a20fc293f3b995c3ce1a6744a5574192125, we renamed all
libfdt functions to be prefixed with fdt_ or _fdt_ to minimise the
chance of collisions with things from whatever package libfdt is
embedded in, pulled into the libfdt build via that environment's
libfdt_env.h.
Except... I
dtc does not use the input() function in flex. Apparently on some gcc
versions the unused function will cause warnings. Therefore, this
patch removes the function by using the 'noinput' option to flex.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Applied.
jdl
The -S option allowed the specification of a minimum size for
the blob, however the main reason for caring about the size is
so there is enough padding to add a chosen node by u-boot or
whoever. In which case, folks don't really care about the absolute
size, but rather the size of the
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
From: Scott Wood [EMAIL PROTECTED]
This patch fixes the following build error with mpc866_ads_defconfig:
-- snip --
...
WRAParch/powerpc/boot/cuImage.mpc866ads
powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such
file or directory
make[2]: ***
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
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
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
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 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
ahci
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] {
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
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
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
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 the
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
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
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.
As part
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 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 there are two
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
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 machine level
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?
-
1 - 100 of 139 matches
Mail list logo
