* Re: Booting ML405 (Kernel panic - not syncing: No init found)
From: Marco Stornelli @ 2008-07-09 12:46 UTC (permalink / raw)
To: neeraj garg; +Cc: linuxppc-embedded
In-Reply-To: <48744475.2080605@cdac.in>
neeraj garg ha scritto:
> 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 :
>
>
> loaded at: 00400000 008E519C
> board data at: 008E3120 008E319C
> relocated to: 00404074 004040F0
> zimage at: 00404E65 00517841
> initrd at: 00518000 008E2B4A
> avail ram: 008E6000 02000000 //there is restriction to use 32 MB
> of memory
>
> some of the initial messages, and then
>
> [ 0.000000] Zone PFN ranges:
> [ 0.000000] DMA 0 -> 8192
> [ 0.000000] Normal 8192 -> 8192
> [ 0.000000] Movable zone start PFN for each node
> [ 0.000000] early_node_map[1] active PFN ranges
> [ 0.000000] 0: 0 -> 8192
> [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 8128
> [ 0.000000] Kernel command line: console=ttyUL0,19200 ip=off
> root=/dev/ram rw init=/sbin/init
> [ 0.000000] Xilinx INTC #0 at 0x1E000000 mapped to 0xFDFFF000
> [ 0.000000] PID hash table entries: 128 (order: 7, 512 bytes)
> [ 0.000116] Console: colour dummy device 80x25
> [ 0.000285] Dentry cache hash table entries: 4096 (order: 2, 16384
> bytes)
> [ 0.000506] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
> [ 0.004931] Memory: 26168k available (1740k kernel code, 576k data,
> 104k init, 0k highmem)
> [ 0.096364] Mount-cache hash table entries: 512
>
> few more messages, and then
>
> [ 2.218059] RAMDISK: Compressed image found at block 0
> [ 3.708864] VFS: Mounted root (ext2 filesystem).
> [ 3.716225] Freeing unused kernel memory
> [ 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
>
>
> [ 183.487322] Code: 0
> [ 183.487329] Addr: c0010540
> [ 183.488000] Oops: Exception in kernel mode, sig: 8 [#1]
> [ 183.488000] NIP: c0010540 LR: 00029030 CTR: c0246cec
> [ 183.488000] REGS: c1c17dd0 TRAP: 2007e90 Not tainted (2.6.25-xlnx)
> [ 183.488000] MSR: 00000000 <> CR: c022e764 XER: c024c0e8
> [ 183.488000] TASK = c1c14850[1] 'init' THREAD: c1c16000
> [ 183.488000] GPR00: 00000000 00000000 c0240000 c0246cec 00000000
> 00000000 c0240000 c0246cec
> [ 183.488000] GPR08: c0250000 0002bf20 c022e764 c0250000 c1c17e80
> c0018e44 c1c14850 00000000
> [ 183.488000] GPR16: 0000002a b8a199a2 0000002a b87fa729 c000bc58
> b8a199a2 b873dc16 0000002a
> [ 183.488000] GPR24: b87fa729 c0018e44 c022e764 000000b4 c1c17e70
> 00029030 00000000 00000000
> [ 183.488000] NIP [c0010540] cpu_clock+0x44/0x6c
> [ 183.488000] LR [00029030] 0x29030
> [ 183.488000] Call Trace:
> [ 183.488000] [c1c17ca0] [c0008ad8] show_stack+0x58/0x180 (unreliable)
> [ 183.488000] [c1c17cd0] [c0008dec] show_regs+0x1e0/0x2cc
> [ 183.488000] [c1c17d00] [c00031d0] die+0x6c/0x88
> [ 183.488000] [c1c17d20] [c000323c] _exception+0x50/0xe0
> [ 183.488000] [c1c17dc0] [c0002d90] ret_from_except_full+0x0/0x4c
> [ 183.488000] Instruction dump:
> [ 183.488000] XXXXXXXX XXXXXXXX XXXXXXXX 38800000 XXXXXXXX XXXXXXXX
> XXXXXXXX 7c000124
> [ 183.488000] XXXXXXXX XXXXXXXX XXXXXXXX 4bfffef1 XXXXXXXX XXXXXXXX
> XXXXXXXX 7d234b78
> [ 183.488000] Kernel panic - not syncing: Attempted to kill init!
>
> --I was doubtful about busybox version used in RAMDISK provided at git
> site. So I compiled my own busybox-1.10.3 with my cross compiler tool
> chain still I am facing the same problem. Can anybody guide me.
>
The problem is that the kernel can't find the init program. Check out
it, does it exist? You can use init= kernel option to specify a new
position other than the default one, if it's in a specific folder.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: libfdt: Increase namespace-pollution paranoia
From: Kumar Gala @ 2008-07-09 12:54 UTC (permalink / raw)
To: jwboyer; +Cc: ppc-dev list, David Gibson
In-Reply-To: <1215603723.13186.0.camel@weaponx>
On Jul 9, 2008, at 6:42 AM, Josh Boyer wrote:
> On Wed, 2008-07-09 at 14:10 +1000, David Gibson wrote:
>> libfdt is supposed to easy to embed in projects all and sundry.
>> Often, it won't be practical to separate the embedded libfdt's
>> namespace from that of the surrounding project. Which means there
>> can
>> be namespace conflicts between even libfdt's internal/static
>> functions
>> and functions or macros coming from the surrounding project's headers
>> via libfdt_env.h.
>>
>> This patch, therefore, renames a bunch of libfdt internal functions
>> and macros and makes a few other chances to reduce the chances of
>> namespace collisions with embedding projects. Specifically:
>> - Internal functions (even static ones) are now named _fdt_*()
>>
>> - The type and (static) global for the error table in
>> fdt_strerror() gain an fdt_ prefix
>>
>> - The unused macro PALIGN is removed
>>
>> - The memeq and streq macros are removed and open-coded in the
>> users (they were only used once each)
>>
>> - Other macros gain an FDT_ prefix
>>
>> - To save some of the bulk from the previous change, an
>> FDT_TAGALIGN() macro is introduced, where FDT_TAGALIGN(x) ==
>> FDT_ALIGN(x, FDT_TAGSIZE)
>>
>> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
>
> 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
^ permalink raw reply
* Re: Updates to powerpc.git
From: Kumar Gala @ 2008-07-09 12:58 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, Andrew Morton
In-Reply-To: <1215588881.8970.358.camel@pasglop>
On Jul 9, 2008, at 2:34 AM, Benjamin Herrenschmidt 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.
What is your intent with the 'master' branch? I hope you do NOT plan
on ever rebasing it. I assume if a patch gets into master and we drop
it you'll do a git-revert of it?
- k
^ permalink raw reply
* Re: [PATCH] Minor fixes for 85xxds and 8536ds board.
From: Kumar Gala @ 2008-07-09 13:00 UTC (permalink / raw)
To: Jason Jin; +Cc: linuxppc-dev list
In-Reply-To: <1215480068-6235-1-git-send-email-Jason.jin@freescale.com>
On Jul 7, 2008, at 8:21 PM, Jason Jin wrote:
> Remove the "uninitialized use" compile warning and
> avoid potential runtime issue.
>
> Signed-off-by: Jason Jin <Jason.jin@freescale.com>
> ---
> arch/powerpc/platforms/85xx/mpc8536_ds.c | 2 +-
> arch/powerpc/platforms/85xx/mpc85xx_ds.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
applied.
- k
^ permalink raw reply
* 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
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