* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: K.Prasad @ 2009-12-14 18:03 UTC (permalink / raw)
To: Roland McGrath
Cc: Michael Neuling, Benjamin Herrenschmidt, Frederic Weisbecker,
David Gibson, linuxppc-dev, Alan Stern, paulus
In-Reply-To: <20091214005648.82BA31DE@magilla.sf.frob.com>
On Sun, Dec 13, 2009 at 04:56:48PM -0800, Roland McGrath wrote:
> I can't see anything you've done to keep this use of MSR_SE in the
> user-mode register state from interfering with user_enable_single_step().
> It looks to me like you'd swallow the normal step indications.
>
Yes, it does unset MSR_SE bit in single_step_dabr_instruction()
irrespective of whether it was previously enabled through
user_enable_single_step(). This could be mitigated with the use of a
separate flag which can be used to conditionally unset MSR_SE, however
given further concerns about pre-emption (as expressed by you below),
I'm afraid of substantial revamp of the user-space semantics.
> Likewise I'm not very clear on the interaction with kprobes, kgdb,
> or whatnot for kernel-mode cases. But I'll leave those concerns to
> others, since I know more about the user-mode situations.
>
Kprobes has been tested to work simultaneously with hw-breakpoints. KGDB
has not been ported yet to use the hw-breakpoint interfaces (KGDB had
issues in it, that prevented it from being tested during our
development...though its maintainer has begun showing interest
recently).
Xmon was (and I believe is still) in a state where data breakpoints did
not work. It needs to be ported too, to benefit from the hw-breakpoint
interfaces.
> Back to the user-mode case, is it really reasonable to disable
> preemption in hw_breakpoint_handler and leave it so across returning
> to user mode? (Is that even possible? I thought user mode was
> always preemptible.) That is done very casually with little comment
> in hw_breakpoint_handler and single_step_dabr_instruction, but it
> seems like an extremely deep and magical thing that merits more
> explanation. I guess the need for it has to do with the per_cpu
> variable you're using, but the whole situation is not very clear on
> first reading. Even for kernel mode, what does this mean when the
> stepped instruction does a page fault?
>
I must admit that the issue of pre-emption should have been given more
thought. Suppose there's a stream of user-space instructions "i1, i2, i3,
.....i<n>" and if 'i2' instruction can cause a hw-breakpoint exception,
then there exists a small window between i1 and i2 where pre-emption is
disabled (while a schedule operation could have taken place otherwise).
Disabling pre-emption is necessary to ensure that hw-breakpoints are
enabled immediately after the causative instruction has finished
execution (the control flow may go astray if pre-emption occurs between
i1 and i2). The root cause of this behaviour is a combination of
'trigger-before-execute' behaviour (for data-exceptions) and a desire
for 'continuous' exceptions (as opposed to one-shot behaviour seen in
ptrace). The per-cpu variable 'last_hit_bp' just helps identify a
single-step exception resulting from a hbp_handler vs other sources.
Resorting to one-shot behaviour (which is the easiest workaround
available) will break the desired uniformity in behaviour for
hw-breakpoint interfaces - say every register_user_<> interface must be
accompanied by a unregister_<> interface, etc. Post perf-events'
integration, ensuring a one-shot behaviour might also have its own
bunch of undesirable consequences (such as circular locks), that must be
overcome.
Unless I see a way to re-instate the breakpoints (surviving a
pre-emption), I will send out a new patch that resorts to a one-shot
behaviour for user-space (kernel-space is fine though).
Thank you for the insightful comments!
K.Prasad
^ permalink raw reply
* Re: spi_mpc8xxx.c: chip select polarity problem
From: Torsten Fleischer @ 2009-12-14 16:54 UTC (permalink / raw)
To: Grant Likely; +Cc: avorontsov, linuxppc-dev
In-Reply-To: <fa686aa40912090946m12fe293cg2efb043cb7a7f573@mail.gmail.com>
On Wed, Dec 9, 2009 at 18:46:51 Grant Likely wrote:
> <to-fleischer@t-online.de> wrote:
> [...]
> > The following patch adds a function to get the active state of the chip
> > select of a SPI device by looking for the 'spi-cs-high' property in the
> > associated device tree node.
> > This function is used by the spi_mpc8xxx driver to set a proper initial
> > value to the associated GPIOs.
> >
> >
> > Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
>
> I like this better. See comments below.
>
[...]
Hey Grant,
below there is a new version of the patch containing the modifications
according to your comments.
Thanks for the hints,
Torsten
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
---
diff -ruN linux-2.6.32_orig//drivers/of/of_spi.c linux-2.6.32/drivers/of/of_spi.c
--- linux-2.6.32_orig//drivers/of/of_spi.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/of/of_spi.c 2009-12-11 17:57:22.016787665 +0100
@@ -12,6 +12,43 @@
#include <linux/of_spi.h>
/**
+ * of_get_spi_cs_active_state - Gets the chip select's active state of a SPI
+ * child devices.
+ * @np: parent node of the SPI device nodes
+ * @index: index/address of the SPI device (refers to the 'reg' property)
+ *
+ * Returns 0 for 'active low' or if the child's node can't be found.
+ * Otherwise it returns 1 ('active high').
+ */
+bool of_get_spi_cs_active_state(struct device_node *np, int index)
+{
+ struct device_node *child;
+ const int *prop;
+ int len;
+ bool active = 0;
+
+ /* search for the matching SPI device */
+ for_each_child_of_node(np, child) {
+ prop = of_get_property(child, "reg", &len);
+ if (!prop || len < sizeof(*prop)) {
+ /* property 'reg' not available (not an error) */
+ continue;
+ }
+
+ if ( *prop == index ) {
+ /* matching device found */
+ if (of_find_property(child, "spi-cs-high", NULL))
+ active = 1;
+ break;
+ }
+ }
+
+ return active;
+}
+EXPORT_SYMBOL(of_get_spi_cs_active_state);
+
+
+/**
* of_register_spi_devices - Register child devices onto the SPI bus
* @master: Pointer to spi_master device
* @np: parent node of SPI device nodes
diff -ruN linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c linux-2.6.32/drivers/spi/spi_mpc8xxx.c
--- linux-2.6.32_orig//drivers/spi/spi_mpc8xxx.c 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/drivers/spi/spi_mpc8xxx.c 2009-12-11 17:15:47.957379333 +0100
@@ -705,6 +705,7 @@
for (; i < ngpios; i++) {
int gpio;
enum of_gpio_flags flags;
+ bool astate;
gpio = of_get_gpio_flags(np, i, &flags);
if (!gpio_is_valid(gpio)) {
@@ -721,8 +722,18 @@
pinfo->gpios[i] = gpio;
pinfo->alow_flags[i] = flags & OF_GPIO_ACTIVE_LOW;
+ /* get the active state of the SPI device */
+ astate = of_get_spi_cs_active_state(np, i);
+
+ /*
+ * alow_flags describe the wiring of the chip select
+ * (0 = non-inverted, 1 = inverted); this must be taken into
+ * account when setting the GPIO's initial value
+ * (see also mpc8xxx_spi_cs_control()); note that astate will
+ * be 0 for active low and 1 for active high respectively
+ */
ret = gpio_direction_output(pinfo->gpios[i],
- pinfo->alow_flags[i]);
+ pinfo->alow_flags[i] ^ !astate);
if (ret) {
dev_err(dev, "can't set output direction for gpio "
"#%d: %d\n", i, ret);
diff -ruN linux-2.6.32_orig//include/linux/of_spi.h linux-2.6.32/include/linux/of_spi.h
--- linux-2.6.32_orig//include/linux/of_spi.h 2009-12-03 04:51:21.000000000 +0100
+++ linux-2.6.32/include/linux/of_spi.h 2009-12-11 17:10:21.681380685 +0100
@@ -15,4 +15,7 @@
extern void of_register_spi_devices(struct spi_master *master,
struct device_node *np);
+extern bool of_get_spi_cs_active_state(struct device_node *np,
+ int index);
+
#endif /* __LINUX_OF_SPI */
^ permalink raw reply
* [PATCH 2/2] USB: ehci-fsl: Add power management support
From: Anton Vorontsov @ 2009-12-14 15:41 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Scott Wood, Jerry Huang, linux-usb, linuxppc-dev
In-Reply-To: <20091214154025.GA24035@oksana.dev.rtsoft.ru>
EHCI FSL controller preserve its state during sleep mode, so nothing
fancy needs to be done.
Though, during 'deep sleep' mode (as found in MPC831x CPUs) the
controller turns off and needs to be reinitialized upon resume.
This patch adds support for hibernation and resuming after deep sleep.
Based on Dave Liu and Jerry Huang's work[1].
[1] http://www.bitshrine.org/gpp/linux-fsl-2.6.24.3-MPC8315ERDB-usb-power-mangement.patch
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/ehci-fsl.c | 90 +++++++++++++++++++++++++++++++++++++++---
1 files changed, 83 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 593a7e7..0e26aa1 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -1,5 +1,6 @@
/*
- * Copyright (c) 2005 MontaVista Software
+ * Copyright 2005-2009 MontaVista Software, Inc.
+ * Copyright 2008 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
@@ -17,17 +18,20 @@
*
* Ported to 834x by Randy Vinson <rvinson@mvista.com> using code provided
* by Hunter Wu.
+ * Power Management support by Dave Liu <daveliu@freescale.com>,
+ * Jerry Huang <Chang-Ming.Huang@freescale.com> and
+ * Anton Vorontsov <avorontsov@ru.mvista.com>.
*/
+#include <linux/kernel.h>
+#include <linux/types.h>
+#include <linux/delay.h>
+#include <linux/pm.h>
#include <linux/platform_device.h>
#include <linux/fsl_devices.h>
#include "ehci-fsl.h"
-/* FIXME: Power Management is un-ported so temporarily disable it */
-#undef CONFIG_PM
-
-
/* configure so an HC device and id are always provided */
/* always called with process context; sleeping is OK */
@@ -285,10 +289,81 @@ static int ehci_fsl_setup(struct usb_hcd *hcd)
return retval;
}
+struct ehci_fsl {
+ struct ehci_hcd ehci;
+
+#ifdef CONFIG_PM
+ /* Saved USB PHY settings, need to restore after deep sleep. */
+ u32 usb_ctrl;
+#endif
+};
+
+#ifdef CONFIG_PM
+
+static struct ehci_fsl *hcd_to_ehci_fsl(struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+
+ return container_of(ehci, struct ehci_fsl, ehci);
+}
+
+static int ehci_fsl_drv_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+ void __iomem *non_ehci = hcd->regs;
+
+ if (!fsl_deep_sleep())
+ return 0;
+
+ ehci_fsl->usb_ctrl = in_be32(non_ehci + FSL_SOC_USB_CTRL);
+ return 0;
+}
+
+static int ehci_fsl_drv_resume(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+ struct ehci_fsl *ehci_fsl = hcd_to_ehci_fsl(hcd);
+ struct ehci_hcd *ehci = hcd_to_ehci(hcd);
+ void __iomem *non_ehci = hcd->regs;
+
+ if (!fsl_deep_sleep())
+ return 0;
+
+ usb_root_hub_lost_power(hcd->self.root_hub);
+
+ /* Restore USB PHY settings and enable the controller. */
+ out_be32(non_ehci + FSL_SOC_USB_CTRL, ehci_fsl->usb_ctrl);
+
+ ehci_reset(ehci);
+ ehci_fsl_reinit(ehci);
+
+ return 0;
+}
+
+static int ehci_fsl_drv_restore(struct device *dev)
+{
+ struct usb_hcd *hcd = dev_get_drvdata(dev);
+
+ usb_root_hub_lost_power(hcd->self.root_hub);
+ return 0;
+}
+
+static struct dev_pm_ops ehci_fsl_pm_ops = {
+ .suspend = ehci_fsl_drv_suspend,
+ .resume = ehci_fsl_drv_resume,
+ .restore = ehci_fsl_drv_restore,
+};
+
+#define EHCI_FSL_PM_OPS (&ehci_fsl_pm_ops)
+#else
+#define EHCI_FSL_PM_OPS NULL
+#endif /* CONFIG_PM */
+
static const struct hc_driver ehci_fsl_hc_driver = {
.description = hcd_name,
.product_desc = "Freescale On-Chip EHCI Host Controller",
- .hcd_priv_size = sizeof(struct ehci_hcd),
+ .hcd_priv_size = sizeof(struct ehci_fsl),
/*
* generic hardware linkage
@@ -355,6 +430,7 @@ static struct platform_driver ehci_fsl_driver = {
.remove = ehci_fsl_drv_remove,
.shutdown = usb_hcd_platform_shutdown,
.driver = {
- .name = "fsl-ehci",
+ .name = "fsl-ehci",
+ .pm = EHCI_FSL_PM_OPS,
},
};
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] USB: ehci-fsl: Fix sparse warnings
From: Anton Vorontsov @ 2009-12-14 15:41 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Scott Wood, Jerry Huang, linux-usb, linuxppc-dev
In-Reply-To: <20091214154025.GA24035@oksana.dev.rtsoft.ru>
This patch fixes following warnings:
ehci-fsl.c:43:5: warning: symbol 'usb_hcd_fsl_probe' was not declared. Should it be static?
ehci-fsl.c:150:6: warning: symbol 'usb_hcd_fsl_remove' was not declared. Should it be static?
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/usb/host/ehci-fsl.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 9911749..593a7e7 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -40,8 +40,8 @@
* Allocates basic resources for this USB host controller.
*
*/
-int usb_hcd_fsl_probe(const struct hc_driver *driver,
- struct platform_device *pdev)
+static int usb_hcd_fsl_probe(const struct hc_driver *driver,
+ struct platform_device *pdev)
{
struct fsl_usb2_platform_data *pdata;
struct usb_hcd *hcd;
@@ -147,7 +147,8 @@ int usb_hcd_fsl_probe(const struct hc_driver *driver,
* Reverses the effect of usb_hcd_fsl_probe().
*
*/
-void usb_hcd_fsl_remove(struct usb_hcd *hcd, struct platform_device *pdev)
+static void usb_hcd_fsl_remove(struct usb_hcd *hcd,
+ struct platform_device *pdev)
{
usb_remove_hcd(hcd);
iounmap(hcd->regs);
--
1.6.3.3
^ permalink raw reply related
* [PATCH v2 0/2] USB: ehci-fsl: Power management support
From: Anton Vorontsov @ 2009-12-14 15:40 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Scott Wood, Jerry Huang, linux-usb, linuxppc-dev
Hi all,
The patches were waiting for commit 2e9d546eda5888962a441da1e96bbf9
("powerpc/fsl: Make fsl_deep_sleep() usable w/ modules and non-83xx
builds") to hit Linus' tree.
Now that the commit is in, I'm resending the series with some
corrections as suggested[1] by Scott Wood.
It might be late for 2.6.33, but I believe that the patches are
actually quite safe.
Thanks!
[1] http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg37297.html
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH] powerpc: handle VSX alignment faults correctly in little-endian mode
From: Neil Campbell @ 2009-12-14 14:21 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <4B2646F9.4000203@linux.vnet.ibm.com>
Neil Campbell wrote:
> This patch fixes the handling of VSX alignment faults in little-endian
> mode (the current code assumes the processor is in big-endian mode).
>
> The patch also makes the handlers clear the top 8 bytes of the register
> when handling an 8 byte VSX load.
For the interested, here is a test case that demonstrates the problem.
It should compile with something like:
gcc -m64 -Wa,-mregnames -fno-strict-aliasing -mcpu=power7 -mvsx vsx_le.c -o vsx_le
On an unpatched kernel it reports 8 failures for me, the patch fixes all 8 of these.
---
#include <stdio.h>
#include <string.h>
int fails = 0;
#define LOAD_FUNC(name,inst) \
void test_load_##name(char* input, char* output, int le) \
{ \
int aligned = (0 == ((long)input & 15)); \
char* alignstr = aligned?"aligned: ":"unaligned: "; \
char* modestr = le?"(le)":"(be)"; \
int i; \
char dummydata[16] __attribute__((__aligned__(16))) = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; \
\
memset(output, 0, 16); \
\
asm ( \
"mr r15, %[address1]\n\t" \
"mr r16, %[address2]\n\t" \
"lvx v0, r0, %[address3]\n\t" /* set register to dummy values */ \
"cmpwi %[le],1 \n\t" \
"beq "#name"leversion \n\t" \
#name" vs32, r0, r15\n\t" \
"b " #name"store\n\t" \
#name"leversion: \n\t" \
"li r0, 171\n\t" \
"li r3, 20\n\t" \
"li r4, 1\n\t" \
"sc\n\t" \
".long " inst "\n\t" \
".long 0xab000038\n\t" /*"li 0, 171\n\t"*/ \
".long 0x14006038\n\t" /*"li 3, 20\n\t"*/ \
".long 0x00008038\n\t" /*"li 4, 0\n\t"*/ \
".long 0x02000044\n\t" /*"sc\n\t"*/ \
#name"store: \n\t" \
"stvx v0,r0,r16 \n\t" \
: \
: [address1] "b" (input), [address2] "b" (output), [address3] "b" (dummydata), [le] "b" (le) \
: "vs32", "r0", "r3", "r4", "r9", "r15", "r16", "cc", "memory"); \
\
fprintf(stderr, #name" %s after %s ", alignstr, modestr); \
for (i = 0; i < 16; ++i) \
{ \
fprintf(stderr, " %x ", output[i]); \
} \
fprintf(stderr, "\n"); \
} \
#define STORE_FUNC(name,inst) \
void test_store_##name(char* input, char* output, int le) \
{ \
int aligned = (0 == ((long)output & 15)); \
char* alignstr = aligned?"aligned: ":"unaligned: "; \
char* modestr = le?"(le)":"(be)"; \
int i; \
\
memset(output, 0, 16); \
\
asm ( \
"mr r15, %[address2]\n\t" \
"lvx v0, r0, %[address1]\n\t" \
"cmpwi %[le],1 \n\t" \
"beq "#name"leversion \n\t" \
#name" vs32, r0, r15\n\t" \
"b " #name"end\n\t" \
#name"leversion: \n\t" \
"li r0, 171\n\t" \
"li r3, 20\n\t" \
"li r4, 1\n\t" \
"sc\n\t" \
".long " inst "\n\t" \
".long 0xab000038\n\t" /*"li 0, 171\n\t"*/ \
".long 0x14006038\n\t" /*"li 3, 20\n\t"*/ \
".long 0x00008038\n\t" /*"li 4, 0\n\t"*/ \
".long 0x02000044\n\t" /*"sc\n\t"*/ \
#name"end: \n\t" \
: \
: [address1] "b" (input), [address2] "b" (output), [le] "b" (le) \
: "vs32", "r0", "r3", "r4", "r9", "r15", "cc", "memory"); \
\
fprintf(stderr, #name" %s after %s ", alignstr, modestr); \
for (i = 0; i < 16; ++i) \
{ \
fprintf(stderr, " %x ", output[i]); \
} \
fprintf(stderr, "\n"); \
} \
void do_compare(char* buf1, char* buf2)
{
if(0 == memcmp(buf1,buf2,16))
{
fprintf(stderr, "PASS\n");
}
else
{
fprintf(stderr, "FAIL\n");
fails++;
}
}
STORE_FUNC(stxvw4x, "0x197f007c")
STORE_FUNC(stxvd2x, "0x997f007c")
STORE_FUNC(stxsdx, "0x997d007c")
LOAD_FUNC(lxvw4x, "0x197e007c")
LOAD_FUNC(lxvd2x, "0x997e007c")
LOAD_FUNC(lxsdx, "0x997c007c")
LOAD_FUNC(lxvdsx, "0x997a007c")
int main(int argc, char* argv[])
{
char inbuf[17] __attribute__((__aligned__(16))) = { -1, 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf };
char alignedinbuf[16] __attribute__((__aligned__(16))) = { 0x0, 0x1, 0x2, 0x3, 0x4, 0x5, 0x6, 0x7, 0x8, 0x9, 0xa, 0xb, 0xc, 0xd, 0xe, 0xf };
char outbuf[17] __attribute__((__aligned__(16))) = { -1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
char alignedoutbuf[16] __attribute__((__aligned__(16))) = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
char alignedoutbuf2[16] __attribute__((__aligned__(16))) = { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 };
test_store_stxvw4x(alignedinbuf, alignedoutbuf, 0);
test_store_stxvw4x(alignedinbuf, &outbuf[1], 0);
do_compare(alignedoutbuf, &outbuf[1]);
test_store_stxvw4x(alignedinbuf, alignedoutbuf, 1);
test_store_stxvw4x(alignedinbuf, &outbuf[1], 1);
do_compare(alignedoutbuf, &outbuf[1]);
fprintf(stderr, "\n");
test_store_stxvd2x(alignedinbuf, alignedoutbuf, 0);
test_store_stxvd2x(alignedinbuf, &outbuf[1], 0);
do_compare(alignedoutbuf, &outbuf[1]);
test_store_stxvd2x(alignedinbuf, alignedoutbuf, 1);
test_store_stxvd2x(alignedinbuf, &outbuf[1], 1);
do_compare(alignedoutbuf, &outbuf[1]);
fprintf(stderr, "\n");
test_store_stxsdx(alignedinbuf, alignedoutbuf, 0);
test_store_stxsdx(alignedinbuf, &outbuf[1], 0);
do_compare(alignedoutbuf, &outbuf[1]);
test_store_stxsdx(alignedinbuf, alignedoutbuf, 1);
test_store_stxsdx(alignedinbuf, &outbuf[1], 1);
do_compare(alignedoutbuf, &outbuf[1]);
fprintf(stderr, "\n");
test_load_lxvw4x(alignedinbuf, alignedoutbuf, 0);
test_load_lxvw4x(&inbuf[1], alignedoutbuf2, 0);
do_compare(alignedoutbuf, alignedoutbuf2);
test_load_lxvw4x(alignedinbuf, alignedoutbuf, 1);
test_load_lxvw4x(&inbuf[1], alignedoutbuf2, 1);
do_compare(alignedoutbuf, alignedoutbuf2);
fprintf(stderr, "\n");
test_load_lxvd2x(alignedinbuf, alignedoutbuf, 0);
test_load_lxvd2x(&inbuf[1], alignedoutbuf2, 0);
do_compare(alignedoutbuf, alignedoutbuf2);
test_load_lxvd2x(alignedinbuf, alignedoutbuf, 1);
test_load_lxvd2x(&inbuf[1], alignedoutbuf2, 1);
do_compare(alignedoutbuf, alignedoutbuf2);
fprintf(stderr, "\n");
test_load_lxsdx(alignedinbuf, alignedoutbuf, 0);
test_load_lxsdx(&inbuf[1], alignedoutbuf2, 0);
do_compare(alignedoutbuf, alignedoutbuf2);
test_load_lxsdx(alignedinbuf, alignedoutbuf, 1);
test_load_lxsdx(&inbuf[1], alignedoutbuf2, 1);
do_compare(alignedoutbuf, alignedoutbuf2);
fprintf(stderr, "\n");
test_load_lxvdsx(alignedinbuf, alignedoutbuf, 0);
test_load_lxvdsx(&inbuf[1], alignedoutbuf2, 0);
do_compare(alignedoutbuf, alignedoutbuf2);
test_load_lxvdsx(alignedinbuf, alignedoutbuf, 1);
test_load_lxvdsx(&inbuf[1], alignedoutbuf2, 1);
do_compare(alignedoutbuf, alignedoutbuf2);
fprintf(stderr, "\n");
fprintf(stderr, "%d tests failed\n", fails);
return fails;
}
^ permalink raw reply
* [PATCH] powerpc: handle VSX alignment faults correctly in little-endian mode
From: Neil Campbell @ 2009-12-14 14:08 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Michael Neuling
This patch fixes the handling of VSX alignment faults in little-endian
mode (the current code assumes the processor is in big-endian mode).
The patch also makes the handlers clear the top 8 bytes of the register
when handling an 8 byte VSX load.
This is based on 2.6.32.
Signed-off-by: Neil Campbell <neilc@linux.vnet.ibm.com>
Cc: <stable@kernel.org>
---
diff --git a/arch/powerpc/kernel/align.c b/arch/powerpc/kernel/align.c
index a5b632e..f0c624f 100644
--- a/arch/powerpc/kernel/align.c
+++ b/arch/powerpc/kernel/align.c
@@ -642,10 +642,14 @@ static int emulate_spe(struct pt_regs *regs, unsigned int reg,
*/
static int emulate_vsx(unsigned char __user *addr, unsigned int reg,
unsigned int areg, struct pt_regs *regs,
- unsigned int flags, unsigned int length)
+ unsigned int flags, unsigned int length,
+ unsigned int elsize)
{
char *ptr;
+ unsigned long *lptr;
int ret = 0;
+ int sw = 0;
+ int i, j;
flush_vsx_to_thread(current);
@@ -654,19 +658,35 @@ static int emulate_vsx(unsigned char __user *addr, unsigned int reg,
else
ptr = (char *) ¤t->thread.vr[reg - 32];
- if (flags & ST)
- ret = __copy_to_user(addr, ptr, length);
- else {
- if (flags & SPLT){
- ret = __copy_from_user(ptr, addr, length);
- ptr += length;
+ lptr = (unsigned long *) ptr;
+
+ if (flags & SW)
+ sw = elsize-1;
+
+ for (j = 0; j < length; j += elsize) {
+ for (i = 0; i < elsize; ++i) {
+ if (flags & ST)
+ ret |= __put_user(ptr[i^sw], addr + i);
+ else
+ ret |= __get_user(ptr[i^sw], addr + i);
}
- ret |= __copy_from_user(ptr, addr, length);
+ ptr += elsize;
+ addr += elsize;
}
- if (flags & U)
- regs->gpr[areg] = regs->dar;
- if (ret)
+
+ if (!ret) {
+ if (flags & U)
+ regs->gpr[areg] = regs->dar;
+
+ /* Splat load copies the same data to top and bottom 8 bytes */
+ if (flags & SPLT)
+ lptr[1] = lptr[0];
+ /* For 8 byte loads, zero the top 8 bytes */
+ else if (!(flags & ST) && (8 == length))
+ lptr[1] = 0;
+ } else
return -EFAULT;
+
return 1;
}
#endif
@@ -767,16 +787,25 @@ int fix_alignment(struct pt_regs *regs)
#ifdef CONFIG_VSX
if ((instruction & 0xfc00003e) == 0x7c000018) {
- /* Additional register addressing bit (64 VSX vs 32 FPR/GPR */
+ unsigned int elsize;
+
+ /* Additional register addressing bit (64 VSX vs 32 FPR/GPR) */
reg |= (instruction & 0x1) << 5;
/* Simple inline decoder instead of a table */
+ /* VSX has only 8 and 16 byte memory accesses */
+ nb = 8;
if (instruction & 0x200)
nb = 16;
- else if (instruction & 0x080)
- nb = 8;
- else
- nb = 4;
+
+ /* Vector stores in little-endian mode swap individual
+ elements, so process them separately */
+ elsize = 4;
+ if (instruction & 0x80)
+ elsize = 8;
+
flags = 0;
+ if (regs->msr & MSR_LE)
+ flags |= SW;
if (instruction & 0x100)
flags |= ST;
if (instruction & 0x040)
@@ -787,7 +816,7 @@ int fix_alignment(struct pt_regs *regs)
nb = 8;
}
PPC_WARN_EMULATED(vsx);
- return emulate_vsx(addr, reg, areg, regs, flags, nb);
+ return emulate_vsx(addr, reg, areg, regs, flags, nb, elsize);
}
#endif
/* A size of 0 indicates an instruction we don't support, with
^ permalink raw reply related
* [PATCH v0] Crypto: Talitos: re-initialize async_tx descriptors
From: Vishnu Suresh @ 2009-12-14 13:33 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams,
linux-crypto, herbert
Cc: Vishnu Suresh, B04825, R58472
The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
o. Rebased to linux-next as of 20091214
drivers/crypto/talitos.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 87f06be..9e261c6 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -952,6 +952,9 @@ static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
return NULL;
}
dma_async_tx_descriptor_init(&new->async_tx, &xor_chan->common);
+ new->async_tx.parent = NULL;
+ new->async_tx.next = NULL;
+
desc = &new->hwdesc;
/* Set destination: Last pointer pair */
--
1.6.4.2
^ permalink raw reply related
* [PATCH v1] Crypto: Talitos: Support for Async_tx XOR offload
From: Vishnu Suresh @ 2009-12-14 13:32 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams,
linux-crypto, herbert
Cc: R58472, B04825, Vishnu Suresh, Dipen Dudhat, Maneesh Gupta
Expose Talitos's XOR functionality to be used for
RAID Parity calculation via the Async_tx layer.
Thanks to Surender Kumar and Lee Nipper for their help in
realising this driver
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
Signed-off-by: Dipen Dudhat <Dipen.Dudhat@freescale.com>
Signed-off-by: Maneesh Gupta <Maneesh.Gupta@freescale.com>
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v0 as per comments received
o. Removed ASYNC_XOR selection from Kconfig
o. Use dma_run_dependencies API instead of scheduling directly
from release path
o. Change spinlock_irqsave to spin_lock_bh
o. Removed setting async_tx_ack
o. Removed unnecessary initialization.
o. Rebased to linux-next as of 20091214
drivers/crypto/Kconfig | 1 +
drivers/crypto/talitos.c | 397 +++++++++++++++++++++++++++++++++++++++++++++-
drivers/crypto/talitos.h | 2 +
3 files changed, 399 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..fe406b2 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -192,6 +192,7 @@ config CRYPTO_DEV_TALITOS
select CRYPTO_ALGAPI
select CRYPTO_AUTHENC
select HW_RANDOM
+ select DMA_ENGINE
depends on FSL_SOC
help
Say 'Y' here to use the Freescale Security Engine (SEC)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c47ffe8..87f06be 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1,7 +1,7 @@
/*
* talitos - Freescale Integrated Security Engine (SEC) device driver
*
- * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008-2009 Freescale Semiconductor, Inc.
*
* Scatterlist Crypto API glue code copied from files with the following:
* Copyright (c) 2006-2007 Herbert Xu <herbert@gondor.apana.org.au>
@@ -37,6 +37,8 @@
#include <linux/io.h>
#include <linux/spinlock.h>
#include <linux/rtnetlink.h>
+#include <linux/dmaengine.h>
+#include <linux/raid/xor.h>
#include <crypto/algapi.h>
#include <crypto/aes.h>
@@ -140,6 +142,9 @@ struct talitos_private {
/* hwrng device */
struct hwrng rng;
+
+ /* XOR Device */
+ struct dma_device dma_dev_common;
};
/* .features flag */
@@ -685,6 +690,375 @@ static void talitos_unregister_rng(struct device *dev)
}
/*
+ * async_tx interface for XOR-capable SECs
+ *
+ * Dipen Dudhat <Dipen.Dudhat@freescale.com>
+ * Maneesh Gupta <Maneesh.Gupta@freescale.com>
+ * Vishnu Suresh <Vishnu@freescale.com>
+ */
+
+/**
+ * talitos_xor_chan - context management for the async_tx channel
+ * @completed_cookie: the last completed cookie
+ * @desc_lock: lock for tx queue
+ * @total_desc: number of descriptors allocated
+ * @submit_q: queue of submitted descriptors
+ * @pending_q: queue of pending descriptors
+ * @in_progress_q: queue of descriptors in progress
+ * @free_desc: queue of unused descriptors
+ * @dev: talitos device implementing this channel
+ * @common: the corresponding xor channel in async_tx
+ */
+struct talitos_xor_chan {
+ dma_cookie_t completed_cookie;
+ spinlock_t desc_lock;
+ unsigned int total_desc;
+ struct list_head submit_q;
+ struct list_head pending_q;
+ struct list_head in_progress_q;
+ struct list_head free_desc;
+ struct device *dev;
+ struct dma_chan common;
+};
+
+/**
+ * talitos_xor_desc - software xor descriptor
+ * @async_tx: the referring async_tx descriptor
+ * @node:
+ * @hwdesc: h/w descriptor
+ */
+struct talitos_xor_desc {
+ struct dma_async_tx_descriptor async_tx;
+ struct list_head tx_list;
+ struct list_head node;
+ struct talitos_desc hwdesc;
+};
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error);
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ dma_cookie_t *done,
+ dma_cookie_t *used)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan->cookie;
+ last_complete = xor_chan->completed_cookie;
+
+ if (done)
+ *done = last_complete;
+
+ if (used)
+ *used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static void talitos_process_pending(struct talitos_xor_chan *xor_chan)
+{
+ struct talitos_xor_desc *desc, *_desc;
+
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ if (talitos_submit(xor_chan->dev, &desc->hwdesc,
+ talitos_release_xor, desc) != -EINPROGRESS)
+ break;
+
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->in_progress_q);
+ }
+ spin_unlock_bh(&xor_chan->desc_lock);
+}
+
+static void talitos_release_xor(struct device *dev, struct talitos_desc *hwdesc,
+ void *context, int error)
+{
+ struct talitos_xor_desc *desc = context;
+ struct talitos_xor_chan *xor_chan;
+ dma_async_tx_callback callback;
+ void *callback_param;
+
+ if (unlikely(error)) {
+ dev_err(dev, "xor operation: talitos error %d\n", error);
+ BUG();
+ }
+
+ xor_chan = container_of(desc->async_tx.chan, struct talitos_xor_chan,
+ common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ if (xor_chan->completed_cookie < desc->async_tx.cookie)
+ xor_chan->completed_cookie = desc->async_tx.cookie;
+
+ callback = desc->async_tx.callback;
+ callback_param = desc->async_tx.callback_param;
+ list_del(&desc->node);
+ list_add_tail(&desc->node, &xor_chan->free_desc);
+ spin_unlock_bh(&xor_chan->desc_lock);
+
+ if (callback)
+ callback(callback_param);
+
+ /* run dependent operations */
+ dma_run_dependencies(&desc->async_tx);
+}
+
+/**
+ * talitos_issue_pending - move the descriptors in submit
+ * queue to pending queue and submit them for processing
+ * @chan: DMA channel
+ */
+static void talitos_issue_pending(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ spin_lock_bh(&xor_chan->desc_lock);
+ list_splice_tail_init(&xor_chan->submit_q,
+ &xor_chan->pending_q);
+ spin_unlock_bh(&xor_chan->desc_lock);
+ talitos_process_pending(xor_chan);
+}
+
+static dma_cookie_t talitos_async_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct talitos_xor_desc *desc;
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t cookie;
+
+ desc = container_of(tx, struct talitos_xor_desc, async_tx);
+ xor_chan = container_of(tx->chan, struct talitos_xor_chan, common);
+
+ cookie = xor_chan->common.cookie + 1;
+ if (cookie < 0)
+ cookie = 1;
+
+ desc->async_tx.cookie = cookie;
+ xor_chan->common.cookie = desc->async_tx.cookie;
+
+ list_splice_tail_init(&desc->tx_list,
+ &xor_chan->submit_q);
+
+ return cookie;
+}
+
+static struct talitos_xor_desc *talitos_xor_alloc_descriptor(
+ struct talitos_xor_chan *xor_chan, gfp_t flags)
+{
+ struct talitos_xor_desc *desc;
+
+ desc = kmalloc(sizeof(*desc), flags);
+ if (desc) {
+ xor_chan->total_desc++;
+ desc->async_tx.tx_submit = talitos_async_tx_submit;
+ INIT_LIST_HEAD(&desc->node);
+ INIT_LIST_HEAD(&desc->tx_list);
+ }
+
+ return desc;
+}
+
+static void talitos_free_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc, *_desc;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ list_for_each_entry_safe(desc, _desc, &xor_chan->submit_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->pending_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->in_progress_q, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ list_for_each_entry_safe(desc, _desc, &xor_chan->free_desc, node) {
+ list_del(&desc->node);
+ xor_chan->total_desc--;
+ kfree(desc);
+ }
+ BUG_ON(unlikely(xor_chan->total_desc)); /* Some descriptor not freed? */
+}
+
+static int talitos_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *desc;
+ LIST_HEAD(tmp_list);
+ int i;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc))
+ return xor_chan->total_desc;
+
+ /* 256 initial descriptors */
+ for (i = 0; i < 256; i++) {
+ desc = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ if (!desc) {
+ dev_err(xor_chan->common.device->dev,
+ "Only %d initial descriptors\n", i);
+ break;
+ }
+ list_add_tail(&desc->node, &tmp_list);
+ }
+
+ if (!i)
+ return -ENOMEM;
+
+ /* At least one desc is allocated */
+ list_splice_init(&tmp_list, &xor_chan->free_desc);
+
+ return xor_chan->total_desc;
+}
+
+static struct dma_async_tx_descriptor * talitos_prep_dma_xor(
+ struct dma_chan *chan, dma_addr_t dest, dma_addr_t *src,
+ unsigned int src_cnt, size_t len, unsigned long flags)
+{
+ struct talitos_xor_chan *xor_chan;
+ struct talitos_xor_desc *new;
+ struct talitos_desc *desc;
+ int i, j;
+
+ BUG_ON(unlikely(len > TALITOS_MAX_DATA_LEN));
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ if (!list_empty(&xor_chan->free_desc)) {
+ new = container_of(xor_chan->free_desc.next,
+ struct talitos_xor_desc, node);
+ list_del(&new->node);
+ } else {
+ new = talitos_xor_alloc_descriptor(xor_chan, GFP_KERNEL);
+ }
+
+ if (!new) {
+ dev_err(xor_chan->common.device->dev,
+ "No free memory for XOR DMA descriptor\n");
+ return NULL;
+ }
+ dma_async_tx_descriptor_init(&new->async_tx, &xor_chan->common);
+
+ desc = &new->hwdesc;
+ /* Set destination: Last pointer pair */
+ to_talitos_ptr(&desc->ptr[6], dest);
+ desc->ptr[6].len = cpu_to_be16(len);
+ desc->ptr[6].j_extent = 0;
+
+ /* Set Sources: End loading from second-last pointer pair */
+ for (i = 5, j = 0; (j < src_cnt) && (i > 0); i--, j++) {
+ to_talitos_ptr(&desc->ptr[i], src[j]);
+ desc->ptr[i].len = cpu_to_be16(len);
+ desc->ptr[i].j_extent = 0;
+ }
+
+ /*
+ * documentation states first 0 ptr/len combo marks end of sources
+ * yet device produces scatter boundary error unless all subsequent
+ * sources are zeroed out
+ */
+ for (; i >= 0; i--) {
+ to_talitos_ptr(&desc->ptr[i], 0);
+ desc->ptr[i].len = 0;
+ desc->ptr[i].j_extent = 0;
+ }
+
+ desc->hdr = DESC_HDR_SEL0_AESU | DESC_HDR_MODE0_AESU_XOR
+ | DESC_HDR_TYPE_RAID_XOR;
+
+ list_add_tail(&new->node, &new->tx_list);
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ return &new->async_tx;
+}
+
+static void talitos_unregister_async_xor(struct device *dev)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct talitos_xor_chan *xor_chan;
+ struct dma_chan *chan;
+
+ if (priv->dma_dev_common.chancnt)
+ dma_async_device_unregister(&priv->dma_dev_common);
+
+ list_for_each_entry(chan, &priv->dma_dev_common.channels, device_node) {
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+ list_del(&chan->device_node);
+ priv->dma_dev_common.chancnt--;
+ kfree(xor_chan);
+ }
+}
+
+/**
+ * talitos_register_dma_async - Initialize the Freescale XOR ADMA device
+ * It is registered as a DMA device with the capability to perform
+ * XOR operation with the Async_tx layer.
+ * The various queues and channel resources are also allocated.
+ */
+static int talitos_register_async_tx(struct device *dev, int max_xor_srcs)
+{
+ struct talitos_private *priv = dev_get_drvdata(dev);
+ struct dma_device *dma_dev = &priv->dma_dev_common;
+ struct talitos_xor_chan *xor_chan;
+ int err;
+
+ xor_chan = kzalloc(sizeof(struct talitos_xor_chan), GFP_KERNEL);
+ if (!xor_chan) {
+ dev_err(dev, "unable to allocate xor channel\n");
+ return -ENOMEM;
+ }
+
+ dma_dev->dev = dev;
+ dma_dev->device_alloc_chan_resources = talitos_alloc_chan_resources;
+ dma_dev->device_free_chan_resources = talitos_free_chan_resources;
+ dma_dev->device_prep_dma_xor = talitos_prep_dma_xor;
+ dma_dev->max_xor = max_xor_srcs;
+ dma_dev->device_is_tx_complete = talitos_is_tx_complete;
+ dma_dev->device_issue_pending = talitos_issue_pending;
+ INIT_LIST_HEAD(&dma_dev->channels);
+ dma_cap_set(DMA_XOR, dma_dev->cap_mask);
+
+ xor_chan->dev = dev;
+ xor_chan->common.device = dma_dev;
+ xor_chan->total_desc = 0;
+ INIT_LIST_HEAD(&xor_chan->submit_q);
+ INIT_LIST_HEAD(&xor_chan->pending_q);
+ INIT_LIST_HEAD(&xor_chan->in_progress_q);
+ INIT_LIST_HEAD(&xor_chan->free_desc);
+ spin_lock_init(&xor_chan->desc_lock);
+
+ list_add_tail(&xor_chan->common.device_node, &dma_dev->channels);
+ dma_dev->chancnt++;
+
+ err = dma_async_device_register(dma_dev);
+ if (err) {
+ dev_err(dev, "Unable to register XOR with Async_tx\n");
+ goto err_out;
+ }
+
+ return err;
+
+err_out:
+ talitos_unregister_async_xor(dev);
+ return err;
+}
+/*
* crypto alg
*/
#define TALITOS_CRA_PRIORITY 3000
@@ -1768,6 +2142,8 @@ static int talitos_remove(struct of_device *ofdev)
tasklet_kill(&priv->done_task);
iounmap(priv->reg);
+ if (priv->dma_dev_common.chancnt)
+ talitos_unregister_async_xor(dev);
dev_set_drvdata(dev, NULL);
@@ -1926,6 +2302,25 @@ static int talitos_probe(struct of_device *ofdev,
dev_info(dev, "hwrng\n");
}
+ /*
+ * register with async_tx xor, if capable
+ * SEC 2.x support up to 3 RAID sources,
+ * SEC 3.x support up to 6
+ */
+ if (hw_supports(dev, DESC_HDR_SEL0_AESU | DESC_HDR_TYPE_RAID_XOR)) {
+ int max_xor_srcs = 3;
+ if (of_device_is_compatible(np, "fsl,sec3.0"))
+ max_xor_srcs = 6;
+
+ err = talitos_register_async_tx(dev, max_xor_srcs);
+ if (err) {
+ dev_err(dev, "failed to register async_tx xor: %d\n",
+ err);
+ goto err_out;
+ }
+ dev_info(dev, "max_xor_srcs %d\n", max_xor_srcs);
+ }
+
/* register crypto algorithms the device supports */
for (i = 0; i < ARRAY_SIZE(driver_algs); i++) {
if (hw_supports(dev, driver_algs[i].desc_hdr_template)) {
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index ff5a145..b6197bc 100644
--- a/drivers/crypto/talitos.h
+++ b/drivers/crypto/talitos.h
@@ -155,6 +155,7 @@
/* primary execution unit mode (MODE0) and derivatives */
#define DESC_HDR_MODE0_ENCRYPT cpu_to_be32(0x00100000)
#define DESC_HDR_MODE0_AESU_CBC cpu_to_be32(0x00200000)
+#define DESC_HDR_MODE0_AESU_XOR cpu_to_be32(0x0c600000)
#define DESC_HDR_MODE0_DEU_CBC cpu_to_be32(0x00400000)
#define DESC_HDR_MODE0_DEU_3DES cpu_to_be32(0x00200000)
#define DESC_HDR_MODE0_MDEU_INIT cpu_to_be32(0x01000000)
@@ -202,6 +203,7 @@
#define DESC_HDR_TYPE_IPSEC_ESP cpu_to_be32(1 << 3)
#define DESC_HDR_TYPE_COMMON_NONSNOOP_NO_AFEU cpu_to_be32(2 << 3)
#define DESC_HDR_TYPE_HMAC_SNOOP_NO_AFEU cpu_to_be32(4 << 3)
+#define DESC_HDR_TYPE_RAID_XOR cpu_to_be32(21 << 3)
/* link table extent field bits */
#define DESC_PTR_LNKTBL_JUMP 0x80
--
1.6.4.2
^ permalink raw reply related
* [PATCH v0] fsldma: re-initialize async_tx descriptors
From: Vishnu Suresh @ 2009-12-14 13:30 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams
Cc: Vishnu Suresh, B04825, R58472
The async_tx descriptors contains dangling pointers.
Hence, re-initialize them to NULL before use.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
o. Rebased to linux-next as of 20091214
drivers/dma/fsldma.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 272097a..779c2b6 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -384,6 +384,8 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(
dma_async_tx_descriptor_init(&desc_sw->async_tx,
&fsl_chan->common);
desc_sw->async_tx.tx_submit = fsl_dma_tx_submit;
+ desc_sw->async_tx.parent = NULL;
+ desc_sw->async_tx.next = NULL;
desc_sw->async_tx.phys = pdesc;
}
--
1.6.4.2
^ permalink raw reply related
* [PATCH v1] fsldma: Delete DMA_INTERRUPT capability
From: Vishnu Suresh @ 2009-12-14 13:30 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, linux-raid, dan.j.williams
Cc: Vishnu Suresh, B04825, R58472
The DMA_INTERRUPT is a NULL transfer, triggering a
Programming Error. Though this Error is handled in
the driver with the fix given in "fsldma: Fix the DMA
halt when using DMA_INTERRUPT async_tx transfer."
<f79abb627f033c85a6088231f20c85bc4a9bd757>,
the RAID5 operation, which initiated the transaction
via Async_tx, hangs.
Hence, this patch removes the DMA_INTERRUPT capability
and the associated code from the driver.
Signed-off-by: Vishnu Suresh <Vishnu@freescale.com>
---
Changes with respect to v0
o. The functionality is removed instead of disabling as
per comments
o. Rebased to linux-next as of 20091214
drivers/dma/fsldma.c | 31 -------------------------------
1 files changed, 0 insertions(+), 31 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 296f9e7..272097a 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -449,35 +449,6 @@ static void fsl_dma_free_chan_resources(struct dma_chan *chan)
fsl_chan->desc_pool = NULL;
}
-static struct dma_async_tx_descriptor *
-fsl_dma_prep_interrupt(struct dma_chan *chan, unsigned long flags)
-{
- struct fsl_dma_chan *fsl_chan;
- struct fsl_desc_sw *new;
-
- if (!chan)
- return NULL;
-
- fsl_chan = to_fsl_chan(chan);
-
- new = fsl_dma_alloc_descriptor(fsl_chan);
- if (!new) {
- dev_err(fsl_chan->dev, "No free memory for link descriptor\n");
- return NULL;
- }
-
- new->async_tx.cookie = -EBUSY;
- new->async_tx.flags = flags;
-
- /* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->tx_list);
-
- /* Set End-of-link to the last link descriptor of new list*/
- set_ld_eol(fsl_chan, new);
-
- return &new->async_tx;
-}
-
static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
struct dma_chan *chan, dma_addr_t dma_dest, dma_addr_t dma_src,
size_t len, unsigned long flags)
@@ -1200,11 +1171,9 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
- fdev->reg.start + 1);
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
- dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
- fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
--
1.6.4.2
^ permalink raw reply related
* [PATCH] powerpc/mm: fix typo of cpumask_clear_cpu()
From: Li Yang @ 2009-12-14 13:01 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
The function name of cpumask_clear_cpu was not correct.
Reported-by: Jin Qing <b24347@freescale.com>
Signed-off-by: Li Yang <leoli@freescale.com>
---
This also implies that the CONFIG_HOTPLUG_CPU was never tested.
We are trying to add cpu hotplug for SMP suspend, but seeing the
following error(on 2.6.31 with context patches applied).
Any idea or suggestion?
------------[ cut here ]------------
Badness at c00161b0 [verbose debug info unavailable]
NIP: c00161b0 LR: c0016190 CTR: c0038f7c
REGS: eec61e10 TRAP: 0700 Not tainted (2.6.31-00040-g7c92556-dirty)
MSR: 00021000 <ME,CE> CR: 22280028 XER: 00000000
TASK = eec54980[0] 'swapper' THREAD: eec60000 CPU: 1
GPR00: 00000001 eec61ec0 eec54980 c0562ea0 eecad500 00000000 00000000 00000001
GPR08: 00eed000 00000000 00000001 eecad67c 00001ca8 00000000 00021000 eec60040
GPR16: eec54b0c c05208a0 c055fbe8 00000001 ffffffff c0560000 c0562ea0 00000004
GPR24: eec60000 00000001 00000000 c0562e80 eec60000 c05291f8 eecad500 c05291f8
NIP [c00161b0] switch_mmu_context+0x54/0x520
LR [c0016190] switch_mmu_context+0x34/0x520
Call Trace:
[eec61ec0] [c00709c8] tick_program_event+0x50/0x60 (unreliable)
[eec61f20] [c03beb54] schedule+0x2bc/0x7bc
[eec61fa0] [c0008a8c] cpu_idle+0x160/0x170
[eec61fc0] [c03c4be0] start_secondary+0x2d0/0x2e8
[eec61ff0] [c0001c9c] __secondary_start+0x30/0x84
Instruction dump:
543c0024 7ec3b378 833c0008 483ab1bd 813e0184 2f9d0000 39290001 913e0184
419e001c 813d0184 7d200034 5400d97e <0f000000> 3929ffff 913d0184 3d20c055
MMU: More active contexts than CPUs ! (3 vs 2)
MMU: More active contexts than CPUs ! (3 vs 2)
arch/powerpc/mm/mmu_context_nohash.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_nohash.c b/arch/powerpc/mm/mmu_context_nohash.c
index be4f34c..1044a63 100644
--- a/arch/powerpc/mm/mmu_context_nohash.c
+++ b/arch/powerpc/mm/mmu_context_nohash.c
@@ -353,7 +353,7 @@ static int __cpuinit mmu_context_cpu_notify(struct notifier_block *self,
read_lock(&tasklist_lock);
for_each_process(p) {
if (p->mm)
- cpu_mask_clear_cpu(cpu, mm_cpumask(p->mm));
+ cpumask_clear_cpu(cpu, mm_cpumask(p->mm));
}
read_unlock(&tasklist_lock);
break;
--
1.6.6-rc1.GIT
^ permalink raw reply related
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-14 12:19 UTC (permalink / raw)
To: Sachin Sant; +Cc: Linux/PPC Development, Ingo Molnar, linux-next, linux-kernel
In-Reply-To: <4B261D7A.9040802@in.ibm.com>
On Mon, 2009-12-14 at 16:41 +0530, Sachin Sant wrote:
> Peter Zijlstra wrote:
> > On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
> > =20
> >> While executing cpu_hotplug(from autotest) tests against latest
> >> next on a power6 box, the machine locks up. A soft reset shows
> >> the following trace
> >>
> >> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> >> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> >> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> >> sp: c00000000c933650
> >> msr: 8000000000089032
> >> current =3D 0xc00000000c173840
> >> paca =3D 0xc000000000bc2600
> >> pid =3D 2602, comm =3D hotplug06.top.s
> >> enter ? for help
> >> [link register ] c000000000342f10 .cpumask_next_and+0x4c/0x94
> >> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0=
x74 (unreliable)
> >> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
> >> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
> >> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
> >> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
> >> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
> >> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
> >> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
> >> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
> >> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
> >> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
> >> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
> >> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
> >> SP (fffe7aef200) is in userspace
> >> 0:mon> e
> >> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> >> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> >> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> >> sp: c00000000c933650
> >> msr: 8000000000089032
> >> current =3D 0xc00000000c173840
> >> paca =3D 0xc000000000bc2600
> >> pid =3D 2602, comm =3D hotplug06.top.s
> >>
OK so how do I read that above thing? What's a System Reset? Is that
like the x86 triple fault thing?
>From what I can make of it, its in move_task_off_dead_cpu(), right after
having called cpuset_cpus_allowed_locked(), doing that cpumask_any_and()
call.
static void move_task_off_dead_cpu(int dead_cpu, struct task_struct *p)
{
int dest_cpu;
const struct cpumask *nodemask =3D cpumask_of_node(cpu_to_node(dead=
_cpu));
again:
/* Look for allowed, online CPU in same node. */
for_each_cpu_and(dest_cpu, nodemask, cpu_active_mask)
if (cpumask_test_cpu(dest_cpu, &p->cpus_allowed))
goto move;
/* Any allowed, online CPU? */
dest_cpu =3D cpumask_any_and(&p->cpus_allowed, cpu_active_mask);
if (dest_cpu < nr_cpu_ids)
goto move;
/* No more Mr. Nice Guy. */
if (dest_cpu >=3D nr_cpu_ids) {
cpuset_cpus_allowed_locked(p, &p->cpus_allowed);
=3D=3D=3D=3D> dest_cpu =3D cpumask_any_and(cpu_active_mask, &p->c=
pus_allowed);
/*
* Don't tell them about moving exiting tasks or
* kernel threads (both mm NULL), since they never
* leave kernel.
*/
if (p->mm && printk_ratelimit()) {
pr_info("process %d (%s) no longer affine to cpu%d\=
n",
task_pid_nr(p), p->comm, dead_cpu);
}
}
move:
/* It can have affinity changed while we were choosing. */
if (unlikely(!__migrate_task_irq(p, dead_cpu, dest_cpu)))
goto again;
}
Both masks, p->cpus_allowed and cpu_active_mask are stable in that p
won't go away since we hold the tasklist_lock (in migrate_list_tasks),
and cpu_active_mask is static storage, so WTH is it going funny on?
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-14 11:11 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Linux/PPC Development, Ingo Molnar, linux-next, linux-kernel
In-Reply-To: <1260786122.4165.142.camel@twins>
[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]
Peter Zijlstra wrote:
> On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
>
>> While executing cpu_hotplug(from autotest) tests against latest
>> next on a power6 box, the machine locks up. A soft reset shows
>> the following trace
>>
>> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
>> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
>> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
>> sp: c00000000c933650
>> msr: 8000000000089032
>> current = 0xc00000000c173840
>> paca = 0xc000000000bc2600
>> pid = 2602, comm = hotplug06.top.s
>> enter ? for help
>> [link register ] c000000000342f10 .cpumask_next_and+0x4c/0x94
>> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0x74 (unreliable)
>> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
>> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
>> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
>> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
>> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
>> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
>> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
>> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
>> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
>> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
>> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
>> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
>> SP (fffe7aef200) is in userspace
>> 0:mon> e
>> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
>> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
>> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
>> sp: c00000000c933650
>> msr: 8000000000089032
>> current = 0xc00000000c173840
>> paca = 0xc000000000bc2600
>> pid = 2602, comm = hotplug06.top.s
>>
>> Last few messages from the dmesg log shows
>>
>
>
>
>> After some debugging a possible suspect seems to be commit
>> 6ad4c18.. : sched: Fix balance vs hotplug race
>>
>
>
> Oh, wonderful :-/
>
> So what is that thing whining about? Not being able to read a cpumask or
> something?
>
> Does your .config have cpusets enabled (there's a different
> cpuset_cpus_allowed_locked implementation depending on that)?
>
Yes CPUSETS config is enabled. I have attached the config.
Thanks
-Sachin
> I know of at least one remaining race and am working on closing that,
> but I'm not sure I can explain this crash with that.
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: config_cpu_hotplug.gz --]
[-- Type: application/x-gzip, Size: 19832 bytes --]
^ permalink raw reply
* Re: [Next] CPU Hotplug test failures on powerpc
From: Peter Zijlstra @ 2009-12-14 10:22 UTC (permalink / raw)
To: Sachin Sant; +Cc: Linux/PPC Development, Ingo Molnar, linux-next, linux-kernel
In-Reply-To: <4B2224C7.1020908@in.ibm.com>
On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
> While executing cpu_hotplug(from autotest) tests against latest
> next on a power6 box, the machine locks up. A soft reset shows
> the following trace
>=20
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> sp: c00000000c933650
> msr: 8000000000089032
> current =3D 0xc00000000c173840
> paca =3D 0xc000000000bc2600
> pid =3D 2602, comm =3D hotplug06.top.s
> enter ? for help
> [link register ] c000000000342f10 .cpumask_next_and+0x4c/0x94
> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0x74=
(unreliable)
> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
> SP (fffe7aef200) is in userspace
> 0:mon> e
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> sp: c00000000c933650
> msr: 8000000000089032
> current =3D 0xc00000000c173840
> paca =3D 0xc000000000bc2600
> pid =3D 2602, comm =3D hotplug06.top.s
>=20
> Last few messages from the dmesg log shows
> After some debugging a possible suspect seems to be commit
> 6ad4c18.. : sched: Fix balance vs hotplug race
Oh, wonderful :-/
So what is that thing whining about? Not being able to read a cpumask or
something?
Does your .config have cpusets enabled (there's a different
cpuset_cpus_allowed_locked implementation depending on that)?
I know of at least one remaining race and am working on closing that,
but I'm not sure I can explain this crash with that.
^ permalink raw reply
* Re: powerpc/kvm tree build failure
From: Alexander Graf @ 2009-12-14 10:03 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul Mackerras, linuxppc-dev, Hollis Blanchard, linuxppc-dev
In-Reply-To: <20091214173512.91e4e39a.sfr@canb.auug.org.au>
On 14.12.2009, at 07:35, Stephen Rothwell wrote:
> Hi all,
>=20
> A powerpc allmodconfig fails like this:
>=20
> arch/powerpc/kvm/built-in.o:(.toc1+0x18): undefined reference to =
`kvm_debugfs_dir'
>=20
> This is because CONFIG_KVM_EXIT_TIMING is a bool while
> CONFIG_KVM_BOOK3S_64 is tristate. This causes =
arch/powerpc/kvm/timing.o
> (which references kvm_debugfs_dir) to be built in, but
> virt/kvm/kvm_main.o (which defines it) to be modular.
Ouch.
EXIT_TIMING could be used by BookE and Book3S KVM support. BookE can't =
be built as a module, while Book3S can.
So what's the usual / best way to fix this? Make EXIT_TIMING a tristate =
too, but only on Book3S? Maybe by defining it as dependent on Book3S or =
BookE KVM support?
The easiest thing for now would probably be to just make it depend on =
BookE support, since we don't have support for exit timing in Book3S =
yet. But I'm not sure which approach is the best to take :-).
Alex=
^ permalink raw reply
* Re: linux-next: 52xx-and-virtex tree build failure
From: Benjamin Herrenschmidt @ 2009-12-14 9:08 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Albert Herranz, linux-kernel, linuxppc-dev, linux-next,
Paul Mackerras
In-Reply-To: <20091214163456.e2e948cc.sfr@canb.auug.org.au>
On Mon, 2009-12-14 at 16:34 +1100, Stephen Rothwell wrote:
> Hi Grant,
>
> Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
>
> arch/powerpc/mm/pgtable_32.c: In function 'mapin_ram':
> arch/powerpc/mm/pgtable_32.c:318: error: too many arguments to function 'mmu_mapin_ram'
>
> Casued by commit de32400dd26e743c5d500aa42d8d6818b79edb73 ("wii: use both
> mem1 and mem2 as ram").
>
> I applied the following patch for today, but this may be too much or
> there may be a better solution.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 14 Dec 2009 16:04:15 +1100
> Subject: [PATCH] powerpc: fix up for mmu_mapin_ram api change
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Grant, please add to your tree along with the Nintendo stuff.
Cheers,
Ben.
> ---
> arch/powerpc/mm/40x_mmu.c | 2 +-
> arch/powerpc/mm/44x_mmu.c | 2 +-
> arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
> arch/powerpc/mm/mmu_decl.h | 6 +++---
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
> index f5e7b9c..08dfa8e 100644
> --- a/arch/powerpc/mm/40x_mmu.c
> +++ b/arch/powerpc/mm/40x_mmu.c
> @@ -91,7 +91,7 @@ void __init MMU_init_hw(void)
> #define LARGE_PAGE_SIZE_16M (1<<24)
> #define LARGE_PAGE_SIZE_4M (1<<22)
>
> -unsigned long __init mmu_mapin_ram(void)
> +unsigned long __init mmu_mapin_ram(unsigned long top)
> {
> unsigned long v, s, mapped;
> phys_addr_t p;
> diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
> index 98052ac..3986264 100644
> --- a/arch/powerpc/mm/44x_mmu.c
> +++ b/arch/powerpc/mm/44x_mmu.c
> @@ -88,7 +88,7 @@ void __init MMU_init_hw(void)
> flush_instruction_cache();
> }
>
> -unsigned long __init mmu_mapin_ram(void)
> +unsigned long __init mmu_mapin_ram(unsigned long top)
> {
> unsigned long addr;
>
> diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
> index fcfcb6e..c539472 100644
> --- a/arch/powerpc/mm/fsl_booke_mmu.c
> +++ b/arch/powerpc/mm/fsl_booke_mmu.c
> @@ -207,7 +207,7 @@ unsigned long map_mem_in_cams(unsigned long ram, int max_cam_idx)
> return amount_mapped;
> }
>
> -unsigned long __init mmu_mapin_ram(void)
> +unsigned long __init mmu_mapin_ram(unsigned long top)
> {
> return tlbcam_addrs[tlbcam_index - 1].limit - PAGE_OFFSET + 1;
> }
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index eef7aaf..d49a775 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -139,15 +139,15 @@ extern void wii_memory_fixups(void);
> */
> #if defined(CONFIG_8xx)
> #define MMU_init_hw() do { } while(0)
> -#define mmu_mapin_ram() (0UL)
> +#define mmu_mapin_ram(top) (0UL)
>
> #elif defined(CONFIG_4xx)
> extern void MMU_init_hw(void);
> -extern unsigned long mmu_mapin_ram(void);
> +extern unsigned long mmu_mapin_ram(unsigned long top);
>
> #elif defined(CONFIG_FSL_BOOKE)
> extern void MMU_init_hw(void);
> -extern unsigned long mmu_mapin_ram(void);
> +extern unsigned long mmu_mapin_ram(unsigned long top);
> extern void adjust_total_lowmem(void);
>
> #elif defined(CONFIG_PPC32)
> --
> 1.6.5.4
>
^ permalink raw reply
* [RESEND]Fix hash_utils_64.c compile errors with DEBUG enabled.
From: Sachin Sant @ 2009-12-14 7:15 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
This time without the funny characters.
Fix following build errors generated with DEBUG=1
cc1: warnings being treated as errors
arch/powerpc/mm/hash_utils_64.c: In function 'htab_dt_scan_page_sizes':
arch/powerpc/mm/hash_utils_64.c:343: error: format '%04x' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
arch/powerpc/mm/hash_utils_64.c:343: error: format '%08x' expects type 'unsigned int', but argument 5 has type 'long unsigned int'
arch/powerpc/mm/hash_utils_64.c: In function 'htab_initialize':
arch/powerpc/mm/hash_utils_64.c:666: error: format '%x' expects type 'unsigned int', but argument 4 has type 'long unsigned int'
... SNIP ...
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
--- a/arch/powerpc/mm/hash_utils_64.c 2009-12-14 11:14:01.000000000 +0530
+++ b/arch/powerpc/mm/hash_utils_64.c 2009-12-14 11:16:37.000000000 +0530
@@ -340,7 +340,7 @@ static int __init htab_dt_scan_page_size
else
def->tlbiel = 0;
- DBG(" %d: shift=%02x, sllp=%04x, avpnm=%08x, "
+ DBG(" %d: shift=%02x, sllp=%04lx, avpnm=%08lx, "
"tlbiel=%d, penc=%d\n",
idx, shift, def->sllp, def->avpnm, def->tlbiel,
def->penc);
@@ -663,7 +663,7 @@ static void __init htab_initialize(void)
base = (unsigned long)__va(lmb.memory.region[i].base);
size = lmb.memory.region[i].size;
- DBG("creating mapping for region: %lx..%lx (prot: %x)\n",
+ DBG("creating mapping for region: %lx..%lx (prot: %lx)\n",
base, size, prot);
#ifdef CONFIG_U3_DART
@@ -1115,7 +1115,7 @@ void flush_hash_page(unsigned long va, r
{
unsigned long hash, index, shift, hidx, slot;
- DBG_LOW("flush_hash_page(va=%016x)\n", va);
+ DBG_LOW("flush_hash_page(va=%016lx)\n", va);
pte_iterate_hashed_subpages(pte, psize, va, index, shift) {
hash = hpt_hash(va, shift, ssize);
hidx = __rpte_to_hidx(pte, index);
@@ -1123,7 +1123,7 @@ void flush_hash_page(unsigned long va, r
hash = ~hash;
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot += hidx & _PTEIDX_GROUP_IX;
- DBG_LOW(" sub %d: hash=%x, hidx=%x\n", index, slot, hidx);
+ DBG_LOW(" sub %ld: hash=%lx, hidx=%lx\n", index, slot, hidx);
ppc_md.hpte_invalidate(slot, va, psize, ssize, local);
} pte_iterate_hashed_end();
}
^ permalink raw reply
* Fix hash_utils_64.c compile errors with DEBUG enabled.
From: Sachin Sant @ 2009-12-14 7:00 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]
Fix following build errors generated with DEBUG=1
cc1: warnings being treated as errors
arch/powerpc/mm/hash_utils_64.c: In function ‘htab_dt_scan_page_sizes’:
arch/powerpc/mm/hash_utils_64.c:345: error: format ‘%04x’ expects type ‘unsigned int’, but argument 4 has type ‘long unsigned int’
arch/powerpc/mm/hash_utils_64.c:345: error: format ‘%08x’ expects type ‘unsigned int’, but argument 5 has type ‘long unsigned int’
arch/powerpc/mm/hash_utils_64.c: In function ‘htab_initialize’:
... SNIP ...
Signed-off-by: Sachin Sant <sachinp@in.ibm.com>
---
diff -Naurp a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
--- a/arch/powerpc/mm/hash_utils_64.c 2009-12-14 11:14:01.000000000 +0530
+++ b/arch/powerpc/mm/hash_utils_64.c 2009-12-14 11:16:37.000000000 +0530
@@ -340,7 +340,7 @@ static int __init htab_dt_scan_page_size
else
def->tlbiel = 0;
- DBG(" %d: shift=%02x, sllp=%04x, avpnm=%08x, "
+ DBG(" %d: shift=%02x, sllp=%04lx, avpnm=%08lx, "
"tlbiel=%d, penc=%d\n",
idx, shift, def->sllp, def->avpnm, def->tlbiel,
def->penc);
@@ -663,7 +663,7 @@ static void __init htab_initialize(void)
base = (unsigned long)__va(lmb.memory.region[i].base);
size = lmb.memory.region[i].size;
- DBG("creating mapping for region: %lx..%lx (prot: %x)\n",
+ DBG("creating mapping for region: %lx..%lx (prot: %lx)\n",
base, size, prot);
#ifdef CONFIG_U3_DART
@@ -1115,7 +1115,7 @@ void flush_hash_page(unsigned long va, r
{
unsigned long hash, index, shift, hidx, slot;
- DBG_LOW("flush_hash_page(va=%016x)\n", va);
+ DBG_LOW("flush_hash_page(va=%016lx)\n", va);
pte_iterate_hashed_subpages(pte, psize, va, index, shift) {
hash = hpt_hash(va, shift, ssize);
hidx = __rpte_to_hidx(pte, index);
@@ -1123,7 +1123,7 @@ void flush_hash_page(unsigned long va, r
hash = ~hash;
slot = (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot += hidx & _PTEIDX_GROUP_IX;
- DBG_LOW(" sub %d: hash=%x, hidx=%x\n", index, slot, hidx);
+ DBG_LOW(" sub %ld: hash=%lx, hidx=%lx\n", index, slot, hidx);
ppc_md.hpte_invalidate(slot, va, psize, ssize, local);
} pte_iterate_hashed_end();
}
^ permalink raw reply
* powerpc/kvm tree build failure
From: Stephen Rothwell @ 2009-12-14 6:35 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: linuxppc-dev, Alexander Graf, Hollis Blanchard
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
Hi all,
A powerpc allmodconfig fails like this:
arch/powerpc/kvm/built-in.o:(.toc1+0x18): undefined reference to `kvm_debugfs_dir'
This is because CONFIG_KVM_EXIT_TIMING is a bool while
CONFIG_KVM_BOOK3S_64 is tristate. This causes arch/powerpc/kvm/timing.o
(which references kvm_debugfs_dir) to be built in, but
virt/kvm/kvm_main.o (which defines it) to be modular.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: devicetree tree build failure
From: Stephen Rothwell @ 2009-12-14 5:38 UTC (permalink / raw)
To: Grant Likely; +Cc: linux-kernel, linuxppc-dev, linux-next, Paul Mackerras
[-- Attachment #1: Type: text/plain, Size: 711 bytes --]
Hi Grant,
Today's linux-next build (powerpc allyesconfig) failed like this:
drivers/of/fdt.c: In function 'early_init_devtree':
drivers/of/fdt.c:530: error: 'early_init_dt_scan_phyp_dump' undeclared (first use in this function)
Caused by commit 825b073d40b34e331d49e727b9e208744ad26259 ("of/flattree:
merge early_init_devtree() and early_init_move_devtree()").
I have reverted that commit (and all later commits) from the devicetree
tree for today.
Grant, are these commits really intended for v2.6.33? If not, please just
remove them from your tree until after v2.6.33-rc1, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* linux-next: 52xx-and-virtex tree build failure
From: Stephen Rothwell @ 2009-12-14 5:34 UTC (permalink / raw)
To: Grant Likely
Cc: Albert Herranz, linux-kernel, linuxppc-dev, linux-next,
Paul Mackerras
Hi Grant,
Today's linux-next build (powerpc ppc44x_defconfig) failed like this:
arch/powerpc/mm/pgtable_32.c: In function 'mapin_ram':
arch/powerpc/mm/pgtable_32.c:318: error: too many arguments to function 'mmu_mapin_ram'
Casued by commit de32400dd26e743c5d500aa42d8d6818b79edb73 ("wii: use both
mem1 and mem2 as ram").
I applied the following patch for today, but this may be too much or
there may be a better solution.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 14 Dec 2009 16:04:15 +1100
Subject: [PATCH] powerpc: fix up for mmu_mapin_ram api change
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/mm/40x_mmu.c | 2 +-
arch/powerpc/mm/44x_mmu.c | 2 +-
arch/powerpc/mm/fsl_booke_mmu.c | 2 +-
arch/powerpc/mm/mmu_decl.h | 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index f5e7b9c..08dfa8e 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -91,7 +91,7 @@ void __init MMU_init_hw(void)
#define LARGE_PAGE_SIZE_16M (1<<24)
#define LARGE_PAGE_SIZE_4M (1<<22)
-unsigned long __init mmu_mapin_ram(void)
+unsigned long __init mmu_mapin_ram(unsigned long top)
{
unsigned long v, s, mapped;
phys_addr_t p;
diff --git a/arch/powerpc/mm/44x_mmu.c b/arch/powerpc/mm/44x_mmu.c
index 98052ac..3986264 100644
--- a/arch/powerpc/mm/44x_mmu.c
+++ b/arch/powerpc/mm/44x_mmu.c
@@ -88,7 +88,7 @@ void __init MMU_init_hw(void)
flush_instruction_cache();
}
-unsigned long __init mmu_mapin_ram(void)
+unsigned long __init mmu_mapin_ram(unsigned long top)
{
unsigned long addr;
diff --git a/arch/powerpc/mm/fsl_booke_mmu.c b/arch/powerpc/mm/fsl_booke_mmu.c
index fcfcb6e..c539472 100644
--- a/arch/powerpc/mm/fsl_booke_mmu.c
+++ b/arch/powerpc/mm/fsl_booke_mmu.c
@@ -207,7 +207,7 @@ unsigned long map_mem_in_cams(unsigned long ram, int max_cam_idx)
return amount_mapped;
}
-unsigned long __init mmu_mapin_ram(void)
+unsigned long __init mmu_mapin_ram(unsigned long top)
{
return tlbcam_addrs[tlbcam_index - 1].limit - PAGE_OFFSET + 1;
}
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index eef7aaf..d49a775 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -139,15 +139,15 @@ extern void wii_memory_fixups(void);
*/
#if defined(CONFIG_8xx)
#define MMU_init_hw() do { } while(0)
-#define mmu_mapin_ram() (0UL)
+#define mmu_mapin_ram(top) (0UL)
#elif defined(CONFIG_4xx)
extern void MMU_init_hw(void);
-extern unsigned long mmu_mapin_ram(void);
+extern unsigned long mmu_mapin_ram(unsigned long top);
#elif defined(CONFIG_FSL_BOOKE)
extern void MMU_init_hw(void);
-extern unsigned long mmu_mapin_ram(void);
+extern unsigned long mmu_mapin_ram(unsigned long top);
extern void adjust_total_lowmem(void);
#elif defined(CONFIG_PPC32)
--
1.6.5.4
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [Next] CPU Hotplug test failures on powerpc
From: Sachin Sant @ 2009-12-14 4:37 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Peter Zijlstra, Linux/PPC Development, Ingo Molnar, linux-next,
linux-kernel
In-Reply-To: <1260758933.2217.7.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
>
>> While executing cpu_hotplug(from autotest) tests against latest
>> next on a power6 box, the machine locks up. A soft reset shows
>> the following trace
>>
>
> Have you heard anything about that one yet or it's still to be
> debugged ? It probably hit upstream by now.
>
Haven't received any response yet.
As you mentioned that patch went upstream and so did the problem.
thanks
-Sachin
> Cheers,
> Ben.
>
>
>> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
>> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
>> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
>> sp: c00000000c933650
>> msr: 8000000000089032
>> current = 0xc00000000c173840
>> paca = 0xc000000000bc2600
>> pid = 2602, comm = hotplug06.top.s
>> enter ? for help
>> [link register ] c000000000342f10 .cpumask_next_and+0x4c/0x94
>> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0x74 (unreliable)
>> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
>> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
>> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
>> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
>> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
>> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
>> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
>> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
>> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
>> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
>> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
>> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
>> SP (fffe7aef200) is in userspace
>> 0:mon> e
>> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
>> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
>> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
>> sp: c00000000c933650
>> msr: 8000000000089032
>> current = 0xc00000000c173840
>> paca = 0xc000000000bc2600
>> pid = 2602, comm = hotplug06.top.s
>>
>> Last few messages from the dmesg log shows
>>
>> 0:mon>
>> <4>IRQ 17 affinity broken off cpu 0
>> <4>IRQ 18 affinity broken off cpu 0
>> <4>IRQ 19 affinity broken off cpu 0
>> <4>IRQ 264 affinity broken off cpu 0
>> <4>cpu 0 (hwid 0) Ready to die...
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
>> <4>Processor 0 found.
>> <4>IRQ 17 affinity broken off cpu 1
>> <4>IRQ 18 affinity broken off cpu 1
>> <4>IRQ 19 affinity broken off cpu 1
>> <4>IRQ 264 affinity broken off cpu 1
>> <4>cpu 1 (hwid 1) Ready to die...
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
>> <4>Processor 1 found.
>> <4>cpu 1 (hwid 1) Ready to die...
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
>> <4>Processor 1 found.
>> <4>cpu 1 (hwid 1) Ready to die...
>> <6>process 2423 (bash) no longer affine to cpu1
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
>> <4>Processor 1 found.
>> <4>cpu 1 (hwid 1) Ready to die...
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
>> <4>Processor 1 found.
>> <4>cpu 1 (hwid 1) Ready to die...
>> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
>> <4>Processor 1 found.
>> <4>cpu 1 (hwid 1) Ready to die...
>> <3>INFO: RCU detected CPU 0 stall (t=1000 jiffies)
>> <3>INFO: RCU detected CPU 0 stall (t=4000 jiffies)
>> 0:mon>
>>
>> After some debugging a possible suspect seems to be commit
>> 6ad4c18.. : sched: Fix balance vs hotplug race
>>
>> If i revert this patch i am able to execute the tests on this
>> power6 without any issues.
>>
>> But at the same time the above patch is required to solve the
>> cpu hotplug related race on x86_64(as a side note this same
>> x86_64 issue can be recreated against latest Linus git as well)
>> that i reported here :
>>
>> http://marc.info/?l=linux-kernel&m=125802682922299&w=2
>>
>> I will try few more iterations with and without the above
>> patch just to make sure i have the correct results.
>>
>> If someone has a suggestion let me know.
>>
>> Thanks
>> -Sachin
>>
>>
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
^ permalink raw reply
* [PATCH] nouveau: Fix endianness with new context program loader
From: Benjamin Herrenschmidt @ 2009-12-14 3:31 UTC (permalink / raw)
To: Ben Skeggs; +Cc: nouveau, Dave Airlie, linuxppc-dev
When switching to request_firmware() to load the context programs,
some endian fixes need to be applied. This makes it work again on
my quad g5 nvidia 6600.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
drivers/gpu/drm/nouveau/nv40_graph.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv40_graph.c b/drivers/gpu/drm/nouveau/nv40_graph.c
index d3e0a2a..7e8547c 100644
--- a/drivers/gpu/drm/nouveau/nv40_graph.c
+++ b/drivers/gpu/drm/nouveau/nv40_graph.c
@@ -252,8 +252,9 @@ nv40_grctx_init(struct drm_device *dev)
memcpy(pgraph->ctxprog, fw->data, fw->size);
cp = pgraph->ctxprog;
- if (cp->signature != 0x5043564e || cp->version != 0 ||
- cp->length != ((fw->size - 7) / 4)) {
+ if (le32_to_cpu(cp->signature) != 0x5043564e ||
+ cp->version != 0 ||
+ le16_to_cpu(cp->length) != ((fw->size - 7) / 4)) {
NV_ERROR(dev, "ctxprog invalid\n");
release_firmware(fw);
nv40_grctx_fini(dev);
@@ -281,8 +282,9 @@ nv40_grctx_init(struct drm_device *dev)
memcpy(pgraph->ctxvals, fw->data, fw->size);
cv = (void *)pgraph->ctxvals;
- if (cv->signature != 0x5643564e || cv->version != 0 ||
- cv->length != ((fw->size - 9) / 8)) {
+ if (le32_to_cpu(cv->signature) != 0x5643564e ||
+ cv->version != 0 ||
+ le32_to_cpu(cv->length) != ((fw->size - 9) / 8)) {
NV_ERROR(dev, "ctxvals invalid\n");
release_firmware(fw);
nv40_grctx_fini(dev);
@@ -294,8 +296,9 @@ nv40_grctx_init(struct drm_device *dev)
cp = pgraph->ctxprog;
nv_wr32(dev, NV40_PGRAPH_CTXCTL_UCODE_INDEX, 0);
- for (i = 0; i < cp->length; i++)
- nv_wr32(dev, NV40_PGRAPH_CTXCTL_UCODE_DATA, cp->data[i]);
+ for (i = 0; i < le16_to_cpu(cp->length); i++)
+ nv_wr32(dev, NV40_PGRAPH_CTXCTL_UCODE_DATA,
+ le32_to_cpu(cp->data[i]));
pgraph->accel_blocked = false;
return 0;
@@ -329,8 +332,9 @@ nv40_grctx_vals_load(struct drm_device *dev, struct nouveau_gpuobj *ctx)
if (!cv)
return;
- for (i = 0; i < cv->length; i++)
- nv_wo32(dev, ctx, cv->data[i].offset, cv->data[i].value);
+ for (i = 0; i < le32_to_cpu(cv->length); i++)
+ nv_wo32(dev, ctx, le32_to_cpu(cv->data[i].offset),
+ le32_to_cpu(cv->data[i].value));
}
/*
^ permalink raw reply related
* Re: [Next] CPU Hotplug test failures on powerpc
From: Benjamin Herrenschmidt @ 2009-12-14 2:48 UTC (permalink / raw)
To: Sachin Sant
Cc: Peter Zijlstra, Linux/PPC Development, Ingo Molnar, linux-next,
linux-kernel
In-Reply-To: <4B2224C7.1020908@in.ibm.com>
On Fri, 2009-12-11 at 16:23 +0530, Sachin Sant wrote:
> While executing cpu_hotplug(from autotest) tests against latest
> next on a power6 box, the machine locks up. A soft reset shows
> the following trace
Have you heard anything about that one yet or it's still to be
debugged ? It probably hit upstream by now.
Cheers,
Ben.
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> sp: c00000000c933650
> msr: 8000000000089032
> current = 0xc00000000c173840
> paca = 0xc000000000bc2600
> pid = 2602, comm = hotplug06.top.s
> enter ? for help
> [link register ] c000000000342f10 .cpumask_next_and+0x4c/0x94
> [c00000000c933650] c0000000000e9f34 .cpuset_cpus_allowed_locked+0x38/0x74 (unreliable)
> [c00000000c9336e0] c000000000090074 .move_task_off_dead_cpu+0xc4/0x1ac
> [c00000000c9337a0] c0000000005e4e5c .migration_call+0x304/0x830
> [c00000000c933880] c0000000005e0880 .notifier_call_chain+0x68/0xe0
> [c00000000c933920] c00000000012a92c ._cpu_down+0x210/0x34c
> [c00000000c933a90] c00000000012aad8 .cpu_down+0x70/0xa8
> [c00000000c933b20] c000000000525940 .store_online+0x54/0x894
> [c00000000c933bb0] c000000000463430 .sysdev_store+0x3c/0x50
> [c00000000c933c20] c0000000001f8320 .sysfs_write_file+0x124/0x18c
> [c00000000c933ce0] c00000000017edac .vfs_write+0xd4/0x1fc
> [c00000000c933d80] c00000000017efdc .SyS_write+0x58/0xa0
> [c00000000c933e30] c0000000000085b4 syscall_exit+0x0/0x40
> --- Exception: c01 (System Call) at 00000fff9fa8a8f8
> SP (fffe7aef200) is in userspace
> 0:mon> e
> cpu 0x0: Vector: 100 (System Reset) at [c00000000c9333d0]
> pc: c0000000003433d8: .find_next_bit+0x54/0xc4
> lr: c000000000342f10: .cpumask_next_and+0x4c/0x94
> sp: c00000000c933650
> msr: 8000000000089032
> current = 0xc00000000c173840
> paca = 0xc000000000bc2600
> pid = 2602, comm = hotplug06.top.s
>
> Last few messages from the dmesg log shows
>
> 0:mon>
> <4>IRQ 17 affinity broken off cpu 0
> <4>IRQ 18 affinity broken off cpu 0
> <4>IRQ 19 affinity broken off cpu 0
> <4>IRQ 264 affinity broken off cpu 0
> <4>cpu 0 (hwid 0) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[0]
> <4>Processor 0 found.
> <4>IRQ 17 affinity broken off cpu 1
> <4>IRQ 18 affinity broken off cpu 1
> <4>IRQ 19 affinity broken off cpu 1
> <4>IRQ 264 affinity broken off cpu 1
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <6>process 2423 (bash) no longer affine to cpu1
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <7>clockevent: decrementer mult[83126e97] shift[32] cpu[1]
> <4>Processor 1 found.
> <4>cpu 1 (hwid 1) Ready to die...
> <3>INFO: RCU detected CPU 0 stall (t=1000 jiffies)
> <3>INFO: RCU detected CPU 0 stall (t=4000 jiffies)
> 0:mon>
>
> After some debugging a possible suspect seems to be commit
> 6ad4c18.. : sched: Fix balance vs hotplug race
>
> If i revert this patch i am able to execute the tests on this
> power6 without any issues.
>
> But at the same time the above patch is required to solve the
> cpu hotplug related race on x86_64(as a side note this same
> x86_64 issue can be recreated against latest Linus git as well)
> that i reported here :
>
> http://marc.info/?l=linux-kernel&m=125802682922299&w=2
>
> I will try few more iterations with and without the above
> patch just to make sure i have the correct results.
>
> If someone has a suggestion let me know.
>
> Thanks
> -Sachin
>
>
^ 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