* Re: [PATCH] ppc: Merge tlb.h
From: Benjamin Herrenschmidt @ 2005-09-08 23:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.61.0509081611230.5055@nylon.am.freescale.net>
On Thu, 2005-09-08 at 16:11 -0500, Kumar Gala wrote:
> Merged tlb.h between asm-ppc32 and asm-ppc64 into asm-powerpc. Also, fixed
> a compiler warning in arch/ppc/mm/tlb.c since it was roughly related.
>
> Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
Do we want to do that ?
Replacing 2 different files with one split in #ifdef isn't a progress...
As I said, I think we need two subdirs for the low level stuffs that is
different, and that includes at this point all of the memory management
related stuff.
In addition, I'd appreciate if we could avoid touching ppc64 mm related
files completely for a couple of weeks as I'm working on a fairly big
patch that I'm really tired of having to rebase all the time ;)
Ben.
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Arnd Bergmann @ 2005-09-08 22:36 UTC (permalink / raw)
To: linuxppc64-dev; +Cc: linuxppc-dev, linuxppc-embedded, pantelis.antoniou
In-Reply-To: <39A39EEE-E3B1-4D34-BC6E-854C3EF56C7D@freescale.com>
On Freedag 09 September 2005 00:02, Kumar Gala wrote:
>
> On Sep 8, 2005, at 4:48 PM, Dan Malek wrote:
> >
> > If we #define CPU_FTR_xxx as a 0 or all 1's for processors that have
> > or don't have these features, will the compiler be smart enough to
> > recognize an always true or false condition and remove the
> > test (or code as appropriate)?
>
> The compiler is smart enough in this case since cpu_has_feature() is
> an inline function.
I actually wrote a patch that solves the problem in a very generic way,
see http://patchwork.ozlabs.org/linuxppc/patch?id=1048 .
I don't remember exactly if there were serious objections against
the patch at that time, but it looks like a much cleaner solution to me
than defining CPU_FTR_xxx to different values depending on the
configuration.
Arnd <><
^ permalink raw reply
* Re: MPC5200 Linux Init Problem
From: Frank Beesley @ 2005-09-08 22:19 UTC (permalink / raw)
To: Bob Peterson; +Cc: Jeff Angielski, linuxppc-embedded
In-Reply-To: <6.2.3.4.1.20050908091250.01eea878@mail.int.acdstar.com>
> Hi Frank,
>
> I recommend you first try to boot using tftp to get your kernel and
> nfs to get
> your root filesystem. Once that boots, you can play with MTD to make
> sure
> your flash chips have full addressability and all, and you can mount your
> jffs partition manually and look at it from the client.
>
> Also, it would be interesting to see what u-boot messages you receive at
> power-on. You may also want to do a printenv command in u-boot and
> post what your u-boot settings are.
>
> Regards,
>
> Bob Peterson
> Advanced Communication Design
>
Here is the Uboot message and env:
U-Boot 1.1.3-ppc-0_3 (Aug 31 2005 - 17:55:35)
CPU: MPC5200 v1.2 at 396
MHz
Bus 132 MHz, IPB 66 MHz, PCI 66
MHz
Board: Aeroflex-Wichita
CAI
DRAM: 128
MB
FLASH: 32
MB
Using default
environment
In:
serial
Out:
serial
Err:
serial
Autostarting. Press any key to
abort..
Hit any key to stop autoboot:
0
Eric-CAI=>
printenv
bootcmd=bootm
FA200000
bootdelay=10
baudrate=115200
preboot=echo;echo Autostarting. Press any key to
abort..;echo
bootargs=root=/dev/mtdblock2
Environment size: 144/65532 bytes
I don't have an ethernet connection on my custom board - bummer. TFTP
and NFS are out. To further explain my custom board, I have an Intel
host (running linux also) that is connected to an FPGA over the PCI bus.
The FPGA then shares the flash interface with the MPC5200. The Intel
host maps the flash using MTD drivers, writes the images, then releases
the flash to the MPC5200. At that point the MPC5200 is brought out of
reset and boots from flash. I have the flash partitioned for uboot,
kernel, rootfs, and a spare data partition. Uboot is at FA000000 (CS1
after initial assembly setup), kernel is at FA200000, rootfs is at
FA800000, spare is at FB800000.
0x00000000-0x00200000 :
"UBoot"
0x00200000-0x00800000 :
"Kernel"
0x00800000-0x01800000 :
"Rootfs"
0x01800000-0x02000000 :
"Cals"
The rootfs is crossing my CS1-CS2 boundary (FA000000, FB000000). I tried
putting my rootfs image in the cals partitions and changed my boot args
to /dev/mtdblock3. This didn't seem to change things. I believe my chip
selects are working properly - this does not rule out the MTD driver
though. I am working on a test now that tests (from uboot) the 30 MB of
flash area beyond uboot.
Any other ideas?
Frank
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Dan Malek @ 2005-09-08 22:20 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc64-dev, linuxppc-dev, linuxppc-embedded,
pantelis.antoniou
In-Reply-To: <39A39EEE-E3B1-4D34-BC6E-854C3EF56C7D@freescale.com>
On Sep 8, 2005, at 6:02 PM, Kumar Gala wrote:
> The compiler is smart enough in this case since cpu_has_feature() is
> an inline function.
I guess I didn't read Becky's comments close enough, but she did
suggest this. I was trying to eliminate the #ifdef, but I guess we will
need it some place.
Thanks.
-- Dan
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Kumar Gala @ 2005-09-08 22:02 UTC (permalink / raw)
To: Dan Malek
Cc: linuxppc64-dev, linuxppc-dev, pantelis.antoniou,
linuxppc-embedded
In-Reply-To: <f2ea45e1b2a9689c450811a61ed46183@embeddededge.com>
On Sep 8, 2005, at 4:48 PM, Dan Malek wrote:
>
> On Sep 8, 2005, at 5:20 PM, Kumar Gala wrote:
>
>
>>>> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>>>> __flush_icache_range(start, stop);
>>>> }
>>>>
>
> If we #define CPU_FTR_xxx as a 0 or all 1's for processors that have
> or don't have these features, will the compiler be smart enough to
> recognize an always true or false condition and remove the
> test (or code as appropriate)?
The compiler is smart enough in this case since cpu_has_feature() is
an inline function.
- kumar
^ permalink raw reply
* Re: r13 is non-volatile?
From: Benjamin Herrenschmidt @ 2005-09-08 21:53 UTC (permalink / raw)
To: linas; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <20050908193053.GO30028@austin.ibm.com>
> There's a different value in R13 depending on which cpu you're on,
> so one mustn't save R13 on one CPU and attempt to restore it on
> another.
>
> Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
> that instead of saving/restoring r13 like this, you could set it up
> at the same time/instead of setting up the paca r13?
ppc32 uses r2 for that, it contains "current".
I don't think we need to bother merging those low level CPU specific
things. We need to have a cpu32 and a cpu64 subdirs in there for things
like these, memory management, etc... imho.
Ben.
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Dan Malek @ 2005-09-08 21:48 UTC (permalink / raw)
To: Kumar Gala
Cc: linuxppc64-dev, linuxppc-dev, pantelis.antoniou,
linuxppc-embedded
In-Reply-To: <D8DEC759-EAB9-457F-AF7B-A10D6593B27A@freescale.com>
On Sep 8, 2005, at 5:20 PM, Kumar Gala wrote:
>>> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>>> __flush_icache_range(start, stop);
>>> }
If we #define CPU_FTR_xxx as a 0 or all 1's for processors that have
or don't have these features, will the compiler be smart enough to
recognize an always true or false condition and remove the
test (or code as appropriate)?
Thanks.
-- Dan
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Kumar Gala @ 2005-09-08 21:20 UTC (permalink / raw)
To: pantelis.antoniou; +Cc: linuxppc64-dev, linuxppc-dev, linuxppc-embedded
In-Reply-To: <200509090008.39692.pantelis.antoniou@gmail.com>
On Sep 8, 2005, at 4:08 PM, Pantelis Antoniou wrote:
> On Friday 09 September 2005 00:02, Becky Bruce wrote:
>
>> So,
>>
>> in include/asm-ppc64/cacheflush.h is the following:
>>
>> static inline void flush_icache_range(unsigned long start, unsigned
>> long stop)
>> {
>> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
>> __flush_icache_range(start, stop);
>> }
>>
>> On the 32-bit side, we don't need the feature test -
>> CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has
>> bits set
>> in the upper 32.
>>
>>
>
> Oh yes we need it. 8xx is non coherent.
I think she lost the I in ICACHE... its a power5 only feature at this
point.
- kumar
^ permalink raw reply
* [PATCH] ppc: Merge tlb.h
From: Kumar Gala @ 2005-09-08 21:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel, linuxppc64-dev
Merged tlb.h between asm-ppc32 and asm-ppc64 into asm-powerpc. Also, fixed
a compiler warning in arch/ppc/mm/tlb.c since it was roughly related.
Signed-off-by: Kumar K. Gala <kumar.gala@freescale.com>
---
commit c5f0c343d08ad9c6862c1755e7b2239f31a2a633
tree c80721ace951bc55b14a8f2a3bf69599bca2e8e9
parent cebb2b156319990fc2fba615bbfeac81be62a86a
author Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 16:09:42 -0500
committer Kumar K. Gala <kumar.gala@freescale.com> Thu, 08 Sep 2005 16:09:42 -0500
arch/ppc/mm/tlb.c | 1 +
include/asm-powerpc/tlb.h | 50 +++++++++++++++++++++++++++++++++++++++
include/asm-ppc/tlb.h | 57 ---------------------------------------------
include/asm-ppc64/tlb.h | 39 -------------------------------
4 files changed, 51 insertions(+), 96 deletions(-)
diff --git a/arch/ppc/mm/tlb.c b/arch/ppc/mm/tlb.c
--- a/arch/ppc/mm/tlb.c
+++ b/arch/ppc/mm/tlb.c
@@ -28,6 +28,7 @@
#include <linux/mm.h>
#include <linux/init.h>
#include <linux/highmem.h>
+#include <linux/pagemap.h>
#include <asm/tlbflush.h>
#include <asm/tlb.h>
diff --git a/include/asm-powerpc/tlb.h b/include/asm-powerpc/tlb.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/tlb.h
@@ -0,0 +1,50 @@
+#ifndef _ASM_POWERPC_TLB_H
+#define _ASM_POWERPC_TLB_H
+
+#include <asm/tlbflush.h>
+#include <asm/page.h>
+
+/* Nothing needed here in fact... */
+#define tlb_start_vma(tlb, vma) do { } while (0)
+#define tlb_end_vma(tlb, vma) do { } while (0)
+
+/* Avoid pulling in another include just for this */
+#define check_pgt_cache() do { } while (0)
+
+#if defined(CONFIG_PPC64)
+struct mmu_gather;
+
+extern void pte_free_finish(void);
+
+#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
+static inline void tlb_flush(struct mmu_gather *tlb)
+{
+ flush_tlb_pending();
+ pte_free_finish();
+}
+#elif defined(CONFIG_PPC_STD_MMU)
+/* Classic PPC with hash-table based MMU... */
+
+struct mmu_gather;
+extern void tlb_flush(struct mmu_gather *tlb);
+extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
+ unsigned long address);
+#else
+/* Embedded PPC with software-loaded TLB, very simple... */
+
+#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
+#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
+#endif /* CONFIG_PPC64 */
+
+/* Get the generic bits... */
+#include <asm-generic/tlb.h>
+
+#ifdef CONFIG_PPC_STD_MMU
+static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep,
+ unsigned long address)
+{
+ if (pte_val(*ptep) & _PAGE_HASHPTE)
+ flush_hash_entry(tlb->mm, ptep, address);
+}
+#endif /* CONFIG_PPC_STD_MMU */
+#endif /* _ASM_POWERPC_TLB_H */
diff --git a/include/asm-ppc/tlb.h b/include/asm-ppc/tlb.h
deleted file mode 100644
--- a/include/asm-ppc/tlb.h
+++ /dev/null
@@ -1,57 +0,0 @@
-/*
- * TLB shootdown specifics for PPC
- *
- * Copyright (C) 2002 Paul Mackerras, IBM Corp.
- *
- * 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; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _PPC_TLB_H
-#define _PPC_TLB_H
-
-#include <linux/config.h>
-#include <asm/pgtable.h>
-#include <asm/pgalloc.h>
-#include <asm/tlbflush.h>
-#include <asm/page.h>
-#include <asm/mmu.h>
-
-#ifdef CONFIG_PPC_STD_MMU
-/* Classic PPC with hash-table based MMU... */
-
-struct mmu_gather;
-extern void tlb_flush(struct mmu_gather *tlb);
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-/* Nothing needed here in fact... */
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
-extern void flush_hash_entry(struct mm_struct *mm, pte_t *ptep,
- unsigned long address);
-
-static inline void __tlb_remove_tlb_entry(struct mmu_gather *tlb, pte_t *ptep,
- unsigned long address)
-{
- if (pte_val(*ptep) & _PAGE_HASHPTE)
- flush_hash_entry(tlb->mm, ptep, address);
-}
-
-#else
-/* Embedded PPC with software-loaded TLB, very simple... */
-
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
-#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-#endif /* CONFIG_PPC_STD_MMU */
-
-#endif /* __PPC_TLB_H */
diff --git a/include/asm-ppc64/tlb.h b/include/asm-ppc64/tlb.h
deleted file mode 100644
--- a/include/asm-ppc64/tlb.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/*
- * TLB shootdown specifics for PPC64
- *
- * Copyright (C) 2002 Anton Blanchard, IBM Corp.
- * Copyright (C) 2002 Paul Mackerras, IBM Corp.
- *
- * 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; either version
- * 2 of the License, or (at your option) any later version.
- */
-#ifndef _PPC64_TLB_H
-#define _PPC64_TLB_H
-
-#include <asm/tlbflush.h>
-
-struct mmu_gather;
-
-extern void pte_free_finish(void);
-
-static inline void tlb_flush(struct mmu_gather *tlb)
-{
- flush_tlb_pending();
- pte_free_finish();
-}
-
-/* Avoid pulling in another include just for this */
-#define check_pgt_cache() do { } while (0)
-
-/* Get the generic bits... */
-#include <asm-generic/tlb.h>
-
-/* Nothing needed here in fact... */
-#define tlb_start_vma(tlb, vma) do { } while (0)
-#define tlb_end_vma(tlb, vma) do { } while (0)
-
-#define __tlb_remove_tlb_entry(tlb, pte, address) do { } while (0)
-
-#endif /* _PPC64_TLB_H */
^ permalink raw reply
* Re: cpu features testing 32 vs 64 bit
From: Pantelis Antoniou @ 2005-09-08 21:08 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <1729b6f2a199a759c4daeadd3ddcdc4a@freescale.com>
On Friday 09 September 2005 00:02, Becky Bruce wrote:
> So,
>
> in include/asm-ppc64/cacheflush.h is the following:
>
> static inline void flush_icache_range(unsigned long start, unsigned
> long stop)
> {
> if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> __flush_icache_range(start, stop);
> }
>
> On the 32-bit side, we don't need the feature test -
> CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
> in the upper 32.
>
Oh yes we need it. 8xx is non coherent.
> There's a couple of ways to deal with merging this:
>
> 1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
> test
> 2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
> when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
> always fail for 32-bit.
>
> I'd like to get some opinions on this. Do folks feel like the
> performance hit of doing the compare is enough to justify going with
> method 1? Should we be using likely/unlikely with the feature test?
>
> This is just one code example - I suspect there will be others as we
> continue the merge, and the importance of performance may differ
> depending on where in the code we are.
>
> Thanks!
> -B
>
Regards
Pantelis
^ permalink raw reply
* cpu features testing 32 vs 64 bit
From: Becky Bruce @ 2005-09-08 21:02 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-embedded, linuxppc-dev
So,
in include/asm-ppc64/cacheflush.h is the following:
static inline void flush_icache_range(unsigned long start, unsigned
long stop)
{
if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
__flush_icache_range(start, stop);
}
On the 32-bit side, we don't need the feature test -
CPU_FTR_COHERENT_CACHE is only defined in 64-bit land, and has bits set
in the upper 32.
There's a couple of ways to deal with merging this:
1) The ever-so-popular #ifdef __powerpc64__around the cpu_has_feature
test
2) No ifdef in the code itself, but #define CPU_FTR_WHATEVER to be 0
when !__powerpc64__ in cputable.h so that the cpu_has_feature test will
always fail for 32-bit.
I'd like to get some opinions on this. Do folks feel like the
performance hit of doing the compare is enough to justify going with
method 1? Should we be using likely/unlikely with the feature test?
This is just one code example - I suspect there will be others as we
continue the merge, and the importance of performance may differ
depending on where in the code we are.
Thanks!
-B
^ permalink raw reply
* Re: RFC: merging of cputables between ppc32/64
From: will schmidt @ 2005-09-08 20:43 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, ppc64-dev
In-Reply-To: <268E83D3-853C-4752-88D1-A7354E924C07@freescale.com>
Kumar Gala wrote:
> I was hoping to get some idea on which direction we wanted to head with
> cputable between ppc32/64. The only major difference that exists
> between the two is the use of cpu_setup().
>
> On ppc32, cpu_setup is called for each processor in an SMP
> configuration. Which gives us the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct
> cpu_spec* spec);
>
> On ppc64, cpu_setup is only called for the boot cpu. It is left to the
Yeah, at the time, we figured all cpu's in a system would be the same.
with the merge of 32/64, is this still going to be the case?
> cpu save/restore functions to handle setting up the state for
> additional CPUs. Which gives is the following signature:
>
> typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec* spec);
>
> So my question is do we just extend the ppc64 signature to match the
> ppc32 by having a dummy "int cpu_nr" that is ignored or do we do
> something else? As far as I can tell cpu_nr is only used by ppc32 as
> temp storage so that the cpu_setup functions can return properly.
If cpu_nr is just used as temp storage, then can it be removed and
replaced with a local variable?
>
> - kumar
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
^ permalink raw reply
* Re: [PATCH] ppc: Moved ASM_CONST macro into ppc_asm.h
From: Kumar Gala @ 2005-09-08 20:32 UTC (permalink / raw)
To: Gala Kumar K.-galak; +Cc: linuxppc-dev, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.61.0509071354270.31849@nylon.am.freescale.net>
Well, this patch breaks thinks since ppc_asm.h really needs a hugh
__ASSEMBLY__ protection for most of it.
I'll send an updated patch that also moves ppc_asm.h into include/asm-
powerpc once we close on the non-volatile issue with r13 between
ppc32/64.
- kumar
On Sep 7, 2005, at 1:55 PM, Gala Kumar K.-galak wrote:
> Moved the ASM_CONST macro into ppc_asm for ppc32 and ppc64 since that
> seems like a much better place for it long term. Also, by adding the
> macro to ppc32 it will ease some future merging of code into
> arch/powerpc.
>
> Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
>
> ---
> commit f56255eddd631902e3835bf7cdd8d94e69799097
> tree 82c222d64fdccbaed25e302816fd4cf6237e8d56
> parent 71c22e7cc4bf30119761b60b26c498d7b9d33e36
> author Kumar K. Gala <kumar.gala@freescale.com> Wed, 07 Sep 2005
> 13:53:35 -0500
> committer Kumar K. Gala <kumar.gala@freescale.com> Wed, 07 Sep 2005
> 13:53:35 -0500
>
> include/asm-ppc/ppc_asm.h | 12 ++++++++++++
> include/asm-ppc64/cputable.h | 2 +-
> include/asm-ppc64/mmu.h | 1 +
> include/asm-ppc64/page.h | 8 +-------
> include/asm-ppc64/ppc_asm.h | 7 +++++++
> 5 files changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/include/asm-ppc/ppc_asm.h b/include/asm-ppc/ppc_asm.h
> --- a/include/asm-ppc/ppc_asm.h
> +++ b/include/asm-ppc/ppc_asm.h
> @@ -11,6 +11,9 @@
> * 2 of the License, or (at your option) any later version.
> */
>
> +#ifndef __PPC_ASM_H
> +#define __PPC_ASM_H
> +
> #include <linux/config.h>
>
> /*
> @@ -348,3 +351,12 @@ END_FTR_SECTION_IFCLR(CPU_FTR_601)
> #define N_RSYM 64
> #define N_SLINE 68
> #define N_SO 100
> +
> +#ifdef __ASSEMBLY__
> + #define ASM_CONST(x) x
> +#else
> + #define __ASM_CONST(x) x##UL
> + #define ASM_CONST(x) __ASM_CONST(x)
> +#endif
> +
> +#endif /* __PPC_ASM_H */
> diff --git a/include/asm-ppc64/cputable.h b/include/asm-ppc64/
> cputable.h
> --- a/include/asm-ppc64/cputable.h
> +++ b/include/asm-ppc64/cputable.h
> @@ -16,7 +16,7 @@
> #define __ASM_PPC_CPUTABLE_H
>
> #include <linux/config.h>
> -#include <asm/page.h> /* for ASM_CONST */
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
>
> /* Exposed to userland CPU features - Must match ppc32 definitions */
> #define PPC_FEATURE_32 0x80000000
> diff --git a/include/asm-ppc64/mmu.h b/include/asm-ppc64/mmu.h
> --- a/include/asm-ppc64/mmu.h
> +++ b/include/asm-ppc64/mmu.h
> @@ -14,6 +14,7 @@
> #define _PPC64_MMU_H_
>
> #include <linux/config.h>
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
> #include <asm/page.h>
>
> /*
> diff --git a/include/asm-ppc64/page.h b/include/asm-ppc64/page.h
> --- a/include/asm-ppc64/page.h
> +++ b/include/asm-ppc64/page.h
> @@ -11,13 +11,7 @@
> */
>
> #include <linux/config.h>
> -
> -#ifdef __ASSEMBLY__
> - #define ASM_CONST(x) x
> -#else
> - #define __ASM_CONST(x) x##UL
> - #define ASM_CONST(x) __ASM_CONST(x)
> -#endif
> +#include <asm/ppc_asm.h> /* for ASM_CONST */
>
> /* PAGE_SHIFT determines the page size */
> #define PAGE_SHIFT 12
> diff --git a/include/asm-ppc64/ppc_asm.h b/include/asm-ppc64/ppc_asm.h
> --- a/include/asm-ppc64/ppc_asm.h
> +++ b/include/asm-ppc64/ppc_asm.h
> @@ -239,4 +239,11 @@
> #define vr30 30
> #define vr31 31
>
> +#ifdef __ASSEMBLY__
> + #define ASM_CONST(x) x
> +#else
> + #define __ASM_CONST(x) x##UL
> + #define ASM_CONST(x) __ASM_CONST(x)
> +#endif
> +
> #endif /* _PPC64_PPC_ASM_H */
> _______________________________________________
> Linuxppc64-dev mailing list
> Linuxppc64-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc64-dev
>
^ permalink raw reply
* Re: [PATCH] add big endian version of ld_/st_ IO access macros and convert main 8xx code to use it
From: Marcelo Tosatti @ 2005-09-08 19:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linux-ppc-embedded
In-Reply-To: <17183.48543.616634.628331@cargo.ozlabs.ibm.com>
On Thu, Sep 08, 2005 at 02:27:11PM +1000, Paul Mackerras wrote:
> Marcelo Tosatti writes:
>
> > eieio/isync are not required. There's no need to execute redudant
> > instructions and occupy kernel space.
>
> Given how long it takes to access I/O devices, I don't believe an
> extra instruction or two is going to make a measurable difference.
> Feel free to show me measurements proving me wrong, of course... :)
I will try to measure it later on and change out_/in_ macros as
suggested.
For now are there any objections against this? Otherwise I'll merge it.
There are a few more places which need conversion, plan to change them
later on also.
Thanks everyone.
diff --git a/arch/ppc/8xx_io/commproc.c b/arch/ppc/8xx_io/commproc.c
--- a/arch/ppc/8xx_io/commproc.c
+++ b/arch/ppc/8xx_io/commproc.c
@@ -73,7 +73,7 @@ cpm_mask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr &= ~(1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) & ~(1 << cpm_vec));
}
static void
@@ -81,7 +81,7 @@ cpm_unmask_irq(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr |= (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr) | (1 << cpm_vec));
}
static void
@@ -95,7 +95,7 @@ cpm_eoi(unsigned int irq)
{
int cpm_vec = irq - CPM_IRQ_OFFSET;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr = (1 << cpm_vec);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cisr, (1 << cpm_vec));
}
struct hw_interrupt_type cpm_pic = {
@@ -133,7 +133,7 @@ m8xx_cpm_reset(void)
* manual recommends it.
* Bit 25, FAM can also be set to use FEC aggressive mode (860T).
*/
- imp->im_siu_conf.sc_sdcr = 1;
+ out_be32(&imp->im_siu_conf.sc_sdcr, 1),
/* Reclaim the DP memory for our use. */
m8xx_cpm_dpinit();
@@ -178,10 +178,10 @@ cpm_interrupt_init(void)
/* Initialize the CPM interrupt controller.
*/
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr =
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr,
(CICR_SCD_SCC4 | CICR_SCC_SCC3 | CICR_SCB_SCC2 | CICR_SCA_SCC1) |
- ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK;
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr = 0;
+ ((CPM_INTERRUPT/2) << 13) | CICR_HP_MASK);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cimr, 0);
/* install the CPM interrupt controller routines for the CPM
* interrupt vectors
@@ -198,7 +198,7 @@ cpm_interrupt_init(void)
if (setup_irq(CPM_IRQ_OFFSET + CPMVEC_ERROR, &cpm_error_irqaction))
panic("Could not allocate CPM error IRQ!");
- ((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr |= CICR_IEN;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr, in_be32(&((immap_t *)IMAP_ADDR)->im_cpic.cpic_cicr) | CICR_IEN);
}
/*
@@ -212,8 +212,8 @@ cpm_get_irq(struct pt_regs *regs)
/* Get the vector by setting the ACK bit and then reading
* the register.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr = 1;
- cpm_vec = ((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr;
+ out_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr, 1);
+ cpm_vec = in_be16(&((volatile immap_t *)IMAP_ADDR)->im_cpic.cpic_civr);
cpm_vec >>= 11;
return cpm_vec;
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -144,12 +144,12 @@ void __init m8xx_calibrate_decr(void)
int freq, fp, divisor;
/* Unlock the SCCR. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrstk.cark_sccrk, KAPWR_KEY);
/* Force all 8xx processors to use divide by 16 processor clock. */
- ((volatile immap_t *)IMAP_ADDR)->im_clkrst.car_sccr |= 0x02000000;
-
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr,
+ in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_sccr)|0x02000000);
/* Processor frequency is MHz.
* The value 'fp' is the number of decrementer ticks per second.
*/
@@ -175,28 +175,24 @@ void __init m8xx_calibrate_decr(void)
* we guarantee the registers are locked, then we unlock them
* for our use.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = ~KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk = KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, ~KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbscrk, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtcsck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_tbk, KAPWR_KEY);
/* Disable the RTC one second and alarm interrupts. */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc &=
- ~(RTCSC_SIE | RTCSC_ALE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) & ~(RTCSC_SIE | RTCSC_ALE));
/* Enable the RTC */
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc |=
- (RTCSC_RTF | RTCSC_RTE);
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc, in_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtcsc) | (RTCSC_RTF | RTCSC_RTE));
/* Enabling the decrementer also enables the timebase interrupts
* (or from the other point of view, to get decrementer interrupts
* we have to enable the timebase). The decrementer interrupt
* is wired into the vector table, nothing to do here for that.
*/
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_tbscr =
- ((mk_int_int_mask(DEC_INTERRUPT) << 8) |
- (TBSCR_TBF | TBSCR_TBE));
+ out_be16(&((immap_t *)IMAP_ADDR)->im_sit.sit_tbscr, (mk_int_int_mask(DEC_INTERRUPT) << 8) | (TBSCR_TBF | TBSCR_TBE));
if (setup_irq(DEC_INTERRUPT, &tbint_irqaction))
panic("Could not allocate timer IRQ!");
@@ -216,9 +212,9 @@ void __init m8xx_calibrate_decr(void)
static int
m8xx_set_rtc_time(unsigned long time)
{
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = KAPWR_KEY;
- ((volatile immap_t *)IMAP_ADDR)->im_sit.sit_rtc = time;
- ((volatile immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck = ~KAPWR_KEY;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, KAPWR_KEY);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc, time);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_sitk.sitk_rtck, ~KAPWR_KEY);
return(0);
}
@@ -226,7 +222,7 @@ static unsigned long
m8xx_get_rtc_time(void)
{
/* Get time from the RTC. */
- return((unsigned long)(((immap_t *)IMAP_ADDR)->im_sit.sit_rtc));
+ return (unsigned long) in_be32(&((immap_t *)IMAP_ADDR)->im_sit.sit_rtc);
}
static void
@@ -235,13 +231,13 @@ m8xx_restart(char *cmd)
__volatile__ unsigned char dummy;
local_irq_disable();
- ((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr |= 0x00000080;
+ out_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr, in_be32(&((immap_t *)IMAP_ADDR)->im_clkrst.car_plprcr) | 0x00000080);
/* Clear the ME bit in MSR to cause checkstop on machine check
*/
mtmsr(mfmsr() & ~0x1000);
- dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
+ dummy = in_8(&((immap_t *)IMAP_ADDR)->im_clkrst.res[0]);
printk("Restart failed\n");
while(1);
}
@@ -306,8 +302,7 @@ m8xx_init_IRQ(void)
i8259_init(0);
/* The i8259 cascade interrupt must be level sensitive. */
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel &=
- ~(0x80000000 >> ISA_BRIDGE_INT);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel, in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_siel & ~(0x80000000 >> ISA_BRIDGE_INT)));
if (setup_irq(ISA_BRIDGE_INT, &mbx_i8259_irqaction))
enable_irq(ISA_BRIDGE_INT);
diff --git a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
--- a/arch/ppc/syslib/m8xx_wdt.c
+++ b/arch/ppc/syslib/m8xx_wdt.c
@@ -29,8 +29,8 @@ void m8xx_wdt_reset(void)
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
- imap->im_siu_conf.sc_swsr = 0x556c; /* write magic1 */
- imap->im_siu_conf.sc_swsr = 0xaa39; /* write magic2 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0x556c); /* write magic1 */
+ out_be16(imap->im_siu_conf.sc_swsr, 0xaa39); /* write magic2 */
}
static irqreturn_t m8xx_wdt_interrupt(int irq, void *dev, struct pt_regs *regs)
@@ -39,7 +39,7 @@ static irqreturn_t m8xx_wdt_interrupt(in
m8xx_wdt_reset();
- imap->im_sit.sit_piscr |= PISCR_PS; /* clear irq */
+ out_be16(imap->im_sit.sit_piscr, in_be16(imap->im_sit.sit_piscr | PISCR_PS)); /* clear irq */
return IRQ_HANDLED;
}
@@ -51,7 +51,7 @@ void __init m8xx_wdt_handler_install(bd_
u32 sypcr;
u32 pitrtclk;
- sypcr = imap->im_siu_conf.sc_sypcr;
+ sypcr = in_be32(imap->im_siu_conf.sc_sypcr);
irch/ppc/syslib/ppc8xx_pic.c:32:f (!(sypcr & 0x04)) {
printk(KERN_NOTICE "m8xx_wdt: wdt disabled (SYPCR: 0x%08X)\n",
@@ -87,9 +87,9 @@ void __init m8xx_wdt_handler_install(bd_
else
pitc = pitrtclk * wdt_timeout / binfo->bi_intfreq / 2;
- imap->im_sit.sit_pitc = pitc << 16;
- imap->im_sit.sit_piscr =
- (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE;
+ out_be32(imap->im_sit.sit_pitc, pitc << 16);
+
+ out_be16(imap->im_sit.sit_piscr, (mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE);
if (setup_irq(PIT_INTERRUPT, &m8xx_wdt_irqaction))
panic("m8xx_wdt: error setting up the watchdog irq!");
diff --git a/arch/ppc/syslib/ppc8xx_pic.c b/arch/ppc/syslib/ppc8xx_pic.c
--- a/arch/ppc/syslib/ppc8xx_pic.c
+++ b/arch/ppc/syslib/ppc8xx_pic.c
@@ -6,6 +6,7 @@
#include <linux/signal.h>
#include <linux/interrupt.h>
#include <asm/irq.h>
+#include <asm/io.h>
#include <asm/8xx_immap.h>
#include <asm/mpc8xx.h>
#include "ppc8xx_pic.h"
@@ -29,8 +30,7 @@ static void m8xx_mask_irq(unsigned int i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_unmask_irq(unsigned int irq_nr)
@@ -41,8 +41,7 @@ static void m8xx_unmask_irq(unsigned int
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
static void m8xx_end_irq(unsigned int irq_nr)
@@ -55,8 +54,7 @@ static void m8xx_end_irq(unsigned int ir
word = irq_nr >> 5;
ppc_cached_irq_mask[word] |= (1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
}
}
@@ -69,9 +67,8 @@ static void m8xx_mask_and_ack(unsigned i
word = irq_nr >> 5;
ppc_cached_irq_mask[word] &= ~(1 << (31-bit));
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask =
- ppc_cached_irq_mask[word];
- ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend = 1 << (31-bit);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_simask, ppc_cached_irq_mask[word]);
+ out_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sipend, 1 << (31-bit));
}
struct hw_interrupt_type ppc8xx_pic = {
@@ -93,7 +90,7 @@ m8xx_get_irq(struct pt_regs *regs)
/* For MPC8xx, read the SIVEC register and shift the bits down
* to get the irq number.
*/
- irq = ((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec >> 26;
+ irq = in_be32(&((immap_t *)IMAP_ADDR)->im_siu_conf.sc_sivec) >> 26;
/*
* When we read the sivec without an interrupt to process, we will
^ permalink raw reply
* Re: r13 is non-volatile?
From: linas @ 2005-09-08 19:30 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <ac556638e1f4b4f9786c30ed0debc4a8@kernel.crashing.org>
On Thu, Sep 08, 2005 at 07:01:18PM +0200, Segher Boessenkool was heard to remark:
> >Was looking at merging some code between ppc32 & ppc64 and noticed
> >that in ppc32 we consider r13 to be part of the non-volatile register
> >set. Is this really correct?
>
> >r13 is suppose to be sdata pointer in ppc32
>
> sdata pointer is non-volatile by definition...
>
> >and system thread id in ppc64.
>
> The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
> it specially
There's a different value in R13 depending on which cpu you're on,
so one mustn't save R13 on one CPU and attempt to restore it on
another.
Maybe, for ppc32, you can pretend that r13 "is like a paca"? So
that instead of saving/restoring r13 like this, you could set it up
at the same time/instead of setting up the paca r13?
--linas
^ permalink raw reply
* PATCH Fix __power64__ typos that should be __powerpc64__
From: jdl @ 2005-09-08 19:05 UTC (permalink / raw)
To: linuxppc-dev, linuxppc64-dev
Fix __power64__ typo that should be __powerpc64__ instead.
include/asm-powerpc/shmbuf.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
diff --git a/include/asm-powerpc/shmbuf.h b/include/asm-powerpc/shmbuf.h
--- a/include/asm-powerpc/shmbuf.h
+++ b/include/asm-powerpc/shmbuf.h
@@ -21,19 +21,19 @@
struct shmid64_ds {
struct ipc64_perm shm_perm; /* operation perms */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused1;
#endif
__kernel_time_t shm_atime; /* last attach time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused2;
#endif
__kernel_time_t shm_dtime; /* last detach time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused3;
#endif
__kernel_time_t shm_ctime; /* last change time */
-#ifndef __power64__
+#ifndef __powerpc64__
unsigned long __unused4;
#endif
size_t shm_segsz; /* size of segment (bytes) */
^ permalink raw reply
* RFC: merging of cputables between ppc32/64
From: Kumar Gala @ 2005-09-08 18:42 UTC (permalink / raw)
To: linuxppc-dev list, ppc64-dev
I was hoping to get some idea on which direction we wanted to head
with cputable between ppc32/64. The only major difference that
exists between the two is the use of cpu_setup().
On ppc32, cpu_setup is called for each processor in an SMP
configuration. Which gives us the following signature:
typedef void (*cpu_setup_t)(unsigned long offset, int cpu_nr, struct
cpu_spec* spec);
On ppc64, cpu_setup is only called for the boot cpu. It is left to
the cpu save/restore functions to handle setting up the state for
additional CPUs. Which gives is the following signature:
typedef void (*cpu_setup_t)(unsigned long offset, struct cpu_spec*
spec);
So my question is do we just extend the ppc64 signature to match the
ppc32 by having a dummy "int cpu_nr" that is ignored or do we do
something else? As far as I can tell cpu_nr is only used by ppc32 as
temp storage so that the cpu_setup functions can return properly.
- kumar
^ permalink raw reply
* can we kill CONFIG_PPC64BRIDGE?
From: Kumar Gala @ 2005-09-08 18:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, ppc64-dev
Paul,
Can we kill CONFIG_PPC64BRIDGE for ppc32... Not sure if anyone is
using this or not?
- kumar
^ permalink raw reply
* Re: r13 is non-volatile?
From: Segher Boessenkool @ 2005-09-08 17:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc64-dev, linuxppc-dev list
In-Reply-To: <0C620F0B-92B0-4EBF-BC0C-49FD4D3D4323@freescale.com>
> Was looking at merging some code between ppc32 & ppc64 and noticed
> that in ppc32 we consider r13 to be part of the non-volatile register
> set. Is this really correct?
I believe so, yes.
> r13 is suppose to be sdata pointer in ppc32
sdata pointer is non-volatile by definition...
> and system thread id in ppc64.
The 64-bit kernel uses GPR13 as the PACA pointer, so it handles
it specially -- it treats the userland values of the register
as non-volatile, though.
> So I'm wondering should we really be considering it NV on ppc32?
Yeah. I'm sure there is some way to make the macro's identical
between 32- and 64-bit, though.
Segher
^ permalink raw reply
* r13 is non-volatile?
From: Kumar Gala @ 2005-09-08 16:28 UTC (permalink / raw)
To: linuxppc-dev list, ppc64-dev
Was looking at merging some code between ppc32 & ppc64 and noticed
that in ppc32 we consider r13 to be part of the non-volatile register
set. Is this really correct?
r13 is suppose to be sdata pointer in ppc32 and system thread id in
ppc64. So I'm wondering should we really be considering it NV on ppc32?
PPC32:
#define SAVE_NVGPRS(base) SAVE_GPR(13, base); SAVE_8GPRS(14,
base); \
SAVE_10GPRS(22, base)
#define REST_NVGPRS(base) REST_GPR(13, base); REST_8GPRS(14,
base); \
REST_10GPRS(22, base)
PPC64:
#define SAVE_NVGPRS(base) SAVE_8GPRS(14, base); SAVE_10GPRS(22,
base)
#define REST_NVGPRS(base) REST_8GPRS(14, base); REST_10GPRS(22,
base)
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: add CONFIG_HZ
From: Dan Malek @ 2005-09-08 15:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: Andrew Morton, linuxppc-dev, Gala Kumar K.-galak, Tom Rini
In-Reply-To: <5B4F5836-F3E6-4511-BD4C-9388BBA715E0@freescale.com>
On Sep 8, 2005, at 10:11 AM, Kumar Gala wrote:
> Idea's on how to solve this are welcome.
Just create the appropriate defconfigs with this clock
frequency and check them in.
Thanks.
-- Dan
^ permalink raw reply
* [PATCH 2.6.13] ppc32: Kill PVR_440* defines
From: Tom Rini @ 2005-09-08 15:14 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
The following patch changes the usages of PVR_440* into strcmp's with
the cpu_name field, and removes the defines altogether. The Ebony
portion was briefly tested long ago. One benefit of moving from
PVR-tests to string tests in general is that not all CPUs can be
differentiated by PVR type, but we could otherwise know which one we're
on and be able to do this type of comparison.
See http://patchwork.ozlabs.org/linuxppc/patch?id=1250 for the original
thread.
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/platforms/4xx/ebony.c
===================================================================
--- linux-2.6.orig/arch/ppc/platforms/4xx/ebony.c
+++ linux-2.6/arch/ppc/platforms/4xx/ebony.c
@@ -91,15 +91,10 @@ ebony_calibrate_decr(void)
* on Rev. C silicon then errata forces us to
* use the internal clock.
*/
- switch (PVR_REV(mfspr(SPRN_PVR))) {
- case PVR_REV(PVR_440GP_RB):
- freq = EBONY_440GP_RB_SYSCLK;
- break;
- case PVR_REV(PVR_440GP_RC1):
- default:
- freq = EBONY_440GP_RC_SYSCLK;
- break;
- }
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GP Rev. B") == 0)
+ freq = EBONY_440GP_RB_SYSCLK;
+ else
+ freq = EBONY_440GP_RC_SYSCLK;
ibm44x_calibrate_decr(freq);
}
Index: linux-2.6/arch/ppc/syslib/ibm440gx_common.c
===================================================================
--- linux-2.6.orig/arch/ppc/syslib/ibm440gx_common.c
+++ linux-2.6/arch/ppc/syslib/ibm440gx_common.c
@@ -236,9 +236,10 @@ void __init ibm440gx_l2c_setup(struct ib
/* Disable L2C on rev.A, rev.B and 800MHz version of rev.C,
enable it on all other revisions
*/
- u32 pvr = mfspr(SPRN_PVR);
- if (pvr == PVR_440GX_RA || pvr == PVR_440GX_RB ||
- (pvr == PVR_440GX_RC && p->cpu > 667000000))
+ if (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. A") == 0 ||
+ strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. B") == 0
+ || (strcmp(cur_cpu_spec[0]->cpu_name, "440GX Rev. C")
+ == 0 && p->cpu > 667000000))
ibm440gx_l2c_disable();
else
ibm440gx_l2c_enable();
Index: linux-2.6/include/asm-ppc/reg.h
===================================================================
--- linux-2.6.orig/include/asm-ppc/reg.h
+++ linux-2.6/include/asm-ppc/reg.h
@@ -366,12 +366,6 @@
#define PVR_STB03XXX 0x40310000
#define PVR_NP405H 0x41410000
#define PVR_NP405L 0x41610000
-#define PVR_440GP_RB 0x40120440
-#define PVR_440GP_RC1 0x40120481
-#define PVR_440GP_RC2 0x40200481
-#define PVR_440GX_RA 0x51b21850
-#define PVR_440GX_RB 0x51b21851
-#define PVR_440GX_RC 0x51b21892
#define PVR_601 0x00010000
#define PVR_602 0x00050000
#define PVR_603 0x00030000
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2.6.13] ppc32: In the boot code, don't rely on BASE_BAUD directly
From: Tom Rini @ 2005-09-08 15:13 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
Modifies serial_init to get base baud rate from the rs_table entry
instead of BAUD_BASE. This patch eliminates duplication between the
SERIAL_PORT_DFNS macro and BAUD_BASE. Without the patch, if a port
set the baud rate in SERIAL_PORT_DFNS, but did not update BASE_BAUD,
the BASE_BAUD value would still be used.
Signed-off-by: Grant Likely <grant.likely@gdcanada.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/boot/common/ns16550.c
===================================================================
--- linux-2.6.orig/arch/ppc/boot/common/ns16550.c
+++ linux-2.6/arch/ppc/boot/common/ns16550.c
@@ -23,7 +23,7 @@ static int shift;
unsigned long serial_init(int chan, void *ignored)
{
- unsigned long com_port;
+ unsigned long com_port, base_baud;
unsigned char lcr, dlm;
/* We need to find out which type io we're expecting. If it's
@@ -43,6 +43,8 @@ unsigned long serial_init(int chan, void
/* How far apart the registers are. */
shift = rs_table[chan].iomem_reg_shift;
+ /* Base baud.. */
+ base_baud = rs_table[chan].baud_base;
/* save the LCR */
lcr = inb(com_port + (UART_LCR << shift));
@@ -62,9 +64,9 @@ unsigned long serial_init(int chan, void
else {
/* Input clock. */
outb(com_port + (UART_DLL << shift),
- (BASE_BAUD / SERIAL_BAUD) & 0xFF);
+ (base_baud / SERIAL_BAUD) & 0xFF);
outb(com_port + (UART_DLM << shift),
- (BASE_BAUD / SERIAL_BAUD) >> 8);
+ (base_baud / SERIAL_BAUD) >> 8);
/* 8 data, 1 stop, no parity */
outb(com_port + (UART_LCR << shift), 0x03);
/* RTS/DTR */
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [PATCH 2.6.13] ppc32: Correct an instruction in the boot code
From: Tom Rini @ 2005-09-08 15:13 UTC (permalink / raw)
To: Andrew Morton, linuxppc-embedded
In the flush and invalidate bootcode on PPC4xx we were accidentally
using the wrong instruction. Use cmplw, which reads from a register
like we want.
From: Frank van Maarseveen <frankvm@frankvm.com>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
Index: linux-2.6/arch/ppc/boot/common/util.S
===================================================================
--- linux-2.6.orig/arch/ppc/boot/common/util.S
+++ linux-2.6/arch/ppc/boot/common/util.S
@@ -252,7 +252,7 @@ _GLOBAL(flush_instruction_cache)
1: dcbf r0,r3 # Flush the data cache
icbi r0,r3 # Invalidate the instruction cache
addi r3,r3,0x10 # Increment by one cache line
- cmplwi cr0,r3,r4 # Are we at the end yet?
+ cmplw cr0,r3,r4 # Are we at the end yet?
blt 1b # No, keep flushing and invalidating
#else
/* Enable, invalidate and then disable the L1 icache/dcache. */
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: How can I compile the module into kernel
From: gqbenjamin @ 2005-09-08 14:39 UTC (permalink / raw)
To: zhonglei; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 552 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox