* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:13 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20101206094925.3dd90271@wker>
Hello Anatolij,
Anatolij Gustschin wrote:
> On Mon, 06 Dec 2010 08:30:37 +0100
> Heiko Schocher <hs@denx.de> wrote:
>
>> Hello Wolfram,
>>
>> Wolfram Sang wrote:
>>> On Sat, Dec 04, 2010 at 09:21:54AM +0100, Heiko Schocher wrote:
>>>
>>> There shall be only one mpc5200-defconfig. Does the genric one work with your
>>> board?
>> Just tried, mpc5200_defconfig works for me, but...
>>
>> ... I miss there the LM81 and RTC DS1374 support ... and in another
>> patchset from me, I add SM501 support for this board ... also
>> for example, I don;t need CONFIG_FB_RADEON*, CONFIG_SPI* defines
>>
>> Hmm.. I understand that maintaining the board_defconfigs is a nightmare.
>> Just a fast thought (I am not a kconfig expert):
>>
>> As there is a mpc5200_defconfig, couldn;t we get rid of the board
>> defconfig(s), and add instead a possibility to store only the changes
>> against the mpc5200_defconfig in a file? That would save a lot of unneeded
>> lines, and maintaining would be easier as common 5200 config options
>> are stored in mpc5200_defconfig ... and a "make board_settings" would do:
>
> You can save a reduced config file in ./defconfig by running
> "make savedefconfig". This ./defconfig file can also be used as a
> board config file in arch/powerpc/configs/52xx/. Look e.g. at the
> config files under arch/powerpc/configs/52xx/.
Ah, Ok, great.
If such a file is accepted in mainline, I make a v2 post.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 9:31 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCA91C.9030107@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> If such a file is accepted in mainline, I make a v2 post.
===
commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
Author: Grant Likely <grant.likely@secretlab.ca>
Date: Mon Jan 21 11:22:22 2008 -0700
[POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
There is no reason to have separate defconfigs for each mpc5200 board.
Instead, here is a common defconfig that can be used for all supported
platforms.
Merging the defconfigs means there are fewer configuration to test when
compile testing all of arch/powerpc and should make support easier.
Supported boards:
Lite5200(b), Efika, TQM5200, CM5200, MotionPro
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
===
A defconfig which brings the board up is good enough. Specific projects tend to
have specialized configs anyhow.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 9:49 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206093148.GA7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>> If such a file is accepted in mainline, I make a v2 post.
>
> ===
>
> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> Author: Grant Likely <grant.likely@secretlab.ca>
> Date: Mon Jan 21 11:22:22 2008 -0700
>
> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>
> There is no reason to have separate defconfigs for each mpc5200 board.
> Instead, here is a common defconfig that can be used for all supported
> platforms.
>
> Merging the defconfigs means there are fewer configuration to test when
> compile testing all of arch/powerpc and should make support easier.
>
> Supported boards:
> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>
> ===
>
> A defconfig which brings the board up is good enough. Specific projects tend to
> have specialized configs anyhow.
Hmm.. applies this also to the DTS?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 9:58 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291613340.11896.216.camel@concordia>
Thank you for the detailed answer. I'm trying to digest it...
> > What's a good source, besides grepping the kernel to no end ?
>
> Nothing really I'm afraid.
8-|
> So you have a device, it appears in your device tree, and you want to
> write a driver for it.
That's the idea. Communication between usermode and the driver is limited to
simple ioctl calls and the driver receives an interrupt when certain data has
been placed in memory blocks by the hardware (like a DMA). Then the user prog
figures out where that latest data buffer is (mmap) and saves it.
> The first issue is that someone needs to create a device for your node,
> it doesn't necessarily happen by default. For many platforms this will
> all happen "automagically" as long as the device node that describes
> your device appears in the right place, but I'll describe it in full
> anyway.
I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
sure I have to do the whole thing. No udev/HAL here.
> In most cases your device will appear below a node that represents a
> bus, eg:
>
> foobus@xyz {
> compatible = "vendor,foobus-v1.m.n", "simple-bus";
> ...
> yournode@abc {
> ...
> }
> }
>
> If that isn't the case you need to arrange for it somehow [1].
Commenting on your [1] here. So should I just add "simple-bus" or does the
VHDL needs to be modified so as to generate this additional bus info ?
I indeed have:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,virtex405", "xlnx,virtex";
model = "testing";
...
plb: plb@0 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-
bus";
ranges ;
...
xps_acqui_data_0: xps-acqui-data@c9800000 {
compatible = "xlnx,xps-acqui-data-3.00.a";
...
}
...
}
...
}
> Somewhere there needs to be code to probe that bus and create devices on
> it. That is usually done in platform code with of_platform_bus_probe().
Isn't the of_* code outdated (just been told that on a previous message) ?
Or was it just for of_register_platform_driver ?
> If you don't know what platform you're on, you can look at a boot log
> for a line saying "Using <blah> machine description", it will be very
> early in the log. "blah" is then the name of the platform you're on, and
> you should be able to grep for it in arch/powerpc/platforms.
"Using Xilinx Virtex machine description"
> Once you've found the .c file for your platform, there should be a call
> somewhere to of_platform_bus_probe(), with a list of ids, and one of
> those ids should match the compatible property of your bus node. In a
> lot of cases that is just "simple-bus".
That'd be:
arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
and
arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
No match for simple-bus of acqui-data in dmesg.
> To check a device is being created for your device node, you can look
> in /sys/devices. The device names don't match 100% with what's in the
> device tree, but the name should be there, so in your case:
>
> # find /sys/devices -name '*xps-acqui-data*'
Indeed:
# ll /sys/devices/plb.0/c9800000.xps-acqui-data
-r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
-r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
-r--r--r-- 1 root root 4.0K Dec 6 09:47 name
lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem ->
../../../bus/of_platform/
-rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
So that's created on boot, right ?
> [...code snipped...]
I still need a platform_device_register() after your sample init, right ?
I'll get on to adapting your sample code now. Thanks a lot.
--
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Wolfram Sang @ 2010-12-06 10:01 UTC (permalink / raw)
To: Heiko Schocher; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <4CFCB195.8000306@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]
> Wolfram Sang wrote:
> > On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
> >> If such a file is accepted in mainline, I make a v2 post.
> >
> > ===
> >
> > commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
> > Author: Grant Likely <grant.likely@secretlab.ca>
> > Date: Mon Jan 21 11:22:22 2008 -0700
> >
> > [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
> >
> > There is no reason to have separate defconfigs for each mpc5200 board.
> > Instead, here is a common defconfig that can be used for all supported
> > platforms.
> >
> > Merging the defconfigs means there are fewer configuration to test when
> > compile testing all of arch/powerpc and should make support easier.
> >
> > Supported boards:
> > Lite5200(b), Efika, TQM5200, CM5200, MotionPro
> >
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > ===
> >
> > A defconfig which brings the board up is good enough. Specific projects tend to
> > have specialized configs anyhow.
>
> Hmm.. applies this also to the DTS?
How should that work? :) There is one kernel with all needed options
(the optional ones being modules) and the DTS selects what is needed.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, 5200: add defconfig for charon board
From: Heiko Schocher @ 2010-12-06 10:25 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Anatolij Gustschin, linuxppc-dev
In-Reply-To: <20101206100116.GB7320@pengutronix.de>
Hello Wolfram,
Wolfram Sang wrote:
>> Wolfram Sang wrote:
>>> On Mon, Dec 06, 2010 at 10:13:00AM +0100, Heiko Schocher wrote:
>>>> If such a file is accepted in mainline, I make a v2 post.
>>> ===
>>>
>>> commit 0a0a5af30b9831e4f049610b5a2d9d5108ff027a
>>> Author: Grant Likely <grant.likely@secretlab.ca>
>>> Date: Mon Jan 21 11:22:22 2008 -0700
>>>
>>> [POWERPC] mpc5200: merge defconfigs for all mpc5200 boards
>>>
>>> There is no reason to have separate defconfigs for each mpc5200 board.
>>> Instead, here is a common defconfig that can be used for all supported
>>> platforms.
>>>
>>> Merging the defconfigs means there are fewer configuration to test when
>>> compile testing all of arch/powerpc and should make support easier.
>>>
>>> Supported boards:
>>> Lite5200(b), Efika, TQM5200, CM5200, MotionPro
>>>
>>> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> ===
>>>
>>> A defconfig which brings the board up is good enough. Specific projects tend to
>>> have specialized configs anyhow.
>> Hmm.. applies this also to the DTS?
>
> How should that work? :) There is one kernel with all needed options
> (the optional ones being modules) and the DTS selects what is needed.
Ok, so I post a v2 without defconfig patch.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 11:56 UTC (permalink / raw)
To: Jeremy Kerr; +Cc: linuxppc-dev
In-Reply-To: <201012061435.07393.jk@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 317 bytes --]
On Mon, 2010-12-06 at 14:35 +0800, Jeremy Kerr wrote:
> Hi Michael,
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
>
> Nice write up, mind if I steal this for the devicetree.org wiki?
Sure thing, feel free to correct any mistakes too ;D
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Michael Ellerman @ 2010-12-06 12:07 UTC (permalink / raw)
To: Guillaume Dargaud; +Cc: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
[-- Attachment #1: Type: text/plain, Size: 5284 bytes --]
On Mon, 2010-12-06 at 10:58 +0100, Guillaume Dargaud wrote:
> Thank you for the detailed answer. I'm trying to digest it...
>
> > > What's a good source, besides grepping the kernel to no end ?
> >
> > Nothing really I'm afraid.
> 8-|
>
> > So you have a device, it appears in your device tree, and you want to
> > write a driver for it.
> That's the idea. Communication between usermode and the driver is limited to
> simple ioctl calls and the driver receives an interrupt when certain data has
> been placed in memory blocks by the hardware (like a DMA). Then the user prog
> figures out where that latest data buffer is (mmap) and saves it.
OK, that should be all pretty straight forward, and covered by the
material in LDD and similar references. You just need to get your device
probed.
> > The first issue is that someone needs to create a device for your node,
> > it doesn't necessarily happen by default. For many platforms this will
> > all happen "automagically" as long as the device node that describes
> > your device appears in the right place, but I'll describe it in full
> > anyway.
>
> I'm on a minimalist embedded system (buildroot+busybox+uclibc), so I'm pretty
> sure I have to do the whole thing. No udev/HAL here.
That's another problem. The device I'm talking about here is just the
minimal struct in the kernel that you need in order for your driver to
probe against it. Once your driver has matched against a device then you
(might) need to worry about exposing a device to userspace in /dev.
> > In most cases your device will appear below a node that represents a
> > bus, eg:
> >
> > foobus@xyz {
> > compatible = "vendor,foobus-v1.m.n", "simple-bus";
> > ...
> > yournode@abc {
> > ...
> > }
> > }
> >
> > If that isn't the case you need to arrange for it somehow [1].
>
> Commenting on your [1] here. So should I just add "simple-bus" or does the
> VHDL needs to be modified so as to generate this additional bus info ?
Doesn't look like it:
> I indeed have:
>
> /dts-v1/;
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,virtex405", "xlnx,virtex";
> model = "testing";
> ...
> plb: plb@0 {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "xlnx,plb-v46-1.05.a", "xlnx,plb-v46-1.00.a", "simple-bus";
> ranges ;
> ...
> xps_acqui_data_0: xps-acqui-data@c9800000 {
> compatible = "xlnx,xps-acqui-data-3.00.a";
> ...
> }
> ...
> }
> ...
> }
That looks good.
> > Somewhere there needs to be code to probe that bus and create devices on
> > it. That is usually done in platform code with of_platform_bus_probe().
>
> Isn't the of_* code outdated (just been told that on a previous message) ?
> Or was it just for of_register_platform_driver ?
No it's just that platform_drivers are now able to do all the things an
of_platform_driver can do, so new code should just use platform_driver.
I'm not sure if of_platform_bus_probe() will go away eventually, but for
now it is the only way to achieve what you need.
> > If you don't know what platform you're on, you can look at a boot log
> > for a line saying "Using <blah> machine description", it will be very
> > early in the log. "blah" is then the name of the platform you're on, and
> > you should be able to grep for it in arch/powerpc/platforms.
>
> "Using Xilinx Virtex machine description"
Cool.
> > Once you've found the .c file for your platform, there should be a call
> > somewhere to of_platform_bus_probe(), with a list of ids, and one of
> > those ids should match the compatible property of your bus node. In a
> > lot of cases that is just "simple-bus".
>
> That'd be:
> arch/powerpc/platforms/40x/virtex.c:51: .name = "Xilinx Virtex",
> and
> arch/powerpc/platforms/40x/virtex.c:21: { .compatible = "simple-bus", },
Perfect.
> No match for simple-bus of acqui-data in dmesg.
That's normal, if the kernel printed out every device it found you'd
drown in messages. If you want to you can put a printk in
of_platform_device_create() and you should see it.
> > To check a device is being created for your device node, you can look
> > in /sys/devices. The device names don't match 100% with what's in the
> > device tree, but the name should be there, so in your case:
> >
> > # find /sys/devices -name '*xps-acqui-data*'
>
> Indeed:
> # ll /sys/devices/plb.0/c9800000.xps-acqui-data
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 devspec
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 modalias
> -r--r--r-- 1 root root 4.0K Dec 6 09:47 name
> lrwxrwxrwx 1 root root 0 Dec 6 09:47 subsystem -> ../../../bus/of_platform/
> -rw-r--r-- 1 root root 4.0K Dec 6 09:47 uevent
>
> So that's created on boot, right ?
Yep, so that is all working fine. You just need to write a driver that
will match against that device.
> > [...code snipped...]
>
> I still need a platform_device_register() after your sample init, right ?
I had one in there already, in foo_driver_init(), didn't I?
> I'll get on to adapting your sample code now. Thanks a lot.
No worries.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* RE: Getting the IRQ number (Was: Basic driver devel questions ?)
From: David Laight @ 2010-12-06 12:17 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201012061058.37612.dargaud@lpsc.in2p3.fr>
=20
> That's the idea. Communication between usermode and the driver is
limited to=20
> simple ioctl calls and the driver receives an interrupt when certain
data has=20
> been placed in memory blocks by the hardware (like a DMA).=20
> Then the user prog figures out where that latest data buffer is (mmap)
and saves it.=20
I've used pread() and pwrite() to directly copy data to/from a devices
PCI memory space.
The driver just verifies the offset and calls copy_to/from_user() [1].
High offsets can be used to access driver specific data.
The userspace code for pread/write is less painful than using ioctl()
for everything.
This also lets you dump the device memory space with hexdump.
I also made the device interrupt generate POLLIN (this needs a bit of
care since the interrupt can arrive before poll() is called).
David
[1] I actually had to use the PCIe dma controller to get adequate
throughput.
^ permalink raw reply
* Re: Getting the IRQ number (Was: Basic driver devel questions ?)
From: Guillaume Dargaud @ 2010-12-06 14:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1291637228.21242.14.camel@concordia>
Hello all,
> OK, that should be all pretty straight forward, and covered by the
> material in LDD and similar references. You just need to get your device
> probed.
I'm not sure what you mean with that term: simply identifying that the device
works using device specific code ?
I've looked at several *_probe functions from other drivers and they are all
completely different with no common code...
Or do you mean calling of_platform_bus_probe() ? What does that function do ?
> No it's just that platform_drivers are now able to do all the things an
> of_platform_driver can do, so new code should just use platform_driver.
>
> I'm not sure if of_platform_bus_probe() will go away eventually, but for
> now it is the only way to achieve what you need.
I assume the kernel needs to be compiled with CONFIG_OF.
...hmm I had to "git pull" in order for this to compile your snippet. That's
really recent! Unfortunately i need to reflash my device with the new kernel
before i can begin testing my module.
When I try to compile your (adapted) snippet, I got this minor problems:
.probe = foo_driver_probe,
^ warning: initialization from incompatible pointer type
Shouldn't foo_driver_probe be:
static int foo_driver_probe(struct platform_device *pdev)
instead of:
static int foo_driver_probe(struct platform_device *device,
const struct of_device_id *device_id)
Also:
struct foo_device *foo;
That's where I put my own content, right ?
And needs to be kfreed in a foo_driver_remove() function, right ?
> > I still need a platform_device_register() after your sample init, right ?
>
> I had one in there already, in foo_driver_init(), didn't I?
You had platform_driver_register(), not that I'm all clear yet on the
distinction...
Another question: I just spent 10 minutes trying to find where "struct device"
was defined. (ack-)grep was absolutely no use. Isn't there a way to cross-
reference my own kernel, the way I've compiled it ?
--
Guillaume Dargaud
http://www.gdargaud.net/Climbing/
^ permalink raw reply
* RE: Getting the IRQ number (Was: Basic driver devel questions ?)
From: David Laight @ 2010-12-06 14:47 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <201012061544.40124.dargaud@lpsc.in2p3.fr>
=20
> Another question: I just spent 10 minutes trying to find
> where "struct device" was defined.
Dirty trick #4:
At the top of a source file (before the first include) add:
struct device { int fubar; };
Then try to compile it.
The compiler will the tell where it is defined!
David
^ permalink raw reply
* [PATCH 0/4] V2 Add ability to link device blob(s) into vmlinux
From: dirk.brandewie @ 2010-12-06 17:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch set adds the ability to link device tree blobs into
vmlinux.
Patch 1 implements the changes to include/asm-generic/vmlinux.lds.h and
adds a generic rule for generating DTB objects to be linked vmlinux.
Patch 2 implements linking a DTB into an x86 image.
Patch 3-4 move {powerpc,microblaze}/boot/Makefile to use the dtc rule
in patch 1.
This patch set has been tested on x86.
Powerpc and Microblaze have been compile tested with and without patch
3 and 4 applied.
Changes from V1:
Documentation added for dtc command in Makefile.lib to
Documentation/kbuild/makefiles.txt
Separate DTB_ALIGNMENT define removed.
FORCE removed from dtc rule.
Removed hardcoded path to dts files from dtc command.
Moved %.dtb: %.dts rule to arch specific makefiles.
Patch for adding kernel command line option to pass in dtb_compat
string dropped from this set will be submitted seperately.
Dirk Brandewie (4):
of: Add support for linking device tree blobs into vmlinux
x86/of: Add building device tree blob(s) into image.
of/powerpc: Use generic rule to build dtb's
microblaze/of: Use generic rule to build dtb's
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
arch/microblaze/boot/Makefile | 10 ++--------
arch/powerpc/boot/Makefile | 8 +++-----
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
scripts/Makefile.lib | 21 ++++++++++++++++++++-
6 files changed, 62 insertions(+), 17 deletions(-)
--
1.7.2.3
^ permalink raw reply
* [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: dirk.brandewie @ 2010-12-06 17:35 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds support for linking device tree blob(s) into
vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
.dtb sections into vmlinux. To maintain compatiblity with the of/fdt
driver code platforms MUST copy the blob to a non-init memory location
before the kernel frees the .init.* sections in the image.
Modifies scripts/Makefile.lib to add a kbuild command to
compile DTS files to device tree blobs and a rule to create objects to
wrap the blobs for linking.
STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
create wrapper objects for the dtb in Makefile.lib. The
STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
STRUCT_ALIGNMENT definition.
The DTB's are placed on 32 byte boundries to allow parsing the blob
with driver/of/fdt.c during early boot without having to copy the blob
to get the structure alignment GCC expects.
A DTB is linked in by adding the DTB object to the list of objects to
be linked into vmlinux in the archtecture specific Makefile using
obj-y += foo.dtb.o
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
scripts/Makefile.lib | 21 ++++++++++++++++++++-
3 files changed, 47 insertions(+), 4 deletions(-)
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index 0ef00bd..fc18bb1 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
resulting in the target file being recompiled for no
obvious reason.
+ dtc
+ Create flattend device tree blob object suitable for linking
+ into vmlinux. Device tree blobs linked into vmlinux are placed
+ in an init section in the image. Platform code *must* copy the
+ blob to non-init memory prior to calling unflatten_device_tree().
+
+ Example:
+ #arch/x86/platform/ce4100/Makefile
+ clean-files := *dtb.S
+
+ DTC_FLAGS := -p 1024
+ obj-y += foo.dtb.o
+
+ $(obj)/%.dtb: $(src)/%.dts
+ $(call if_changed,dtc)
--- 6.7 Custom kbuild commands
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index bd69d79..024d3b9 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -23,7 +23,7 @@
* _etext = .;
*
* _sdata = .;
- * RO_DATA_SECTION(PAGE_SIZE)
+* RO_DATA_SECTION(PAGE_SIZE)
* RW_DATA_SECTION(...)
* _edata = .;
*
@@ -67,7 +67,8 @@
* Align to a 32 byte boundary equal to the
* alignment gcc 4.5 uses for a struct
*/
-#define STRUCT_ALIGN() . = ALIGN(32)
+#define STRUCT_ALIGNMENT 32
+#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
/* The actual configuration determine if the init/exit sections
* are handled as text/data or they can be discarded (which
@@ -146,6 +147,13 @@
#define TRACE_SYSCALLS()
#endif
+
+#define KERNEL_DTB() \
+ STRUCT_ALIGN(); \
+ VMLINUX_SYMBOL(__dtb_start) = .; \
+ *(.dtb.init.rodata) \
+ VMLINUX_SYMBOL(__dtb_end) = .;
+
/* .data section */
#define DATA_DATA \
*(.data) \
@@ -468,7 +476,8 @@
MCOUNT_REC() \
DEV_DISCARD(init.rodata) \
CPU_DISCARD(init.rodata) \
- MEM_DISCARD(init.rodata)
+ MEM_DISCARD(init.rodata) \
+ KERNEL_DTB()
#define INIT_TEXT \
*(.init.text) \
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 4c72c11..937eabbb 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -200,7 +200,26 @@ quiet_cmd_gzip = GZIP $@
cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
(rm -f $@ ; false)
-
+# DTC
+# ---------------------------------------------------------------------------
+
+# Generate an assembly file to wrap the output of the device tree compiler
+$(obj)/%.dtb.S: $(obj)/%.dtb
+ @echo '#include <asm-generic/vmlinux.lds.h>' > $@
+ @echo '.section .dtb.init.rodata,"a"' >> $@
+ @echo '.balign STRUCT_ALIGNMENT' >> $@
+ @echo '.global __dtb_$(*F)_begin' >> $@
+ @echo '__dtb_$(*F)_begin:' >> $@
+ @echo '.incbin "$<" ' >> $@
+ @echo '__dtb_$(*F)_end:' >> $@
+ @echo '.global __dtb_$(*F)_end' >> $@
+ @echo '.balign STRUCT_ALIGNMENT' >> $@
+
+DTC = $(objtree)/scripts/dtc/dtc
+
+quiet_cmd_dtc = DTC $@
+ cmd_dtc = $(DTC) -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
+ooo
# Bzip2
# ---------------------------------------------------------------------------
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/4] x86/of: Add building device tree blob(s) into image.
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
This patch adds linking device tree blob into vmlinux. DTB's are
added by adding the blob object name to list of objects to be linked
into the image.
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/x86/platform/ce4100/Makefile | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/platform/ce4100/Makefile b/arch/x86/platform/ce4100/Makefile
index 91fc929..3b49187 100644
--- a/arch/x86/platform/ce4100/Makefile
+++ b/arch/x86/platform/ce4100/Makefile
@@ -1 +1,11 @@
obj-$(CONFIG_X86_INTEL_CE) += ce4100.o
+clean-files := *dtb.S
+
+ifdef CONFIG_X86_OF
+###
+# device tree blob
+obj-$(CONFIG_X86_INTEL_CE) += ce4100.dtb.o
+
+$(obj)/%.dtb: $(src)/%.dts
+ $(call if_changed,dtc)
+endif
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/4] of/powerpc: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/powerpc/boot/Makefile | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index fae8192..3afb33a 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -35,7 +35,7 @@ endif
BOOTCFLAGS += -I$(obj) -I$(srctree)/$(obj)
-DTS_FLAGS ?= -p 1024
+DTC_FLAGS ?= -p 1024
$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
@@ -332,10 +332,8 @@ $(obj)/treeImage.%: vmlinux $(obj)/%.dtb $(wrapperbits)
$(call if_changed,wrap,treeboot-$*,,$(obj)/$*.dtb)
# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
-
-$(obj)/%.dtb: $(dtstree)/%.dts
- $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 $(DTS_FLAGS) $(dtstree)/$*.dts
+$(obj)/%.dtb: $(src)/dts/%.dts
+ $(call if_changed,dtc)
# If there isn't a platform selected then just strip the vmlinux.
ifeq (,$(image-y))
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/4] microblaze/of: Use generic rule to build dtb's
From: dirk.brandewie @ 2010-12-06 17:36 UTC (permalink / raw)
To: linux-kernel
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
sodaville, Dirk Brandewie, linuxppc-dev
In-Reply-To: <cover.1291656753.git.dirk.brandewie@gmail.com>
From: Dirk Brandewie <dirk.brandewie@gmail.com>
Modify arch/powerpc/boot/Makefile to use dtc command in
scripts/Makefile.lib
Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
---
arch/microblaze/boot/Makefile | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/microblaze/boot/Makefile b/arch/microblaze/boot/Makefile
index be01d78..52430e5 100644
--- a/arch/microblaze/boot/Makefile
+++ b/arch/microblaze/boot/Makefile
@@ -10,9 +10,6 @@ targets := linux.bin linux.bin.gz simpleImage.%
OBJCOPYFLAGS := -O binary
-# Where the DTS files live
-dtstree := $(srctree)/$(src)/dts
-
# Ensure system.dtb exists
$(obj)/linked_dtb.o: $(obj)/system.dtb
@@ -51,14 +48,11 @@ $(obj)/simpleImage.%: vmlinux FORCE
$(call if_changed,strip)
@echo 'Kernel: $@ is ready' ' (#'`cat .version`')'
-# Rule to build device tree blobs
-DTC = $(objtree)/scripts/dtc/dtc
# Rule to build device tree blobs
-quiet_cmd_dtc = DTC $@
- cmd_dtc = $(DTC) -O dtb -o $(obj)/$*.dtb -b 0 -p 1024 $(dtstree)/$*.dts
+DTC_FLAGS := -p 1024
-$(obj)/%.dtb: $(dtstree)/%.dts FORCE
+$(obj)/%.dtb: $(src)/dts/%.dts FORCE
$(call if_changed,dtc)
clean-files += *.dtb simpleImage.*.unstrip linux.bin.ub
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] Make auto-loading of therm_pm72 possible
From: kevin diggs @ 2010-12-06 18:25 UTC (permalink / raw)
To: Marc Zyngier; +Cc: Linux PPC Development
In-Reply-To: <1291561537-1943-1-git-send-email-maz@misterjones.org>
Hi,
On a sort of related issue, if anyone out there has a PowerMac7,3
(dual 2.5 GHz 970Fx, PCI-X), I would appreciate it if you could do me
a favor.
I think this therm_pm72 thing creates the sysfs temperature and
voltage attributes for the cpus. I noticed on my machine that if I use
the cpufreq driver for this thing the frequencies were like 2.0 and
2.5. The problem is that the cpu voltages were something like 1.25 and
1.37 respectively. At 1.37 and 2.5 GHz, cpu 1 would zoom to 110+ under
load.
When I finally managed to get a compiler built that could build a
kernel past 2.6.28, I removed the cpufreq driver. Now this thing runs
at 2.5 GHz all the time. Under load cpu1 tops out at like 74 ish. I
eventually noticed that the voltage was 1.25. Huh? I thought this
voltage scaling business used the high voltage for the high frequency.
How can this thing be running at its high speed at the lower
voltage???
Can someone please confirm this behavior on a different 7,3? I did get
this thing off of ebay and might have myself a franken G5?
Thanks!
kevin
P.S.: I also don't get the 2.0 GHz low speed? I thought with the FX
the speed would be 2.5 / 2 or 1.25? Does this beast NOT use the FX's
frequency scaling capabilities?
^ permalink raw reply
* Re: [PATCH 1/4] of: Add support for linking device tree blobs into vmlinux
From: Sam Ravnborg @ 2010-12-06 19:02 UTC (permalink / raw)
To: dirk.brandewie
Cc: linux-arch, mmarek, microblaze-uclinux, devicetree-discuss,
linux-kernel, sodaville, linuxppc-dev
In-Reply-To: <76a37fa459aeadce5d11db8a7cc044687a2e0e8c.1291656753.git.dirk.brandewie@gmail.com>
On Mon, Dec 06, 2010 at 09:35:59AM -0800, dirk.brandewie@gmail.com wrote:
> From: Dirk Brandewie <dirk.brandewie@gmail.com>
>
> This patch adds support for linking device tree blob(s) into
> vmlinux. Modifies asm-generic/vmlinux.lds.h to add linking
> .dtb sections into vmlinux. To maintain compatiblity with the of/fdt
> driver code platforms MUST copy the blob to a non-init memory location
> before the kernel frees the .init.* sections in the image.
>
> Modifies scripts/Makefile.lib to add a kbuild command to
> compile DTS files to device tree blobs and a rule to create objects to
> wrap the blobs for linking.
>
> STRUCT_ALIGNMENT is defined in vmlinux.lds.h for use in the rule to
> create wrapper objects for the dtb in Makefile.lib. The
> STRUCT_ALIGN() macro in vmlinux.lds.h is modified to use the
> STRUCT_ALIGNMENT definition.
>
> The DTB's are placed on 32 byte boundries to allow parsing the blob
> with driver/of/fdt.c during early boot without having to copy the blob
> to get the structure alignment GCC expects.
>
> A DTB is linked in by adding the DTB object to the list of objects to
> be linked into vmlinux in the archtecture specific Makefile using
> obj-y += foo.dtb.o
>
> Signed-off-by: Dirk Brandewie <dirk.brandewie@gmail.com>
> ---
> Documentation/kbuild/makefiles.txt | 15 +++++++++++++++
> include/asm-generic/vmlinux.lds.h | 15 ++++++++++++---
> scripts/Makefile.lib | 21 ++++++++++++++++++++-
> 3 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
> index 0ef00bd..fc18bb1 100644
> --- a/Documentation/kbuild/makefiles.txt
> +++ b/Documentation/kbuild/makefiles.txt
> @@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
> resulting in the target file being recompiled for no
> obvious reason.
>
> + dtc
> + Create flattend device tree blob object suitable for linking
> + into vmlinux. Device tree blobs linked into vmlinux are placed
> + in an init section in the image. Platform code *must* copy the
> + blob to non-init memory prior to calling unflatten_device_tree().
> +
> + Example:
> + #arch/x86/platform/ce4100/Makefile
> + clean-files := *dtb.S
> +
> + DTC_FLAGS := -p 1024
> + obj-y += foo.dtb.o
> +
> + $(obj)/%.dtb: $(src)/%.dts
> + $(call if_changed,dtc)
When using "if_changed" you need to add your target to targets-y.
And you need to specify FORCE as a prerequisite to force kbuild
to use the if_changed logic.
The purpose of if_changed is to check if the commandlien has changed
and execute the command again also if the commandline has changed.
The simpler variant is $(call cmd,dtc) where you do not check
the command line and do not need FORCE.
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bd69d79..024d3b9 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -23,7 +23,7 @@
> * _etext = .;
> *
> * _sdata = .;
> - * RO_DATA_SECTION(PAGE_SIZE)
> +* RO_DATA_SECTION(PAGE_SIZE)
> * RW_DATA_SECTION(...)
> * _edata = .;
> *
Change seems wrong.
> @@ -67,7 +67,8 @@
> * Align to a 32 byte boundary equal to the
> * alignment gcc 4.5 uses for a struct
> */
> -#define STRUCT_ALIGN() . = ALIGN(32)
> +#define STRUCT_ALIGNMENT 32
> +#define STRUCT_ALIGN() . = ALIGN(STRUCT_ALIGNMENT)
>
> /* The actual configuration determine if the init/exit sections
> * are handled as text/data or they can be discarded (which
> @@ -146,6 +147,13 @@
> #define TRACE_SYSCALLS()
> #endif
>
> +
> +#define KERNEL_DTB() \
> + STRUCT_ALIGN(); \
> + VMLINUX_SYMBOL(__dtb_start) = .; \
> + *(.dtb.init.rodata) \
> + VMLINUX_SYMBOL(__dtb_end) = .;
> +
> /* .data section */
> #define DATA_DATA \
> *(.data) \
> @@ -468,7 +476,8 @@
> MCOUNT_REC() \
> DEV_DISCARD(init.rodata) \
> CPU_DISCARD(init.rodata) \
> - MEM_DISCARD(init.rodata)
> + MEM_DISCARD(init.rodata) \
> + KERNEL_DTB()
>
> #define INIT_TEXT \
> *(.init.text) \
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index 4c72c11..937eabbb 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -200,7 +200,26 @@ quiet_cmd_gzip = GZIP $@
> cmd_gzip = (cat $(filter-out FORCE,$^) | gzip -f -9 > $@) || \
> (rm -f $@ ; false)
>
> -
> +# DTC
> +# ---------------------------------------------------------------------------
> +
> +# Generate an assembly file to wrap the output of the device tree compiler
> +$(obj)/%.dtb.S: $(obj)/%.dtb
> + @echo '#include <asm-generic/vmlinux.lds.h>' > $@
> + @echo '.section .dtb.init.rodata,"a"' >> $@
> + @echo '.balign STRUCT_ALIGNMENT' >> $@
> + @echo '.global __dtb_$(*F)_begin' >> $@
> + @echo '__dtb_$(*F)_begin:' >> $@
> + @echo '.incbin "$<" ' >> $@
> + @echo '__dtb_$(*F)_end:' >> $@
> + @echo '.global __dtb_$(*F)_end' >> $@
> + @echo '.balign STRUCT_ALIGNMENT' >> $@
> +
If we really want this rule in Makefile.lib then at least make it less verbose,
and more secure.
Something like this:
quiet_dt_S_dtb_cmd = DTB $@
dt_S_dtb_cmd = \
( \
@echo '#include <asm-generic/vmlinux.lds.h>'; \
@echo '.section .dtb.init.rodata,"a"'; \
@echo '.balign STRUCT_ALIGNMENT'; \
echo '.global __dtb_$(*F)_begin'; \
echo '__dtb_$(*F)_begin:'; \
echo '.incbin "$<" '; \
echo '__dtb_$(*F)_end:'; \
echo '.global __dtb_$(*F)_end'; \
echo '.balign STRUCT_ALIGNMENT'; \
) > $@
$(obj)/%.dtb.S: $(obj)/%.dtb
$(call cmd,dt_S_dtb)
> +DTC = $(objtree)/scripts/dtc/dtc
If this is the only spot where we use DTC then drop the variable.
> +
> +quiet_cmd_dtc = DTC $@
> + cmd_dtc = $(DTC) -O dtb -o $@ -b 0 $(DTC_FLAGS) $<
> +ooo
What is the purpose of these "ooo"? A debugging left-over?
Sam
^ permalink raw reply
* [PATCH] powerpc/watchdog: Propagate Book E WDT period changes to all cores
From: Randy Vinson @ 2010-12-06 21:02 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org, linux-watchdog, Kumar Gala
When the watchdog period is changed, it needs to be propagated to all cores
in addition to the core that performed the change.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
---
drivers/watchdog/booke_wdt.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/booke_wdt.c b/drivers/watchdog/booke_wdt.c
index d11ffb0..c8ffa6c 100644
--- a/drivers/watchdog/booke_wdt.c
+++ b/drivers/watchdog/booke_wdt.c
@@ -85,6 +85,22 @@ static unsigned int sec_to_period(unsigned int secs)
return 0;
}
+static void __booke_wdt_set(void *data)
+{
+ u32 val;
+
+ val = mfspr(SPRN_TCR);
+ val &= ~WDTP_MASK;
+ val |= WDTP(booke_wdt_period);
+
+ mtspr(SPRN_TCR, val);
+}
+
+static void booke_wdt_set(void)
+{
+ on_each_cpu(__booke_wdt_set, NULL, 0);
+}
+
static void __booke_wdt_ping(void *data)
{
mtspr(SPRN_TSR, TSR_ENW|TSR_WIS);
@@ -181,8 +197,7 @@ static long booke_wdt_ioctl(struct file *file,
#else
booke_wdt_period = tmp;
#endif
- mtspr(SPRN_TCR, (mfspr(SPRN_TCR) & ~WDTP_MASK) |
- WDTP(booke_wdt_period));
+ booke_wdt_set();
return 0;
case WDIOC_GETTIMEOUT:
return put_user(booke_wdt_period, p);
--
1.6.3.3.328.ge81f
^ permalink raw reply related
* [RFC/PATCH 0/7] powerpc: Implement lazy save of FP, VMX and VSX state in SMP
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev, linux-kernel
This implements lazy save of FP, VMX and VSX state on SMP 64bit and 32
bit powerpc.
Currently we only do lazy save in UP, but this patch set extends this to
SMP. We always do lazy restore.
For VMX, on a context switch we do the following:
- if we are switching to a CPU that currently holds the new processes
state, just turn on VMX in the MSR (this is the lazy/quick case)
- if the new processes state is in the thread_struct, turn VMX off.
- if the new processes state is in someone else's CPU, IPI that CPU to
giveup it's state and turn VMX off in the MSR (slow IPI case).
We always start the new process at this point, irrespective of if we
have the state or not in the thread struct or current CPU.
So in the slow case, we attempt to avoid the IPI latency by starting
the process immediately and only waiting for the state to be flushed
when the process actually needs VMX. ie. when we take the VMX
unavailable exception after the context switch.
FP is implemented in a similar way. VSX reuses the FP and VMX code as
it doesn't have any additional state over what FP and VMX used.
I've been benchmarking with Anton Blanchard's context_switch.c benchmark
found here:
http://ozlabs.org/~anton/junkcode/context_switch.c
Using this benchmark as is gives no degradation in performance with these
patches applied.
Inserting a simple FP instruction into one of the threads (gives the
nice save/restore lazy case), I get about a 4% improvement in context
switching rates with my patches applied. I get similar results VMX.
With a simple VSX instruction (VSX state is 64x128bit registers) in 1
thread I get an 8% bump in performance with these patches.
With FP/VMX/VSX instructions in both threads, I get no degradation in
performance.
Running lmbench doesn't have any degradation in performance.
Most of my benchmarking and testing has been done on 64 bit systems.
I've tested 32 bit FP but I've not tested 32 bit VMX at all.
There is probably some optimisations to my asm code that can also be
made. I've been concentrating on correctness, as opposed to speed
with the asm code, since if you get a lazy context switch, you skip
all the asm now anyway.
Whole series is bisectable to compile with various 64/32bit SMP/UP
FPU/VMX/VSX config options on and off.
I really hate the include file changes in this series. Getting the
call_single_data in the powerpc threads_struct was a PITA :-)
Mikey
Signed-off-by: Michael Neuling <mikey@neuling.org>
^ permalink raw reply
* [RFC/PATCH 1/7] Add csd_locked function
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101206234043.083045003@neuling.org>
Add csd_locked function to determine if a struct call_single_data is
currently locked. This can be used to see if an IPI can be called
again using this call_single_data.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
kernel/smp.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: linux-lazy/kernel/smp.c
===================================================================
--- linux-lazy.orig/kernel/smp.c
+++ linux-lazy/kernel/smp.c
@@ -12,6 +12,7 @@
#include <linux/gfp.h>
#include <linux/smp.h>
#include <linux/cpu.h>
+#include <linux/hardirq.h>
static struct {
struct list_head queue;
@@ -131,6 +132,22 @@
}
/*
+ * Determine if a csd is currently locked. This can be used to
+ * determine if an IPI is currently pending using this csd already.
+ */
+int csd_locked(struct call_single_data *data)
+{
+ WARN_ON(preemptible());
+
+ /* Ensure flags have propagated */
+ smp_mb();
+
+ if (data->flags & CSD_FLAG_LOCK)
+ return 1;
+ return 0;
+}
+
+/*
* Insert a previously allocated call_single_data element
* for execution on the given CPU. data must already have
* ->func, ->info, and ->flags set.
^ permalink raw reply
* [RFC/PATCH 2/7] Rearrange include files to make struct call_single_data usable in more places
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20101206234043.083045003@neuling.org>
We need to put struct call_single_data in the powerpc thread_struct,
but can't without this.
The thread_struct is in processor.h. To add a struct call_single_data
to the thread_struct asm/processor.h must include linux/smp.h. When
linux/smp.h is added to processor.h this creates an include loop via
with list.h via:
linux/list.h includes:
linux/prefetch.h includes:
asm/processor.h (for powerpc) includes:
linux/smp.h includes:
linux/list.h
This loops results in an "incomplete list type" compile when using
struct list_head as used in struct call_single_data.
This patch rearanges some include files to avoid this loop.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
include/linux/call_single_data.h | 14 ++++++++++++++
include/linux/list.h | 4 +++-
include/linux/smp.h | 8 +-------
3 files changed, 18 insertions(+), 8 deletions(-)
Index: linux-lazy/include/linux/call_single_data.h
===================================================================
--- /dev/null
+++ linux-lazy/include/linux/call_single_data.h
@@ -0,0 +1,14 @@
+#ifndef __LINUX_CALL_SINGLE_DATA_H
+#define __LINUX_CALL_SINGLE_DATA_H
+
+#include <linux/list.h>
+
+struct call_single_data {
+ struct list_head list;
+ void (*func) (void *info);
+ void *info;
+ u16 flags;
+ u16 priv;
+};
+
+#endif /* __LINUX_CALL_SINGLE_DATA_H */
Index: linux-lazy/include/linux/list.h
===================================================================
--- linux-lazy.orig/include/linux/list.h
+++ linux-lazy/include/linux/list.h
@@ -4,7 +4,6 @@
#include <linux/types.h>
#include <linux/stddef.h>
#include <linux/poison.h>
-#include <linux/prefetch.h>
/*
* Simple doubly linked list implementation.
@@ -16,6 +15,9 @@
* using the generic single-entry routines.
*/
+#include <linux/prefetch.h>
+#include <asm/system.h>
+
#define LIST_HEAD_INIT(name) { &(name), &(name) }
#define LIST_HEAD(name) \
Index: linux-lazy/include/linux/smp.h
===================================================================
--- linux-lazy.orig/include/linux/smp.h
+++ linux-lazy/include/linux/smp.h
@@ -9,18 +9,12 @@
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/list.h>
+#include <linux/call_single_data.h>
#include <linux/cpumask.h>
extern void cpu_idle(void);
typedef void (*smp_call_func_t)(void *info);
-struct call_single_data {
- struct list_head list;
- smp_call_func_t func;
- void *info;
- u16 flags;
- u16 priv;
-};
/* total number of cpus in this system (may exceed NR_CPUS) */
extern unsigned int total_cpus;
^ permalink raw reply
* [RFC/PATCH 3/7] powerpc: Reorganise powerpc include files to make call_single_data
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20101206234043.083045003@neuling.org>
We need to put struct call_single_data in the powerpc thread_struct,
but can't without this.
In processor.h this moves up the prefetch() functions before the
#include of types.h to ensure __builtin_prefetch doesn't get defined
twice.
Similarly in hw_irq.h move arch_irqs_disabled_flags() to before the
#include of processor.h to ensure it's correctly found when hw_irq.h
has already been included somewhere earlier
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/hw_irq.h | 21 ++++++++------
arch/powerpc/include/asm/processor.h | 52 ++++++++++++++++++-----------------
2 files changed, 40 insertions(+), 33 deletions(-)
Index: linux-lazy/arch/powerpc/include/asm/hw_irq.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/hw_irq.h
+++ linux-lazy/arch/powerpc/include/asm/hw_irq.h
@@ -8,10 +8,6 @@
#include <linux/errno.h>
#include <linux/compiler.h>
-#include <asm/ptrace.h>
-#include <asm/processor.h>
-
-extern void timer_interrupt(struct pt_regs *);
#ifdef CONFIG_PPC64
#include <asm/paca.h>
@@ -81,6 +77,8 @@
#else /* CONFIG_PPC64 */
+#include <asm/reg.h>
+
#define SET_MSR_EE(x) mtmsr(x)
static inline unsigned long arch_local_save_flags(void)
@@ -108,6 +106,16 @@
return flags;
}
+static inline bool arch_irqs_disabled_flags(unsigned long flags)
+{
+ return (flags & MSR_EE) == 0;
+}
+
+#include <asm/ptrace.h>
+#include <asm/processor.h>
+
+extern void timer_interrupt(struct pt_regs *);
+
static inline void arch_local_irq_disable(void)
{
#ifdef CONFIG_BOOKE
@@ -127,11 +135,6 @@
#endif
}
-static inline bool arch_irqs_disabled_flags(unsigned long flags)
-{
- return (flags & MSR_EE) == 0;
-}
-
static inline bool arch_irqs_disabled(void)
{
return arch_irqs_disabled_flags(arch_local_save_flags());
Index: linux-lazy/arch/powerpc/include/asm/processor.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/processor.h
+++ linux-lazy/arch/powerpc/include/asm/processor.h
@@ -20,6 +20,34 @@
#ifndef __ASSEMBLY__
#include <linux/compiler.h>
+
+struct thread_struct;
+
+/*
+ * Prefetch macros.
+ */
+#define ARCH_HAS_PREFETCH
+#define ARCH_HAS_PREFETCHW
+#define ARCH_HAS_SPINLOCK_PREFETCH
+
+static inline void prefetch(const void *x)
+{
+ if (unlikely(!x))
+ return;
+
+ __asm__ __volatile__ ("dcbt 0,%0" : : "r" (x));
+}
+
+static inline void prefetchw(const void *x)
+{
+ if (unlikely(!x))
+ return;
+
+ __asm__ __volatile__ ("dcbtst 0,%0" : : "r" (x));
+}
+
+#define spin_lock_prefetch(x) prefetchw(x)
+
#include <asm/ptrace.h>
#include <asm/types.h>
@@ -327,30 +355,6 @@
int validate_sp(unsigned long sp, struct task_struct *p,
unsigned long nbytes);
-/*
- * Prefetch macros.
- */
-#define ARCH_HAS_PREFETCH
-#define ARCH_HAS_PREFETCHW
-#define ARCH_HAS_SPINLOCK_PREFETCH
-
-static inline void prefetch(const void *x)
-{
- if (unlikely(!x))
- return;
-
- __asm__ __volatile__ ("dcbt 0,%0" : : "r" (x));
-}
-
-static inline void prefetchw(const void *x)
-{
- if (unlikely(!x))
- return;
-
- __asm__ __volatile__ ("dcbtst 0,%0" : : "r" (x));
-}
-
-#define spin_lock_prefetch(x) prefetchw(x)
#ifdef CONFIG_PPC64
#define HAVE_ARCH_PICK_MMAP_LAYOUT
^ permalink raw reply
* [RFC/PATCH 4/7] powerpc: Change fast_exception_return to restore r0, r7. r8, and CTR
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20101206234043.083045003@neuling.org>
Currently we don't restore r0, r7, r8 and CTR in
fast_exception_return. This changes fast_exception_return to restore
these, which were saved anyway on exception entry.
This seems like a bug waiting to happen, plus we do it in hash_page
for 32bit anyway.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/entry_32.S | 4 ++++
arch/powerpc/mm/hash_low_32.S | 7 -------
2 files changed, 4 insertions(+), 7 deletions(-)
Index: linux-lazy/arch/powerpc/kernel/entry_32.S
===================================================================
--- linux-lazy.orig/arch/powerpc/kernel/entry_32.S
+++ linux-lazy/arch/powerpc/kernel/entry_32.S
@@ -720,6 +720,10 @@
#endif
2: REST_4GPRS(3, r11)
+ REST_2GPRS(7, r11)
+ REST_GPR(0, r11)
+ lwz r10,_CTR(r11)
+ mtctr r10
lwz r10,_CCR(r11)
REST_GPR(1, r11)
mtcr r10
Index: linux-lazy/arch/powerpc/mm/hash_low_32.S
===================================================================
--- linux-lazy.orig/arch/powerpc/mm/hash_low_32.S
+++ linux-lazy/arch/powerpc/mm/hash_low_32.S
@@ -146,13 +146,6 @@
li r0,0
stw r0,mmu_hash_lock@l(r8)
#endif
-
- /* Return from the exception */
- lwz r5,_CTR(r11)
- mtctr r5
- lwz r0,GPR0(r11)
- lwz r7,GPR7(r11)
- lwz r8,GPR8(r11)
b fast_exception_return
#ifdef CONFIG_SMP
^ permalink raw reply
* [RFC/PATCH 5/7] powerpc: Enable lazy save VMX registers for SMP
From: Michael Neuling @ 2010-12-06 23:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20101206234043.083045003@neuling.org>
This enables lazy save of VMX registers for SMP configurations.
This adds a pointer to the thread struct to say which CPU holds this
processes VMX register state. On 64 bit, this points to the paca of
the CPU holding the state or NULL if it's in the thread_struct. On 32
bit, this is the CPU number of the CPU holding the state or -1 if it's
in the thread_struct.
It also adds a per cpu pointer (paca on 64bit), which points to the
thread_struct of the process who's state we currently own.
On a context switch we do the following:
- if we are switching to a CPU that currently holds the new processes
state, just turn on VMX in the MSR (this is the lazy/quick case)
- if the new processes state is in the thread_struct, turn VMX off.
- if the new processes state is in someone else's CPU, IPI that CPU
to giveup it's state and turn VMX off.
We always start the new process at this point, irrespective of if we
have the state or not in the thread struct or current CPU.
When we take the VMX unavailable, load_up_altivec checks to see if the
state is now in the thread_struct. If it is, we restore the VMX
registers and start the process. If it's not, we need to wait for the
IPI to finish. Unfortunately, IRQs are off on the current CPU at this
point, so we must turn IRQs on (to avoid a deadlock) before we block
waiting for the IPI to finished on the other CPU.
We also change load_up_altivec to call giveup_altivec to save it's
state rather than duplicating this code. This means that
giveup_altivec can now be called with the MMU on or off, hence we pass
in an offset, which gets subtracted on 32 bit systems on loads and
stores.
For 32bit it's be nice to have last_used_altivec cacheline aligned or
as per_cpu variables but we can't access per_cpu vars in asm
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/include/asm/paca.h | 5
arch/powerpc/include/asm/processor.h | 22 ++
arch/powerpc/include/asm/reg.h | 9 +
arch/powerpc/include/asm/system.h | 10 -
arch/powerpc/kernel/asm-offsets.c | 4
arch/powerpc/kernel/paca.c | 3
arch/powerpc/kernel/process.c | 138 ++++++++++++------
arch/powerpc/kernel/vector.S | 199 ++++++++++++++++++++-------
arch/powerpc/platforms/pseries/hotplug-cpu.c | 1
9 files changed, 288 insertions(+), 103 deletions(-)
Index: linux-lazy/arch/powerpc/include/asm/paca.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/paca.h
+++ linux-lazy/arch/powerpc/include/asm/paca.h
@@ -145,6 +145,11 @@
u64 dtl_ridx; /* read index in dispatch log */
struct dtl_entry *dtl_curr; /* pointer corresponding to dtl_ridx */
+#ifdef CONFIG_ALTIVEC
+ /* lazy save pointers */
+ struct task_struct *last_used_altivec;
+#endif
+
#ifdef CONFIG_KVM_BOOK3S_HANDLER
/* We use this to store guest state in */
struct kvmppc_book3s_shadow_vcpu shadow_vcpu;
Index: linux-lazy/arch/powerpc/include/asm/processor.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/processor.h
+++ linux-lazy/arch/powerpc/include/asm/processor.h
@@ -18,6 +18,16 @@
#define TS_FPRWIDTH 1
#endif
+#ifdef CONFIG_PPC64
+#ifdef __ASSEMBLY__
+#define TS_LAZY_STATE_INVALID 0
+#else
+#define TS_LAZY_STATE_INVALID NULL
+#endif
+#else
+#define TS_LAZY_STATE_INVALID -1
+#endif
+
#ifndef __ASSEMBLY__
#include <linux/compiler.h>
@@ -48,6 +58,7 @@
#define spin_lock_prefetch(x) prefetchw(x)
+#include <linux/call_single_data.h>
#include <asm/ptrace.h>
#include <asm/types.h>
@@ -109,7 +120,6 @@
/* Lazy FPU handling on uni-processor */
extern struct task_struct *last_task_used_math;
-extern struct task_struct *last_task_used_altivec;
extern struct task_struct *last_task_used_vsx;
extern struct task_struct *last_task_used_spe;
@@ -177,6 +187,14 @@
#define TS_VSRLOWOFFSET 1
#define TS_FPR(i) fpr[i][TS_FPROFFSET]
+#ifdef CONFIG_PPC64
+#define TS_LAZY_STATE_TYPE struct paca_struct *
+#define TS_LAZY_STATE_INVALID NULL
+#else
+#define TS_LAZY_STATE_TYPE unsigned long
+#define TS_LAZY_STATE_INVALID -1
+#endif
+
struct thread_struct {
unsigned long ksp; /* Kernel stack pointer */
unsigned long ksp_limit; /* if ksp <= ksp_limit stack overflow */
@@ -253,6 +271,8 @@
/* AltiVec status */
vector128 vscr __attribute__((aligned(16)));
unsigned long vrsave;
+ TS_LAZY_STATE_TYPE vr_state; /* where my vr state is */
+ struct call_single_data vr_csd; /* IPI data structure */
int used_vr; /* set if process has used altivec */
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
Index: linux-lazy/arch/powerpc/include/asm/reg.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/reg.h
+++ linux-lazy/arch/powerpc/include/asm/reg.h
@@ -808,6 +808,15 @@
#define __is_processor(pv) (PVR_VER(mfspr(SPRN_PVR)) == (pv))
+#ifdef CONFIG_PPC64
+#define GET_CURRENT_THREAD(reg) \
+ ld (reg),PACACURRENT(r13) ; \
+ addi (reg),(reg),THREAD
+#else
+#define GET_CURRENT_THREAD(reg) \
+ mfspr (reg),SPRN_SPRG_THREAD
+#endif
+
/*
* IBM has further subdivided the standard PowerPC 16-bit version and
* revision subfields of the PVR for the PowerPC 403s into the following:
Index: linux-lazy/arch/powerpc/include/asm/system.h
===================================================================
--- linux-lazy.orig/arch/powerpc/include/asm/system.h
+++ linux-lazy/arch/powerpc/include/asm/system.h
@@ -7,6 +7,7 @@
#include <linux/kernel.h>
#include <linux/irqflags.h>
+#include <asm/irqflags.h>
#include <asm/hw_irq.h>
/*
@@ -145,7 +146,8 @@
extern void enable_kernel_fp(void);
extern void flush_fp_to_thread(struct task_struct *);
extern void enable_kernel_altivec(void);
-extern void giveup_altivec(struct task_struct *);
+extern void giveup_altivec(unsigned long offset);
+extern void giveup_altivec_ipi(void *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
extern void __giveup_vsx(struct task_struct *);
@@ -157,13 +159,7 @@
extern void cvt_fd(float *from, double *to);
extern void cvt_df(double *from, float *to);
-#ifndef CONFIG_SMP
extern void discard_lazy_cpu_state(void);
-#else
-static inline void discard_lazy_cpu_state(void)
-{
-}
-#endif
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
Index: linux-lazy/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-lazy.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-lazy/arch/powerpc/kernel/asm-offsets.c
@@ -89,6 +89,7 @@
DEFINE(THREAD_VRSAVE, offsetof(struct thread_struct, vrsave));
DEFINE(THREAD_VSCR, offsetof(struct thread_struct, vscr));
DEFINE(THREAD_USED_VR, offsetof(struct thread_struct, used_vr));
+ DEFINE(THREAD_VR_STATE, offsetof(struct thread_struct, vr_state));
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
DEFINE(THREAD_VSR0, offsetof(struct thread_struct, fpr));
@@ -197,6 +198,9 @@
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
+#ifdef CONFIG_ALTIVEC
+ DEFINE(PACA_LAST_USED_ALTIVEC, offsetof(struct paca_struct, last_used_altivec));
+#endif
#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
DEFINE(PACA_KVM_SVCPU, offsetof(struct paca_struct, shadow_vcpu));
DEFINE(SVCPU_SLB, offsetof(struct kvmppc_book3s_shadow_vcpu, slb));
Index: linux-lazy/arch/powerpc/kernel/paca.c
===================================================================
--- linux-lazy.orig/arch/powerpc/kernel/paca.c
+++ linux-lazy/arch/powerpc/kernel/paca.c
@@ -162,6 +162,9 @@
new_paca->hw_cpu_id = 0xffff;
new_paca->kexec_state = KEXEC_STATE_NONE;
new_paca->__current = &init_task;
+#ifdef CONFIG_ALTIVEC
+ new_paca->last_used_altivec = NULL;
+#endif
#ifdef CONFIG_PPC_STD_MMU_64
new_paca->slb_shadow_ptr = &slb_shadow[cpu];
#endif /* CONFIG_PPC_STD_MMU_64 */
Index: linux-lazy/arch/powerpc/kernel/process.c
===================================================================
--- linux-lazy.orig/arch/powerpc/kernel/process.c
+++ linux-lazy/arch/powerpc/kernel/process.c
@@ -59,7 +59,6 @@
#ifndef CONFIG_SMP
struct task_struct *last_task_used_math = NULL;
-struct task_struct *last_task_used_altivec = NULL;
struct task_struct *last_task_used_vsx = NULL;
struct task_struct *last_task_used_spe = NULL;
#endif
@@ -117,14 +116,7 @@
{
WARN_ON(preemptible());
-#ifdef CONFIG_SMP
- if (current->thread.regs && (current->thread.regs->msr & MSR_VEC))
- giveup_altivec(current);
- else
- giveup_altivec(NULL); /* just enable AltiVec for kernel - force */
-#else
- giveup_altivec(last_task_used_altivec);
-#endif /* CONFIG_SMP */
+ giveup_altivec(0);
}
EXPORT_SYMBOL(enable_kernel_altivec);
@@ -134,16 +126,7 @@
*/
void flush_altivec_to_thread(struct task_struct *tsk)
{
- if (tsk->thread.regs) {
- preempt_disable();
- if (tsk->thread.regs->msr & MSR_VEC) {
-#ifdef CONFIG_SMP
- BUG_ON(tsk != current);
-#endif
- giveup_altivec(tsk);
- }
- preempt_enable();
- }
+ giveup_altivec(0);
}
#endif /* CONFIG_ALTIVEC */
@@ -169,7 +152,7 @@
void giveup_vsx(struct task_struct *tsk)
{
giveup_fpu(tsk);
- giveup_altivec(tsk);
+ giveup_altivec(0);
__giveup_vsx(tsk);
}
@@ -220,7 +203,6 @@
}
#endif /* CONFIG_SPE */
-#ifndef CONFIG_SMP
/*
* If we are doing lazy switching of CPU state (FP, altivec or SPE),
* and the current task has some state, discard it.
@@ -228,12 +210,12 @@
void discard_lazy_cpu_state(void)
{
preempt_disable();
- if (last_task_used_math == current)
- last_task_used_math = NULL;
#ifdef CONFIG_ALTIVEC
- if (last_task_used_altivec == current)
- last_task_used_altivec = NULL;
+ giveup_altivec(0);
#endif /* CONFIG_ALTIVEC */
+#ifndef CONFIG_SMP
+ if (last_task_used_math == current)
+ last_task_used_math = NULL;
#ifdef CONFIG_VSX
if (last_task_used_vsx == current)
last_task_used_vsx = NULL;
@@ -242,9 +224,9 @@
if (last_task_used_spe == current)
last_task_used_spe = NULL;
#endif
+#endif /* CONFIG_SMP */
preempt_enable();
}
-#endif /* CONFIG_SMP */
#ifdef CONFIG_PPC_ADV_DEBUG_REGS
void do_send_trap(struct pt_regs *regs, unsigned long address,
@@ -386,6 +368,78 @@
#ifdef CONFIG_PPC64
DEFINE_PER_CPU(struct cpu_usage, cpu_usage_array);
#endif
+#ifdef CONFIG_PPC64
+#define LAZY_STATE_HERE (get_paca())
+#define LAZY_STATE_CPU_ID (state->hw_cpu_id)
+#else
+#define LAZY_STATE_HERE (smp_processor_id())
+#define LAZY_STATE_CPU_ID (state)
+#endif
+
+extern int csd_locked(struct call_single_data *data);
+
+#ifdef CONFIG_ALTIVEC
+/* Return value indicates if it was lazy or not */
+static bool switch_to_altivec_lazy(struct task_struct *prev,
+ struct task_struct *new)
+{
+ /*
+ * At this point the Altivec reg state can be in 1 of 3 places
+ * 1) cached on _this_ CPU. Lazy/fast :-)
+ * 2) in the thread_struct. Normal :-|
+ * 3) cached on another CPU. Slow IPI :-(
+ * .... lets go workout what happened....
+ */
+
+ /* Cache the state pointer here incase it changes */
+ TS_LAZY_STATE_TYPE state = new->thread.vr_state;
+
+ /* Is the state here? */
+ if (state == LAZY_STATE_HERE) {
+ /* It's here! Excellent, simply turn VMX on */
+ new->thread.regs->msr |= MSR_VEC;
+ return true;
+ }
+ /*
+ * If we have used VMX in the past, but don't have lazy state,
+ * then make sure we turn off VMX. load_up_altivec will deal
+ * with saving the lazy state if we run a VMX instruction
+ */
+ new->thread.regs->msr &= ~MSR_VEC;
+
+ if (state != TS_LAZY_STATE_INVALID) {
+#ifdef CONFIG_SMP
+ /*
+ * To avoid a deadlock, make sure we don't
+ * have someone else state here
+ */
+ discard_lazy_cpu_state();
+
+ /*
+ * Get the other CPU to flush it's state
+ * synchronously. It's possible this may may get run
+ * multiple times, but giveup_altivec can handle this.
+ */
+ if (!csd_locked(&(new->thread.vr_csd)))
+ __smp_call_function_single(
+ LAZY_STATE_CPU_ID,
+ &(new->thread.vr_csd),
+ 0);
+#else /* CONFIG_SMP */
+ /* UP can't have state on another CPU */
+ BUG();
+#endif
+
+ }
+ return false;
+}
+#else /* CONFIG_ALTIVEC */
+static bool switch_to_altivec_lazy(struct task_struct *prev,
+ struct task_struct *new)
+{
+ return true;
+}
+#endif /* CONFIG_ALTIVEC */
struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *new)
@@ -393,6 +447,12 @@
struct thread_struct *new_thread, *old_thread;
unsigned long flags;
struct task_struct *last;
+ int lazy = 1;
+
+ /* Does next have lazy state somewhere? */
+ if (new->thread.regs) {
+ lazy &= switch_to_altivec_lazy(prev, new);
+ }
#ifdef CONFIG_SMP
/* avoid complexity of lazy save/restore of fpu
@@ -406,21 +466,6 @@
*/
if (prev->thread.regs && (prev->thread.regs->msr & MSR_FP))
giveup_fpu(prev);
-#ifdef CONFIG_ALTIVEC
- /*
- * If the previous thread used altivec in the last quantum
- * (thus changing altivec regs) then save them.
- * We used to check the VRSAVE register but not all apps
- * set it, so we don't rely on it now (and in fact we need
- * to save & restore VSCR even if VRSAVE == 0). -- paulus
- *
- * On SMP we always save/restore altivec regs just to avoid the
- * complexity of changing processors.
- * -- Cort
- */
- if (prev->thread.regs && (prev->thread.regs->msr & MSR_VEC))
- giveup_altivec(prev);
-#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
if (prev->thread.regs && (prev->thread.regs->msr & MSR_VSX))
/* VMX and FPU registers are already save here */
@@ -439,13 +484,6 @@
#endif /* CONFIG_SPE */
#else /* CONFIG_SMP */
-#ifdef CONFIG_ALTIVEC
- /* Avoid the trap. On smp this this never happens since
- * we don't set last_task_used_altivec -- Cort
- */
- if (new->thread.regs && last_task_used_altivec == new)
- new->thread.regs->msr |= MSR_VEC;
-#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_VSX
if (new->thread.regs && last_task_used_vsx == new)
new->thread.regs->msr |= MSR_VSX;
@@ -862,6 +900,10 @@
current->thread.vscr.u[3] = 0x00010000; /* Java mode disabled */
current->thread.vrsave = 0;
current->thread.used_vr = 0;
+ current->thread.vr_state = TS_LAZY_STATE_INVALID;
+ current->thread.vr_csd.func = giveup_altivec_ipi;
+ current->thread.vr_csd.info = 0;
+ current->thread.vr_csd.flags = 0;
#endif /* CONFIG_ALTIVEC */
#ifdef CONFIG_SPE
memset(current->thread.evr, 0, sizeof(current->thread.evr));
Index: linux-lazy/arch/powerpc/kernel/vector.S
===================================================================
--- linux-lazy.orig/arch/powerpc/kernel/vector.S
+++ linux-lazy/arch/powerpc/kernel/vector.S
@@ -5,7 +5,29 @@
#include <asm/cputable.h>
#include <asm/thread_info.h>
#include <asm/page.h>
+#include <asm/exception-64s.h>
+#include <linux/threads.h>
+#ifdef CONFIG_PPC32
+ .section .bss
+ .align 4
+last_used_altivec:
+ .space 4*NR_CPUS
+ .previous
+/*
+ * Get the last_used_altivec pointer for this cpu.
+ * Pointer ends up in register n. offset in a, volotile scratch in b
+ */
+#define LAST_USED_ALTIVEC_PTR(n, a, b) \
+ rlwinm b,r1,0,0,(31-THREAD_SHIFT) ; \
+ sub b,b,a ; \
+ lwz b,TI_CPU(b) ; \
+ slwi b,b,2 ; \
+ lis n,last_used_altivec@ha ; \
+ addi n,n,last_used_altivec@l ; \
+ sub n,n,b ; \
+ add n,n,b
+#endif
/*
* load_up_altivec(unused, unused, tsk)
* Disable VMX for the task which had it previously,
@@ -20,38 +42,98 @@
MTMSRD(r5) /* enable use of AltiVec now */
isync
+ mflr r10
+#ifdef CONFIG_PPC32
+ lis r3, PAGE_OFFSET@h
+#endif
+ bl giveup_altivec_msr_done
/*
- * For SMP, we don't do lazy VMX switching because it just gets too
- * horrendously complex, especially when a task switches from one CPU
- * to another. Instead we call giveup_altvec in switch_to.
- * VRSAVE isn't dealt with here, that is done in the normal context
- * switch code. Note that we could rely on vrsave value to eventually
- * avoid saving all of the VREGs here...
+ * lazy restore:
+ * If we are doing lazy restore we enter here either:
+ * 1. never done vmx before
+ * 2. done vmx and state is in our thread_struct
+ * 3. done vmx and but state is being flushed via an IPI
*/
-#ifndef CONFIG_SMP
- LOAD_REG_ADDRBASE(r3, last_task_used_altivec)
- toreal(r3)
- PPC_LL r4,ADDROFF(last_task_used_altivec)(r3)
- PPC_LCMPI 0,r4,0
- beq 1f
+ GET_CURRENT_THREAD(r5)
+ lwz r4,THREAD_USED_VR(r5)
+ PPC_LCMPI cr0,r4,0 /* we've not used vmx before */
+ beq 4f
+
+ /*
+ * Spin here waiting for IPI to finish. Once the data is in
+ * our thread_struct, vr_state will be null:
+ *
+ * First quickly check to see if data has been flushed from
+ * another CPU yet (as it's likely the IPI has completed)
+ */
+5:
+ PPC_LL r4,THREAD_VR_STATE(r5)
+ PPC_LCMPI 0,r4,TS_LAZY_STATE_INVALID
+ beq+ 3f /* it's likely the data is already here */
+ /*
+ * Bugger, the IPI has not completed. Let's spin here waiting
+ * for it, but we should turn on IRQ incase someone is wait for
+ * us for something.
+ */
- /* Save VMX state to last_task_used_altivec's THREAD struct */
- toreal(r4)
- addi r4,r4,THREAD
- SAVE_32VRS(0,r5,r4)
- mfvscr vr0
- li r10,THREAD_VSCR
- stvx vr0,r10,r4
- /* Disable VMX for last_task_used_altivec */
- PPC_LL r5,PT_REGS(r4)
- toreal(r5)
- PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
- lis r10,MSR_VEC@h
- andc r4,r4,r10
- PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
-1:
-#endif /* CONFIG_SMP */
+ /* Enable IRQs */
+#ifdef CONFIG_PPC32
+ mfmsr r4
+ rlwimi r4,r9,0,MSR_EE
+ MTMSRD(r4)
+#else
+ ENABLE_INTS
+#endif
+2:
+ /* Wait for lazy state to appear */
+ PPC_LL r4,THREAD_VR_STATE(r5)
+ PPC_LCMPI 0,r4,TS_LAZY_STATE_INVALID
+ bne 2b
+ /* disable irqs and enable vec again */
+#ifdef CONFIG_PPC32
+ mfmsr r4
+ oris r4,r4,MSR_VEC@h
+ xori r4,r4,MSR_EE
+ MTMSRD(r4)
+#else
+ mfmsr r11
+ oris r11,r11,MSR_VEC@h
+ xori r11,r11,MSR_EE
+ MTMSRD(r11)
+#endif
+ /*
+ * make sure we didn't pickup someones state while we had IRQs
+ * on
+ */
+#ifdef CONFIG_PPC32
+ lis r3, PAGE_OFFSET@h
+#endif
+ bl giveup_altivec_msr_done
+3:
+ LWSYNC /* make sure VMX registers are in memory */
+4:
+ mtlr r10
+ /* setup lazy pointers */
+ GET_CURRENT_THREAD(r5)
+#ifdef CONFIG_PPC64
+ PPC_STL r13,THREAD_VR_STATE(r5)
+#else
+ /* get the cpuid */
+ lis r6,PAGE_OFFSET@h
+ rlwinm r7,r1,0,0,(31-THREAD_SHIFT)
+ sub r7,r7,r6
+ lwz r7,TI_CPU(r7)
+ PPC_STL r7,THREAD_VR_STATE(r5) /* write the cpuid */
+#endif
+ subi r4, r5, THREAD
+#ifdef CONFIG_PPC64
+ PPC_STL r4,PACA_LAST_USED_ALTIVEC(r13)
+#else
+/* lis r6,PAGE_OFFSET@h */
+ LAST_USED_ALTIVEC_PTR(r3, r6, r7)
+ PPC_STL r4,0(r3)
+#endif
/* Hack: if we get an altivec unavailable trap with VRSAVE
* set to all zeros, we assume this is a broken application
* that fails to set it properly, and thus we switch it to
@@ -65,11 +147,8 @@
1:
/* enable use of VMX after return */
#ifdef CONFIG_PPC32
- mfspr r5,SPRN_SPRG_THREAD /* current task's THREAD (phys) */
oris r9,r9,MSR_VEC@h
#else
- ld r4,PACACURRENT(r13)
- addi r5,r4,THREAD /* Get THREAD */
oris r12,r12,MSR_VEC@h
std r12,_MSR(r1)
#endif
@@ -79,29 +158,41 @@
lvx vr0,r10,r5
mtvscr vr0
REST_32VRS(0,r4,r5)
-#ifndef CONFIG_SMP
- /* Update last_task_used_altivec to 'current' */
- subi r4,r5,THREAD /* Back to 'current' */
- fromreal(r4)
- PPC_STL r4,ADDROFF(last_task_used_altivec)(r3)
-#endif /* CONFIG_SMP */
/* restore registers and return */
blr
-
/*
- * giveup_altivec(tsk)
- * Disable VMX for the task given as the argument,
- * and save the vector registers in its thread_struct.
+ * giveup_altivec(offset)
+ * Disable VMX for the task currently using vmx and and save the
+ * vector registers in its thread_struct.
* Enables the VMX for use in the kernel on return.
*/
+_GLOBAL(giveup_altivec_ipi)
_GLOBAL(giveup_altivec)
mfmsr r5
oris r5,r5,MSR_VEC@h
SYNC
MTMSRD(r5) /* enable use of VMX now */
isync
+
+giveup_altivec_msr_done:
+#ifdef CONFIG_PPC64
+ PPC_LL r3,PACA_LAST_USED_ALTIVEC(r13)
+#else
+ mr r7, r3
+ LAST_USED_ALTIVEC_PTR(r4, r7, r5)
+ PPC_LL r3,0(r4) /* phys address */
+#endif
PPC_LCMPI 0,r3,0
- beqlr- /* if no previous owner, done */
+ beqlr /* if no previous owner, done */
+#ifdef CONFIG_PPC32
+ /* turn phys address into phys or virt based on offset */
+ lis r6,PAGE_OFFSET@h
+ sub r6, r6, r7
+ add r3, r3, r6
+#endif
+2:
+ /* Save state to the thread struct */
+ mr r6,r3
addi r3,r3,THREAD /* want THREAD of task */
PPC_LL r5,PT_REGS(r3)
PPC_LCMPI 0,r5,0
@@ -110,6 +201,9 @@
li r4,THREAD_VSCR
stvx vr0,r4,r3
beq 1f
+#ifdef CONFIG_PPC32
+ sub r5, r5, r7
+#endif
PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
#ifdef CONFIG_VSX
BEGIN_FTR_SECTION
@@ -120,14 +214,25 @@
#else
lis r3,MSR_VEC@h
#endif
- andc r4,r4,r3 /* disable FP for previous task */
+ andc r4,r4,r3 /* disable vmx for previous task */
PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5)
1:
-#ifndef CONFIG_SMP
+ /*
+ * If this is an ipi, make sure state is is commited before we
+ * clear the lazy state pointers and return. If a CPU is waiting on
+ * this data (IPI case) then it won't start until VR_STATE is cleared
+ */
+ LWSYNC /* make sure registers are in mem before say they are */
+ li r5,TS_LAZY_STATE_INVALID
+ PPC_STL r5,THREAD+THREAD_VR_STATE(r6)
li r5,0
- LOAD_REG_ADDRBASE(r4,last_task_used_altivec)
- PPC_STL r5,ADDROFF(last_task_used_altivec)(r4)
-#endif /* CONFIG_SMP */
+#ifdef CONFIG_PPC64
+ PPC_STL r5,PACA_LAST_USED_ALTIVEC(r13)
+#else
+ LAST_USED_ALTIVEC_PTR(r3, r7, r4)
+ PPC_STL r5,0(r3)
+#endif
+ LWSYNC
blr
#ifdef CONFIG_VSX
Index: linux-lazy/arch/powerpc/platforms/pseries/hotplug-cpu.c
===================================================================
--- linux-lazy.orig/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ linux-lazy/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -112,6 +112,7 @@
local_irq_disable();
idle_task_exit();
+ discard_lazy_cpu_state();
xics_teardown_cpu();
if (get_preferred_offline_state(cpu) == CPU_STATE_INACTIVE) {
^ 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