On Mon, 4 Aug 2008 14:49:16 +1000
Paul Mackerras [EMAIL PROTECTED] wrote:
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
The main thing there is that we have moved the powerpc include files
from include/asm-powerpc
The function htab_bolt_mapping() is used to create permanent
mappings in the MMU hash table, for example, in order to create
the linear mapping of vmemmap. It's also used by early boot
ioremap (before mem_init_done).
However, the way ioremap uses it is incorrect as it passes it
the protection
False alarm. They hardcoded the arch into the include. So
#include asm-powerpc/time.h
no longer works but
#include asm/time.h
does. This is an artifact from when we where trying to use arch/ppc.
Cheers,
Sean
___
Linuxppc-dev mailing list
On Tue, 2008-08-05 at 16:47 +1200, Paul Collins wrote:
It's about four years old. It was in storage for about six months and I
got it repaired a few weeks ago (display cable and inverter). The sort
of crazy crap I've been reporting certainly smacks of memory corruption.
But on the other
Hi Ben,
Just a trivial note ..
On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
+++ linux-work/arch/powerpc/mm/hash_utils_64.c2008-08-05
16:09:47.0 +1000
@@ -18,7 +18,7 @@
* 2 of the License, or (at your option) any later version.
*/
On Tue, 2008-08-05 at 17:28 +1000, Stephen Rothwell wrote:
Hi Ben,
Just a trivial note ..
On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
+++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05
16:09:47.0 +1000
@@ -18,7 +18,7 @@
On Tue, 5 Aug 2008, Benjamin Herrenschmidt wrote:
Can you find out where that stupid value comes from ?
I didn't have time to look at in detail, but it fails from the
ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c):
htab = (__force struct hash_pte
Michael Ellerman [EMAIL PROTECTED] writes:
I see you have FTRACE enabled. That's new and could potentially bugger
things up without the compiler knowing, so can you turn that off.
With FTRACE disabled, doing cross-builds from the 2.6.26 amd64 client, a
setup that normally triggers the problem
arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
Ah, I missed that one. Indeed it -is- used.
Ok, that leaves us with 2 options:
- Change ps3_hpte_updatepp() to not read from the hash table via that
mapping (ie, do you have an LV1 call to read an HPTE ? Do you
On Tue, 05 Aug 2008 11:05:03 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
- Remove the populating of the tree from the revmap function as
you already do
- Move it to irq_create_mapping() for the normal case
- For pre-existing interrupt, have the generic code that
On Mon, 04 Aug 2008 09:31:36 -0700 Daniel Walker [EMAIL PROTECTED] wrote:
On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -119,6 +119,7 @@ struct irq_host {
} linear;
struct
Hi Benjamin,
On Tue, 05 Aug 2008 11:03:46 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Mon, 2008-08-04 at 13:08 +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)
You could do that by adding:
if (!(pteflags (_PAGE_USER | _PAGE_RW)))
rflags |= (1 1) | (1 63);
Dbl check that the resulting mapping isn't accessible to user space though.
Make these 1UL x, and a proper patch would have to also test
that the CPU supports the 3rd
On (04/08/08 14:10), Dave Hansen didst pronounce:
On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
We are a lot more reliable than we were although exact quantification is
difficult because it's workload dependent. For a long time, I've been able
to test bits and pieces with hugepages
LD vmlinux.o
mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
(.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here
mm/built-in.o: In function `arch_get_unmapped_area_topdown':
(.opd+0x2730):
On Tue, 2008-08-05 at 21:43 +1200, Paul Collins wrote:
Michael Ellerman [EMAIL PROTECTED] writes:
I see you have FTRACE enabled. That's new and could potentially bugger
things up without the compiler knowing, so can you turn that off.
With FTRACE disabled, doing cross-builds from the
On Tue, 05 Aug 2008 13:39:49 +0200 Johannes Berg [EMAIL PROTECTED] wrote:
LD vmlinux.o
mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
(.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here
I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600)
system. If I remove the 'simple-bus' compatible from the soc node in
the .dts it works. Otherwise it hangs at but and looks to be crashed
in the serial driver due to accessing memory at 0.
I've tried the same .dts
In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the
Recent of_platform changes made of_bus_type_init() overwrite the bus type's
.dev_attrs list, so move ibmebus' name attribute (which is needed by eHCA
userspace support) into generic OF device code. Tested on POWER.
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
arch/powerpc/kernel/ibmebus.c
Almost all of the includes in include/asm-powerpc where moved to
arch/powerpc/include/asm. This is breaking almost all of my user mode
code... so I assume I am doing something very wrong.
Here is a simple program that flushes stdout for no apparent reason ;)
#include stdio.h
#include sys/ioctl.h
On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
To get that right between children, you end up something very fs-like
when the child needs to fault in a page that is already populated by the
parent. I strongly
On Aug 5, 2008, at 11:09 AM, Sean MacLennan wrote:
Almost all of the includes in include/asm-powerpc where moved to
arch/powerpc/include/asm. This is breaking almost all of my user mode
code... so I assume I am doing something very wrong.
Here is a simple program that flushes stdout for no
On (05/08/08 09:12), Dave Hansen didst pronounce:
On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
To get that right between children, you end up something very fs-like
when the child needs to fault in a page that
So when we receive a spurious irq, EOI it, and then mask it.
What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls? Should you instead first mask
it, and only then EOI it? Or doesn't that work on XICS?
Segher
On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
we get things like proper reservations which we can do for MAP_PRIVATE these
days. Again, we
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no
Chris Friesen wrote:
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here!
So get_immrbase can function without a device_type = soc
property in the soc node.
The soc node should really be named immr
because it does not include the entire soc, however
u-boot currently looks up this node by name for
a clock fixup so leave it soc for now. We will change
it later after
This will allow the eventual removal of device_type = soc
properties in soc nodes.
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_soc.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c
Now that get_immrbase knows about immr aliases.
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8313erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc8315erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_rdb.dts
Now that get_immrbase knows about immr aliases.
Some chip docs call this ccsr for 8[56]xx platforms
but we stick with immr for consistency across 8xxx.
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/ksi8560.dts |3 ++-
arch/powerpc/boot/dts/mpc8536ds.dts
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = soc
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted to use a reg
property of some actual device instead of making
Arnd Bergmann wrote:
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = soc
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted to use a reg
property of some actual device
On Aug 5, 2008, at 3:49 PM, Scott Wood wrote:
Arnd Bergmann wrote:
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = soc
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted
On Tue, Aug 5, 2008 at 2:13 PM, John Rigby [EMAIL PROTECTED] wrote:
So get_immrbase can function without a device_type = soc
property in the soc node.
The soc node should really be named immr
because it does not include the entire soc, however
u-boot currently looks up this node by name for
Oops, forgot to add devicetree-discuss to the cc: list
g.
On Tue, Aug 5, 2008 at 3:05 PM, Grant Likely [EMAIL PROTECTED] wrote:
On Tue, Aug 5, 2008 at 2:13 PM, John Rigby [EMAIL PROTECTED] wrote:
So get_immrbase can function without a device_type = soc
property in the soc node.
The soc node
On Tue, Aug 5, 2008 at 2:49 PM, Scott Wood [EMAIL PROTECTED] wrote:
Arnd Bergmann wrote:
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = soc
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all
Grant Likely wrote:
Is it not sufficient to search the tree for a node with the
chip-immr compatible value? I don't think this is the intended use
case of aliases.
That get's really annoying in code that is meant to deal with multiple
chips. I don't think finding the network or serial node
On Tue, Aug 5, 2008 at 3:08 PM, Scott Wood [EMAIL PROTECTED] wrote:
Grant Likely wrote:
Is it not sufficient to search the tree for a node with the
chip-immr compatible value? I don't think this is the intended use
case of aliases.
That get's really annoying in code that is meant to deal
Uncle!
U-boot:
The 5121 currently fixes up the soc's bus-frequency node with a hard
coded path.
I'll leave it that way.
Kernel:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304
Grant Likely wrote:
But finding nodes that meet a criteria *is* what compatible is for and
there is precedence for it. All u-boot platforms are finding the node
by path right now, and so all of them need to be changed. Changing
them to find by compatible that is set per-board or per-SoC makes
John Rigby wrote:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304 to it to pass to setup_indirect_pci as the
cfg_addr, and cfg_data addresses.
I'm more than willing to change
I'm trying to debug some Kconfig problems and am looking for a way to
get more debug output.
I have used KBUILD_VERBOSE=1 on the command line and it didn't help
much.
I'm seeing an issue with creating a new defconfig file for a board. I
get the .config created, then copy it to a
Scott Wood wrote:
John Rigby wrote:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304 to it to pass to setup_indirect_pci as the
cfg_addr, and cfg_data addresses.
I'm more than
On Tue, 2008-08-05 at 15:37 -0600, John Linn wrote:
I’m trying to debug some Kconfig problems and am looking for a way to
get more debug output.
I have used KBUILD_VERBOSE=1 on the command line and it didn’t help
much.
I’m seeing an issue with creating a new defconfig file for a
Thanks Josh, I just came to the conclusion it was busted somehow in the
mainline after repeating it there.
-- John
-Original Message-
From: Josh Boyer [mailto:[EMAIL PROTECTED] On Behalf Of Josh Boyer
Sent: Tuesday, August 05, 2008 4:49 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
On Tue, 2008-08-05 at 12:26 -0700, Kevin Diggs wrote:
Chris Friesen wrote:
Kevin Diggs wrote:
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone mucking with our
The FSL MSI code keeps a pointer to the of_node from the device
it represents. However it also has an irq_host, which contains
a pointer to the of_node, so use that one instead.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_msi.c | 12 +---
There are now two almost identical implementations of an MSI bitmap
allocator, one in mpic_msi.c and the other in fsl_msi.c.
Merge them together and put the result in msi_bitmap.c. Some of the
MPIC bits will remain to provide a nicer interface for the MPIC users.
In the process we fix two
This is 90% straight forward, although we have to change a few
printk format strings as well because of the change in type of hwirq.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/sysdev/fsl_msi.c | 103 ++---
arch/powerpc/sysdev/fsl_msi.h
This effects the U3 MSI code as well as the PASEMI MSI code. We keep
some of the MPIC routines as helpers, and also the U3 best-guess
reservation logic. The rest is replaced by the generic code.
And a few printk format changes due to hwirq type change.
Signed-off-by: Michael Ellerman [EMAIL
Benjamin Herrenschmidt wrote:
arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
Ok, that leaves us with 2 options:
- Change ps3_hpte_updatepp() to not read from the hash table via that
mapping (ie, do you have an LV1 call to read an HPTE ? Do you measure
any
On Tue, Aug 05, 2008 at 04:19:44PM -0500, Scott Wood wrote:
Grant Likely wrote:
But finding nodes that meet a criteria *is* what compatible is for and
there is precedence for it. All u-boot platforms are finding the node
by path right now, and so all of them need to be changed. Changing
Hi,
If I have:
inline unsigned int get_PLL_range(unsigned int range, unsigned int
config)
{
unsigned int ret;
/*
* Turn r3 (range) into a rotate count for the selected range.
* 0 - 23, 1 - 31
*/
__asm__ __volatile__ ( slwi %0,%0,3\n
On Tue, 2008-08-05 at 17:20 -0700, Kevin Diggs wrote:
Hi,
thats bad right? Because the addi 0, 0, 23 will not work as expected
because of the special property of r0. FYI: The first three lines
after the #APP are from a similar function get_PLL_ratio().
Is there a way to
Hi Kevin,
/*
* Turn r3 (range) into a rotate count for the selected
range. * 0 - 23, 1 - 31
*/
__asm__ __volatile__ ( slwi %0,%0,3\n
addi %0,%0,23\n
rlwnm %0,%1,%0,30,31\n:
On Tue, 2008-08-05 at 18:48 +0200, Segher Boessenkool wrote:
So when we receive a spurious irq, EOI it, and then mask it.
What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls? Should you instead first mask
it, and only then EOI it? Or doesn't
Michael Ellerman wrote:
On Tue, 2008-08-05 at 12:26 -0700, Kevin Diggs wrote:
Chris Friesen wrote:
Kevin Diggs wrote:
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,cf750gxvStateBits)) {
/*
* Someone
In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the
Jeremy Kerr wrote:
Hi Kevin,
/*
* Turn r3 (range) into a rotate count for the selected
range. * 0 - 23, 1 - 31
*/
__asm__ __volatile__ ( slwi %0,%0,3\n
addi %0,%0,23\n
rlwnm %0,%1,%0,30,31\n:
- Original Message Follows -
From: Michael Ellerman [EMAIL PROTECTED]
To: Paul Mackerras [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org, Milton Miller
[EMAIL PROTECTED], Segher Boessenkool
[EMAIL PROTECTED]
Subject: [PATCH] powerpc: EOI spurious irqs during boot so
they can be reenabled
Hi John,
[From further in the discussion, this may no longer be relevant ...]
On Tue, 5 Aug 2008 14:13:37 -0600 John Rigby [EMAIL PROTECTED] wrote:
- soc = of_find_node_by_type(NULL, soc);
+ /*
+ * First look for an immr alias
+ */
+ np = of_find_node_by_name(NULL,
As well as fdt_subnode_offset(), libfdt includes an
fdt_subnode_offset_namelen() function that takes the subnode name to
look up not as a NUL-terminated string, but as a string with an
explicit length. This can be useful when the caller has the name as
part of a longer string, such as a full
On Tue, 2008-08-05 at 20:55 -0600, miltonm wrote:
- Original Message Follows -
From: Michael Ellerman [EMAIL PROTECTED]
To: Paul Mackerras [EMAIL PROTECTED]
Cc: linuxppc-dev@ozlabs.org, Milton Miller
[EMAIL PROTECTED], Segher Boessenkool
[EMAIL PROTECTED]
Subject: [PATCH] powerpc:
This changes the way we make the boot wrapper position-independent.
Before we just added the offset (the difference between runtime
address and link address) to each entry in the .got2 section. That
doesn't relocate pointer values in initialized variables and arrays.
Instead we now link the
66 matches
Mail list logo
