* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Timur Tabi @ 2013-02-02 20:24 UTC (permalink / raw)
To: Stef van Os; +Cc: Scott Wood, linuxppc-dev, Paul Mackerras
In-Reply-To: <510D6819.7050002@prodrive.nl>
On Sat, Feb 2, 2013 at 1:25 PM, Stef van Os <stef.van.os@prodrive.nl> wrote:
>> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
>> don't want PCI. Maybe PCI and srio should be moved out of that file, or
>> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
>>
> I went with timur's solution, patch v2 uses mpc8548si-post.dtsi and
> mpc8548si-pre.dtsi again, disabling everything that is not on the board.
FYI, someone posted some patches for dtc a couple months ago that
added an option to strip out disabled nodes when compiling the dts,
but those patches were rejected. In your case, those patches could
significantly reduce the size of the compiled dtb.
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-02 20:15 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <20130202145801.GB1434@kroah.com>
On Saturday, February 02, 2013 03:58:01 PM Greg KH wrote:
> On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> > On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > > > them, or give me a _really_ good reason why they will not work.
> > > > >
> > > > > We cannot use the existing system devices or ACPI devices here. During
> > > > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > > > device information in a platform-neutral way. During hot-add, we first
> > > > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > > > but platform-neutral modules cannot use them as they are ACPI-specific.
> > > >
> > > > But suppose we're smart and have ACPI scan handlers that will create
> > > > "physical" device nodes for those devices during the ACPI namespace scan.
> > > > Then, the platform-neutral nodes will be able to bind to those "physical"
> > > > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > > > this way that will reflect all of the dependencies we need to take into
> > > > account during hot-add and hot-remove operations. That may not be what we
> > > > have today, but I don't see any *fundamental* obstacles preventing us from
> > > > using this approach.
> > >
> > > I would _much_ rather see that be the solution here as I think it is the
> > > proper one.
> > >
> > > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > >
> > > I agree.
> > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > I say do what we always have done here, if the user asked us to tear
> > > something down, let it happen as they are the ones that know best :)
> > >
> > > Seriously, I guess this gets back to the "fail disconnect" idea that the
> > > ACPI developers keep harping on. I thought we already resolved this
> > > properly by having them implement it in their bus code, no reason the
> > > same thing couldn't happen here, right?
> >
> > Not really. :-) We haven't ever resolved that particular issue I'm afraid.
>
> Ah, I didn't realize that.
>
> > > I don't think the core needs to do anything special, but if so, I'll be glad
> > > to review it.
> >
> > OK, so this is the use case. We have "eject" defined for something like
> > a container with a number of CPU cores, PCI host bridge, and a memory
> > controller under it. And a few pretty much arbitrary I/O devices as a bonus.
> >
> > Now, there's a button on the system case labeled as "Eject" and if that button
> > is pressed, we're supposed to _try_ to eject all of those things at once. We
> > are allowed to fail that request, though, if that's problematic for some
> > reason, but we're supposed to let the BIOS know about that.
> >
> > Do you seriously think that if that button is pressed, we should just proceed
> > with removing all that stuff no matter what? That'd be kind of like Russian
> > roulette for whoever pressed that button, because s/he could only press it and
> > wait for the system to either crash or not. Or maybe to crash a bit later
> > because of some delayed stuff that would hit one of those devices that had just
> > gone. Surely not a situation any admin of a high-availability system would
> > like to be in. :-)
> >
> > Quite frankly, I have no idea how that can be addressed in a single bus type,
> > let alone ACPI (which is not even a proper bus type, just something pretending
> > to be one).
>
> You don't have it as a single bus type, you have a controller somewhere,
> off of the bus being destroyed, that handles sending remove events to
> the device and tearing everything down. PCI does this from the very
> beginning.
Yes, but those are just remove events and we can only see how destructive they
were after the removal. The point is to be able to figure out whether or not
we *want* to do the removal in the first place.
Say you have a computing node which signals a hardware problem in a processor
package (the container with CPU cores, memory, PCI host bridge etc.). You
may want to eject that package, but you don't want to kill the system this
way. So if the eject is doable, it is very much desirable to do it, but if it
is not doable, you'd rather shut the box down and do the replacement afterward.
That may be costly, however (maybe weeks of computations), so it should be
avoided if possible, but not at the expense of crashing the box if the eject
doesn't work out.
> I know it's more complicated with these types of devices, and I think we
> are getting closer to the correct solution, I just don't want to ever
> see duplicate devices in the driver model for the same physical device.
Do you mean two things based on struct device for the same hardware component?
That's been happening already pretty much forever for every PCI device known
to the ACPI layer, for PNP and many others. However, those ACPI things are (or
rather should be, but we're going to clean that up) only for convenience (to be
able to see the namespace structure and related things in sysfs). So the stuff
under /sys/devices/LNXSYSTM\:00/ is not "real". In my view it shouldn't even
be under /sys/devices/ (/sys/firmware/acpi/ seems to be a better place for it),
but that may be difficult to change without breaking user space (maybe we can
just symlink it from /sys/devices/ or something). And the ACPI bus type
shouldn't even exist in my opinion.
There's much confusion in there and much work to clean that up, I agree, but
that's kind of separate from the hotplug thing.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Stef van Os @ 2013-02-02 19:25 UTC (permalink / raw)
To: Scott Wood; +Cc: Paul Mackerras, linuxppc-dev, timur.tabi
In-Reply-To: <1359765063.23561.14@snotra>
Thanks for the comment!
On 02/02/2013 01:31 AM, Scott Wood wrote:
> On 02/01/2013 09:36:53 AM, Stef van Os wrote:
>> + memory {
>> + device_type = "memory";
>> + reg = <0 0 0x0 0x40000000>;
>> + };
>
> You have a "filled in by U-Boot" comment elsewhere in the file, but
> you aren't letting U-Boot fill in the memory size?
>
The U-Boot used in this board currently does not call the
fdt_fixup_memory function. Would have been better, but changing it now
requires production image changes and requalification.
>> + board_lbc: lbc: localbus@fe0005000 {
>> + reg = <0xf 0xe0005000 0 0x1000>;
>> + ranges = <0x0 0x0 0xf 0xff800000 0x00800000>;
>> + };
>> +
>> + board_soc: soc: soc8548@fe0000000 {
>> + ranges = <0 0xf 0xe0000000 0x100000>;
>> + };
>
> I know some existing dts files do this, but there's no need for two
> labels one one node.
True, fixed in v2 of patch.
>
>> + rio: rapidio@fe00c0000 {
>> + reg = <0xf 0xe00c0000 0x0 0x11000>;
>> + port1 {
>> + ranges = <0x0 0x0 0x0 0x80000000 0x0 0x40000000>;
>> + };
>> + };
>> +};
>> +
>> +&lbc {
>> + #address-cells = <2>;
>> + #size-cells = <1>;
>> + compatible = "fsl,mpc8548-lbc", "fsl,pq3-localbus", "simple-bus";
>> + interrupts = <19 2 0 0>;
>> +};
>> +
>> +&rio {
>> + compatible = "fsl,srio";
>> + interrupts = <48 2 0 0>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + fsl,srio-rmu-handle = <&rmu>;
>> + ranges;
>> +
>> + port1 {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + cell-index = <1>;
>> + };
>> +};
>> +
>> +&soc {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + device_type = "soc";
>> + compatible = "fsl,mpc8548-immr", "simple-bus";
>> + bus-frequency = <0>; // Filled out by uboot.
>> +
>> + ecm-law@0 {
>> + compatible = "fsl,ecm-law";
>> + reg = <0x0 0x1000>;
>> + fsl,num-laws = <10>;
>> + };
>> +
>> + ecm@1000 {
>> + compatible = "fsl,mpc8548-ecm", "fsl,ecm";
>> + reg = <0x1000 0x1000>;
>> + interrupts = <17 2 0 0>;
>> + };
>> +
>> + memory-controller@2000 {
>> + compatible = "fsl,mpc8548-memory-controller";
>> + reg = <0x2000 0x1000>;
>> + interrupts = <18 2 0 0>;
>> + };
>> +
>> +/include/ "fsl/pq3-i2c-0.dtsi"
>> +/include/ "fsl/pq3-i2c-1.dtsi"
>> +/include/ "fsl/pq3-duart-0.dtsi"
>> +
>> + L2: l2-cache-controller@20000 {
>> + compatible = "fsl,mpc8548-l2-cache-controller";
>> + reg = <0x20000 0x1000>;
>> + cache-line-size = <32>; // 32 bytes
>> + cache-size = <0x80000>; // L2, 512K
>> + interrupts = <16 2 0 0>;
>> + };
>> +
>> +/include/ "fsl/pq3-dma-0.dtsi"
>> +/include/ "fsl/pq3-etsec1-0.dtsi"
>> +/include/ "fsl/pq3-etsec1-1.dtsi"
>> +/include/ "fsl/pq3-etsec1-2.dtsi"
>> +/include/ "fsl/pq3-etsec1-3.dtsi"
>> +
>> +/include/ "fsl/pq3-sec2.1-0.dtsi"
>> +/include/ "fsl/pq3-mpic.dtsi"
>> +/include/ "fsl/pq3-rmu-0.dtsi"
>> +
>> + global-utilities@e0000 {
>> + compatible = "fsl,mpc8548-guts";
>> + reg = <0xe0000 0x1000>;
>> + fsl,has-rstcr;
>> + };
>> +};
>
> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that
> you don't want PCI. Maybe PCI and srio should be moved out of that
> file, or ifdeffed if 85xx ever ends up using the preprocessor for its
> device trees.
>
I went with timur's solution, patch v2 uses mpc8548si-post.dtsi and
mpc8548si-pre.dtsi again, disabling everything that is not on the board.
>> diff --git a/arch/powerpc/platforms/85xx/ppa8548.c
>> b/arch/powerpc/platforms/85xx/ppa8548.c
>> new file mode 100644
>> index 0000000..80a9307
>> --- /dev/null
>> +++ b/arch/powerpc/platforms/85xx/ppa8548.c
>> @@ -0,0 +1,119 @@
>> +/*
>> + * ppa8548 setup and early boot code.
>> + *
>> + * Copyright 2009 Prodrive B.V..
>> + *
>> + * By Stef van Os (see MAINTAINERS for contact information)
>> + *
>> + * Based on the SBC8548 support - Copyright 2007 Wind River Systems
>> Inc.
>> + * Based on the MPC8548CDS support - Copyright 2005 Freescale Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify it
>> + * under the terms of the GNU General Public License as published
>> by the
>> + * Free Software Foundation; either version 2 of the License, or
>> (at your
>> + * option) any later version.
>> + */
>> +
>> +#include <linux/stddef.h>
>> +#include <linux/kernel.h>
>> +#include <linux/init.h>
>> +#include <linux/errno.h>
>> +#include <linux/reboot.h>
>> +#include <linux/kdev_t.h>
>> +#include <linux/major.h>
>> +#include <linux/console.h>
>> +#include <linux/delay.h>
>> +#include <linux/seq_file.h>
>> +#include <linux/initrd.h>
>> +#include <linux/module.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/fsl_devices.h>
>> +#include <linux/of_platform.h>
>> +
>> +#include <asm/pgtable.h>
>> +#include <asm/page.h>
>> +#include <asm/atomic.h>
>> +#include <asm/time.h>
>> +#include <asm/io.h>
>> +#include <asm/machdep.h>
>> +#include <asm/ipic.h>
>> +#include <asm/irq.h>
>> +#include <mm/mmu_decl.h>
>> +#include <asm/prom.h>
>> +#include <asm/udbg.h>
>> +#include <asm/mpic.h>
>> +
>> +#include <sysdev/fsl_soc.h>
>
> I doubt you need all of these.
>
> E.g. asm/ipic.h is for 83xx and 512x chips. Some others are for
> things that haven't been done by board files for years (e.g. kdev_t.h).
Fixed in v2, 10 includes left, instead of 25+...
>
>> +static void ppa8548_show_cpuinfo(struct seq_file *m)
>> +{
>> + uint pvid, svid, phid1;
>> +
>> + pvid = mfspr(SPRN_PVR);
>> + svid = mfspr(SPRN_SVR);
>> +
>> + seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
>> + seq_printf(m, "Machine\t\t: ppa8548\n");
>> + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
>> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
>> +
>> + /* Display cpu Pll setting */
>> + phid1 = mfspr(SPRN_HID1);
>> + seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
>> +}
>
> PVR and ppc_md.name are already shown by the generic /proc/cpuinfo code.
>
> -Scott
Fixed, removed PVR and Machine. SVR is still shown, because it is not in
generic cpuinfo code.
Will do a test run of the changes and send out v2 later this weekend.
Regards,
Stef
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Greg KH @ 2013-02-02 15:01 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <1359751210.15120.278.camel@misato.fc.hp.com>
On Fri, Feb 01, 2013 at 01:40:10PM -0700, Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > > A. Proceed within system device bus scan.
> > > B. Proceed within ACPI bus scan.
> > > C. Proceed with a sequence (as a mini-boot).
> > >
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > >
> > > Here is summary of key questions & answers so far. I hope this
> > > clarifies why I am suggesting option 3.
> > >
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system. System devices are not
> > > connected to any particular standard buses.
> >
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses". All this means is that system devices are connected
> > to the "system" bus, nothing more.
>
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses? I will investigate them to
> see how they are managed to support hotplug.
Any device that is attached to any bus in the driver model can be
hotunplugged from userspace by telling it to be "unbound" from the
driver controlling it. Try it for any platform device in your system to
see how it happens.
> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > provide low-level services to enable other subsystems to come up.
> >
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
>
> I think system devices are unique in a sense that they are initialized
> before drivers run.
No, most all devices are "initialized" before a driver runs on it, USB
is one such example, PCI another, and I'm pretty sure that there are
others.
> > If you need to initialize the driver
> > core earlier, then do so. Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
>
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory. They do not actually initialize cpu and memory. I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.
We already represent CPUs in the sysfs tree, don't represent them in two
different places with two different structures. Use the existing ones
please.
> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
>
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug. I tried to say
> that this option would not be doable.
I haven't yet been convinced otherwise, sorry. Please prove me wrong :)
thanks,
greg k-h
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Greg KH @ 2013-02-02 14:58 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <1987042.JQv02Zsfg5@vostro.rjw.lan>
On Fri, Feb 01, 2013 at 11:12:59PM +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> > On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > > them, or give me a _really_ good reason why they will not work.
> > > >
> > > > We cannot use the existing system devices or ACPI devices here. During
> > > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > > device information in a platform-neutral way. During hot-add, we first
> > > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > > but platform-neutral modules cannot use them as they are ACPI-specific.
> > >
> > > But suppose we're smart and have ACPI scan handlers that will create
> > > "physical" device nodes for those devices during the ACPI namespace scan.
> > > Then, the platform-neutral nodes will be able to bind to those "physical"
> > > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > > this way that will reflect all of the dependencies we need to take into
> > > account during hot-add and hot-remove operations. That may not be what we
> > > have today, but I don't see any *fundamental* obstacles preventing us from
> > > using this approach.
> >
> > I would _much_ rather see that be the solution here as I think it is the
> > proper one.
> >
> > > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> >
> > I agree.
> >
> > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > when we try do eject a device at the top of a subtree and need to tear down
> > > the entire subtree below it, but if that's going to lead to a system crash,
> > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > help from the driver core here.
> >
> > I say do what we always have done here, if the user asked us to tear
> > something down, let it happen as they are the ones that know best :)
> >
> > Seriously, I guess this gets back to the "fail disconnect" idea that the
> > ACPI developers keep harping on. I thought we already resolved this
> > properly by having them implement it in their bus code, no reason the
> > same thing couldn't happen here, right?
>
> Not really. :-) We haven't ever resolved that particular issue I'm afraid.
Ah, I didn't realize that.
> > I don't think the core needs to do anything special, but if so, I'll be glad
> > to review it.
>
> OK, so this is the use case. We have "eject" defined for something like
> a container with a number of CPU cores, PCI host bridge, and a memory
> controller under it. And a few pretty much arbitrary I/O devices as a bonus.
>
> Now, there's a button on the system case labeled as "Eject" and if that button
> is pressed, we're supposed to _try_ to eject all of those things at once. We
> are allowed to fail that request, though, if that's problematic for some
> reason, but we're supposed to let the BIOS know about that.
>
> Do you seriously think that if that button is pressed, we should just proceed
> with removing all that stuff no matter what? That'd be kind of like Russian
> roulette for whoever pressed that button, because s/he could only press it and
> wait for the system to either crash or not. Or maybe to crash a bit later
> because of some delayed stuff that would hit one of those devices that had just
> gone. Surely not a situation any admin of a high-availability system would
> like to be in. :-)
>
> Quite frankly, I have no idea how that can be addressed in a single bus type,
> let alone ACPI (which is not even a proper bus type, just something pretending
> to be one).
You don't have it as a single bus type, you have a controller somewhere,
off of the bus being destroyed, that handles sending remove events to
the device and tearing everything down. PCI does this from the very
beginning.
I know it's more complicated with these types of devices, and I think we
are getting closer to the correct solution, I just don't want to ever
see duplicate devices in the driver model for the same physical device.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Timur Tabi @ 2013-02-02 12:31 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <20130202130201.204ee2fd@crub>
Anatolij Gustschin wrote:
>>> +struct mpc512x_lpc {
>>> + u32 cs_cfg[8]; /* CS config */
>>> + u32 cs_ctrl; /* CS Control Register */
>>> + u32 cs_status; /* CS Status Register */
>>> + u32 burst_ctrl; /* CS Burst Control Register */
>>> + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
>>> + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
>>> + u32 alt; /* Address Latch Timing Register */
>>> +};
>>
>> These should be __be32.
>
> Why? To add a new bunch of sparse warnings?
Hmm... I thought that making them __be32 will *avoid* sparse warnings.
>> You forgot the iounmap() if lpc == NULL.
>
> No, it is intentional, no need to map/unmap again and again for all
> subsequent calls.
Sorry, for some reason I thought that lpc was a parameter that you passed in.
--
Timur Tabi
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Anatolij Gustschin @ 2013-02-02 12:02 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <CAOZdJXUfe5KWBtabUUPrGHhcFb6dbnPNJCsU23yoxb-4GeKQsg@mail.gmail.com>
On Fri, 1 Feb 2013 22:31:51 -0600
Timur Tabi <timur@tabi.org> wrote:
> On Fri, Feb 1, 2013 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> > Add ability to configure CS parameters for devices that need
> > different CS parameters setup after their configuration. I.e.
> > an FPGA device on LP bus can require different CS parameters
> > for its bus interface after loading firmware into it. A driver
> > can easily reconfigure the LPC CS parameters using this function.
>
> Could you define "CS" somewhere?
I'll define it in revised commit log in v2.
> > +struct mpc512x_lpc {
> > + u32 cs_cfg[8]; /* CS config */
> > + u32 cs_ctrl; /* CS Control Register */
> > + u32 cs_status; /* CS Status Register */
> > + u32 burst_ctrl; /* CS Burst Control Register */
> > + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
> > + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
> > + u32 alt; /* Address Latch Timing Register */
> > +};
>
> These should be __be32.
Why? To add a new bunch of sparse warnings?
...
> > + if (cs < 0 || cs > 7)
> > + return -EINVAL;
>
> If you make cs an unsigned int, you won't need to test for < 0.
can do that, yes.
> > +
> > + if (!lpc) {
> > + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
> > + lpc = of_iomap(np, 0);
> > + of_node_put(np);
> > + if (!lpc)
> > + return -ENOMEM;
> > + }
> > +
> > + out_be32(&lpc->cs_cfg[cs], val);
>
> You forgot the iounmap() if lpc == NULL.
No, it is intentional, no need to map/unmap again and again for all
subsequent calls.
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(mpc512x_cs_config);
>
> EXPORT_SYMBOL, please, to match the rest of the Freescale platforms.
I'll change it in v2. Thanks!
Anatolij
^ permalink raw reply
* AW: Why is the e500v2 core not using cpuidle?
From: Thomas Waldecker @ 2013-02-02 9:41 UTC (permalink / raw)
To: Scott Wood; +Cc: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
In-Reply-To: <1359742517.23561.2@snotra>
Hi Scott,=0A=
=0A=
>> Why is there no support for the cpuidle framework?=0A=
> Because nobody implemented it. :-)=0A=
That's the reason I thought before :-)=0A=
=0A=
> The only reason I can think of to implement it on this chip would be to=
=0A=
> dynamically choose when to enter nap versus doze, rather than always=0A=
> just using doze. It's not clear whether the difference in power=0A=
> savings is worth it -- do you have any way of measuring?=0A=
=0A=
Is the e500 only using doze? There are comments in the file =0A=
arch/powerpc/kernel/idle_e500.S=0A=
which are stating:=0A=
/* Go to NAP or DOZE now */=0A=
or=0A=
/* Return from NAP/DOZE ...*/=0A=
=0A=
and because of this comments I thought that both modes are in use.=0A=
=0A=
I have a way of measuring the power and it is also a small part of my maste=
rthesis,=0A=
but it is not very meaningful because at the measuring point there are othe=
r peripheral=0A=
components too.=0A=
=0A=
According to the comments can I activate the nap mode somehow?=0A=
=0A=
>> How can I debug the e500 idle modes?=0A=
>> Are there any statistics?=0A=
> Top reports idle percentage...=0A=
If the e500 and e500v2 are indeed using only the doze mode it =0A=
would be enough statistics.=0A=
=0A=
>> I already ran PowerTOP on a QorIQ P2020 but it's almost useless=0A=
>> because the information is missing.=0A=
> What information are you looking for?=0A=
=0A=
On my laptop I get detailled idle stats in PowerTOP 2.2=0A=
=0A=
Package | CPU 0=0A=
POLL 0.0% | POLL 0.0% 0.0 ms=0A=
C1 0.7% | C1 0.4% 0.2 ms=0A=
C2 86.0% | C2 86.8% 1.4 ms=0A=
=0A=
| CPU 1=0A=
| POLL 0.0% 0.4 ms=0A=
| C1 0.9% 0.6 ms=0A=
| C2 85.2% 1.5 ms=0A=
=0A=
It is using the sysfs interface=0A=
=0A=
thomas@localhost /s/d/s/c/c/cpuidle> pwd=0A=
/sys/devices/system/cpu/cpu0/cpuidle=0A=
thomas@localhost /s/d/s/c/c/cpuidle> tree=0A=
.=0A=
=86=80=80 state0=0A=
=81=9A=9A =86=80=80 desc=0A=
=81=9A=9A =86=80=80 disable=0A=
=81=9A=9A =86=80=80 latency=0A=
=81=9A=9A =86=80=80 name=0A=
=81=9A=9A =86=80=80 power=0A=
=81=9A=9A =86=80=80 time=0A=
=81=9A=9A =84=80=80 usage=0A=
=86=80=80 state1=0A=
(same as state0)=0A=
=84=80=80 state2=0A=
(also same as state 0)=0A=
thomas@localhost /s/d/s/c/c/cpuidle> cat */name=0A=
POLL=0A=
C1=0A=
C2=0A=
=0A=
Such statistics would be great for the doze, nap (and sleep for the whole p=
ackage).=0A=
=0A=
Kind regards,=0A=
Thomas=
^ permalink raw reply
* Re: [PATCH] PowerPC documentation: fixed path to the powerpc directory
From: Thomas Waldecker @ 2013-02-02 9:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, linux-kernel, rob, linux-doc
In-Reply-To: <1357858846.4838.92.camel@pasglop>
Hi Ben,
I sent it twice, sorry. I haven't seen it applied for a long time and
got no response.
It is already applied.
Kind regards,
Thomas
^ permalink raw reply
* linux-next: build failure after merge of the tip tree
From: Stephen Rothwell @ 2013-02-02 5:04 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
Cc: Sukadev Bhattiprolu, linux-next, linux-kernel, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 3674 bytes --]
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/perf/power7-pmu.c:397:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:397:2: error: (near initialization for 'power7_events_attr[0]') [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:398:2: error: (near initialization for 'power7_events_attr[1]') [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:399:2: error: (near initialization for 'power7_events_attr[2]') [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:400:2: error: (near initialization for 'power7_events_attr[3]') [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:401:2: error: (near initialization for 'power7_events_attr[4]') [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:402:2: error: (near initialization for 'power7_events_attr[5]') [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:403:2: error: (near initialization for 'power7_events_attr[6]') [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:404:2: error: (near initialization for 'power7_events_attr[7]') [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:406:2: error: (near initialization for 'power7_events_attr[8]') [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:407:2: error: (near initialization for 'power7_events_attr[9]') [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:408:2: error: (near initialization for 'power7_events_attr[10]') [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:409:2: error: (near initialization for 'power7_events_attr[11]') [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:410:2: error: (near initialization for 'power7_events_attr[12]') [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:411:2: error: (near initialization for 'power7_events_attr[13]') [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:412:2: error: (near initialization for 'power7_events_attr[14]') [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: initialization from incompatible pointer type [-Werror]
arch/powerpc/perf/power7-pmu.c:413:2: error: (near initialization for 'power7_events_attr[15]') [-Werror]
Caused by commit 1c53a270724d ("perf/POWER7: Make generic event
translations available in sysfs").
I have used the tip tree from 20130128 for today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Timur Tabi @ 2013-02-02 4:34 UTC (permalink / raw)
To: Scott Wood; +Cc: Stef van Os, Paul Mackerras, linuxppc-dev
In-Reply-To: <1359765063.23561.14@snotra>
On Fri, Feb 1, 2013 at 6:31 PM, Scott Wood <scottwood@freescale.com> wrote:
>
> I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you
> don't want PCI. Maybe PCI and srio should be moved out of that file, or
> ifdeffed if 85xx ever ends up using the preprocessor for its device trees.
Wouldn't it be easier to add status="disabled" in this dts file? I do
something similar with the LBC on the p1022rdk.
board_lbc: lbc: localbus@ffe05000 {
/* The P1022 RDK does not have any localbus devices */
status = "disabled";
};
^ permalink raw reply
* Re: [PATCH] powerpc/512x: add function for CS parameter configuration
From: Timur Tabi @ 2013-02-02 4:31 UTC (permalink / raw)
To: Anatolij Gustschin; +Cc: linuxppc-dev
In-Reply-To: <1359725305-23916-1-git-send-email-agust@denx.de>
On Fri, Feb 1, 2013 at 7:28 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Add ability to configure CS parameters for devices that need
> different CS parameters setup after their configuration. I.e.
> an FPGA device on LP bus can require different CS parameters
> for its bus interface after loading firmware into it. A driver
> can easily reconfigure the LPC CS parameters using this function.
Could you define "CS" somewhere?
> +struct mpc512x_lpc {
> + u32 cs_cfg[8]; /* CS config */
> + u32 cs_ctrl; /* CS Control Register */
> + u32 cs_status; /* CS Status Register */
> + u32 burst_ctrl; /* CS Burst Control Register */
> + u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
> + u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
> + u32 alt; /* Address Latch Timing Register */
> +};
These should be __be32.
> +
> +int mpc512x_cs_config(int cs, u32 val);
> +
> #endif /* __ASM_POWERPC_MPC5121_H__ */
> diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
> index c344438..112b4f6 100644
> --- a/arch/powerpc/platforms/512x/mpc512x_shared.c
> +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
> @@ -436,3 +436,33 @@ void __init mpc512x_init(void)
> mpc512x_restart_init();
> mpc512x_psc_fifo_init();
> }
> +
> +/**
> + * mpc512x_cs_config - Setup chip select configuration
> + * @cs: chip select number
> + * @val: chip select configuration value
> + *
> + * Perform chip select configuration for devices on LocalPlus Bus.
> + * Intended to dynamically reconfigure the chip select parameters
> + * for configurable devices on the bus.
> + */
> +int mpc512x_cs_config(int cs, u32 val)
> +{
> + static struct mpc512x_lpc __iomem *lpc;
> + struct device_node *np;
> +
> + if (cs < 0 || cs > 7)
> + return -EINVAL;
If you make cs an unsigned int, you won't need to test for < 0.
> +
> + if (!lpc) {
> + np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
> + lpc = of_iomap(np, 0);
> + of_node_put(np);
> + if (!lpc)
> + return -ENOMEM;
> + }
> +
> + out_be32(&lpc->cs_cfg[cs], val);
You forgot the iounmap() if lpc == NULL.
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(mpc512x_cs_config);
EXPORT_SYMBOL, please, to match the rest of the Freescale platforms.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Scott Wood @ 2013-02-02 0:31 UTC (permalink / raw)
To: Stef van Os; +Cc: Paul Mackerras, linuxppc-dev, Stef van Os
In-Reply-To: <1359733013-722-1-git-send-email-stef.van.os@prodrive.nl>
On 02/01/2013 09:36:53 AM, Stef van Os wrote:
> + memory {
> + device_type =3D "memory";
> + reg =3D <0 0 0x0 0x40000000>;
> + };
You have a "filled in by U-Boot" comment elsewhere in the file, but you =20
aren't letting U-Boot fill in the memory size?
> + board_lbc: lbc: localbus@fe0005000 {
> + reg =3D <0xf 0xe0005000 0 0x1000>;
> + ranges =3D <0x0 0x0 0xf 0xff800000 0x00800000>;
> + };
> +
> + board_soc: soc: soc8548@fe0000000 {
> + ranges =3D <0 0xf 0xe0000000 0x100000>;
> + };
I know some existing dts files do this, but there's no need for two =20
labels one one node.
> + rio: rapidio@fe00c0000 {
> + reg =3D <0xf 0xe00c0000 0x0 0x11000>;
> + port1 {
> + ranges =3D <0x0 0x0 0x0 0x80000000 0x0 =20
> 0x40000000>;
> + };
> + };
> +};
> +
> +&lbc {
> + #address-cells =3D <2>;
> + #size-cells =3D <1>;
> + compatible =3D "fsl,mpc8548-lbc", "fsl,pq3-localbus", =20
> "simple-bus";
> + interrupts =3D <19 2 0 0>;
> +};
> +
> +&rio {
> + compatible =3D "fsl,srio";
> + interrupts =3D <48 2 0 0>;
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + fsl,srio-rmu-handle =3D <&rmu>;
> + ranges;
> +
> + port1 {
> + #address-cells =3D <2>;
> + #size-cells =3D <2>;
> + cell-index =3D <1>;
> + };
> +};
> +
> +&soc {
> + #address-cells =3D <1>;
> + #size-cells =3D <1>;
> + device_type =3D "soc";
> + compatible =3D "fsl,mpc8548-immr", "simple-bus";
> + bus-frequency =3D <0>; // Filled out by uboot.
> +
> + ecm-law@0 {
> + compatible =3D "fsl,ecm-law";
> + reg =3D <0x0 0x1000>;
> + fsl,num-laws =3D <10>;
> + };
> +
> + ecm@1000 {
> + compatible =3D "fsl,mpc8548-ecm", "fsl,ecm";
> + reg =3D <0x1000 0x1000>;
> + interrupts =3D <17 2 0 0>;
> + };
> +
> + memory-controller@2000 {
> + compatible =3D "fsl,mpc8548-memory-controller";
> + reg =3D <0x2000 0x1000>;
> + interrupts =3D <18 2 0 0>;
> + };
> +
> +/include/ "fsl/pq3-i2c-0.dtsi"
> +/include/ "fsl/pq3-i2c-1.dtsi"
> +/include/ "fsl/pq3-duart-0.dtsi"
> +
> + L2: l2-cache-controller@20000 {
> + compatible =3D "fsl,mpc8548-l2-cache-controller";
> + reg =3D <0x20000 0x1000>;
> + cache-line-size =3D <32>; // 32 bytes
> + cache-size =3D <0x80000>; // L2, 512K
> + interrupts =3D <16 2 0 0>;
> + };
> +
> +/include/ "fsl/pq3-dma-0.dtsi"
> +/include/ "fsl/pq3-etsec1-0.dtsi"
> +/include/ "fsl/pq3-etsec1-1.dtsi"
> +/include/ "fsl/pq3-etsec1-2.dtsi"
> +/include/ "fsl/pq3-etsec1-3.dtsi"
> +
> +/include/ "fsl/pq3-sec2.1-0.dtsi"
> +/include/ "fsl/pq3-mpic.dtsi"
> +/include/ "fsl/pq3-rmu-0.dtsi"
> +
> + global-utilities@e0000 {
> + compatible =3D "fsl,mpc8548-guts";
> + reg =3D <0xe0000 0x1000>;
> + fsl,has-rstcr;
> + };
> +};
I guess the reason you're not using fsl/mpc8548si-post.dtsi is that you =20
don't want PCI. Maybe PCI and srio should be moved out of that file, =20
or ifdeffed if 85xx ever ends up using the preprocessor for its device =20
trees.
> diff --git a/arch/powerpc/platforms/85xx/ppa8548.c =20
> b/arch/powerpc/platforms/85xx/ppa8548.c
> new file mode 100644
> index 0000000..80a9307
> --- /dev/null
> +++ b/arch/powerpc/platforms/85xx/ppa8548.c
> @@ -0,0 +1,119 @@
> +/*
> + * ppa8548 setup and early boot code.
> + *
> + * Copyright 2009 Prodrive B.V..
> + *
> + * By Stef van Os (see MAINTAINERS for contact information)
> + *
> + * Based on the SBC8548 support - Copyright 2007 Wind River Systems =20
> Inc.
> + * Based on the MPC8548CDS support - Copyright 2005 Freescale Inc.
> + *
> + * This program is free software; you can redistribute it and/or =20
> modify it
> + * under the terms of the GNU General Public License as published =20
> by the
> + * Free Software Foundation; either version 2 of the License, or =20
> (at your
> + * option) any later version.
> + */
> +
> +#include <linux/stddef.h>
> +#include <linux/kernel.h>
> +#include <linux/init.h>
> +#include <linux/errno.h>
> +#include <linux/reboot.h>
> +#include <linux/kdev_t.h>
> +#include <linux/major.h>
> +#include <linux/console.h>
> +#include <linux/delay.h>
> +#include <linux/seq_file.h>
> +#include <linux/initrd.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/pgtable.h>
> +#include <asm/page.h>
> +#include <asm/atomic.h>
> +#include <asm/time.h>
> +#include <asm/io.h>
> +#include <asm/machdep.h>
> +#include <asm/ipic.h>
> +#include <asm/irq.h>
> +#include <mm/mmu_decl.h>
> +#include <asm/prom.h>
> +#include <asm/udbg.h>
> +#include <asm/mpic.h>
> +
> +#include <sysdev/fsl_soc.h>
I doubt you need all of these.
E.g. asm/ipic.h is for 83xx and 512x chips. Some others are for things =20
that haven't been done by board files for years (e.g. kdev_t.h).
> +static void ppa8548_show_cpuinfo(struct seq_file *m)
> +{
> + uint pvid, svid, phid1;
> +
> + pvid =3D mfspr(SPRN_PVR);
> + svid =3D mfspr(SPRN_SVR);
> +
> + seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
> + seq_printf(m, "Machine\t\t: ppa8548\n");
> + seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
> + seq_printf(m, "SVR\t\t: 0x%x\n", svid);
> +
> + /* Display cpu Pll setting */
> + phid1 =3D mfspr(SPRN_HID1);
> + seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
> +}
PVR and ppc_md.name are already shown by the generic /proc/cpuinfo code.
-Scott=
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-02-01 23:12 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-acpi@vger.kernel.org, Greg KH,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <2370118.yuaZBuKn6n@vostro.rjw.lan>
On Fri, 2013-02-01 at 23:21 +0100, Rafael J. Wysocki wrote:
> On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> > On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > > This is already done for PCI host bridges and platform devices and I don't
> > > > > see why we can't do that for the other types of devices too.
> > > > >
> > > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > > help from the driver core here.
> > > >
> > > > There are three different approaches suggested for system device
> > > > hot-plug:
> > > > A. Proceed within system device bus scan.
> > > > B. Proceed within ACPI bus scan.
> > > > C. Proceed with a sequence (as a mini-boot).
> > > >
> > > > Option A uses system devices as tokens, option B uses acpi devices as
> > > > tokens, and option C uses resource tables as tokens, for their handlers.
> > > >
> > > > Here is summary of key questions & answers so far. I hope this
> > > > clarifies why I am suggesting option 3.
> > > >
> > > > 1. What are the system devices?
> > > > System devices provide system-wide core computing resources, which are
> > > > essential to compose a computer system. System devices are not
> > > > connected to any particular standard buses.
> > >
> > > Not a problem, lots of devices are not connected to any "particular
> > > standard busses". All this means is that system devices are connected
> > > to the "system" bus, nothing more.
> >
> > Can you give me a few examples of other devices that support hotplug and
> > are not connected to any particular buses? I will investigate them to
> > see how they are managed to support hotplug.
> >
> > > > 2. Why are the system devices special?
> > > > The system devices are initialized during early boot-time, by multiple
> > > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > > provide low-level services to enable other subsystems to come up.
> > >
> > > Sorry, no, that doesn't mean they are special, nothing here is unique
> > > for the point of view of the driver model from any other device or bus.
> >
> > I think system devices are unique in a sense that they are initialized
> > before drivers run.
> >
> > > > 3. Why can't initialize the system devices from the driver structure at
> > > > boot?
> > > > The driver structure is initialized at the end of the boot sequence and
> > > > requires the low-level services from the system devices initialized
> > > > beforehand.
> > >
> > > Wait, what "driver structure"?
> >
> > Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
> > from driver_init() at the end of the boot sequence, and initialize
> > system/cpu and system/memory devices. I assume they are the system bus
> > you are referring with option A.
> >
> > > If you need to initialize the driver
> > > core earlier, then do so. Or, even better, just wait until enough of
> > > the system has come up and then go initialize all of the devices you
> > > have found so far as part of your boot process.
> >
> > They are pseudo drivers that provide sysfs entry points of cpu and
> > memory. They do not actually initialize cpu and memory. I do not think
> > initializing cpu and memory fits into the driver model either, since
> > drivers should run after cpu and memory are initialized.
> >
> > > None of the above things you have stated seem to have anything to do
> > > with your proposed patch, so I don't understand why you have mentioned
> > > them...
> >
> > You suggested option A before, which uses system bus scan to initialize
> > all system devices at boot time as well as hot-plug. I tried to say
> > that this option would not be doable.
> >
> > > > 4. Why do we need a new common framework?
> > > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > > and memory modules. They are common code and do not depend on ACPI.
> > > > Therefore, a new common framework is necessary to integrate both
> > > > on-lining/off-lining operation and hot-plugging operation of system
> > > > devices into a single framework.
> > >
> > > {sigh}
> > >
> > > Removing and adding devices and handling hotplug operations is what the
> > > driver core was written for, almost 10 years ago. To somehow think that
> > > your devices are "special" just because they don't use ACPI is odd,
> > > because the driver core itself has nothing to do with ACPI. Don't get
> > > the current mix of x86 system code tied into ACPI confused with an
> > > driver core issues here please.
> >
> > CPU online/offline operation is performed within the CPU module. Memory
> > online/offline operation is performed within the memory module. CPU and
> > memory hotplug operations are performed within ACPI. While they deal
> > with the same set of devices, they operate independently and are not
> > managed under a same framework.
> >
> > I agree with you that not using ACPI is perfectly fine. My point is
> > that ACPI framework won't be able to manage operations that do not use
> > ACPI.
> >
> > > > 5. Why can't do everything with ACPI bus scan?
> > > > Software dependency among system devices may not be dictated by the ACPI
> > > > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > > > a new cpu may need its local memory), but such ordering cannot be
> > > > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > > > online/offline operations are independent from ACPI.
> > >
> > > That's fine, the driver core is independant from ACPI. I don't care how
> > > you do the scaning of your devices, but I do care about you creating new
> > > driver core pieces that duplicate the existing functionality of what we
> > > have today.
> > >
> > > In short, I like Rafael's proposal better, and I fail to see how
> > > anything you have stated here would matter in how this is implemented. :)
> >
> > Doing everything within ACPI means we can only manage ACPI hotplug
> > operations, not online/offline operations. But I understand that you
> > concern about adding a new framework with option C. It is good to know
> > that you are fine with option B. :) So, I will step back, and think
> > about what we can do within ACPI.
>
> Not much, because ACPI only knows about a subset of devices that may be
> involved in that, and a limited one for that matter. For one example,
> anything connected through PCI and not having a corresponding ACPI object (i.e.
> pretty much every add-in card in existence) will be unknown to ACPI. And
> say one of these things is a SATA controller with a number of disks under it
> and so on. ACPI won't even know that it exists. Moreover, PCI won't know
> that those disks exist. Etc.
Agreed. Thanks for bringing I/Os into the picture. I did not mention
them since they have not supported in this patchset, but we certainly
need to consider them into the design.
Thanks,
-Toshi
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-01 22:21 UTC (permalink / raw)
To: Toshi Kani
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-acpi@vger.kernel.org, Greg KH,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
isimatu.yasuaki@jp.fujitsu.com, yinghai@kernel.org,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <1359751210.15120.278.camel@misato.fc.hp.com>
On Friday, February 01, 2013 01:40:10 PM Toshi Kani wrote:
> On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> > On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > > This is already done for PCI host bridges and platform devices and I don't
> > > > see why we can't do that for the other types of devices too.
> > > >
> > > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > > when we try do eject a device at the top of a subtree and need to tear down
> > > > the entire subtree below it, but if that's going to lead to a system crash,
> > > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > > help from the driver core here.
> > >
> > > There are three different approaches suggested for system device
> > > hot-plug:
> > > A. Proceed within system device bus scan.
> > > B. Proceed within ACPI bus scan.
> > > C. Proceed with a sequence (as a mini-boot).
> > >
> > > Option A uses system devices as tokens, option B uses acpi devices as
> > > tokens, and option C uses resource tables as tokens, for their handlers.
> > >
> > > Here is summary of key questions & answers so far. I hope this
> > > clarifies why I am suggesting option 3.
> > >
> > > 1. What are the system devices?
> > > System devices provide system-wide core computing resources, which are
> > > essential to compose a computer system. System devices are not
> > > connected to any particular standard buses.
> >
> > Not a problem, lots of devices are not connected to any "particular
> > standard busses". All this means is that system devices are connected
> > to the "system" bus, nothing more.
>
> Can you give me a few examples of other devices that support hotplug and
> are not connected to any particular buses? I will investigate them to
> see how they are managed to support hotplug.
>
> > > 2. Why are the system devices special?
> > > The system devices are initialized during early boot-time, by multiple
> > > subsystems, from the boot-up sequence, in pre-defined order. They
> > > provide low-level services to enable other subsystems to come up.
> >
> > Sorry, no, that doesn't mean they are special, nothing here is unique
> > for the point of view of the driver model from any other device or bus.
>
> I think system devices are unique in a sense that they are initialized
> before drivers run.
>
> > > 3. Why can't initialize the system devices from the driver structure at
> > > boot?
> > > The driver structure is initialized at the end of the boot sequence and
> > > requires the low-level services from the system devices initialized
> > > beforehand.
> >
> > Wait, what "driver structure"?
>
> Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
> from driver_init() at the end of the boot sequence, and initialize
> system/cpu and system/memory devices. I assume they are the system bus
> you are referring with option A.
>
> > If you need to initialize the driver
> > core earlier, then do so. Or, even better, just wait until enough of
> > the system has come up and then go initialize all of the devices you
> > have found so far as part of your boot process.
>
> They are pseudo drivers that provide sysfs entry points of cpu and
> memory. They do not actually initialize cpu and memory. I do not think
> initializing cpu and memory fits into the driver model either, since
> drivers should run after cpu and memory are initialized.
>
> > None of the above things you have stated seem to have anything to do
> > with your proposed patch, so I don't understand why you have mentioned
> > them...
>
> You suggested option A before, which uses system bus scan to initialize
> all system devices at boot time as well as hot-plug. I tried to say
> that this option would not be doable.
>
> > > 4. Why do we need a new common framework?
> > > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > > and memory modules. They are common code and do not depend on ACPI.
> > > Therefore, a new common framework is necessary to integrate both
> > > on-lining/off-lining operation and hot-plugging operation of system
> > > devices into a single framework.
> >
> > {sigh}
> >
> > Removing and adding devices and handling hotplug operations is what the
> > driver core was written for, almost 10 years ago. To somehow think that
> > your devices are "special" just because they don't use ACPI is odd,
> > because the driver core itself has nothing to do with ACPI. Don't get
> > the current mix of x86 system code tied into ACPI confused with an
> > driver core issues here please.
>
> CPU online/offline operation is performed within the CPU module. Memory
> online/offline operation is performed within the memory module. CPU and
> memory hotplug operations are performed within ACPI. While they deal
> with the same set of devices, they operate independently and are not
> managed under a same framework.
>
> I agree with you that not using ACPI is perfectly fine. My point is
> that ACPI framework won't be able to manage operations that do not use
> ACPI.
>
> > > 5. Why can't do everything with ACPI bus scan?
> > > Software dependency among system devices may not be dictated by the ACPI
> > > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > > a new cpu may need its local memory), but such ordering cannot be
> > > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > > online/offline operations are independent from ACPI.
> >
> > That's fine, the driver core is independant from ACPI. I don't care how
> > you do the scaning of your devices, but I do care about you creating new
> > driver core pieces that duplicate the existing functionality of what we
> > have today.
> >
> > In short, I like Rafael's proposal better, and I fail to see how
> > anything you have stated here would matter in how this is implemented. :)
>
> Doing everything within ACPI means we can only manage ACPI hotplug
> operations, not online/offline operations. But I understand that you
> concern about adding a new framework with option C. It is good to know
> that you are fine with option B. :) So, I will step back, and think
> about what we can do within ACPI.
Not much, because ACPI only knows about a subset of devices that may be
involved in that, and a limited one for that matter. For one example,
anything connected through PCI and not having a corresponding ACPI object (i.e.
pretty much every add-in card in existence) will be unknown to ACPI. And
say one of these things is a SATA controller with a number of disks under it
and so on. ACPI won't even know that it exists. Moreover, PCI won't know
that those disks exist. Etc.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Rafael J. Wysocki @ 2013-02-01 22:12 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390, Toshi Kani, jiang.liu, wency, linux-acpi, yinghai,
linux-kernel, linux-mm, isimatu.yasuaki, srivatsa.bhat, guohanjun,
bhelgaas, akpm, linuxppc-dev, lenb
In-Reply-To: <20130201072312.GB1180@kroah.com>
On Friday, February 01, 2013 08:23:12 AM Greg KH wrote:
> On Thu, Jan 31, 2013 at 09:54:51PM +0100, Rafael J. Wysocki wrote:
> > > > But, again, I'm going to ask why you aren't using the existing cpu /
> > > > memory / bridge / node devices that we have in the kernel. Please use
> > > > them, or give me a _really_ good reason why they will not work.
> > >
> > > We cannot use the existing system devices or ACPI devices here. During
> > > hot-plug, ACPI handler sets this shp_device info, so that cpu and memory
> > > handlers (drivers/cpu.c and mm/memory_hotplug.c) can obtain their target
> > > device information in a platform-neutral way. During hot-add, we first
> > > creates an ACPI device node (i.e. device under /sys/bus/acpi/devices),
> > > but platform-neutral modules cannot use them as they are ACPI-specific.
> >
> > But suppose we're smart and have ACPI scan handlers that will create
> > "physical" device nodes for those devices during the ACPI namespace scan.
> > Then, the platform-neutral nodes will be able to bind to those "physical"
> > nodes. Moreover, it should be possible to get a hierarchy of device objects
> > this way that will reflect all of the dependencies we need to take into
> > account during hot-add and hot-remove operations. That may not be what we
> > have today, but I don't see any *fundamental* obstacles preventing us from
> > using this approach.
>
> I would _much_ rather see that be the solution here as I think it is the
> proper one.
>
> > This is already done for PCI host bridges and platform devices and I don't
> > see why we can't do that for the other types of devices too.
>
> I agree.
>
> > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > when we try do eject a device at the top of a subtree and need to tear down
> > the entire subtree below it, but if that's going to lead to a system crash,
> > for example, we want to cancel the eject. It seems to me that we'll need some
> > help from the driver core here.
>
> I say do what we always have done here, if the user asked us to tear
> something down, let it happen as they are the ones that know best :)
>
> Seriously, I guess this gets back to the "fail disconnect" idea that the
> ACPI developers keep harping on. I thought we already resolved this
> properly by having them implement it in their bus code, no reason the
> same thing couldn't happen here, right?
Not really. :-) We haven't ever resolved that particular issue I'm afraid.
> I don't think the core needs to do anything special, but if so, I'll be glad
> to review it.
OK, so this is the use case. We have "eject" defined for something like
a container with a number of CPU cores, PCI host bridge, and a memory
controller under it. And a few pretty much arbitrary I/O devices as a bonus.
Now, there's a button on the system case labeled as "Eject" and if that button
is pressed, we're supposed to _try_ to eject all of those things at once. We
are allowed to fail that request, though, if that's problematic for some
reason, but we're supposed to let the BIOS know about that.
Do you seriously think that if that button is pressed, we should just proceed
with removing all that stuff no matter what? That'd be kind of like Russian
roulette for whoever pressed that button, because s/he could only press it and
wait for the system to either crash or not. Or maybe to crash a bit later
because of some delayed stuff that would hit one of those devices that had just
gone. Surely not a situation any admin of a high-availability system would
like to be in. :-)
Quite frankly, I have no idea how that can be addressed in a single bus type,
let alone ACPI (which is not even a proper bus type, just something pretending
to be one).
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [RFC PATCH v2 01/12] Add sys_hotplug.h for system device hotplug framework
From: Toshi Kani @ 2013-02-01 20:40 UTC (permalink / raw)
To: Greg KH
Cc: linux-s390@vger.kernel.org, jiang.liu@huawei.com,
wency@cn.fujitsu.com, linux-mm@kvack.org, yinghai@kernel.org,
linux-kernel@vger.kernel.org, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, isimatu.yasuaki@jp.fujitsu.com,
srivatsa.bhat@linux.vnet.ibm.com, guohanjun@huawei.com,
bhelgaas@google.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, lenb@kernel.org
In-Reply-To: <20130201073010.GC1180@kroah.com>
On Fri, 2013-02-01 at 07:30 +0000, Greg KH wrote:
> On Thu, Jan 31, 2013 at 06:32:18PM -0700, Toshi Kani wrote:
> > This is already done for PCI host bridges and platform devices and I don't
> > > see why we can't do that for the other types of devices too.
> > >
> > > The only missing piece I see is a way to handle the "eject" problem, i.e.
> > > when we try do eject a device at the top of a subtree and need to tear down
> > > the entire subtree below it, but if that's going to lead to a system crash,
> > > for example, we want to cancel the eject. It seems to me that we'll need some
> > > help from the driver core here.
> >
> > There are three different approaches suggested for system device
> > hot-plug:
> > A. Proceed within system device bus scan.
> > B. Proceed within ACPI bus scan.
> > C. Proceed with a sequence (as a mini-boot).
> >
> > Option A uses system devices as tokens, option B uses acpi devices as
> > tokens, and option C uses resource tables as tokens, for their handlers.
> >
> > Here is summary of key questions & answers so far. I hope this
> > clarifies why I am suggesting option 3.
> >
> > 1. What are the system devices?
> > System devices provide system-wide core computing resources, which are
> > essential to compose a computer system. System devices are not
> > connected to any particular standard buses.
>
> Not a problem, lots of devices are not connected to any "particular
> standard busses". All this means is that system devices are connected
> to the "system" bus, nothing more.
Can you give me a few examples of other devices that support hotplug and
are not connected to any particular buses? I will investigate them to
see how they are managed to support hotplug.
> > 2. Why are the system devices special?
> > The system devices are initialized during early boot-time, by multiple
> > subsystems, from the boot-up sequence, in pre-defined order. They
> > provide low-level services to enable other subsystems to come up.
>
> Sorry, no, that doesn't mean they are special, nothing here is unique
> for the point of view of the driver model from any other device or bus.
I think system devices are unique in a sense that they are initialized
before drivers run.
> > 3. Why can't initialize the system devices from the driver structure at
> > boot?
> > The driver structure is initialized at the end of the boot sequence and
> > requires the low-level services from the system devices initialized
> > beforehand.
>
> Wait, what "driver structure"?
Sorry it was not clear. cpu_dev_init() and memory_dev_init() are called
from driver_init() at the end of the boot sequence, and initialize
system/cpu and system/memory devices. I assume they are the system bus
you are referring with option A.
> If you need to initialize the driver
> core earlier, then do so. Or, even better, just wait until enough of
> the system has come up and then go initialize all of the devices you
> have found so far as part of your boot process.
They are pseudo drivers that provide sysfs entry points of cpu and
memory. They do not actually initialize cpu and memory. I do not think
initializing cpu and memory fits into the driver model either, since
drivers should run after cpu and memory are initialized.
> None of the above things you have stated seem to have anything to do
> with your proposed patch, so I don't understand why you have mentioned
> them...
You suggested option A before, which uses system bus scan to initialize
all system devices at boot time as well as hot-plug. I tried to say
that this option would not be doable.
> > 4. Why do we need a new common framework?
> > Sysfs CPU and memory on-lining/off-lining are performed within the CPU
> > and memory modules. They are common code and do not depend on ACPI.
> > Therefore, a new common framework is necessary to integrate both
> > on-lining/off-lining operation and hot-plugging operation of system
> > devices into a single framework.
>
> {sigh}
>
> Removing and adding devices and handling hotplug operations is what the
> driver core was written for, almost 10 years ago. To somehow think that
> your devices are "special" just because they don't use ACPI is odd,
> because the driver core itself has nothing to do with ACPI. Don't get
> the current mix of x86 system code tied into ACPI confused with an
> driver core issues here please.
CPU online/offline operation is performed within the CPU module. Memory
online/offline operation is performed within the memory module. CPU and
memory hotplug operations are performed within ACPI. While they deal
with the same set of devices, they operate independently and are not
managed under a same framework.
I agree with you that not using ACPI is perfectly fine. My point is
that ACPI framework won't be able to manage operations that do not use
ACPI.
> > 5. Why can't do everything with ACPI bus scan?
> > Software dependency among system devices may not be dictated by the ACPI
> > hierarchy. For instance, memory should be initialized before CPUs (i.e.
> > a new cpu may need its local memory), but such ordering cannot be
> > guaranteed by the ACPI hierarchy. Also, as described in 4,
> > online/offline operations are independent from ACPI.
>
> That's fine, the driver core is independant from ACPI. I don't care how
> you do the scaning of your devices, but I do care about you creating new
> driver core pieces that duplicate the existing functionality of what we
> have today.
>
> In short, I like Rafael's proposal better, and I fail to see how
> anything you have stated here would matter in how this is implemented. :)
Doing everything within ACPI means we can only manage ACPI hotplug
operations, not online/offline operations. But I understand that you
concern about adding a new framework with option C. It is good to know
that you are fine with option B. :) So, I will step back, and think
about what we can do within ACPI.
Thanks,
-Toshi
^ permalink raw reply
* Re: Why is the e500v2 core not using cpuidle?
From: Scott Wood @ 2013-02-01 18:15 UTC (permalink / raw)
To: Thomas Waldecker
Cc: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
In-Reply-To: <B88C075EE1324644BA0452D5EFDD58281395211D@TQ-MAIL.tq-net.de>
On 02/01/2013 06:06:05 AM, Thomas Waldecker wrote:
> Hi,
>=20
> As part of my masterthesis I was just looking around the kernel
> sources for cpuidle and figured out that the only CPU in the PowerPC
> architecture using the cpuidle framework is the pseries.
>=20
> I assume the e500v2 core is using the idle modes
> in arch/powerpc/kernel/idle_e500.S
>=20
> Why is there no support for the cpuidle framework?
Because nobody implemented it. :-)
The only reason I can think of to implement it on this chip would be to =20
dynamically choose when to enter nap versus doze, rather than always =20
just using doze. It's not clear whether the difference in power =20
savings is worth it -- do you have any way of measuring?
> How can I debug the e500 idle modes?
> Are there any statistics?
Top reports idle percentage...
> I already ran PowerTOP on a QorIQ P2020 but it's almost useless
> because the information is missing.
What information are you looking for?
-Scott=
^ permalink raw reply
* [PATCH 1/1] powerpc/85xx: Board support for ppa8548
From: Stef van Os @ 2013-02-01 15:36 UTC (permalink / raw)
To: Kumar Gala, linuxppc-dev; +Cc: Paul Mackerras, Stef van Os
Initial board support for the Prodrive PPA8548 AMC module. Board
is an MPC8548 AMC platform used in RapidIO systems. This module is
also used to test/work on mainline linux RapidIO software.
PPA8548 overview:
- 1.3 GHz Freescale PowerQUICC III MPC8548 processor
- 1 GB DDR2 @ 266 MHz
- 8 MB NOR flash
- Serial RapidIO 1.2
- 1 x 10/100/1000 BASE-T front ethernet
- 1 x 1000 BASE-BX ethernet on AMC connector
Signed-off-by: Stef van Os <stef.van.os@prodrive.nl>
---
arch/powerpc/boot/dts/ppa8548.dts | 238 +++++++++++++++++++++++++++
arch/powerpc/configs/85xx/ppa8548_defconfig | 65 ++++++++
arch/powerpc/platforms/85xx/Kconfig | 7 +
arch/powerpc/platforms/85xx/Makefile | 1 +
arch/powerpc/platforms/85xx/ppa8548.c | 119 +++++++++++++
5 files changed, 430 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/ppa8548.dts
create mode 100644 arch/powerpc/configs/85xx/ppa8548_defconfig
create mode 100644 arch/powerpc/platforms/85xx/ppa8548.c
diff --git a/arch/powerpc/boot/dts/ppa8548.dts b/arch/powerpc/boot/dts/ppa8548.dts
new file mode 100644
index 0000000..5eaba83
--- /dev/null
+++ b/arch/powerpc/boot/dts/ppa8548.dts
@@ -0,0 +1,238 @@
+/*
+ * PPA8548 Device Tree Source (36-bit address map)
+ * Copyright 2013 Prodrive B.V.
+ *
+ * Based on:
+ * MPC8548 CDS Device Tree Source (36-bit address map)
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+/include/ "fsl/e500v2_power_isa.dtsi"
+
+/ {
+ model = "ppa8548";
+ compatible = "ppa8548";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-parent = <&mpic>;
+
+ aliases {
+ serial0 = &serial0;
+ serial1 = &serial1;
+ ethernet0 = &enet0;
+ ethernet1 = &enet1;
+ rapidio0 = &rio;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8548@0 {
+ device_type = "cpu";
+ reg = <0x0>;
+ next-level-cache = <&L2>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0 0 0x0 0x40000000>;
+ };
+
+ board_lbc: lbc: localbus@fe0005000 {
+ reg = <0xf 0xe0005000 0 0x1000>;
+ ranges = <0x0 0x0 0xf 0xff800000 0x00800000>;
+ };
+
+ board_soc: soc: soc8548@fe0000000 {
+ ranges = <0 0xf 0xe0000000 0x100000>;
+ };
+
+ rio: rapidio@fe00c0000 {
+ reg = <0xf 0xe00c0000 0x0 0x11000>;
+ port1 {
+ ranges = <0x0 0x0 0x0 0x80000000 0x0 0x40000000>;
+ };
+ };
+};
+
+&lbc {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8548-lbc", "fsl,pq3-localbus", "simple-bus";
+ interrupts = <19 2 0 0>;
+};
+
+&rio {
+ compatible = "fsl,srio";
+ interrupts = <48 2 0 0>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ fsl,srio-rmu-handle = <&rmu>;
+ ranges;
+
+ port1 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ cell-index = <1>;
+ };
+};
+
+&soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+ compatible = "fsl,mpc8548-immr", "simple-bus";
+ bus-frequency = <0>; // Filled out by uboot.
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8548-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2 0 0>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,mpc8548-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupts = <18 2 0 0>;
+ };
+
+/include/ "fsl/pq3-i2c-0.dtsi"
+/include/ "fsl/pq3-i2c-1.dtsi"
+/include/ "fsl/pq3-duart-0.dtsi"
+
+ L2: l2-cache-controller@20000 {
+ compatible = "fsl,mpc8548-l2-cache-controller";
+ reg = <0x20000 0x1000>;
+ cache-line-size = <32>; // 32 bytes
+ cache-size = <0x80000>; // L2, 512K
+ interrupts = <16 2 0 0>;
+ };
+
+/include/ "fsl/pq3-dma-0.dtsi"
+/include/ "fsl/pq3-etsec1-0.dtsi"
+/include/ "fsl/pq3-etsec1-1.dtsi"
+/include/ "fsl/pq3-etsec1-2.dtsi"
+/include/ "fsl/pq3-etsec1-3.dtsi"
+
+/include/ "fsl/pq3-sec2.1-0.dtsi"
+/include/ "fsl/pq3-mpic.dtsi"
+/include/ "fsl/pq3-rmu-0.dtsi"
+
+ global-utilities@e0000 {
+ compatible = "fsl,mpc8548-guts";
+ reg = <0xe0000 0x1000>;
+ fsl,has-rstcr;
+ };
+};
+
+&board_lbc {
+ nor@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x00800000>;
+ bank-width = <2>;
+ device-width = <2>;
+
+ partition@0 {
+ reg = <0x0 0x7A0000>;
+ label = "user";
+ };
+
+ partition@7A0000 {
+ reg = <0x7A0000 0x20000>;
+ label = "env";
+ read-only;
+ };
+
+ partition@7C0000 {
+ reg = <0x7C0000 0x40000>;
+ label = "u-boot";
+ read-only;
+ };
+ };
+};
+
+&board_soc {
+ i2c@3000 {
+ rtc@6f {
+ compatible = "intersil,isl1208";
+ reg = <0x6f>;
+ };
+ };
+
+ i2c@3100 {
+ };
+
+ ethernet@24000 {
+ status = "disabled";
+ };
+
+ mdio@24520 {
+ phy0: ethernet-phy@0 {
+ interrupts = <7 1 0 0>;
+ reg = <0x0>;
+ device_type = "ethernet-phy";
+ };
+ phy1: ethernet-phy@1 {
+ interrupts = <8 1 0 0>;
+ reg = <0x1>;
+ device_type = "ethernet-phy";
+ };
+ tbi0: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet0: ethernet@25000 {
+ tbi-handle = <&tbi1>;
+ phy-handle = <&phy0>;
+ };
+
+ mdio@25520 {
+ tbi1: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet1: ethernet@26000 {
+ tbi-handle = <&tbi2>;
+ phy-handle = <&phy1>;
+ };
+
+ mdio@26520 {
+ tbi2: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ ethernet@27000 {
+ status = "disabled";
+ };
+
+ mdio@27520 {
+ tbi3: tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+};
+
diff --git a/arch/powerpc/configs/85xx/ppa8548_defconfig b/arch/powerpc/configs/85xx/ppa8548_defconfig
new file mode 100644
index 0000000..a11337d
--- /dev/null
+++ b/arch/powerpc/configs/85xx/ppa8548_defconfig
@@ -0,0 +1,65 @@
+CONFIG_PPC_85xx=y
+CONFIG_PPA8548=y
+CONFIG_DTC=y
+CONFIG_DEFAULT_UIMAGE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+# CONFIG_PCI is not set
+# CONFIG_USB_SUPPORT is not set
+CONFIG_ADVANCED_OPTIONS=y
+CONFIG_LOWMEM_SIZE_BOOL=y
+CONFIG_LOWMEM_SIZE=0x40000000
+CONFIG_LOWMEM_CAM_NUM_BOOL=y
+CONFIG_LOWMEM_CAM_NUM=4
+CONFIG_PAGE_OFFSET_BOOL=y
+CONFIG_PAGE_OFFSET=0xb0000000
+CONFIG_KERNEL_START_BOOL=y
+CONFIG_KERNEL_START=0xb0000000
+# CONFIG_PHYSICAL_START_BOOL is not set
+CONFIG_PHYSICAL_START=0x00000000
+CONFIG_PHYSICAL_ALIGN=0x04000000
+CONFIG_TASK_SIZE_BOOL=y
+CONFIG_TASK_SIZE=0xb0000000
+
+CONFIG_FSL_LBC=y
+CONFIG_FSL_DMA=y
+CONFIG_FSL_RIO=y
+
+CONFIG_RAPIDIO=y
+CONFIG_RAPIDIO_DMA_ENGINE=y
+CONFIG_RAPIDIO_TSI57X=y
+CONFIG_RAPIDIO_TSI568=y
+CONFIG_RAPIDIO_CPS_XX=y
+CONFIG_RAPIDIO_CPS_GEN2=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_PROC_DEVICETREE=y
+
+CONFIG_MTD=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_CFI_INTELEXT=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_CONCAT=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_PHYSMAP_OF=y
+
+CONFIG_I2C=y
+CONFIG_I2C_MPC=y
+CONFIG_I2C_CHARDEV
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_HCTOSYS=y
+CONFIG_RTC_DRV_ISL1208=y
+
+CONFIG_NET=y
+CONFIG_INET=y
+CONFIG_IP_PNP=y
+CONFIG_NETDEVICES=y
+CONFIG_MII=y
+CONFIG_GIANFAR=y
+CONFIG_MARVELL_PHY=y
+CONFIG_NFS_FS=y
+CONFIG_ROOT_NFS=y
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 02d02a0..803bfed 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -191,6 +191,13 @@ config SBC8548
help
This option enables support for the Wind River SBC8548 board
+config PPA8548
+ bool "Prodrive PPA8548"
+ help
+ This option enables support for the Prodrive PPA8548 board.
+ select DEFAULT_UIMAGE
+ select HAS_RAPIDIO
+
config GE_IMP3A
bool "GE Intelligent Platforms IMP3A"
select DEFAULT_UIMAGE
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index 76f679c..d5f4195 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_P5040_DS) += p5040_ds.o corenet_ds.o
obj-$(CONFIG_STX_GP3) += stx_gp3.o
obj-$(CONFIG_TQM85xx) += tqm85xx.o
obj-$(CONFIG_SBC8548) += sbc8548.o
+obj-$(CONFIG_PPA8548) += ppa8548.o
obj-$(CONFIG_SOCRATES) += socrates.o socrates_fpga_pic.o
obj-$(CONFIG_KSI8560) += ksi8560.o
obj-$(CONFIG_XES_MPC85xx) += xes_mpc85xx.o
diff --git a/arch/powerpc/platforms/85xx/ppa8548.c b/arch/powerpc/platforms/85xx/ppa8548.c
new file mode 100644
index 0000000..80a9307
--- /dev/null
+++ b/arch/powerpc/platforms/85xx/ppa8548.c
@@ -0,0 +1,119 @@
+/*
+ * ppa8548 setup and early boot code.
+ *
+ * Copyright 2009 Prodrive B.V..
+ *
+ * By Stef van Os (see MAINTAINERS for contact information)
+ *
+ * Based on the SBC8548 support - Copyright 2007 Wind River Systems Inc.
+ * Based on the MPC8548CDS support - Copyright 2005 Freescale Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include <linux/stddef.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/errno.h>
+#include <linux/reboot.h>
+#include <linux/kdev_t.h>
+#include <linux/major.h>
+#include <linux/console.h>
+#include <linux/delay.h>
+#include <linux/seq_file.h>
+#include <linux/initrd.h>
+#include <linux/module.h>
+#include <linux/interrupt.h>
+#include <linux/fsl_devices.h>
+#include <linux/of_platform.h>
+
+#include <asm/pgtable.h>
+#include <asm/page.h>
+#include <asm/atomic.h>
+#include <asm/time.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/ipic.h>
+#include <asm/irq.h>
+#include <mm/mmu_decl.h>
+#include <asm/prom.h>
+#include <asm/udbg.h>
+#include <asm/mpic.h>
+
+#include <sysdev/fsl_soc.h>
+
+static void __init ppa8548_pic_init(void)
+{
+ struct mpic *mpic = mpic_alloc(NULL, 0, MPIC_BIG_ENDIAN,
+ 0, 256, " OpenPIC ");
+ BUG_ON(mpic == NULL);
+ mpic_init(mpic);
+}
+
+/*
+ * Setup the architecture
+ */
+static void __init ppa8548_setup_arch(void)
+{
+ if (ppc_md.progress)
+ ppc_md.progress("ppa8548_setup_arch()", 0);
+}
+
+static void ppa8548_show_cpuinfo(struct seq_file *m)
+{
+ uint pvid, svid, phid1;
+
+ pvid = mfspr(SPRN_PVR);
+ svid = mfspr(SPRN_SVR);
+
+ seq_printf(m, "Vendor\t\t: Prodrive B.V.\n");
+ seq_printf(m, "Machine\t\t: ppa8548\n");
+ seq_printf(m, "PVR\t\t: 0x%x\n", pvid);
+ seq_printf(m, "SVR\t\t: 0x%x\n", svid);
+
+ /* Display cpu Pll setting */
+ phid1 = mfspr(SPRN_HID1);
+ seq_printf(m, "PLL setting\t: 0x%x\n", ((phid1 >> 24) & 0x3f));
+}
+
+static struct of_device_id __initdata of_bus_ids[] = {
+ { .name = "soc", },
+ { .type = "soc", },
+ { .compatible = "simple-bus", },
+ { .compatible = "gianfar", },
+ { .compatible = "fsl,srio", },
+ {},
+};
+
+static int __init declare_of_platform_devices(void)
+{
+ of_platform_bus_probe(NULL, of_bus_ids, NULL);
+
+ return 0;
+}
+machine_device_initcall(ppa8548, declare_of_platform_devices);
+
+/*
+ * Called very early, device-tree isn't unflattened
+ */
+static int __init ppa8548_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+
+ return of_flat_dt_is_compatible(root, "ppa8548");
+}
+
+define_machine(ppa8548) {
+ .name = "ppa8548",
+ .probe = ppa8548_probe,
+ .setup_arch = ppa8548_setup_arch,
+ .init_IRQ = ppa8548_pic_init,
+ .show_cpuinfo = ppa8548_show_cpuinfo,
+ .get_irq = mpic_get_irq,
+ .restart = fsl_rstcr_restart,
+ .calibrate_decr = generic_calibrate_decr,
+ .progress = udbg_progress,
+};
--
1.7.2.5
^ permalink raw reply related
* [PATCH] powerpc/512x: add function for CS parameter configuration
From: Anatolij Gustschin @ 2013-02-01 13:28 UTC (permalink / raw)
To: linuxppc-dev
Add ability to configure CS parameters for devices that need
different CS parameters setup after their configuration. I.e.
an FPGA device on LP bus can require different CS parameters
for its bus interface after loading firmware into it. A driver
can easily reconfigure the LPC CS parameters using this function.
Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
arch/powerpc/include/asm/mpc5121.h | 16 +++++++++++++
arch/powerpc/platforms/512x/mpc512x_shared.c | 30 ++++++++++++++++++++++++++
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpc5121.h b/arch/powerpc/include/asm/mpc5121.h
index 8c0ab2c..738ebca 100644
--- a/arch/powerpc/include/asm/mpc5121.h
+++ b/arch/powerpc/include/asm/mpc5121.h
@@ -53,4 +53,20 @@ struct mpc512x_ccm {
u32 m4ccr; /* MSCAN4 CCR */
u8 res[0x98]; /* Reserved */
};
+
+/*
+ * LPC Module
+ */
+struct mpc512x_lpc {
+ u32 cs_cfg[8]; /* CS config */
+ u32 cs_ctrl; /* CS Control Register */
+ u32 cs_status; /* CS Status Register */
+ u32 burst_ctrl; /* CS Burst Control Register */
+ u32 deadcycle_ctrl; /* CS Deadcycle Control Register */
+ u32 holdcycle_ctrl; /* CS Holdcycle Control Register */
+ u32 alt; /* Address Latch Timing Register */
+};
+
+int mpc512x_cs_config(int cs, u32 val);
+
#endif /* __ASM_POWERPC_MPC5121_H__ */
diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c
index c344438..112b4f6 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -436,3 +436,33 @@ void __init mpc512x_init(void)
mpc512x_restart_init();
mpc512x_psc_fifo_init();
}
+
+/**
+ * mpc512x_cs_config - Setup chip select configuration
+ * @cs: chip select number
+ * @val: chip select configuration value
+ *
+ * Perform chip select configuration for devices on LocalPlus Bus.
+ * Intended to dynamically reconfigure the chip select parameters
+ * for configurable devices on the bus.
+ */
+int mpc512x_cs_config(int cs, u32 val)
+{
+ static struct mpc512x_lpc __iomem *lpc;
+ struct device_node *np;
+
+ if (cs < 0 || cs > 7)
+ return -EINVAL;
+
+ if (!lpc) {
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc5121-lpc");
+ lpc = of_iomap(np, 0);
+ of_node_put(np);
+ if (!lpc)
+ return -ENOMEM;
+ }
+
+ out_be32(&lpc->cs_cfg[cs], val);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(mpc512x_cs_config);
--
1.7.5.4
^ permalink raw reply related
* Why is the e500v2 core not using cpuidle?
From: Thomas Waldecker @ 2013-02-01 12:06 UTC (permalink / raw)
To: Linux PPC dev mailing list (linuxppc-dev@lists.ozlabs.org)
Hi,
As part of my masterthesis I was just looking around the kernel=20
sources for cpuidle and figured out that the only CPU in the PowerPC=20
architecture using the cpuidle framework is the pseries.
I assume the e500v2 core is using the idle modes=20
in arch/powerpc/kernel/idle_e500.S
Why is there no support for the cpuidle framework?
How can I debug the e500 idle modes?=20
Are there any statistics?
I already ran PowerTOP on a QorIQ P2020 but it's almost useless=20
because the information is missing.
Kind regards,
Thomas Waldecker
^ permalink raw reply
* [RFC PATCH 5/5] powerpc: select HAVE_CONTEXT_TRACKING for pSeries
From: Li Zhong @ 2013-02-01 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhong, fweisbec, paulus, paulmck, linuxppc-dev
In-Reply-To: <1359714465-6297-1-git-send-email-zhong@linux.vnet.ibm.com>
Start context tracking support from pSeries.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig
index 837cf49..a9570fe 100644
--- a/arch/powerpc/platforms/pseries/Kconfig
+++ b/arch/powerpc/platforms/pseries/Kconfig
@@ -17,6 +17,7 @@ config PPC_PSERIES
select PPC_NATIVE
select PPC_PCI_CHOICE if EXPERT
select ZLIB_DEFLATE
+ select HAVE_CONTEXT_TRACKING
default y
config PPC_SPLPAR
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 4/5] powerpc: Use the new schedule_user API on userspace preemption
From: Li Zhong @ 2013-02-01 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhong, fweisbec, paulus, paulmck, linuxppc-dev
In-Reply-To: <1359714465-6297-1-git-send-email-zhong@linux.vnet.ibm.com>
This patch corresponds to
[PATCH] x86: Use the new schedule_user API on userspace preemption
commit 0430499ce9d78691f3985962021b16bf8f8a8048
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/context_tracking.h | 11 +++++++++++
arch/powerpc/kernel/entry_64.S | 3 ++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/context_tracking.h b/arch/powerpc/include/asm/context_tracking.h
index 3adccd8..2e042ba 100644
--- a/arch/powerpc/include/asm/context_tracking.h
+++ b/arch/powerpc/include/asm/context_tracking.h
@@ -1,6 +1,7 @@
#ifndef _ASM_POWERPC_CONTEXT_TRACKING_H
#define _ASM_POWERPC_CONTEXT_TRACKING_H
+#ifndef __ASSEMBLY__
#include <linux/context_tracking.h>
#include <asm/ptrace.h>
@@ -17,4 +18,14 @@ static inline void exception_exit(struct pt_regs *regs)
#endif
}
+#else /* __ASSEMBLY__ */
+
+#ifdef CONFIG_CONTEXT_TRACKING
+#define SCHEDULE_USER bl .schedule_user
+#else
+#define SCHEDULE_USER bl .schedule
+#endif
+
+#endif /* !__ASSEMBLY__ */
+
#endif
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 3d990d3..91f09ec 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -33,6 +33,7 @@
#include <asm/irqflags.h>
#include <asm/ftrace.h>
#include <asm/hw_irq.h>
+#include <asm/context_tracking.h>
/*
* System calls.
@@ -595,7 +596,7 @@ _GLOBAL(ret_from_except_lite)
andi. r0,r4,_TIF_NEED_RESCHED
beq 1f
bl .restore_interrupts
- bl .schedule
+ SCHEDULE_USER
b .ret_from_except_lite
1: bl .save_nvgprs
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 3/5] powerpc: Exit user context on notify resume
From: Li Zhong @ 2013-02-01 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhong, fweisbec, paulus, paulmck, linuxppc-dev
In-Reply-To: <1359714465-6297-1-git-send-email-zhong@linux.vnet.ibm.com>
This patch allows RCU usage in do_notify_resume, e.g. signal handling.
It corresponds to
[PATCH] x86: Exit RCU extended QS on notify resume
commit edf55fda35c7dc7f2d9241c3abaddaf759b457c6
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/kernel/signal.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/powerpc/kernel/signal.c b/arch/powerpc/kernel/signal.c
index 3b99711..c1eaea2 100644
--- a/arch/powerpc/kernel/signal.c
+++ b/arch/powerpc/kernel/signal.c
@@ -13,6 +13,7 @@
#include <linux/signal.h>
#include <linux/uprobes.h>
#include <linux/key.h>
+#include <linux/context_tracking.h>
#include <asm/hw_breakpoint.h>
#include <asm/uaccess.h>
#include <asm/unistd.h>
@@ -158,6 +159,8 @@ static int do_signal(struct pt_regs *regs)
void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
{
+ user_exit();
+
if (thread_info_flags & _TIF_UPROBE)
uprobe_notify_resume(regs);
@@ -168,6 +171,8 @@ void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
clear_thread_flag(TIF_NOTIFY_RESUME);
tracehook_notify_resume(regs);
}
+
+ user_enter();
}
long sys_sigaltstack(const stack_t __user *uss, stack_t __user *uoss,
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH 2/5] powerpc: Exception hooks for context tracking subsystem
From: Li Zhong @ 2013-02-01 10:27 UTC (permalink / raw)
To: linux-kernel; +Cc: Li Zhong, fweisbec, paulus, paulmck, linuxppc-dev
In-Reply-To: <1359714465-6297-1-git-send-email-zhong@linux.vnet.ibm.com>
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks for userspace RCU extended QS
commit 6ba3c97a38803883c2eee489505796cb0a727122
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/context_tracking.h | 20 +++++++
arch/powerpc/kernel/exceptions-64s.S | 4 +-
arch/powerpc/kernel/traps.c | 79 ++++++++++++++++++++-------
arch/powerpc/mm/fault.c | 15 ++++-
arch/powerpc/mm/hash_utils_64.c | 17 ++++++
5 files changed, 112 insertions(+), 23 deletions(-)
create mode 100644 arch/powerpc/include/asm/context_tracking.h
diff --git a/arch/powerpc/include/asm/context_tracking.h b/arch/powerpc/include/asm/context_tracking.h
new file mode 100644
index 0000000..3adccd8
--- /dev/null
+++ b/arch/powerpc/include/asm/context_tracking.h
@@ -0,0 +1,20 @@
+#ifndef _ASM_POWERPC_CONTEXT_TRACKING_H
+#define _ASM_POWERPC_CONTEXT_TRACKING_H
+
+#include <linux/context_tracking.h>
+#include <asm/ptrace.h>
+
+static inline void exception_enter(struct pt_regs *regs)
+{
+ user_exit();
+}
+
+static inline void exception_exit(struct pt_regs *regs)
+{
+#ifdef CONFIG_CONTEXT_TRACKING
+ if (user_mode(regs))
+ user_enter();
+#endif
+}
+
+#endif
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 4665e82..b877cf2 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -1184,15 +1184,17 @@ END_MMU_FTR_SECTION_IFCLR(MMU_FTR_SLB)
rlwimi r4,r0,32-13,30,30 /* becomes _PAGE_USER access bit */
ori r4,r4,1 /* add _PAGE_PRESENT */
rlwimi r4,r5,22+2,31-2,31-2 /* Set _PAGE_EXEC if trap is 0x400 */
+ addi r6,r1,STACK_FRAME_OVERHEAD
/*
* r3 contains the faulting address
* r4 contains the required access permissions
* r5 contains the trap number
+ * r6 contains the address of pt_regs
*
* at return r3 = 0 for success, 1 for page fault, negative for error
*/
- bl .hash_page /* build HPTE if possible */
+ bl .hash_page_ct /* build HPTE if possible */
cmpdi r3,0 /* see if hash_page succeeded */
/* Success */
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 3251840..d7c0414 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -59,6 +59,7 @@
#include <asm/fadump.h>
#include <asm/switch_to.h>
#include <asm/debug.h>
+#include <asm/context_tracking.h>
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
int (*__debugger)(struct pt_regs *regs) __read_mostly;
@@ -660,6 +661,8 @@ void machine_check_exception(struct pt_regs *regs)
{
int recover = 0;
+ exception_enter(regs);
+
__get_cpu_var(irq_stat).mce_exceptions++;
/* See if any machine dependent calls. In theory, we would want
@@ -674,7 +677,7 @@ void machine_check_exception(struct pt_regs *regs)
recover = cur_cpu_spec->machine_check(regs);
if (recover > 0)
- return;
+ goto exit;
#if defined(CONFIG_8xx) && defined(CONFIG_PCI)
/* the qspan pci read routines can cause machine checks -- Cort
@@ -684,20 +687,23 @@ void machine_check_exception(struct pt_regs *regs)
* -- BenH
*/
bad_page_fault(regs, regs->dar, SIGBUS);
- return;
+ goto exit;
#endif
if (debugger_fault_handler(regs))
- return;
+ goto exit;
if (check_io_access(regs))
- return;
+ goto exit;
die("Machine check", regs, SIGBUS);
/* Must die if the interrupt is not recoverable */
if (!(regs->msr & MSR_RI))
panic("Unrecoverable Machine check");
+
+exit:
+ exception_exit(regs);
}
void SMIException(struct pt_regs *regs)
@@ -707,20 +713,29 @@ void SMIException(struct pt_regs *regs)
void unknown_exception(struct pt_regs *regs)
{
+ exception_enter(regs);
+
printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n",
regs->nip, regs->msr, regs->trap);
_exception(SIGTRAP, regs, 0, 0);
+
+ exception_exit(regs);
}
void instruction_breakpoint_exception(struct pt_regs *regs)
{
+ exception_enter(regs);
+
if (notify_die(DIE_IABR_MATCH, "iabr_match", regs, 5,
5, SIGTRAP) == NOTIFY_STOP)
- return;
+ goto exit;
if (debugger_iabr_match(regs))
- return;
+ goto exit;
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
+
+exit:
+ exception_exit(regs);
}
void RunModeException(struct pt_regs *regs)
@@ -730,15 +745,20 @@ void RunModeException(struct pt_regs *regs)
void __kprobes single_step_exception(struct pt_regs *regs)
{
+ exception_enter(regs);
+
clear_single_step(regs);
if (notify_die(DIE_SSTEP, "single_step", regs, 5,
5, SIGTRAP) == NOTIFY_STOP)
- return;
+ goto exit;
if (debugger_sstep(regs))
- return;
+ goto exit;
_exception(SIGTRAP, regs, TRAP_TRACE, regs->nip);
+
+exit:
+ exception_exit(regs);
}
/*
@@ -993,32 +1013,34 @@ void __kprobes program_check_exception(struct pt_regs *regs)
unsigned int reason = get_reason(regs);
extern int do_mathemu(struct pt_regs *regs);
+ exception_enter(regs);
+
/* We can now get here via a FP Unavailable exception if the core
* has no FPU, in that case the reason flags will be 0 */
if (reason & REASON_FP) {
/* IEEE FP exception */
parse_fpe(regs);
- return;
+ goto exit;
}
if (reason & REASON_TRAP) {
/* Debugger is first in line to stop recursive faults in
* rcu_lock, notify_die, or atomic_notifier_call_chain */
if (debugger_bpt(regs))
- return;
+ goto exit;
/* trap exception */
if (notify_die(DIE_BPT, "breakpoint", regs, 5, 5, SIGTRAP)
== NOTIFY_STOP)
- return;
+ goto exit;
if (!(regs->msr & MSR_PR) && /* not user-mode */
report_bug(regs->nip, regs) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
- return;
+ goto exit;
}
_exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip);
- return;
+ goto exit;
}
/* We restore the interrupt state now */
@@ -1036,16 +1058,16 @@ void __kprobes program_check_exception(struct pt_regs *regs)
switch (do_mathemu(regs)) {
case 0:
emulate_single_step(regs);
- return;
+ goto exit;
case 1: {
int code = 0;
code = __parse_fpscr(current->thread.fpscr.val);
_exception(SIGFPE, regs, code, regs->nip);
- return;
+ goto exit;
}
case -EFAULT:
_exception(SIGSEGV, regs, SEGV_MAPERR, regs->nip);
- return;
+ goto exit;
}
/* fall through on any other errors */
#endif /* CONFIG_MATH_EMULATION */
@@ -1056,10 +1078,10 @@ void __kprobes program_check_exception(struct pt_regs *regs)
case 0:
regs->nip += 4;
emulate_single_step(regs);
- return;
+ goto exit;
case -EFAULT:
_exception(SIGSEGV, regs, SEGV_MAPERR, regs->nip);
- return;
+ goto exit;
}
}
@@ -1067,12 +1089,17 @@ void __kprobes program_check_exception(struct pt_regs *regs)
_exception(SIGILL, regs, ILL_PRVOPC, regs->nip);
else
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
+
+exit:
+ exception_exit(regs);
}
void alignment_exception(struct pt_regs *regs)
{
int sig, code, fixed = 0;
+ exception_enter(regs);
+
/* We restore the interrupt state now */
if (!arch_irq_disabled_regs(regs))
local_irq_enable();
@@ -1084,7 +1111,7 @@ void alignment_exception(struct pt_regs *regs)
if (fixed == 1) {
regs->nip += 4; /* skip over emulated instruction */
emulate_single_step(regs);
- return;
+ goto exit;
}
/* Operand address was bad */
@@ -1099,6 +1126,9 @@ void alignment_exception(struct pt_regs *regs)
_exception(sig, regs, code, regs->dar);
else
bad_page_fault(regs, regs->dar, sig);
+
+exit:
+ exception_exit(regs);
}
void StackOverflow(struct pt_regs *regs)
@@ -1127,23 +1157,32 @@ void trace_syscall(struct pt_regs *regs)
void kernel_fp_unavailable_exception(struct pt_regs *regs)
{
+ exception_enter(regs);
+
printk(KERN_EMERG "Unrecoverable FP Unavailable Exception "
"%lx at %lx\n", regs->trap, regs->nip);
die("Unrecoverable FP Unavailable Exception", regs, SIGABRT);
+
+ exception_exit(regs);
}
void altivec_unavailable_exception(struct pt_regs *regs)
{
+ exception_enter(regs);
+
if (user_mode(regs)) {
/* A user program has executed an altivec instruction,
but this kernel doesn't support altivec. */
_exception(SIGILL, regs, ILL_ILLOPC, regs->nip);
- return;
+ goto exit;
}
printk(KERN_EMERG "Unrecoverable VMX/Altivec Unavailable Exception "
"%lx at %lx\n", regs->trap, regs->nip);
die("Unrecoverable VMX/Altivec Unavailable Exception", regs, SIGABRT);
+
+exit:
+ exception_exit(regs);
}
void vsx_unavailable_exception(struct pt_regs *regs)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 3a8489a..b1b9542 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -42,6 +42,7 @@
#include <asm/tlbflush.h>
#include <asm/siginfo.h>
#include <asm/debug.h>
+#include <asm/context_tracking.h>
#include <mm/mmu_decl.h>
#include "icswx.h"
@@ -193,8 +194,8 @@ static int mm_fault_error(struct pt_regs *regs, unsigned long addr, int fault)
* The return value is 0 if the fault was handled, or the signal
* number if this is a kernel fault that can't be handled here.
*/
-int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
- unsigned long error_code)
+static int __kprobes __do_page_fault(struct pt_regs *regs,
+ unsigned long address, unsigned long error_code)
{
struct vm_area_struct * vma;
struct mm_struct *mm = current->mm;
@@ -475,6 +476,16 @@ bad_area_nosemaphore:
}
+int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
+ unsigned long error_code)
+{
+ int ret;
+ exception_enter(regs);
+ ret = __do_page_fault(regs, address, error_code);
+ exception_exit(regs);
+ return ret;
+}
+
/*
* bad_page_fault is called when we have a bad access from the kernel.
* It is called from the DSI and ISI handlers in head.S and from some
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 3a292be..447e5a7 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -55,6 +55,7 @@
#include <asm/code-patching.h>
#include <asm/fadump.h>
#include <asm/firmware.h>
+#include <asm/context_tracking.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -1083,6 +1084,18 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
}
EXPORT_SYMBOL_GPL(hash_page);
+int hash_page_ct(unsigned long ea, unsigned long access,
+ unsigned long trap, struct pt_regs *regs)
+{
+ int ret;
+
+ exception_enter(regs);
+ ret = hash_page(ea, access, trap);
+ exception_exit(regs);
+
+ return ret;
+}
+
void hash_preload(struct mm_struct *mm, unsigned long ea,
unsigned long access, unsigned long trap)
{
@@ -1194,6 +1207,8 @@ void flush_hash_range(unsigned long number, int local)
*/
void low_hash_fault(struct pt_regs *regs, unsigned long address, int rc)
{
+ exception_enter(regs);
+
if (user_mode(regs)) {
#ifdef CONFIG_PPC_SUBPAGE_PROT
if (rc == -2)
@@ -1203,6 +1218,8 @@ void low_hash_fault(struct pt_regs *regs, unsigned long address, int rc)
_exception(SIGBUS, regs, BUS_ADRERR, address);
} else
bad_page_fault(regs, address, SIGBUS);
+
+ exception_exit(regs);
}
#ifdef CONFIG_DEBUG_PAGEALLOC
--
1.7.9.5
^ permalink raw reply related
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