* Re: [PATCH v4] powerpc: update crypto node definition and device tree instances
From: Kumar Gala @ 2008-07-09 13:08 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20080708191333.9eb5310a.kim.phillips@freescale.com>
On Jul 8, 2008, at 7:13 PM, Kim Phillips wrote:
> delete obsolete device-type property, delete model property
> (use compatible property instead), prepend "fsl," to Freescale
> specific properties. Add nodes to device trees that are missing them,
> and fix broken property values in other trees.
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> changes from v3: sec.txt in new place following Kumar's latest
> preference, cleaned up interrupt description and removed
> interrupt-parent in documentation.
applied.
I fixed mpc832x_rdb.dts and mpc8536ds.dts as there were minor issues
related to the interrupt props in those nodes.
- k
^ permalink raw reply
* Re: libfdt: Increase namespace-pollution paranoia
From: Jon Loeliger @ 2008-07-09 13:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev list, David Gibson
In-Reply-To: <1F3AE758-B99A-457F-A74D-6D12DAF74115@kernel.crashing.org>
>
> > On a slightly unrelated note, are you planning to sync the in-kernel
> > dtc/libfdt version with the upstream version anytime soon?
>
> I know jon put an -rc, not sure if he plans to pick up the slew of
> patches for the next -rc or the next release, but it would be good to
> resync the in-kernel version for 2.6.27.
>
> - k
My (DTC) plan is to apply the single patch with some
include file fixes, and release that.
I'll line the slew of patches up for the following release.
jdl
^ permalink raw reply
* Please pull from 'powerpc-next' branch
From: Kumar Gala @ 2008-07-09 13:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
Please pull from 'powerpc-next' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/dts.git powerpc-next
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 1176 -------
Documentation/powerpc/dts-bindings/fsl/board.txt | 29
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt | 67
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt | 21
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt | 41
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt | 18
Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt | 15
Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt | 45
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt | 58
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt | 24
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt | 51
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt | 60
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt | 70
Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt | 22
Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt | 21
Documentation/powerpc/dts-bindings/fsl/diu.txt | 18
Documentation/powerpc/dts-bindings/fsl/dma.txt | 127
Documentation/powerpc/dts-bindings/fsl/gtm.txt | 31
Documentation/powerpc/dts-bindings/fsl/guts.txt | 25
Documentation/powerpc/dts-bindings/fsl/i2c.txt | 32
Documentation/powerpc/dts-bindings/fsl/lbc.txt | 35
Documentation/powerpc/dts-bindings/fsl/msi-pic.txt | 36
Documentation/powerpc/dts-bindings/fsl/sata.txt | 29
Documentation/powerpc/dts-bindings/fsl/sec.txt | 68
Documentation/powerpc/dts-bindings/fsl/spi.txt | 24
Documentation/powerpc/dts-bindings/fsl/ssi.txt | 38
Documentation/powerpc/dts-bindings/fsl/tsec.txt | 69
Documentation/powerpc/dts-bindings/fsl/usb.txt | 59
arch/powerpc/boot/dts/ksi8560.dts | 20
arch/powerpc/boot/dts/mpc8272ads.dts | 32
arch/powerpc/boot/dts/mpc8313erdb.dts | 15
arch/powerpc/boot/dts/mpc8315erdb.dts | 15
arch/powerpc/boot/dts/mpc832x_mds.dts | 15
arch/powerpc/boot/dts/mpc832x_rdb.dts | 15
arch/powerpc/boot/dts/mpc8349emitx.dts | 12
arch/powerpc/boot/dts/mpc8349emitxgp.dts | 12
arch/powerpc/boot/dts/mpc834x_mds.dts | 15
arch/powerpc/boot/dts/mpc836x_mds.dts | 13
arch/powerpc/boot/dts/mpc8377_mds.dts | 13
arch/powerpc/boot/dts/mpc8377_rdb.dts | 14
arch/powerpc/boot/dts/mpc8378_mds.dts | 13
arch/powerpc/boot/dts/mpc8378_rdb.dts | 14
arch/powerpc/boot/dts/mpc8379_mds.dts | 13
arch/powerpc/boot/dts/mpc8379_rdb.dts | 14
arch/powerpc/boot/dts/mpc8536ds.dts | 432 ++
arch/powerpc/boot/dts/mpc8541cds.dts | 11
arch/powerpc/boot/dts/mpc8544ds.dts | 11
arch/powerpc/boot/dts/mpc8548cds.dts | 11
arch/powerpc/boot/dts/mpc8555cds.dts | 11
arch/powerpc/boot/dts/mpc8568mds.dts | 14
arch/powerpc/boot/dts/mpc8572ds.dts | 12
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 2
arch/powerpc/boot/dts/mpc866ads.dts | 11
arch/powerpc/boot/dts/mpc885ads.dts | 11
arch/powerpc/boot/dts/sbc8349.dts | 14
arch/powerpc/boot/dts/sbc8548.dts | 11
arch/powerpc/boot/dts/tqm8541.dts | 11
arch/powerpc/boot/dts/tqm8548.dts | 5
arch/powerpc/boot/dts/tqm8555.dts | 11
arch/powerpc/configs/85xx/tqm8548_defconfig | 143
arch/powerpc/configs/mpc8536_ds_defconfig | 1637 ++++++++++
arch/powerpc/kernel/time.c | 4
arch/powerpc/platforms/82xx/Kconfig | 11
arch/powerpc/platforms/82xx/mpc8272_ads.c | 4
arch/powerpc/platforms/82xx/pq2ads-pci-pic.c | 2
arch/powerpc/platforms/83xx/Kconfig | 10
arch/powerpc/platforms/85xx/Kconfig | 6
arch/powerpc/platforms/85xx/Makefile | 1
arch/powerpc/platforms/85xx/mpc8536_ds.c | 125
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 14
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 8
arch/powerpc/platforms/86xx/Kconfig | 16
arch/powerpc/platforms/86xx/Makefile | 1
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 26
arch/powerpc/platforms/86xx/mpc86xx.h | 3
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 64
arch/powerpc/platforms/86xx/pic.c | 78
arch/powerpc/platforms/86xx/sbc8641d.c | 25
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 4
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 3
arch/powerpc/platforms/Kconfig | 33
arch/powerpc/sysdev/cpm_common.c | 3
arch/powerpc/sysdev/fsl_pci.c | 2
drivers/serial/cpm_uart/cpm_uart_core.c | 20
include/linux/pci_ids.h | 2
85 files changed, 3887 insertions(+), 1490 deletions(-)
Anton Vorontsov (1):
powerpc/86xx: mpc8610_hpcd: fix interrupt trigger type for ULi IDE
Dave Jiang (1):
powerpc/85xx: publish of device for cds platforms
Jason Jin (1):
powerpc/85xx: Minor fixes for 85xxds and 8536ds board.
Jochen Friedrich (1):
powerpc/CPM: Add i2c pins to dts and board setup
Kim Phillips (1):
powerpc/fsl: update crypto node definition and device tree instances
Kumar Gala (7):
powerpc/85xx: Fix KSI8560 .dts
powerpc/85xx: minor fixes for MPC85xx DS board port
powerpc/85xx: Add support for MPC8536DS
powerpc/86xx: Refactor pic init
powerpc/booke: don't reinitialize time base
powerpc: Add 82xx/83xx/86xx to 6xx Multiplatform
powerpc/fsl: Refactor device bindings
Laurent Pinchart (1):
cpm_uart: Support uart_wait_until_sent()
Nye Liu (1):
powerpc/CPM: Minor cosmetic changes to udbg_putc
Rune Torgersen (2):
cpm_uart: Fix cpm uart corruption with PREEMPT_RT
powerpc: Fix pq2fads irq handling with PREEMPT_RT
Wolfgang Grandegger (1):
powerpc/85xx: TQM8548: add missing support for RTC and LM75
^ permalink raw reply
* Re: [Cbe-oss-dev] [patch 02/02] powerpc/cell: add support for power button of future IBM cell blades
From: Arnd Bergmann @ 2008-07-09 13:15 UTC (permalink / raw)
To: cbe-oss-dev, benh; +Cc: Christian Krafft, Christian Krafft, linuxppc-dev
In-Reply-To: <1215574530.8970.306.camel@pasglop>
On Wednesday 09 July 2008, Benjamin Herrenschmidt wrote:
> Sorry Christian, i'm still not too happy with this one.
>=20
> There are two issues at hand here:
>=20
> =A0- The use of SELECT, that will be frowned on unfortunately.
Ok, this should be easy to fix, by making it depend on INPUT
instead, like the ACPI power button does. It's modeled after
that anyway.
> =A0- I'm not too sure it's very safe the way you do it. If I understand
> correctly, you can get called for that sysreset at -any- time, including
> when interrupts are off right ?
Yes, that sounds like a problem.
> That means potentially, code that has interrupts off will be interrupted
> by input_report/input_sync, which is really bad (may corrupt the input
> layer internal list management for example).
I can't think of a case where this can realistically hit us (the blades
don't have any other input devices normally), but of course you are
right that it's broken anyway.
> You could solve both things with a little trick: Have the platform code
> just basically set a global flag when the button was pressed and have a
> module that depends on INPUT & INPUT_DEV poll for it (slowly pls) and do
> the input report.
Ugly, but doable, yes. I wonder if there is a way that we can trigger some
interrupt from system_reset_exception context in order to get around the
polling though. tasklets and workqueues unfortunately won't do us any good
here because they also depend on disabling interrupts.
Arnd <><
^ permalink raw reply
* Re: Updates to powerpc.git
From: Josh Boyer @ 2008-07-09 13:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, Andrew Morton
In-Reply-To: <1215588881.8970.358.camel@pasglop>
On Wed, 09 Jul 2008 17:34:41 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I've pushed some updates to my version of powerpc.git.
>=20
> The tree itself is at:
>=20
> =EF=BB=BF git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>=20
> It contains 3 branches:
>=20
> - merge : this is for merging with the current stable and doesn't
> currently contain anything interesting
>=20
> - master : this is our current "powerpc.git" tree, it may contain
> various experimental stuff that may or may not go upstream
> or may contain dependent patches that we rely on but that
> are to be merged via some other tree.
>=20
> - next : this is the candidate stuff for linux-next and the next
> merge window
>=20
> (Andrew, you -may- want to pull that instead of paulus one until
> he's back from vacation).
>=20
> Until today, master and next pointed to the same commit, which was
> the same as paulus master and powerpc-next branches. Tonight, I've
> pushed some patches to master that I intend to have in next, but
> I'd like to let them sit in master for a couple of days to make sure
> nothing is badly broken mostly and make sure I didn't screw up in
> my various patch monkeying operations.
One thing to point out is that if you decide to only select a few of
those patches, you'll need to cherry-pick them into your next branch
(or rebase). That means that when you pull from Linus into your master
branch during/after the merge window, you'll get all kinds of funny
merge commits.
If you want to use your master branch as a place for experimental
stuff, that's fine by me. But you'll want to keep next separate from
it so it's as "clean" as possible for those trying to track what is
definitely going into the next release.
If it were up to me (which it's not), I would have master just track
Linus, next track what's going into the next release, and "bleeding" or
"experimental" track stuff that isn't fully vetted yet. I might start
doing that with my tree in the very near future.
Also, Paul is pretty good about not rebasing his branches when at all
possible, and I suspect that's why his master and next were often the
same. It makes life lots easier for the sub-maintainers and anyone
trying to track against the tree. I humbly beg you to keep that going.
josh
^ permalink raw reply
* Re: [PATCH 0/3] ALSA fixes for non-coherent ppc32
From: Takashi Iwai @ 2008-07-09 17:27 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20080709083111.44860@gmx.net>
At Wed, 09 Jul 2008 10:31:11 +0200,
Gerhard Pircher wrote:
>
> Hi,
>
> -------- Original-Nachricht --------
> > Datum: Wed, 18 Jun 2008 12:38:31 +0200
> > Von: Takashi Iwai <tiwai@suse.de>
> > An: benh@kernel.crashing.org
> > CC: linuxppc-dev@ozlabs.org, cjg@cruxppc.org
> > Betreff: [PATCH 0/3] ALSA fixes for non-coherent ppc32
>
> > Hi,
> >
> > I've tried to renew the fixes of ALSA issues about non-coherent DMA
> > memories. The last patch worked for SG-buffers somehow but would
> > result in a problem if many pages are allocated because of
> > dma_alloc_coherent() handling. Now, I chose a more simpler
> > workaround: the SG-buffers are handled as simple continuous buffers.
> >
> > This time I split the patches to several parts. The first patch
> > contains a very lazy dma_mmap_coherent() implementation for ppc32.
> > The next patch adds the call of dma_mmap_coherent() for the default
> > mmap of ALSA PCM. And the last one is to add the conversion of
> > SG-buffer handling as above.
> >
> > The patches are created against the latest ALSA tree, and the last
> > patch won't be applicable fully to 2.6.26-rc6. But, it's only for
> > snd-hda-intel and there is no PPC32 hardware supporting this, AFAIK.
> > So just ignore the reject.
> >
> > The patches are found also on my git tree, dma-fix branch of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >
> > Any comments and test reports are appreciated, especially about
> > dma_mmap_coherent() addition.
> I know this answer comes a little bit late, but my PPC machine was not
> working for two weeks due to a hardware failure. I tested the patch on
> 2.6.26-rc9 and it seems to work fine so far with my emu10k soundcard.
> I just had to add "#include <linux/dma-mapping.h>" to pcm_native.c.
> Otherwise it wouldn't compile.
Thanks, I fixed it now on my git tree.
Takashi
^ permalink raw reply
* Re: [PATCH 0/3] ALSA fixes for non-coherent ppc32
From: Takashi Iwai @ 2008-07-09 17:31 UTC (permalink / raw)
To: benh, Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <1215593735.8970.361.camel@pasglop>
At Wed, 09 Jul 2008 18:55:35 +1000,
Benjamin Herrenschmidt wrote:
>
> On Wed, 2008-07-09 at 10:31 +0200, Gerhard Pircher wrote:
> > >
> > > The patches are found also on my git tree, dma-fix branch of
> > >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> > >
> > > Any comments and test reports are appreciated, especially about
> > > dma_mmap_coherent() addition.
> > I know this answer comes a little bit late, but my PPC machine was not
> > working for two weeks due to a hardware failure. I tested the patch on
> > 2.6.26-rc9 and it seems to work fine so far with my emu10k soundcard.
> > I just had to add "#include <linux/dma-mapping.h>" to pcm_native.c.
> > Otherwise it wouldn't compile.
>
> Can I get the latest powerpc-side patches so I can review-ack them in
> time for the merge window ?
The changes in ppc are only the patch below. The others are in
sound/*. I wrote it as an inline function simply it's so short and I
didn't want extra exports.
thanks,
Takashi
---
commit 2c8662fde57af4cf928d17e089dc3dd2096f4b30
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Jun 17 16:39:04 2008 +0200
ppc: Add dma_mmap_coherent() for PPC32
A very lazy version of dma_mmap_coherent() implementation for ppc32.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
diff --git a/include/asm-powerpc/dma-mapping.h b/include/asm-powerpc/dma-mapping.h
index bbefb69..a6a9675 100644
--- a/include/asm-powerpc/dma-mapping.h
+++ b/include/asm-powerpc/dma-mapping.h
@@ -306,6 +306,24 @@ static inline void dma_unmap_sg(struct device *dev, struct scatterlist *sg,
/* We don't do anything here. */
}
+/*
+ * A helper to mmap the pages allocated via dma_alloc_coherent()
+ */
+static inline int dma_mmap_coherent(struct device *dev,
+ struct vm_area_struct *vma,
+ void *cpu_addr, dma_addr_t handle,
+ size_t size)
+{
+ struct page *pg;
+#ifdef CONFIG_NOT_COHERENT_CACHE
+ /* I'm too lazy and can't stop using bus_to_virt() here... */
+ cpu_addr = bus_to_virt(handle);
+#endif
+ pg = virt_to_page(cpu_addr);
+ return remap_pfn_range(vma, vma->vm_start,
+ page_to_pfn(pg) + vma->vm_pgoff,
+ size, vma->vm_page_prot);
+}
#endif /* CONFIG_PPC64 */
static inline void dma_sync_single_for_cpu(struct device *dev,
^ permalink raw reply related
* Re: Updates to powerpc.git
From: Kumar Gala @ 2008-07-09 13:40 UTC (permalink / raw)
To: Josh Boyer; +Cc: Andrew Morton, linuxppc-dev list
In-Reply-To: <20080709091846.69b08e34@zod.rchland.ibm.com>
On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
> On Wed, 09 Jul 2008 17:34:41 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
>> I've pushed some updates to my version of powerpc.git.
>>
>> The tree itself is at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>>
>> It contains 3 branches:
>>
>> - merge : this is for merging with the current stable and doesn't
>> currently contain anything interesting
>>
>> - master : this is our current "powerpc.git" tree, it may contain
>> various experimental stuff that may or may not go
>> upstream
>> or may contain dependent patches that we rely on but that
>> are to be merged via some other tree.
>>
>> - next : this is the candidate stuff for linux-next and the next
>> merge window
>>
>> (Andrew, you -may- want to pull that instead of paulus one until
>> he's back from vacation).
>>
>> Until today, master and next pointed to the same commit, which was
>> the same as paulus master and powerpc-next branches. Tonight, I've
>> pushed some patches to master that I intend to have in next, but
>> I'd like to let them sit in master for a couple of days to make sure
>> nothing is badly broken mostly and make sure I didn't screw up in
>> my various patch monkeying operations.
>
> One thing to point out is that if you decide to only select a few of
> those patches, you'll need to cherry-pick them into your next branch
> (or rebase). That means that when you pull from Linus into your master
> branch during/after the merge window, you'll get all kinds of funny
> merge commits.
>
> If you want to use your master branch as a place for experimental
> stuff, that's fine by me. But you'll want to keep next separate from
> it so it's as "clean" as possible for those trying to track what is
> definitely going into the next release.
>
> If it were up to me (which it's not), I would have master just track
> Linus, next track what's going into the next release, and "bleeding"
> or
> "experimental" track stuff that isn't fully vetted yet. I might start
> doing that with my tree in the very near future.
I do something similar, but my master is a merge of linus and my next
branch, which is roughly what I think paul did.
> Also, Paul is pretty good about not rebasing his branches when at all
> possible, and I suspect that's why his master and next were often the
> same. It makes life lots easier for the sub-maintainers and anyone
> trying to track against the tree. I humbly beg you to keep that
> going.
I agree and I'm sure linus will tell you how evil it is to rebase as a
maintainer.
- k
^ permalink raw reply
* [PATCH] powerpc: Fix problems with 32bit PPC's running with more than 2GB of RAM
From: Stefan Roese @ 2008-07-09 13:44 UTC (permalink / raw)
To: linuxppc-dev
This patch enables 32bit PPC's (with 36bit physical address space, e.g.
IBM/AMCC PPC44x) to run with more than 2GB of RAM. Mostly its just
replacing types (unsigned long -> phys_addr_t).
Tested on an AMCC Katmai with 4GB of DDR2.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/mm/init_32.c | 4 ++--
arch/powerpc/mm/mem.c | 8 ++++----
arch/powerpc/mm/mmu_decl.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 1952b4d..325ccdd 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -56,8 +56,8 @@
DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
-unsigned long total_memory;
-unsigned long total_lowmem;
+phys_addr_t total_memory;
+phys_addr_t total_lowmem;
phys_addr_t memstart_addr = (phys_addr_t)~0ull;
EXPORT_SYMBOL(memstart_addr);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 51f82d8..55ef772 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -329,7 +329,7 @@ static int __init mark_nonram_nosave(void)
void __init paging_init(void)
{
unsigned long total_ram = lmb_phys_mem_size();
- unsigned long top_of_ram = lmb_end_of_DRAM();
+ phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
#ifdef CONFIG_PPC32
@@ -348,10 +348,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
- top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
+ (u64)top_of_ram, total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (top_of_ram - total_ram) >> 20);
+ (long int)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 0480225..4e46c63 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -49,8 +49,8 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
extern phys_addr_t __initial_memory_limit_addr;
-extern unsigned long total_memory;
-extern unsigned long total_lowmem;
+extern phys_addr_t total_memory;
+extern phys_addr_t total_lowmem;
extern phys_addr_t memstart_addr;
extern phys_addr_t lowmem_end_addr;
--
1.5.6.2
^ permalink raw reply related
* Re: [RFC/PATCH] powerpc/bootwrapper: Allow user to specify additional default targets
From: Josh Boyer @ 2008-07-09 14:00 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40807070729w524aa50xb1c762f13ba31da1@mail.gmail.com>
On Mon, 7 Jul 2008 08:29:47 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On Mon, Jul 7, 2008 at 8:07 AM, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
> > On Mon, 7 Jul 2008 07:34:23 -0600 Grant Likely wrote:
> >> Specifically the case I'm thinking of is when a user of a Xilinx FPGA
> >> drops a new .dts file into arch/powerpc/boot/dts (say
> >> 'super-sexy-platform.dts'). However, instead of modifying the
> >> Makefile or always typing 'make simpleImage.super-sexy-platform', then
> >> can add 'simpleImage.super-sexy-platform' to their defconfig which I
> >> can see being easier for someone to get their head around.
> >
> > Yeah, I thought about the Virtex case with the differing bitstreams
> > after I sent out my original question. For purposes like that, this
> > seems like a great fit. For truly discrete boards, I prefer discrete
> > defconfigs.
> >
> > So overall I see value in the patch. If nobody else has objections,
> > then it's fine with me.
>
> so.... can I have an ack? :-)
Oops, sorry. Of course.
Acked-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
josh
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Josh Boyer @ 2008-07-09 14:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20080704172240.GE17062@secretlab.ca>
On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote:
> Hi Josh,
>
> Here are the bulk of the Xilinx 440 support patches. Please pull
> into your next branch.
>
> Thanks,
> g.
>
> The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a:
> Michael Neuling (1):
> powerpc: Update for VSX core file and ptrace
>
> are available in the git repository at:
>
> git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
Any chance to get that updated with the latest fixes before I pull it
in? Namely the DTS file for virtex5, but there might have been others.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Josh Boyer @ 2008-07-09 14:23 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080708055449.EDFDADDEF5@ozlabs.org>
On Tue, 08 Jul 2008 15:54:40 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> This is some preliminary work to improve TLB management on SW loaded
> TLB powerpc platforms. This introduce support for non-atomic PTE
> operations in pgtable-ppc32.h and removes write back to the PTE from
> the TLB miss handlers. In addition, the DSI interrupt code no longer
> tries to fixup write permission, this is left to generic code, and
> _PAGE_HWWRITE is gone.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Boots for me now. So far it's surviving a dbench run, and I'll try
hackbench/kernbench shortly.
I've got this queued up in my -next branch.
josh
^ permalink raw reply
* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: Grant Likely @ 2008-07-09 14:33 UTC (permalink / raw)
To: neeraj garg; +Cc: linuxppc-embedded
In-Reply-To: <48744475.2080605@cdac.in>
On Wed, Jul 09, 2008 at 10:24:13AM +0530, neeraj garg wrote:
> Hi,
>
> I am trying to boot ML405 with Linux source code downloaded from
> http://www.git.xilinx.com . My cross compiler tool chain version is
> gcc-3.4.1, glibc-2.3.2 and binutils-2.15. I have also downloaded RAMDISK
> from same url (http://www.git.xilinx.com). When I download
> zImage.initrd.elf using XMD everything goes fine, untill RAMDISK is
> uncompressed, I get following messages :
>
<snip>
> [ 3.736691] Failed to
> execute /sbin/init. Attempting defaults...
> [ 3.748073] Kernel panic - not syncing: No init found. Try passing
> init= option to kernel.
> [ 3.772040] Rebooting in 180 seconds..[ 183.487314] Signal: 8
>
Try changing the kernel parameters line to specify init=/bin/sh and see
what happens.
g.
^ permalink raw reply
* Re: Updates to powerpc.git
From: Grant Likely @ 2008-07-09 14:38 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Andrew Morton
In-Reply-To: <BA91427F-F52C-4AA5-886B-E8D7527EA203@kernel.crashing.org>
On Wed, Jul 09, 2008 at 08:40:21AM -0500, Kumar Gala wrote:
>
> On Jul 9, 2008, at 8:18 AM, Josh Boyer wrote:
>
>> On Wed, 09 Jul 2008 17:34:41 +1000
>> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>> Also, Paul is pretty good about not rebasing his branches when at all
>> possible, and I suspect that's why his master and next were often the
>> same. It makes life lots easier for the sub-maintainers and anyone
>> trying to track against the tree. I humbly beg you to keep that
>> going.
>
> I agree and I'm sure linus will tell you how evil it is to rebase as a
> maintainer.
Add my voice to the chorus. Rebasing a branch that I commit on top of
really messes up the workflow.
g.
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Grant Likely @ 2008-07-09 14:39 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1215612904.13186.4.camel@weaponx>
On Wed, Jul 09, 2008 at 10:15:04AM -0400, Josh Boyer wrote:
> On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote:
> > Hi Josh,
> >
> > Here are the bulk of the Xilinx 440 support patches. Please pull
> > into your next branch.
> >
> > Thanks,
> > g.
> >
> > The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a:
> > Michael Neuling (1):
> > powerpc: Update for VSX core file and ptrace
> >
> > are available in the git repository at:
> >
> > git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
>
> Any chance to get that updated with the latest fixes before I pull it
> in? Namely the DTS file for virtex5, but there might have been others.
Yes, I'll do that this morning, along with the extra images patch.
g.
^ permalink raw reply
* merge from arch/ppc to arch/powerpc on lite5200
From: mejjad lahcen @ 2008-07-09 14:42 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]
Hi all of you,
I am working to port linux2.6.26 on board based on lite5200, but the kernel
hangs here ( see output)
# Booting image at ff000000 ...
Image Name: Linux-2.6.26-rc9
Created: 2008-07-09 14:05:34 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1738816 Bytes = 1.7 MB
Load Address: 00400000
Entry Point: 00400550
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at ff200000 ...
Image Name: ram disk
Created: 2008-07-09 14:28:18 UTC
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 5878062 Bytes = 5.6 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 039c3000, end 03f5e12e ... OK
Memory <- <0x0 0x4000000> (64MB)
CPU clock-frequency <- 0x1687d280 (378MHz)
CPU timebase-frequency <- 0x1406f40 (21MHz)
CPU bus-frequency <- 0x501bd00 (84MHz)
zImage starting: loaded at 0x00400000 (sp: 0x03f5ede0)
Allocating 0x3887b8 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x00788e30)...done 0x3683e0 bytes
Using loader supplied ramdisk at 0x39c3000-0x3f5e12e
initrd head: 0x1f8b0808
Linux/PowerPC load: root=/dev/ram rw console=ttyPSC0 ramdisk_size=16000
ip=192.168.0.133:192.168.0.131:192.168.0.2:255.255.255.0::eth0:off
Finalizing device tree... flat tree at 0x795300
:))))))
I compiled ramdisk with arch/powerpc but I got the same problem, I dont know
if someone has reesolved this issue
thanks
[-- Attachment #2: Type: text/html, Size: 1969 bytes --]
^ permalink raw reply
* unsubscribe
From: Ed Henderson @ 2008-07-09 14:45 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3 bytes --]
[-- Attachment #2: Type: text/html, Size: 1619 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Fix problems with 32bit PPC's running with more than 2GB of RAM
From: Kumar Gala @ 2008-07-09 14:20 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <1215611076-13518-1-git-send-email-sr@denx.de>
On Jul 9, 2008, at 8:44 AM, Stefan Roese wrote:
> This patch enables 32bit PPC's (with 36bit physical address space,
> e.g.
> IBM/AMCC PPC44x) to run with more than 2GB of RAM. Mostly its just
> replacing types (unsigned long -> phys_addr_t).
should the commit header really be >= 4G. I don't think there is any
issue with 2-4G support as it stands.
>
>
> Tested on an AMCC Katmai with 4GB of DDR2.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
- k
^ permalink raw reply
* Re: [PATCH] powerpc: Fix problems with 32bit PPC's running with more than 2GB of RAM
From: Stefan Roese @ 2008-07-09 15:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <300E659E-810B-4C90-A8C8-78E39B73D8B0@kernel.crashing.org>
On Wednesday 09 July 2008, Kumar Gala wrote:
> On Jul 9, 2008, at 8:44 AM, Stefan Roese wrote:
> > This patch enables 32bit PPC's (with 36bit physical address space,
> > e.g.
> > IBM/AMCC PPC44x) to run with more than 2GB of RAM. Mostly its just
> > replacing types (unsigned long -> phys_addr_t).
>
> should the commit header really be >= 4G. I don't think there is any
> issue with 2-4G support as it stands.
Right. I'll fix this up and resubmit.
Thanks.
Best regards,
Stefan
^ permalink raw reply
* [PATCH v2] powerpc: Fix problems with 32bit PPC's running with >= 4GB of RAM
From: Stefan Roese @ 2008-07-09 15:09 UTC (permalink / raw)
To: linuxppc-dev
This patch enables 32bit PPC's (with 36bit physical address space, e.g.
IBM/AMCC PPC44x) to run with >= 4GB of RAM. Mostly its just replacing types
(unsigned long -> phys_addr_t).
Tested on an AMCC Katmai with 4GB of DDR2.
Signed-off-by: Stefan Roese <sr@denx.de>
---
arch/powerpc/mm/init_32.c | 4 ++--
arch/powerpc/mm/mem.c | 8 ++++----
arch/powerpc/mm/mmu_decl.h | 4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index 1952b4d..325ccdd 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -56,8 +56,8 @@
DEFINE_PER_CPU(struct mmu_gather, mmu_gathers);
-unsigned long total_memory;
-unsigned long total_lowmem;
+phys_addr_t total_memory;
+phys_addr_t total_lowmem;
phys_addr_t memstart_addr = (phys_addr_t)~0ull;
EXPORT_SYMBOL(memstart_addr);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 51f82d8..55ef772 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -329,7 +329,7 @@ static int __init mark_nonram_nosave(void)
void __init paging_init(void)
{
unsigned long total_ram = lmb_phys_mem_size();
- unsigned long top_of_ram = lmb_end_of_DRAM();
+ phys_addr_t top_of_ram = lmb_end_of_DRAM();
unsigned long max_zone_pfns[MAX_NR_ZONES];
#ifdef CONFIG_PPC32
@@ -348,10 +348,10 @@ void __init paging_init(void)
kmap_prot = PAGE_KERNEL;
#endif /* CONFIG_HIGHMEM */
- printk(KERN_DEBUG "Top of RAM: 0x%lx, Total RAM: 0x%lx\n",
- top_of_ram, total_ram);
+ printk(KERN_DEBUG "Top of RAM: 0x%llx, Total RAM: 0x%lx\n",
+ (u64)top_of_ram, total_ram);
printk(KERN_DEBUG "Memory hole size: %ldMB\n",
- (top_of_ram - total_ram) >> 20);
+ (long int)((top_of_ram - total_ram) >> 20));
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
#ifdef CONFIG_HIGHMEM
max_zone_pfns[ZONE_DMA] = lowmem_end_addr >> PAGE_SHIFT;
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 0480225..4e46c63 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -49,8 +49,8 @@ extern unsigned int num_tlbcam_entries;
extern unsigned long ioremap_bot;
extern unsigned long __max_low_memory;
extern phys_addr_t __initial_memory_limit_addr;
-extern unsigned long total_memory;
-extern unsigned long total_lowmem;
+extern phys_addr_t total_memory;
+extern phys_addr_t total_lowmem;
extern phys_addr_t memstart_addr;
extern phys_addr_t lowmem_end_addr;
--
1.5.6.2
^ permalink raw reply related
* [PATCH v3] Add PPC_FEATURE_PSERIES_PERFMON_COMPAT
From: Nathan Lynch @ 2008-07-09 15:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras
In-Reply-To: <20080703232001.GB9594@localdomain>
Background from Maynard Johnson:
As of POWER6, a set of 32 common events is defined that must be
supported on all future POWER processors. The main impetus for this
compat set is the need to support partition migration, especially from
processor P(n) to processor P(n+1), where performance software that's
running in the new partition may not be knowledgeable about processor
P(n+1). If a performance tool determines it does not support the
physical processor, but is told (via the
PPC_FEATURE_PSERIES_PERFMON_COMPAT bit) that the processor supports
the notion of the PMU compat set, then the performance tool can
surface just those events to the user of the tool.
PPC_FEATURE_PSERIES_PERFMON_COMPAT indicates that the PMU supports at
least this basic subset of events which is compatible across POWER
processor lines.
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
Changes since v2:
- Further disambiguated name of feature bit (PMU -> PERFMON)
Changes since v1:
- make name of feature bit less generic
- provide more complete changelog
arch/powerpc/kernel/cputable.c | 6 ++++--
include/asm-powerpc/cputable.h | 3 +++
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 817cea1..02088b0 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -70,10 +70,12 @@ extern void __restore_cpu_power7(void);
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP)
#define COMMON_USER_POWER6 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_05 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | \
+ PPC_FEATURE_PSERIES_PERFMON_COMPAT)
#define COMMON_USER_POWER7 (COMMON_USER_PPC64 | PPC_FEATURE_ARCH_2_06 |\
PPC_FEATURE_SMT | PPC_FEATURE_ICACHE_SNOOP | \
- PPC_FEATURE_TRUE_LE)
+ PPC_FEATURE_TRUE_LE | \
+ PPC_FEATURE_PSERIES_PERFMON_COMPAT)
#define COMMON_USER_PA6T (COMMON_USER_PPC64 | PPC_FEATURE_PA6T |\
PPC_FEATURE_TRUE_LE | \
PPC_FEATURE_HAS_ALTIVEC_COMP)
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 3171ac9..58d4281 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -27,6 +27,9 @@
#define PPC_FEATURE_ARCH_2_06 0x00000100
#define PPC_FEATURE_HAS_VSX 0x00000080
+#define PPC_FEATURE_PSERIES_PERFMON_COMPAT \
+ 0x00000040
+
#define PPC_FEATURE_TRUE_LE 0x00000002
#define PPC_FEATURE_PPC_LE 0x00000001
--
1.5.6.2
^ permalink raw reply related
* Re: [patch 5/5] powerpc: Dont clear _PAGE_COHERENT when _PAGE_SAO is set
From: Dave Kleikamp @ 2008-07-09 15:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1215575177.8970.311.camel@pasglop>
On Wed, 2008-07-09 at 13:46 +1000, Benjamin Herrenschmidt wrote:
> The old code looks bogus.. why clear M when G is set ? Only
> I should have mattered.
I can't find anywhere where G gets set without also setting I, so the
test seems redundant as well.
> I'll apply anyway as you aren't changing the existing behaviour here but
> maybe you can shoot me a fixup patch that removes the _PAGE_GUARDED
> condition completely here ?
No problem. There is code in cell/beat_htab.c doing the same thing.
I've gone ahead and fixed it there too.
> It's legal to have G=1 M=1 pages and can even be useful under some
> circumstances.
It doesn't look like anyone is trying to take advantage of that
currently.
Here's your patch:
powerpc: Remove unnecessary condition when sanity-checking WIMG bits
It is okay for both _PAGE_GUARDED and _PAGE_COHERENT (G and M) to be set
in the same pte. In fact, even if that were not the case, there doesn't
seem to be any place where G is set without also setting I (_PAGE_NO_CACHE),
so the test for I is sufficient.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
diff --git a/arch/powerpc/platforms/cell/beat_htab.c b/arch/powerpc/platforms/cell/beat_htab.c
index 81467ff..2e67bd8 100644
--- a/arch/powerpc/platforms/cell/beat_htab.c
+++ b/arch/powerpc/platforms/cell/beat_htab.c
@@ -112,7 +112,7 @@ static long beat_lpar_hpte_insert(unsigned long hpte_group,
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
- if (rflags & (_PAGE_GUARDED|_PAGE_NO_CACHE))
+ if (rflags & _PAGE_NO_CACHE)
hpte_r &= ~_PAGE_COHERENT;
spin_lock(&beat_htab_lock);
@@ -334,7 +334,7 @@ static long beat_lpar_hpte_insert_v3(unsigned long hpte_group,
if (!(vflags & HPTE_V_BOLTED))
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
- if (rflags & (_PAGE_GUARDED|_PAGE_NO_CACHE))
+ if (rflags & _PAGE_NO_CACHE)
hpte_r &= ~_PAGE_COHERENT;
/* insert into not-volted entry */
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index 38b5927..52a80e5 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -305,8 +305,7 @@ static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
flags = 0;
/* Make pHyp happy */
- if ((rflags & _PAGE_GUARDED) ||
- ((rflags & _PAGE_NO_CACHE) & !(rflags & _PAGE_WRITETHRU)))
+ if ((rflags & _PAGE_NO_CACHE) & !(rflags & _PAGE_WRITETHRU))
hpte_r &= ~_PAGE_COHERENT;
lpar_rc = plpar_pte_enter(flags, hpte_group, hpte_v, hpte_r, &slot);
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply related
* Re: [PATCH] powerpc: rework 4xx PTE access and TLB miss
From: Kumar Gala @ 2008-07-09 15:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20080708055449.EDFDADDEF5@ozlabs.org>
On Jul 8, 2008, at 12:54 AM, Benjamin Herrenschmidt wrote:
> This is some preliminary work to improve TLB management on SW loaded
> TLB powerpc platforms. This introduce support for non-atomic PTE
> operations in pgtable-ppc32.h and removes write back to the PTE from
> the TLB miss handlers. In addition, the DSI interrupt code no longer
> tries to fixup write permission, this is left to generic code, and
> _PAGE_HWWRITE is gone.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> This is a first step, plan is to do the same for FSL BookE, 405 and
> possibly 8xx too. From there, I want to rework a bit the execute
> permission handling to avoid multiple faults, add support for
> _PAGE_EXEC (no executable mappings), for prefaulting (especially
> for kmap) and proper SMP support for future SMP capable BookE
> platforms.
>
> v2. This version fixes a couple of typos, add a few comments and
> change use of flush_instruction_cache() to flush_icache_range()
> which will be more appropriate if there is ever an SMP variant.
>
> v3. Relying on the generic code to fixup _PAGE_ACCESSED doesn't
> work for exec faults because our cache coherency code in
> do_page_fault() will never go all the way to the generic code
> for these. We fix it up by always setting _PAGE_ACCESSED when
> setting _PAGE_HWEXEC in there.
> This version of the patch is rebased on top of -next
shouldn't you remove _PAGE_HWWRITE from 40x? (I'm still seeing it in
pgtable-ppc32.h and head_40x.S)
- k
^ permalink raw reply
* [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Chirag Jog @ 2008-07-09 15:33 UTC (permalink / raw)
To: linux.kernel, linux-rt-users, linuxppc-dev
Cc: Timothy R. Chavez, Nivedita Singhvi, paulmck
Hi,
This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
variables are accessed in a preempt unsafe way.
When a power box with -rt kernel is booted, multiple BUG messages are
generated "BUG: init:1 task might have lost a preemption check!".
After booting a kernel with these patches applied, these messages
don't appear.
Also I ran the realtime tests from ltp to ensure the stability.
Signed-Off-By: Chirag <chirag@linux.vnet.ibm.com>
arch/powerpc/mm/tlb_64.c | 29 ++++++++++++++++-------------
arch/powerpc/platforms/pseries/iommu.c | 14 ++++++++++----
include/asm-powerpc/tlb.h | 5 ++---
3 files changed, 28 insertions(+), 20 deletions(-)
Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-07 13:13:59.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-09 20:57:01.000000000 +0530
@@ -38,7 +38,6 @@
* include/asm-powerpc/tlb.h file -- tgall
*/
DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
struct pte_freelist_batch
@@ -48,7 +47,7 @@
pgtable_free_t tables[0];
};
-DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
+DEFINE_PER_CPU_LOCKED(struct pte_freelist_batch *, pte_freelist_cur);
unsigned long pte_freelist_forced_free;
#define PTE_FREELIST_SIZE \
@@ -92,16 +91,14 @@
void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
{
- /*
- * This is safe since tlb_gather_mmu has disabled preemption.
- * tlb->cpu is set by tlb_gather_mmu as well.
- */
+ int cpu;
cpumask_t local_cpumask = cpumask_of_cpu(tlb->cpu);
- struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
+ struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
if (atomic_read(&tlb->mm->mm_users) < 2 ||
cpus_equal(tlb->mm->cpu_vm_mask, local_cpumask)) {
pgtable_free(pgf);
+ goto cleanup;
return;
}
@@ -109,6 +106,7 @@
*batchp = (struct pte_freelist_batch *)__get_free_page(GFP_ATOMIC);
if (*batchp == NULL) {
pgtable_free_now(pgf);
+ goto cleanup;
return;
}
(*batchp)->index = 0;
@@ -118,6 +116,9 @@
pte_free_submit(*batchp);
*batchp = NULL;
}
+
+ cleanup:
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/*
@@ -253,13 +254,15 @@
void pte_free_finish(void)
{
- /* This is safe since tlb_gather_mmu has disabled preemption */
- struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
+ int cpu;
+ struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
- if (*batchp == NULL)
- return;
- pte_free_submit(*batchp);
- *batchp = NULL;
+ if (*batchp) {
+ pte_free_submit(*batchp);
+ *batchp = NULL;
+ }
+
+ put_cpu_var_locked(pte_freelist_cur, cpu);
}
/**
Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
===================================================================
--- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-07 22:58:37.000000000 +0530
+++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-09 10:22:51.000000000 +0530
@@ -40,18 +40,17 @@
static inline void tlb_flush(struct mmu_gather *tlb)
{
- struct ppc64_tlb_batch *tlbbatch = &__get_cpu_var(ppc64_tlb_batch);
+ struct ppc64_tlb_batch *tlbbatch = &get_cpu_var(ppc64_tlb_batch);
/* If there's a TLB batch pending, then we must flush it because the
* pages are going to be freed and we really don't want to have a CPU
* access a freed page because it has a stale TLB
*/
if (tlbbatch->index) {
- preempt_disable();
__flush_tlb_pending(tlbbatch);
- preempt_enable();
}
+ put_cpu_var(ppc64_tlb_batch);
pte_free_finish();
}
Index: linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c
===================================================================
--- linux-2.6.25.8-rt7.orig/arch/powerpc/platforms/pseries/iommu.c 2008-07-07 23:16:29.000000000 +0530
+++ linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c 2008-07-09 10:49:21.000000000 +0530
@@ -124,7 +124,7 @@
}
}
-static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
+static DEFINE_PER_CPU_LOCKED(u64 *, tce_page) = NULL;
static void tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
long npages, unsigned long uaddr,
@@ -135,12 +135,13 @@
u64 *tcep;
u64 rpn;
long l, limit;
+ int cpu;
if (npages == 1)
return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
direction);
- tcep = __get_cpu_var(tce_page);
+ tcep = get_cpu_var_locked(tce_page, &cpu);
/* This is safe to do since interrupts are off when we're called
* from iommu_alloc{,_sg}()
@@ -148,10 +149,13 @@
if (!tcep) {
tcep = (u64 *)__get_free_page(GFP_ATOMIC);
/* If allocation fails, fall back to the loop implementation */
- if (!tcep)
+ if (!tcep) {
+ put_cpu_var_locked(tce_page, cpu);
return tce_build_pSeriesLP(tbl, tcenum, npages,
uaddr, direction);
- __get_cpu_var(tce_page) = tcep;
+ }
+
+ per_cpu_var_locked(tce_page, cpu) = tcep;
}
rpn = (virt_to_abs(uaddr)) >> TCE_SHIFT;
@@ -188,6 +192,8 @@
printk("\ttce[0] val = 0x%lx\n", tcep[0]);
show_stack(current, (unsigned long *)__get_SP());
}
+
+ put_cpu_var_locked(tce_page, cpu);
}
static void tce_free_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
^ permalink raw reply
* Re: Please pull linux-2.6-virtex.git
From: Grant Likely @ 2008-07-09 15:57 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1215612904.13186.4.camel@weaponx>
Hey Josh, here is the new pull request:
The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a:
Michael Neuling (1):
powerpc: Update for VSX core file and ptrace
are available in the git repository at:
git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
Grant Likely (4):
powerpc/bootwrapper: Add documentation of boot wrapper targets
powerpc/bootwrapper: add missing bit of simpleImage target
powerpc/bootwrapper: Allow user to specify additional default targets
powerpc/440: Convert Virtex ML507 device tree to dts-v1
John Linn (5):
powerpc/virtex: add dts file for ML507 reference design
powerpc/virtex: Fix booting of Xilinx FPGAs with 16550 for 405 and 440
powerpc/virtex: add Xilinx Virtex 5 ppc440 platform support
powerpc/virtex: add Xilinx 440 cpu to the cputable
powerpc/virtex: add defconfig for virtex 5 platforms
Documentation/powerpc/bootwrapper.txt | 141 ++++
arch/powerpc/Kconfig | 13 +
arch/powerpc/Makefile | 15 +-
arch/powerpc/boot/Makefile | 5 +-
arch/powerpc/boot/dts/virtex440-ml507.dts | 296 ++++++++
arch/powerpc/boot/simpleboot.c | 6 +
arch/powerpc/boot/virtex.c | 100 +++
arch/powerpc/boot/wrapper | 10 +-
arch/powerpc/configs/44x/virtex5_defconfig | 1107 ++++++++++++++++++++++++++++
arch/powerpc/kernel/cputable.c | 10 +
arch/powerpc/platforms/44x/Kconfig | 26 +
arch/powerpc/platforms/44x/Makefile | 1 +
arch/powerpc/platforms/44x/virtex.c | 60 ++
13 files changed, 1787 insertions(+), 3 deletions(-)
create mode 100644 Documentation/powerpc/bootwrapper.txt
create mode 100644 arch/powerpc/boot/dts/virtex440-ml507.dts
create mode 100644 arch/powerpc/boot/virtex.c
create mode 100644 arch/powerpc/configs/44x/virtex5_defconfig
create mode 100644 arch/powerpc/platforms/44x/virtex.c
On Wed, Jul 9, 2008 at 8:15 AM, Josh Boyer <jwboyer@gmail.com> wrote:
> On Fri, 2008-07-04 at 11:22 -0600, Grant Likely wrote:
>> Hi Josh,
>>
>> Here are the bulk of the Xilinx 440 support patches. Please pull
>> into your next branch.
>>
>> Thanks,
>> g.
>>
>> The following changes since commit f3e909c2750eb20536bacacc867dc9047b70546a:
>> Michael Neuling (1):
>> powerpc: Update for VSX core file and ptrace
>>
>> are available in the git repository at:
>>
>> git://git.secretlab.ca/git/linux-2.6-virtex virtex-for-2.6.27
>
> Any chance to get that updated with the latest fixes before I pull it
> in? Namely the DTS file for virtex5, but there might have been others.
>
> josh
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ 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