Re: MPC5200 PCI Issues
When enabling the debug-printouts, it came to me that I forgot to
mention something kind of important. Using the standard mpc52xx_pci.c,
even the memory resources are mapped to zero.
After disabling this code block, the memory regions are mapped out
fine (but still no IO):
static void
mpc52xx_pci_fixup_resources(struct pci_dev *dev)
{
int i;
pr_debug("mpc52xx_pci_fixup_resources() %.4x:%.4x\n",
dev->vendor, dev->device);
/* We don't rely on boot loader for PCI and resets all
devices */
for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
struct resource *res = &dev->resource[i];
if (res->end > res->start) {/* Only valid resources */
res->end -= res->start;
res->start = 0;
res->flags |= IORESOURCE_UNSET;
}
}
What is the purpose of this code? Since all resources are reset here,
where are they inteded to be re-allocated?
Here is the bootlog with the aforementioned code enabled:
reading cuImage.lite5200b
1833699 bytes read
## Booting kernel from Legacy Image at 00201400 ...
Image Name: Linux-2.6.28
Created: 2009-02-05 6:54:20 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size:1833635 Bytes = 1.7 MB
Load Address: 0040
Entry Point: 004005a0
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
[0.00] Using lite5200 machine description
[0.00] Linux version 2.6.28 (tknuts...@ztn-ubuntu) (gcc
version 4.3.2 (Sourcery G++ Lite 4.3-50) ) #66 Thu Feb 5 07:51:46 CET
2009
[0.00] Adding MPC52xx PCI host bridge /p...@fd00
[0.00] PCI host bridge /p...@fd00 (primary) ranges:
[0.00] MEM 0x5000..0x5fff -> 0x5000
[0.00] IO 0x6000..0x60ff -> 0x
[0.00] mpc52xx_pci_setup(hose=c03ec000, pci_regs=fdffad00)
[0.00] mem_resource[0] = {.start=5000, .end=5fff, .flags=200}
[0.00] .io_resource={.start=0,.end=ff,.flags=100}
.io_base_phys=0x6000
[0.00] Zone PFN ranges:
[0.00] DMA 0x -> 0x4000
[0.00] Normal 0x4000 -> 0x4000
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[1] active PFN ranges
[0.00] 0: 0x -> 0x4000
[0.00] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 16256
[0.00] Kernel command line: console=ttyPSC0,115200 root=/dev/sda2 rw
[0.00] MPC52xx PIC is up and running!
[0.00] PID hash table entries: 256 (order: 8, 1024 bytes)
[0.00] clocksource: timebase mult[7d0] shift[22] registered
[0.000263] console [ttyPSC0] enabled
[0.121690] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.129012] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[0.147433] Memory: 60844k/65536k available (3704k kernel code,
4624k reserved, 156k data, 117k bss, 180k init)
[0.157672] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0,
CPUs=1, Nodes=1
[0.165373] Calibrating delay loop... 63.87 BogoMIPS (lpj=127744)
[0.236265] Mount-cache hash table entries: 512
[0.245719] net_namespace: 288 bytes
[0.250237] NET: Registered protocol family 16
[0.284887] PCI: Probing PCI hardware
[0.289670] mpc52xx_pci_fixup_resources() 1057:5809
[0.294799] PCI::00:17.0 Resource 0
5040-507f [21208] fixup...
[0.303180] PCI::00:17.05040-507f
[0.309998] PCI::00:17.0 Resource 1
5080-50ff [20200] fixup...
[0.318262] PCI::00:17.05080-50ff
[0.325062] PCI::00:17.0 Resource 2
6000-600f [20101] fixup...
[0.26] PCI::00:17.06000-600f
[0.340124] mpc52xx_pci_fixup_resources() 104c:9065
[0.345242] PCI::00:18.0 Resource 0
5100-513f [21208] fixup...
[0.353519] PCI::00:18.05100-513f
[0.360319] PCI::00:18.0 Resource 1
5180-51ff [20200] fixup...
[0.368583] PCI::00:18.05180-51ff
[0.375383] PCI::00:18.0 Resource 2
6010-601f [20101] fixup...
[0.383647] PCI::00:18.06010-601f
[0.390444] mpc52xx_pci_fixup_resources() 104c:9065
[0.395549] PCI::00:19.0 Resource 0
5200-523f [21208] fixup...
[0.403826] PCI::00:19.05200-523f
[0.410626] PCI::00:19.0 Resource 1
5280-52ff [20200] fixup...
[0.418889] PCI::00:19.05280-52ff
[
Re: [ANN] Introducing new "test" branch in powerpc.git tree
On Wed, 2009-02-04 at 23:53 -0600, Kumar Gala wrote: > > Are you going to ask "test" get pulled into Stephen's -next tree? No, I don't intend to let things stage long enough in "test" for that to matter and I asked Stephen, he isn't hot about it. Hopefully the max lifetime for something in "test" should be around a week. It's really a way for me to advertise what I want to push out and still have a last minute chance to catch big mistakes. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[no subject]
2009-02-05 03212009 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/1 v3] AMCC PPC 460SX redwood SoC platform initial framework
On Feb 4, 2009, at 5:45 PM, Madhulika Madishetty wrote:
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/
cputable.c
index 923f87a..5c40da4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -43,6 +43,7 @@ extern void __setup_cpu_440spe(unsigned long
offset, struct cpu_spec* spec);
extern void __setup_cpu_440x5(unsigned long offset, struct cpu_spec*
spec);
extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec*
spec);
extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec*
spec);
+extern void __setup_cpu_460sx(unsigned long offset, struct cpu_spec
*spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec*
spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec*
spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec*
spec);
@@ -1634,6 +1635,18 @@ static struct cpu_spec __initdata cpu_specs[]
= {
.machine_check = machine_check_440A,
.platform = "ppc440",
},
+ { /* 460SX */
+ .pvr_mask = 0xff00,
+ .pvr_value = 0x13541800,
+ .cpu_name = "460SX",
+ .cpu_features = CPU_FTRS_44X,
+ .cpu_user_features = COMMON_USER_BOOKE,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .cpu_setup = __setup_cpu_460sx,
+ .machine_check = machine_check_440A,
+ .platform = "ppc440",
+ },
This needs to be updated to include the new mmu_features field.
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new "test" branch in powerpc.git tree
On Feb 4, 2009, at 10:01 PM, Benjamin Herrenschmidt wrote: Hoy ! So I've been annoyed for some time by the way we do our preparation for the next merge window. The "next" branch is defined as not being rebased ever (well, as much as possible), which makes it impossible to just stash things early in there and rebase if needed, which is a useful exercise in the weeks leading to the merge window to be able to test patches, fix them, etc... while keeping a good idea of what's planned to go in. Thus I've created a "test" branch. I'll push it out later today with various things pending. For pulls from sub-maintainers, I'll probably merge into "next" quickly (ie. a day or two after hitting "test" just enough time to find gross problems). That will allow me to be more pro-active also at pulling things off the mailing list and sticking them there even if some cosmetic changes have been requested to the patch as I will have no issue rebasing it when the new patch comes in. Now, one important rule is: test will be reset at the beginning of every merge window. I will not let it degenerate into the old linuxppc-dev bk tree that drifted for years and had things that never got merged. I'm also not sure whether sub-maintainers should do the same thing with a "test" branch of their own. I certainly don't mind if they rebase their "next" branches so I'm happy for them to play the same game directly into their 'next' branch as long as the day they ask me to pull it into the real 'next', they are reasonably confident that the stuff in there is stable. For any complaint, see my secretary in the Oort cloud. Are you going to ask "test" get pulled into Stephen's -next tree? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Commits pushed to test branch
I've pushed these commits to the test branch. This include the next branches from Kumar and Grant, which I'll move over to my "next" branch soon, probably tomorrow, if the world doesn't end in the meantime. The rest is picked up from patchwork, and will trickle up to "next" as I see fit unless somebody hollers. People are _MUCH_WELCOME_ to pull that test branch and test it, that's the whole point of having it, so we can catch problems before their hit the next branch that we can't rebase. Further occurences of this announce won't be that verbose, though I haven't decided on a proper format or subject tag yet :-) Anton Vorontsov (2): powerpc/fsl_pci: Add MPC83xx PCI-E controller RC mode support powerpc/83xx: Add PCI-E support for all MPC83xx boards with PCI-E Benjamin Herrenschmidt (3): powerpc: Rework I$/D$ coherency (v2) Grant Likely (7): powerpc/5200: Stop using device_type and port-number properties powerpc/5200: Trim cruft from device trees powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver powerpc/5200: Remove pr_debug() from hot paths in irq driver powerpc/5200: Refactor mpc5200 interrupt controller driver powerpc/5200: Rework GPT driver to also be an IRQ controller powerpc/5200: Add support for the Media5200 board from Freescale Grzegorz Bernacki (1): powerpc/5200: Add support for the digsy MTC board. Kumar Gala (3): powerpc/fsl-booke: Cleanup init/exception setup to be runtime powerpc/fsl: Ensure PCI_QUIRKS are enabled for FSL_PCI powerpc: Unify asm opcode definitions and support Laurent Pinchart (1): cpm2: Round the baud-rate clock divider to the nearest integer. Martyn Welch (3): powerpc/86xx: Board support for GE Fanuc SBC310 powerpc/86xx: Default configutation for GE Fanuc's SBC310 powerpc/86xx: Extend GE Fanuc GPIO driver for the SBC310 Michael Ellerman (7): powerpc: Remove unused ppc64_terminate_msg() powerpc: Allow debugging of LMBs with lmb=debug lmb: Rework lmb_dump_all() output powerpc/pseries: Fix MSI-X interrupt querying powerpc/pseries: Add support for ibm,req#msi-x powerpc/pseries: Check for MSI-X also in rtas_msi_pci_irq_fixup() powerpc/pseries: Return the number of MSIs we could allocate Milton Miller (3): powerpc/numa: Avoid possible reference beyond prop. length in find_min_common_depth() powerpc/numa: Remove redundant find_cpu_node() powerpc/pseries: Remove write only variable in PCI DLPAR Peter Korsgaard (1): powerpc: convert dts-bindings/fsl/dma.txt to dts-v1 syntax Reynes Philippe (2): powerpc/83xx: Add i2c eeprom to dts for MPC837x RDB powerpc/83xx: Add gpio to MPC837x RDB Trent Piepho (3): powerpc/fsl-booke: Remove code duplication in lowmem mapping powerpc/fsl-booke: Allow larger CAM sizes than 256 MB powerpc/fsl-booke: Make CAM entries used for lowmem configurable Wolfgang Grandegger (2): powerpc/85xx: TQM85xx - fix sensitivity of CAN interrupts powerpc/85xx: TQM85xx - add i2c device nodes for LM75 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> Right, but then you need to set that in the VMA's, and thus gone is your > nice fast g_u_p() that doesn't touch VMAs :-) Registering memory is a slow path thing in the RDMA world. Speeding it up is nice, so we make userspace do the madvise(VM_DONTCOPY) if it cares but if it doesn't it can leave it out. > > Yes, but unfortunately MPI says apps can allocate memory however they > > damn well please... in any case these issues are all-too-well-known in > > the RDMA world for quite a while. > Yup. What do you think of the idea of pre-COWing pages with an elevated > count at fork time ? Super-duper sucks if the first thing the child does is exec() :) Also if the parent has registered > half the memory in the system then it's instant OOM. So not that useful for the RDMA case :) The one thing that might make sense is to pre-COW any partial pages that the parent has registered -- ie if half a page can be used by the child, at least pre-COW that, but leave all the full pages with VM_DONTCOPY. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wed, 2009-02-04 at 21:10 -0800, Roland Dreier wrote: > > Note that g_u_p() has all sort of shortcommings... we were discussing > > some of that recently due to bugs reported from the field. > > > > The problem mostly is that you cannot guarantee that the physical page > > will remain mapped to that virtual address in the process. For example, > > if your code is part of some library used by an application, and that > > application somewhere does a fork/exec (for example, a system() call to > > run a shell helper), copy-on-write will hit, and you may end up with > > the child process getting the original physical page and the original > > process getting the copy... > > Believe me, I'm well aware of that. We added VM_DONTCOPY to allow apps > to fork() without the child triggering COW, but that means only the > parent process can use the mapped memory (and the app has to worry about > page boundaries etc). Right, but then you need to set that in the VMA's, and thus gone is your nice fast g_u_p() that doesn't touch VMAs :-) > Yes, but unfortunately MPI says apps can allocate memory however they > damn well please... in any case these issues are all-too-well-known in > the RDMA world for quite a while. Yup. What do you think of the idea of pre-COWing pages with an elevated count at fork time ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] AMCC Crypto4xx Device Driver v6
On Wed, Jan 28, 2009 at 02:53:05PM -0800, James Hsiao wrote:
> This patch adds support for AMCC ppc4xx security device driver. This is the
> initial release that includes the driver framework with AES and SHA1
> algorithms
> support.
> The remaining algorithms will be released in the near future.
>
> Signed-off-by: James Hsiao
Patch applied. Thanks James!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> Note that g_u_p() has all sort of shortcommings... we were discussing > some of that recently due to bugs reported from the field. > > The problem mostly is that you cannot guarantee that the physical page > will remain mapped to that virtual address in the process. For example, > if your code is part of some library used by an application, and that > application somewhere does a fork/exec (for example, a system() call to > run a shell helper), copy-on-write will hit, and you may end up with > the child process getting the original physical page and the original > process getting the copy... Believe me, I'm well aware of that. We added VM_DONTCOPY to allow apps to fork() without the child triggering COW, but that means only the parent process can use the mapped memory (and the app has to worry about page boundaries etc). > We've been discussing that at KS with various people, Linus says g_u_p() > sucks, don't do that :-) Most of the time, the other approach should be > used, ie, the driver allocates memory, and userspace mmap's it, in which > case you get access to the VMA to set flags such as don't copy on fork. Yes, but unfortunately MPI says apps can allocate memory however they damn well please... in any case these issues are all-too-well-known in the RDMA world for quite a while. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [ANN] Introducing new "test" branch in powerpc.git tree
On Wed, Feb 4, 2009 at 9:01 PM, Benjamin Herrenschmidt wrote: > [...] > Now, one important rule is: test will be reset at the beginning of every > merge window. I will not let it degenerate into the old linuxppc-dev bk > tree that drifted for years and had things that never got merged. > > I'm also not sure whether sub-maintainers should do the same thing with > a "test" branch of their own. I certainly don't mind if they rebase > their "next" branches so I'm happy for them to play the same game > directly into their 'next' branch as long as the day they ask me to pull > it into the real 'next', they are reasonably confident that the stuff in > there is stable. I'm cool with this. I certainly maintain a branch which is frequently rebased and that is exactly where I stash stuff as I try to decide what to do with it. The only difference is that mine isn't usually public. If people want to see it, then I push it out, but otherwise I just wait until I've got a real pull request. In fact, in this cycle I did push out to my -next and then had to redo it before I sent my pull request because one of the middle commits had an oops (but, nobody bases their patches on my -next tree, so it doesn't have the same repercussions). g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[ANN] Introducing new "test" branch in powerpc.git tree
Hoy ! So I've been annoyed for some time by the way we do our preparation for the next merge window. The "next" branch is defined as not being rebased ever (well, as much as possible), which makes it impossible to just stash things early in there and rebase if needed, which is a useful exercise in the weeks leading to the merge window to be able to test patches, fix them, etc... while keeping a good idea of what's planned to go in. Thus I've created a "test" branch. I'll push it out later today with various things pending. For pulls from sub-maintainers, I'll probably merge into "next" quickly (ie. a day or two after hitting "test" just enough time to find gross problems). That will allow me to be more pro-active also at pulling things off the mailing list and sticking them there even if some cosmetic changes have been requested to the patch as I will have no issue rebasing it when the new patch comes in. Now, one important rule is: test will be reset at the beginning of every merge window. I will not let it degenerate into the old linuxppc-dev bk tree that drifted for years and had things that never got merged. I'm also not sure whether sub-maintainers should do the same thing with a "test" branch of their own. I certainly don't mind if they rebase their "next" branches so I'm happy for them to play the same game directly into their 'next' branch as long as the day they ask me to pull it into the real 'next', they are reasonably confident that the stuff in there is stable. For any complaint, see my secretary in the Oort cloud. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Benjamin Herrenschmidt wrote: > On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote: >> * Anything that is decided at compiled time should probably go to the arch- >> dependent header. >> >> * Anything that can change at boot time (e.g., for x86 that would include >> the capabilities of the FPU), or even run time (is there any ?) should >> be described to the letter (in fine print) in 'struct cr_hdr_cpu' and >> friends. > > I think we should avoid compile time completely. For instance, TASK_COMM_LEN is currently defined as 16; but in future (or custom) kernel it may be different; so in the task header I put a field that explicitly indicates this length, just in case. I think it's useful to be able to detect such inconsistencies. (of course this example is not arch-specific; and it would be wiser to have one such entry for the entire checkpoint image instead of one for each process) I concur with the rest below. Oren > > We mostly try to have kernels running on everything anyway, and there's > no reason not to be able to move a snapshot to a different CPU if it's > not using a feature of the CPU that is different. > > Nathan, what about you start the structure with a 64 bit bitmask that > indicates what "records" are present followed by concatenated records ? > > IE. The "main" state (pt_regs) wouldn't change, but then, you could have > a list of things: > > - FPRs > - old style VSX > - VSRs > - Freescale SPE state > - DABR > - BookE IAC/DACs > - tbd... > > Then, when resuming a snapshot, we can use some bit masks trickery > indicating the validity on a given target. IE. If CPU has no VSX and > original program uses VSX then you can't resume. But if CPU has VSR you > can.. etc... We can keep it trivial at fist, especting the same > features, and try to be smart later. > > Ben. > > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
On Thu, Feb 05, 2009 at 12:15:31PM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2009-02-04 at 19:35 -0500, Steven Rostedt wrote: > > On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote: > > > On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote: > > > > Remove -fno-omit-frame-pointer flag from CFLAGS. > > > > Remove -fno-omit-frame-pointer workarounds. > > > > > > But what about -pg -requires -fno-omit-frame-pointer ? > > > > I don't think it requires -fno-omit-frame-pointer. It is just > > incompatible with -fomit-frame-pointer. > > From a quick test, you seem to be right. > > Now the question of course is whether -pg will internally trigger > the bug for which we need the workaround tho... According to http://marc.info/?l=linux-kernel&m=121958694215835&w=4 just removing -fno-omit-frame-pointer solved the problem. But I'll double check that on the actual hardware. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
On Wed, 2009-02-04 at 19:35 -0500, Steven Rostedt wrote: > On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote: > > > Remove -fno-omit-frame-pointer flag from CFLAGS. > > > Remove -fno-omit-frame-pointer workarounds. > > > > But what about -pg -requires -fno-omit-frame-pointer ? > > I don't think it requires -fno-omit-frame-pointer. It is just > incompatible with -fomit-frame-pointer. >From a quick test, you seem to be right. Now the question of course is whether -pg will internally trigger the bug for which we need the workaround tho... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
On Wed, Feb 04, 2009 at 07:35:54PM -0500, Steven Rostedt wrote: > > On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote: > > On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote: > > > Remove -fno-omit-frame-pointer flag from CFLAGS. > > > Remove -fno-omit-frame-pointer workarounds. > > > > But what about -pg -requires -fno-omit-frame-pointer ? > > I don't think it requires -fno-omit-frame-pointer. It is just > incompatible with -fomit-frame-pointer. Yep, -fno-omit-frame-poiner isn't needed for -pg. I explained this in http://lkml.org/lkml/2009/2/3/342 : | Ah... | | $ gcc -pg -fomit-frame-pointer -S c.c | gcc: -pg and -fomit-frame-pointer are incompatible | | It's hard-coded in gcc, in the code that don't know about | architecture details. | | But on PowerPC -O1 implies -fomit-frame-pointer, that is | | gcc -pg -O1 -fno-omit-frame-pointer | and | gcc -pg -O1 | | produce different outputs. Thus -pg -O should be the same | as "-pg -O -fomit-framepointer". That is, `gcc -O -pg -fno-omit-frame-pointer -S` output: main: mflr 0 stw 0,4(1) bl _mcount stwu 1,-16(1) mflr 0 stw 0,20(1) stw 31,12(1) mr 31,1 li 3,0 lwz 11,0(1) lwz 0,4(11) mtlr 0 lwz 31,-4(11) mr 1,11 blr ^^ -pg works (_mcount call), but r31 wasted. Now `gcc -O -pg -S` output: main: mflr 0 stw 0,4(1) bl _mcount stwu 1,-16(1) mflr 0 stw 0,20(1) li 3,0 lwz 0,20(1) mtlr 0 addi 1,1,16 blr ^^ _mcount is still there, and r31 isn't used. -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
On Thu, 2009-02-05 at 11:31 +1100, Benjamin Herrenschmidt wrote: > On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote: > > Remove -fno-omit-frame-pointer flag from CFLAGS. > > Remove -fno-omit-frame-pointer workarounds. > > But what about -pg -requires -fno-omit-frame-pointer ? I don't think it requires -fno-omit-frame-pointer. It is just incompatible with -fomit-frame-pointer. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
On Wed, 2009-02-04 at 18:08 +0300, Anton Vorontsov wrote: > Remove -fno-omit-frame-pointer flag from CFLAGS. > Remove -fno-omit-frame-pointer workarounds. But what about -pg -requires -fno-omit-frame-pointer ? Ben. > Signed-off-by: Anton Vorontsov > --- > arch/powerpc/Makefile| 10 ++ > arch/powerpc/kernel/Makefile | 10 +- > arch/powerpc/platforms/powermac/Makefile |2 +- > lib/Kconfig.debug|8 > 4 files changed, 16 insertions(+), 14 deletions(-) > > diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile > index 72d17f5..627aa7f 100644 > --- a/arch/powerpc/Makefile > +++ b/arch/powerpc/Makefile > @@ -120,10 +120,12 @@ ifeq ($(CONFIG_6xx),y) > KBUILD_CFLAGS+= -mcpu=powerpc > endif > > -# Work around a gcc code-gen bug with -fno-omit-frame-pointer. > -ifeq ($(CONFIG_FUNCTION_TRACER),y) > -KBUILD_CFLAGS+= -mno-sched-epilog > -endif > +# Remove -fno-omit-frame-pointer flag. There are two reasons: > +# 1. On powerpc we always have frame pointers. > +# 2. Some gcc versions might generate wrong code with -fno-omit-frame-pointer > +#flag. So, if for some reason you're going to remove this line, then add > +#-mno-sched-epilog to workaround the gcc bug. > +KBUILD_CFLAGS := $(subst -fno-omit-frame-pointer,,$(KBUILD_CFLAGS)) > > cpu-as-$(CONFIG_4xx) += -Wa,-m405 > cpu-as-$(CONFIG_6xx) += -Wa,-maltivec > diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile > index 8d1a419..a97f215 100644 > --- a/arch/powerpc/kernel/Makefile > +++ b/arch/powerpc/kernel/Makefile > @@ -14,14 +14,14 @@ endif > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > -CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog > -CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_cputable.o = -pg > +CFLAGS_REMOVE_prom_init.o = -pg > +CFLAGS_REMOVE_btext.o = -pg > +CFLAGS_REMOVE_prom.o = -pg > > ifdef CONFIG_DYNAMIC_FTRACE > # dynamic ftrace setup. > -CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_ftrace.o = -pg > endif > > endif > diff --git a/arch/powerpc/platforms/powermac/Makefile > b/arch/powerpc/platforms/powermac/Makefile > index 50f1693..0eb8781 100644 > --- a/arch/powerpc/platforms/powermac/Makefile > +++ b/arch/powerpc/platforms/powermac/Makefile > @@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC > > ifdef CONFIG_FUNCTION_TRACER > # Do not trace early boot code > -CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog > +CFLAGS_REMOVE_bootx_init.o = -pg > endif > > obj-y+= pic.o setup.o time.o feature.o pci.o > \ > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 29044f5..657126c 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -402,7 +402,7 @@ config LOCKDEP > bool > depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT > && LOCKDEP_SUPPORT > select STACKTRACE > - select FRAME_POINTER if !X86 && !MIPS && !PPC > + select FRAME_POINTER if !X86 && !MIPS > select KALLSYMS > select KALLSYMS_ALL > > @@ -583,7 +583,7 @@ config FRAME_POINTER > bool "Compile the kernel with frame pointers" > depends on DEBUG_KERNEL && \ > (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ > - AVR32 || SUPERH || BLACKFIN || MN10300) || \ > + AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \ > ARCH_WANT_FRAME_POINTERS > default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS > help > @@ -771,13 +771,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER > depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT > depends on !X86_64 > select STACKTRACE > - select FRAME_POINTER if !PPC > + select FRAME_POINTER > help > Provide stacktrace filter for fault-injection capabilities > > config LATENCYTOP > bool "Latency measuring infrastructure" > - select FRAME_POINTER if !MIPS && !PPC > + select FRAME_POINTER if !MIPS > select KALLSYMS > select KALLSYMS_ALL > select STACKTRACE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
On Wed, 2009-02-04 at 18:44 -0500, Oren Laadan wrote: > * Anything that is decided at compiled time should probably go to the arch- > dependent header. > > * Anything that can change at boot time (e.g., for x86 that would include > the capabilities of the FPU), or even run time (is there any ?) should > be described to the letter (in fine print) in 'struct cr_hdr_cpu' and > friends. I think we should avoid compile time completely. We mostly try to have kernels running on everything anyway, and there's no reason not to be able to move a snapshot to a different CPU if it's not using a feature of the CPU that is different. Nathan, what about you start the structure with a 64 bit bitmask that indicates what "records" are present followed by concatenated records ? IE. The "main" state (pt_regs) wouldn't change, but then, you could have a list of things: - FPRs - old style VSX - VSRs - Freescale SPE state - DABR - BookE IAC/DACs - tbd... Then, when resuming a snapshot, we can use some bit masks trickery indicating the validity on a given target. IE. If CPU has no VSX and original program uses VSX then you can't resume. But if CPU has VSR you can.. etc... We can keep it trivial at fist, especting the same features, and try to be smart later. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> get_user_pages() also gives us the vma back, and we can see from > is_vm_hugetlb_page() (-- BTW can I just say that a function > is_xxx_page() that operates on vmas is horribly misnamed --) that these > pages all come from a hugetlb mapping, but figuring out the size of that > mapping is I guess a challenge. Note that g_u_p() has all sort of shortcommings... we were discussing some of that recently due to bugs reported from the field. The problem mostly is that you cannot guarantee that the physical page will remain mapped to that virtual address in the process. For example, if your code is part of some library used by an application, and that application somewhere does a fork/exec (for example, a system() call to run a shell helper), copy-on-write will hit, and you may end up with the child process getting the original physical page and the original process getting the copy... So your HW will still DMA to a valid page (ie, it's count will have been incremented) but it's not going to be the one the application uses any more. There are similar issues that can be cause, afaik, by madvise, etc... We've been discussing that at KS with various people, Linus says g_u_p() sucks, don't do that :-) Most of the time, the other approach should be used, ie, the driver allocates memory, and userspace mmap's it, in which case you get access to the VMA to set flags such as don't copy on fork. An option possibly would be to make fork() pre-COW pages with an elevated count to ensure that at least the original process is the one to keep the original physical page... but that has other potential side effects or performance issues. A can of worms.. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/1 v3] AMCC PPC 460SX redwood SoC platform initial framework
From: Madhulika Madishetty
This patch contains initial framework for the AMCC Redwood board.
Signed-off-by: Madhulika Madishetty
Signed-off-by: Tirumala Marri
Signed-off-by: Feng Kan
Signed-off-by: Vidhyananth Venkatasamy
Signed-off-by: Preetesh Parekh
Acked-by: Loc Ho
Acked-by: Feng Kan
---
arch/powerpc/boot/dts/redwood.dts | 244 ++
arch/powerpc/configs/44x/redwood_defconfig | 1176
arch/powerpc/kernel/cpu_setup_44x.S|1 +
arch/powerpc/kernel/cputable.c | 13 +
arch/powerpc/platforms/44x/Kconfig | 19 +
arch/powerpc/platforms/44x/ppc44x_simple.c |1 +
6 files changed, 1454 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/redwood.dts
create mode 100644 arch/powerpc/configs/44x/redwood_defconfig
diff --git a/arch/powerpc/boot/dts/redwood.dts
b/arch/powerpc/boot/dts/redwood.dts
new file mode 100644
index 000..ad402c4
--- /dev/null
+++ b/arch/powerpc/boot/dts/redwood.dts
@@ -0,0 +1,244 @@
+/*
+ * Device Tree Source for AMCC Redwood(460SX)
+ *
+ * Copyright 2008 AMCC
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ model = "amcc,redwood";
+ compatible = "amcc,redwood";
+ dcr-parent = <&{/cpus/c...@0}>;
+
+ aliases {
+ ethernet0 = &EMAC0;
+ serial0 = &UART0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ c...@0 {
+ device_type = "cpu";
+ model = "PowerPC,460SX";
+ reg = <0x>;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+ timebase-frequency = <0>; /* Filled in by U-Boot */
+ i-cache-line-size = <32>;
+ d-cache-line-size = <32>;
+ i-cache-size = <32768>;
+ d-cache-size = <32768>;
+ dcr-controller;
+ dcr-access-method = "native";
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x 0x>; /* Filled in by
U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <0>;
+ dcr-reg = <0x0c0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <1>;
+ dcr-reg = <0x0d0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x1e 0x4 0x1f 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <2>;
+ dcr-reg = <0x0e0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0xa 0x4 0xb 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = "ibm,uic-460sx","ibm,uic";
+ interrupt-controller;
+ cell-index = <3>;
+ dcr-reg = <0x0f0 0x009>;
+ #address-cells = <0>;
+ #size-cells = <0>;
+ #interrupt-cells = <2>;
+ interrupts = <0x10 0x4 0x11 0x4>; /* cascade */
+ interrupt-parent = <&UIC0>;
+ };
+
+ SDR0: sdr {
+ compatible = "ibm,sdr-460sx";
+ dcr-reg = <0x00e 0x002>;
+ };
+
+ CPR0: cpr {
+ compatible = "ibm,cpr-460sx";
+ dcr-reg = <0x00c 0x002>;
+ };
+
+ plb {
+ compatible = "ibm,plb-460sx", "ibm,plb4";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges;
+ clock-frequency = <0>; /* Filled in by U-Boot */
+
+ SDRAM0: sdram {
+ compatible = "ibm,sdram-460sx", "ibm,sdram-405gp";
+ dcr-reg = <0x010 0x002>;
+ };
+
+ MAL0: mcmal {
+ compatible = "ibm,mcmal-460sx", "ibm,mcmal2";
+ dcr-reg = <0x180 0x62>;
+ num-tx-chans = <4>;
+ num-
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
>> Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
+struct cr_hdr_cpu {
+ struct pt_regs pt_regs;
+ /* relevant fields from thread_struct */
+ double fpr[32][TS_FPRWIDTH];
+ unsigned int fpscr;
+ int fpexc_mode;
+ /* unsigned int align_ctl; this is never updated? */
+ unsigned long dabr;
+};
>>> Is there some version or other identification somewhere ? If not there
>>> should be. ie, we're going to add things here. For example, what about
>>> the vector registers ? Also, some CPUs will have more HW debug registers
>>> than just the DABR (we plan to add support for all the BookE architected
>>> IACs and DACs for example), etc...
>> The arch-independent checkpoint header does have kernel
>> maj:min:rev:patch info. We expect to have to do more,
>> assuming that the .config can change the arch-dependent
>> cpu header (i.e. perhaps TS_FPRWIDTH could be changed).
>
> It could to a certain extent... things like VSX, VSR, or freescale SPE,
> or even the Cell SPU state etc
>
> I wonder if we want a tagged structure so we can easily add things...
>From the little bit I read hear, I suspect that the sub-arch classification
is best done in an arch-dependent header. I'd follow the following rule
of thumb:
* Anything that is decided at compiled time should probably go to the arch-
dependent header.
* Anything that can change at boot time (e.g., for x86 that would include
the capabilities of the FPU), or even run time (is there any ?) should
be described to the letter (in fine print) in 'struct cr_hdr_cpu' and
friends.
Oren.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Dynamic-ftrace not working in PlayStation3
> OK, I've been able to reproduce it. It looks like the assumptions of the > trampoline that I've made is not correct if the size of the module is over > some limit. I had to make usb-core into a module, and I see the same > bug. > > I'll take a deeper look into it. Thanks ! I've been a bit swamped lately and didn't get a chance to dig into that one .. yet. Let me know if you are stuck tho. Cheers Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] arch/powerpc: Eliminate double sizeof
Julia Lawall wrote: Signed-off-by: Julia Lawall --- arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c --- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c +++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c @@ -186,7 +186,7 @@ out_unmap_regs: iounmap(priv->regs); out_free_bootmem: free_bootmem((unsigned long)priv, -sizeof(sizeof(struct pq2ads_pci_pic))); +sizeof(struct pq2ads_pci_pic)); of_node_put(np); out_unmap_irq: irq_dispose_mapping(irq); ACK -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] arch/powerpc: Eliminate double sizeof
From: Julia Lawall Taking sizeof the result of sizeof is quite strange and does not seem to be what is wanted here. This was fixed using the following semantic patch. (http://www.emn.fr/x-info/coccinelle/) // @@ expression E; @@ - sizeof ( sizeof (E) - ) @@ type T; @@ - sizeof ( sizeof (T) - ) // Signed-off-by: Julia Lawall --- arch/powerpc/platforms/82xx/pq2ads-pci-pic.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -u -p a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c --- a/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c +++ b/arch/powerpc/platforms/82xx/pq2ads-pci-pic.c @@ -186,7 +186,7 @@ out_unmap_regs: iounmap(priv->regs); out_free_bootmem: free_bootmem((unsigned long)priv, -sizeof(sizeof(struct pq2ads_pci_pic))); +sizeof(struct pq2ads_pci_pic)); of_node_put(np); out_unmap_irq: irq_dispose_mapping(irq); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Dynamic-ftrace not working in PlayStation3
On Sat, 31 Jan 2009, Arnd Bergmann wrote: > On Saturday 31 January 2009, Geoff Levand wrote: > > > > > > So I take it that the above showed that the code worked for some? > > > > In my trials it blows up on the first load_module() call, and for my > > config that was usbcore: > > I looked into it some more with Remis yesterday, and we got ftrace > working by building usbcore and alsa into the kernel. Incidentally, > usbcore is the largest module in this installation (~3MB), which > indicates that it is in some way either related to the size of the > module. > > > This ptr of 5f666f725f726573 seems bogus. I think this code is not > > working correctly: > > This is an ascii string "_for_res", probably part of > usb_lock_device_for_reset. We saw the same behaviour, but > a different string. OK, I've been able to reproduce it. It looks like the assumptions of the trampoline that I've made is not correct if the size of the module is over some limit. I had to make usb-core into a module, and I see the same bug. I'll take a deeper look into it. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Add platform support for AmigaOne
On Wed, Feb 04, 2009 at 10:35:31PM +0100, Gerhard Pircher wrote: > > Original-Nachricht > > Datum: Wed, 4 Feb 2009 21:59:41 +0100 > > Von: Gabriel Paubert > > An: Benjamin Herrenschmidt > > CC: Gerhard Pircher , linuxppc-dev list > > > > Betreff: Re: [PATCH v2 1/4] Add platform support for AmigaOne > > > On Wed, Feb 04, 2009 at 02:50:07PM +1100, Benjamin Herrenschmidt wrote: > > > > > > > + hose->first_busno = bus_range ? bus_range[0] : 0; > > > > + hose->last_busno = bus_range ? bus_range[1] : 0xff; > > > > + > > > > + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0); > > > > > > Minor in the context of amigaone but still... the above should come > > > from the device-tree... I suppose those are really just IO space > > > addresses cf8 and cfc, in which case, an option is to call that first: > > > > Hmm, the first is feC...,the other one feE..., 2Mbytes apart. > > > > I don't know the hardware but I've never seen something like that. > > Of course a typo is always a possibility... > The Pegasos 1 uses the same northbridge and chrp_find_bridges() calls > setup_indirect_pci() with the same addresses. As a proud owner, I concur that those numbers are correct... -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Add platform support for AmigaOne
Original-Nachricht > Datum: Wed, 4 Feb 2009 21:59:41 +0100 > Von: Gabriel Paubert > An: Benjamin Herrenschmidt > CC: Gerhard Pircher , linuxppc-dev list > > Betreff: Re: [PATCH v2 1/4] Add platform support for AmigaOne > On Wed, Feb 04, 2009 at 02:50:07PM +1100, Benjamin Herrenschmidt wrote: > > > > > + hose->first_busno = bus_range ? bus_range[0] : 0; > > > + hose->last_busno = bus_range ? bus_range[1] : 0xff; > > > + > > > + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0); > > > > Minor in the context of amigaone but still... the above should come > > from the device-tree... I suppose those are really just IO space > > addresses cf8 and cfc, in which case, an option is to call that first: > > Hmm, the first is feC...,the other one feE..., 2Mbytes apart. > > I don't know the hardware but I've never seen something like that. > Of course a typo is always a possibility... The Pegasos 1 uses the same northbridge and chrp_find_bridges() calls setup_indirect_pci() with the same addresses. Gerhard -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> You should be able to find the head of a compound page using the > compound_head() inline, so try > PAGE_SIZE << compound_order(compound_head(page)) Thanks! Looks like that should be exactly what we need. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
* Anton Vorontsov wrote:
> This patch gives arches more freedom on overwriting CFLAGS, specifically
> on PowerPC we want to remove -fno-omit-frame-pointer flag.
>
> Signed-off-by: Anton Vorontsov
> ---
> Makefile |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 7715b2c..d1ba93f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -525,8 +525,6 @@ else
> KBUILD_CFLAGS+= -O2
> endif
>
> -include $(srctree)/arch/$(SRCARCH)/Makefile
> -
> ifneq (CONFIG_FRAME_WARN,0)
> KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
> endif
> @@ -555,6 +553,8 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
> KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
> endif
>
> +include $(srctree)/arch/$(SRCARCH)/Makefile
> +
> # arch Makefile may override CC so keep this after arch Makefile is included
> NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> CHECKFLAGS += $(NOSTDINC_FLAGS)
> --
this patch is really for Sam to judge - Cc:-ed him.
Ingo
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wed, 04 Feb 2009 11:11:22 -0800 Roland Dreier wrote: > > > > huge_page_size(page_hstate(page)) > > > > That would suit. I assume the intention is for that to be usable by > > > driver modules on any architecture? > > > erm, you overestimate the amount of planning and forethought which goes > > into these things ;) > > > The lack of any EXPORT_SYMBOL(size_to_hstate) is a broadish hint. > > Heh. Looking into the implementation, it seems that I could actually do > > PAGE_SIZE << compound_order(page) > > directly (since there's no reason to go from size to hstate and back to > size. I don't know all the details of these VM internals, but that > seems to only work on the first (small) page of a giant page? Which > causes problems for what we're trying to do here... > > To summarize the goal, we are mapping user memory to a device that has > its own page tables, where the device's page tables can also use > multiple page sizes. Using big pages on the device leads to similar > efficiencies as hugetlb pages do on the CPU, and in fact if a user has > used hugetlb pages for the memory they're giving to the device, that's a > very strong hint that the device should use big pages too. > > But one valid situation we have to handle in the driver is if, say, > userspace has a hugetlb mapped at virtual address 0x20, and wants to > map 0x8 bytes at 0x28 to the device. In that case, we're going > to do essentially > > get_user_pages(..., 0x28, 0x8 / PAGE_SIZE, ...) > > and get_user_pages() is going to give us a bunch of normal PAGE_SIZE > pages starting at offset 0x80 within the compound page that makes up > the huge page mapped at 0x20. > > get_user_pages() also gives us the vma back, and we can see from > is_vm_hugetlb_page() (-- BTW can I just say that a function > is_xxx_page() that operates on vmas is horribly misnamed --) that these > pages all come from a hugetlb mapping, but figuring out the size of that > mapping is I guess a challenge. compound_head() will convert any page* inside a hugepage into a pointer to the head page. It should work OK for regular pages as well as CONFIG_HUGETLB=n. So.. PAGE_SIZE << compound_order(compound_head(page)) ? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
On Wed, Feb 04, 2009 at 11:11:22AM -0800, Roland Dreier wrote: > Heh. Looking into the implementation, it seems that I could actually do > PAGE_SIZE << compound_order(page) > directly (since there's no reason to go from size to hstate and back to > size. I don't know all the details of these VM internals, but that > seems to only work on the first (small) page of a giant page? Which > causes problems for what we're trying to do here... You should be able to find the head of a compound page using the compound_head() inline, so try PAGE_SIZE << compound_order(compound_head(page)) -- wli ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Add platform support for AmigaOne
On Wed, Feb 04, 2009 at 02:50:07PM +1100, Benjamin Herrenschmidt wrote: > > > + hose->first_busno = bus_range ? bus_range[0] : 0; > > + hose->last_busno = bus_range ? bus_range[1] : 0xff; > > + > > + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0); > > Minor in the context of amigaone but still... the above should come from > the device-tree... I suppose those are really just IO space addresses > cf8 and cfc, in which case, an option is to call that first: Hmm, the first is feC...,the other one feE..., 2Mbytes apart. I don't know the hardware but I've never seen something like that. Of course a typo is always a possibility... Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
On Wed, 2009-02-04 at 09:54 -0600, Serge E. Hallyn wrote:
> Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
> >
> > > +struct cr_hdr_cpu {
> > > + struct pt_regs pt_regs;
> > > + /* relevant fields from thread_struct */
> > > + double fpr[32][TS_FPRWIDTH];
> > > + unsigned int fpscr;
> > > + int fpexc_mode;
> > > + /* unsigned int align_ctl; this is never updated? */
> > > + unsigned long dabr;
> > > +};
> >
> > Is there some version or other identification somewhere ? If not there
> > should be. ie, we're going to add things here. For example, what about
> > the vector registers ? Also, some CPUs will have more HW debug registers
> > than just the DABR (we plan to add support for all the BookE architected
> > IACs and DACs for example), etc...
>
> The arch-independent checkpoint header does have kernel
> maj:min:rev:patch info. We expect to have to do more,
> assuming that the .config can change the arch-dependent
> cpu header (i.e. perhaps TS_FPRWIDTH could be changed).
It could to a certain extent... things like VSX, VSR, or freescale SPE,
or even the Cell SPU state etc
I wonder if we want a tagged structure so we can easily add things...
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull 'next' branch of linux-2.6-mpc52xx.git
And I really mean -next this time. :-) The following changes since commit b1792e367053968f2ddb48bc911d314143ce6242: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../jbarnes/pci-2.6 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx.git next Grant Likely (7): powerpc/5200: Stop using device_type and port-number properties powerpc/5200: Trim cruft from device trees powerpc/5200: Don't specify IRQF_SHARED in PSC UART driver powerpc/5200: Remove pr_debug() from hot paths in irq driver powerpc/5200: Refactor mpc5200 interrupt controller driver powerpc/5200: Rework GPT driver to also be an IRQ controller powerpc/5200: Add support for the Media5200 board from Freescale Grzegorz Bernacki (1): powerpc/5200: Add support for the digsy MTC board. arch/powerpc/boot/Makefile |4 +- arch/powerpc/boot/dts/cm5200.dts | 49 +--- arch/powerpc/boot/dts/digsy_mtc.dts | 254 +++ arch/powerpc/boot/dts/lite5200.dts | 52 +--- arch/powerpc/boot/dts/lite5200b.dts | 63 +--- arch/powerpc/boot/dts/media5200.dts | 318 +++ arch/powerpc/boot/dts/motionpro.dts | 42 +-- arch/powerpc/boot/dts/pcm030.dts | 182 --- arch/powerpc/boot/dts/tqm5200.dts| 32 +-- arch/powerpc/platforms/52xx/Kconfig | 12 +- arch/powerpc/platforms/52xx/Makefile |3 +- arch/powerpc/platforms/52xx/media5200.c | 273 arch/powerpc/platforms/52xx/mpc5200_simple.c |1 + arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 85 - arch/powerpc/platforms/52xx/mpc52xx_gpt.c| 435 ++ arch/powerpc/platforms/52xx/mpc52xx_pic.c| 170 --- drivers/net/fec_mpc52xx.c|6 +- drivers/serial/mpc52xx_uart.c| 40 +-- 18 files changed, 1476 insertions(+), 545 deletions(-) create mode 100644 arch/powerpc/boot/dts/digsy_mtc.dts create mode 100644 arch/powerpc/boot/dts/media5200.dts create mode 100644 arch/powerpc/platforms/52xx/media5200.c create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2 1/4] Add platform support for AmigaOne
On Wed, 2009-02-04 at 13:09 +0100, Gerhard Pircher wrote: > I agree that these addresses should come from the device-tree, but these > two config registers are not located within the normal PCI I/O address > space (0xfe00-0xfec0). > Maybe I should add a "reg" property to the PHB node, but I don't know if > this is the right approach. The OF PCI spec isn't very clear about this. > What do you think? Yup, "reg" in the PHB is what most machines use for that. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller
Hey Wolfram, thanks for the review.
On Wed, Feb 4, 2009 at 12:55 PM, Wolfram Sang wrote:
>
> I have been told to move such a changelog below the dashed lines,
> because it is not so important for the git-history.
This is only in my email for review purposes. It won't be in the git commit.
>> + status = in_be32(&gpt->regs->status) | MPC52xx_GPT_STATUS_IRQMASK;
>
> Like I mentioned in my first review, the following if-clause is always
> true. You probably mean "& MPC52xx_GPT_STATUS_IRQMASK"?
You're right. I missed this from your first review. Fixed.
>> +/* -
>> + * GPIOLIB hooks
>> + */
>> +#if defined(CONFIG_GPIOLIB)
>> +static inline struct mpc52xx_gpt_priv *gc_to_mpc52xx_gpt(struct gpio_chip
>> *gc)
>> +{
>> + return container_of(to_of_gpio_chip(gc), struct
>> mpc52xx_gpt_priv,of_gc);
>
> Space after ','. As it is now, this is a checkpatch-error. Lines over 80
> chars are a warning.
This is on purpose as I described earlier. Checkpatch is not God, and
the cure is worse than the disease. (Granted, the disease is
equivalent to a running nose, and the cure to cheap kleenex, but hey,
it's still my decision).
>> +#else /* defined(CONFIG_SYSFS) */
>> +static void mpc52xx_gpt_create_attribs(struct mpc52xx_gpt_priv *) { return
>> 0; }
>> +#endif /* defined(CONFIG_SYSFS) */
>
> Hmmm, I still have problems with this sysfs-entry. If you say that this
> is good for debugging, then please make it #DEBUG at least. Imagine
> every driver doing such things, this adds bloat. I'd still rather
> suggest using
>
> ~ memedit /dev/mem
> -> map 0x4000
> -> md 0x600
>
> which does the same and even allows for more (writing for example).
I understand your argument, but I'm still going to leave it in and
leave it enabled for now. I will consider removing it after a release
or too.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...
On Wed, Feb 4, 2009 at 2:14 PM, Alan Nishioka wrote: > request_firmware uses the hotplug code so the kernel doesn't have any > sourceless binaries compiled into it. on init, the driver requests the > firmware, user mode hotplug daemon loads the firmware from disk and gives > the driver a pointer to it. > > since this is a short term problem, i would suggest converting rt73.bin to > a header file and compiling it into the kernel. you have to make a few > minor changes to where request_firmware is called, but in the end firmware > is just an array of bytes with a pointer to it. this is what i did when i > was testing usb wifi a little while ago. > > i am probably going to open source hell for suggesting this, but i'm a > hardware engineer, so i am in hell already. > > alan nishioka Yes, you will certainly burn for this. :-) Mike Timmons: I'll show you how MINE works (and if someone out there can point out errors, fire away -- I'm not making the claim that this is completely correct). I hope that this will be new and helpful information for you. If it's not, my apologies; feel free to dump this in the bit bucket. In my /sbin/hotplug I have a bunch of stuff for doing field updates, but at the very bottom, I have this: if [ "$1" == "firmware" ] && [ "$ACTION" == "add" ]; then echo 1 > /sys/$DEVPATH/loading cat /lib/firmware/$FIRMWARE > /sys/$DEVPATH/data echo 0 > /sys/$DEVPATH/loading echo "RT73 firmware loaded." > /dev/console fi That's how the firmware is loaded. caveat: I am using 2.6.25 in my system. I have no idea what's changed from .24 to .25 that might be getting in your way. You could consider moving just the section in .25 that deals with the chipsets in question (ralink, I think??). I put all this together in about an hour after doing a little reading. It all works very well. Now if I could just get that pesky AP mode working... Also in my hotplug script is if [ "$1" == "net" ] && [ "$ACTION" == "add" ] && [ "$INTERFACE" == "wlan0" ]; then iwconfig wlan0 mode managed iwconfig wlan0 channel auto iwconfig wlan0 key DADADADADADADADADADADADADA iwconfig wlan0 essid mlxwap fi You will want to get the sources for the wifi utilities compiled for your target, too. Not hard to do. I don't think I had to make any changes to it. Those who wish, feel free to post suggestions, etc. I'm doing all of my work on an ARM target, so I don't know if there are any gotchas in the rt drivers for the rt73 usb stuff. Also, you could check out rt2x00.serialmonkey.com if you haven't found it. They are live (well, mostly dead) on #rt2x00 on freenode. Good luck; if you have questions, feel free to email me directly. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Calling wait_event_interruptible_timeout() in I2C wait functions
Timur Tabi wrote: > However, it appears that this is not common behavior for I2C driver. In > fact, only these six drivers ever call wait_event_interruptible_timeout(): > > i2c-cpm.c I don't know about the others, but in i2c-cpm.c the use of interruptible wait seems incorrect. Maybe it could be made correct, but as is, it does not correctly clean up the hardware state or return a useful value when interrupted by a signal. It's not clear what to do, anyway - it's hard to know which messages of the interrupted transaction have actually taken effect in the hardware. I think it's better to use uninterruptible wait here and just live with the delayed signal handling (one second delay in the unlikely worst case for i2c-cpm). In general, I think it's best to consider I2C I/O to be uninterruptible, like disk I/O. The only reason to make it interruptible is to make sure you don't end up with an unkillable process due to an I/O error, and that is adequately handled by a timeout (and re-initialization of the I2C interface in that case). -=] Mike [=- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller
Hello Grant,
On Wed, Feb 04, 2009 at 11:23:05AM -0700, Grant Likely wrote:
> From: Grant Likely
>
> This patch adds IRQ controller support to the MPC5200 General
> Purpose Timer (GPT) device driver. With this patch the mpc5200-gpt
> driver supports both GPIO and IRQ functions.
>
> The GPT driver was contained within the mpc52xx_gpio.c file, but this
> patch moves it out into a new file (mpc52xx_gpt.c) since it has more
> than just GPIO functionality now and it was only grouped with the
> mpc52xx-gpio drivers as a matter of convenience before. Also, this
> driver will most likely get extended again to also provide support
> for the timer function.
>
> Implementation note: Alternately, I could have tried to implement
> the IRQ support as a separate driver and left the GPIO portion alone.
> However, multiple functions of this device (ie. GPIO input+interrupt
> controller, or timer+GPIO) can be active at the same time and the
> registers are shared so it is safer to contain all functionality
> within a single driver.
>
> v4 changes:
> - Fix compile error when GPIOLIB is not enabled.
> v3 changes:
> - Use set/clbits() for manipulating registers
> - Fix incorrect comments
> - Other minor tidying
> v2 changes:
> - Removed magic numbers
> - Only set to GPIO mode if it has the gpio-controller property. Otherwise
> leave the configuration alone. Firmware may have already configured it.
I have been told to move such a changelog below the dashed lines,
because it is not so important for the git-history.
>
> Signed-off-by: Grant Likely
> ---
>
> Here is what I hope to be the last version of this patch. This version fixes
> a compile error when GPIO support is not compiled into the kernel. I've
> pushed this out to my -next tree. I'll be asking Ben to pull it tomorrow.
Sorry, but it still has issues. This review in a hurry leaves me with a
bit uneasy feelings, still, if the remaining issues get resolved, you
may add my
Reviewed-by: Wolfram Sang
>
> g.
>
> arch/powerpc/platforms/52xx/Makefile |2
> arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 85 -
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 435
>
> 3 files changed, 436 insertions(+), 86 deletions(-)
> create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c
>
>
> diff --git a/arch/powerpc/platforms/52xx/Makefile
> b/arch/powerpc/platforms/52xx/Makefile
> index 9dfbde2..bfd4f52 100644
> --- a/arch/powerpc/platforms/52xx/Makefile
> +++ b/arch/powerpc/platforms/52xx/Makefile
> @@ -1,7 +1,7 @@
> #
> # Makefile for 52xx based boards
> #
> -obj-y+= mpc52xx_pic.o mpc52xx_common.o
> +obj-y+= mpc52xx_pic.o mpc52xx_common.o
> mpc52xx_gpt.o
> obj-$(CONFIG_PCI)+= mpc52xx_pci.o
>
> obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
> diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> index 07f89ae..2b8d8ef 100644
> --- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> +++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
> @@ -354,88 +354,6 @@ static struct of_platform_driver
> mpc52xx_simple_gpiochip_driver = {
> .remove = mpc52xx_gpiochip_remove,
> };
>
> -/*
> - * GPIO LIB API implementation for gpt GPIOs.
> - *
> - * Each gpt only has a single GPIO.
> - */
> -static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - return (in_be32(®s->status) & (1 << (31 - 23))) ? 1 : 0;
> -}
> -
> -static void
> -mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - if (val)
> - out_be32(®s->mode, 0x34);
> - else
> - out_be32(®s->mode, 0x24);
> -
> - pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> -}
> -
> -static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
> -{
> - struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
> - struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
> -
> - out_be32(®s->mode, 0x04);
> -
> - return 0;
> -}
> -
> -static int
> -mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
> -{
> - mpc52xx_gpt_gpio_set(gc, gpio, val);
> - pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
> -
> - return 0;
> -}
> -
> -static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
> - const struct of_device_id *match)
> -{
> - struct of_mm_gpio_chip *mmchip;
> - struct of_gpio_chip *chip;
> -
> - mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
> - if (!mmchip)
> - return -ENOMEM;
> -
> - chip = &mmchip->of_gc;
> -
> - chip->gpio_cells = 2;
> -
Re: kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...
request_firmware uses the hotplug code so the kernel doesn't have any sourceless binaries compiled into it. on init, the driver requests the firmware, user mode hotplug daemon loads the firmware from disk and gives the driver a pointer to it. since this is a short term problem, i would suggest converting rt73.bin to a header file and compiling it into the kernel. you have to make a few minor changes to where request_firmware is called, but in the end firmware is just an array of bytes with a pointer to it. this is what i did when i was testing usb wifi a little while ago. i am probably going to open source hell for suggesting this, but i'm a hardware engineer, so i am in hell already. alan nishioka Mike Timmons wrote: I received great help last week in getting a USB wi fi device working. Thanks again, but can someone read below and advise me on kernel 2.6.24? The best out-of-the box solution for me was 2.6.27.8, for which I needed a Denx eldx toolchain in place of the toolchain I was using to compile 2.6.24. The significance of all this is that I did get USB wi fi working, but... I'm not in a position to upgrade from 2.6.24 at this time. I need to get the USB wi wi (Linksys WUSB54GC) working under 2.6.24. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: FW: [PATCH] powerpc/mm: Export HPAGE_SHIFT
> > > huge_page_size(page_hstate(page)) > > That would suit. I assume the intention is for that to be usable by > > driver modules on any architecture? > erm, you overestimate the amount of planning and forethought which goes > into these things ;) > The lack of any EXPORT_SYMBOL(size_to_hstate) is a broadish hint. Heh. Looking into the implementation, it seems that I could actually do PAGE_SIZE << compound_order(page) directly (since there's no reason to go from size to hstate and back to size. I don't know all the details of these VM internals, but that seems to only work on the first (small) page of a giant page? Which causes problems for what we're trying to do here... To summarize the goal, we are mapping user memory to a device that has its own page tables, where the device's page tables can also use multiple page sizes. Using big pages on the device leads to similar efficiencies as hugetlb pages do on the CPU, and in fact if a user has used hugetlb pages for the memory they're giving to the device, that's a very strong hint that the device should use big pages too. But one valid situation we have to handle in the driver is if, say, userspace has a hugetlb mapped at virtual address 0x20, and wants to map 0x8 bytes at 0x28 to the device. In that case, we're going to do essentially get_user_pages(..., 0x28, 0x8 / PAGE_SIZE, ...) and get_user_pages() is going to give us a bunch of normal PAGE_SIZE pages starting at offset 0x80 within the compound page that makes up the huge page mapped at 0x20. get_user_pages() also gives us the vma back, and we can see from is_vm_hugetlb_page() (-- BTW can I just say that a function is_xxx_page() that operates on vmas is horribly misnamed --) that these pages all come from a hugetlb mapping, but figuring out the size of that mapping is I guess a challenge. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
MPC5200 PCI Issues
I am currently trying to get an MPC5200-based board to run Linux
2.6.28. Most of the devices are working, however i have some issues
with the PCI-bus. More precisely, the issue is that all of
the cards' IO-regions are mapped to address 0x0.
In my device tree I have the following:
p...@fd00 {
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
reg = <0xfd00 0x100>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0xb000 0 0 1 &mpc5200_pic 0 0 3 // MPC5200
0xb000 0 0 2 &mpc5200_pic 0 0 3
0xb000 0 0 3 &mpc5200_pic 0 0 3
0xb000 0 0 4 &mpc5200_pic 0 0 3
0xb800 0 0 1 &mpc5200_pic 1 1 3 // c64x0
0xb800 0 0 2 &mpc5200_pic 1 1 3
0xb800 0 0 3 &mpc5200_pic 1 1 3
0xb800 0 0 4 &mpc5200_pic 1 1 3
0xc000 0 0 1 &mpc5200_pic 1 1 3 // c64x1
0xc000 0 0 2 &mpc5200_pic 1 1 3
0xc000 0 0 3 &mpc5200_pic 1 1 3
0xc000 0 0 4 &mpc5200_pic 1 1 3
0xc800 0 0 1 &mpc5200_pic 1 1 3 // c64x2
0xc800 0 0 2 &mpc5200_pic 1 1 3
0xc800 0 0 3 &mpc5200_pic 1 1 3
0xc800 0 0 4 &mpc5200_pic 1 1 3
0xd000 0 0 1 &mpc5200_pic 1 1 3 // c64x3
0xd000 0 0 2 &mpc5200_pic 1 1 3
0xd000 0 0 3 &mpc5200_pic 1 1 3
0xd000 0 0 4 &mpc5200_pic 1 1 3
0xd800 0 0 1 &mpc5200_pic 1 1 3 // c64x4
0xd800 0 0 2 &mpc5200_pic 1 1 3
0xd800 0 0 3 &mpc5200_pic 1 1 3
0xd800 0 0 4 &mpc5200_pic 1 1 3>;
clock-frequency = <0x1e84800>; //<0>; // From boot loader
interrupts = <2 8 0 2 9 0 2 10 0>;
interrupt-parent = <&mpc5200_pic>;
bus-range = <0 0>;
ranges = <0x0200 0 0x5000 0x5000 0 0x1000
0x0100 0 0x 0x6000 0 0x0100>;
};
The cards' memory regions are mapped out fine to different addresses
in the 0x5000-0x6000 range. However, the IO regions are all mapped
to zero.
Do you have any idea on what could be wrong or in which direction I
should be looking?
--
Hälsningar/Regards
Tobias Knutsson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Maple PPC970 kexec crash-dump problems
Hi Milton, I've tracked it down to the device tree passed to the second kernel being screwed-up when patched by kexec-tools. Namely, it was creating linux,usable-memory entries that were wrong, and the MMU initialization hung when it failed allocating for the page tables. I hacked the tool, and got passed that point in the init sequence, but the very first IO mapped access fails, so the MMU doesn't seem to be set up correctly. Anyway, up to my question: is the crash dump (kdump) kernel supposed to use the memory reserved for it by the first kernel for its working memory ? e.g. On that board, I have 0->2GB and 4->6GB for a total of 4GB of RAM. Let's say I reserve 1...@32m, that's 0x200->0xa00. Is the second kernel supposed to use (0x200+) -> 0xa00 for its memory pool and leave everything else: 0->0x200, 0xa00 -> 8000, 0x1 -> 0x18000 as memory that is from the first kernel, used to debug it ? Basically, I am trying to figure out if I patched the tool correctly. Thanks, Ben On Sat, Jan 24, 2009 at 2:52 AM, Milton Miller wrote: > On Sat Jan 24 at 07:59:47 EST in 2009, Benjamin Walsh wrote: > >> I am trying to use kexec with a crash dump kernel on a Maple board >> (Motorola >> ATCA6101 to be precise). This board is running a two-CPU PPC970FX. I am >> running a 2.6.27-10 kernel and have tried both older kexec-tools and the >> newest ones. I have tried SMP and non-SMP kernels. >> > > Once you start the second cpu it is likly executing instructions somewhere. > > Priory to 2.6.27 you had to compile a fixxed offset kerenl to run kdump. > With 2.6.27 that option was removed and replaced with teh relocatable > kerenl. However, becasue of the way linux interacts with open firmware, the > kernel will still move itself to 0 unless a specific flag is set. The > location of the flag was changed twice during the merge process, and the > patches for kexec-tools were not made until early this year. > > Using kexec -l to fast boot works correctly. However, loading a crash dump >> kernel and triggering a crash via echo c > /proc/sysrq-trigger simply >> hangs >> the board. I have traced the sequence down to after the call to >> kexec_copy_flush(), when the CPU returns to real-address mode (bl >> real_mode). At this point I have no further debugging information. >> > > > Two things could help me: >> >> - Getting the fix if this is a known issue and a fix exists. I have looked >> at recent patches and nothing lept to mind, mostly relocatable kernel >> support. >> > > That is a major change. > > That said, I don't know if anyone has tested kexec panic beyond pseries for > 64 bit powerpc. > > I know Paul originally prototyped the relocatable patch on a powermac, but > I dont' know what if any smp testing he performed. And you said you are > actualy on maple not a powermac, so the startup issues are different. > > - Obtaining the address of the serial port @3f8 in real mode. The init >> sequence with udbg ON says that the physical address of the port is >> 0xf40003f8; however, setting it up in poll mode and trying to stuff >> characters in the tx buffer doesn't produce anything. >> > > Ah yes. In real mode you can only talk to cacheable memory without > implementation specific assistance. However, if you look in the kernel for > the maple early udbg support, you will find the code you need to talk to > that serial port in real mode. > > >> Has anyone recently tried to use the serial port in real mode ? >> >> Thanks for any help. >> >> Ben >> > > Hope this gets you started. I wrote a lot of the kernel code, but I had > the advantage of external jtag access to the processor to see where it when > ended up when it went astray. > > milton > > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v4] powerpc/5200: Rework GPT driver to also be an IRQ controller
From: Grant Likely
This patch adds IRQ controller support to the MPC5200 General
Purpose Timer (GPT) device driver. With this patch the mpc5200-gpt
driver supports both GPIO and IRQ functions.
The GPT driver was contained within the mpc52xx_gpio.c file, but this
patch moves it out into a new file (mpc52xx_gpt.c) since it has more
than just GPIO functionality now and it was only grouped with the
mpc52xx-gpio drivers as a matter of convenience before. Also, this
driver will most likely get extended again to also provide support
for the timer function.
Implementation note: Alternately, I could have tried to implement
the IRQ support as a separate driver and left the GPIO portion alone.
However, multiple functions of this device (ie. GPIO input+interrupt
controller, or timer+GPIO) can be active at the same time and the
registers are shared so it is safer to contain all functionality
within a single driver.
v4 changes:
- Fix compile error when GPIOLIB is not enabled.
v3 changes:
- Use set/clbits() for manipulating registers
- Fix incorrect comments
- Other minor tidying
v2 changes:
- Removed magic numbers
- Only set to GPIO mode if it has the gpio-controller property. Otherwise
leave the configuration alone. Firmware may have already configured it.
Signed-off-by: Grant Likely
---
Here is what I hope to be the last version of this patch. This version fixes
a compile error when GPIO support is not compiled into the kernel. I've
pushed this out to my -next tree. I'll be asking Ben to pull it tomorrow.
g.
arch/powerpc/platforms/52xx/Makefile |2
arch/powerpc/platforms/52xx/mpc52xx_gpio.c | 85 -
arch/powerpc/platforms/52xx/mpc52xx_gpt.c | 435
3 files changed, 436 insertions(+), 86 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc52xx_gpt.c
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index 9dfbde2..bfd4f52 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -1,7 +1,7 @@
#
# Makefile for 52xx based boards
#
-obj-y += mpc52xx_pic.o mpc52xx_common.o
+obj-y += mpc52xx_pic.o mpc52xx_common.o mpc52xx_gpt.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index 07f89ae..2b8d8ef 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -354,88 +354,6 @@ static struct of_platform_driver
mpc52xx_simple_gpiochip_driver = {
.remove = mpc52xx_gpiochip_remove,
};
-/*
- * GPIO LIB API implementation for gpt GPIOs.
- *
- * Each gpt only has a single GPIO.
- */
-static int mpc52xx_gpt_gpio_get(struct gpio_chip *gc, unsigned int gpio)
-{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
- struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
-
- return (in_be32(®s->status) & (1 << (31 - 23))) ? 1 : 0;
-}
-
-static void
-mpc52xx_gpt_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
-{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
- struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
-
- if (val)
- out_be32(®s->mode, 0x34);
- else
- out_be32(®s->mode, 0x24);
-
- pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
-}
-
-static int mpc52xx_gpt_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
-{
- struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
- struct mpc52xx_gpt __iomem *regs = mm_gc->regs;
-
- out_be32(®s->mode, 0x04);
-
- return 0;
-}
-
-static int
-mpc52xx_gpt_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
-{
- mpc52xx_gpt_gpio_set(gc, gpio, val);
- pr_debug("%s: gpio: %d val: %d\n", __func__, gpio, val);
-
- return 0;
-}
-
-static int __devinit mpc52xx_gpt_gpiochip_probe(struct of_device *ofdev,
- const struct of_device_id *match)
-{
- struct of_mm_gpio_chip *mmchip;
- struct of_gpio_chip *chip;
-
- mmchip = kzalloc(sizeof(*mmchip), GFP_KERNEL);
- if (!mmchip)
- return -ENOMEM;
-
- chip = &mmchip->of_gc;
-
- chip->gpio_cells = 2;
- chip->gc.ngpio= 1;
- chip->gc.direction_input = mpc52xx_gpt_gpio_dir_in;
- chip->gc.direction_output = mpc52xx_gpt_gpio_dir_out;
- chip->gc.get = mpc52xx_gpt_gpio_get;
- chip->gc.set = mpc52xx_gpt_gpio_set;
-
- return of_mm_gpiochip_add(ofdev->node, mmchip);
-}
-
-static const struct of_device_id mpc52xx_gpt_gpiochip_match[] = {
- {
- .compatible = "fsl,mpc5200-gpt-gpio",
- },
- {}
-};
-
-static struct of_platform_driver mpc52xx_gpt_gpiochip_driver = {
- .name = "gpio_gpt",
- .match_ta
Re: MPC5200 PCI Issues
On Wed, Feb 4, 2009 at 9:53 AM, Tobias Knutsson wrote: > clock-frequency = <0x1e84800>; //<0>; // From boot loader > interrupts = <2 8 0 2 9 0 2 10 0>; > interrupt-parent = <&mpc5200_pic>; > bus-range = <0 0>; > ranges = <0x0200 0 0x5000 0x5000 0 0x1000 > 0x0100 0 0x 0x6000 0 0x0100>; > }; > > The cards' memory regions are mapped out fine to different addresses > in the 0x5000-0x6000 range. However, the IO regions are all mapped > to zero. > > Do you have any idea on what could be wrong or in which direction I > should be looking? Hmmm. Your ranges property looks okay to me. The MPC5200 setup code may be doing the wrong thing. Turn on debug at the top of arch/powerpc/platforms/mpc52xx/mpc52xx_pci.c and post your kernel output. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
2009/2/4 Steven Rostedt : > > >From ftrace.h: > > #ifdef CONFIG_FRAME_POINTER > /* TODO: need to fix this for ARM */ > # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) > # define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1)) > # define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2)) > # define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3)) > # define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4)) > # define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5)) > # define CALLER_ADDR6 ((unsigned long)__builtin_return_address(6)) > #else > # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) > # define CALLER_ADDR1 0UL > # define CALLER_ADDR2 0UL > # define CALLER_ADDR3 0UL > # define CALLER_ADDR4 0UL > # define CALLER_ADDR5 0UL > # define CALLER_ADDR6 0UL > #endif > > Yep! > Ok. 2009/2/4 Anton Vorontsov : > It depends on the architecture. On PowerPC we always have frame pointers, > thus __builtin_return_address(1..) will always work. On x86 it won't work > that way. > > Thanks, > > -- > Anton Vorontsov Thanks for your answers! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
kernel 2.6.24 USB wi fi device firmware loading issue(s): rt73.bin...
I received great help last week in getting a USB wi fi device working. Thanks again, but can someone read below and advise me on kernel 2.6.24? The best out-of-the box solution for me was 2.6.27.8, for which I needed a Denx eldx toolchain in place of the toolchain I was using to compile 2.6.24. The significance of all this is that I did get USB wi fi working, but... I'm not in a position to upgrade from 2.6.24 at this time. I need to get the USB wi wi (Linksys WUSB54GC) working under 2.6.24. After success with linking firmware with the 2.6.27.8 kernel, 2.6.24 I keep hitting this error when loading from user space (I don't appear to have the, "link with kernel" option with 2.6.24)... sh-2.05b# ifconfig wlan0 up [ 764.744354] phy0 -> rt2x00lib_request_firmware: Info - Loading firmware file 'rt73.bin'. After a considerable delay I get an error that indicates the file can't be found. I have spent many, many hours following leads (and links) this group has directed me to. Thanks again. I'm either missing a very simple step or indeed support under 6.2.24 is not good. Please advise. I've done the following... 1)placed rt73.bin in various locations (/lib/firmware, lib/firmware/'uname -a', and the location specified by my /etc/hotplug/firmware.agent), according to tips on some threads I've read. None of this appears to make a difference. 2) I'm a bit confused by the hotplug dependancy, although I do have hotplug enabled. "hotplug" makes me think I should be configuring some script to load the firmware upon device insertion, but, "ifconfig wlan0 up" appears to want to load the firmware anyway so I'm guessing if I just get rt73.bin installed correctly it should work. Comparing my working 2.6.27.8 to 2.6.24 in the areas of, "firmware" and the ralink rt2x00 drivers reveals MANY changes, no doubt for the better. QUESTIONS: 1) Am I missing something VERY simple on this firmware loading topic that should make this work under 2.6.24, or am I bumping into the reason so much of this code has changed between 2.6.24 and 2.6.27.8? -linking firmware with the lernel at compile time is a nice, obvious method offered by the later kernel. I'm confused by the userspace method and I think this is where my problem lay. 2) am I correctly, "installing" the firmware just by placing rt73.bin in the correct location in my filesystem, or is there some other magic required before, "request_firmware()" will work? Just when I thought I understood some of the kernel I hit a new topic: firmware loading! Any help much appreciated... -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
Quoting Benjamin Herrenschmidt (b...@kernel.crashing.org):
>
> > +struct cr_hdr_cpu {
> > + struct pt_regs pt_regs;
> > + /* relevant fields from thread_struct */
> > + double fpr[32][TS_FPRWIDTH];
> > + unsigned int fpscr;
> > + int fpexc_mode;
> > + /* unsigned int align_ctl; this is never updated? */
> > + unsigned long dabr;
> > +};
>
> Is there some version or other identification somewhere ? If not there
> should be. ie, we're going to add things here. For example, what about
> the vector registers ? Also, some CPUs will have more HW debug registers
> than just the DABR (we plan to add support for all the BookE architected
> IACs and DACs for example), etc...
The arch-independent checkpoint header does have kernel
maj:min:rev:patch info. We expect to have to do more,
assuming that the .config can change the arch-dependent
cpu header (i.e. perhaps TS_FPRWIDTH could be changed).
-serge
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
On Wed, Feb 04, 2009 at 04:26:15PM +0100, Frédéric Weisbecker wrote: [...] > > @@ -136,6 +138,7 @@ config SCHED_TRACER > >select TRACING > >select CONTEXT_SWITCH_TRACER > >select TRACER_MAX_TRACE > > + select FRAME_POINTER > >help > > This tracer tracks the latency of the highest priority task > > to be scheduled in, starting from the point it has woken up. > > -- > > > Looks right. > > BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ? > I guess it would only work with the first caller builtin_return_address(0) It depends on the architecture. On PowerPC we always have frame pointers, thus __builtin_return_address(1..) will always work. On x86 it won't work that way. Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
2009/2/4 Anton Vorontsov : > Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they > should select FRAME_POINTER. Otherwise traces are meaningless. > > Signed-off-by: Anton Vorontsov > --- > kernel/trace/Kconfig |3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > index e2a4ff6..48f7a37 100644 > --- a/kernel/trace/Kconfig > +++ b/kernel/trace/Kconfig > @@ -86,6 +86,7 @@ config IRQSOFF_TRACER >select TRACE_IRQFLAGS >select TRACING >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This option measures the time spent in irqs-off critical > sections, with microsecond accuracy. > @@ -108,6 +109,7 @@ config PREEMPT_TRACER >depends on DEBUG_KERNEL >select TRACING >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This option measures the time spent in preemption off critical > sections, with microsecond accuracy. > @@ -136,6 +138,7 @@ config SCHED_TRACER >select TRACING >select CONTEXT_SWITCH_TRACER >select TRACER_MAX_TRACE > + select FRAME_POINTER >help > This tracer tracks the latency of the highest priority task > to be scheduled in, starting from the point it has woken up. > -- Looks right. BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ? I guess it would only work with the first caller builtin_return_address(0) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
On Wed, 2009-02-04 at 16:26 +0100, Frédéric Weisbecker wrote: > 2009/2/4 Anton Vorontsov : > > Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they > > should select FRAME_POINTER. Otherwise traces are meaningless. > > > > Signed-off-by: Anton Vorontsov > > --- > > kernel/trace/Kconfig |3 +++ > > 1 files changed, 3 insertions(+), 0 deletions(-) > > > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > > index e2a4ff6..48f7a37 100644 > > --- a/kernel/trace/Kconfig > > +++ b/kernel/trace/Kconfig > > @@ -86,6 +86,7 @@ config IRQSOFF_TRACER > >select TRACE_IRQFLAGS > >select TRACING > >select TRACER_MAX_TRACE > > + select FRAME_POINTER > >help > > This option measures the time spent in irqs-off critical > > sections, with microsecond accuracy. > > @@ -108,6 +109,7 @@ config PREEMPT_TRACER > >depends on DEBUG_KERNEL > >select TRACING > >select TRACER_MAX_TRACE > > + select FRAME_POINTER > >help > > This option measures the time spent in preemption off critical > > sections, with microsecond accuracy. > > @@ -136,6 +138,7 @@ config SCHED_TRACER > >select TRACING > >select CONTEXT_SWITCH_TRACER > >select TRACER_MAX_TRACE > > + select FRAME_POINTER > >help > > This tracer tracks the latency of the highest priority task > > to be scheduled in, starting from the point it has woken up. > > -- > > > Looks right. > > BTW, how behaves builtin_return_address in case of !FRAME_POINTERS ? > I guess it would only work with the first caller builtin_return_address(0) >From ftrace.h: #ifdef CONFIG_FRAME_POINTER /* TODO: need to fix this for ARM */ # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) # define CALLER_ADDR1 ((unsigned long)__builtin_return_address(1)) # define CALLER_ADDR2 ((unsigned long)__builtin_return_address(2)) # define CALLER_ADDR3 ((unsigned long)__builtin_return_address(3)) # define CALLER_ADDR4 ((unsigned long)__builtin_return_address(4)) # define CALLER_ADDR5 ((unsigned long)__builtin_return_address(5)) # define CALLER_ADDR6 ((unsigned long)__builtin_return_address(6)) #else # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0)) # define CALLER_ADDR1 0UL # define CALLER_ADDR2 0UL # define CALLER_ADDR3 0UL # define CALLER_ADDR4 0UL # define CALLER_ADDR5 0UL # define CALLER_ADDR6 0UL #endif Yep! -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3] tracing: Tracers that use CALLER_ADDR macros should select FRAME_POINTER
Irqsoff, switch and preempt tracers use CALLER_ADDR macros, so they should select FRAME_POINTER. Otherwise traces are meaningless. Signed-off-by: Anton Vorontsov --- kernel/trace/Kconfig |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index e2a4ff6..48f7a37 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -86,6 +86,7 @@ config IRQSOFF_TRACER select TRACE_IRQFLAGS select TRACING select TRACER_MAX_TRACE + select FRAME_POINTER help This option measures the time spent in irqs-off critical sections, with microsecond accuracy. @@ -108,6 +109,7 @@ config PREEMPT_TRACER depends on DEBUG_KERNEL select TRACING select TRACER_MAX_TRACE + select FRAME_POINTER help This option measures the time spent in preemption off critical sections, with microsecond accuracy. @@ -136,6 +138,7 @@ config SCHED_TRACER select TRACING select CONTEXT_SWITCH_TRACER select TRACER_MAX_TRACE + select FRAME_POINTER help This tracer tracks the latency of the highest priority task to be scheduled in, starting from the point it has woken up. -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Make it possible to safely select CONFIG_FRAME_POINTER
Remove -fno-omit-frame-pointer flag from CFLAGS. Remove -fno-omit-frame-pointer workarounds. Signed-off-by: Anton Vorontsov --- arch/powerpc/Makefile| 10 ++ arch/powerpc/kernel/Makefile | 10 +- arch/powerpc/platforms/powermac/Makefile |2 +- lib/Kconfig.debug|8 4 files changed, 16 insertions(+), 14 deletions(-) diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index 72d17f5..627aa7f 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -120,10 +120,12 @@ ifeq ($(CONFIG_6xx),y) KBUILD_CFLAGS += -mcpu=powerpc endif -# Work around a gcc code-gen bug with -fno-omit-frame-pointer. -ifeq ($(CONFIG_FUNCTION_TRACER),y) -KBUILD_CFLAGS += -mno-sched-epilog -endif +# Remove -fno-omit-frame-pointer flag. There are two reasons: +# 1. On powerpc we always have frame pointers. +# 2. Some gcc versions might generate wrong code with -fno-omit-frame-pointer +#flag. So, if for some reason you're going to remove this line, then add +#-mno-sched-epilog to workaround the gcc bug. +KBUILD_CFLAGS := $(subst -fno-omit-frame-pointer,,$(KBUILD_CFLAGS)) cpu-as-$(CONFIG_4xx) += -Wa,-m405 cpu-as-$(CONFIG_6xx) += -Wa,-maltivec diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 8d1a419..a97f215 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -14,14 +14,14 @@ endif ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code -CFLAGS_REMOVE_cputable.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_prom_init.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_btext.o = -pg -mno-sched-epilog -CFLAGS_REMOVE_prom.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_cputable.o = -pg +CFLAGS_REMOVE_prom_init.o = -pg +CFLAGS_REMOVE_btext.o = -pg +CFLAGS_REMOVE_prom.o = -pg ifdef CONFIG_DYNAMIC_FTRACE # dynamic ftrace setup. -CFLAGS_REMOVE_ftrace.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_ftrace.o = -pg endif endif diff --git a/arch/powerpc/platforms/powermac/Makefile b/arch/powerpc/platforms/powermac/Makefile index 50f1693..0eb8781 100644 --- a/arch/powerpc/platforms/powermac/Makefile +++ b/arch/powerpc/platforms/powermac/Makefile @@ -2,7 +2,7 @@ CFLAGS_bootx_init.o += -fPIC ifdef CONFIG_FUNCTION_TRACER # Do not trace early boot code -CFLAGS_REMOVE_bootx_init.o = -pg -mno-sched-epilog +CFLAGS_REMOVE_bootx_init.o = -pg endif obj-y += pic.o setup.o time.o feature.o pci.o \ diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 29044f5..657126c 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -402,7 +402,7 @@ config LOCKDEP bool depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT select STACKTRACE - select FRAME_POINTER if !X86 && !MIPS && !PPC + select FRAME_POINTER if !X86 && !MIPS select KALLSYMS select KALLSYMS_ALL @@ -583,7 +583,7 @@ config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ (CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \ -AVR32 || SUPERH || BLACKFIN || MN10300) || \ +AVR32 || SUPERH || BLACKFIN || MN10300 || PPC) || \ ARCH_WANT_FRAME_POINTERS default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS help @@ -771,13 +771,13 @@ config FAULT_INJECTION_STACKTRACE_FILTER depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT depends on !X86_64 select STACKTRACE - select FRAME_POINTER if !PPC + select FRAME_POINTER help Provide stacktrace filter for fault-injection capabilities config LATENCYTOP bool "Latency measuring infrastructure" - select FRAME_POINTER if !MIPS && !PPC + select FRAME_POINTER if !MIPS select KALLSYMS select KALLSYMS_ALL select STACKTRACE -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] Makefile: Include arch Makefiles as late as possible
This patch gives arches more freedom on overwriting CFLAGS, specifically
on PowerPC we want to remove -fno-omit-frame-pointer flag.
Signed-off-by: Anton Vorontsov
---
Makefile |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 7715b2c..d1ba93f 100644
--- a/Makefile
+++ b/Makefile
@@ -525,8 +525,6 @@ else
KBUILD_CFLAGS += -O2
endif
-include $(srctree)/arch/$(SRCARCH)/Makefile
-
ifneq (CONFIG_FRAME_WARN,0)
KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
endif
@@ -555,6 +553,8 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
endif
+include $(srctree)/arch/$(SRCARCH)/Makefile
+
# arch Makefile may override CC so keep this after arch Makefile is included
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
CHECKFLAGS += $(NOSTDINC_FLAGS)
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] ftrace: On PowerPC we don't need frame pointers for CALLER_ADDRs
On Tue, Feb 03, 2009 at 07:19:55PM +0300, Anton Vorontsov wrote: > On Tue, Feb 03, 2009 at 05:06:45PM +0100, Ingo Molnar wrote: > > > > * Anton Vorontsov wrote: > > > > > According to this discussion: > > > > > > http://lkml.org/lkml/2008/7/25/338 > > > http://lkml.org/lkml/2008/7/26/72 > > > > > > Frame pointers do nothing useful on PowerPC, so lib/Kconfig.debug > > > makes CONFIG_FRAME_POINTER unselectable on PPC targets. But ftrace.h > > > requires CONFIG_FRAME_POINTER for CALLER_ADDR macros. [...] > > > > hm, why not add PPC to FRAME_POINTERS list of architectures, and select it > > from the powerpc arch Kconfig? Does that cause complications somewhere? > > -fno-omit-frame-pointers makes the code worse w/o any actual > benefit that we would use. Plus, there is a long standing bug in > gcc that makes -fno-omit-frame-pointer generate wrong code for PPC > targets: > > http://lkml.org/lkml/2008/9/2/25 > > That is, the only tracer that needs[1] -fno-omit-frame-pointer is > "FUNCTION_TRCER", but we workaround the issue via -mno-sched-epilog, > quoting arch/powerpc/Makefile: > > # Work around a gcc code-gen bug with -fno-omit-frame-pointer. > ifeq ($(CONFIG_FUNCTION_TRACER),y) > KBUILD_CFLAGS += -mno-sched-epilog > endif Thinking about it more... we can workaround the bug the other way, and then permit CONFIG_FRAME_POINTER on PowerPC. Patches are coming... -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Can not get PATA to work for Compact Flash with 2.6.28 kernel
Lixin Yao wrote: > I redefined io functions in libata-sff.c, byte operations are converted > to 16bit word operations. Maybe I should ask for HW changes in new > revisions of the board. > I do recommend that. We got it wrong on our first board too. :-) It is much better to get the hardware right than to carry your endian SW patch forever. Two other potential issues: 1) making sure the "most significant byte enable" is used, so that byte writes work correctly. You most likely have this correct already, or you would not have gotten this far. And 2) make sure you allow for the hold time / turn-off time of the CF. We use a 440EPx, and cannot set up the external bus controller to generate valid cycles in all cases. So, we added some flip-flops to stretch the rising edge of the chip select, which guarantees proper timing. (I'm going a bit far afield from the purpose of this mailing list, so if you want more details, please contact me directly.) Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
ADS5121 problem using audio interface
Hi I'm trying to get the audio interface working on my ADS5121 Rev4.0 and have some questions. I did manage to record and play audio files of type raw and format S32_BE like this: $ arecord -traw -c2 -fS32_BE -Dhw:0,0 testfile $ aplay -traw -c2 -fS32_BE -Dhw:0,0 testfile I am not able to get the auto conversion work, so that I could play a wav file of any format. I'm getting this error: $ aplay -Dplughw:0,0 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Mono ALSA lib pcm_plug.c:773:(snd_pcm_plug_hw_refine_schange) Unable to find an usable access for 'plughw:0,0' aplay: set_params:901: Sample format non available I'm not sure, but I expect this to be a problem of my ALSA configuration and this is where I'm stuck. Does anyone have a working ALSA configuration file for the ads5121? Or any other hints on how to overcome this problem? Does anyone know how to convert wav files so that they can be played in raw mode? Many thanks Stefan. - These are the steps I performed to get audio work: I'm using kernel 2.6.24.6 (linux-2.6-denx.git/ads5121) with ALSA-1.0.15 built into the kernel and ELDK-4.2. 1. Build and install alsa-lib-1.0.15 and alsa-utils-1.0.15 natively on the target. $ wget ftp://ftp.alsa-project.org/pub/lib/alsa-lib-1.0.15.tar.bz2 $ tar xf alsa-lib-1.0.15.tar.bz2 $ cd alsa-lib-1.0.15 $ ./configure $ make $ make install $ wget ftp://ftp.alsa-project.org/pub/utils/alsa-utils-1.0.15.tar.bz2 $ tar xf alsa-utils-1.0.15.tar.bz2 $ cd alsa-utils-1.0.15 $ ./configure --disable-nls $ make $ make install 2. Manually create the device nodes, with Minor numbers according to output from /proc/asound/devices $ cat /proc/asound/devices 0: [ 0] : control 1:: sequencer 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 33:: timer $ mkdir /dev/snd $ mknod /dev/snd/pcmC0D0p c 116 16 $ mknod /dev/snd/pcmC0D0c c 116 24 $ mknod /dev/snd/controlC0 c 116 0 $ mknod /dev/snd/timer c 116 33 $ mknod /dev/snd/seq c 116 1 3. Run aplay... $ aplay -l List of PLAYBACK Hardware Devices card 0: ADS [MPC5121 ADS], device 0: AC97 AC97 HiFi--0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 $ aplay -L default:CARD=ADS MPC5121 ADS, Default Audio Device null Discard all samples (playback) or generate zero samples (capture) $ aplay -traw -c2 -fS32_BE -Dhw:0,0 /dev/urandom $ arecord -traw -c2 -fS32_BE -Dhw:0,0 testfile $ aplay -traw -c2 -fS32_BE -Dhw:0,0 testfile ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
Ravishankar Govindarao RFL Electronics Inc. E-mail : ravi@rflelect.com Voice: 973.334.3100 Ext. 233 Fax: 973.334.3863 CONFIDENTIALITY NOTE This e-mail, including any attachments, may contain confidential and/or legally privileged information. The Information is intended only for the use of the individual or entity named on this e-mail . If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on the contents of this transmitted Information is strictly prohibited. Further, if you are not the intended recipient, please notify us by return e-mail and delete the Information promptly. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: next-20090204 build break : ftrace
On Wed, 4 Feb 2009, Sachin P. Sant wrote: > Hi Stephen, > > 20090204 randconfig build on powerpc fails with : > > CC arch/powerpc/kernel/ftrace.o > arch/powerpc/kernel/ftrace.c: In function __ftrace_make_nop: > arch/powerpc/kernel/ftrace.c:204: error: dereferencing pointer to incomplete > type > arch/powerpc/kernel/ftrace.c: In function __ftrace_make_call: > arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete > type > arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete > type > arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete > type > arch/powerpc/kernel/ftrace.c:407: error: dereferencing pointer to incomplete > type > make[1]: *** [arch/powerpc/kernel/ftrace.o] Error 1 > make: *** [arch/powerpc/kernel] Error 2 > > config attached. > Thanks, I'll give it a try later today on my PPC64 box. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting 2.6.29-rc3 on mpc8661d_hpcn failing
On Wed, 2009-02-04 at 11:47 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2009-02-03 at 15:50 +, Martyn Welch wrote:
> >
> > The primary CPU is spinning in smp_generic_give_timebase() waiting for
> > "!tbsync->ack". The secondary CPU has made it into
> > smp_generic_take_timebase() and has apparently (according to some
> > printk's I put in there) set "tbsync->ack=1". After that I don't get
> > any printk's, I guess that the one I have put in the "!
> > tbsync->handshake" while loop is making it to the print buffer, but
> > with both processors spinning it's not getting to the serial console.
> >
> > At a guess, given that commit 64b3d0e8122b422e879b23d42f9e0e8efbbf9744
> > seems to be the point that it stopped working correctly, that "tbsync"
> > is now somehow becoming cached?
> >
> Maybe we are missing the M bit in the mapping ?
>
> Let's see... the kernel mapping is done via BATs on those guys (ie, e600
> is a hash table based processor right ? some kind of 74xx). The code
> that sets them up is in
>
> arch/powerpc/mm/ppc_mmu_32.c
>
> In mmu_mapin_ram() we call setbat() multiple times. The last argument is
> the "flags" which is set to _PAGE_RAM. That should contain
> _PAGE_COHERENT when CONFIG_SMP is set unless I screwed up. IE. _PAGE_RAM
> is _PAGE_KERNEL | _PAGE_HWEXEC. _PAGE_KERNEL is _PAGE_BASE plus things,
> and _PAGE_BASE should contains _PAGE_COHERENT if CONFIG_SMP or
> CONFIG_PPC_STD_MMU are set and they should both be in your case.
>
> setbat() itself will clear _PAGE_COHERENT under some circumstances
> however. Either if the flags contain _PAGE_NO_CACHE, which should not be
> the case here, or if the CPU feature bit CPU_FTR_NEED_COHERENT is -not-
> set. I think that could be the cause of the problem.
>
> CPU_FTR_NEED_COHERENT is set as part of CPU_FTR_COMMON if CONFIG_SMP
> is set (among other things). So it -should- be set for you. since
> CPU_FTR_COMMON should be OR'ed with all CPU table entries.
>
> So I'm a bit at a loss here... unless something else went wrong.
>
> Please let me know what you find out.
>
> Cheers,
> Ben.
I think it is indeed something else. I added the patch below which
resulted in the following lines in the kernel messages:
Set BAT 2 for 0x1000 from phys:0x0 at virt:0xc000
Page coherency set
Set BAT 3 for 0x1000 from phys:0x1000 at virt:0xd000
Page coherency set
...
tbsync structure allocated at 0xef818360 for 0x48
tbsync happens to live at 0xc0515110
running happens to live at 0xc0515114
This suggests to me that whilst *tbsync and running are located within
RAM mapped by the BATs, the memory allocated for the tbsync structure is
not and is mapped via page tables. I guess this structure is then only
mapped correctly for the first core.
Martyn
--
diff --git a/arch/powerpc/kernel/smp-tbsync.c b/arch/powerpc/kernel/smp-tbsync.c
index a5e5452..fdeda20 100644
--- a/arch/powerpc/kernel/smp-tbsync.c
+++ b/arch/powerpc/kernel/smp-tbsync.c
@@ -117,6 +117,10 @@ void __devinit smp_generic_give_timebase(void)
/* if this fails then this kernel won't work anyway... */
tbsync = kzalloc( sizeof(*tbsync), GFP_KERNEL );
+ printk("tbsync structure allocated at 0x%p for 0x%x\n", tbsync,
+ sizeof(*tbsync));
+ printk("tbsync happens to live at 0x%p\n", &tbsync);
+ printk("running happens to live at 0x%p\n", &running);
mb();
running = 1;
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index fe65c40..2035cd6 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -123,6 +123,9 @@ void __init setbat(int index, unsigned long virt, phys_addr_
int wimgxpp;
struct ppc_bat *bat = BATS[index];
+ printk("Set BAT %d for 0x%x from phys:0x%lx at virt:0x%lx\n", index,
+ size, phys, virt);
+
if ((flags & _PAGE_NO_CACHE) ||
(cpu_has_feature(CPU_FTR_NEED_COHERENT) == 0))
flags &= ~_PAGE_COHERENT;
@@ -134,6 +137,11 @@ void __init setbat(int index, unsigned long virt, phys_addr
wimgxpp = flags & (_PAGE_WRITETHRU | _PAGE_NO_CACHE
| _PAGE_COHERENT | _PAGE_GUARDED);
wimgxpp |= (flags & _PAGE_RW)? BPP_RW: BPP_RX;
+ if (wimgxpp & _PAGE_COHERENT) {
+ printk("Page coherency set\n");
+ } else {
+ printk("Page coherency cleared\n");
+ }
bat[1].batu = virt | (bl << 2) | 2; /* Vs=1, Vp=0 */
bat[1].batl = BAT_PHYS_ADDR(phys) | wimgxpp;
#ifndef CONFIG_KGDB /* want user access for breakpoints */
--
Martyn Welch MEng MPhil MIET (Principal Software Engineer) T:+44(0)1327322748
GE Fanuc Intelligent Platforms Ltd,|Registered in England and Wales
Tove Valley Business Park, Towcester, |(3828642) at 100 Barbirolli Square,
Northants, NN12 6PF, UK T:+44(0)1327359444 |Manchester,M2 3AB VAT:GB 7298494
Re: [PATCH v2 1/4] Add platform support for AmigaOne
Original-Nachricht > Datum: Wed, 04 Feb 2009 14:50:07 +1100 > Von: Benjamin Herrenschmidt > An: Gerhard Pircher > CC: linuxppc-dev list > Betreff: Re: [PATCH v2 1/4] Add platform support for AmigaOne > > + hose->first_busno = bus_range ? bus_range[0] : 0; > > + hose->last_busno = bus_range ? bus_range[1] : 0xff; > > + > > + setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc, 0); > > Minor in the context of amigaone but still... the above should come from > the device-tree... I suppose those are really just IO space addresses > cf8 and cfc, in which case, an option is to call that first: I agree that these addresses should come from the device-tree, but these two config registers are not located within the normal PCI I/O address space (0xfe00-0xfec0). Maybe I should add a "reg" property to the PHB node, but I don't know if this is the right approach. The OF PCI spec isn't very clear about this. What do you think? Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
next-20090204 build break : ftrace
Hi Stephen, 20090204 randconfig build on powerpc fails with : CC arch/powerpc/kernel/ftrace.o arch/powerpc/kernel/ftrace.c: In function __ftrace_make_nop: arch/powerpc/kernel/ftrace.c:204: error: dereferencing pointer to incomplete type arch/powerpc/kernel/ftrace.c: In function __ftrace_make_call: arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete type arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete type arch/powerpc/kernel/ftrace.c:400: error: dereferencing pointer to incomplete type arch/powerpc/kernel/ftrace.c:407: error: dereferencing pointer to incomplete type make[1]: *** [arch/powerpc/kernel/ftrace.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 config attached. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - # # Automatically generated make config: don't edit # Linux kernel version: 2.6.29-rc3 # Wed Feb 4 18:31:52 2009 # CONFIG_PPC64=y # # Processor support # CONFIG_POWER4_ONLY=y CONFIG_POWER4=y CONFIG_TUNE_CELL=y CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y CONFIG_VSX=y CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y # CONFIG_VIRT_CPU_ACCOUNTING is not set CONFIG_SMP=y CONFIG_NR_CPUS=32 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_ARCH_PHYS_ADDR_T_64BIT=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SCHED_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y CONFIG_GENERIC_TBSYNC=y CONFIG_AUDIT_ARCH=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_64=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set CONFIG_PPC_DCR_MMIO=y CONFIG_PPC_DCR=y CONFIG_PPC_OF_PLATFORM_PCI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y # # RCU Subsystem # CONFIG_CLASSIC_RCU=y # CONFIG_TREE_RCU is not set # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set # CONFIG_CGROUPS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y # CONFIG_PRINTK is not set # CONFIG_BUG is not set # CONFIG_ELF_CORE is not set # CONFIG_PCSPKR_PLATFORM is not set CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_PCI_QUIRKS=y # CONFIG_SLAB is not set # CONFIG_SLUB is not set CONFIG_SLQB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y CONFIG_MARKERS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_SYSCALL_WRAPPERS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y CONFIG_SLOW_WORK=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y # CONFIG_IOSCHED_CFQ is not set CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED
[no subject]
unsubscribe linux-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH v2] ftrace: On PowerPC we don't need frame pointers forCALLER_ADDRs
unsubscribe linux-kernel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
unsubscribe
___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
