* [POWERPC] iseries: remove const warning
From: Stephen Rothwell @ 2006-08-16 5:24 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Just one bit of fallout from the constification of the get_property
return value.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/viopath.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/viopath.c b/arch/powerpc/platforms/iseries/viopath.c
index efeb6ae..9baa4ee 100644
--- a/arch/powerpc/platforms/iseries/viopath.c
+++ b/arch/powerpc/platforms/iseries/viopath.c
@@ -117,6 +117,7 @@ static int proc_viopath_show(struct seq_
HvLpEvent_Rc hvrc;
DECLARE_MUTEX_LOCKED(Semaphore);
struct device_node *node;
+ const char *sysid;
buf = kmalloc(HW_PAGE_SIZE, GFP_KERNEL);
if (!buf)
@@ -152,15 +153,15 @@ static int proc_viopath_show(struct seq_
seq_printf(m, "AVAILABLE_VETH=%x\n", vlanMap);
node = of_find_node_by_path("/");
- buf = NULL;
+ sysid = NULL;
if (node != NULL)
- buf = get_property(node, "system-id", NULL);
+ sysid = get_property(node, "system-id", NULL);
- if (buf == NULL)
+ if (sysid == NULL)
seq_printf(m, "SRLNBR=<UNKNOWN>\n");
else
/* Skip "IBM," on front of serial number, see dt.c */
- seq_printf(m, "SRLNBR=%s\n", buf + 4);
+ seq_printf(m, "SRLNBR=%s\n", sysid + 4);
of_node_put(node);
--
1.4.1.1
^ permalink raw reply related
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Michael Ellerman @ 2006-08-16 5:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060816152032.2407a832.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> gcc 4.1 produces some warnings that it is ignoring the packed attribute
> on some structure elements, so just remove them.
Why is it ignoring them? Because there's no packing to be done?
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-16 5:32 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1155705964.12715.8.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
On Wed, 16 Aug 2006 15:26:04 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> > gcc 4.1 produces some warnings that it is ignoring the packed attribute
> > on some structure elements, so just remove them.
>
> Why is it ignoring them? Because there's no packing to be done?
A patch went into gcc to warn if the thing you are packing is already
minimally aligned. I have not idea why it warns ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Alan Modra @ 2006-08-16 6:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060816153206.5bd2d64e.sfr@canb.auug.org.au>
On Wed, Aug 16, 2006 at 03:32:06PM +1000, Stephen Rothwell wrote:
> On Wed, 16 Aug 2006 15:26:04 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> > > gcc 4.1 produces some warnings that it is ignoring the packed attribute
> > > on some structure elements, so just remove them.
> >
> > Why is it ignoring them? Because there's no packing to be done?
>
> A patch went into gcc to warn if the thing you are packing is already
> minimally aligned. I have not idea why it warns ...
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01883.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Problems dynamically linking busybox with ppc libs.
From: Keith Redfern @ 2006-08-16 8:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
I am trying to dynamically link busybox with the correct libraries but
run into problems with directory paths and CC/LD flags.
I am using the toolchain supplied with ELDK and my target board is
ppc_8xx based. The busybox version that I am using is 1.1.3.
I see the following in Rules.mak and have been trying different variable
options but with no success.
# To compile vs some other alternative libc, you may need to use/adjust
# the following lines to meet your needs...
#
# If you are using Red Hat 6.x with the compatible RPMs (for developing
under
# Red Hat 5.x and glibc 2.0) uncomment the following. Be sure to read
about
# using the compatible RPMs (compat-*) at http://www.redhat.com !
#LIBCDIR:=/usr/i386-glibc20-linux
#
# For other libraries, you are on your own. But these may (or may not)
help...
#LDFLAGS+=-nostdlib
#LIBRARIES:=$(LIBCDIR)/lib/libc.so.6
#CROSS_CFLAGS+=-nostdinc -I$(LIBCDIR)/include -I$(GCCINCDIR)
-funsigned-char
#GCCINCDIR:=$(shell gcc -print-search-dirs | sed -ne "s/install:
\(.*\)/\1include/gp")
#
# For other libraries, you are on your own. But these may (or may not)
help...
Is this the correct place to make modifications?
Has anyone already figured the changes required to get this to work with
ELDK toolchain?
Any insight would be useful.
......Keith
Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: Type: text/html, Size: 8370 bytes --]
^ permalink raw reply
* boot kernel 2.6.18 is hang???
From: jie han @ 2006-08-16 9:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4719 bytes --]
I am trying to take a working embedded linux system from kernel 2.4 to
2.6. The hardware is a custom board using a mpc8270vr processor.
The working system uses u-boot 1.1.4 with linux kernel 2.4.24.
I am using the same u-boot and I am trying to port linux kernel 2.6.18.
I believe I have done everything required to get the kernel booting. However, the kernel
seems to hang after being uncompressed. Here is what I see after running
bootm from u-boot:
OLT=> tftp 500000 uImage
Using FCC1 ETHERNET device
TFTP from server 192.168.2.45; our IP address is 192.168.2.109
Filename 'uImage'.
Load address: 0x500000
Loading: #################################################################
#################################################################
#################################################################
done
Bytes transferred = 995314 (f2ff2 hex)
OLT=> bootm 500000
## Booting image at 00500000 ...
Image Name: Linux-2.6.18/Ocean BoradBand Ltd
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 995250 Bytes = 971.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
log_buf context is
OLT=> md 1b9d60 100
001b9d60: c020c0a4 00004000 00000000 ffffffff . ....@.........
001b9d70: 00000001 c01b9d74 c01b9d74 00000001 .......t...t....
001b9d80: c01b9d80 c01b9d80 ffffffff 61637175 ............acqu
001b9d90: 6972655f 636f6e73 6f6c655f 73656d00 ire_console_sem.
001b9da0: 63616c6c 5f636f6e 736f6c65 5f647269 call_console_dri
001b9db0: 76657273 00000000 ffffffff 00000001 vers............
001b9dc0: 00001388 00000000 00000000 c001571c ..............W.
001b9dd0: 00000000 c001589c 00000000 00000000 ......X.........
001b9de0: 00000000 00000000 00000000 00000000 ................
001b9df0: 00000000 00000000 00000000 00000000 ................
001b9e00: 00000000 00000000 00000000 00000000 ................
001b9e10: 00000000 00000000 00000000 00000000 ................
001b9e20: 00000000 00000000 00000000 00000000 ................
001b9e30: 00000000 00000000 00000001 65786974 ............exit
001b9e40: 5f6d6d00 5f5f6578 69745f73 69676e61 _mm.__exit_signa
001b9e50: 6c000000 72656c65 6173655f 7461736b l...release_task
001b9e60: 00000000 63686f6f 73655f6e 65775f70 ....choose_new_p
001b9e70: 6172656e 74000000 666f7267 65745f6f arent...forget_o
001b9e80: 72696769 6e616c5f 70617265 6e740000 riginal_parent..
001b9e90: 65786974 5f6e6f74 69667900 646f5f65 exit_notify.do_e
001b9ea0: 78697400 646f5f67 726f7570 5f657869 xit.do_group_exi
001b9eb0: 74000000 77616974 5f746173 6b5f636f t...wait_task_co
001b9ec0: 6e74696e 75656400 77616974 5f746173 ntinued.wait_tas
001b9ed0: 6b5f7a6f 6d626965 00000000 77616974 k_zombie....wait
001b9ee0: 5f746173 6b5f7374 6f707065 64000000 _task_stopped...
001b9ef0: 646f5f77 61697400 0000000a 00000001 do_wait.........
001b9f00: c0019b50 00000000 00000000 6370755f ...P........cpu_
001b9f10: 63616c6c 6261636b 00000000 00000001 callback........
001b9f20: 00000001 5f5f6c6f 63616c5f 62685f65 ....__local_bh_e
001b9f30: 6e61626c 65000000 00000001 00000001 nable...........
001b9f40: 5f6c6f63 616c5f62 685f656e 61626c65 _local_bh_enable
001b9f50: 00000000 7461736b 6c65745f 61637469 ....tasklet_acti
001b9f60: 6f6e0000 7461736b 6c65745f 68695f61 on..tasklet_hi_a
001b9f70: 6374696f 6e000000 00000001 00000001 ction...........
001b9f80: 6c6f6361 6c5f6268 5f656e61 626c6500 local_bh_enable.
001b9f90: 00000001 6c6f6361 6c5f6268 5f656e61 ....local_bh_ena
001b9fa0: 626c655f 69700000 00000001 5f5f6c6f ble_ip......__lo
001b9fb0: 63616c5f 62685f64 69736162 6c650000 cal_bh_disable..
001b9fc0: 00000000 ffffffff c018a9b0 00000200 ................
001b9fd0: 00000000 00000000 00000000 00000000 ................
001b9fe0: ffffffff c018a9b8 00000100 00000000 ................
001b9ff0: 00000000 00000000 00000000 c0075590 ..............U.
001ba000: c0075878 00000000 00000000 00000000 ..Xx............
001ba010: 00000000 00000000 00000000 00000000 ................
001ba020: 00000000 00000000 c001a53c 00000000 ...........<....
001ba030: c0075014 00000000 00000000 00000000 ..P.............
001ba040: 00000000 00000000 00000000 00000000 ................
001ba050: 00000000 00000000 00000000 00000000 ................
001ba060: 00000000 00000000 00000000 00000000 ................
001ba070: c0075590 c0075878 00000000 00000000 ..U...Xx........
Any ideas would be appreciated.
Regards,
Jie
---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
[-- Attachment #2: Type: text/html, Size: 5100 bytes --]
^ permalink raw reply
* [PATCH] Gunzip call fix for PPC kernel images >4MB
From: Benjamin Heyne @ 2006-08-16 9:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini, Paul Mackerras, Milton Miller
If Kernel images for PPC grow >4MB inflating of the kernel fails.
Increasing the link/load address doesn't help. Problem is
solved by replacing the fixed address of the gunzip() call in
misc-embedded.c with CONFIG_BOOT_LOAD.
Signed-off-by: Benjamin Heyne <benjamin.heyne@uni-dortmund.de>
---
--- arch/ppc/boot/simple/misc-embedded.c.orig 2006-08-16 10:56:10.000000000 +0200
+++ arch/ppc/boot/simple/misc-embedded.c 2006-08-16 10:56:55.000000000 +0200
@@ -213,7 +213,7 @@ load_kernel(unsigned long load_addr, int
*cp = 0;
puts("\nUncompressing Linux...");
- gunzip(0, 0x400000, zimage_start, &zimage_size);
+ gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
flush_instruction_cache();
puts("done.\n");
{
--
Benjamin Heyne
=======================================================
Arbeitsgebiet Datentechnik, Universitaet Dortmund
Information Processing Lab, University of Dortmund
Otto-Hahn-Strasse 4, 44227 Dortmund, Germany
Fon: +49 231 755 7017, Fax: +49 231 755 7019
www.dt.e-technik.uni-dortmund.de, Raum/Room P1-04-217
^ permalink raw reply
* Re: Who cares about PReP?
From: Gabriel Paubert @ 2006-08-16 10:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17622.58559.879330.496619@cargo.ozlabs.ibm.com>
On Mon, Aug 07, 2006 at 04:59:11PM +1000, Paul Mackerras wrote:
> I started looking at moving the PReP code over to arch/powerpc. I am
> struck by how many ifdefs there are in there to set things up for
> particular individual PReP implementations. We can do better than
> that, I'm sure,
hopefully.
> but the issue becomes one of testing. The only PReP I
> have here is an RS/6000 43p-140.
>
> Who else has a PReP system and would be willing to do some testing and
> debugging? If so, what sort of PReP is it?
We are using 20+ MVME boards here so I am interested,
MVME2400/2600/2700 to be precise.
Right now I can test patches and not much more, I'm really
short of time and fighting other issues. Among them my PB
G4 from last December just completely failed (and Apple
told me to bring it to a shop in this city that is closed
for holidays until ... September 4th).
Regards,
Gabriel
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Gabriel Paubert @ 2006-08-16 10:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: 'Albert Cahalan', debian-powerpc, linuxppc-dev
In-Reply-To: <17633.18057.778991.483461@cargo.ozlabs.ibm.com>
On Tue, Aug 15, 2006 at 01:59:05PM +1000, Paul Mackerras wrote:
> Matt Sealey writes:
>
> > Book I compatible PowerPC's have had a "no-executable" bit in
> > the page protection flags since the dark ages.. see page 7-38
> > and 7-39 of the 'Programming Environments Manual for 32-Bit
> > Microprocessors'.. this document predates even the G3.
>
> What are you referring to? I have a copy of the PEM from pre-G3 days,
> and a copy that I downloaded just now, and neither of them have an N
> bit in the PTE (and yes I just looked carefully through pages 7-38 and
> 7-39).
>
> There is an N bit in the segment register format, and that's what
> Albert is using.
>
> > As far as the documentation goes, you can make the page
> > readable and writable to the LSU, but the N bit causes the
> > instruction fetch to cause a machine check. That's pretty
> > "not-executable" to me at least :)
>
> A machine check is nasty, because it may not be recoverable...
I agree, but I don't know why you believe it would cause
a machine check (0x200): from my docs, it is an ISI (0x400).
BTW, there is one way to make pages non executable: mark
them as guarded, but it will have a significant cost in
terms of performance.
I never understood why PTE entries waste 4 bits (WIMG)
for effectively very few valid combinations.
Regards,
Gabriel
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-16 11:07 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: 'Albert Cahalan', debian-powerpc, linuxppc-dev
In-Reply-To: <20060816105925.GB21865@iram.es>
Gabriel Paubert writes:
> I agree, but I don't know why you believe it would cause
> a machine check (0x200): from my docs, it is an ISI (0x400).
I don't believe it would cause a machine check either, but that is
what Matt Sealey was saying. I don't know where he got that idea.
> BTW, there is one way to make pages non executable: mark
> them as guarded, but it will have a significant cost in
> terms of performance.
Indeed. I guess we could do that as a config option for machines that
really want maximum security at the expense of performance, but I
don't think all users would want that.
Paul.
^ permalink raw reply
* Re: Who cares about PReP?
From: Paul Mackerras @ 2006-08-16 11:22 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20060816101527.GA21865@iram.es>
Gabriel Paubert writes:
> We are using 20+ MVME boards here so I am interested,
> MVME2400/2600/2700 to be precise.
If you (and anyone else who is interested) could send me the contents
of /proc/residual, /proc/iomem, /proc/ioports and /proc/interrupts
from your systems (one of each different type) that could be helpful.
Thanks,
Paul.
^ permalink raw reply
* Re: Who cares about PReP?
From: Paul Mackerras @ 2006-08-16 11:57 UTC (permalink / raw)
To: Gabriel Paubert, linuxppc-dev
In-Reply-To: <17634.65529.252720.646039@cargo.ozlabs.ibm.com>
I wrote:
> If you (and anyone else who is interested) could send me the contents
> of /proc/residual, /proc/iomem, /proc/ioports and /proc/interrupts
> from your systems (one of each different type) that could be helpful.
And /proc/cpuinfo would be interesting too.
Paul.
^ permalink raw reply
* [PATCH] Add a helper for calculating RTAS "config_addr" parameters
From: Michael Ellerman @ 2006-08-16 12:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Several RTAS calls take a "config_addr" parameter, which is a particular
way of specifying a PCI busno, devfn and register number into a 32-bit word.
Currently these are open-coded, and I'll be adding another soon, replace
them with a helper that encapsulates the logic. Be more strict about masking
the busno too, just in case.
Booted on P5 LPAR.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/rtas_pci.c | 6 ++----
include/asm-powerpc/rtas.h | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 4 deletions(-)
Index: git/arch/powerpc/kernel/rtas_pci.c
===================================================================
--- git.orig/arch/powerpc/kernel/rtas_pci.c
+++ git/arch/powerpc/kernel/rtas_pci.c
@@ -81,8 +81,7 @@ int rtas_read_config(struct pci_dn *pdn,
if (!config_access_valid(pdn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = ((where & 0xf00) << 20) | (pdn->busno << 16) |
- (pdn->devfn << 8) | (where & 0xff);
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, where);
buid = pdn->phb->buid;
if (buid) {
ret = rtas_call(ibm_read_pci_config, 4, 2, &returnval,
@@ -134,8 +133,7 @@ int rtas_write_config(struct pci_dn *pdn
if (!config_access_valid(pdn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = ((where & 0xf00) << 20) | (pdn->busno << 16) |
- (pdn->devfn << 8) | (where & 0xff);
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, where);
buid = pdn->phb->buid;
if (buid) {
ret = rtas_call(ibm_write_pci_config, 5, 1, NULL, addr,
Index: git/include/asm-powerpc/rtas.h
===================================================================
--- git.orig/include/asm-powerpc/rtas.h
+++ git/include/asm-powerpc/rtas.h
@@ -230,5 +230,21 @@ extern unsigned long rtas_rmo_buf;
#define GLOBAL_INTERRUPT_QUEUE 9005
+/**
+ * rtas_config_addr - Format a busno, devfn and reg for RTAS.
+ * @busno: The bus number.
+ * @devfn: The device and function number as encoded by PCI_DEVFN().
+ * @reg: The register number.
+ *
+ * This function encodes the given busno, devfn and register number as
+ * required for RTAS calls that take a "config_addr" parameter.
+ * See PAPR requirement 7.3.4-1 for more info.
+ */
+static inline u32 rtas_config_addr(int busno, int devfn, int reg)
+{
+ return ((reg & 0xf00) << 20) | ((busno & 0xff) << 16) |
+ (devfn << 8) | (reg & 0xff);
+}
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_RTAS_H */
^ permalink raw reply
* help
From: Hemanth KumarBS @ 2006-08-16 12:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Hi,
I am working on PPC-8248. Is montavista has driver for DMA based SPI
driver ?
Regards
Hemanth
[-- Attachment #2: Type: text/html, Size: 277 bytes --]
^ permalink raw reply
* Did someone have a working SPI Driver for Linux 2.6
From: Keinen Namen @ 2006-08-16 12:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Did someone have a working SPI Driver for Linux 2.6 and the MPC82xx from Freescale?
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Did someone have a working SPI Driver for Linux 2.6
From: Laurent Pinchart @ 2006-08-16 13:09 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Keinen Namen
In-Reply-To: <20060816125228.98000@gmx.net>
> Did someone have a working SPI Driver for Linux 2.6 and the MPC82xx from
> Freescale?
I'm working on such a driver. I will try to send a patch in a few days. The
driver is being tested on an MMC device, so basic functionalities should be
there, but things are far from being finished.
Laurent Pinchart
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Arnd Bergmann @ 2006-08-16 13:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20060816152032.2407a832.sfr@canb.auug.org.au>
On Wednesday 16 August 2006 07:20, Stephen Rothwell wrote:
> gcc 4.1 produces some warnings that it is ignoring the packed attribute
> on some structure elements, so just remove them.
>
Wouldn't it be nicer to just specify the packed attribute on the
structure instead of each of the members? My reading of the
gcc documentation is that this is functionally the same, but
it makes the source more readable, aside from avoiding this warning.
Arnd <><
^ permalink raw reply
* Re: *** PROBABLY SPAM *** No Clock on SPI
From: Laurent Pinchart @ 2006-08-16 13:22 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: GSM909
In-Reply-To: <20060815164521.230780@gmx.net>
Hi Fred,
> I=C2=B4m writing a Driver for SPI. That is not working now.
> I have a MPC8260 using Linux 2.6.14 (rheap patch).
>
> Did someone else write a driver for SPI on this =C2=B5C or an other drive=
r? So I
> can see what i did wrong?
I'm working on an SPI driver for the MPC8248. I'll try to send a patch in a=
=20
few days.
> My SPCOM[STR] flag isn=C2=B4t cleared automatically after one clock cycle.
> What here going wrong ? ( I know this register is write only)
> There is also no Clock on my SPICLK.
Make sure you programmed the SPMODE register correctly.
> How I have to allocate the Memory for the BD=C2=B4s and the buffer for th=
e BD=C2=B4s?
The buffer descriptors should be allocated from CPM DPRAM using cpm_dpalloc=
().=20
The buffers can be allocated from any DMA-able memory (all system memory).
> Is there something special when I allocate Memory for my Parameter Ram?
You don't need to allocate memory for the parameter RAM. I declared PROFF_S=
PI=20
equal to 192 (I2C parameter RAM is at 128) in include/asm-ppc/cpm2.h:
#define PROFF_SMC1 (0)
#define PROFF_SMC2 (64)
#define PROFF_I2C (128)
#define PROFF_SPI (192)
Don't forget to set CPM_DATAONLY_BASE to 256 instead of 128 in the same fil=
e.
Then, set
*(u16 *)(&immap->im_dprambase[PROFF_SPI_BASE]) =3D PROFF_SPI;
in your driver code, and set the SPI pram resource to
=2Ename =3D "pram",
=2Estart =3D 0x00c0,
=2Eend =3D 0x00ff,
=2Eflags =3D IORESOURCE_MEM,
in arch/ppc/syslib/pq2_devices.c
> Is something wrong with the 2.6 Kernel so i have to use the 2.4 Kernel ?
You should not use 2.4. 2.6 is the way to go.
Laurent Pinchart
^ permalink raw reply
* Re: Problems dynamically linking busybox with ppc libs.
From: Ben Warren @ 2006-08-16 14:13 UTC (permalink / raw)
To: Keith Redfern; +Cc: linuxppc-embedded
In-Reply-To: <367F3B3911959C4DA9991C00166F620C1DE208@EUDUCEX2.europe.ad.flextronics.com>
Keith,
On Wed, 2006-08-16 at 10:53 +0200, Keith Redfern wrote:
> I am trying to dynamically link busybox with the correct libraries but
> run into problems with directory paths and CC/LD flags.
>
> I am using the toolchain supplied with ELDK and my target board is
> ppc_8xx based. The busybox version that I am using is 1.1.3.
>
<snip>
>
> Is this the correct place to make modifications?
>
> Has anyone already figured the changes required to get this to work
> with ELDK toolchain?
>
> Any insight would be useful.
>
>
>
> ...…Keith
I have busybox 1.2 building under ELDK 4.0, and didn't mess at all with
the Make system, and am building for a ppc_6xx- target. I realize this
isn't quite your setup, but is pretty close.
As long as you have the tools listed in your PATH (in my
case /opt/tools/eldk4.0/usr/bin:/opt/tools/eldk4.0/bin), you should be
able to build fine using 'make menuconfig'. Just go to 'Busybox
Settings->Build Options' and select 'Do you want to build BusyBox with a
Cross Compiler?', in your case entering 'ppc_8xx-' or whatever the
prefix is for your CPU.
regards,
Ben
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Albert Cahalan @ 2006-08-16 14:43 UTC (permalink / raw)
To: Paul Mackerras; +Cc: debian-powerpc, linuxppc-dev
In-Reply-To: <17634.64640.709200.871907@cargo.ozlabs.ibm.com>
On 8/16/06, Paul Mackerras <paulus@samba.org> wrote:
> Gabriel Paubert writes:
> > BTW, there is one way to make pages non executable: mark
> > them as guarded, but it will have a significant cost in
> > terms of performance.
>
> Indeed. I guess we could do that as a config option for machines that
> really want maximum security at the expense of performance, but I
> don't think all users would want that.
On the other hand, if you want to squeeze some performance
out of the chip, turn off coherency. (probably not for SMP)
I've done it before, with a non-Linux OS. It does help.
Other tricks are to map userspace via BATs and, on the 7410
at least, to map half or all of the outermost cache memory as
a special block of high-speed memory.
^ permalink raw reply
* Re: 2.6.18-rc3->rc4 hugetlbfs regression
From: Adam Litke @ 2006-08-16 15:00 UTC (permalink / raw)
To: Dave Hansen
Cc: Suzuki Kp, PPC External List, Linux Kernel Mailing List, linux-mm,
Yao Fei Zhu, lge, Nishanth Aravamudan
In-Reply-To: <1155655344.12700.45.camel@localhost.localdomain>
On Tue, 2006-08-15 at 08:22 -0700, Dave Hansen wrote:
> kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
Alright, this one is only triggered when slab debugging is enabled. The slabs
are assumed to be aligned on a HUGEPTE_TABLE_SIZE boundary. The free path
makes use of this assumption and uses the lowest nibble to pass around an index
into an array of kmem_cache pointers. With slab debugging turned on, the slab
is still aligned, but the "working" object pointer is not. This would break
the assumption above that a full nibble is available for the PGF_CACHENUM_MASK.
The following patch reduces PGF_CACHENUM_MASK to cover only the two least
significant bits, which is enough to cover the current number of 4 pgtable
cache types. Then use this constant to mask out the appropriate part of the
huge pte pointer.
Signed-off-by: Adam Litke <agl@us.ibm.com>
---
arch/powerpc/mm/hugetlbpage.c | 2 +-
include/asm-powerpc/pgalloc.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -upN reference/arch/powerpc/mm/hugetlbpage.c current/arch/powerpc/mm/hugetlbpage.c
--- reference/arch/powerpc/mm/hugetlbpage.c
+++ current/arch/powerpc/mm/hugetlbpage.c
@@ -153,7 +153,7 @@ static void free_hugepte_range(struct mm
hpdp->pd = 0;
tlb->need_flush = 1;
pgtable_free_tlb(tlb, pgtable_free_cache(hugepte, HUGEPTE_CACHE_NUM,
- HUGEPTE_TABLE_SIZE-1));
+ PGF_CACHENUM_MASK));
}
#ifdef CONFIG_PPC_64K_PAGES
diff -upN reference/include/asm-powerpc/pgalloc.h current/include/asm-powerpc/pgalloc.h
--- reference/include/asm-powerpc/pgalloc.h
+++ current/include/asm-powerpc/pgalloc.h
@@ -117,7 +117,7 @@ static inline void pte_free(struct page
pte_free_kernel(page_address(ptepage));
}
-#define PGF_CACHENUM_MASK 0xf
+#define PGF_CACHENUM_MASK 0x3
typedef struct pgtable_free {
unsigned long val;
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-16 15:22 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <1155705695.12715.7.camel@localhost.localdomain>
In message <1155705695.12715.7.camel@localhost.localdomain> you wrote:
>
> --=-PNKyW5KJv4630LcmkXVt
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, 2006-08-15 at 23:00 -0500, Michael Neuling wrote:
> > The RTAS console doesn't have to be Cell specific. If we have both
> > the put and get char RTAS functions, init the rtas console.
> >=20
> > Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
> > +++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> > @@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
> > basep =3D of_get_flat_dt_prop(node, "get-term-char", NULL);
> > if (basep)
> > rtas_getchar_token =3D *basep;
> > +
> > + if (rtas_putchar_token !=3D RTAS_UNKNOWN_SERVICE &&
> > + rtas_getchar_token !=3D RTAS_UNKNOWN_SERVICE)
> > + udbg_init_rtas_console();
> > +
> > #endif
> > =20
> > /* break now */
> > Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
> > +++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> > @@ -150,10 +150,6 @@ static int __init cell_probe(void)
> > !of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
> > return 0;
> > =20
> > -#ifdef CONFIG_UDBG_RTAS_CONSOLE
> > - udbg_init_rtas_console();
> > -#endif
> > -
>
> I'd like to see it still guarded by UDBG_RTAS_CONSOLE, otherwise there's
> no way to select a different type of early console on a machine which
> has those tokens in the device tree.
Agreed but that section in rtas.c is already guarded by
UDBG_RTAS_CONSOLE. After applying the patch, it looks like:
#ifdef CONFIG_UDBG_RTAS_CONSOLE
basep = of_get_flat_dt_prop(node, "put-term-char", NULL);
if (basep)
rtas_putchar_token = *basep;
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
if (basep)
rtas_getchar_token = *basep;
if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
udbg_init_rtas_console();
#endif
Mikey
^ permalink raw reply
* Re: CPM2 UARTs: Won't work under low (<= 1200BD) baudrates?
From: Dan Malek @ 2006-08-16 15:42 UTC (permalink / raw)
To: David Tao; +Cc: linuxppc-embedded
In-Reply-To: <20060815195203.37918.qmail@web32106.mail.mud.yahoo.com>
On Aug 15, 2006, at 3:52 PM, David Tao wrote:
> Under 2400 baud or above the UARTs work fine, but once the baudrate
> set to 1200 or below, there is NO data can be sent out or received
> even programed to do so.
It doesn't look like we check the baud rate and
add the preceding divide-by-16 clock for the
low baud rates like we did on the original CPM.
You can add this, test it, and submit a patch if
you like :-)
Thanks.
-- Dan
^ permalink raw reply
* [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-16 16:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Add instrumentation for hypervisor calls on pseries. Call statistics
include number of calls, wall time and cpu cycles (if available) and
are made available via debugfs. Instrumentation code is behind the
HCALL_STATS config option and has no impact if not enabled.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc2/arch/powerpc/Kconfig.debug powerpc2.work/arch/powerpc/Kconfig.debug
--- powerpc2/arch/powerpc/Kconfig.debug 2006-08-14 18:00:45.000000000 +0000
+++ powerpc2.work/arch/powerpc/Kconfig.debug 2006-08-15 18:45:57.000000000 +0000
@@ -18,6 +18,20 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES && DEBUG_FS
+ help
+ Adds code to keep track of the number of hypervisor calls made and
+ the amount of time spent in hypervisor callsr. Wall time spent in
+ each call is always calculated, and if available CPU cycles spent
+ are also calculated. A directory named hcall_inst is added at the
+ root of the debugfs filesystem. Within the hcall_inst directory
+ are files that contain CPU specific call statistics.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr powerpc2/arch/powerpc/kernel/asm-offsets.c powerpc2.work/arch/powerpc/kernel/asm-offsets.c
--- powerpc2/arch/powerpc/kernel/asm-offsets.c 2006-08-14 18:00:46.000000000 +0000
+++ powerpc2.work/arch/powerpc/kernel/asm-offsets.c 2006-08-14 22:22:49.000000000 +0000
@@ -136,6 +136,7 @@ int main(void)
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
+ DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
DEFINE(LPPACASRR0, offsetof(struct lppaca, saved_srr0));
DEFINE(LPPACASRR1, offsetof(struct lppaca, saved_srr1));
@@ -160,6 +161,12 @@ int main(void)
/* Create extra stack space for SRR0 and SRR1 when calling prom/rtas. */
DEFINE(PROM_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
DEFINE(RTAS_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
+
+ /* hcall statistics */
+ DEFINE(HCALL_STAT_SIZE, sizeof(struct hcall_stats));
+ DEFINE(HCALL_STAT_CALLS, offsetof(struct hcall_stats, num_calls));
+ DEFINE(HCALL_STAT_TB, offsetof(struct hcall_stats, tb_total));
+ DEFINE(HCALL_STAT_PURR, offsetof(struct hcall_stats, purr_total));
#endif /* CONFIG_PPC64 */
DEFINE(GPR0, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[0]));
DEFINE(GPR1, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[1]));
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/Makefile powerpc2.work/arch/powerpc/platforms/pseries/Makefile
--- powerpc2/arch/powerpc/platforms/pseries/Makefile 2006-08-14 18:00:55.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/Makefile 2006-08-14 21:31:45.000000000 +0000
@@ -12,3 +12,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/hvCall.S powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc2/arch/powerpc/platforms/pseries/hvCall.S 2006-08-14 18:00:55.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S 2006-08-15 19:06:10.000000000 +0000
@@ -10,9 +10,67 @@
#include <asm/hvcall.h>
#include <asm/processor.h>
#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
#define STK_PARM(i) (48 + ((i)-3)*8)
+#ifdef CONFIG_HCALL_STATS
+/*
+ * precall must preserve all registers. use unused STK_PARM()
+ * areas to save snapshots and opcode.
+ */
+#define HCALL_INST_PRECALL \
+ std r3,STK_PARM(r3)(r1); /* save opcode */ \
+ mftb r3; /* get timebase and */ \
+ std r3,STK_PARM(r5)(r1); /* save for later */ \
+BEGIN_FTR_SECTION; \
+ mfspr r3,SPRN_PURR; /* get PURR and */ \
+ std r3,STK_PARM(r6)(r1); /* save for later */ \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ ld r3,STK_PARM(r3)(r1); /* opcode back in r3 */
+
+/*
+ * postcall is performed immediately before function return which
+ * allows liberal use of volital registers.
+ */
+#define HCALL_INST_POSTCALL \
+ /* get time and PURR snapshots after hcall */ \
+ mftb r7; /* timebase after */ \
+BEGIN_FTR_SECTION; \
+ mfspr r8,SPRN_PURR; /* PURR after */ \
+ ld r6,STK_PARM(r6)(r1); /* PURR before */ \
+ subf r6,r6,r8; /* delta */ \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ ld r5,STK_PARM(r5)(r1); /* timebase before */ \
+ subf r5,r5,r7; /* time delta */ \
+ \
+ /* calculate address of stat structure */ \
+ ld r4,STK_PARM(r3)(r1); /* use opcode as */ \
+ rldicl r4,r4,62,2; /* index into array */ \
+ mulli r4,r4,HCALL_STAT_SIZE; \
+ LOAD_REG_ADDR(r7, per_cpu__hcall_stats); \
+ add r4,r4,r7; \
+ ld r7,PACA_DATA_OFFSET(r13); /* per cpu offset */ \
+ add r4,r4,r7; \
+ \
+ /* update stats */ \
+ ld r7,HCALL_STAT_CALLS(r4); /* count */ \
+ addi r7,r7,1; \
+ std r7,HCALL_STAT_CALLS(r4); \
+ ld r7,HCALL_STAT_TB(r4); /* timebase */ \
+ add r7,r7,r5; \
+ std r7,HCALL_STAT_TB(r4); \
+BEGIN_FTR_SECTION; \
+ ld r7,HCALL_STAT_PURR(r4); /* PURR */ \
+ add r7,r7,r6; \
+ std r7,HCALL_STAT_PURR(r4); \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR);
+#else
+#define HCALL_INST_PRECALL
+#define HCALL_INST_POSTCALL
+#endif
+
.text
_GLOBAL(plpar_hcall_norets)
@@ -21,8 +79,12 @@ _GLOBAL(plpar_hcall_norets)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
HVSC /* invoke the hypervisor */
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
blr /* return r3 = status */
@@ -33,6 +95,8 @@ _GLOBAL(plpar_hcall)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -50,6 +114,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +127,8 @@ _GLOBAL(plpar_hcall9)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -86,6 +154,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc2.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc2/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-08-15 21:41:17.000000000 +0000
@@ -0,0 +1,129 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include <linux/kernel.h>
+#include <linux/percpu.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/cpumask.h>
+#include <asm/hvcall.h>
+#include <asm/firmware.h>
+#include <asm/cputable.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < (MAX_HCALL_OPCODES + 1))
+ return (void *)(unsigned long)(*pos + 1);
+
+ return NULL;
+}
+
+static void *hc_next(struct seq_file *m, void *p, loff_t * pos)
+{
+ ++*pos;
+
+ return hc_start(m, pos);
+}
+
+static void hc_stop(struct seq_file *m, void *p)
+{
+}
+
+static int hc_show(struct seq_file *m, void *p)
+{
+ unsigned long h_num = (unsigned long)p;
+ struct hcall_stats *hs = (struct hcall_stats *)m->private;
+
+ if (hs[h_num].num_calls) {
+ if (cpu_has_feature(CPU_FTR_PURR))
+ seq_printf(m, "%lu %lu %lu %lu\n", h_num<<2,
+ hs[h_num].num_calls,
+ hs[h_num].tb_total,
+ hs[h_num].purr_total);
+ else
+ seq_printf(m, "%lu %lu %lu\n", h_num<<2,
+ hs[h_num].num_calls,
+ hs[h_num].tb_total);
+ }
+
+ return 0;
+}
+
+static struct seq_operations hcall_inst_seq_ops = {
+ .start = hc_start,
+ .next = hc_next,
+ .stop = hc_stop,
+ .show = hc_show
+};
+
+static int hcall_inst_seq_open(struct inode *inode, struct file *file)
+{
+ int rc;
+ struct seq_file *seq;
+
+ rc = seq_open(file, &hcall_inst_seq_ops);
+ seq = file->private_data;
+ seq->private = file->f_dentry->d_inode->u.generic_ip;
+
+ return rc;
+}
+
+static struct file_operations hcall_inst_seq_fops = {
+ .open = hcall_inst_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+#define HCALL_ROOT_DIR "hcall_inst"
+#define CPU_NAME_BUF_SIZE 32
+
+static int __init hcall_inst_init(void)
+{
+ struct dentry *hcall_root;
+ struct dentry *hcall_file;
+ char cpu_name_buf[CPU_NAME_BUF_SIZE];
+ int cpu;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return 0;
+
+ hcall_root = debugfs_create_dir(HCALL_ROOT_DIR, NULL);
+ if (!hcall_root)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu) {
+ snprintf(cpu_name_buf, CPU_NAME_BUF_SIZE, "cpu%d", cpu);
+ hcall_file = debugfs_create_file(cpu_name_buf, S_IRUGO,
+ hcall_root,
+ per_cpu(hcall_stats, cpu),
+ &hcall_inst_seq_fops);
+ if (!hcall_file)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+__initcall(hcall_inst_init);
diff -Naupr powerpc2/include/asm-powerpc/hvcall.h powerpc2.work/include/asm-powerpc/hvcall.h
--- powerpc2/include/asm-powerpc/hvcall.h 2006-08-14 18:05:16.000000000 +0000
+++ powerpc2.work/include/asm-powerpc/hvcall.h 2006-08-14 21:31:45.000000000 +0000
@@ -246,6 +246,15 @@ long plpar_hcall(unsigned long opcode, u
#define PLPAR_HCALL9_BUFSIZE 9
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
+/* For hcall instrumentation. One structure per-hcall, per-CPU */
+struct hcall_stats {
+ unsigned long num_calls; /* number of calls (on this CPU) */
+ unsigned long tb_total; /* total wall time (mftb) of calls. */
+ unsigned long purr_total; /* total cpu time (PURR) of calls. */
+};
+void update_hcall_stats(unsigned long opcode, unsigned long tb_delta,
+ unsigned long purr_delta);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* [PATCH 1/2]: powerpc/cell spidernet bottom half
From: Linas Vepstas @ 2006-08-16 16:18 UTC (permalink / raw)
To: netdev, linux-kernel, linuxppc-dev
Cc: akpm, Jens Osterkamp, James K Lewis, jeff, Arnd Bergmann
In-Reply-To: <20060811170337.GH10638@austin.ibm.com>
Please apply and forward upstream. This patch requires the previous
sequence of 4 spidernet patches to be applied.
--linas
The recent set of low-waterark patches for the spider result in a
significant amount of computing being done in an interrupt context.
This patch moves this to a "bottom half" aka work queue, so that
the code runs in a normal kernel context. Curiously, this seems to
result in a performance boost of about 5% for large packets.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Utz Bacher <utz.bacher@de.ibm.com>
Cc: Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
----
drivers/net/spider_net.c | 21 +++++++++++++++------
drivers/net/spider_net.h | 4 +++-
2 files changed, 18 insertions(+), 7 deletions(-)
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.c 2006-08-15 14:25:50.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.c 2006-08-15 14:28:56.000000000 -0500
@@ -883,9 +883,10 @@ out:
* spider_net_cleanup_tx_ring - cleans up the TX ring
* @card: card structure
*
- * spider_net_cleanup_tx_ring is called by the tx_timer (as we don't use
- * interrupts to cleanup our TX ring) and returns sent packets to the stack
- * by freeing them
+ * spider_net_cleanup_tx_ring is called by either the tx_timer
+ * or from a work-queue scheduled by the tx-empty interrupt.
+ * This routine releases resources associted with transmitted
+ * packets, including updating the queue tail pointer.
*/
static void
spider_net_cleanup_tx_ring(struct spider_net_card *card)
@@ -895,12 +896,20 @@ spider_net_cleanup_tx_ring(struct spider
spin_lock_irqsave(&card->tx_chain.lock, flags);
if ((spider_net_release_tx_chain(card, 0) != 0) &&
- (card->netdev->flags & IFF_UP))
+ (card->netdev->flags & IFF_UP)) {
spider_net_kick_tx_dma(card);
+ netif_wake_queue(card->netdev);
+ }
spin_unlock_irqrestore(&card->tx_chain.lock, flags);
}
+static void
+spider_net_tx_cleanup_task(void * data)
+{
+ spider_net_cleanup_tx_ring((struct spider_net_card *) data);
+}
+
/**
* spider_net_do_ioctl - called for device ioctls
* @netdev: interface device structure
@@ -1499,8 +1508,7 @@ spider_net_interrupt(int irq, void *ptr,
netif_rx_schedule(netdev);
}
if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
+ schedule_work(&card->tx_cleanup_task);
}
if (status_reg & SPIDER_NET_ERRINT )
@@ -2117,6 +2125,7 @@ spider_net_alloc_card(void)
card->netdev = netdev;
card->msg_enable = SPIDER_NET_DEFAULT_MSG;
INIT_WORK(&card->tx_timeout_task, spider_net_tx_timeout_task, netdev);
+ INIT_WORK(&card->tx_cleanup_task, spider_net_tx_cleanup_task, card);
init_waitqueue_head(&card->waitq);
atomic_set(&card->tx_timeout_task_counter, 0);
Index: linux-2.6.18-rc3-mm2/drivers/net/spider_net.h
===================================================================
--- linux-2.6.18-rc3-mm2.orig/drivers/net/spider_net.h 2006-08-15 14:25:50.000000000 -0500
+++ linux-2.6.18-rc3-mm2/drivers/net/spider_net.h 2006-08-15 14:28:56.000000000 -0500
@@ -24,7 +24,7 @@
#ifndef _SPIDER_NET_H
#define _SPIDER_NET_H
-#define VERSION "1.1 A"
+#define VERSION "1.1 B"
#include "sungem_phy.h"
@@ -441,6 +441,8 @@ struct spider_net_card {
atomic_t tx_timeout_task_counter;
wait_queue_head_t waitq;
+ struct work_struct tx_cleanup_task;
+
/* for ethtool */
int msg_enable;
^ 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