* Re: [PATCH] of/device: Don't register disabled devices
From: Grant Likely @ 2011-01-07 17:23 UTC (permalink / raw)
To: David Gibson, Blanchard, Hollis, devicetree-discuss, linuxppc-dev,
linux-kernel, Scott Wood, Benjamin Herrenschmidt, Saxena, Deepak
In-Reply-To: <20110105233535.GB8846@yookeroo>
On Thu, Jan 06, 2011 at 10:35:35AM +1100, David Gibson wrote:
> On Wed, Jan 05, 2011 at 02:53:27PM -0800, Blanchard, Hollis wrote:
> > On 01/03/2011 03:01 PM, Grant Likely wrote:
> > > Device nodes with the property status="disabled" are not usable and so
> > > don't register them when parsing the device tree for devices.
> > >
> > This is great and all, but a fair amount of driver code explicitly
> > searches the tree, rather than registering a probe function. That's why
> > our earlier patches in this area were more comprehensive.
As your patch set shows, the total set isn't unmanageable, and the
preference for new code is to use the device model infrastructure if
at all possible.
> >
> > What are your thoughts on handling those cases?
>
> One by one. Trying to handle the explicit searches automagically is
> just asking for trouble.
Just as David says, the special cases are... well... special.
Anything making decisions about registering devices needs to follow
the status!="okay" rules.
g.
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2011-01-07 16:44 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA900@na3-mail.mgc.mentorg.com>
On Fri, Jan 7, 2011 at 9:00 AM, Blanchard, Hollis
<Hollis_Blanchard@mentor.com> wrote:
> On 01/07/2011 07:48 AM, Grant Likely wrote:
>> Actually, for a while now the kernel has been moving towards userspace
>> being responsible for device identification. =A0That's what udev is for.
>> =A0 The kernel udev looks at the available information when a device is
>> registered/bound, and it creates useful symlinks to the dynamically
>> assigned major/minor devices. =A0The rest of userspace doesn't need to
>> know about it; it can simply use the symlinks in /dev, but it is
>> appropriate to let udev figure out the correct naming.
> Can you point out an example of how this is done for Open Firmware
> devices currently?
Nope, because while it has been a theoretical concern, in practice the
issue hasn't come up on any of the hardware I've worked on or I've
seen patches for. Mostly this is because the device tree
representations are internally self consistent;
dependencies/connections are explicitly expressed with phandles or
full paths which eliminates any need for enumeration in all the cases
I've had to deal with.
What I can point at is that almost all Linux character, block, and
network devices are assigned major/minor numbers in a first-come
first-served basis. This of course causes problems for userspace
applications who need a stable handle to a specific device. Device
renaming turned out to be horribly complex, which is why for character
and block devices the whole problem was punted out into userspace for
udev to handle with symlinks. Network device unfortunately don't
appear in /dev, so they are stuck with device renaming until some form
of network device name aliasing is created.
As Scott also says, I know from experience that trying to maintain
enumeration in the device tree nodes themselves, and getting device
drivers to request specific numbers is painful, complex and fragile.
If I could go back in time I would never have attempted it on the
mpc5200 psc (serial) devices.
> In particular, how are the udev rules supposed to
> operate? They get a device path, use that to find additional information
> in /proc/device-tree (hope that's mounted), and then what? Do we
> hardcode the block addresses in the rules, for example @1400 and @2400?
You can do that; but from the little bit I know about your use case,
user-space visible references would be better explicitly expressed in
the aliases node. It isn't currently, but matching aliases can easily
be added to the device's UEVENT property in /sys. That is probably
the approach I would investigate for getting instance information out
to udev so it can create useful symlinks to the /dev device files.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-07 16:00 UTC (permalink / raw)
To: Grant Likely; +Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <AANLkTikROM4MtmLYEK_6ndRzbDJ3xjMM5iSPzDhpRWLy@mail.gmail.com>
On 01/07/2011 07:48 AM, Grant Likely wrote:
> Actually, for a while now the kernel has been moving towards userspace
> being responsible for device identification. That's what udev is for.
> The kernel udev looks at the available information when a device is
> registered/bound, and it creates useful symlinks to the dynamically
> assigned major/minor devices. The rest of userspace doesn't need to
> know about it; it can simply use the symlinks in /dev, but it is
> appropriate to let udev figure out the correct naming.
Can you point out an example of how this is done for Open Firmware=20
devices currently? In particular, how are the udev rules supposed to=20
operate? They get a device path, use that to find additional information =
in /proc/device-tree (hope that's mounted), and then what? Do we=20
hardcode the block addresses in the rules, for example @1400 and @2400?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Grant Likely @ 2011-01-07 15:48 UTC (permalink / raw)
To: Blanchard, Hollis
Cc: Scott Wood, Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <DD7A9A95166BF4418C4C1EB2033B6EE2038FA8FD@na3-mail.mgc.mentorg.com>
On Thu, Jan 6, 2011 at 2:52 PM, Blanchard, Hollis
<Hollis_Blanchard@mentor.com> wrote:
> On 01/05/2011 03:07 PM, Scott Wood wrote:
>> On Wed, 5 Jan 2011 14:49:40 -0800
>> "Blanchard, Hollis"<Hollis_Blanchard@mentor.com> =A0wrote:
>>
>>> On 01/05/2011 02:09 PM, Scott Wood wrote:
>>>> On Wed, 5 Jan 2011 15:58:55 -0600
>>>> Meador Inge<meador_inge@mentor.com> =A0 wrote:
>>>>
>>>>> We need some sort of mapping between a message register and a message
>>>>> register number so that the message registers can be referenced throu=
gh
>>>>> some sort of API (e.g. 'mpic_msgr_read(0)'). =A0One way to do that wo=
uld
>>>>> be by putting an order on the registers. =A0Maybe there is a better w=
ay,
>>>>> though ...
>>>> A message register is uniquely identified by a reference to the device
>>>> tree node, plus a 0-3 index into that node's message registers.
>>> Really what we're talking about is software configuration, not hardware
>>> description.
>> Part of that software configuration involves identifying the hardware
>> being referenced.
>>
>>> We've gone back and forth on representing this information
>>> in the device tree, and most recently decided against it. Outside the
>>> kernel, a device node reference isn't really practical.
>> Global enumeration isn't much fun either. =A0For something like this
>> where it's very unlikely that additional MPIC message units will be
>> added to the system dynamically, it's managable, but it's not a good
>> habit to get into. =A0Look at the pain that's been caused by such
>> assumptions in the i2c subsystem, in kernel interrupt management, etc.
>>
>> A reference to a node is just a pointer to a software message driver
>> object, which can be obtained from looking up an alias. =A0It's a little
>> less simple than just using a number, but it's not impractical. It also
>> provides a natural place to put a layer of indirection in the code that
>> isolates the upper-layer protocol from the details of what sort of
>> message transport it is using.
>>
>> Now, if you don't care about this, and want to just use numbers in your
>> application, go ahead. =A0But I don't think that such an assumption
>> should go into the device tree binding. =A0Have the software number the
>> message register banks in increasing physical address order, or based
>> on numbered aliases similar to how U-Boot enumerates ethernet nodes, or
>> something similar.
> Using physical addresses doesn't solve the enumeration problem either,
> but I think it's beside the point: userspace must refer to the device.
> There is a rich history of userspace *not* walking /proc/device-tree in
> order to refer to a physical device. Are you suggesting this case is
> special?
Actually, for a while now the kernel has been moving towards userspace
being responsible for device identification. That's what udev is for.
The kernel udev looks at the available information when a device is
registered/bound, and it creates useful symlinks to the dynamically
assigned major/minor devices. The rest of userspace doesn't need to
know about it; it can simply use the symlinks in /dev, but it is
appropriate to let udev figure out the correct naming.
Also, if you want to do global enumeration of devices, the accepted
way to do so is to use properties in the /aliases node in the form:
'<type><number> =3D "/path/to/device/node";'
g.
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Rafael Beims @ 2011-01-07 10:00 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: michael, linuxppc-dev, scottwood, RFeany
In-Reply-To: <OFB0350E05.07B070EF-ONC1257810.005CAF17-C1257810.005CAF19@transmode.se>
On Thu, Jan 6, 2011 at 2:52 PM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
> The 8xx tlbil_va should not be needed in recent 2.6 after I fixed the 8xx=
TLB code
> to workaround the dcbst bug there instead. See
> http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dco=
mmitdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98=
c37d03a4a7c5a3f8b1e3b8e5
>
> Not sure what release it went into though.
>
> =A0Jocke
I saw that the commit you mention did make it in the 2.6.33 version. I
will try to boot it here and see if the problem is also solved in this
version.
Rafael
^ permalink raw reply
* [PATCH] powerpc: add support for multiple 85xx RapidIO development boards
From: Alex Dubov @ 2011-01-07 8:27 UTC (permalink / raw)
To: linuxppc-dev
Many RapidIO development boards do not require any board/vendor specific=0A=
tweaking at kernel start, and can rely on the flattened device tree for=0Aa=
ll their hardware configuration needs.=0A=0AThis patch adds support for "ge=
neric,mpc85xx-riodev" compatible boards=0Awith PCI disabled by default and =
RapidIO enabled. It will also try to=0Aread a "vendor" property from the ro=
ot of device tree to provide a possibly=0Auseful bit of information in the =
/proc/cpuinfo.=0A=0ASigned-off-by: Alex Dubov <oakad@yahoo.com>=0A---=0A ar=
ch/powerpc/configs/85xx/mpc85xx_riodev_defconfig | 82 ++++++++++++++=0A a=
rch/powerpc/platforms/85xx/Kconfig | 9 ++=0A arch/powerpc=
/platforms/85xx/Makefile | 1 +=0A arch/powerpc/platforms/8=
5xx/mpc85xx_riodev.c | 116 ++++++++++++++++++++=0A 4 files changed, =
208 insertions(+), 0 deletions(-)=0A create mode 100644 arch/powerpc/config=
s/85xx/mpc85xx_riodev_defconfig=0A create mode 100644 arch/powerpc/platform=
s/85xx/mpc85xx_riodev.c=0A=0Adiff --git a/arch/powerpc/configs/85xx/mpc85xx=
_riodev_defconfig b/arch/powerpc/configs/85xx/mpc85xx_riodev_defconfig=0Ane=
w file mode 100644=0Aindex 0000000..5d0596e=0A--- /dev/null=0A+++ b/arch/po=
werpc/configs/85xx/mpc85xx_riodev_defconfig=0A@@ -0,0 +1,82 @@=0A+CONFIG_PP=
C_85xx=3Dy=0A+CONFIG_EXPERIMENTAL=3Dy=0A+CONFIG_SYSVIPC=3Dy=0A+CONFIG_LOG_B=
UF_SHIFT=3D14=0A+CONFIG_BLK_DEV_INITRD=3Dy=0A+# CONFIG_CC_OPTIMIZE_FOR_SIZE=
is not set=0A+CONFIG_EMBEDDED=3Dy=0A+CONFIG_MODULES=3Dy=0A+CONFIG_MODULE_U=
NLOAD=3Dy=0A+# CONFIG_BLK_DEV_BSG is not set=0A+CONFIG_MPC85xx_RIODEV=3Dy=
=0A+CONFIG_HIGHMEM=3Dy=0A+CONFIG_NO_HZ=3Dy=0A+CONFIG_HIGH_RES_TIMERS=3Dy=0A=
+CONFIG_BINFMT_MISC=3Dy=0A+CONFIG_MATH_EMULATION=3Dy=0A+CONFIG_SPARSE_IRQ=
=3Dy=0A+# CONFIG_SECCOMP is not set=0A+CONFIG_PCI=3Dn=0A+CONFIG_PCIEPORTBUS=
=3Dn=0A+# CONFIG_PCIEASPM is not set=0A+CONFIG_NET=3Dy=0A+CONFIG_PACKET=3Dy=
=0A+CONFIG_UNIX=3Dy=0A+CONFIG_XFRM_USER=3Dy=0A+CONFIG_INET=3Dy=0A+CONFIG_IP=
_MULTICAST=3Dy=0A+CONFIG_IP_PNP=3Dy=0A+CONFIG_IP_PNP_DHCP=3Dy=0A+CONFIG_IP_=
PNP_BOOTP=3Dy=0A+CONFIG_SYN_COOKIES=3Dy=0A+# CONFIG_INET_LRO is not set=0A+=
# CONFIG_IPV6 is not set=0A+CONFIG_UEVENT_HELPER_PATH=3D"/sbin/hotplug"=0A+=
# CONFIG_FW_LOADER is not set=0A+CONFIG_MTD=3Dy=0A+CONFIG_MTD_PARTITIONS=3D=
y=0A+CONFIG_MTD_OF_PARTS=3Dy=0A+CONFIG_MTD_CHAR=3Dy=0A+CONFIG_MTD_BLKDEVS=
=3Dy=0A+CONFIG_MTD_CFI=3Dy=0A+CONFIG_MTD_CFI_AMDSTD=3Dy=0A+CONFIG_MTD_PHYSM=
AP_OF=3Dy=0A+CONFIG_MTD_NAND_ECC_SMC=3Dy=0A+CONFIG_MTD_NAND=3Dy=0A+CONFIG_M=
TD_NAND_FSL_UPM=3Dy=0A+CONFIG_PROC_DEVICETREE=3Dy=0A+CONFIG_BLK_DEV_LOOP=3D=
y=0A+CONFIG_BLK_DEV_RAM=3Dy=0A+CONFIG_BLK_DEV_RAM_SIZE=3D32768=0A+CONFIG_NE=
TDEVICES=3Dy=0A+CONFIG_NET_ETHERNET=3Dy=0A+CONFIG_MII=3Dy=0A+CONFIG_GIANFAR=
=3Dy=0A+# CONFIG_INPUT_MOUSEDEV is not set=0A+# CONFIG_INPUT_KEYBOARD is no=
t set=0A+# CONFIG_INPUT_MOUSE is not set=0A+# CONFIG_SERIO is not set=0A+# =
CONFIG_VT is not set=0A+CONFIG_SERIAL_8250=3Dy=0A+CONFIG_SERIAL_8250_CONSOL=
E=3Dy=0A+# CONFIG_HW_RANDOM is not set=0A+CONFIG_I2C=3Dy=0A+CONFIG_I2C_CHAR=
DEV=3Dy=0A+CONFIG_I2C_MPC=3Dy=0A+CONFIG_VIDEO_OUTPUT_CONTROL=3Dy=0A+# CONFI=
G_USB_SUPPORT is not set=0A+CONFIG_INOTIFY=3Dy=0A+CONFIG_PROC_KCORE=3Dy=0A+=
CONFIG_TMPFS=3Dy=0A+CONFIG_JFFS2_FS=3Dy=0A+CONFIG_NFS_FS=3Dy=0A+CONFIG_ROOT=
_NFS=3Dy=0A+CONFIG_PARTITION_ADVANCED=3Dy=0A+# CONFIG_MSDOS_PARTITION is no=
t set=0A+CONFIG_DEBUG_KERNEL=3Dy=0A+CONFIG_DETECT_HUNG_TASK=3Dy=0A+CONFIG_D=
EBUG_MUTEXES=3Dy=0A+# CONFIG_DEBUG_BUGVERBOSE is not set=0A+# CONFIG_RCU_CP=
U_STALL_DETECTOR is not set=0A+CONFIG_SYSCTL_SYSCALL_CHECK=3Dy=0A+# CONFIG_=
CRYPTO_ANSI_CPRNG is not set=0Adiff --git a/arch/powerpc/platforms/85xx/Kco=
nfig b/arch/powerpc/platforms/85xx/Kconfig=0Aindex b6976e1..be48db0 100644=
=0A--- a/arch/powerpc/platforms/85xx/Kconfig=0A+++ b/arch/powerpc/platforms=
/85xx/Kconfig=0A@@ -97,6 +97,15 @@ config XES_MPC85xx=0A =09 Manufacturer:=
Extreme Engineering Solutions, Inc.=0A =09 URL: <http://www.xes-inc.com/>=
=0A =0A+config MPC85xx_RIODEV=0A+=09bool "Generic MPC85xx board with serial=
RapidIO"=0A+=09select DEFAULT_UIMAGE=0A+=09select HAS_RAPIDIO=0A+=09help=
=0A+=09 This option enables support for one of many RapidIO development=0A=
+=09 boards, which do not need any vendor specific kernel tweaks and=0A+=
=09 fully rely on flattened device tree for the hardware configuration.=0A=
+=0A config STX_GP3=0A =09bool "Silicon Turnkey Express GP3"=0A =09help=0Ad=
iff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/8=
5xx/Makefile=0Aindex dd70db7..228f0f9 100644=0A--- a/arch/powerpc/platforms=
/85xx/Makefile=0A+++ b/arch/powerpc/platforms/85xx/Makefile=0A@@ -14,6 +14,=
7 @@ obj-$(CONFIG_P1022_DS) +=3D p1022_ds.o=0A obj-$(CONFIG_P3041_DS) =
+=3D p3041_ds.o corenet_ds.o=0A obj-$(CONFIG_P4080_DS) +=3D p4080_ds.o =
corenet_ds.o=0A obj-$(CONFIG_P5020_DS) +=3D p5020_ds.o corenet_ds.o=0A+o=
bj-$(CONFIG_MPC85xx_RIODEV) +=3D mpc85xx_riodev.o=0A obj-$(CONFIG_STX_GP3)=
=09 +=3D stx_gp3.o=0A obj-$(CONFIG_TQM85xx)=09 +=3D tqm85xx.o=0A obj-$(CO=
NFIG_SBC8560) +=3D sbc8560.o=0Adiff --git a/arch/powerpc/platforms/85xx=
/mpc85xx_riodev.c b/arch/powerpc/platforms/85xx/mpc85xx_riodev.c=0Anew file=
mode 100644=0Aindex 0000000..415f22b=0A--- /dev/null=0A+++ b/arch/powerpc/=
platforms/85xx/mpc85xx_riodev.c=0A@@ -0,0 +1,116 @@=0A+/*=0A+ * Based on tq=
m85xx.c and other similar files.=0A+ *=0A+ * Copyright (c) 2011 Alex Dubov =
<oakad@yahoo.com>=0A+ *=0A+ * This program is free software; you can redist=
ribute it and/or modify it=0A+ * under the terms of the GNU General Pub=
lic License as published by the=0A+ * Free Software Foundation; either ver=
sion 2 of the License, or (at your=0A+ * option) any later version.=0A+ */=
=0A+=0A+#include <linux/seq_file.h>=0A+#include <linux/of_platform.h>=0A+=
=0A+#include <asm/machdep.h>=0A+#include <asm/mpic.h>=0A+#include <asm/udbg=
.h>=0A+=0A+#include <sysdev/fsl_soc.h>=0A+=0A+static void __init mpc85xx_ri=
odev_pic_init(void)=0A+{=0A+=09struct mpic *mpic;=0A+=09struct resource r;=
=0A+=09struct device_node *np;=0A+=0A+=09np =3D of_find_node_by_type(NULL, =
"open-pic");=0A+=09if (!np) {=0A+=09=09printk(KERN_ERR "Could not find open=
-pic node\n");=0A+=09=09return;=0A+=09}=0A+=0A+=09if (of_address_to_resourc=
e(np, 0, &r)) {=0A+=09=09printk(KERN_ERR "Could not map mpic register space=
\n");=0A+=09=09of_node_put(np);=0A+=09=09return;=0A+=09}=0A+=0A+=09mpic =3D=
mpic_alloc(np, r.start,=0A+=09=09=09MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC=
_BIG_ENDIAN,=0A+=09=09=090, 256, " OpenPIC ");=0A+=09BUG_ON(mpic =3D=3D NU=
LL);=0A+=09of_node_put(np);=0A+=0A+=09mpic_init(mpic);=0A+}=0A+=0A+/*=0A+ *=
Setup the architecture=0A+ */=0A+static void __init mpc85xx_riodev_setup_a=
rch(void)=0A+{=0A+}=0A+=0A+static void mpc85xx_riodev_show_cpuinfo(struct s=
eq_file *m)=0A+{=0A+=09struct device_node *root =3D NULL;=0A+=09const char =
*vendor_str =3D NULL;=0A+=09uint pvid, svid, phid1;=0A+=0A+=09pvid =3D mfsp=
r(SPRN_PVR);=0A+=09svid =3D mfspr(SPRN_SVR);=0A+=0A+=09root =3D of_find_nod=
e_by_path("/");=0A+=09if (root) {=0A+=09=09vendor_str =3D of_get_property(r=
oot, "vendor", NULL);=0A+=09=09of_node_put(root);=0A+=09}=0A+=0A+=09if (!ve=
ndor_str)=0A+=09=09vendor_str =3D "generic";=0A+=0A+=09seq_printf(m, "vendo=
r\t\t: %s\n", vendor_str);=0A+=09seq_printf(m, "PVR\t\t: 0x%x\n", pvid);=0A=
+=09seq_printf(m, "SVR\t\t: 0x%x\n", svid);=0A+=0A+=09/* Display cpu Pll se=
tting */=0A+=09phid1 =3D mfspr(SPRN_HID1);=0A+=09seq_printf(m, "PLL setting=
\t: 0x%x\n", ((phid1 >> 24) & 0x3f));=0A+}=0A+=0A+static struct of_device_i=
d __initdata of_bus_ids[] =3D {=0A+=09{ .compatible =3D "simple-bus", },=0A=
+=09{ .compatible =3D "gianfar", },=0A+=09{},=0A+};=0A+=0A+static int __ini=
t declare_of_platform_devices(void)=0A+{=0A+=09of_platform_bus_probe(NULL, =
of_bus_ids, NULL);=0A+=0A+=09return 0;=0A+}=0A+machine_device_initcall(mpc8=
5xx_riodev, declare_of_platform_devices);=0A+=0A+/*=0A+ * Called very early=
, device-tree isn't unflattened=0A+ */=0A+static int __init mpc85xx_riodev_=
probe(void)=0A+{=0A+=09unsigned long root =3D of_get_flat_dt_root();=0A+=0A=
+=09return of_flat_dt_is_compatible(root, "generic,mpc85xx-riodev");=0A+}=
=0A+=0A+define_machine(mpc85xx_riodev) {=0A+=09.name=09=09=09=3D "MPC85xx w=
/ SRIO",=0A+=09.probe=09=09=09=3D mpc85xx_riodev_probe,=0A+=09.setup_arch=
=09=09=3D mpc85xx_riodev_setup_arch,=0A+=09.init_IRQ=09=09=3D mpc85xx_riode=
v_pic_init,=0A+=09.show_cpuinfo=09=09=3D mpc85xx_riodev_show_cpuinfo,=0A+=
=09.get_irq=09=09=3D mpic_get_irq,=0A+=09.restart=09=09=3D fsl_rstcr_restar=
t,=0A+=09.calibrate_decr=09=09=3D generic_calibrate_decr,=0A+=09.progress=
=09=09=3D udbg_progress,=0A+};=0A-- =0A1.7.3.2=0A=0A=0A=0A=0A
^ permalink raw reply
* [PATCH 8/8] powerpc/kdump: Disable ftrace during kexec
From: Anton Blanchard @ 2011-01-07 4:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
We should disable ftrace during kexec, some of the tracers are very invasive
and we do not want them going off while doing the low level work of swapping
one kernel out for another. This mirrors what we do on x86.
Even though we cannot return from a kexec on powerpc (since we do not implement
CONFIG_KEXEC_JUMP), add the restore code in case we do one day.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:52:02.012644243 +1100
@@ -15,6 +15,7 @@
#include <linux/memblock.h>
#include <linux/of.h>
#include <linux/irq.h>
+#include <linux/ftrace.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -82,8 +83,14 @@ void arch_crash_save_vmcoreinfo(void)
*/
void machine_kexec(struct kimage *image)
{
+ int save_ftrace_enabled;
+
+ save_ftrace_enabled = __ftrace_enabled_save();
+
default_machine_kexec(image);
+ __ftrace_enabled_restore(save_ftrace_enabled);
+
/* Fall back to normal restart if we're still alive. */
machine_restart(NULL);
for(;;);
^ permalink raw reply
* [PATCH 7/8] powerpc/kdump: Move crash_kexec_stop_spus to kdump crash handler
From: Anton Blanchard @ 2011-01-07 3:59 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
Use the crash handler hooks to run the SPU stop code, just like we do for
ehea and cell RAS code.
While I'm here I noticed "CPUSs reliabally"
so fix the spelling MISTAKESs reliabally.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/kernel/crash.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/crash.c 2010-12-13 22:52:03.475242242 +1100
+++ powerpc.git/arch/powerpc/kernel/crash.c 2011-01-07 12:52:00.812606428 +1100
@@ -48,7 +48,7 @@ int crashing_cpu = -1;
static cpumask_t cpus_in_crash = CPU_MASK_NONE;
cpumask_t cpus_in_sr = CPU_MASK_NONE;
-#define CRASH_HANDLER_MAX 2
+#define CRASH_HANDLER_MAX 3
/* NULL terminated list of shutdown handles */
static crash_shutdown_t crash_shutdown_handles[CRASH_HANDLER_MAX+1];
static DEFINE_SPINLOCK(crash_handlers_lock);
@@ -125,7 +125,7 @@ static void crash_kexec_prepare_cpus(int
smp_wmb();
/*
- * FIXME: Until we will have the way to stop other CPUSs reliabally,
+ * FIXME: Until we will have the way to stop other CPUs reliably,
* the crash CPU will send an IPI and wait for other CPUs to
* respond.
* Delay of at least 10 seconds.
@@ -254,72 +254,6 @@ void crash_kexec_secondary(struct pt_reg
cpus_in_sr = CPU_MASK_NONE;
}
#endif
-#ifdef CONFIG_SPU_BASE
-
-#include <asm/spu.h>
-#include <asm/spu_priv1.h>
-
-struct crash_spu_info {
- struct spu *spu;
- u32 saved_spu_runcntl_RW;
- u32 saved_spu_status_R;
- u32 saved_spu_npc_RW;
- u64 saved_mfc_sr1_RW;
- u64 saved_mfc_dar;
- u64 saved_mfc_dsisr;
-};
-
-#define CRASH_NUM_SPUS 16 /* Enough for current hardware */
-static struct crash_spu_info crash_spu_info[CRASH_NUM_SPUS];
-
-static void crash_kexec_stop_spus(void)
-{
- struct spu *spu;
- int i;
- u64 tmp;
-
- for (i = 0; i < CRASH_NUM_SPUS; i++) {
- if (!crash_spu_info[i].spu)
- continue;
-
- spu = crash_spu_info[i].spu;
-
- crash_spu_info[i].saved_spu_runcntl_RW =
- in_be32(&spu->problem->spu_runcntl_RW);
- crash_spu_info[i].saved_spu_status_R =
- in_be32(&spu->problem->spu_status_R);
- crash_spu_info[i].saved_spu_npc_RW =
- in_be32(&spu->problem->spu_npc_RW);
-
- crash_spu_info[i].saved_mfc_dar = spu_mfc_dar_get(spu);
- crash_spu_info[i].saved_mfc_dsisr = spu_mfc_dsisr_get(spu);
- tmp = spu_mfc_sr1_get(spu);
- crash_spu_info[i].saved_mfc_sr1_RW = tmp;
-
- tmp &= ~MFC_STATE1_MASTER_RUN_CONTROL_MASK;
- spu_mfc_sr1_set(spu, tmp);
-
- __delay(200);
- }
-}
-
-void crash_register_spus(struct list_head *list)
-{
- struct spu *spu;
-
- list_for_each_entry(spu, list, full_list) {
- if (WARN_ON(spu->number >= CRASH_NUM_SPUS))
- continue;
-
- crash_spu_info[spu->number].spu = spu;
- }
-}
-
-#else
-static inline void crash_kexec_stop_spus(void)
-{
-}
-#endif /* CONFIG_SPU_BASE */
/*
* Register a function to be called on shutdown. Only use this if you
@@ -439,8 +373,6 @@ void default_machine_crash_shutdown(stru
crash_shutdown_cpu = -1;
__debugger_fault_handler = old_handler;
- crash_kexec_stop_spus();
-
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(1, 0);
}
Index: powerpc.git/arch/powerpc/platforms/cell/spu_base.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/spu_base.c 2010-12-13 22:52:03.495242622 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/spu_base.c 2011-01-07 12:52:00.812606428 +1100
@@ -727,6 +727,67 @@ static ssize_t spu_stat_show(struct sys_
static SYSDEV_ATTR(stat, 0644, spu_stat_show, NULL);
+struct crash_spu_info {
+ struct spu *spu;
+ u32 saved_spu_runcntl_RW;
+ u32 saved_spu_status_R;
+ u32 saved_spu_npc_RW;
+ u64 saved_mfc_sr1_RW;
+ u64 saved_mfc_dar;
+ u64 saved_mfc_dsisr;
+};
+
+#define CRASH_NUM_SPUS 16 /* Enough for current hardware */
+static struct crash_spu_info crash_spu_info[CRASH_NUM_SPUS];
+
+static void crash_kexec_stop_spus(void)
+{
+ struct spu *spu;
+ int i;
+ u64 tmp;
+
+ for (i = 0; i < CRASH_NUM_SPUS; i++) {
+ if (!crash_spu_info[i].spu)
+ continue;
+
+ spu = crash_spu_info[i].spu;
+
+ crash_spu_info[i].saved_spu_runcntl_RW =
+ in_be32(&spu->problem->spu_runcntl_RW);
+ crash_spu_info[i].saved_spu_status_R =
+ in_be32(&spu->problem->spu_status_R);
+ crash_spu_info[i].saved_spu_npc_RW =
+ in_be32(&spu->problem->spu_npc_RW);
+
+ crash_spu_info[i].saved_mfc_dar = spu_mfc_dar_get(spu);
+ crash_spu_info[i].saved_mfc_dsisr = spu_mfc_dsisr_get(spu);
+ tmp = spu_mfc_sr1_get(spu);
+ crash_spu_info[i].saved_mfc_sr1_RW = tmp;
+
+ tmp &= ~MFC_STATE1_MASTER_RUN_CONTROL_MASK;
+ spu_mfc_sr1_set(spu, tmp);
+
+ __delay(200);
+ }
+}
+
+static void crash_register_spus(struct list_head *list)
+{
+ struct spu *spu;
+ int ret;
+
+ list_for_each_entry(spu, list, full_list) {
+ if (WARN_ON(spu->number >= CRASH_NUM_SPUS))
+ continue;
+
+ crash_spu_info[spu->number].spu = spu;
+ }
+
+ ret = crash_shutdown_register(&crash_kexec_stop_spus);
+ if (ret)
+ printk(KERN_ERR "Could not register SPU crash handler");
+}
+
static int __init init_spu_base(void)
{
int i, ret = 0;
^ permalink raw reply
* [PATCH 6/8] powerpc/kexec: Remove empty ppc_md.machine_kexec_prepare
From: Anton Blanchard @ 2011-01-07 3:58 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
We check for a valid handler before calling ppc_md.machine_kexec_prepare
so we can just remove these empty handlers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/platforms/embedded6xx/wii.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/embedded6xx/wii.c 2010-12-13 22:52:03.535243386 +1100
+++ powerpc.git/arch/powerpc/platforms/embedded6xx/wii.c 2011-01-07 12:51:59.422562597 +1100
@@ -18,7 +18,6 @@
#include <linux/init.h>
#include <linux/irq.h>
#include <linux/seq_file.h>
-#include <linux/kexec.h>
#include <linux/of_platform.h>
#include <linux/memblock.h>
#include <mm/mmu_decl.h>
@@ -226,13 +225,6 @@ static void wii_shutdown(void)
flipper_quiesce();
}
-#ifdef CONFIG_KEXEC
-static int wii_machine_kexec_prepare(struct kimage *image)
-{
- return 0;
-}
-#endif /* CONFIG_KEXEC */
-
define_machine(wii) {
.name = "wii",
.probe = wii_probe,
@@ -246,9 +238,6 @@ define_machine(wii) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
.machine_shutdown = wii_shutdown,
-#ifdef CONFIG_KEXEC
- .machine_kexec_prepare = wii_machine_kexec_prepare,
-#endif
};
static struct of_device_id wii_of_bus[] = {
Index: powerpc.git/arch/powerpc/platforms/embedded6xx/gamecube.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/embedded6xx/gamecube.c 2010-12-13 22:52:03.555243746 +1100
+++ powerpc.git/arch/powerpc/platforms/embedded6xx/gamecube.c 2011-01-07 12:51:59.422562597 +1100
@@ -75,14 +75,6 @@ static void gamecube_shutdown(void)
flipper_quiesce();
}
-#ifdef CONFIG_KEXEC
-static int gamecube_kexec_prepare(struct kimage *image)
-{
- return 0;
-}
-#endif /* CONFIG_KEXEC */
-
-
define_machine(gamecube) {
.name = "gamecube",
.probe = gamecube_probe,
@@ -95,9 +87,6 @@ define_machine(gamecube) {
.calibrate_decr = generic_calibrate_decr,
.progress = udbg_progress,
.machine_shutdown = gamecube_shutdown,
-#ifdef CONFIG_KEXEC
- .machine_kexec_prepare = gamecube_kexec_prepare,
-#endif
};
^ permalink raw reply
* [PATCH 5/8] powerpc/kexec: Don't initialise kexec hooks to default handlers
From: Anton Blanchard @ 2011-01-07 3:57 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
There's no need to initialise ppc_md.machine_kexec and
ppc_md.machine_kexec_prepare to the default handlers.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:58.112521318 +1100
@@ -145,8 +145,4 @@ define_machine(qpace) {
.calibrate_decr = generic_calibrate_decr,
.progress = qpace_progress,
.init_IRQ = iic_init_IRQ,
-#ifdef CONFIG_KEXEC
- .machine_kexec = default_machine_kexec,
- .machine_kexec_prepare = default_machine_kexec_prepare,
-#endif
};
Index: powerpc.git/arch/powerpc/platforms/pseries/kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:56.222461754 +1100
+++ powerpc.git/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:58.112521318 +1100
@@ -61,12 +61,3 @@ void __init setup_kexec_cpu_down_xics(vo
{
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
}
-
-static int __init pseries_kexec_setup(void)
-{
- ppc_md.machine_kexec = default_machine_kexec;
- ppc_md.machine_kexec_prepare = default_machine_kexec_prepare;
-
- return 0;
-}
-machine_device_initcall(pseries, pseries_kexec_setup);
^ permalink raw reply
* [PATCH 4/8] powerpc/kdump: Remove ppc_md.machine_crash_shutdown
From: Anton Blanchard @ 2011-01-07 3:56 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_crash_shutdown, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:54.082394288 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:56.222461754 +1100
@@ -236,12 +236,6 @@ struct machdep_calls {
#ifdef CONFIG_KEXEC
void (*kexec_cpu_down)(int crash_shutdown, int secondary);
- /* Called to do the minimal shutdown needed to run a kexec'd kernel
- * to run successfully.
- * XXX Should we move this one out of kexec scope?
- */
- void (*machine_crash_shutdown)(struct pt_regs *regs);
-
/* Called to do what every setup is needed on image and the
* reboot code buffer. Returns 0 on success.
* Provide your own (maybe dummy) implementation if your platform
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:54.082394288 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:56.222461754 +1100
@@ -44,10 +44,7 @@ void machine_kexec_mask_interrupts(void)
void machine_crash_shutdown(struct pt_regs *regs)
{
- if (ppc_md.machine_crash_shutdown)
- ppc_md.machine_crash_shutdown(regs);
- else
- default_machine_crash_shutdown(regs);
+ default_machine_crash_shutdown(regs);
}
/*
Index: powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/cell/qpace_setup.c 2010-12-13 22:52:03.765247709 +1100
+++ powerpc.git/arch/powerpc/platforms/cell/qpace_setup.c 2011-01-07 12:51:56.222461754 +1100
@@ -148,6 +148,5 @@ define_machine(qpace) {
#ifdef CONFIG_KEXEC
.machine_kexec = default_machine_kexec,
.machine_kexec_prepare = default_machine_kexec_prepare,
- .machine_crash_shutdown = default_machine_crash_shutdown,
#endif
};
Index: powerpc.git/arch/powerpc/platforms/pseries/kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/platforms/pseries/kexec.c 2010-12-13 22:52:03.745247341 +1100
+++ powerpc.git/arch/powerpc/platforms/pseries/kexec.c 2011-01-07 12:51:56.222461754 +1100
@@ -66,7 +66,6 @@ static int __init pseries_kexec_setup(vo
{
ppc_md.machine_kexec = default_machine_kexec;
ppc_md.machine_kexec_prepare = default_machine_kexec_prepare;
- ppc_md.machine_crash_shutdown = default_machine_crash_shutdown;
return 0;
}
^ permalink raw reply
* [PATCH 3/8] powerpc/kexec: Remove ppc_md.machine_kexec
From: Anton Blanchard @ 2011-01-07 3:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_kexec, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:51.352308248 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:54.082394288 +1100
@@ -248,12 +248,6 @@ struct machdep_calls {
* claims to support kexec.
*/
int (*machine_kexec_prepare)(struct kimage *image);
-
- /* Called to perform the _real_ kexec.
- * Do NOT allocate memory or fail here. We are past the point of
- * no return.
- */
- void (*machine_kexec)(struct kimage *image);
#endif /* CONFIG_KEXEC */
#ifdef CONFIG_SUSPEND
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:51.352308248 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:54.082394288 +1100
@@ -85,10 +85,7 @@ void arch_crash_save_vmcoreinfo(void)
*/
void machine_kexec(struct kimage *image)
{
- if (ppc_md.machine_kexec)
- ppc_md.machine_kexec(image);
- else
- default_machine_kexec(image);
+ default_machine_kexec(image);
/* Fall back to normal restart if we're still alive. */
machine_restart(NULL);
^ permalink raw reply
* [PATCH 2/8] powerpc/kexec: Remove ppc_md.machine_kexec_cleanup
From: Anton Blanchard @ 2011-01-07 3:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
No one uses ppc_md.machine_kexec_cleanup, so remove it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:46.682161055 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:51.352308248 +1100
@@ -249,9 +249,6 @@ struct machdep_calls {
*/
int (*machine_kexec_prepare)(struct kimage *image);
- /* Called to handle any machine specific cleanup on image */
- void (*machine_kexec_cleanup)(struct kimage *image);
-
/* Called to perform the _real_ kexec.
* Do NOT allocate memory or fail here. We are past the point of
* no return.
Index: powerpc.git/arch/powerpc/kernel/machine_kexec.c
===================================================================
--- powerpc.git.orig/arch/powerpc/kernel/machine_kexec.c 2010-12-13 22:52:03.975251680 +1100
+++ powerpc.git/arch/powerpc/kernel/machine_kexec.c 2011-01-07 12:51:51.352308248 +1100
@@ -65,8 +65,6 @@ int machine_kexec_prepare(struct kimage
void machine_kexec_cleanup(struct kimage *image)
{
- if (ppc_md.machine_kexec_cleanup)
- ppc_md.machine_kexec_cleanup(image);
}
void arch_crash_save_vmcoreinfo(void)
^ permalink raw reply
* [PATCH 1/8] powerpc: Move all ppc_md kexec function pointers together
From: Anton Blanchard @ 2011-01-07 3:54 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110107145255.72cf30ba@kryten>
Move all the kexec handlers together.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: powerpc.git/arch/powerpc/include/asm/machdep.h
===================================================================
--- powerpc.git.orig/arch/powerpc/include/asm/machdep.h 2011-01-07 12:50:52.020438276 +1100
+++ powerpc.git/arch/powerpc/include/asm/machdep.h 2011-01-07 12:51:46.682161055 +1100
@@ -118,9 +118,6 @@ struct machdep_calls {
* If for some reason there is no irq, but the interrupt
* shouldn't be counted as spurious, return NO_IRQ_IGNORE. */
unsigned int (*get_irq)(void);
-#ifdef CONFIG_KEXEC
- void (*kexec_cpu_down)(int crash_shutdown, int secondary);
-#endif
/* PCI stuff */
/* Called after scanning the bus, before allocating resources */
@@ -237,6 +234,8 @@ struct machdep_calls {
void (*machine_shutdown)(void);
#ifdef CONFIG_KEXEC
+ void (*kexec_cpu_down)(int crash_shutdown, int secondary);
+
/* Called to do the minimal shutdown needed to run a kexec'd kernel
* to run successfully.
* XXX Should we move this one out of kexec scope?
^ permalink raw reply
* [PATCH 0/8]: Some kexec/kdump cleanups
From: Anton Blanchard @ 2011-01-07 3:52 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
Hi,
These patches have been sitting around in my tree for a while. Back
when I was trying to understand the twisty maze of powerpc kexec/kdump
I did a number of cleanups. Here they are.
Anton
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Blanchard, Hollis @ 2011-01-06 21:52 UTC (permalink / raw)
To: Scott Wood; +Cc: Inge, Meador, devicetree-discuss, linuxppc-dev
In-Reply-To: <20110105170725.1a82c5a6@udp111988uds.am.freescale.net>
On 01/05/2011 03:07 PM, Scott Wood wrote:
> On Wed, 5 Jan 2011 14:49:40 -0800
> "Blanchard, Hollis"<Hollis_Blanchard@mentor.com> wrote:
>
>> On 01/05/2011 02:09 PM, Scott Wood wrote:
>>> On Wed, 5 Jan 2011 15:58:55 -0600
>>> Meador Inge<meador_inge@mentor.com> wrote:
>>>
>>>> We need some sort of mapping between a message register and a =
message
>>>> register number so that the message registers can be referenced =
through
>>>> some sort of API (e.g. 'mpic_msgr_read(0)'). One way to do that =
would
>>>> be by putting an order on the registers. Maybe there is a better =
way,
>>>> though ...
>>> A message register is uniquely identified by a reference to the =
device
>>> tree node, plus a 0-3 index into that node's message registers.
>> Really what we're talking about is software configuration, not =
hardware
>> description.
> Part of that software configuration involves identifying the hardware
> being referenced.
>
>> We've gone back and forth on representing this information
>> in the device tree, and most recently decided against it. Outside the
>> kernel, a device node reference isn't really practical.
> Global enumeration isn't much fun either. For something like this
> where it's very unlikely that additional MPIC message units will be
> added to the system dynamically, it's managable, but it's not a good
> habit to get into. Look at the pain that's been caused by such
> assumptions in the i2c subsystem, in kernel interrupt management, etc.
>
> A reference to a node is just a pointer to a software message driver
> object, which can be obtained from looking up an alias. It's a little
> less simple than just using a number, but it's not impractical. It =
also
> provides a natural place to put a layer of indirection in the code =
that
> isolates the upper-layer protocol from the details of what sort of
> message transport it is using.
>
> Now, if you don't care about this, and want to just use numbers in =
your
> application, go ahead. But I don't think that such an assumption
> should go into the device tree binding. Have the software number the
> message register banks in increasing physical address order, or based
> on numbered aliases similar to how U-Boot enumerates ethernet nodes, =
or
> something similar.
Using physical addresses doesn't solve the enumeration problem either,=20
but I think it's beside the point: userspace must refer to the device.=20
There is a rich history of userspace *not* walking /proc/device-tree in=20
order to refer to a physical device. Are you suggesting this case is=20
special?
Hollis Blanchard
Mentor Graphics, Embedded Systems Division
^ permalink raw reply
* Re: DMA implementation on MPC8572
From: Ira W. Snyder @ 2011-01-06 20:52 UTC (permalink / raw)
To: deebul nair; +Cc: linuxppc-dev
In-Reply-To: <AANLkTik1br89HU+sUOfHYB74uWqOBJSCNpbvf21xsh_r@mail.gmail.com>
On Thu, Jan 06, 2011 at 07:54:16PM +0530, deebul nair wrote:
> Hi all
>
> I am using the MPC8572 processor.
> I wanted to use the DMA functionality in the powerpc board for talking to a
> FPGA device connected on the loacl bus.
>
> I have compiled the fsldma.c code and inserted it.
> On insertion the driver probes all the dma channels
> Can anyone tell me how to test the driver and also how to use the driver?
>
For memcpy tests, the dmatest module provides a good example. See
drivers/dma/dmatest.c for the source.
For more advanced usage, search the archives for:
[PATCH RFCv3 0/2] CARMA Board Support
Those drivers use some of the advanced features of the DMAEngine API to
transfer data from an FPGA into RAM.
Ira
^ permalink raw reply
* Re: [RFC] MPIC Bindings and Bindings for AMP Systems
From: Scott Wood @ 2011-01-06 20:10 UTC (permalink / raw)
To: Meador Inge; +Cc: linuxppc-dev, devicetree-discuss, Blanchard, Hollis
In-Reply-To: <4D252FDC.4090404@mentor.com>
On Wed, 5 Jan 2011 20:58:36 -0600
Meador Inge <meador_inge@mentor.com> wrote:
> On 01/03/2011 02:22 PM, Scott Wood wrote:
> > On Wed, 22 Dec 2010 23:58:09 -0600
> > Perhaps a something like this, with "doorbell" being a new standard
> > hw-independent service with its own binding:
> >
> > msg1: mpic-msg@1400 {
> > compatible = "fsl,mpic-v3.0-msg";
> > reg =<0x1400 0x200>;
> > interrupts<176 2 178 2>;
> >
> > // We have message registers 0 and 2 for sending,
> > // and 1 and 3 for receiving.
> > // If absent, we own all message registers in this block.
> > fsl,mpic-msg-send-mask =<0x5>;
> > fsl,mpic-msg-receive-mask =<0xa>;
Alternatively, we could describe available ranges similarly to the
existing MSI binding.
> After thinking about it a little more, I like the idea of having a
> 'receive-mask' to further partition the message register blocks. This
> would also allow us to remove IRQs from the 'interrupts' property that
> are not being used on a given node. As for the 'send-mask', why would
> we want to block sending messages? It seems to me that it would be
> reasonable to allow a node to send a message to any other node.
The send-mask, like the receive-mask, is optional. If for your
application it makes sense to give all partitions send access to all
doorbells, then you can do that.
You might want to provide a send-mask if you are not specifying to the
partition how to use the message registers, just splitting them up for
their own internal use (especially if you have a larger multicore system
where each partition has multiple CPUs).
Or, you may want to add a layer of robustness against one partition
interfering with a message register that is only supposed to be used by
another partition, even if there are instructions elsewhere about which
message register to use for what purpose.
Plus, it provides symmetry between send and receive -- otherwise, you'd
have a numberspace that is limited to your own resources on receive,
but a global numberspace on send.
> As an example, consider a four core system. Then we might have
> something like (only relevant DTS bits shown):
>
> Core 0:
> mpic-msgr-block@1400 {
> // Receives messages on registers 1 and 3.
> interrupts = <0xb1 2 0xb3 2>;
> receive-mask = <0xa>;
> };
> Core 1:
> mpic-msgr-block@1400 {
> // Receives messages on register 2.
> interrupts = <0xb2 2>;
> receive-mask = <0x4>;
> };
> Core 2:
> mpic-msgr-block@1400 {
> // Receives messages on register 0.
> interrupts = <0xb0 2>;
> receive-mask = <0x1>;
> };
> Core 3:
> mpic-msgr-block@1400 {
> // Receives no messages.
> interrupts = <>;
> };
For core 3 I'd just leave out the node entirely. Note that the absence
of a receive-mask indicates that all the registers are available (i.e.
normal unpartitioned case), not none.
-Scott
^ permalink raw reply
* RE: RapidIO: question about rionet probe call
From: Bounine, Alexandre @ 2011-01-06 19:43 UTC (permalink / raw)
To: Thomas Taranowski, linuxppc-dev
In-Reply-To: <AANLkTi=ns4-bz1JBdzjX0tvqNuEDRiM6UpmzMu_Fr8cw@mail.gmail.com>
Did you change anything in RIO initialization sequence?
For multiple mport support I had to adjust rio_init_mports/rio_init
sequence.
Alex.
> -----Original Message-----
> From: =
linuxppc-dev-bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+alexandre.bounine=3Didt.com@lists.ozlabs.org] On Behalf Of
Thomas Taranowski
> Sent: Thursday, January 06, 2011 3:27 AM
> To: linuxppc-dev@lists.ozlabs.org
> Subject: RapidIO: question about rionet probe call
>=20
> I'm doing some work to support multiple mport architectures, and have
> run into an issue where the rionet_probe() function isn't being
> called, so my rionet net device never get's created. I've also
> verified that the rio_device_probe() isn't being called either.
>=20
> The low level rio bus driver initializes and probes correctly, and
> creates the required entries in sysfs. Then, later, I see the
> rionet_init get called and return success, indicating it registered
> with the rapidio bus correctly, so everything looks good.
>=20
>=20
> I see the following output (extra debug prints added) , indicating the
> rionet driver is being added, but it never gets probed afterward.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ~~~ rio_register_driver ~~~
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> bus: 'rapidio': add driver rionet
> initializing klist
> init and added kobj, err=3D0
> driver_create_file err=3D0
> driver added attrs, err=3D0
> returning 0
> RIO: rionet_init rio_register_driver: rc=3D0
>=20
>=20
> Any ideas on why rionet isn't being probed? Is rionet currently
working?
> I'm running a 2.6.36-rc8 baseline.
>=20
> Thanks,
> Thomas Taranowski
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Fix SPRG get/set for Book3S and BookE
From: Marcelo Tosatti @ 2011-01-06 16:39 UTC (permalink / raw)
To: Peter Tyser; +Cc: linuxppc-dev, kvm, kvm-ppc, agraf
In-Reply-To: <1293652285-13313-1-git-send-email-ptyser@xes-inc.com>
On Wed, Dec 29, 2010 at 01:51:25PM -0600, Peter Tyser wrote:
> Previously SPRGs 4-7 were improperly read and written in
> kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
>
> Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> ---
> I noticed this while grepping for somthing unrelated and assume its
> a typo. Feel free to add to the patch description; I don't use KVM
> so don't know what the high-level consequences of this change are.
>
> arch/powerpc/kvm/book3s.c | 14 ++++++++------
> arch/powerpc/kvm/booke.c | 14 ++++++++------
> 2 files changed, 16 insertions(+), 12 deletions(-)
Applied, thanks.
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: Joakim Tjernlund @ 2011-01-06 16:52 UTC (permalink / raw)
To: michael; +Cc: scottwood, linuxppc-dev, RFeany, rbeims
In-Reply-To: <4D25BB08.7000001@evidence.eu.com>
>>> + /* On 8xx, cache control instructions (particularly
>>> + * "dcbst" from flush=5Fdcache=5Ficache) fault as write
>>> + * operation if there is an unpopulated TLB entry
>>> + * for the address in question. To workaround that,
>>> + * we invalidate the TLB here, thus avoiding dcbst
>>> + * misbehaviour.
>>> + */
>>> + /* 8xx doesn't care about PID, size or ind args */
>>> + =5Ftlbil=5Fva(addr, 0, 0, 0);
>>> #endif /* CONFIG=5F8xx */
>>> +
>>> + if (!pg)
>>> + return pte;
>>> +
>>> + if (!PageReserved(pg)&& !test=5Fbit(PG=5Farch=5F1,&pg->flags)) {
>>> flush=5Fdcache=5Ficache=5Fpage(pg);
>>> set=5Fbit(PG=5Farch=5F1,&pg->flags);
>>> }
>> Rex, do you recall under what specific circumstances the =5Ftlbil=5Fva is
>> needed? Is it possible that it will be caused by a dcbst in other
>> contexts that are not dependent on the state of PG=5Farch=5F1?
The 8xx tlbil=5Fva should not be needed in recent 2.6 after I fixed the 8xx=
TLB code
to workaround the dcbst bug there instead. See=20
http://git.kernel.org/?p=3Dlinux/kernel/git/torvalds/linux-2.6.git;a=3Dcomm=
itdiff;h=3D0a2ab51ffb8dfdf51402dcfb446629648c96bc78;hp=3D60e071fee994ff98c3=
7d03a4a7c5a3f8b1e3b8e5
Not sure what release it went into though.
Jocke=
=
^ permalink raw reply
* DMA implementation on MPC8572
From: deebul nair @ 2011-01-06 14:24 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 365 bytes --]
Hi all
I am using the MPC8572 processor.
I wanted to use the DMA functionality in the powerpc board for talking to a
FPGA device connected on the loacl bus.
I have compiled the fsldma.c code and inserted it.
On insertion the driver probes all the dma channels
Can anyone tell me how to test the driver and also how to use the driver?
--
Cheeers
Deebul !!!!!!
[-- Attachment #2: Type: text/html, Size: 481 bytes --]
^ permalink raw reply
* Re: mpc880 linux-2.6.32 slow running processes
From: michael @ 2011-01-06 12:52 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Rafael Beims, Rex Feany
In-Reply-To: <20110105174256.29fd378a@udp111988uds.am.freescale.net>
Hi
On 01/06/2011 12:42 AM, Scott Wood wrote:
> On Wed, 5 Jan 2011 19:23:33 +0100
> michael<michael@evidence.eu.com> wrote:
>
>> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
>> index dd5ea95..cb67076 100644
>> --- a/arch/powerpc/include/asm/pte-8xx.h
>> +++ b/arch/powerpc/include/asm/pte-8xx.h
>> @@ -32,7 +32,7 @@
>> #define _PAGE_FILE 0x0002 /* when !present: nonlinear file mapping */
>> #define _PAGE_NO_CACHE 0x0002 /* I: cache inhibit */
>> #define _PAGE_SHARED 0x0004 /* No ASID (context) compare */
>> -#define _PAGE_SPECIAL 0x0008 /* SW entry, forced to 0 by the TLB miss */
>> +#define _PAGE_SPECIAL 0x0000 /* SW entry, forced to 0 by the TLB miss */
> What do you think is going wrong with the special bit on 8xx?
>
> Or might the change to set_pte_filter() alone be what fixed the problem?
>
Only the set_pte_filter doesn't fix the problem. The slow-down depends on
the __HAVE_ARCH_PTE_SPECIAL related code, but 2 months ago I didn't find the reason
and now I don't have the architecture. I will do some tests when I will came back in Italy.
>> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
>> index 5304093..1da03a8 100644
>> --- a/arch/powerpc/mm/pgtable.c
>> +++ b/arch/powerpc/mm/pgtable.c
>> @@ -173,21 +173,29 @@ static pte_t set_pte_filter(pte_t pte, unsigned long addr)
>> pte = __pte(pte_val(pte)& ~_PAGE_HPTEFLAGS);
>> if (pte_looks_normal(pte)&& !(cpu_has_feature(CPU_FTR_COHERENT_ICACHE) ||
>> cpu_has_feature(CPU_FTR_NOEXECUTE))) {
>> - struct page *pg = maybe_pte_to_page(pte);
>> - if (!pg)
>> + unsigned long pfn = pte_pfn(pte);
>> + struct page *pg;
>> +
>> + if (unlikely(!pfn_valid(pfn)))
>> return pte;
>> - if (!test_bit(PG_arch_1,&pg->flags)) {
>> +
>> + pg = pfn_to_page(pfn);
>> #ifdef CONFIG_8xx
>> - /* On 8xx, cache control instructions (particularly
>> - * "dcbst" from flush_dcache_icache) fault as write
>> - * operation if there is an unpopulated TLB entry
>> - * for the address in question. To workaround that,
>> - * we invalidate the TLB here, thus avoiding dcbst
>> - * misbehaviour.
>> - */
>> - /* 8xx doesn't care about PID, size or ind args */
>> - _tlbil_va(addr, 0, 0, 0);
>> + /* On 8xx, cache control instructions (particularly
>> + * "dcbst" from flush_dcache_icache) fault as write
>> + * operation if there is an unpopulated TLB entry
>> + * for the address in question. To workaround that,
>> + * we invalidate the TLB here, thus avoiding dcbst
>> + * misbehaviour.
>> + */
>> + /* 8xx doesn't care about PID, size or ind args */
>> + _tlbil_va(addr, 0, 0, 0);
>> #endif /* CONFIG_8xx */
>> +
>> + if (!pg)
>> + return pte;
>> +
>> + if (!PageReserved(pg)&& !test_bit(PG_arch_1,&pg->flags)) {
>> flush_dcache_icache_page(pg);
>> set_bit(PG_arch_1,&pg->flags);
>> }
> Rex, do you recall under what specific circumstances the _tlbil_va is
> needed? Is it possible that it will be caused by a dcbst in other
> contexts that are not dependent on the state of PG_arch_1?
>
> -Scott
>
Michael
^ permalink raw reply
* RapidIO: question about rionet probe call
From: Thomas Taranowski @ 2011-01-06 8:26 UTC (permalink / raw)
To: linuxppc-dev
I'm doing some work to support multiple mport architectures, and have
run into an issue where the rionet_probe() function isn't being
called, so my rionet net device never get's created. I've also
verified that the rio_device_probe() isn't being called either.
The low level rio bus driver initializes and probes correctly, and
creates the required entries in sysfs. Then, later, I see the
rionet_init get called and return success, indicating it registered
with the rapidio bus correctly, so everything looks good.
I see the following output (extra debug prints added) , indicating the
rionet driver is being added, but it never gets probed afterward.
~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~ rio_register_driver ~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~
bus: 'rapidio': add driver rionet
initializing klist
init and added kobj, err=0
driver_create_file err=0
driver added attrs, err=0
returning 0
RIO: rionet_init rio_register_driver: rc=0
Any ideas on why rionet isn't being probed? Is rionet currently working?
I'm running a 2.6.36-rc8 baseline.
Thanks,
Thomas Taranowski
^ permalink raw reply
* Re: [PATCH v2 1/2] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2011-01-06 4:47 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, linuxppc-dev
In-Reply-To: <1292049075-1809-1-git-send-email-hs@denx.de>
On Sat, Dec 11, 2010 at 07:31:15AM +0100, Heiko Schocher wrote:
> - add binding to OF, compatible name "smi,sm501"
>
> - add read/write functions for using this driver
> also on powerpc plattforms
>
> - add commandline options:
> sm501.fb_mode:
> Specify resolution as "<xres>x<yres>[-<bpp>][@<refresh>]"
> sm501.bpp:
> Specify bit-per-pixel if not specified mode
>
> - Add support for encoding display mode information
> in the device tree using verbatim EDID block.
>
> If the "edid" entry in the "smi,sm501" node is present,
> the driver will build mode database using EDID data
> and allow setting the display modes from this database.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> cc: linux-fbdev@vger.kernel.org
> cc: devicetree-discuss@ozlabs.org
> cc: Ben Dooks <ben@simtec.co.uk>
> cc: Vincent Sanders <vince@simtec.co.uk>
> cc: Samuel Ortiz <sameo@linux.intel.com>
> cc: linux-kernel@vger.kernel.org
>
> ---
> - changes since v1:
> add Ben Dooks, Vincent Sanders and Samuel Ortiz to cc, as suggested from
> Paul Mundt.
>
> Documentation/kernel-parameters.txt | 7 +
> Documentation/powerpc/dts-bindings/sm501.txt | 30 +++
> drivers/mfd/sm501.c | 141 ++++++++------
> drivers/video/sm501fb.c | 264 +++++++++++++++++---------
> include/linux/sm501.h | 8 +
> 5 files changed, 299 insertions(+), 151 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>
So has this stalled out? If Samuel wants to ack the MFD bits I don't mind
taking it through the fbdev tree. I can dust off an SM501 board to make
sure it still works for the non-OF case, although most of the changes
look fairly mechanical, so I don't forsee too much difficulty.
A few minor notes however. For starters, it would be nice to see this
patch split out a bit more logically. All of the items in your changelog
are more or less independent logical changes, and should really be
independent patches. As such, I'd like to see the EDID support as one
patch, the OF binding support layered on top of that, the documentation
split out as a trivial patch, and the I/O routine thing dealt with
separately. This should also make it easier for Samuel to simply ack the
OF bindings part that touch the MFD driver without having to be bothered
with any of the other stuff should regressions pop up at a later point in
time via a bisection.
As far as the DTS bindings documentation goes, I'm not sure what the best
way to split that out is. Perhaps simply lumping it in with the OF
bindings makes the most logical sense, and it's obviously a dependency
for the architecture-specific portion as well.
> @@ -1698,6 +1727,9 @@ static int sm501fb_init_fb(struct fb_info *fb,
> fb->fbops = &par->ops;
> fb->flags = FBINFO_FLAG_DEFAULT | FBINFO_READS_FAST |
> FBINFO_HWACCEL_COPYAREA | FBINFO_HWACCEL_FILLRECT |
> +#if defined(CONFIG_PPC_MPC52xx)
> + FBINFO_FOREIGN_ENDIAN |
> +#endif
> FBINFO_HWACCEL_XPAN | FBINFO_HWACCEL_YPAN;
>
> /* fixed data */
This is now getting in to deep hack territory. It's also not entirely
obvious how you expect things like the imageblit op to work given that
you're not selecting any of FB_{BIG,LITTLE,BOTH,FOREIGN}_ENDIAN, which
leads me to suspect you are manually doing this in your .config in a
relatively fragile way.
In the OF case I suppose you probably want something like:
#ifdef __BIG_ENDIAN
if (of_get_property(dp, "little-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#else
if (of_get_property(dp, "big-endian", NULL))
foreign_endian = FBINFO_FOREIGN_ENDIAN;
#endif
and then simply hide the details in the DTS file in order to get rid of
CPU-specific hacks.
> +#if defined(CONFIG_PPC_MPC52xx)
> +#define smc501_readl(addr) __do_readl_be((addr))
> +#define smc501_writel(val, addr) __do_writel_be((val), (addr))
> +#else
> +#define smc501_readl(addr) readl(addr)
> +#define smc501_writel(val, addr) writel(val, addr)
> +#endif
Based on the Kconfig option for endianness you could probably just wrap these
to ioread/write32{,be} and hide the semantics in your iomap implementation?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox