Re: [git pull] Please pull powerpc.git merge branch
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 to arch/powerpc/include/asm. There is also a commit from Kumar Gala that removes code that was only referenced when compiling with ARCH=ppc, and is now dead since arch/ppc is gone, plus a couple of warning fixes from Tony Breeds. What is the correct way to include these files? I have a driver that needs to access get_tbl() which is defined in time.h. Do I put: #include arch/powerpc/include/asm/time.h in the source file? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
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 flags in the linux PTE form while htab_bolt_mapping()
expects them in the hash table format. This is made more confusing
by the fact that some of those flags are actually in the same
position in both cases.
This patch fixes it all by making htab_bolt_mapping() take normal
linux protection flags instead, and use a little helper to convert
them to htab flags. Callers can now use the usual PAGE_* definitions
safely.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
arch/powerpc/include/asm/mmu-hash64.h |2 -
arch/powerpc/mm/hash_utils_64.c | 65 --
arch/powerpc/mm/init_64.c |9 +---
3 files changed, 44 insertions(+), 32 deletions(-)
--- linux-work.orig/arch/powerpc/mm/hash_utils_64.c 2008-08-05
15:15:06.0 +1000
+++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05 16:09:47.0
+1000
@@ -18,7 +18,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#undef DEBUG
+#define DEBUG
#undef DEBUG_LOW
#include linux/spinlock.h
@@ -151,39 +151,53 @@ static struct mmu_psize_def mmu_psize_de
},
};
+static unsigned long htab_convert_pte_flags(unsigned long pteflags)
+{
+ unsigned long rflags = pteflags 0x1fa;
+
+ /* _PAGE_EXEC - NOEXEC */
+ if ((pteflags _PAGE_EXEC) == 0)
+ rflags |= HPTE_R_N;
+
+ /* PP bits. PAGE_USER is already PP bit 0x2, so we only
+* need to add in 0x1 if it's a read-only user page
+*/
+ if ((pteflags _PAGE_USER) !((pteflags _PAGE_RW)
+(pteflags _PAGE_DIRTY)))
+ rflags |= 1;
+
+ /* Always add C */
+ return rflags | HPTE_R_C;
+}
int htab_bolt_mapping(unsigned long vstart, unsigned long vend,
- unsigned long pstart, unsigned long mode,
+ unsigned long pstart, unsigned long prot,
int psize, int ssize)
{
unsigned long vaddr, paddr;
unsigned int step, shift;
- unsigned long tmp_mode;
int ret = 0;
shift = mmu_psize_defs[psize].shift;
step = 1 shift;
+ prot = htab_convert_pte_flags(prot);
+
+ DBG(htab_bolt_mapping(%lx..%lx - %lx (%lx,%d,%d)\n,
+ vstart, vend, pstart, prot, psize, ssize);
+
for (vaddr = vstart, paddr = pstart; vaddr vend;
vaddr += step, paddr += step) {
unsigned long hash, hpteg;
unsigned long vsid = get_kernel_vsid(vaddr, ssize);
unsigned long va = hpt_va(vaddr, vsid, ssize);
- tmp_mode = mode;
-
- /* Make non-kernel text non-executable */
- if (!in_kernel_text(vaddr))
- tmp_mode = mode | HPTE_R_N;
-
hash = hpt_hash(va, shift, ssize);
hpteg = ((hash htab_hash_mask) * HPTES_PER_GROUP);
- DBG(htab_bolt_mapping: calling %p\n, ppc_md.hpte_insert);
-
BUG_ON(!ppc_md.hpte_insert);
- ret = ppc_md.hpte_insert(hpteg, va, paddr,
- tmp_mode, HPTE_V_BOLTED, psize, ssize);
+ ret = ppc_md.hpte_insert(hpteg, va, paddr, prot,
+HPTE_V_BOLTED, psize, ssize);
if (ret 0)
break;
@@ -519,9 +533,9 @@ static unsigned long __init htab_get_tab
#ifdef CONFIG_MEMORY_HOTPLUG
void create_section_mapping(unsigned long start, unsigned long end)
{
- BUG_ON(htab_bolt_mapping(start, end, __pa(start),
- _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX,
- mmu_linear_psize, mmu_kernel_ssize));
+ BUG_ON(htab_bolt_mapping(start, end, __pa(start),
+PAGE_KERNEL, mmu_linear_psize,
+mmu_kernel_ssize));
}
int remove_section_mapping(unsigned long start, unsigned long end)
@@ -570,7 +584,7 @@ void __init htab_initialize(void)
{
unsigned long table;
unsigned long pteg_count;
- unsigned long mode_rw;
+ unsigned long prot, tprot;
unsigned long base = 0, size = 0, limit;
int i;
@@ -628,7 +642,7 @@ void __init htab_initialize(void)
mtspr(SPRN_SDR1, _SDR1);
}
- mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
+ prot = PAGE_KERNEL;
#ifdef CONFIG_DEBUG_PAGEALLOC
linear_map_hash_count = lmb_end_of_DRAM() PAGE_SHIFT;
@@ -646,8 +660,10 @@ void __init htab_initialize(void)
for (i=0; i lmb.memory.cnt; i++) {
base = (unsigned
Re: [git pull] Please pull powerpc.git merge branch
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 Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
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 hand, 2.6.25 (Debian's) and 2.6.26 (my own) have been trouble-free. Any chance you can bisect the problem ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
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. */ -#undef DEBUG +#define DEBUG You will turn this off again before it goes into Paulus' tree, right? :-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpXfBBZz8HnT.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Fix attribute confusion with htab_bolt_mapping()
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 @@ * 2 of the License, or (at your option) any later version. */ -#undef DEBUG +#define DEBUG You will turn this off again before it goes into Paulus' tree, right? :-) Ahah ! Good catch :-) Yup, I will. I forgot to add RFC in fact, as this is what that patch is at least for today. I need to run a few more tests tomorrow before paulus merges it. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
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 *)ioremap_flags(htab_addr, htab_size, pgprot_val(PAGE_READONLY_X)); IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is why I used pgprot_val(PAGE_READONLY_X) here. Why are you mapping it in the first place btw ? Do you actually use that mapping ? arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'. With kind regards, Geert Uytterhoeven Software Architect Sony Techsoft Centre Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ A division of Sony Europe (Belgium) N.V. VAT BE 0413.825.160 · RPR Brussels Fortis 293-0376800-10 GEBA-BE-BB___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
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 on the 2nd or 3rd build, I was able to do 10 complete builds. (make clean oldconfig vmlinux modules) So it looks like ftrace is the cause, or at least provokes some other usually-latent problem. I wasn't using it, so I'll just leave it off. And can you enable CONFIG_CODE_PATCHING_SELFTEST and CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed that /could/ (maybe) cause random blow ups. With those options enabled, I get this: Running code patching self-tests ... Running feature fixup self-tests ... -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
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 measure any significant performance loss using that instead ? updatepp shouldn't be something called -that- often). - Add a way to setup HPTEs using 3 PPP bits. I'm not going to implement that for the main hash code just yet though (the assembly) but it might be possible to implement it specifically for mappings bolted. That means it would only work when the mapping is done early but on PS3, we know that the hash table is always mapped early. The later would be a matter of taking my htab_convert_pte_flags() function and making it capable, when _PAGE_USER is _not_ set and _PAGE_RW is not set neither, to set PPP to 110. 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. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
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 initializes the radix tree walk through all interrupts and setup the revmap for them. If that needs locking vs. concurrent irq_create_mapping, it's easy to use one of the available spinlocks for that. And in fact, you may even be able to avoid GFP_ATOMIC completely here and switch it to GFP_KERNEL since irq_create_mapping() can sleep afaik, provided that you avoid the spinlocking. Well, maybe, will have to look into this in details. Thanks, Sebastien. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc - Make the irq reverse mapping radix tree lockless
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 radix_tree_root tree;
} revmap_data;
+ spinlock_t tree_lock;
You have a tabbing issue above..
Yuck, right.
Thanks,
Sebastien.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
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) 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 smp_xics_probe() (the mm is already up but no interrupts
have been registered at that point) to avoid having to insert a mapping into
the tree in interrupt context. This will help in simplifying the locking
constraints and move to a lockless radix tree in subsequent patches.
I'm not too happy with the moving of the radix tree init to platform
code.
The fact that the revmap code uses a radix tree should be mostly
transparent to the XICS code. I don't like adding this explicit code
from xics to initialize it.
OK, I'm fine with that.
I think the tree should still be initialized from generic code and it
can be done as late as we want as interrupts work without the tree being
there, they are just a bit slower.
I believe the right approach is:
- Remove the populating of the tree from the revmap function as
you already do
- Move it to irq_create_mapping() for the normal case
Agreed.
- For pre-existing interrupt, have the generic code that initializes
the radix tree walk through all interrupts and setup the revmap for
them. If that needs locking vs. concurrent irq_create_mapping, it's
easy to use one of the available spinlocks for that.
That's what I wanted to avoid to not add some new complexity, but I can
see that my approach makes some assumptions about initializations order
that I'm no longer comfortable with. Will do as you suggest as it's
way more explicit.
Thanks a lot for your comments.
Sebastien.
Cheers,
Ben.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/kernel/irq.c | 17 -
arch/powerpc/platforms/pseries/smp.c |1 +
arch/powerpc/platforms/pseries/xics.c |5 +
arch/powerpc/platforms/pseries/xics.h |1 +
4 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d972dec..9bef9f3 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1016,23 +1016,6 @@ void irq_early_init(void)
get_irq_desc(i)-status |= IRQ_NOREQUEST;
}
-/* We need to create the radix trees late */
-static int irq_late_init(void)
-{
- struct irq_host *h;
- unsigned long flags;
-
- irq_radix_wrlock(flags);
- list_for_each_entry(h, irq_hosts, link) {
- if (h-revmap_type == IRQ_HOST_MAP_TREE)
- INIT_RADIX_TREE(h-revmap_data.tree, GFP_ATOMIC);
- }
- irq_radix_wrunlock(flags);
-
- return 0;
-}
-arch_initcall(irq_late_init);
-
#ifdef CONFIG_VIRQ_DEBUG
static int virq_debug_show(struct seq_file *m, void *private)
{
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 9d8f8c8..3d4429a 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -130,6 +130,7 @@ static void smp_xics_message_pass(int target, int msg)
static int __init smp_xics_probe(void)
{
+ xics_radix_revmap_init();
xics_request_IPIs();
return cpus_weight(cpu_possible_map);
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..d6e28f9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -556,6 +556,11 @@ static struct irq_host_ops xics_host_ops = {
.xlate = xics_host_xlate,
};
+void __init xics_radix_revmap_init(void)
+{
+ INIT_RADIX_TREE(xics_host-revmap_data.tree, GFP_ATOMIC);
+}
+
static void __init xics_init_host(void)
{
if (firmware_has_feature(FW_FEATURE_LPAR))
diff --git a/arch/powerpc/platforms/pseries/xics.h
b/arch/powerpc/platforms/pseries/xics.h
index 1c5321a..11490be 100644
--- a/arch/powerpc/platforms/pseries/xics.h
+++ b/arch/powerpc/platforms/pseries/xics.h
@@ -19,6 +19,7 @@ extern void xics_setup_cpu(void);
extern void xics_teardown_cpu(void);
extern void xics_kexec_teardown_cpu(int secondary);
extern void xics_cause_IPI(int cpu);
+extern void xics_radix_revmap_init(void);
extern void xics_request_IPIs(void);
extern void xics_migrate_irqs_away(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
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 PP bit. We probably need to add a CPU feature bit for that. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 by allocating the pool at the time I needed it even after days of uptime. Previously this required a reboot. This is also a pretty big expansion of fs/hugetlb/ use outside of the filesystem itself. It is hacking the existing shared memory kernel-internal user to spit out effectively anonymous memory. Where do we draw the line where we stop using the filesystem for this? Other than the immediate code reuse, does it gain us anything? I have to think that actually refactoring the filesystem code and making it usable for really anonymous memory, then using *that* in these patches would be a lot more sane. Especially for someone that goes to look at it in a year. :) 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 suspect we end up back at hugetlbfs backing it :/ If you were going to do such a thing, you'd end up converting something like ramfs to hugetlbfs and sharing that. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
64-bit build failure without hugetlbfs
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): multiple definition of `arch_get_unmapped_area_topdown' arch/powerpc/mm/built-in.o:(.opd+0x918): first defined here mm/built-in.o: In function `.arch_get_unmapped_area': (.text+0x1ce3c): multiple definition of `.arch_get_unmapped_area' arch/powerpc/mm/built-in.o:(.text+0x72b8): first defined here mm/built-in.o: In function `arch_get_unmapped_area': (.opd+0x2718): multiple definition of `arch_get_unmapped_area' arch/powerpc/mm/built-in.o:(.opd+0x930): first defined here make: *** [vmlinux.o] Error 1 enabling hugetlbfs cures it. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
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 2.6.26 amd64 client, a setup that normally triggers the problem on the 2nd or 3rd build, I was able to do 10 complete builds. (make clean oldconfig vmlinux modules) So it looks like ftrace is the cause, or at least provokes some other usually-latent problem. I wasn't using it, so I'll just leave it off. OK, that's sort of good, but also not. I can't see anything in the ftrace code that explains it, but I guess it's lurking. We'll try and reproduce locally and bang on it. Thanks for chasing it, and let us know if you get an oops with CONFIG_FTRACE=n. And can you enable CONFIG_CODE_PATCHING_SELFTEST and CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed that /could/ (maybe) cause random blow ups. With those options enabled, I get this: Running code patching self-tests ... Running feature fixup self-tests ... That's good, they only print if they fail. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 64-bit build failure without hugetlbfs
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 mm/built-in.o: In function `arch_get_unmapped_area_topdown': (.opd+0x2730): multiple definition of `arch_get_unmapped_area_topdown' arch/powerpc/mm/built-in.o:(.opd+0x918): first defined here mm/built-in.o: In function `.arch_get_unmapped_area': (.text+0x1ce3c): multiple definition of `.arch_get_unmapped_area' arch/powerpc/mm/built-in.o:(.text+0x72b8): first defined here mm/built-in.o: In function `arch_get_unmapped_area': (.opd+0x2718): multiple definition of `arch_get_unmapped_area' arch/powerpc/mm/built-in.o:(.opd+0x930): first defined here make: *** [vmlinux.o] Error 1 enabling hugetlbfs cures it. johannes Or disabling CONFIG_PPC_64K_PAGES if you do not want to enable hugetlbfs... Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
hang w/ppc6xx_defconfig related to 'simple-bus' compatible
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 (w/'simple-bus') using the mpc8641_hpcn_defconfig and things work. Any one got any ideas? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
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 irq when we originally
received it - when it was spurious.
This can be reproduced trivially by banging the keyboard while kexec'ing on
a P5 LPAR, even though the hvc_console driver request's the console irq later
in boot, the console is non-functional because we're receiving no console
interrupts.
So when we receive a spurious irq, EOI it, and then mask it.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
Probably 27 material unless there are objections ..
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..dc007f4 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -321,21 +321,26 @@ static unsigned int xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+ iosync();
+ direct_xirr_info_set((0xff 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+ xics_eoi_hwirq_direct((unsigned int)irq_map[virq].hwirq);
+}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
- direct_xirr_info_set((0xff 24) | irq);
+ lpar_xirr_info_set((0xff 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
- iosync();
- lpar_xirr_info_set((0xff 24) | irq);
+ xics_eoi_hwirq_lpar((unsigned int)irq_map[virq].hwirq);
}
static inline unsigned int xics_remap_irq(unsigned int vec)
@@ -350,9 +355,15 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
if (likely(irq != NO_IRQ))
return irq;
- printk(KERN_ERR Interrupt %u (real) is invalid,
- disabling it.\n, vec);
+ pr_err(%s: no mapping for hwirq %u, disabling it.\n, __func__, vec);
+
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ xics_eoi_hwirq_lpar(vec);
+ else
+ xics_eoi_hwirq_direct(vec);
+
xics_mask_real_irq(vec);
+
return NO_IRQ;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ibmebus/of_platform: Move name sysfs attribute into generic OF devices
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 | 12
drivers/of/device.c | 10 ++
2 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9d42eb5..a063622 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -233,17 +233,6 @@ void ibmebus_free_irq(u32 ist, void *dev_id)
}
EXPORT_SYMBOL(ibmebus_free_irq);
-static ssize_t name_show(struct device *dev,
-struct device_attribute *attr, char *buf)
-{
- return sprintf(buf, %s\n, to_of_device(dev)-node-name);
-}
-
-static struct device_attribute ibmebus_dev_attrs[] = {
- __ATTR_RO(name),
- __ATTR_NULL
-};
-
static char *ibmebus_chomp(const char *in, size_t count)
{
char *out = kmalloc(count + 1, GFP_KERNEL);
@@ -327,7 +316,6 @@ static struct bus_attribute ibmebus_bus_attrs[] = {
struct bus_type ibmebus_bus_type = {
.uevent= of_device_uevent,
- .dev_attrs = ibmebus_dev_attrs,
.bus_attrs = ibmebus_bus_attrs
};
EXPORT_SYMBOL(ibmebus_bus_type);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 8a1d93a..51e5214 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -57,6 +57,15 @@ static ssize_t devspec_show(struct device *dev,
return sprintf(buf, %s\n, ofdev-node-full_name);
}
+static ssize_t name_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct of_device *ofdev;
+
+ ofdev = to_of_device(dev);
+ return sprintf(buf, %s\n, ofdev-node-name);
+}
+
static ssize_t modalias_show(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -71,6 +80,7 @@ static ssize_t modalias_show(struct device *dev,
struct device_attribute of_platform_device_attrs[] = {
__ATTR_RO(devspec),
+ __ATTR_RO(name),
__ATTR_RO(modalias),
__ATTR_NULL
};
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Big include file move breaks user mode
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
int main(int argc, char *argv[])
{
ioctl(1, TCFLSH, 1);
return 0;
}
This builds and runs fine under x86 and ppc before the include file
move. After the move, the compile fails because gcc can't find
asm/ioctls.h which is needed by /usr/include/bits/ioctls.h (let's
ignore the cross-compile path for now).
The other big one I am hitting is that /usr/include/bits/errno.h
includes linux/errno.h which includes asm/errno.h which no longer
exists.
Anybody know how to fix this? I am using the DENX 4.1 toolchain if that
helps. Also, if there is a better place to post this, let me know. I
posted here since it only affects powerpc cross compiles... x86 still
has all the includes in the right place.
Should include/asm be a link to arch/powerpc/include/asm?
Cheers,
Sean
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 suspect we end up back at hugetlbfs backing it :/ Yeah, but the case I'm worried about is plain anonymous. We already have the fs to back SHARED|ANONYMOUS, and they're not really anonymous. :) This patch *really* needs anonymous pages, and it kinda shoehorns them in with the filesystem. Stacks aren't shared at all, so this is a perfect example of where we can forget the fs, right? -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Big include file move breaks user mode
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 apparent reason ;)
#include stdio.h
#include sys/ioctl.h
int main(int argc, char *argv[])
{
ioctl(1, TCFLSH, 1);
return 0;
}
This builds and runs fine under x86 and ppc before the include file
move. After the move, the compile fails because gcc can't find
asm/ioctls.h which is needed by /usr/include/bits/ioctls.h (let's
ignore the cross-compile path for now).
The other big one I am hitting is that /usr/include/bits/errno.h
includes linux/errno.h which includes asm/errno.h which no longer
exists.
Anybody know how to fix this? I am using the DENX 4.1 toolchain if
that
helps. Also, if there is a better place to post this, let me know. I
posted here since it only affects powerpc cross compiles... x86 still
has all the includes in the right place.
Should include/asm be a link to arch/powerpc/include/asm?
Are you using the headers_install option? or just point to a kernel
tree.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 is already populated by the parent. I strongly suspect we end up back at hugetlbfs backing it :/ Yeah, but the case I'm worried about is plain anonymous. We already have the fs to back SHARED|ANONYMOUS, and they're not really anonymous. :) This patch *really* needs anonymous pages, and it kinda shoehorns them in with the filesystem. Stacks aren't shared at all, so this is a perfect example of where we can forget the fs, right? 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 could call that sort of thing directly if the reservation layer was split out separate from hugetlbfs but I still don't see the gain for all that churn. What am I missing? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
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 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
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 could call that sort of thing directly if the reservation layer was split out separate from hugetlbfs but I still don't see the gain for all that churn. What am I missing? This is good for getting us incremental functionality. It is probably the smallest amount of code to get it functional. My concern is that we're going down a path that all large page usage should be through the one and only filesystem. Once we establish that dependency, it is going to be awfully hard to undo it; just think of all of the inherent behavior in hugetlbfs. So, we better be sure that the filesystem really is the way to go, especially if we're going to start having other areas of the kernel depend on it internally. That said, this particular patch doesn't appear *too* bound to hugetlb itself. But, some of its limitations *do* come from the filesystem, like its inability to handle VM_GROWS... -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
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 idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine is
running. Fortunately, because I had a bug where this bit was not getting
cleared on one of the paths through the target routine ... I now know it
is not safe to call schedule (it got stuck in there - knocked out my adb
keyboard! - (I think target is called from a timer that the governor
sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
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! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 5121 u-boot uses the immr alias instead
of the node name.
Signed-off-by: John Rigby [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc5121ads.dts |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc5121ads.dts
b/arch/powerpc/boot/dts/mpc5121ads.dts
index 1f9036c..c52c51d 100644
--- a/arch/powerpc/boot/dts/mpc5121ads.dts
+++ b/arch/powerpc/boot/dts/mpc5121ads.dts
@@ -19,6 +19,7 @@
aliases {
pci = pci;
+ immr = immr;
};
cpus {
@@ -135,7 +136,7 @@
};
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
compatible = fsl,mpc5121-immr;
#address-cells = 1;
#size-cells = 1;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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 b/arch/powerpc/sysdev/fsl_soc.c
index 214388e..2643395 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -45,14 +45,35 @@ extern void init_fec_ioports(struct fs_platform_info*);
extern void init_smc_ioports(struct fs_uart_platform_info*);
static phys_addr_t immrbase = -1;
+/*
+ * Some chips call this immr some ccsr, we
+ * use the term immr for both.
+ */
phys_addr_t get_immrbase(void)
{
- struct device_node *soc;
+ struct device_node *soc = NULL;
+ struct device_node *np;
+ const char *path;
+
if (immrbase != -1)
return immrbase;
- soc = of_find_node_by_type(NULL, soc);
+ /*
+* First look for an immr alias
+*/
+ np = of_find_node_by_name(NULL, /aliases);
+ if (np) {
+ path = of_get_property(np, immr, NULL);
+ if (path)
+ soc = of_find_node_by_name(NULL, path);
+ }
+ /*
+* If no immr alias then fall back to finding
+* it by device_type
+*/
+ if (!soc)
+ soc = of_find_node_by_type(NULL, soc);
if (soc) {
int size;
u32 naddr;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH add immr alias 3/4] powerpc: 83xx: Add immr aliases to 83xx device trees.
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|3 ++-
arch/powerpc/boot/dts/mpc8349emitx.dts |3 ++-
arch/powerpc/boot/dts/mpc8349emitxgp.dts |3 ++-
arch/powerpc/boot/dts/mpc834x_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc836x_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc836x_rdk.dts|3 ++-
arch/powerpc/boot/dts/mpc8377_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc8377_rdb.dts|3 ++-
arch/powerpc/boot/dts/mpc8378_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc8378_rdb.dts|3 ++-
arch/powerpc/boot/dts/mpc8379_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc8379_rdb.dts|3 ++-
arch/powerpc/boot/dts/sbc8349.dts|3 ++-
16 files changed, 32 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index 2a94ae0..3c04cd2 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -23,6 +23,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -94,7 +95,7 @@
};
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index f704513..3327670 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -22,6 +22,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -92,7 +93,7 @@
};
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index fbc9304..a2757b3 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -35,6 +35,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -64,7 +65,7 @@
reg = 0xf800 0x8000;
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc832x_rdb.dts
b/arch/powerpc/boot/dts/mpc832x_rdb.dts
index b157d18..50e0539 100644
--- a/arch/powerpc/boot/dts/mpc832x_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc832x_rdb.dts
@@ -23,6 +23,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -47,7 +48,7 @@
reg = 0x 0x0400;
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 700e076..ed24c85 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -24,6 +24,7 @@
serial1 = serial1;
pci0 = pci0;
pci1 = pci1;
+ immr = immr;
};
cpus {
@@ -48,7 +49,7 @@
reg = 0x 0x1000;
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index cdd3063..24a696d 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -22,6 +22,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -46,7 +47,7 @@
reg = 0x 0x1000;
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts
b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 783241c..aad88e1 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -24,6 +24,7 @@
serial1 = serial1;
pci0 =
[PATCH add immr alias 4/4] powerpc: 8[56]xx: Add immr aliases to 8[56]xx device trees
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|3 ++-
arch/powerpc/boot/dts/mpc8540ads.dts |3 ++-
arch/powerpc/boot/dts/mpc8541cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8544ds.dts|3 ++-
arch/powerpc/boot/dts/mpc8548cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8555cds.dts |3 ++-
arch/powerpc/boot/dts/mpc8560ads.dts |3 ++-
arch/powerpc/boot/dts/mpc8568mds.dts |3 ++-
arch/powerpc/boot/dts/mpc8572ds.dts|3 ++-
arch/powerpc/boot/dts/mpc8610_hpcd.dts |3 ++-
arch/powerpc/boot/dts/mpc8641_hpcn.dts |3 ++-
arch/powerpc/boot/dts/mpc866ads.dts|6 +-
arch/powerpc/boot/dts/mpc885ads.dts|6 +-
arch/powerpc/boot/dts/sbc8548.dts |3 ++-
arch/powerpc/boot/dts/sbc8560.dts |3 ++-
arch/powerpc/boot/dts/sbc8641d.dts |3 ++-
arch/powerpc/boot/dts/stx_gp3_8560.dts |3 ++-
arch/powerpc/boot/dts/tqm8540.dts |3 ++-
arch/powerpc/boot/dts/tqm8541.dts |3 ++-
arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 +++-
arch/powerpc/boot/dts/tqm8548.dts |4 +++-
arch/powerpc/boot/dts/tqm8555.dts |3 ++-
arch/powerpc/boot/dts/tqm8560.dts |3 ++-
24 files changed, 56 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/boot/dts/ksi8560.dts
b/arch/powerpc/boot/dts/ksi8560.dts
index 4973758..9d3e560 100644
--- a/arch/powerpc/boot/dts/ksi8560.dts
+++ b/arch/powerpc/boot/dts/ksi8560.dts
@@ -24,6 +24,7 @@
ethernet0 = enet0;
ethernet1 = enet1;
ethernet2 = enet2;
+ immr = immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = 0x 0x1000; /* Fixed by
bootwrapper */
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8536ds.dts
b/arch/powerpc/boot/dts/mpc8536ds.dts
index 1505d68..0d28ff4 100644
--- a/arch/powerpc/boot/dts/mpc8536ds.dts
+++ b/arch/powerpc/boot/dts/mpc8536ds.dts
@@ -26,6 +26,7 @@
pci1 = pci1;
pci2 = pci2;
pci3 = pci3;
+ immr = immr;
};
cpus {
@@ -45,7 +46,7 @@
reg = ; // Filled by U-Boot
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
b/arch/powerpc/boot/dts/mpc8540ads.dts
index 9568bfa..1f32d2f 100644
--- a/arch/powerpc/boot/dts/mpc8540ads.dts
+++ b/arch/powerpc/boot/dts/mpc8540ads.dts
@@ -24,6 +24,7 @@
serial0 = serial0;
serial1 = serial1;
pci0 = pci0;
+ immr = immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = 0x0 0x800; // 128M at 0x0
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8541cds.dts
b/arch/powerpc/boot/dts/mpc8541cds.dts
index 6480f4f..e5fb2d1 100644
--- a/arch/powerpc/boot/dts/mpc8541cds.dts
+++ b/arch/powerpc/boot/dts/mpc8541cds.dts
@@ -24,6 +24,7 @@
serial1 = serial1;
pci0 = pci0;
pci1 = pci1;
+ immr = immr;
};
cpus {
@@ -49,7 +50,7 @@
reg = 0x0 0x800; // 128M at 0x0
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8544ds.dts
b/arch/powerpc/boot/dts/mpc8544ds.dts
index f1fb207..0814730 100644
--- a/arch/powerpc/boot/dts/mpc8544ds.dts
+++ b/arch/powerpc/boot/dts/mpc8544ds.dts
@@ -25,6 +25,7 @@
pci1 = pci1;
pci2 = pci2;
pci3 = pci3;
+ immr = immr;
};
cpus {
@@ -50,7 +51,7 @@
reg = 0x0 0x0;// Filled by U-Boot
};
- [EMAIL PROTECTED] {
+ immr: [EMAIL PROTECTED] {
#address-cells = 1;
#size-cells = 1;
device_type = soc;
diff --git a/arch/powerpc/boot/dts/mpc8548cds.dts
b/arch/powerpc/boot/dts/mpc8548cds.dts
index 431b496..71ff390 100644
--- a/arch/powerpc/boot/dts/mpc8548cds.dts
+++ b/arch/powerpc/boot/dts/mpc8548cds.dts
@@ -29,6 +29,7 @@
pci0 = pci0;
Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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 assumptions about the register layout of the whole SOC. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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 instead of making assumptions about the register layout of the whole SOC. That wouldn't eliminate the need for the alias, though -- u-boot needs to find the node to fill in properties. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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 to use a reg property of some actual device instead of making assumptions about the register layout of the whole SOC. That wouldn't eliminate the need for the alias, though -- u-boot needs to find the node to fill in properties. While I have no issue with the change. I'm interested to see how John plans on using this in u-boot. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 a clock fixup so leave it soc for now. We will change it later after 5121 u-boot uses the immr alias instead of the node name. 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. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 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 5121 u-boot uses the immr alias instead of the node name. 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. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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 users can be converted to use a reg property of some actual device instead of making assumptions about the register layout of the whole SOC. That wouldn't eliminate the need for the alias, though -- u-boot needs to find the node to fill in properties. (already made this comment on one of the later patches, but it is more relevant here...) I don't think that using aliases is the best solution. I'd rather see U-Boot search for the appropriate compatible value for the IMMR node. g. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 that corresponds to u-boot's enumeration is what it's meant for, either, but pretty much any alternative you can come up with has someone saying that it's not what *that* was meant for, either. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 with multiple chips. I don't think finding the network or serial node that corresponds to u-boot's enumeration is what it's meant for, either, but pretty much any alternative you can come up with has someone saying that it's not what *that* was meant for, either. 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 complete sense to me. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 to it to pass to setup_indirect_pci as the cfg_addr, and cfg_data addresses. I'm more than willing to change mpc83xx_add_bridge to not use get_immrbase. One simple solution is to pass the cfg_addr and cfg_data addresses in. If that seems ok then thats what I will do. John Grant Likely wrote: 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 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 5121 u-boot uses the immr alias instead of the node name. 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. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 complete sense to me. It is ridiculous to have to duplicate code (or create a table, or whatever) just so it can search for mpc8536-foo, mpc8544-foo, mpc8548-foo, etc -- and in the case of the SoC, it's *not* fully compatible, so we *can't* pick one as the default -- but it's compatible for the purposes of the code in question. I figured an alias would attract fewer flames than a compatible of fsl,immr (though I'm fine with it -- it's specifying compatibility of device tree binding, not of the hardware). And no, they're not all finding it by path now -- there's a lot of use of device_type soc, which is what we're trying to avoid by introducing this alias. The bootwrapper is also affected. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 mpc83xx_add_bridge to not use get_immrbase. One simple solution is to pass the cfg_addr and cfg_data addresses in. If that seems ok then thats what I will do. We should really be putting those addresses in the reg property of the PCI node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Kconfig debug help
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 defconfig, and then it doesn't do anything when I run make with the defconfig file. Thanks for any help, John This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 willing to change mpc83xx_add_bridge to not use get_immrbase. One simple solution is to pass the cfg_addr and cfg_data addresses in. If that seems ok then thats what I will do. We should really be putting those addresses in the reg property of the PCI node. -Scott Yes, which is what fsl_add_bridge does it. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kconfig debug help
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 board. I get the .config created, then copy it to a defconfig, and then it doesn’t do anything when I run make with the defconfig file. Yeah, I hit that myself this weekend. It's a bug in the Kconfig area. It's 1/2 fixed in the latest Linus and powerpc trees. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Kconfig debug help
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 Subject: Re: Kconfig debug help 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 board. I get the .config created, then copy it to a defconfig, and then it doesn't do anything when I run make with the defconfig file. Yeah, I hit that myself this weekend. It's a bug in the Kconfig area. It's 1/2 fixed in the latest Linus and powerpc trees. josh This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
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 cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
How are you copying the table? Is it an atomic copy? Otherwise you could
just end up copying the table while it's being updated, and you get a
copy of the partially updated table.
Don't you just need a spinlock?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] powerpc: fsl_msi doesn't need it's own of_node
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 +---
arch/powerpc/sysdev/fsl_msi.h |3 ---
2 files changed, 5 insertions(+), 10 deletions(-)
Hi Paul, I sent these a while ago, and they were acked by FSL folks and
Ojn - so I think Benh just forgot to merge them for 27.
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 2c5187c..d49fa99 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -108,7 +108,8 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
bitmap_allocate_region(msi-fsl_msi_bitmap, 0,
get_count_order(NR_MSI_IRQS));
- p = of_get_property(msi-of_node, msi-available-ranges, len);
+ p = of_get_property(msi-irqhost-of_node, msi-available-ranges,
+ len);
if (!p) {
/* No msi-available-ranges property,
@@ -120,7 +121,7 @@ static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
if ((len % (2 * sizeof(u32))) != 0) {
printk(KERN_WARNING fsl_msi: Malformed msi-available-ranges
- property on %s\n, msi-of_node-full_name);
+ property on %s\n, msi-irqhost-of_node-full_name);
return -EINVAL;
}
@@ -317,14 +318,11 @@ static int __devinit fsl_of_msi_probe(struct of_device
*dev,
goto error_out;
}
- msi-of_node = of_node_get(dev-node);
+ msi-irqhost = irq_alloc_host(dev-node, IRQ_HOST_MAP_LINEAR,
+ NR_MSI_IRQS, fsl_msi_host_ops, 0);
- msi-irqhost = irq_alloc_host(of_node_get(dev-node),
- IRQ_HOST_MAP_LINEAR,
- NR_MSI_IRQS, fsl_msi_host_ops, 0);
if (msi-irqhost == NULL) {
dev_err(dev-dev, No memory for MSI irqhost\n);
- of_node_put(dev-node);
err = -ENOMEM;
goto error_out;
}
diff --git a/arch/powerpc/sysdev/fsl_msi.h b/arch/powerpc/sysdev/fsl_msi.h
index a653468..6574550 100644
--- a/arch/powerpc/sysdev/fsl_msi.h
+++ b/arch/powerpc/sysdev/fsl_msi.h
@@ -22,9 +22,6 @@
#define FSL_PIC_IP_IPIC0x0002
struct fsl_msi {
- /* Device node of the MSI interrupt*/
- struct device_node *of_node;
-
struct irq_host *irqhost;
unsigned long cascade_irq;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: Split-out common MSI bitmap logic into msi_bitmap.c
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 buglets. The first is that the allocation
routines, now msi_bitmap_alloc_hwirqs(), returned an unsigned result,
even though they use -1 to indicate allocation failure. Although all
the callers were checking correctly, it is much better for the routine
to just return an int. At least until someone wants ~2 billion MSIs.
The second buglet is that the device tree reservation logic only
allowed power-of-two reservations. AFAICT that didn't effect any existing
code but it's nicer if we can reserve arbitrary irqs from MSI use.
We also add some selftests, which exposed the two buglets and now test
for them, as well as some basic sanity tests. The tests are only built
when CONFIG_DEBUG_KERNEL=y.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/Kconfig.debug|5 +
arch/powerpc/include/asm/msi_bitmap.h | 35 +
arch/powerpc/sysdev/Kconfig |6 +
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/msi_bitmap.c | 247 +
5 files changed, 294 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
index 4ebc52a..15eb278 100644
--- a/arch/powerpc/Kconfig.debug
+++ b/arch/powerpc/Kconfig.debug
@@ -51,6 +51,11 @@ config FTR_FIXUP_SELFTEST
depends on DEBUG_KERNEL
default n
+config MSI_BITMAP_SELFTEST
+ bool Run self-tests of the MSI bitmap code.
+ depends on DEBUG_KERNEL
+ default n
+
config XMON
bool Include xmon kernel debugger
depends on DEBUG_KERNEL
diff --git a/arch/powerpc/include/asm/msi_bitmap.h
b/arch/powerpc/include/asm/msi_bitmap.h
new file mode 100644
index 000..97ac3f4
--- /dev/null
+++ b/arch/powerpc/include/asm/msi_bitmap.h
@@ -0,0 +1,35 @@
+#ifndef _POWERPC_SYSDEV_MSI_BITMAP_H
+#define _POWERPC_SYSDEV_MSI_BITMAP_H
+
+/*
+ * Copyright 2008, Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include linux/of.h
+#include asm/irq.h
+
+struct msi_bitmap {
+ struct device_node *of_node;
+ unsigned long *bitmap;
+ spinlock_t lock;
+ unsigned intirq_count;
+};
+
+int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num);
+void msi_bitmap_free_hwirqs(struct msi_bitmap *bmp, unsigned int offset,
+ unsigned int num);
+void msi_bitmap_reserve_hwirq(struct msi_bitmap *bmp, unsigned int hwirq);
+
+int msi_bitmap_reserve_dt_hwirqs(struct msi_bitmap *bmp);
+
+int msi_bitmap_alloc(struct msi_bitmap *bmp, unsigned int irq_count,
+struct device_node *of_node);
+void msi_bitmap_free(struct msi_bitmap *bmp);
+
+#endif /* _POWERPC_SYSDEV_MSI_BITMAP_H */
diff --git a/arch/powerpc/sysdev/Kconfig b/arch/powerpc/sysdev/Kconfig
index 72fb35b..3965828 100644
--- a/arch/powerpc/sysdev/Kconfig
+++ b/arch/powerpc/sysdev/Kconfig
@@ -6,3 +6,9 @@ config PPC4xx_PCI_EXPRESS
bool
depends on PCI 4xx
default n
+
+config PPC_MSI_BITMAP
+ bool
+ depends on PCI_MSI
+ default y if MPIC
+ default y if FSL_PCI
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a90054b..b6c269e 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -5,6 +5,7 @@ endif
mpic-msi-obj-$(CONFIG_PCI_MSI) += mpic_msi.o mpic_u3msi.o mpic_pasemi_msi.o
obj-$(CONFIG_MPIC) += mpic.o $(mpic-msi-obj-y)
fsl-msi-obj-$(CONFIG_PCI_MSI) += fsl_msi.o
+obj-$(CONFIG_PPC_MSI_BITMAP) += msi_bitmap.o
obj-$(CONFIG_PPC_MPC106) += grackle.o
obj-$(CONFIG_PPC_DCR_NATIVE) += dcr-low.o
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
new file mode 100644
index 000..f84217b
--- /dev/null
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -0,0 +1,247 @@
+/*
+ * Copyright 2006-2008, Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2 of the
+ * License.
+ *
+ */
+
+#include linux/kernel.h
+#include linux/bitmap.h
+#include asm/msi_bitmap.h
+
+int msi_bitmap_alloc_hwirqs(struct msi_bitmap *bmp, int num)
+{
+ unsigned long flags;
+ int offset, order = get_count_order(num);
+
+ spin_lock_irqsave(bmp-lock, flags);
+ /*
+* This is fast, but stricter than we need. We might want to add
+* a fallback routine which does a linear
[PATCH 3/4] powerpc: Convert the FSL MSI code to use msi_bitmap
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 |5 +-
2 files changed, 17 insertions(+), 91 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index d49fa99..f25ce81 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -14,7 +14,6 @@
*/
#include linux/irq.h
#include linux/bootmem.h
-#include linux/bitmap.h
#include linux/msi.h
#include linux/pci.h
#include linux/of_platform.h
@@ -67,96 +66,22 @@ static struct irq_host_ops fsl_msi_host_ops = {
.map = fsl_msi_host_map,
};
-static irq_hw_number_t fsl_msi_alloc_hwirqs(struct fsl_msi *msi, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
- int offset;
-
- spin_lock_irqsave(msi-bitmap_lock, flags);
-
- offset = bitmap_find_free_region(msi-fsl_msi_bitmap,
- NR_MSI_IRQS, order);
-
- spin_unlock_irqrestore(msi-bitmap_lock, flags);
-
- pr_debug(%s: allocated 0x%x (2^%d) at offset 0x%x\n,
- __func__, num, order, offset);
-
- return offset;
-}
-
-static void fsl_msi_free_hwirqs(struct fsl_msi *msi, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug(%s: freeing 0x%x (2^%d) at offset 0x%x\n,
- __func__, num, order, offset);
-
- spin_lock_irqsave(msi-bitmap_lock, flags);
- bitmap_release_region(msi-fsl_msi_bitmap, offset, order);
- spin_unlock_irqrestore(msi-bitmap_lock, flags);
-}
-
-static int fsl_msi_free_dt_hwirqs(struct fsl_msi *msi)
-{
- int i;
- int len;
- const u32 *p;
-
- bitmap_allocate_region(msi-fsl_msi_bitmap, 0,
- get_count_order(NR_MSI_IRQS));
-
- p = of_get_property(msi-irqhost-of_node, msi-available-ranges,
- len);
-
- if (!p) {
- /* No msi-available-ranges property,
-* All the 256 MSI interrupts can be used
-*/
- fsl_msi_free_hwirqs(msi, 0, 0x100);
- return 0;
- }
-
- if ((len % (2 * sizeof(u32))) != 0) {
- printk(KERN_WARNING fsl_msi: Malformed msi-available-ranges
- property on %s\n, msi-irqhost-of_node-full_name);
- return -EINVAL;
- }
-
- /* Format is: (u32 start u32 count)+ */
- len /= 2 * sizeof(u32);
- for (i = 0; i len; i++, p += 2)
- fsl_msi_free_hwirqs(msi, *p, *(p + 1));
-
- return 0;
-}
-
static int fsl_msi_init_allocator(struct fsl_msi *msi_data)
{
int rc;
- int size = BITS_TO_LONGS(NR_MSI_IRQS) * sizeof(u32);
- msi_data-fsl_msi_bitmap = kzalloc(size, GFP_KERNEL);
+ rc = msi_bitmap_alloc(msi_data-bitmap, NR_MSI_IRQS,
+ msi_data-irqhost-of_node);
+ if (rc)
+ return rc;
- if (msi_data-fsl_msi_bitmap == NULL) {
- pr_debug(%s: ENOMEM allocating allocator bitmap!\n,
- __func__);
- return -ENOMEM;
+ rc = msi_bitmap_reserve_dt_hwirqs(msi_data-bitmap);
+ if (rc 0) {
+ msi_bitmap_free(msi_data-bitmap);
+ return rc;
}
- rc = fsl_msi_free_dt_hwirqs(msi_data);
- if (rc)
- goto out_free;
-
return 0;
-out_free:
- kfree(msi_data-fsl_msi_bitmap);
-
- msi_data-fsl_msi_bitmap = NULL;
- return rc;
-
}
static int fsl_msi_check_device(struct pci_dev *pdev, int nvec, int type)
@@ -176,7 +101,8 @@ static void fsl_teardown_msi_irqs(struct pci_dev *pdev)
if (entry-irq == NO_IRQ)
continue;
set_irq_msi(entry-irq, NULL);
- fsl_msi_free_hwirqs(msi_data, virq_to_hw(entry-irq), 1);
+ msi_bitmap_free_hwirqs(msi_data-bitmap,
+ virq_to_hw(entry-irq), 1);
irq_dispose_mapping(entry-irq);
}
@@ -198,15 +124,14 @@ static void fsl_compose_msi_msg(struct pci_dev *pdev, int
hwirq,
static int fsl_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
{
- irq_hw_number_t hwirq;
- int rc;
+ int rc, hwirq;
unsigned int virq;
struct msi_desc *entry;
struct msi_msg msg;
struct fsl_msi *msi_data = fsl_msi;
list_for_each_entry(entry, pdev-msi_list, list) {
- hwirq = fsl_msi_alloc_hwirqs(msi_data, 1);
+ hwirq = msi_bitmap_alloc_hwirqs(msi_data-bitmap, 1);
if (hwirq 0) {
rc = hwirq;
pr_debug(%s: fail allocating msi interrupt\n,
@@ -217,9
[PATCH 4/4] powerpc: Convert the MPIC MSI code to use msi_bitmap
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 PROTECTED]
---
arch/powerpc/include/asm/mpic.h |4 +-
arch/powerpc/sysdev/mpic.h|2 -
arch/powerpc/sysdev/mpic_msi.c| 123 +
arch/powerpc/sysdev/mpic_pasemi_msi.c | 24 ---
arch/powerpc/sysdev/mpic_u3msi.c | 22 +++---
5 files changed, 44 insertions(+), 131 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index fe566a3..34d9ac4 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -5,6 +5,7 @@
#include linux/irq.h
#include linux/sysdev.h
#include asm/dcr.h
+#include asm/msi_bitmap.h
/*
* Global registers
@@ -301,8 +302,7 @@ struct mpic
#endif
#ifdef CONFIG_PCI_MSI
- spinlock_t bitmap_lock;
- unsigned long *hwirq_bitmap;
+ struct msi_bitmap msi_bitmap;
#endif
#ifdef CONFIG_MPIC_BROKEN_REGREAD
diff --git a/arch/powerpc/sysdev/mpic.h b/arch/powerpc/sysdev/mpic.h
index fbf8a26..6209c62 100644
--- a/arch/powerpc/sysdev/mpic.h
+++ b/arch/powerpc/sysdev/mpic.h
@@ -14,8 +14,6 @@
#ifdef CONFIG_PCI_MSI
extern void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq);
extern int mpic_msi_init_allocator(struct mpic *mpic);
-extern irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num);
-extern void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num);
extern int mpic_u3msi_init(struct mpic *mpic);
extern int mpic_pasemi_msi_init(struct mpic *mpic);
#else
diff --git a/arch/powerpc/sysdev/mpic_msi.c b/arch/powerpc/sysdev/mpic_msi.c
index de3e5e8..1d44eee 100644
--- a/arch/powerpc/sysdev/mpic_msi.c
+++ b/arch/powerpc/sysdev/mpic_msi.c
@@ -15,59 +15,17 @@
#include asm/prom.h
#include asm/hw_irq.h
#include asm/ppc-pci.h
+#include asm/msi_bitmap.h
#include sysdev/mpic.h
-static void __mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
-{
- pr_debug(mpic: reserving hwirq 0x%lx\n, hwirq);
- bitmap_allocate_region(mpic-hwirq_bitmap, hwirq, 0);
-}
-
void mpic_msi_reserve_hwirq(struct mpic *mpic, irq_hw_number_t hwirq)
{
- unsigned long flags;
-
/* The mpic calls this even when there is no allocator setup */
- if (!mpic-hwirq_bitmap)
+ if (!mpic-msi_bitmap.bitmap)
return;
- spin_lock_irqsave(mpic-bitmap_lock, flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
- spin_unlock_irqrestore(mpic-bitmap_lock, flags);
-}
-
-irq_hw_number_t mpic_msi_alloc_hwirqs(struct mpic *mpic, int num)
-{
- unsigned long flags;
- int offset, order = get_count_order(num);
-
- spin_lock_irqsave(mpic-bitmap_lock, flags);
- /*
-* This is fast, but stricter than we need. We might want to add
-* a fallback routine which does a linear search with no alignment.
-*/
- offset = bitmap_find_free_region(mpic-hwirq_bitmap, mpic-irq_count,
-order);
- spin_unlock_irqrestore(mpic-bitmap_lock, flags);
-
- pr_debug(mpic: allocated 0x%x (2^%d) at offset 0x%x\n,
-num, order, offset);
-
- return offset;
-}
-
-void mpic_msi_free_hwirqs(struct mpic *mpic, int offset, int num)
-{
- unsigned long flags;
- int order = get_count_order(num);
-
- pr_debug(mpic: freeing 0x%x (2^%d) at offset 0x%x\n,
-num, order, offset);
-
- spin_lock_irqsave(mpic-bitmap_lock, flags);
- bitmap_release_region(mpic-hwirq_bitmap, offset, order);
- spin_unlock_irqrestore(mpic-bitmap_lock, flags);
+ msi_bitmap_reserve_hwirq(mpic-msi_bitmap, hwirq);
}
#ifdef CONFIG_MPIC_U3_HT_IRQS
@@ -83,13 +41,13 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
/* Reserve source numbers we know are reserved in the HW */
for (i = 0; i 8; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(mpic-msi_bitmap, i);
for (i = 42; i 46; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(mpic-msi_bitmap, i);
for (i = 100; i 105; i++)
- __mpic_msi_reserve_hwirq(mpic, i);
+ msi_bitmap_reserve_hwirq(mpic-msi_bitmap, i);
np = NULL;
while ((np = of_find_all_nodes(np))) {
@@ -99,7 +57,7 @@ static int mpic_msi_reserve_u3_hwirqs(struct mpic *mpic)
while (of_irq_map_one(np, index++, oirq) == 0) {
ops-xlate(mpic-irqhost, NULL, oirq.specifier,
oirq.size, hwirq, flags);
- __mpic_msi_reserve_hwirq(mpic, hwirq);
+
Re: PS3 early lock-up
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 significant performance loss using that instead ? updatepp shouldn't be something called -that- often). Yes, we have lv1_read_htab_entries(). Mokuno-san started some work to convert to using it and removing the htab mapping: http://git.kernel.org/?p=linux/kernel/git/geoff/ps3-linux-patches.git;a=blob;f=ps3-wip/ps3-htab-rework.diff;hb=HEAD Unfortunately, this week Mokuno-san is on holiday, and I am busy preparing for SIGGRAPH (next week). - Add a way to setup HPTEs using 3 PPP bits. I'm not going to implement that for the main hash code just yet though (the assembly) but it might be possible to implement it specifically for mappings bolted. That means it would only work when the mapping is done early but on PS3, we know that the hash table is always mapped early. The later would be a matter of taking my htab_convert_pte_flags() function and making it capable, when _PAGE_USER is _not_ set and _PAGE_RW is not set neither, to set PPP to 110. 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. If we can't remove the htab mapping with lv1_read_htab_entries(), I'll look into this way. -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 2/4] powerpc: 5121: Add immr alias to MPC5121 ADS device tree.
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 them to find by compatible that is set per-board or per-SoC makes complete sense to me. It is ridiculous to have to duplicate code (or create a table, or whatever) just so it can search for mpc8536-foo, mpc8544-foo, mpc8548-foo, etc -- and in the case of the SoC, it's *not* fully compatible, so we *can't* pick one as the default -- but it's compatible for the purposes of the code in question. I figured an alias would attract fewer flames than a compatible of fsl,immr (though I'm fine with it -- it's specifying compatibility of device tree binding, not of the hardware). And no, they're not all finding it by path now -- there's a lot of use of device_type soc, which is what we're trying to avoid by introducing this alias. The bootwrapper is also affected. FWIW, recent u-boot also looks for fsl,soc compatible entry. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
inline assembly r0 SOS
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
addi %0,%0,23\n
rlwnm %0,%1,%0,30,31\n:
=r(ret):
r(config),0(range)
);
return ret;
}
in a header and the resultant code generated is:
.L58:
li 0,1 # ratio,
mr 29,0 # ret, ratio
#APP
slwi 29,29,3 # ret
addi 29,29,21# ret
rlwnm 29,28,29,27,31 # ret, ret
slwi 0,0,3 # ret
addi 0,0,23 # ret
rlwnm 0,28,0,30,31 # ret, ret
#NO_APP
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 blacklist r0?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
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 blacklist r0? Yes. Use b instead of r in the constraints to force the compiler to avoid r0 when assigning a register. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
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: =r(ret): r(config),0(range) ); Wouldn't this be much simpler in plain C? However, if you really do need to do this in inline asm, you can use the b modifier rather than r to avoid using r0. Cheers, Jeremy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
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 that work on XICS? Yeah right, in which case we'd have not EOI'ed that one and we're back at square one. It seems to work with a mask then EOI, so unless Milton says otherwise I'll do it that way - new patch coming. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: to schedule() or not to schedule() ?
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 mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no idea what I am doing
* ... my reasoning is I want to yeild the cpu so whoever is
* mucking around can finish)
*/
schedule();
}
This is to prevent bad things from happening if someone is trying to
change a parameter for the driver via sysfs while the target routine
is running. Fortunately, because I had a bug where this bit was not
getting cleared on one of the paths through the target routine ... I
now know it is not safe to call schedule (it got stuck in there -
knocked out my adb keyboard! - (I think target is called from a timer
that the governor sets up ... interrupt context?)).
Is the issue that someone may be in the middle of a multi-stage
procedure, and you've woken up partway through?
If so, what about simply rescheduling the timer for some short time in
the future and aborting the current call?
Chris,
Thanks for taking the time to reply. The parameter in question modifies
the frequency table. It is used several times in the target routine.
I've addressed the issue by making a local copy of the frequency table
upon entry to the target routine and use that while there. I don't care
who wins the race.
How are you copying the table? Is it an atomic copy? Otherwise you could
just end up copying the table while it's being updated, and you get a
copy of the partially updated table.
Don't you just need a spinlock?
cheers
In the initialization routine I create 2 tables. One is a table with all
the frequencies. The other has just the min and max. The parameter just
changes a pointer to point to one table or the other. The above
addressing of the issue should really say a local copy of the pointer
to the frequency table.
Thanks for the reply!
For the purpose of learning, there is no direct, correct way to yield
the cpu when in a timer fired routine, right?
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
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 irq when we originally
received it - when it was spurious.
This can be reproduced trivially by banging the keyboard while kexec'ing on
a P5 LPAR, even though the hvc_console driver request's the console irq, the
console is non-functional because we're receiving no console interrupts.
So when we receive a spurious irq mask it and then EOI it.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 29 -
1 files changed, 20 insertions(+), 9 deletions(-)
Updated to mask then EOI, thanks to Segher for whacking me with the clue stick.
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..4c692b2 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -321,21 +321,26 @@ static unsigned int xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+ iosync();
+ direct_xirr_info_set((0xff 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+ xics_eoi_hwirq_direct((unsigned int)irq_map[virq].hwirq);
+}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
- direct_xirr_info_set((0xff 24) | irq);
+ lpar_xirr_info_set((0xff 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
- unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
- iosync();
- lpar_xirr_info_set((0xff 24) | irq);
+ xics_eoi_hwirq_lpar((unsigned int)irq_map[virq].hwirq);
}
static inline unsigned int xics_remap_irq(unsigned int vec)
@@ -350,9 +355,15 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
if (likely(irq != NO_IRQ))
return irq;
- printk(KERN_ERR Interrupt %u (real) is invalid,
- disabling it.\n, vec);
+ pr_err(%s: no mapping for hwirq %u, disabling it.\n, __func__, vec);
+
xics_mask_real_irq(vec);
+
+ if (firmware_has_feature(FW_FEATURE_LPAR))
+ xics_eoi_hwirq_lpar(vec);
+ else
+ xics_eoi_hwirq_direct(vec);
+
return NO_IRQ;
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: inline assembly r0 SOS
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: =r(ret): r(config),0(range) ); Wouldn't this be much simpler in plain C? I just knew someone was gonna try to rain on my rlwnm'in fun parade! Wonder if the C code can be made to compile down to 3 instructions? However, if you really do need to do this in inline asm, you can use the b modifier rather than r to avoid using r0. Oh cool! Thanks! You to Ben! Cheers, Jeremy kevin ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
- 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 later
Date: Wed, 6 Aug 2008 12:03:37 +1000 (EST)
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 irq when we originally received it - when it
was spurious.
This can be reproduced trivially by banging the keyboard
while kexec'ing on a P5 LPAR, even though the hvc_console
driver request's the console irq, the console is
non-functional because we're receiving no console
interrupts.
which means some driver didn't disable interrupts on its
shutdown, but I digress.
So when we receive a spurious irq mask it and then EOI it.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 29
-
1 files changed, 20 insertions(+), 9 deletions(-)
Updated to mask then EOI, thanks to Segher for whacking me
with the clue stick.
Actually, just sending the EOI would likely result in the
exact same interrupt comming back, as the mask will set
a bit near the source but the interrupt would have already
been missed. (most irqs in xics systems are level).
Thanks to segher for noticing the order. However...
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c index
0fc830f..4c692b2 100644 ---
a/arch/powerpc/platforms/pseries/xics.c +++
b/arch/powerpc/platforms/pseries/xics.c @@ -321,21 +321,26
@@ static unsigned int xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+iosync();
+direct_xirr_info_set((0xff 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+xics_eoi_hwirq_direct((unsigned
int)irq_map[virq].hwirq); +}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
-direct_xirr_info_set((0xff 24) | irq);
+lpar_xirr_info_set((0xff 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
-iosync();
-lpar_xirr_info_set((0xff 24) | irq);
+xics_eoi_hwirq_lpar((unsigned
int)irq_map[virq].hwirq);
}
static inline unsigned int xics_remap_irq(unsigned int
vec) @@ -350,9 +355,15 @@ static inline unsigned int
xics_remap_irq(unsigned int vec)
if (likely(irq != NO_IRQ))
return irq;
-printk(KERN_ERR Interrupt %u (real) is invalid,
-disabling it.\n, vec);
+pr_err(%s: no mapping for hwirq %u, disabling it.\n
, __func__, vec); +
xics_mask_real_irq(vec);
+
+if (firmware_has_feature(FW_FEATURE_LPAR))
+xics_eoi_hwirq_lpar(vec);
+else
+xics_eoi_hwirq_direct(vec);
+
return NO_IRQ;
}
I really dislike this great big if in the middle of a
function.
we called this function from two different call sites where
the
choice of which to call was based on their environment.
Please move the call to eoi the hwirq to the callers, who
know
which path to take.
I guess it might make sense to put the printk in a
mask_invalid_real_irq wrapper, and then perhaps just
duplicate
the small remaining code? Or split the return of spurious
from NO_IRQ (ie should spurious be NO_IRQ_IGNORE?)
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH add immr alias 1/4] powerpc: Teach get_immrbase to use immr alias if it exists.
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, /aliases);
+ if (np) {
+ path = of_get_property(np, immr, NULL);
+ if (path)
+ soc = of_find_node_by_name(NULL, path);
of_node_put(np);
+ }
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpfjlEY8kaJe.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Implement fdt_get_property_namelen() and fdt_getprop_namelen()
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 path.
However, we don't have corresponding 'namelen' versions for
fdt_get_property() and fdt_getprop(). There are less obvious use
cases for these variants on property names, but there are
circumstances where they can be useful e.g. looking up property names
which need to be parsed from a longer string buffer such as user input
or a configuration file, or looking up an alias in a path with
IEEE1275 style aliases.
So, since it's very easy to implement such variants, this patch does
so. The original NUL-terminated variants are, of course, implemented
in terms of the namelen versions.
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2008-08-05 14:12:17.0 +1000
+++ dtc/libfdt/fdt_ro.c 2008-08-05 14:39:19.0 +1000
@@ -80,6 +80,14 @@ const char *fdt_string(const void *fdt,
return (const char *)fdt + fdt_off_dt_strings(fdt) + stroffset;
}
+static int _fdt_string_eq(const void *fdt, int stroffset,
+ const char *s, int len)
+{
+ const char *p = fdt_string(fdt, stroffset);
+
+ return (strlen(p) == len) (memcmp(p, s, len) == 0);
+}
+
int fdt_get_mem_rsv(const void *fdt, int n, uint64_t *address, uint64_t *size)
{
FDT_CHECK_HEADER(fdt);
@@ -175,9 +183,10 @@ const char *fdt_get_name(const void *fdt
return NULL;
}
-const struct fdt_property *fdt_get_property(const void *fdt,
- int nodeoffset,
- const char *name, int *lenp)
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+ int nodeoffset,
+ const char *name,
+ int namelen, int *lenp)
{
uint32_t tag;
const struct fdt_property *prop;
@@ -210,7 +219,7 @@ const struct fdt_property *fdt_get_prope
if (! prop)
goto fail;
namestroff = fdt32_to_cpu(prop-nameoff);
- if (strcmp(fdt_string(fdt, namestroff), name) == 0) {
+ if (_fdt_string_eq(fdt, namestroff, name, namelen)) {
/* Found it! */
int len = fdt32_to_cpu(prop-len);
prop = fdt_offset_ptr(fdt, offset,
@@ -238,18 +247,32 @@ const struct fdt_property *fdt_get_prope
return NULL;
}
-const void *fdt_getprop(const void *fdt, int nodeoffset,
- const char *name, int *lenp)
+const struct fdt_property *fdt_get_property(const void *fdt,
+ int nodeoffset,
+ const char *name, int *lenp)
+{
+ return fdt_get_property_namelen(fdt, nodeoffset, name,
+ strlen(name), lenp);
+}
+
+const void *fdt_getprop_namelen(const void *fdt, int nodeoffset,
+ const char *name, int namelen, int *lenp)
{
const struct fdt_property *prop;
- prop = fdt_get_property(fdt, nodeoffset, name, lenp);
+ prop = fdt_get_property_namelen(fdt, nodeoffset, name, namelen, lenp);
if (! prop)
return NULL;
return prop-data;
}
+const void *fdt_getprop(const void *fdt, int nodeoffset,
+ const char *name, int *lenp)
+{
+ return fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), lenp);
+}
+
uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
{
const uint32_t *php;
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2008-08-05 14:29:15.0 +1000
+++ dtc/libfdt/libfdt.h 2008-08-05 14:40:58.0 +1000
@@ -343,6 +343,22 @@ int fdt_path_offset(const void *fdt, con
const char *fdt_get_name(const void *fdt, int nodeoffset, int *lenp);
/**
+ * fdt_get_property_namelen - find a property based on substring
+ * @fdt: pointer to the device tree blob
+ * @nodeoffset: offset of the node whose property to find
+ * @name: name of the property to find
+ * @namelen: number of characters of name to consider
+ * @lenp: pointer to an integer variable (will be overwritten) or NULL
+ *
+ * Identical to fdt_get_property_namelen(), but only examine the first
+ * namelen characters of name for matching the property name.
+ */
+const struct fdt_property *fdt_get_property_namelen(const void *fdt,
+
Re: [PATCH] powerpc: EOI spurious irqs during boot so they can be reenabled later
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: EOI spurious irqs during boot so
they can be reenabled later
Date: Wed, 6 Aug 2008 12:03:37 +1000 (EST)
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 irq when we originally received it - when it
was spurious.
This can be reproduced trivially by banging the keyboard
while kexec'ing on a P5 LPAR, even though the hvc_console
driver request's the console irq, the console is
non-functional because we're receiving no console
interrupts.
which means some driver didn't disable interrupts on its
shutdown, but I digress.
But in the case of kdump the driver never gets a chance to shutdown its
irq, but I digress too :)
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c index
0fc830f..4c692b2 100644 ---
a/arch/powerpc/platforms/pseries/xics.c +++
b/arch/powerpc/platforms/pseries/xics.c @@ -321,21 +321,26
@@ static unsigned int xics_startup(unsigned int virq)
return 0;
}
+static void xics_eoi_hwirq_direct(unsigned int hwirq)
+{
+iosync();
+direct_xirr_info_set((0xff 24) | hwirq);
+}
+
static void xics_eoi_direct(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
+xics_eoi_hwirq_direct((unsigned
int)irq_map[virq].hwirq); +}
+static void xics_eoi_hwirq_lpar(unsigned int hwirq)
+{
iosync();
-direct_xirr_info_set((0xff 24) | irq);
+lpar_xirr_info_set((0xff 24) | hwirq);
}
-
static void xics_eoi_lpar(unsigned int virq)
{
-unsigned int irq = (unsigned int)irq_map[virq].hwirq;
-
-iosync();
-lpar_xirr_info_set((0xff 24) | irq);
+xics_eoi_hwirq_lpar((unsigned
int)irq_map[virq].hwirq);
}
static inline unsigned int xics_remap_irq(unsigned int
vec) @@ -350,9 +355,15 @@ static inline unsigned int
xics_remap_irq(unsigned int vec)
if (likely(irq != NO_IRQ))
return irq;
-printk(KERN_ERR Interrupt %u (real) is invalid,
-disabling it.\n, vec);
+pr_err(%s: no mapping for hwirq %u, disabling it.\n
, __func__, vec); +
xics_mask_real_irq(vec);
+
+if (firmware_has_feature(FW_FEATURE_LPAR))
+xics_eoi_hwirq_lpar(vec);
+else
+xics_eoi_hwirq_direct(vec);
+
return NO_IRQ;
}
I really dislike this great big if in the middle of a
function.
we called this function from two different call sites where
the
choice of which to call was based on their environment.
Please move the call to eoi the hwirq to the callers, who
know which path to take.
It's not pretty, but the alternative is worse I think:
From 0a908825c8de6cd4c26288aba8c5b7fe3ed0a69f Mon Sep 17 00:00:00 2001
From: Michael Ellerman [EMAIL PROTECTED]
Date: Tue, 5 Aug 2008 22:34:48 +1000
Subject: [PATCH] powerpc: EOI spurious irqs during boot so they can be
reenabled later
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 irq when we originally
received it - when it was spurious.
This can be reproduced trivially by banging the keyboard while kexec'ing on
a P5 LPAR, even though the hvc_console driver request's the console irq, the
console is non-functional because we're receiving no console interrupts.
So when we receive a spurious irq mask it and then EOI it.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/platforms/pseries/xics.c | 74 ++---
1 files changed, 50 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..754706c 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -90,7 +90,7 @@ static inline unsigned int direct_xirr_info_get(void)
{
int cpu = smp_processor_id();
- return in_be32(xics_per_cpu[cpu]-xirr.word);
+ return in_be32(xics_per_cpu[cpu]-xirr.word) 0x00ff;
}
static inline void direct_xirr_info_set(int value)
@@ -124,7 +124,8 @@ static inline unsigned int lpar_xirr_info_get(void)
lpar_rc = plpar_xirr(return_value);
if (lpar_rc != H_SUCCESS)
panic( bad return code xirr - rc = %lx \n,
[RFC PATCH] Link the bootwrapper as a position-independent executable
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 bootwrapper with -pie to get a position- independent executable, and process the relocations in the dynamic relocation section that the linker puts into the executable. This means that initialized variables and arrays get relocated properly. Currently we only process R_PPC_RELATIVE relocations, which is all we get provided C files are compiled with -fPIC (which they are already) and assembly code is written to be position-independent. Some of the changes below are to make parts of crt0.S be PIC code (i.e. generate no relocations other than R_PPC_RELATIVE). The relocation code below does nothing if there is no dynamic section, which means that we can link without -pie and it will work provided that the bootwrapper executable is loaded at its linked-at address. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] --- diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S index f1c4dfc..a6901c3 100644 --- a/arch/powerpc/boot/crt0.S +++ b/arch/powerpc/boot/crt0.S @@ -6,16 +6,28 @@ * as published by the Free Software Foundation; either version * 2 of the License, or (at your option) any later version. * - * NOTE: this code runs in 32 bit mode and is packaged as ELF32. + * NOTE: this code runs in 32 bit mode, is position-independent, + * and is packaged as ELF32. */ #include ppc_asm.h .text - /* a procedure descriptor used when booting this as a COFF file */ + /* A procedure descriptor used when booting this as a COFF file. +* When making COFF, this comes first in the link and we're +* linked at 0x50. +*/ .globl _zimage_start_opd _zimage_start_opd: - .long _zimage_start, 0, 0, 0 + .long 0x50, 0, 0, 0 + +p_start: .long _start +p_etext: .long _etext +p_bss_start: .long __bss_start +p_end: .long _end + + .weak _platform_stack_top +p_pstack: .long _platform_stack_top .weak _zimage_start .globl _zimage_start @@ -24,37 +36,60 @@ _zimage_start: _zimage_start_lib: /* Work out the offset between the address we were linked at and the address where we're running. */ - bl 1f -1: mflrr0 - lis r9,[EMAIL PROTECTED] - addir9,r9,[EMAIL PROTECTED] - subf. r0,r9,r0 - beq 3f /* if running at same address as linked */ + bl .+4 +p_base:mflrr10 /* r10 now points to runtime addr of p_base */ + /* grab the link address of the dynamic section in r11 */ + addis r11,r10,(_GLOBAL_OFFSET_TABLE_-p_base)@ha + lwz r11,(_GLOBAL_OFFSET_TABLE_-p_base)@l(r11) + cmpwi r11,0 + beq 3f /* if not linked -pie */ + /* get the runtime address of the dynamic section in r12 */ + .weak __dynamic_start + addis r12,r10,(__dynamic_start-p_base)@ha + addir12,r12,(__dynamic_start-p_base)@l + subfr11,r11,r12 /* runtime - linktime offset */ - /* The .got2 section contains a list of addresses, so add - the address offset onto each entry. */ - lis r9,[EMAIL PROTECTED] - addir9,r9,[EMAIL PROTECTED] - lis r8,[EMAIL PROTECTED] - addir8,r8,[EMAIL PROTECTED] - subf. r8,r9,r8 + /* The dynamic section contains a series of tagged entries. +* We need the RELA and RELACOUNT entries. */ +RELA = 7 +RELACOUNT = 0x6ff9 + li r9,0 + li r0,0 +9: lwz r8,0(r12) /* get tag */ + cmpwi r8,0 + beq 10f /* end of list */ + cmpwi r8,RELA + bne 11f + lwz r9,4(r12) /* get RELA pointer in r9 */ + b 12f +11:addis r8,r8,(-RELACOUNT)@ha + cmpwi r8,[EMAIL PROTECTED] + bne 12f + lwz r0,4(r12) /* get RELACOUNT value in r0 */ +12:addir12,r12,8 + b 9b + + /* The relocation section contains a list of relocations. +* We now do the R_PPC_RELATIVE ones, which point to words +* which need to be initialized with addend + offset. +* The R_PPC_RELATIVE ones come first and there are RELACOUNT +* of them. */ +10:or. r8,r0,r9/* skip relocation if we don't have both */ beq 3f - srwi. r8,r8,2 - mtctr r8 - add r9,r0,r9 -2: lwz r8,0(r9) - add r8,r8,r0 - stw r8,0(r9) - addir9,r9,4 + mtctr r0 +2: lbz r0,4+3(r9) /* ELF32_R_INFO(reloc-r_info) */ + cmpwi r0,22 /* R_PPC_RELATIVE */ + bne 3f + lwz r12,0(r9)
