* Re: AltiVec in the kernel
From: Linas Vepstas @ 2006-07-20 17:42 UTC (permalink / raw)
To: Matt Sealey; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <001301c6abf8$73d780e0$99dfdfdf@bakuhatsu.net>
On Thu, Jul 20, 2006 at 07:31:32AM -0500, Matt Sealey wrote:
>
> What's the case in the kernel for the memcpy functions etc., are
> they optimized for doing things like longword copies rather than
> byte-per-byte etc.?
arch/powerpc/lib/copy_32.S
arch/powerpc/lib/memcpy_64.S
Looks pretty darned optimized to me.
> We found glibc sucked for that.
Only because someone was asleep at the wheel, or there was a bug.
When glibc gets ported to a new architecture, one of the earliest
tasks is to create optimized versions of memcpy and the like.
Presumably, on powerpc, this would have been done more than a
decade ago; its hard for me to imagine that there'd be a problem
there. Now, I haven't looked at the code, but I just can't imagine
how this would not have been found and fixed by now. Is there
really a problem wiht glibc performance on powerpc? I mean,
this is a pretty serious accusation, and something that should
be fixed asap.
--linas
^ permalink raw reply
* PHY Howto ?
From: David H. Lynch Jr. @ 2006-07-20 17:52 UTC (permalink / raw)
To: linuxppc-embedded
If I am writing a network MAC driver, for hardware that has a phy
that is already supported, if I provide the appropriate mdio_read() and
mdio_write() calls to access the phy registers, and setup my config to
include phylib and drivers for my specific phy, what else do I have to
take care of with respect to the phy within my driver ?
Are there some resources, howto's, examples, ... demonstrating
how to use phylib ?
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: PHY Howto ?
From: Vitaly Bordug @ 2006-07-20 18:01 UTC (permalink / raw)
To: dhlii; +Cc: linuxppc-embedded
In-Reply-To: <44BFC2EF.5020305@dlasys.net>
On Thu, 20 Jul 2006 13:52:47 -0400
"David H. Lynch Jr." <dhlii@dlasys.net> wrote:
> If I am writing a network MAC driver, for hardware that has a phy
> that is already supported, if I provide the appropriate mdio_read() and
> mdio_write() calls to access the phy registers, and setup my config to
> include phylib and drivers for my specific phy, what else do I have to
> take care of with respect to the phy within my driver ?
>
> Are there some resources, howto's, examples, ... demonstrating
> how to use phylib ?
There is pretty good writeup in Documentation about your concern, find it at
Documentation/networking/phy.txt . Live example is obviously drivers/net/gianfar*
--
Sincerely,
Vitaly
^ permalink raw reply
* Problem with ibm_emac driver
From: Ian Remmler @ 2006-07-20 18:32 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I'm having a problem with the ibm_emac driver for the built in
gigabit ethernet on the 440gx. I was hoping someone could shed
some light or at least point me in the right direction.
I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
problem we are having is this: when we push data over the emac
interface (eth0 and eth1 both show the problem), we sporadically
get a "MAL: Rx descriptor error..." from mal_rxde in
ibm_ocp_mal.c.
Occasionally, the interface will "freeze up" for a few seconds.
An ifconfig down/up will bring it back, but from then on it will
freeze up again right away.
It looks to me like this error indicates that we're out of RX
buffers, but I don't how we would be running out. I'm no kernel
or networking expert, but I thought the TCP stack would take
care of throttling itself to prevent that sort of thing. I
would appreciate any help.
Thanks,
- Ian.
--
"A shark on whiskey is mighty risky.
A shark on beer is a beer engineer."
-- Dr. Worm
^ permalink raw reply
* Re: page locking in PowerPC cores
From: Benjamin Herrenschmidt @ 2006-07-20 18:50 UTC (permalink / raw)
To: Parav Pandit; +Cc: linuxppc-embedded
In-Reply-To: <20060719044510.24117.qmail@web36604.mail.mud.yahoo.com>
Only memory mapped into userland contexts can be paged out in the first
place.
Ben.
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 18:51 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153408592.19682.39.camel@saruman.qstreams.net>
On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
> Hello,
>
> Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> under the /sysfs device model? I have some optical transponders on my
> board that through the wisdom of some committee all have the same
> fixed
> I2C address. To get around this, we put them behind muxes, creating
> 'virtual' I2C busses. I imagine this could be modeled something like
> the USB hub model, but that's just a first stab.
I'm pretty sure I submitted a set of patches for this upstream.
However there was some desire to hold off until some other changes.
http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
- kumar
^ permalink raw reply
* Re: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 18:47 UTC (permalink / raw)
To: Linas Vepstas; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720174255.GP5905@austin.ibm.com>
At Thu, 20 Jul 2006 12:42:55 -0500,
Linas Vepstas wrote:
> > We found glibc sucked for that.
>
> Only because someone was asleep at the wheel, or there was a bug.
>
> When glibc gets ported to a new architecture, one of the earliest
> tasks is to create optimized versions of memcpy and the like.
> Presumably, on powerpc, this would have been done more than a
> decade ago; its hard for me to imagine that there'd be a problem
> there. Now, I haven't looked at the code, but I just can't imagine
> how this would not have been found and fixed by now. Is there
> really a problem wiht glibc performance on powerpc? I mean,
> this is a pretty serious accusation, and something that should
> be fixed asap.
In the course of my work, I use powerpc architecture simulators. When
working on Mac OS X with a G5, I had to implement some of the basic
AltiVec specifically for use by their libc memcpy implementation. A
quick grep memcpy in the recent glibc sources on my linux/ppc box seems
to show no where near that level of optimization, but I admit that I
could have missed something. However, I would not be surprised that
glibc avoided AltiVec specific optimizations since it would add to the
complexity of supporting various architectures with one binary. On Mac
OS X, libc actually delegated a small number of libc calls such as
memcpy via a kernel managed page at the end of the address space that
setup which routines to use based on currently running architecture.
-bri
^ permalink raw reply
* Re: I2C with bus muxes
From: Ben Warren @ 2006-07-20 19:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: Linuxppc-embedded
In-Reply-To: <61F75343-B9B9-4349-A463-E39C7532A378@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 931 bytes --]
Way cool! Thanks a lot. I'll try it out when my hardware comes in...
regards,
Ben
On Thu, 2006-07-20 at 13:51 -0500, Kumar Gala wrote:
> On Jul 20, 2006, at 10:16 AM, Ben Warren wrote:
>
> > Hello,
> >
> > Has anyone implemented devices like the Philips PCA954x I2C bus muxes
> > under the /sysfs device model? I have some optical transponders on my
> > board that through the wisdom of some committee all have the same
> > fixed
> > I2C address. To get around this, we put them behind muxes, creating
> > 'virtual' I2C busses. I imagine this could be modeled something like
> > the USB hub model, but that's just a first stab.
>
> I'm pretty sure I submitted a set of patches for this upstream.
> However there was some desire to hold off until some other changes.
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=114376108231285&w=2
> http://marc.theaimsgroup.com/?t=114316214100001&r=1&w=2
>
> - kumar
>
>
[-- Attachment #2: Type: text/html, Size: 1826 bytes --]
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-20 19:05 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <le8xmoktav.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> A quick grep memcpy in the recent glibc sources on my linux/ppc box
> seems to show no where near that level of optimization, but I admit
> that I could have missed something.
http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
-Olof
^ permalink raw reply
* Re: I2C with bus muxes
From: Kumar Gala @ 2006-07-20 19:18 UTC (permalink / raw)
To: bwarren; +Cc: Linuxppc-embedded
In-Reply-To: <1153422097.19682.84.camel@saruman.qstreams.net>
On Jul 20, 2006, at 2:01 PM, Ben Warren wrote:
> Way cool! Thanks a lot. I'll try it out when my hardware comes in...
Cool, I no longer have access the the system that used the mux, so
when I rework the driver can I get you to test it?
- k
^ permalink raw reply
* Re: Problem with ibm_emac driver
From: Eugene Surovegin @ 2006-07-20 19:56 UTC (permalink / raw)
To: Ian Remmler; +Cc: linuxppc-embedded
In-Reply-To: <20060720183242.GA22930@localhost>
On Thu, Jul 20, 2006 at 01:32:42PM -0500, Ian Remmler wrote:
> Hi,
>
> I'm having a problem with the ibm_emac driver for the built in
> gigabit ethernet on the 440gx. I was hoping someone could shed
> some light or at least point me in the right direction.
>
> I'm using a GMS P502 board runing 2.4.27-pre3 (from GMS). The
> problem we are having is this: when we push data over the emac
> interface (eth0 and eth1 both show the problem), we sporadically
> get a "MAL: Rx descriptor error..." from mal_rxde in
> ibm_ocp_mal.c.
>
> Occasionally, the interface will "freeze up" for a few seconds.
> An ifconfig down/up will bring it back, but from then on it will
> freeze up again right away.
>
> It looks to me like this error indicates that we're out of RX
> buffers, but I don't how we would be running out. I'm no kernel
> or networking expert, but I thought the TCP stack would take
> care of throttling itself to prevent that sort of thing. I
> would appreciate any help.
No idea what GMS is, but they seem to use old buggy EMAC driver.
You can use kernel.org's 2.6 or 2.4.31 backport at
http://kernel.ebshome.net/
As a side note, TCP cannot throttle _all_ Rx traffic, think for
example of a fast box sending a lot of small UDP packets to the 440gx.
--
Eugene
^ permalink raw reply
* mainly iSeries updates
From: Stephen Rothwell @ 2006-07-20 21:25 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]
Hi Paul,
Please pull ozlabs.org:~sfr/kernels/sfr.git to get the following:
Michael Ellerman:
[POWERPC] iseries: Use device tree /system-id in /proc/iSeries/config
[POWERPC] iseries: Move e2a()/strne2a() into their only caller
[POWERPC] iseries: Cleanup e2a() and strne2a()
[POWERPC] iseries: Make ItExtVpdPanel private to iSeries
[POWERPC] iseries: Make HvLpConfig_get(Primary)LpIndex functions
[POWERPC] iseries: Move ItLpNaca into platforms/iseries
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] iseries: Fix a compiler warning in platforms/iseries/vpdinfo.c
[POWERPC] Fix a compiler warning in mm/tlb_64.c
[POWERPC] iseries: Move iommu_table_cb into platforms/iseries
Stephen Rothwell:
[POWERPC] iseries: A new iSeries console
[POWERPC] Make the hvc_console output buffer size settable
[POWERPC] iseries: Small viotape cleanup allowed by devfs removal
[POWERPC] iseries: Remove unnecessary include of iseries/hv_lp_event.h
--
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: AltiVec in the kernel
From: Brian D. Carlstrom @ 2006-07-20 21:56 UTC (permalink / raw)
To: Olof Johansson; +Cc: 'Paul Mackerras', 'linuxppc-dev list'
In-Reply-To: <20060720190523.GA27775@pb15.lixom.net>
At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > seems to show no where near that level of optimization, but I admit
> > that I could have missed something.
>
> http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
Very interesting. According to that page, the memcpy optimizations seem
to be using 64-bit operations and that 128-bit AltiVec operations are
still being solicited.
I was encouraged to see the following:
If you need to build generic distributions (supporting several
<cpu_types>) you can leverage the dl_procinfo support built into
glibc. This mechanism allows for multiple versions of the core
libraries (libc, libm, librt, libpthread, libpthread_db) to be
stored in hardware/platform specific subdirectories under /lib[64].
However, I'm guessing this addon is not something found in common
distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
-bri
^ permalink raw reply
* Re: AltiVec in the kernel
From: Daniel Ostrow @ 2006-07-20 22:39 UTC (permalink / raw)
To: Brian D. Carlstrom
Cc: Olof Johansson, 'linuxppc-dev list',
'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, 2006-07-20 at 14:56 -0700, Brian D. Carlstrom wrote:
> At Thu, 20 Jul 2006 14:05:23 -0500, Olof Johansson wrote:
> > On Thu, Jul 20, 2006 at 11:47:04AM -0700, Brian D. Carlstrom wrote:
> > > A quick grep memcpy in the recent glibc sources on my linux/ppc box
> > > seems to show no where near that level of optimization, but I admit
> > > that I could have missed something.
> >
> > http://penguinppc.org/dev/glibc/glibc-powerpc-cpu-addon.html
>
> Very interesting. According to that page, the memcpy optimizations seem
> to be using 64-bit operations and that 128-bit AltiVec operations are
> still being solicited.
>
> I was encouraged to see the following:
>
> If you need to build generic distributions (supporting several
> <cpu_types>) you can leverage the dl_procinfo support built into
> glibc. This mechanism allows for multiple versions of the core
> libraries (libc, libm, librt, libpthread, libpthread_db) to be
> stored in hardware/platform specific subdirectories under /lib[64].
>
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
It has been part of Gentoo's glibc since 2.4 came out.
--Dan
^ permalink raw reply
* mpic discovery on JS20
From: Amos Waterland @ 2006-07-20 23:16 UTC (permalink / raw)
To: linuxppc-dev
Current Linus and Paulus trees do this on JS20 blades with SLOF:
Failed to locate the MPIC interrupt controller
PID hash table entries: 4096 (order: 12, 32768 bytes)
Maple: Found RTC at IO 0x1070
cpu 0x0: Vector: 700 (Program Check) at [c00000007ef83ab0]
pc: c00000000002e0c8: .mpic_request_ipis+0x34/0xc8
lr: c00000000036b484: .smp_mpic_probe+0x3c/0x58
sp: c00000007ef83d30
msr: 9000000000029032
current = 0xc00000000194d610
paca = 0xc00000000038f180
pid = 1, comm = swapper
kernel BUG in mpic_request_ipis at arch/powerpc/sysdev/mpic.c:1132!
Doing a git-bisect produces this:
0ebfff1491ef85d41ddf9c633834838be144f69f is first bad commit
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Mon Jul 3 21:36:01 2006 +1000
[POWERPC] Add new interrupt mapping core and change platforms to use it
This adds the new irq remapper core and removes the old one. Because
there are some fundamental conflicts with the old code, like the value
of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
etc..., this commit also changes the relevant platform and driver code
over to use the new remapper (so as not to cause difficulties later
in bisecting).
This patch removes the old pre-parsing of the open firmware interrupt
tree along with all the bogus assumptions it made to try to renumber
interrupts according to the platform. This is all to be handled by the
new code now.
For the pSeries XICS interrupt controller, a single remapper host is
created for the whole machine regardless of how many interrupt
presentation and source controllers are found, and it's set to match
any device node that isn't a 8259. That works fine on pSeries and
avoids having to deal with some of the complexities of split source
controllers vs. presentation controllers in the pSeries device trees.
The powerpc i8259 PIC driver now always requests the legacy interrupt
range. It also has the feature of being able to match any device node
(including NULL) if passed no device node as an input. That will help
porting over platforms with broken device-trees like Pegasos who don't
have a proper interrupt tree.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* RE: [Linux-ATM-General] mpc8360sar
From: Li Tony-r64360 @ 2006-07-21 2:36 UTC (permalink / raw)
To: Alex Zeffertt, Kumar Gala, Chu hanjin-r52514
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
In-Reply-To: <44BFABFD.1070904@cambridgebroadband.com>
Alex, we are working on the 8360 upstream. As the similarity between
832x and 8360, if the 8360 has benn accepted, it would be easy for 832x
upstream.
We have submit the 8360 patch to the opensource. But we are waiting it
to be accepted.
BTW, the new version QOC3-ATM card will adopt. The QOC3-ATM card code
need some modification.=20
I send the new code to you if it done. Ok ?
Tony
> -----Original Message-----
> From: Alex Zeffertt [mailto:ajz@cambridgebroadband.com]=20
> Sent: Friday, July 21, 2006 12:15 AM
> To: Kumar Gala
> Cc: Li Tony-r64360; linux-atm-general@lists.sourceforge.net;=20
> linuxppc-embedded@ozlabs.org
> Subject: Re: [Linux-ATM-General] mpc8360sar
>=20
> Kumar Gala wrote:
> >=20
> > On Jul 20, 2006, at 8:33 AM, Alex Zeffertt wrote:
> >=20
> >>
> >>> Any reason we dont try to get your work up stream into=20
> the mainline=20
> >>> kernel?
> >>> - kumar
> >>
> >> I'd like to see it upstreamed - the more people who use it=20
> the more=20
> >> help I get!
> >>
> >> However, mpc8360sar is built on Freescale's BSP which adds basic=20
> >> support for the board, the MPC832xE-MDS, to the stock=20
> linux kernel. =20
> >> This support consists of the following patches:
> >>
> >> Patch0 : patch-2.6.11.bz2
> >> Patch1 : linux-2.6.11-mpc8349e-general-20060414.patch
> >> Patch2 : linux-2.6.11-mpc8349e-pci-3.patch
> >> Patch3 : linux-2.6.11-mpc8349e-pci-agent.patch
> >> Patch4 : linux-2.6.11-mpc8349e-watchdog.patch
> >> Patch5 : linux-2.6.11-mpc83xx-sec2.patch
> >> Patch6 : mpc832x-sec2v15-config-1.patch
> >> Patch7 : linux-2.6.11-mpc8349e-usb-gadget.patch
> >> Patch8 : linux-2.6.11-mpc8349e-usb-host.patch
> >> Patch9 : linux-2.6.11-mpc8360-general-1.patch
> >> Patch10 : linux-2.6.11-mpc8360-pci-agent.patch
> >> Patch11 : linux-2.6.11-mpc832x-basic-4.patch
> >> Patch12 : linux-2.6.11-mpc832x-pci-agent.patch
> >> Patch13 : linux-2.6.11-mpc832x-spi-1.patch
> >> Patch14 : linux-2.6.11-mpc832x-BIT.patch
> >> Patch15 : linux-2.6.11-mpc83xx-ct-1.patch
> >> Patch16 : linux-2.6.11-mpc832x-usb-gadget.patch
> >> Patch17 : linux-2.6.11-mpc832x-atm-1.patch
> >>
> >> I guess there's no point upstreaming mpc8360sar until=20
> freescale have=20
> >> upstreamed these patches (and ported them to the current kernel).
> >=20
> > True, a large number of these patches are upstream, and if I had=20
> > access to MPC836x or MPC832x HW I'd work on getting the others that=20
> > are reasonable.
> >=20
> >> Alex
> >>
> >> PS It's probable that mpc8360sar actually only requires a=20
> handful of=20
> >> the above patches to be applied.
> >=20
> > Agreed.
> >=20
> > - kumar
>=20
>=20
> Tony, can you let me know when CONFIG_MPC832XE_MDS support is=20
> upstreamed to a kernel.org kernel. I'll then try to get the=20
> mpc8360sar working with this kernel and then upstream it.
>=20
> Alex
>=20
> PS I'm not entirely sure how "upstreaming" is done.
>=20
^ permalink raw reply
* Regarding MAL
From: Sangameshwar Pujari @ 2006-07-21 3:54 UTC (permalink / raw)
Cc: linuxppc-dev, linux-atm-general, linuxppc-embedded
Hi,
i am porting a EMAC driver from NetBSD to my Xilinix ML403 embeddded =
board . NETBSD code is Having a Media Access Layer (MAL) , which i want =
to know bit , is it the same MAC layer .
regards
sangamesh
^ permalink raw reply
* Re: AltiVec in the kernel
From: Olof Johansson @ 2006-07-21 6:35 UTC (permalink / raw)
To: Brian D. Carlstrom; +Cc: 'linuxppc-dev list', 'Paul Mackerras'
In-Reply-To: <lezmf4j5ym.wl%bdc@carlstrom.com>
On Thu, Jul 20, 2006 at 02:56:33PM -0700, Brian D. Carlstrom wrote:
> However, I'm guessing this addon is not something found in common
> distributions for PowerPC like Debian, Fedora, Gentoo, Ubuntu, ...
There's always lead time to get things into distros, that would still be
true if you modified glibc instead as well.
-Olof
^ permalink raw reply
* [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr linux-2.6.17-rc6/arch/powerpc/Kconfig.debug linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug
--- linux-2.6.17-rc6/arch/powerpc/Kconfig.debug 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/Kconfig.debug 2006-06-13 21:39:24.000000000 +0000
@@ -18,6 +18,16 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES
+ help
+ Adds code to keep track of number of hypervisor calls made and
+ the amount of time spent in hypervisor calls.
+
+ 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 linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/Makefile 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/Makefile 2006-06-13 21:39:24.000000000 +0000
@@ -9,3 +9,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 linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall.S 2006-06-06 00:57:02.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall.S 2006-06-13 21:39:24.000000000 +0000
@@ -25,7 +25,11 @@
unsigned long *out2, R9
unsigned long *out3); R10
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_base)
+#else
_GLOBAL(plpar_hcall)
+#endif
HMT_MEDIUM
mfcr r0
@@ -52,7 +56,15 @@ _GLOBAL(plpar_hcall)
/* Simple interface with no output values (other than status) */
+#ifdef CONFIG_HCALL_STATS
_GLOBAL(plpar_hcall_norets)
+ b plpar_hcall_norets_C
+
+
+_GLOBAL(plpar_hcall_norets_base)
+#else
+_GLOBAL(plpar_hcall_norets)
+#endif
HMT_MEDIUM
mfcr r0
@@ -76,7 +88,11 @@ _GLOBAL(plpar_hcall_norets)
unsigned long arg8, 112(R1)
unsigned long *out1); 120(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_8arg_2ret_base)
+#else
_GLOBAL(plpar_hcall_8arg_2ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -102,7 +118,11 @@ _GLOBAL(plpar_hcall_8arg_2ret)
unsigned long *out3, R10
unsigned long *out4); 112(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_4out_base)
+#else
_GLOBAL(plpar_hcall_4out)
+#endif
HMT_MEDIUM
mfcr r0
@@ -144,7 +164,11 @@ _GLOBAL(plpar_hcall_4out)
unsigned long *out6, 102(R1)
unsigned long *out7); 100(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_7arg_7ret_base)
+#else
_GLOBAL(plpar_hcall_7arg_7ret)
+#endif
HMT_MEDIUM
mfcr r0
@@ -193,7 +217,11 @@ _GLOBAL(plpar_hcall_7arg_7ret)
unsigned long *out8, 94(R1)
unsigned long *out9, 92(R1)
*/
+#ifdef CONFIG_HCALL_STATS
+_GLOBAL(plpar_hcall_9arg_9ret_base)
+#else
_GLOBAL(plpar_hcall_9arg_9ret)
+#endif
HMT_MEDIUM
mfcr r0
diff -Naupr linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- linux-2.6.17-rc6/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.17-rc6.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-06-13 21:39:24.000000000 +0000
@@ -0,0 +1,239 @@
+/*
+ * 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 <asm/hvcall.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+static inline void update_stats(unsigned long opcode, unsigned long t_before)
+{
+ unsigned long op_index= opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ /* racey, but acceptable for non-critical stats */
+ hs->total_time += (mfspr(SPRN_PURR) - t_before);
+ hs->num_calls++;
+}
+
+extern long plpar_hcall_base (unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3);
+
+long plpar_hcall(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_base(opcode, arg1, arg2, arg3, arg4, out1, out2, out3);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_norets_base(unsigned long opcode, ...);
+
+long plpar_hcall_norets_C(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_norets_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_8arg_2ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1);
+
+long plpar_hcall_8arg_2ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long *out1)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_8arg_2ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, out1);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_4out_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4);
+
+long plpar_hcall_4out(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_4out_base(opcode, arg1, arg2, arg3, arg4, out1,
+ out2, out3, out4);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_7arg_7ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7);
+
+long plpar_hcall_7arg_7ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_7arg_7ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, out1, out2, out3, out4,
+ out5, out6, out7);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
+
+extern long plpar_hcall_9arg_9ret_base(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9);
+
+long plpar_hcall_9arg_9ret(unsigned long opcode,
+ unsigned long arg1,
+ unsigned long arg2,
+ unsigned long arg3,
+ unsigned long arg4,
+ unsigned long arg5,
+ unsigned long arg6,
+ unsigned long arg7,
+ unsigned long arg8,
+ unsigned long arg9,
+ unsigned long *out1,
+ unsigned long *out2,
+ unsigned long *out3,
+ unsigned long *out4,
+ unsigned long *out5,
+ unsigned long *out6,
+ unsigned long *out7,
+ unsigned long *out8,
+ unsigned long *out9)
+{
+ long rc;
+ unsigned long t_before = mfspr(SPRN_PURR);
+
+ rc = plpar_hcall_9arg_9ret_base(opcode, arg1, arg2, arg3, arg4, arg5,
+ arg6, arg7, arg8, arg9, out1, out2,
+ out3, out4, out5, out6, out7, out8,
+ out9);
+
+ update_stats(opcode, t_before);
+ return rc;
+}
diff -Naupr linux-2.6.17-rc6/include/asm-powerpc/hvcall.h linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h
--- linux-2.6.17-rc6/include/asm-powerpc/hvcall.h 2006-06-13 21:38:45.000000000 +0000
+++ linux-2.6.17-rc6.work/include/asm-powerpc/hvcall.h 2006-06-13 21:39:24.000000000 +0000
@@ -292,6 +292,13 @@ long plpar_hcall_9arg_9ret(unsigned long
unsigned long *out8,
unsigned long *out9);
+#ifdef CONFIG_HCALL_STATS
+struct hcall_stats {
+ unsigned long num_calls;
+ unsigned long total_time;
+};
+#endif /* CONFIG_HCALL_STATS */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: Instrument Hypervisor Calls: add instrumentation
From: Mike Kravetz @ 2006-07-21 6:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721064153.GC8639@monkey.ibm.com>
On Thu, Jul 20, 2006 at 11:41:53PM -0700, Mike Kravetz wrote:
> Gather snapshots in the hcall routines and make callout to update data.
Wrong patch!!!! Sorry! Here is the correct one.
Gather snapshots in the hcall routines and make callout to update data.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/Kconfig.debug powerpc.work/arch/powerpc/Kconfig.debug
--- powerpc/arch/powerpc/Kconfig.debug 2006-07-19 18:45:58.000000000 +0000
+++ powerpc.work/arch/powerpc/Kconfig.debug 2006-07-21 07:06:49.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 calls: both wall time (based
+ on time base) and cpu time (based on PURR). 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 powerpc/arch/powerpc/platforms/pseries/Makefile powerpc.work/arch/powerpc/platforms/pseries/Makefile
--- powerpc/arch/powerpc/platforms/pseries/Makefile 2006-07-19 18:46:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/Makefile 2006-07-21 07:06:49.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 powerpc/arch/powerpc/platforms/pseries/hvCall.S powerpc.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc/arch/powerpc/platforms/pseries/hvCall.S 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall.S 2006-07-21 07:06:49.000000000 +0000
@@ -11,7 +11,57 @@
#include <asm/processor.h>
#include <asm/ppc_asm.h>
-#define STK_PARM(i) (48 + ((i)-3)*8)
+#define STK_PARM(i) (STACKFRAMESIZE + 48 + ((i)-3)*8)
+#define STK_REG(i) (112 + ((i)-14)*8)
+
+#ifdef CONFIG_HCALL_STATS
+#define STACKFRAMESIZE 256
+#define HCALL_INST_PRECALL \
+ /* use stack frame to save a few non-volital regs */ \
+ stdu r1,-STACKFRAMESIZE(r1); \
+ std r31,STK_REG(r31)(r1); \
+ std r30,STK_REG(r30)(r1); \
+ std r29,STK_REG(r29)(r1); \
+ std r28,STK_REG(r28)(r1); \
+ \
+ /* save lr and hcall opcode */ \
+ /* then get time, purr snapshot before hcall */ \
+ mflr r31; \
+ mr r30,r3; \
+ mftb r29; \
+BEGIN_FTR_SECTION; \
+ mfspr r28,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR);
+
+#define HCALL_INST_POSTCALL \
+ /* get time, purr snapshot after hcall */ \
+ mftb r4; \
+BEGIN_FTR_SECTION; \
+ mfspr r5,SPRN_PURR; \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ /* setup regs to call routine that stuffs stats */ \
+ /* into per-cpu/per-call structure. */ \
+ subf r4,r29,r4; \
+ subf r5,r28,r5; \
+ mr r29,r3; /* save hcall rc */ \
+ mr r3,r30; \
+ bl .update_hcall_stats; \
+ \
+ /* restore hcall rc, lr and non-volital regs */ \
+ mr r3,r29; \
+ mtlr r31; \
+ ld r31,STK_REG(r31)(r1); \
+ ld r30,STK_REG(r30)(r1); \
+ ld r29,STK_REG(r29)(r1); \
+ ld r28,STK_REG(r28)(r1); \
+ addi r1,r1,STACKFRAMESIZE
+#else
+
+#define STACKFRAMESIZE 0
+#define HCALL_INST_PRECALL nop
+#define HCALL_INST_POSTCALL nop
+#endif
.text
@@ -21,8 +71,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 +87,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 +106,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +119,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 +146,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:08:40.000000000 +0000
@@ -0,0 +1,44 @@
+/*
+ * 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>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Common update of the per-CPU/per-hcall statistics
+ */
+void update_hcall_stats(unsigned long opcode,
+ unsigned long tb_delta,
+ unsigned long purr_delta)
+{
+ unsigned long op_index = opcode >> 2;
+ struct hcall_stats *hs = &__get_cpu_var(hcall_stats[op_index]);
+
+ hs->tb_total += tb_delta;
+ hs->purr_total += purr_delta;
+ hs->num_calls++;
+}
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-21 07:04:39.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:06:49.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 3/3] powerpc: Instrument Hypervisor Calls: add debugfs file
From: Mike Kravetz @ 2006-07-21 6:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Make statistics available via files in debugfs.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:10:08.000000000 +0000
+++ powerpc.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-07-21 07:11:00.000000000 +0000
@@ -42,3 +42,96 @@ void update_hcall_stats(unsigned long op
hs->purr_total += purr_delta;
hs->num_calls++;
}
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < MAX_HCALL_OPCODES)
+ 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)
+ 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);
+
+ 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);
^ permalink raw reply
* Can't "up" my eth0
From: Denny @ 2006-07-21 7:03 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1151373673.26257.194.camel@mindpipe>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
Hi,
I am now succefully to bring up my kernel on my PPC440GP custom board, but I failed to up my eth0, the eth0 is link down after the kernel is booting up.
There is no effect, after the command ifconfig eth0 up.
Can anyone tell me what may be the root case, and what reason may cause the eth0 unstable, thanks a lot.
below is my log:
PPC 4xx OCP EMAC driver, version 3.53
mal0: initialized, 4 TX channels, 2 RX channels
zmii0: bridge in RMII mode
eth0: emac0, MAC 00:01:02:54:12:47
eth0: found Generic MII PHY (0x01)
emac1: can't find PHY!
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 4, 65536 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RAMDISK: Compressed image found at block 0
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 120k init
Starting pid 22, console /dev/teth0: link is down
Starting pid 27, console /dev/ttyS1: '/bin/bash'
Starting pid 26, console /dev/ttyS1: '/bin/application'
### Application running ...
Starting pid 29, console /dev/ttyS1: '/bin/application'
Thanks in advance!
- Denny
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
* [PATCH 1/3] powerpc: Instrument Hypervisor Calls: merge headers
From: Mike Kravetz @ 2006-07-21 6:39 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060721063824.GA8639@monkey.ibm.com>
Move all the Hypervisor call definitions to to a single header file.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc/drivers/net/ibmveth.h powerpc.work/drivers/net/ibmveth.h
--- powerpc/drivers/net/ibmveth.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/drivers/net/ibmveth.h 2006-07-21 07:03:44.000000000 +0000
@@ -41,16 +41,6 @@
#define IbmVethMcastRemoveFilter 0x2UL
#define IbmVethMcastClearFilterTable 0x3UL
-/* hcall numbers */
-#define H_VIO_SIGNAL 0x104
-#define H_REGISTER_LOGICAL_LAN 0x114
-#define H_FREE_LOGICAL_LAN 0x118
-#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
-#define H_SEND_LOGICAL_LAN 0x120
-#define H_MULTICAST_CTRL 0x130
-#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
-#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
-
/* hcall macros */
#define h_register_logical_lan(ua, buflst, rxq, fltlst, mac) \
plpar_hcall_norets(H_REGISTER_LOGICAL_LAN, ua, buflst, rxq, fltlst, mac)
diff -Naupr powerpc/include/asm-powerpc/hvcall.h powerpc.work/include/asm-powerpc/hvcall.h
--- powerpc/include/asm-powerpc/hvcall.h 2006-07-19 18:58:18.000000000 +0000
+++ powerpc.work/include/asm-powerpc/hvcall.h 2006-07-21 07:03:44.000000000 +0000
@@ -164,9 +164,15 @@
#define H_VIO_SIGNAL 0x104
#define H_SEND_CRQ 0x108
#define H_COPY_RDMA 0x110
+#define H_REGISTER_LOGICAL_LAN 0x114
+#define H_FREE_LOGICAL_LAN 0x118
+#define H_ADD_LOGICAL_LAN_BUFFER 0x11C
+#define H_SEND_LOGICAL_LAN 0x120
+#define H_MULTICAST_CTRL 0x130
#define H_SET_XDABR 0x134
#define H_STUFF_TCE 0x138
#define H_PUT_TCE_INDIRECT 0x13C
+#define H_CHANGE_LOGICAL_LAN_MAC 0x14C
#define H_VTERM_PARTNER_INFO 0x150
#define H_REGISTER_VTERM 0x154
#define H_FREE_VTERM 0x158
@@ -196,11 +202,13 @@
#define H_GET_HCA_INFO 0x1B8
#define H_GET_PERF_COUNT 0x1BC
#define H_MANAGE_TRACE 0x1C0
+#define H_FREE_LOGICAL_LAN_BUFFER 0x1D4
#define H_QUERY_INT_STATE 0x1E4
#define H_POLL_PENDING 0x1D8
#define H_JOIN 0x298
#define H_VASI_STATE 0x2A4
#define H_ENABLE_CRQ 0x2B0
+#define MAX_HCALL_OPCODES (H_ENABLE_CRQ >> 2)
#ifndef __ASSEMBLY__
^ permalink raw reply
* [PATCH 0/3] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-07-21 6:38 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is a version of the instrumentation patches built on top of
Anton's hcall cleanup patch. In addition, I have gathered the
timebase and PURR snapshots in assembly code. However, it still
performs a call out to C code that updates the data structures.
I'd appreciate some comments on the assembly code as it has been
a looooong time since I've written any.
--
Mike
^ permalink raw reply
* Boot strategies and Boot Image formats in arch/powerpc
From: Claus Gindhart @ 2006-07-21 9:35 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Olaf Wepner, Sabine Bielski, Stefan Nickl
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]
Hi all,
currently i am trying to migrate our existing PowerPC board supports from the arch/ppc - directory into the new arch/powerpc. I am directly working within a cloned paulus_powerpc git repository on the most recent status.
We (Kontron) want to bring our kernel sources into the appropriate for an open source submission. We are modifying both our proprietary Bootloader, and the Linux Kernel, to make them fit to the new conventions, e.g. the flattened device tree.
However, i dont understand the following:
In the old structure, the kernel provided a bunch of sub directories (simple,openfirmware,...) to create a wrapper around the Linux kernel for brining it into the format, which is appropriate for the boot loader used.
This structure was easily adaptable for custom image formats.
Now, these dirs dont exist any more.
What is the strategy here (i could assume one the 3 variants below ?
a) Is it now in the responsibility of the bootloader, to support one of the image formats,
which can be generated here currently ?
b) Will these subdirs (e.g. "simple") come here, but just where not ported yet ?
c) Or, shall such wrapper around the kernel, and/or bringing the kernel into a particular file format
be performed outside the kernel source, by proprietary tools
(e.g. like U-boot does it with the mkimage tool) ?
--
Mit freundlichen Gruessen / Best regards
Claus Gindhart
SW R&D
Kontron Modular Computers
phone :++49 (0)8341-803-374
mailto:claus.gindhart@kontron-modular.com
http://www.kontron.com
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GU d- s++:>++:+ a+ C++$ !U !P L++>$ E-- W+(-) N- o?
K? w !O !M V !PS PE- Y+ PGP+ t 5? X R* tv- b+ DI+++
D-- G e++> h--- !r x+++
------END GEEK CODE BLOCK------
[-- Attachment #2: Type: text/html, Size: 3578 bytes --]
^ 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