* Re: [PATCH] Fix vmemmap warning in init_64..c
From: Geert Uytterhoeven @ 2007-10-17 8:55 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev, Paul Mackerras
In-Reply-To: <20071017043024.GE9814@bakeyournoodle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1728 bytes --]
On Wed, 17 Oct 2007, Tony Breeds wrote:
> Use the right printk format to silence the following warning.
>
> CC arch/powerpc/mm/init_64.o
> arch/powerpc/mm/init_64.c: In function 'vmemmap_populate':
> arch/powerpc/mm/init_64.c:243: warning: format '%p' expects type 'void *', but argument 4 has type 'long unsigned int'
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
> ---
>
> Also a whitespace fix while I'm there.
>
> arch/powerpc/mm/init_64.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
> index 702d884..6720b1c 100644
> --- a/arch/powerpc/mm/init_64.c
> +++ b/arch/powerpc/mm/init_64.c
> @@ -240,7 +240,7 @@ int __meminit vmemmap_populate(struct page *start_page,
> return -ENOMEM;
>
> printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
^^
> - "physical %p.\n", start, p, __pa(p));
> + "physical %08lx.\n", start, p, __pa(p));
^^
Anyone with memory outside 32-bit (`%08lx') space?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: vga16fb doesn't build on powerpc (vgacon_remap_base)
From: Geert Uytterhoeven @ 2007-10-17 8:49 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linuxppc-dev, linux-fbdev-devel
In-Reply-To: <20071016191403.GA5962@nineveh.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2040 bytes --]
On Tue, 16 Oct 2007, Joseph Fannin wrote:
> vga16fb is an available config option on powerpc, but it won't link
> with my .config:
>
> ERROR: "vgacon_remap_base" [drivers/video/vga16fb.ko] undefined!
>
>
> I'm guessing this is because include/asm-powerpc/vga.h declares
> vgacon_remap_base:
>
> extern unsigned long vgacon_remap_base;
>
>
> ...but arch/powerpc/kernel/setup_32.c wraps the definition in an #ifdef:
>
> #ifdef CONFIG_VGA_CONSOLE
> unsigned long vgacon_remap_base;
> EXPORT_SYMBOL(vgacon_remap_base);
> #endif
>
>
> So CONFIG_VGA_CONSOLE=n and CONFIG_FB_VGA16=[y|m] won't work.
>
> I've also noticed that the only places in the tree that ever assign
> anything to config_remap_base are under arch/ppc. And
> include/asm-powerpc/vga.h also does this:
>
> #ifdef __powerpc64__
> #define VGA_MAP_MEM(x,s) ((unsigned long) ioremap((x), s))
> #else
> #define VGA_MAP_MEM(x,s) (x + vgacon_remap_base)
> #endif
>
>
> So VGACON probably doesn't work either on 32bit. I'm guessing arch/powerpc
> doesn't support PREP.
It's not only useful for PREP, but also for CHRP.
> How best could this be fixed up? Or should I just let the thing
> be? This is obviously not a new thing, and I don't have any hardware
> that supports this stuff either.
I remember this problem was present when I still had a working LongTrail (which
is CHRP), long before arch/powerpc/ was created.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH 2/2] Use of_get_pci_dev_node() in axon_msi.c
From: Michael Ellerman @ 2007-10-17 7:12 UTC (permalink / raw)
To: Paul Mackerras
Cc: sparclinux, Stephen Rothwell, David S. Miller, linuxppc-dev
In-Reply-To: <8f76815cbbaf5fbab82c843d87bc0dafab038c80.1192605144.git.michael@ellerman.id.au>
Use of_get_pci_dev_node() in axon_msi.c. Switch to including <linux/of.h>
so we get the prototype.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/cell/axon_msi.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/cell/axon_msi.c b/arch/powerpc/platforms/cell/axon_msi.c
index 095988f..034041c 100644
--- a/arch/powerpc/platforms/cell/axon_msi.c
+++ b/arch/powerpc/platforms/cell/axon_msi.c
@@ -14,10 +14,10 @@
#include <linux/pci.h>
#include <linux/msi.h>
#include <linux/reboot.h>
+#include <linux/of.h>
#include <asm/dcr.h>
#include <asm/machdep.h>
-#include <asm/prom.h>
/*
@@ -119,7 +119,7 @@ static struct axon_msic *find_msi_translator(struct pci_dev *dev)
const phandle *ph;
struct axon_msic *msic = NULL;
- dn = of_node_get(pci_device_to_OF_node(dev));
+ dn = of_get_pci_dev_node(dev);
if (!dn) {
dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
return NULL;
@@ -176,7 +176,7 @@ static int setup_msi_msg_address(struct pci_dev *dev, struct msi_msg *msg)
int len;
const u32 *prop;
- dn = of_node_get(pci_device_to_OF_node(dev));
+ dn = of_get_pci_dev_node(dev);
if (!dn) {
dev_dbg(&dev->dev, "axon_msi: no pci_dn found\n");
return -ENODEV;
--
1.5.1.3.g7a33b
^ permalink raw reply related
* [PATCH 1/2] Introduce of_get_pci_dev_node()
From: Michael Ellerman @ 2007-10-17 7:12 UTC (permalink / raw)
To: Paul Mackerras
Cc: sparclinux, Stephen Rothwell, David S. Miller, linuxppc-dev
Both powerpc and sparc have a routine, pci_device_to_OF_node(), which
returns the device_node associated with a given pci device.
The new routine, of_get_pci_dev_node(), performs exactly the same function
with the one exception that it returns a refcounted pointer to the
device_node, callers must then release the reference with of_node_put().
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
drivers/of/Makefile | 1 +
drivers/of/pci.c | 24 ++++++++++++++++++++++++
include/linux/of.h | 3 +++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index ab9be5d..f49898c 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -1,2 +1,3 @@
obj-y = base.o
obj-$(CONFIG_OF_DEVICE) += device.o platform.o
+obj-$(CONFIG_PCI) += pci.o
diff --git a/drivers/of/pci.c b/drivers/of/pci.c
new file mode 100644
index 0000000..2319c22
--- /dev/null
+++ b/drivers/of/pci.c
@@ -0,0 +1,24 @@
+/*
+ * Copyright 2007 Michael Ellerman, IBM Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/of.h>
+#include <linux/pci.h>
+
+/**
+ * of_get_pci_dev_node - Get a device node from a pci_dev
+ * @pdev: pci_dev to get the node from
+ *
+ * Returns a node pointer with refcount incremented, use
+ * of_node_put() on it when done.
+ */
+struct device_node *of_get_pci_dev_node(struct pci_dev *pdev)
+{
+ return of_node_get(pci_device_to_OF_node(pdev));
+}
+EXPORT_SYMBOL(of_get_pci_dev_node);
diff --git a/include/linux/of.h b/include/linux/of.h
index 6df80e9..e5bfb13 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -57,4 +57,7 @@ extern const void *of_get_property(const struct device_node *node,
extern int of_n_addr_cells(struct device_node *np);
extern int of_n_size_cells(struct device_node *np);
+struct pci_dev;
+extern struct device_node *of_get_pci_dev_node(struct pci_dev *pdev);
+
#endif /* _LINUX_OF_H */
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: 2.6.23-git-10 Build Failure on powerpc - asm-powerpc/dma_mapping.h
From: Olof Johansson @ 2007-10-17 6:50 UTC (permalink / raw)
To: Kamalesh Babulal; +Cc: linuxppc-dev, LKML
In-Reply-To: <4715A9C1.9090106@linux.vnet.ibm.com>
Hi,
On Wed, Oct 17, 2007 at 11:50:49AM +0530, Kamalesh Babulal wrote:
> Build fails on the powerpc fails with 2.6.23-git10
This was fixed by 33ff910f0f466184ffc3514628f18403dcd86761.
-Olof
^ permalink raw reply
* Re: ioctl32: Unknown cmd
From: Geert Uytterhoeven @ 2007-10-17 6:38 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linux/PPC Development, Linux Kernel Development, Jens Axboe
In-Reply-To: <200710162150.37636.arnd@arndb.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1875 bytes --]
On Tue, 16 Oct 2007, Arnd Bergmann wrote:
> On Tuesday 16 October 2007, Geert Uytterhoeven wrote:
> > The recent (post 2.6.23) changes to compat_ioctl made the reporting of
> > unsupported ioctls more verbose. E.g. on the PS3 I get:
> >
> > | ioctl32(cdrom_id:608): Unknown cmd fd(3) cmd(00005331){t:'S';sz:0} arg(00000000) on /dev/.tmp-11-0
> > | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> > | ioctl32(hdparm:1427): Unknown cmd fd(3) cmd(0000031f){t:03;sz:0} arg(00000000) on /dev/ps3da
> >
> > The first one is triggered by the detection of the CD/DVD/BD-ROM driver,
> > The others are triggered by me running hdparm.
> >
> > Was this intentional?
>
> No, it was certainly not intentional, and I can't figure out why it happens.
> The ioctl numbers from your example are HDIO_DRIVE_CMD and CDROM_GET_CAPABILITY,
> both of which should be handled through compat_blkdev_driver_ioctl by calling
> the native ioctl method of the driver, and return -ENOTTY otherwise.
>
> The one point where it is expected to have changed now is when you try
> to do these ioctls on something that is not a block device. Are you sure that
> the files you tried them on were created correctly?
/dev/ps3da is definitely a block device.
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* 2.6.23-git-10 Build Failure on powerpc - asm-powerpc/dma_mapping.h
From: Kamalesh Babulal @ 2007-10-17 6:20 UTC (permalink / raw)
To: LKML, linuxppc-dev, Andy Whitcroft
Hi,
Build fails on the powerpc fails with 2.6.23-git10
CC init/main.o
In file included from include/linux/dma-mapping.h:42,
from include/linux/dmaengine.h:29,
from include/linux/skbuff.h:29,
from include/linux/netlink.h:155,
from include/linux/genetlink.h:4,
from include/net/genetlink.h:4,
from include/linux/taskstats_kern.h:12,
from init/main.c:45:
include/asm/dma-mapping.h: In function `dma_unmap_page':
include/asm/dma-mapping.h:14: error: implicit declaration of function `get_dma_ops'
include/asm/dma-mapping.h:14: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:17: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:21: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h:21: warning: its scope is only this definition or declaration, which is probably not what you want
include/asm/dma-mapping.h: In function `dma_map_sg':
include/asm/dma-mapping.h:23: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:26: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:31: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_unmap_sg':
include/asm/dma-mapping.h:33: warning: initialization makes pointer from integer without a cast
include/asm/dma-mapping.h:36: error: dereferencing pointer to incomplete type
include/asm/dma-mapping.h: In function `dma_sync_single_for_cpu':
include/asm/dma-mapping.h:167: error: implicit declaration of function `__dma_sync'
include/asm/dma-mapping.h:167: error: implicit declaration of function `bus_to_virt'
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:180: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_sync_sg_for_cpu':
include/asm/dma-mapping.h:187: error: implicit declaration of function `for_each_sg'
include/asm/dma-mapping.h:188: error: parse error before "__dma_sync_page"
include/asm/dma-mapping.h: At top level:
include/asm/dma-mapping.h:193: warning: `struct scatterlist' declared inside parameter list
include/asm/dma-mapping.h: In function `dma_sync_sg_for_device':
include/asm/dma-mapping.h:201: error: parse error before "__dma_sync_page"
include/asm/dma-mapping.h: In function `dma_mapping_error':
include/asm/dma-mapping.h:207: error: `DMA_ERROR_CODE' undeclared (first use in this function)
include/asm/dma-mapping.h:207: error: (Each undeclared identifier is reported only once
include/asm/dma-mapping.h:207: error: for each function it appears in.)
In file included from include/linux/dma-mapping.h:42,
from include/linux/dmaengine.h:29,
from include/linux/skbuff.h:29,
from include/linux/netlink.h:155,
from include/linux/genetlink.h:4,
from include/net/genetlink.h:4,
from include/linux/taskstats_kern.h:12,
from init/main.c:45:
include/asm/dma-mapping.h:259:2: #endif without #if
include/asm/dma-mapping.h:260:2: #endif without #if
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
^ permalink raw reply
* Re: PPC440EPx GPIO control help
From: Jeff Mock @ 2007-10-17 6:21 UTC (permalink / raw)
To: David Hawkins; +Cc: linuxppc-embedded
In-Reply-To: <47158C69.2070903@ovro.caltech.edu>
David Hawkins wrote:
>> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
>> What I would want to do is to control (write and read values to) its
>> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
>> inportb(0x378) to read. I read the PPC440EPx manual but I find it
>> difficult to understand.
>>
>> Could anyone show me any tutorial or some sample codes?
>
> I copied the code below from some test code I wrote for a TS7300
> board (uses an ARM EP9302 processor). However, since its user-space
> code it should work fine.
>
I might be a little out of date, but I think you must write your own
driver to wiggle the GPIO pins on a 440 processor. I just finished a
project using a 440GX with a 2.6.15 kernel (we froze the code about 8
months ago).
The 440 powerPC core is a 32-bit processor with 36-bit physical
addresses. The physical address for the GPIO pins is someplace above
4GB. An mmap() of /dev/mem only lets you map the lower 4GB of the
address space, as a result you can't write a user space program on the
440 to wiggle the GPIO pins. (This was true with 2.6.15, I can't speak
for later kernels).
This tossed me into writing device drivers, which turned out to be not
nearly as scary as I imagined. The Linux Device Drivers book is fabulous:
http://lwn.net/Kernel/LDD3/
Here is a driver for the 440GX that controls an LED on one of the GPIO
pins you can use as an example. The device /dev/pdev-led has a
read/write interface so you can do something like this:
# echo "1" > /dev/pdev-led # turn on LED
# echo "0" > /dev/pdev-led # turn off LED
It also has a /proc interface so you can cat /proc/pdev-led to read the
status of the LED. There are several other drivers there that probably
won't be interesting, but pdev-led.c is probably a good starting point:
http://www.mock.com/wsvn/listing.php?repname=mock.pdev&path=/trunk/sw/driver/
jeff
^ permalink raw reply
* Re: New time code miscalculates cpu usage
From: Tony Breeds @ 2007-10-17 6:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: paulus, linuxppc-dev
In-Reply-To: <20071016202525.GA11837@lixom.net>
On Tue, Oct 16, 2007 at 03:25:25PM -0500, Olof Johansson wrote:
> Hi,
>
> Not sure when this started happening, but I wanted to report it. I'll
> start bisecting in a day or two if noone else has gotten around to
> looking at it:
>
> $ echo "int main(void) { while(1); }" > test.c ; gcc test.c
> $ time ./a.out & sleep 2 ; killall a.out
> real 0m2.008s
> user 0m4.014s
> sys 0m0.002s
>
> Seen on POWER5 and PA6T, haven't tried anything else yet.
For what it's worth, this is my bug. I suspected it, and git bisect
confirmed it.I have an ugly work around now, but hope to have something
better out tomorrow.
Thanks Olof.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: Merge dtc
From: David Gibson @ 2007-10-17 5:22 UTC (permalink / raw)
To: Grant Likely; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <fa686aa40710160617o57564cb4r260a40cd66407852@mail.gmail.com>
On Tue, Oct 16, 2007 at 07:17:01AM -0600, Grant Likely wrote:
> On 10/15/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > This very large patch incorporates a copy of dtc into the kernel
> > source, in arch/powerpc/boot/dtc-src. This means that dtc is no
> > longer an external dependency to build kernels with configurations
> > which need a dtb file.
>
> Powerpc is probably not going to be the only user of dtc. Microblaze
> will be using it too. Can it be put somewhere more common?
Well, I guess we can move it to scripts/ when microblaze starts using
it.
Also, tell me more about this microblaze, I'm certainly interested in
new users of dtc...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: current -git adbhid.c build error
From: Dmitry Torokhov @ 2007-10-17 4:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18197.36181.369197.363642@cargo.ozlabs.ibm.com>
On Wednesday 17 October 2007, Paul Mackerras wrote:
>
> It was a mis-merge between 555ddbb4, which made that change and *did*
> add the declaration of key, and 9a402b64, which deleted the line that
> the declaration of key was added to.
Oops, sorry.
>
> We need the patch below. Dmitry, will you push it or will I?
>
Please do. Thanks!
--
Dmitry
^ permalink raw reply
* [PATCH] Fix vmemmap warning in init_64..c
From: Tony Breeds @ 2007-10-17 4:30 UTC (permalink / raw)
To: Paul Mackerras, LinuxPPC-dev
Use the right printk format to silence the following warning.
CC arch/powerpc/mm/init_64.o
arch/powerpc/mm/init_64.c: In function 'vmemmap_populate':
arch/powerpc/mm/init_64.c:243: warning: format '%p' expects type 'void *', but argument 4 has type 'long unsigned int'
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Also a whitespace fix while I'm there.
arch/powerpc/mm/init_64.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 702d884..6720b1c 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -240,7 +240,7 @@ int __meminit vmemmap_populate(struct page *start_page,
return -ENOMEM;
printk(KERN_WARNING "vmemmap %08lx allocated at %p, "
- "physical %p.\n", start, p, __pa(p));
+ "physical %08lx.\n", start, p, __pa(p));
mapped = htab_bolt_mapping(start, start + page_size,
__pa(p), mode_rw, mmu_linear_psize,
--
1.5.3.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Benjamin Herrenschmidt @ 2007-10-17 4:26 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jakub Jelinek, linuxppc-dev list, Andrew Haley, Alan Modra,
Deepak Bhole
The current DWARF info for CR are incorrect causing the gcc unwinder to
go to lunch if taking a segfault in the vdso. This patch fixes it.
Problem identified by Andrew Haley, and fix provided by Jakub Jelinek
(thanks !).
Unfortunately, a bug in gcc cause it to not quite work either, but that
is being fixed separately with something around the lines of:
linux-unwind.h:
fs->regs.reg[R_CR2].loc.offset = (long) ®s->ccr - new_cfa;
+ /* CR? regs are just 32-bit and PPC is big-endian. */
+ fs->regs.reg[R_CR2].loc.offset += sizeof (long) - 4;
(According to Jakub)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/vdso64/sigtramp.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:32:49.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:34:18.000000000 +1000
@@ -134,13 +134,16 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
9:
/* This is where the pt_regs pointer can be found on the stack. */
-#define PTREGS 128+168+56
+#define PTREGS 128+168+56
/* Size of regs. */
-#define RSIZE 8
+#define RSIZE 8
+
+/* Size of CR reg in DWARF unwind info. */
+#define CRSIZE 4
/* This is the offset of the VMX reg pointer. */
-#define VREGS 48*RSIZE+33*8
+#define VREGS 48*RSIZE+33*8
/* Describe where general purpose regs are saved. */
#define EH_FRAME_GEN \
@@ -178,7 +181,7 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
rsave (31, 31*RSIZE); \
rsave (67, 32*RSIZE); /* ap, used as temp for nip */ \
rsave (65, 36*RSIZE); /* lr */ \
- rsave (70, 38*RSIZE) /* cr */
+ rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */
/* Describe where the FP regs are saved. */
#define EH_FRAME_FP \
^ permalink raw reply
* [PATCH] powerpc: Fix 64 bits vDSO dwarf info for CR register
From: Benjamin Herrenschmidt @ 2007-10-17 4:23 UTC (permalink / raw)
To: Paul Mackerras
Cc: Jakub Jelinek, linuxppc-dev list, Andrew Haley, Alan Modra,
Deepak Bhole
The current DWARF info for CR are incorrect causing the gcc unwinder to
go to lunch if taking a segfault in the vdso. This patch fixes it.
Problem identified by Andrew Haley, and fix provided by Jakub Jelinek
(thanks !).
Unfortunately, a bug in gcc cause it to not quite work either, but that
is being fixed separately with something around the lines of:
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Index: linux-work/arch/powerpc/kernel/vdso64/sigtramp.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:32:49.000000000 +1000
+++ linux-work/arch/powerpc/kernel/vdso64/sigtramp.S 2007-10-17 13:34:18.000000000 +1000
@@ -134,13 +134,16 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
9:
/* This is where the pt_regs pointer can be found on the stack. */
-#define PTREGS 128+168+56
+#define PTREGS 128+168+56
/* Size of regs. */
-#define RSIZE 8
+#define RSIZE 8
+
+/* Size of CR reg in DWARF unwind info. */
+#define CRSIZE 4
/* This is the offset of the VMX reg pointer. */
-#define VREGS 48*RSIZE+33*8
+#define VREGS 48*RSIZE+33*8
/* Describe where general purpose regs are saved. */
#define EH_FRAME_GEN \
@@ -178,7 +181,7 @@ V_FUNCTION_END(__kernel_sigtramp_rt64)
rsave (31, 31*RSIZE); \
rsave (67, 32*RSIZE); /* ap, used as temp for nip */ \
rsave (65, 36*RSIZE); /* lr */ \
- rsave (70, 38*RSIZE) /* cr */
+ rsave (70, 38*RSIZE + (RSIZE - CRSIZE)) /* cr */
/* Describe where the FP regs are saved. */
#define EH_FRAME_FP \
^ permalink raw reply
* Re: current -git adbhid.c build error
From: Paul Mackerras @ 2007-10-17 4:19 UTC (permalink / raw)
To: Joseph Fannin; +Cc: linuxppc-dev, Dmitry Torokhov
In-Reply-To: <20071016181644.GA9337@nineveh.local>
Joseph Fannin writes:
> Commit b981d8b3f5e008ff10d993be633ad00564fc22cd in Linus's git tree
> did this:
>
>
> @@ -374,9 +373,9 @@ adbhid_input_keycode(int id, int scancode, int repeat)
> #endif /* CONFIG_PPC_PMAC */
> }
>
> - if (adbhid[id]->keycode[keycode]) {
> - input_report_key(adbhid[id]->input,
> - adbhid[id]->keycode[keycode],
> adbhid[id]->!up_flag);
> + key = adbhid[id]->keycode[keycode];
> + if (key) {
> + input_report_key(adbhid[id]->input, key, !up_flag);
> input_sync(adbhid[id]->input);
> } else
> printk(KERN_INFO "Unhandled ADB key (scancode %#02x)
> %s.\n", keycode,
>
> ... but did not define "key":
It was a mis-merge between 555ddbb4, which made that change and *did*
add the declaration of key, and 9a402b64, which deleted the line that
the declaration of key was added to.
We need the patch below. Dmitry, will you push it or will I?
Paul.
[PATCH] Restore declaration of key in adbhid_input_keycode.
Merge commit b981d8b3f5e008ff10d993be633ad00564fc22cd lost the
declaration of `key' that 555ddbb4e2191c8823df2d61525218ac39481385
added, resulting in failure to compile. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/drivers/macintosh/adbhid.c b/drivers/macintosh/adbhid.c
index 8cce016..2766e4f 100644
--- a/drivers/macintosh/adbhid.c
+++ b/drivers/macintosh/adbhid.c
@@ -282,7 +282,7 @@ static void
adbhid_input_keycode(int id, int scancode, int repeat)
{
struct adbhid *ahid = adbhid[id];
- int keycode, up_flag;
+ int keycode, up_flag, key;
keycode = scancode & 0x7f;
up_flag = scancode & 0x80;
^ permalink raw reply related
* Re: PPC440EPx GPIO control help
From: David Hawkins @ 2007-10-17 4:15 UTC (permalink / raw)
To: Dell Query; +Cc: linuxppc-embedded
In-Reply-To: <400754.83957.qm@web45604.mail.sp1.yahoo.com>
Hi Dell,
> I am a Linux and PPC newbie.
Ok.
> I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21.
> What I would want to do is to control (write and read values to) its
> GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and
> inportb(0x378) to read. I read the PPC440EPx manual but I find it
> difficult to understand.
>
> Could anyone show me any tutorial or some sample codes?
I copied the code below from some test code I wrote for a TS7300
board (uses an ARM EP9302 processor). However, since its user-space
code it should work fine.
Generally for manipulating I/Os you write a custom driver. However,
when getting to know a processor, it sometimes helps to cheat and
just write to registers directly.
The code below uses /dev/mem to map a page or more of the processor
address space into your process. Go find the byte address of your
GPIO registers and pass that as the argument.
Google for /dev/mem and you'll find lots of code that looks more
or less like this. This code just gives you a minimal console so
that you can mess with multiple registers.
BTW, you can really screw yourself if you mess with registers
you shouldn't, eg. memory controller settings etc. So be careful.
From the looks of the code, it provides options for
32-bit access or 8-bit access.
Cheers,
Dave
/*
* mem_debug.c
*
* 5/10/07 D. W. Hawkins (dwh@ovro.caltech.edu)
*
* A debug console for read/write access to /dev/mem mapped
* areas.
*/
#include <stdio.h>
#include <errno.h>
#include <string.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <sys/mman.h>
#include <stdlib.h>
#include <unistd.h>
void display_help();
void change_mem(char *cmd);
void display_mem(char *cmd);
void process_command(char *cmd);
/* Mapped address and size */
static char *mem_addr = NULL;
static unsigned int mem_phys = 0;
static unsigned int mem_pages = 0;
static unsigned int mem_size = 0;
static void show_usage()
{
printf("\nUsage: mem_debug -a <address> -n <pages>\n"\
" -h Help (this message)\n"\
" -a <address> Hex address to start the map\n"\
" -n <pages> Number of pages to map\n\n");
}
int main(int argc, char *argv[])
{
int opt; /* getopt processing */
int fd; /* /dev/mem file descriptor */
char buf[200]; /* command processing buffer */
int len = 200;
int page_size = getpagesize();
int status;
while ((opt = getopt(argc, argv, "a:hn:")) != -1) {
switch (opt) {
case 'a':
status = sscanf(optarg, "%X", &mem_phys);
if (status != 1) {
printf("Parse error for -a option\n");
show_usage();
return -1;
}
break;
case 'h':
show_usage();
return -1;
case 'n':
mem_pages = atoi(optarg);
break;
default:
show_usage();
return -1;
}
}
if (mem_phys != (mem_phys/page_size)*page_size) {
printf("Error: the address must be page-aligned (0x%X)\n",
page_size);
return -1;
}
if (mem_pages == 0) {
mem_pages = 1;
}
mem_size = mem_pages*page_size;
/* Startup */
printf("\n------------------------\n");
printf("/dev/mem debug interface\n");
printf("========================\n\n");
/* Open /dev/mem and map it */
printf(" * open /dev/mem\n");
fd = open("/dev/mem", O_RDWR | O_SYNC);
if (fd < 0) {
printf("Open /dev/mem failed - %s\n",
strerror(errno));
return -1;
}
printf(" * map %d page(s) (%d-bytes) at address 0x%.8X\n",
mem_pages, mem_size, mem_phys);
mem_addr = (char *)mmap(
0,
mem_size,
PROT_READ|PROT_WRITE,
MAP_SHARED,
fd,
mem_phys);
if (mem_addr == (char *)MAP_FAILED) {
printf("Error: mmap failed\n");
close(fd);
return -1;
}
/* Display help */
display_help();
/* Process commands */
while (1) {
printf("CMD> ");
fflush(stdout);
fgets(buf,len,stdin);
process_command(buf);
}
/* Cleanup */
munmap((void *)mem_addr, mem_pages*page_size);
close(fd);
return 0;
}
/*--------------------------------------------------------------------
* User interface
*--------------------------------------------------------------------
*/
void display_help()
{
printf("\n ? Help\n");
printf(" dw addr len Display len words starting from addr\n");
printf(" db addr len Display len bytes starting from addr\n");
printf(" cw addr val Change word at addr to val\n");
printf(" cb addr val Change byte at addr to val\n");
printf(" q Quit\n");
printf("\n Notes:\n");
printf(" * addr, len, and val are interpreted as hex values\n");
printf(" * addresses are always byte based\n");
printf(" * addresses are offsets relative to the base address\n\n");
}
void process_command(char *cmd)
{
if (cmd[0] == '\0') {
return;
}
switch (cmd[0]) {
case '?':
display_help();
break;
case 'd':
case 'D':
display_mem(cmd);
break;
case 'c':
case 'C':
change_mem(cmd);
break;
case 'q':
case 'Q':
exit(0);
default:
break;
}
return;
}
void display_mem(char *cmd)
{
char width = 0;
int addr = 0;
int len = 0;
int status;
int i, data;
/* d, db, dw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &len);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
if (len > mem_size) {
len = mem_size;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
for (i = 0; i < len; i++) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = (int)(mem_addr[addr+i]) & 0xFF;
printf("%.02X ", data);
}
printf("\n");
break;
default:
for (i = 0; i < len; i+=4) {
if ((i%16) == 0) {
printf("\n%.8X: ", mem_phys + addr + i);
}
data = *(int *)(mem_addr + addr + i);
printf("%.08X ", data);
}
printf("\n");
break;
}
printf("\n");
return;
}
void change_mem(char *cmd)
{
char width = 0;
int addr = 0;
int data = 0;
int status;
/* c, cb, cw */
status = sscanf(cmd, "%*c%c %x %x", &width, &addr, &data);
if (status != 3) {
printf("syntax error (use ? for help)\n");
return;
}
/* Convert to offset if required */
if (addr >= mem_phys) {
addr -= mem_phys;
}
if (addr >= mem_size) {
printf("Illegal address\n");
return;
}
switch (width) {
case 'b':
mem_addr[addr] = data & 0xFF;
break;
default:
*(int *)(mem_addr + addr) = data;
break;
}
return;
}
^ permalink raw reply
* Re: Tx Command of MPC8280 hangs the kernel
From: Misbah khan @ 2007-10-17 4:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <e5eb93010710111728y6ef1e12che0cec8303c30d64d@mail.gmail.com>
Can u send the part of the code for better understanding
-Misbah
suresh suresh wrote:
>
> Hi,
>
> I am facing kernel hang when ATM Tx command is issued. I am using SUSE
> linux. Does anyone have any idea why it is happening?
>
>
> Regards,
> Suresh
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
View this message in context: http://www.nabble.com/Tx-Command-of-MPC8280-hangs-the-kernel-tf4610753.html#a13246766
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH 2/2] [POWERPC] Use of_register_driver to implement of_register_platform_driver
From: Stephen Rothwell @ 2007-10-17 3:43 UTC (permalink / raw)
To: paulus; +Cc: sparclinux, ppc-dev, David S. Miller, wli
In-Reply-To: <20071017134123.cfe10b79.sfr@canb.auug.org.au>
Also of_unregister{,_platform}_driver.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/of_platform.c | 20 --------------------
include/asm-powerpc/of_platform.h | 10 ++++++++--
2 files changed, 8 insertions(+), 22 deletions(-)
This depends on the Sparc part (patch 1/2) being in the tree first.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/of_platform.c b/arch/powerpc/kernel/of_platform.c
index eca8ccc..9b01602 100644
--- a/arch/powerpc/kernel/of_platform.c
+++ b/arch/powerpc/kernel/of_platform.c
@@ -67,26 +67,6 @@ static int __init of_bus_driver_init(void)
postcore_initcall(of_bus_driver_init);
-int of_register_platform_driver(struct of_platform_driver *drv)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = &of_platform_bus_type;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-EXPORT_SYMBOL(of_register_platform_driver);
-
-void of_unregister_platform_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-EXPORT_SYMBOL(of_unregister_platform_driver);
-
static void of_platform_make_bus_id(struct of_device *dev)
{
struct device_node *node = dev->node;
diff --git a/include/asm-powerpc/of_platform.h b/include/asm-powerpc/of_platform.h
index 80e6fad..d20a4cd 100644
--- a/include/asm-powerpc/of_platform.h
+++ b/include/asm-powerpc/of_platform.h
@@ -15,8 +15,14 @@
#include <linux/of_platform.h>
/* Platform drivers register/unregister */
-extern int of_register_platform_driver(struct of_platform_driver *drv);
-extern void of_unregister_platform_driver(struct of_platform_driver *drv);
+static inline int of_register_platform_driver(struct of_platform_driver *drv)
+{
+ return of_register_driver(drv, &of_platform_bus_type);
+}
+static inline void of_unregister_platform_driver(struct of_platform_driver *drv)
+{
+ of_unregister_driver(drv);
+}
/* Platform devices and busses creation */
extern struct of_device *of_platform_device_create(struct device_node *np,
--
1.5.3.4
^ permalink raw reply related
* [PATCH 1/2] [SPARC/64] Consolidate of_register_driver
From: Stephen Rothwell @ 2007-10-17 3:41 UTC (permalink / raw)
To: David S. Miller; +Cc: sparclinux, ppc-dev, wli
Also of_unregister_driver. These will be shortly also used by the
PowerPC code.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/kernel/of_device.c | 20 --------------------
arch/sparc64/kernel/of_device.c | 20 --------------------
drivers/of/platform.c | 21 +++++++++++++++++++++
include/asm-sparc/of_platform.h | 5 +----
include/asm-sparc64/of_platform.h | 5 +----
include/linux/of_platform.h | 4 ++++
6 files changed, 27 insertions(+), 48 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/sparc/kernel/of_device.c b/arch/sparc/kernel/of_device.c
index fb2caef..3ea000d 100644
--- a/arch/sparc/kernel/of_device.c
+++ b/arch/sparc/kernel/of_device.c
@@ -585,24 +585,6 @@ static int __init of_debug(char *str)
__setup("of_debug=", of_debug);
-int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = bus;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-
-void of_unregister_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-
struct of_device* of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
@@ -628,6 +610,4 @@ struct of_device* of_platform_device_create(struct device_node *np,
return dev;
}
-EXPORT_SYMBOL(of_register_driver);
-EXPORT_SYMBOL(of_unregister_driver);
EXPORT_SYMBOL(of_platform_device_create);
diff --git a/arch/sparc64/kernel/of_device.c b/arch/sparc64/kernel/of_device.c
index 42d7798..fc5c0cc 100644
--- a/arch/sparc64/kernel/of_device.c
+++ b/arch/sparc64/kernel/of_device.c
@@ -869,26 +869,6 @@ static int __init of_debug(char *str)
__setup("of_debug=", of_debug);
-int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
-{
- /* initialize common driver fields */
- if (!drv->driver.name)
- drv->driver.name = drv->name;
- if (!drv->driver.owner)
- drv->driver.owner = drv->owner;
- drv->driver.bus = bus;
-
- /* register with core */
- return driver_register(&drv->driver);
-}
-EXPORT_SYMBOL(of_register_driver);
-
-void of_unregister_driver(struct of_platform_driver *drv)
-{
- driver_unregister(&drv->driver);
-}
-EXPORT_SYMBOL(of_unregister_driver);
-
struct of_device* of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 864f09f..b47bb2d 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -12,6 +12,7 @@
*
*/
#include <linux/errno.h>
+#include <linux/module.h>
#include <linux/device.h>
#include <linux/of_device.h>
#include <linux/of_platform.h>
@@ -94,3 +95,23 @@ int of_bus_type_init(struct bus_type *bus, const char *name)
bus->resume = of_platform_device_resume;
return bus_register(bus);
}
+
+int of_register_driver(struct of_platform_driver *drv, struct bus_type *bus)
+{
+ /* initialize common driver fields */
+ if (!drv->driver.name)
+ drv->driver.name = drv->name;
+ if (!drv->driver.owner)
+ drv->driver.owner = drv->owner;
+ drv->driver.bus = bus;
+
+ /* register with core */
+ return driver_register(&drv->driver);
+}
+EXPORT_SYMBOL(of_register_driver);
+
+void of_unregister_driver(struct of_platform_driver *drv)
+{
+ driver_unregister(&drv->driver);
+}
+EXPORT_SYMBOL(of_unregister_driver);
diff --git a/include/asm-sparc/of_platform.h b/include/asm-sparc/of_platform.h
index 64a2300..d638737 100644
--- a/include/asm-sparc/of_platform.h
+++ b/include/asm-sparc/of_platform.h
@@ -18,12 +18,9 @@
extern struct bus_type ebus_bus_type;
extern struct bus_type sbus_bus_type;
-extern struct bus_type of_platform_bus_type;
+
#define of_bus_type of_platform_bus_type /* for compatibility */
-extern int of_register_driver(struct of_platform_driver *drv,
- struct bus_type *bus);
-extern void of_unregister_driver(struct of_platform_driver *drv);
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/include/asm-sparc64/of_platform.h b/include/asm-sparc64/of_platform.h
index f7c1f17..f15cfa7 100644
--- a/include/asm-sparc64/of_platform.h
+++ b/include/asm-sparc64/of_platform.h
@@ -19,12 +19,9 @@
extern struct bus_type isa_bus_type;
extern struct bus_type ebus_bus_type;
extern struct bus_type sbus_bus_type;
-extern struct bus_type of_platform_bus_type;
+
#define of_bus_type of_platform_bus_type /* for compatibility */
-extern int of_register_driver(struct of_platform_driver *drv,
- struct bus_type *bus);
-extern void of_unregister_driver(struct of_platform_driver *drv);
extern struct of_device *of_platform_device_create(struct device_node *np,
const char *bus_id,
struct device *parent,
diff --git a/include/linux/of_platform.h b/include/linux/of_platform.h
index 448f70b..a8efcfe 100644
--- a/include/linux/of_platform.h
+++ b/include/linux/of_platform.h
@@ -48,6 +48,10 @@ struct of_platform_driver
#define to_of_platform_driver(drv) \
container_of(drv,struct of_platform_driver, driver)
+extern int of_register_driver(struct of_platform_driver *drv,
+ struct bus_type *bus);
+extern void of_unregister_driver(struct of_platform_driver *drv);
+
#include <asm/of_platform.h>
extern struct of_device *of_find_device_by_node(struct device_node *np);
--
1.5.3.4
^ permalink raw reply related
* PPC440EPx GPIO control help
From: Dell Query @ 2007-10-17 3:29 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Hi,
I am a Linux and PPC newbie.
I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.
Could anyone show me any tutorial or some sample codes?
Thanks,
Dell
---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
[-- Attachment #2: Type: text/html, Size: 884 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Benjamin Herrenschmidt @ 2007-10-17 3:24 UTC (permalink / raw)
To: Jeff Garzik
Cc: netdev, Roland Dreier, Stephen Hemminger, David S. Miller,
linuxppc-dev list
In-Reply-To: <47157EA4.1000500@garzik.org>
\
> > Note: unfortunately, Jeff already picked up the EMAC patch without
> > waiting for this to be sorted out (oops...). So if you agree with
> > this patch, it would be nice to have it go in quickly or maybe via
> > Jeff's tree to avoid breakage ? Not terribly important tho.
>
>
> Sorry, I thought that was the way everybody was headed. With the driver
> broken /anyway/, I just sorta threw it into the pile of fixes.
>
> It's upstream now, so let me know if you want to revert or move forward
> from here...
Let's just move forward. I can always re-fix the driver :-)
Ben.
^ permalink raw reply
* PPC440EPx GPIO control help
From: Dell Query @ 2007-10-17 3:14 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
Hi,
I am a Linux and PPC newbie.
I have a PPC440EPx Sequoia Evaluation board that runs on Linux 2.6.21. What I would want to do is to control (write and read values to) its GPIO. Perhaps similar to Turbo C's outputb(0x378,0x01) to write and inportb(0x378) to read. I read the PPC440EPx manual but I find it difficult to understand.
Could anyone show me any tutorial or some sample codes?
Thanks,
Dell
---------------------------------
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.
[-- Attachment #2: Type: text/html, Size: 639 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] net: Add __napi_sycnhronize() to sync with napi poll
From: Jeff Garzik @ 2007-10-17 3:16 UTC (permalink / raw)
To: benh
Cc: netdev, Roland Dreier, Stephen Hemminger, David S. Miller,
linuxppc-dev list
In-Reply-To: <1192589522.11899.130.camel@pasglop>
Benjamin Herrenschmidt wrote:
> net: Add __napi_synchronize() to sync with napi poll
>
> The EMAC driver which needs to handle multiple devices with one
> NAPI instance implements its own per-channel disable bit. However,
> when setting such a bit, it needs to synchronize with the poller
> (that is make sure that any pending poller instance has completed,
> or is started late enough to see that disable bit).
>
> This implements a low level __napi_synchronize() function to acheive
> that. The underscores are to emphasis the low level aspect of it and
> to discourage driver writers who don't know what they are doing to
> use it (to please DaveM :-)
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> Switched to do a cpu_relax() spin instead and only on SMP. Not that
> we have an smp_mb() in there which synchronize_irq() lacks. I believe
> this is a bug in synchronize_irq() which I'll handle separately.
>
> Note: unfortunately, Jeff already picked up the EMAC patch without
> waiting for this to be sorted out (oops...). So if you agree with
> this patch, it would be nice to have it go in quickly or maybe via
> Jeff's tree to avoid breakage ? Not terribly important tho.
Sorry, I thought that was the way everybody was headed. With the driver
broken /anyway/, I just sorta threw it into the pile of fixes.
It's upstream now, so let me know if you want to revert or move forward
from here...
Jeff
^ permalink raw reply
* Re: mpc 860 boot linux2.6.23 problem
From: Dan Malek @ 2007-10-17 2:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-embedded@ozlabs.org
In-Reply-To: <4714E44F.7030909@freescale.com>
On Oct 16, 2007, at 12:18 PM, Scott Wood wrote:
> Upgrading to the latest u-boot certainly shouldn't hurt, but I don't
> think there's any device tree support for 8xx yet,
Have you tried it? Works for me. In fact, most
of the development you see today was done
by Pantelis on the 8xx.
-- Dan
^ permalink raw reply
* Re: [PATCH v2] Device tree bindings for Xilinx devices
From: Grant Likely @ 2007-10-17 3:03 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: linuxppc-dev, microblaze-uclinux, Wolfgang Reissnegger, Leonid
In-Reply-To: <fa686aa40710161935p2aef36efx6154071b0055698f@mail.gmail.com>
On 10/16/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 10/16/07, Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: glikely@secretlab.ca [mailto:glikely@secretlab.ca] On
> > > Behalf Of Grant Likely
> > > Sent: Tuesday, October 16, 2007 12:36 PM
> > > To: Stephen Neuendorffer
> > > Cc: linuxppc-dev@ozlabs.org; Wolfgang Reissnegger; Leonid;
> > > microblaze-uclinux@itee.uq.edu.au
> > > Subject: Re: [PATCH v2] Device tree bindings for Xilinx devices
> > >
> > > On 10/16/07, Stephen Neuendorffer
> > > <stephen.neuendorffer@xilinx.com> wrote:
> > > >
> > > > > + n) Xilinx EMAC and Xilinx TEMAC
> > > > > +
> > > > > + Xilinx Ethernet devices. Uses common properties from
> > > > > other Ethernet
> > > > > + devices with the following constraints:
> > > > > +
> > > > > + Required properties:
> > > > > + - compatible : Must include one of: "xilinx,plb-temac",
> > > > > + "xilinx,plb-emac", "xilinx-opb-emac"
> > > > > + - dma-mode : Must be one of "none", "simple", "sg" (sg
> > > > > == scatter gather)
> > > >
> > > > I think it's going to be a significant headache to remap
> > > things like the
> > > > dma-mode from the xilinx configurations to something else, and then
> > > > interpret them correctly in the drivers.
> > > >
> > > > Although it lacks a bit in style, perhaps, I'd greatly prefer having
> > > > something like:
> > > >
> > > > Ethernet_MAC {
> > > > xilinx,C_DMA_PRESENT = <1>;
> > > > ...
> > > > }
> > > >
> > > > (which happens to correspond to "none" above)
> > >
> > > Ugh. Can't say I'm thrilled about this....
> > >
> > > But in this case is might be a necessity. The IP core is already
> > > parameterized and the best way to describe the device is to use the
> > > existing parameter names.
> >
> > I don't really like it either, expecially after thinking about it more.
> > The problem is that a single IP core might correspond to multiple
> > logical devices. The parameters actually need to be from the point of
> > view of the drivers. That is, they need to be names like in the
> > xparameters:
> >
> > xilinx,DMA_PRESENT = <1>;
>
> Hmm, not bad. It does still get a little harry when one IP core
> implements multiple logical devices, but maybe the IP core should
> create a node and the logical devices can be sub nodes with the
> appropriate properties needed to describe which logical device it is.
>
> >
> > In this case, the translation looks simple, but it is currently
> > implemented by a bunch of gnarly .tcl code. (Don't ask... :) In the
> > future, this *could* be simple code, but in the short term, it won't be
> > any simpler than having pretty names. Furthermore, the best driver code
> > that I can come up with for using this essentially looks like:
> >
> > static int __devinit xenet_of_probe(struct of_device *ofdev, const
> > struct of_device_id *match)
> > {
> > struct xemac_platform_data pdata_struct;
> > struct resource r_irq_struct;
> > struct resource r_mem_struct;
> >
> > struct resource *r_irq = &r_irq_struct; /* Interrupt resources
> > */
> > struct resource *r_mem = &r_mem_struct; /* IO mem resources */
> > struct xemac_platform_data *pdata = &pdata_struct;
> > int rc = 0;
> >
> > printk(KERN_ERR "Device Tree Probing \'%s\'\n",
> > ofdev->node->name);
> >
> > /* Get iospace for the device */
> > rc = of_address_to_resource(ofdev->node, 0, r_mem);
> > if(rc) {
> > dev_warn(&ofdev->dev, "invalid address\n");
> > return rc;
> > }
> >
> > /* Get IRQ for the device */
> > rc = of_irq_to_resource(ofdev->node, 0, r_irq);
> > if(rc == NO_IRQ) {
> > dev_warn(&ofdev->dev, "no IRQ found.\n");
> > return rc;
> > }
> >
> > pdata_struct.dma_mode = get_u32(ofdev,
> > "C_DMA_PRESENT");
> > pdata_struct.has_mii = get_u32(ofdev, "C_MII_EXIST");
> > pdata_struct.has_cam = get_u32(ofdev, "C_CAM_EXIST");
> > pdata_struct.has_err_cnt = get_u32(ofdev,
> > "C_ERR_COUNT_EXIST");
> > pdata_struct.has_jumbo = get_u32(ofdev,
> > "C_JUMBO_EXIST");
> > pdata_struct.tx_dre = get_u32(ofdev,
> > "C_TX_DRE_TYPE");
> > pdata_struct.rx_dre = get_u32(ofdev,
> > "C_RX_DRE_TYPE");
> > pdata_struct.tx_hw_csum = get_u32(ofdev,
> > "C_TX_INCLUDE_CSUM");
> > pdata_struct.rx_hw_csum = get_u32(ofdev,
> > "C_RX_INCLUDE_CSUM");
> > memcpy(pdata_struct.mac_addr, of_get_mac_address(ofdev->node),
> > 6);
> >
> > return probe_initialization(&ofdev->dev, r_mem, r_irq, pdata);
> > }
> >
> > Where probe_initialization contains shares code with the platform_device
> > version of probe. This means that the string is still translated into
> > another name anyway. Anybody have any better ideas for doing this?
>
> That's pretty close to what I've done on the sysace, uartlite and
> xilinxfb drivers.
>
> > > I want to be careful though. Parameters can change from one version
> > > of an IP core to another. The driver needs to be able to determine
> > > what version of the IP core is used so that the parameters make sense.
> > > I'm also nervous about adding every possible C_ value to the device
> > > node for each xilinx IP-core; that could make the device tree quite
> > > large. (on the other hand; maybe that doesn't matter... It is
> > > probably a bigger deal for microblaze than powerpc too.).
> >
> > Using the xparameters set of values could solve this problem, since only
> > things that make sense to the driver are actually set.
>
> I've thought about this more since I wrote the above paragraph. The
> compatible property was designed to solve that exact problem. We'll
> just embed the version in the compatible list.
And, yes, you're right. Using the xparams value set is probably the
place to start for choosing which properties to put in the device
tree. I'll document this stuff up and respin my patch.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox