[PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.0 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.0 +0200
@@ -666,9 +666,10 @@ static void mpc8xxx_spi_cs_control(struc
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev-platform_data);
u16 cs = spi-chip_select;
int gpio = pinfo-gpios[cs];
- bool alow = pinfo-alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo-alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +708,29 @@ static int of_mpc8xxx_spi_get_chipselect
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, can't request gpio #%d: %d\n, i,
ret);
+ goto err_loop;
+ }
+
+ pinfo-gpios[i] = gpio;
+ pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo-gpios[i],
+ pinfo-alow_flags[i]);
+ if (ret) {
+ dev_err(dev, can't set output direction for gpio
+ #%d: %d\n, i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo-gpios[i] = -EEXIST;
+ } else {
dev_err(dev, invalid gpio #%d: %d\n, i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, can't request gpio #%d: %d\n, i, ret);
- goto err_loop;
- }
-
- pinfo-gpios[i] = gpio;
- pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo-gpios[i],
- pinfo-alow_flags[i]);
- if (ret) {
- dev_err(dev, can't set output direction for gpio
- #%d: %d\n, i, ret);
- goto err_loop;
- }
}
pdata-max_chipselect = ngpios;
--
--
Rini van Zetten
Senior Software Engineer
-
ARVOO Engineering B.V.
Tasveld 13
3417 XS Montfoort
The Netherlands
E-mail : mailto:r...@arvoo.com Rini van Zetten
Web : www.arvoo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver
Hi Grant,
some comments below:
(by the way, have you tested this patch on hardware? I wonder because of the
SSOE-issue, but maybe it works despite the documentation.)
On Wed, Jun 17, 2009 at 08:55:01PM -0600, Grant Likely wrote:
From: Grant Likely grant.lik...@secretlab.ca
Adds support for the dedicated SPI device on the Freescale MPC5200(b)
SoC.
Signed-off-by: Grant Likely grant.lik...@secretlab.ca
---
Hi David,
It's been a while since I've posted this, but I believe I've addressed
all the outstanding comments against v3, and people are asking me for it.
The pre-message stuff is all gone and the error handling should be
better now.
BTW, the premessage stuff was to handle a platform I had where some of
the CS lines were controlled with a separate SPI transaction to the
same SPI controller. It almost looks like an SPI bridge. It requires
more thought before I try again.
Being a new driver, it would be nice to get it into 2.6.31, but
definitely not critical.
g.
drivers/spi/Kconfig |8 +
drivers/spi/Makefile|1
drivers/spi/mpc52xx_spi.c | 520
+++
include/linux/spi/mpc52xx_spi.h | 10 +
4 files changed, 539 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/mpc52xx_spi.c
create mode 100644 include/linux/spi/mpc52xx_spi.h
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 83a185d..1994bcd 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -132,6 +132,14 @@ config SPI_LM70_LLP
which interfaces to an LM70 temperature sensor using
a parallel port.
+config SPI_MPC52xx
+ tristate Freescale MPC52xx SPI (non-PSC) controller support
+ depends on PPC_MPC52xx SPI
+ select SPI_MASTER_OF
+ help
+ This drivers supports the MPC52xx SPI controller in master SPI
+ mode.
+
config SPI_MPC52xx_PSC
tristate Freescale MPC52xx PSC SPI controller
depends on PPC_MPC52xx EXPERIMENTAL
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 5d04519..8de32c7 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_SPI_OMAP_UWIRE)+= omap_uwire.o
obj-$(CONFIG_SPI_OMAP24XX) += omap2_mcspi.o
obj-$(CONFIG_SPI_ORION) += orion_spi.o
obj-$(CONFIG_SPI_MPC52xx_PSC)+= mpc52xx_psc_spi.o
+obj-$(CONFIG_SPI_MPC52xx)+= mpc52xx_spi.o
obj-$(CONFIG_SPI_MPC83xx)+= spi_mpc83xx.o
obj-$(CONFIG_SPI_S3C24XX_GPIO) += spi_s3c24xx_gpio.o
obj-$(CONFIG_SPI_S3C24XX)+= spi_s3c24xx.o
diff --git a/drivers/spi/mpc52xx_spi.c b/drivers/spi/mpc52xx_spi.c
new file mode 100644
index 000..ef8379b
--- /dev/null
+++ b/drivers/spi/mpc52xx_spi.c
@@ -0,0 +1,520 @@
+/*
+ * MPC52xx SPI bus driver.
+ *
+ * Copyright (C) 2008 Secret Lab Technologies Ltd.
+ *
+ * This file is released under the GPLv2
+ *
+ * This is the driver for the MPC5200's dedicated SPI controller.
+ *
+ * Note: this driver does not support the MPC5200 PSC in SPI mode. For
+ * that driver see drivers/spi/mpc52xx_psc_spi.c
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/of_platform.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/spi/mpc52xx_spi.h
Is this still needed? See last comment...
+#include linux/of_spi.h
+#include linux/io.h
+#include asm/time.h
Really asm?
+#include asm/mpc52xx.h
+
+MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
+MODULE_DESCRIPTION(MPC52xx SPI (non-PSC) Driver);
+MODULE_LICENSE(GPL);
+
+/* Register offsets */
+#define SPI_CTRL10x00
+#define SPI_CTRL1_SPIE (1 7)
+#define SPI_CTRL1_SPE(1 6)
+#define SPI_CTRL1_MSTR (1 4)
+#define SPI_CTRL1_CPOL (1 3)
+#define SPI_CTRL1_CPHA (1 2)
+#define SPI_CTRL1_SSOE (1 1)
+#define SPI_CTRL1_LSBFE (1 0)
+
+#define SPI_CTRL20x01
+#define SPI_BRR 0x04
+
+#define SPI_STATUS 0x05
+#define SPI_STATUS_SPIF (1 7)
+#define SPI_STATUS_WCOL (1 6)
+#define SPI_STATUS_MODF (1 4)
+
+#define SPI_DATA 0x09
+#define SPI_PORTDATA 0x0d
+#define SPI_DATADIR 0x10
+
+/* FSM state return values */
+#define FSM_STOP 0 /* Nothing more for the state machine to */
+ /* do. If something interesting happens */
+ /* then and IRQ will be received */
s/and/an/? Throughout the comments, there is sometimes a double space.
+#define FSM_POLL 1 /* need to poll for completion, an IRQ is */
+ /* not expected */
+#define FSM_CONTINUE 2 /* Keep iterating the state machine */
+
+/* Driver internal data */
+struct mpc52xx_spi {
+
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
* Paul Mackerras pau...@samba.org wrote: Ingo Molnar writes: Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? Kumar's comments seemed to me to be wanting changes to accommodate code that doesn't exist yet, so I think those changes should be done later when that code exists and we know exactly what is needed. So the current patches are fine as-is IMO. ok - will queue them up. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 6/6] perf_counter: tools: Makefile tweaks for 64-bit powerpc
* Paul Mackerras pau...@samba.org wrote: This also removes the -Werror flag when building on a 64-bit powerpc machine. The userspace definition of u64 is unsigned long rather than unsigned long long, meaning that gcc warns every time a u64 is printed with %Lx or %llx (though that does work properly). In future we may use PRI64 etc. for printing 64-bit quantities, which would eliminate these warnings. +# Don't use -Werror on ppc64; we get warnings due to using +# %Lx formats on __u64, which is unsigned long. +Werror := -Werror +ifeq ($(uname_M),ppc64) + Werror := +endif Note, i left out this bit from the commit - we need to find a better solution than to allow ugly warnings on PowerPC. Could we use the kernel's u64 type directly perhaps? That would allow us to change all __u64 to u64 in all of tools/perf/ which is a nice clean-up in any case. Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add irqtrace support for 32-bit powerpc (v2)
On Thu, 2009-06-18 at 13:43 +1000, Benjamin Herrenschmidt wrote: Index: linux-work/arch/powerpc/kernel/udbg.c === --- linux-work.orig/arch/powerpc/kernel/udbg.c 2009-06-18 13:21:29.0 +1000 +++ linux-work/arch/powerpc/kernel/udbg.c 2009-06-18 13:21:39.0 +1000 @@ -65,6 +65,7 @@ void __init udbg_early_init(void) #ifdef CONFIG_PPC_EARLY_DEBUG console_loglevel = 10; #endif + register_early_udbg_console(); } And that bit of course have nothing to do in that patch :-) No need for a respin for now though unless we find other problems. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PowerPC PCI DMA issues (prefetch/coherency?)
Chris Pringle wrote: Chris Pringle wrote: You could enable CONFIG_NOT_COHERENT_CACHE. I've just tried this (I had to edit Kconfig in power/platforms to make the build system accept it), and interestingly it's making no difference. I'm using streaming mappings, and are using the pci_map_sg functions to ensure the memory is mapped/flushed correctly. I've also explicitly put in a pci_dma_sync_sg_for_device, however that's also not made any difference. Turning the cpu cache snoop off has the same affect as it did without CONFIG_NOT_COHERENT_CACHE; it gets much worse. Any other ideas? Will back off the low latency patches next, and give 2.6.30 a try - see if that makes any difference. Low latency patches made no difference. Tried it with 2.6.30 and it now works. There are a couple of commits contributing to the fix, including one introduced between 2.6.29-rc8 and 2.6.29 proper in powerpc/kernel/head_32.S (couple of commits with the name Fix Respect _PAGE_COHERENT on classic ppc32 SW TLB load machines). I've tried backporting this to 2.6.29-rc8 and it then worked. Backporting to 2.6.26 made no difference however, so I suspect there are other things fixed which are also contributing. I'm going to move to 2.6.29/2.6.30 which should resolve our issue. Thanks to all who have contributed to this thread. The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE needs _PAGE_COHERENT in order to work correctly, and in fact there is now a comment in there to that affect in 2.6.29. Backporting that change has made it work on 2.6.26. Both this patch, and the fix to head_32.S are needed for it to work correctly on older kernels. Chris -- __ Chris Pringle Software Engineer Miranda Technologies Ltd. Hithercroft Road Wallingford Oxfordshire OX10 9DG UK Tel. +44 1491 820206 Fax. +44 1491 820001 www.miranda.com Miranda Technologies Limited Registered in England and Wales CN 02017053 Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PowerPC] Badness at drivers/char/tty_ldisc.c:210 during shutdown
I came across the following badness message during shutdown on a Power6 box.
This was with 2.6.30-git12(3fe0344faf7fdcb158bd5c1a9aec960a8d70c8e8)
[ cut here ]
Badness at drivers/char/tty_ldisc.c:210
NIP: c0409428 LR: c0409410 CTR:
REGS: c000374f37f0 TRAP: 0700 Not tainted (2.6.30-git12)
MSR: 80029032 EE,ME,CE,IR,DR CR: 24000484 XER: 0001
TASK = c0003d941ae0[8535] 'vhangup' THREAD: c000374f CPU: 1
6GPR00: 0001 c000374f3a70 c0ef4550 0001
6GPR04: c0409410 c0003e99f000 c0406ba0
6GPR08: c000374f3a70
6GPR12: 24000488 c1002600
6GPR16: 320c8a50 0002 320b03b0
6GPR20: c0003e1d3d00 0001
6GPR24: 0001 c0003d4a05e0
6GPR28: c13ffd38 c0e7e610 c000374f3a70
NIP [c0409428] .tty_ldisc_put+0xbc/0xf4
LR [c0409410] .tty_ldisc_put+0xa4/0xf4
Call Trace:
[c000374f3a70] [c0409410] .tty_ldisc_put+0xa4/0xf4 (unreliable)
[c000374f3b10] [c0409808] .tty_ldisc_reinit+0x38/0x80
[c000374f3ba0] [c040a218] .tty_ldisc_hangup+0x190/0x260
[c000374f3c40] [c04000d0] .do_tty_hangup+0x188/0x4c0
[c000374f3d20] [c0400480] .tty_vhangup_self+0x34/0x54
[c000374f3db0] [c01917c8] .sys_vhangup+0x38/0x58
[c000374f3e30] [c0008534] syscall_exit+0x0/0x40
Instruction dump:
912b0088 4bcd2201 6000 e87e8008 7f44d378 481c0735 6000 801b0008
7c09fe70 7d200278 7c004850 54000ffe 0b00 7f63db78 4bd7cf0d 6000
Not sure if this is a new issue. I haven't really paid attention
to messages that are displayed during shutdown.
Line 210 corresponds to the following code.
static void tty_ldisc_put(struct tty_ldisc *ld)
{
..
spin_unlock_irqrestore(tty_ldisc_lock, flags);
WARN_ON(ld-refcount); ===
...
Thanks
-Sachin
--
-
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
-
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
On Jun 18, 2009, at 1:19 AM, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
Anton,
Can you review and ack this if you are ok with it.
- k
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.0 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.0 +0200
@@ -666,9 +666,10 @@ static void mpc8xxx_spi_cs_control(struc
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev-
platform_data);
u16 cs = spi-chip_select;
int gpio = pinfo-gpios[cs];
- bool alow = pinfo-alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo-alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
+ }
}
static int of_mpc8xxx_spi_get_chipselects(struct device *dev)
@@ -707,27 +708,29 @@ static int of_mpc8xxx_spi_get_chipselect
enum of_gpio_flags flags;
gpio = of_get_gpio_flags(np, i, flags);
- if (!gpio_is_valid(gpio)) {
+ if (gpio_is_valid(gpio)) {
+ ret = gpio_request(gpio, dev_name(dev));
+ if (ret) {
+ dev_err(dev, can't request gpio #%d: %d\n, i,
ret);
+ goto err_loop;
+ }
+
+ pinfo-gpios[i] = gpio;
+ pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
+
+ ret = gpio_direction_output(pinfo-gpios[i],
+ pinfo-alow_flags[i]);
+ if (ret) {
+ dev_err(dev, can't set output direction for gpio
+ #%d: %d\n, i, ret);
+ goto err_loop;
+ }
+ } else if (gpio == -EEXIST) {
+ pinfo-gpios[i] = -EEXIST;
+ } else {
dev_err(dev, invalid gpio #%d: %d\n, i, gpio);
goto err_loop;
}
-
- ret = gpio_request(gpio, dev_name(dev));
- if (ret) {
- dev_err(dev, can't request gpio #%d: %d\n, i, ret);
- goto err_loop;
- }
-
- pinfo-gpios[i] = gpio;
- pinfo-alow_flags[i] = flags OF_GPIO_ACTIVE_LOW;
-
- ret = gpio_direction_output(pinfo-gpios[i],
- pinfo-alow_flags[i]);
- if (ret) {
- dev_err(dev, can't set output direction for gpio
- #%d: %d\n, i, ret);
- goto err_loop;
- }
}
pdata-max_chipselect = ngpios;
--
--
Rini van Zetten
Senior Software Engineer
-
ARVOO Engineering B.V.
Tasveld 13
3417 XS Montfoort
The Netherlands
E-mail : mailto:r...@arvoo.com Rini van Zetten
Web : www.arvoo.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
On Jun 17, 2009, at 6:24 PM, Paul Mackerras wrote: Kumar Gala writes: This should be something like: obj64-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_64) +obj32-$(CONFIG_PPC_PERF_CTRS) += mpc7450-pmu.o obj32-$(CONFIG_PPC_PERF_CTRS)-$(PPC_BOOK3S_32) Or use new Kconfig types as I suggested on patch 1/6 Feel free to send a patch making those changes along with adding the code to support the Freescale embedded PMU. :) Paul. In looking at doing this what suggestions do you have in implementing perf_instruction_pointer() if we don't have the equivalent of SIAR. Just use regs-nip ? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Interesting scheme. I guess this is for eSPI controllers that can
do their own chip-selects, but we want GPIO chip selects in addition
(or in place of built-in ones), correct?
Signed-off-by: Rini van Zetten r...@arvoo.nl
---
Changes :
patch against 2.6.30-rc8-mm1
I assume this is v2 already, and I overlooked v1, sorry.
Technically the patch looks OK, but please fix some cosmetics issues.
checkpatch reports:
WARNING: patch prefix 'drivers' exists, appears to be a -p0 patch
WARNING: line over 80 characters
#131: FILE: spi/spi_mpc8xxx.c:714:
+ dev_err(dev, can't request gpio #%d: %d\n, i,
ret);
WARNING: line over 80 characters
#141: FILE: spi/spi_mpc8xxx.c:724:
+ dev_err(dev, can't set output direction for
gpio
--- drivers/spi/spi_mpc8xxx.c.org 2009-06-12 10:45:21.0 +0200
+++ drivers/spi/spi_mpc8xxx.c 2009-06-12 10:54:48.0 +0200
@@ -666,9 +666,10 @@ static void mpc8xxx_spi_cs_control(struc
struct mpc8xxx_spi_probe_info *pinfo = to_of_pinfo(dev-platform_data);
u16 cs = spi-chip_select;
int gpio = pinfo-gpios[cs];
- bool alow = pinfo-alow_flags[cs];
-
- gpio_set_value(gpio, on ^ alow);
+ if (gpio != -EEXIST) {
+ bool alow = pinfo-alow_flags[cs];
+ gpio_set_value(gpio, on ^ alow);
Please put an empty line after variable declaration.
Thanks!
--
Anton Vorontsov
email: cbouatmai...@gmail.com
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -mm][POWERPC] mpc8xxx : allow SPI without cs.
On Jun 18, 2009, at 8:09 AM, Anton Vorontsov wrote:
On Thu, Jun 18, 2009 at 08:19:44AM +0200, Rini van Zetten wrote:
This patch adds the possibility to have a spi device without a cs.
For example, the dts file should look something like this:
spi-controller {
gpios = pio1 1 0 /* cs0 */
0 /* cs1, no GPIO */
pio2 2 0;/* cs2 */
Interesting scheme. I guess this is for eSPI controllers that can
do their own chip-selects, but we want GPIO chip selects in addition
(or in place of built-in ones), correct?
That is a good question. What HW is this for (I don't think its for
eSPI but I could be wrong).
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add configurable -Werror for arch/powerpc
On Monday 15 June 2009, Timur Tabi wrote: On Mon, Jun 15, 2009 at 2:50 AM, Michael Ellermanmich...@ellerman.id.au wrote: arch/powerpc/platforms/chrp/setup.c:378: error: the frame size of 1040 bytes is larger than 1024 bytes What's so bad about a frame size larger than 1024? It's not necessarily a bug, but all frame sizes in the call chain combined must never exceed the kernel stack size. 1024 is an arbitrary limit that we warn about for a single function, because it's likely that things will break if you have more than one of these. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [spi-devel-general] [PATCH v4] powerpc/5200: Add mpc5200-spi (non-PSC) device driver
Hi Grant, The double spaces at the end of sentences are intentional. It is perhaps a bit quaint and old fashioned, but it is my writing style. Ah, okay. + + /* Statistics */ + int msg_count; + int wcol_count; + int wcol_ticks; + u32 wcol_tx_timestamp; + int modf_count; + int byte_count; Hmm, there isn't even a debug-printout for those. Putting #ifdef DEBUG around them will be ugly. Well, I can't make up if this is just overhead or useful debugging aid, so no real objection :) There used to be a sysfs interface for dumping these, but it was an ugly misuse. I'd like to leave these in. I still have the sysfs bits in a private patch and I'm going to rework them for debugfs. Okay. Maybe a comment stating the future use will be nice. But I wonder more about the usage of the SS pin and if this chipsel is needed at all (sadly I cannot test as I don't have any board with SPI connected to that device). You define the SS-pin as output, but do not set the SSOE-bit. More, you use the MODF-feature, so the SS-pin should be defined as input? According to Table 17.3 in the PM, you have that pin defined as generic purpose output. That's right. The SS handling by the SPI device is completely useless, so this driver uses it as a GPIO and asserts it manually. That definately needs a comment :D (perhaps with some more details if you know them). The MODF irq is probably irrelevant, but I'd like to leave it in for completeness. But it won't work if the pin is set to output, no? Are you sure there are no side-effects? + /* initialize the device */ + out_8(regs+SPI_CTRL1, SPI_CTRL1_SPIE | SPI_CTRL1_SPE | SPI_CTRL1_MSTR); spaces around operator. Intentional to keep from spilling past column 80; but I'll move the missing spaces to around the | operators. I think it is easier to read that way. Ah, I remember, we had this topic a while ago :D Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
killing use of ppc_md.init
ppc_md.init only exists on ppc32 and seems like its pretty useless today. The users seem to fall into two classes: 1. called to do of_platform_bus_probe() - most platforms use machine_device_initcall() for this 2. some platform init code which seems like it could move into setup_arch(). The second one seems to only be on amigaone and chrp. Anyone know if there is any harm in moving the amigaone_init() into amigaone_setup_arch() and similarly on chrp chrp_init2() into chrp_setup_arch(). - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
On Wed, Jun 17, 2009 at 02:14:20PM +1000, David Gibson wrote: On Wed, Jun 10, 2009 at 02:38:18PM +0530, K.Prasad wrote: Modify process handling code to recognise hardware debug registers during copy and flush operations. Introduce a new TIF_DEBUG task flag to indicate a process's use of debug register. Load the debug register values into a new CPU during initialisation. Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com --- arch/powerpc/kernel/process.c | 15 +++ arch/powerpc/kernel/smp.c |2 ++ 2 files changed, 17 insertions(+) Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c === --- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/process.c +++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c @@ -50,6 +50,7 @@ #include asm/syscalls.h #ifdef CONFIG_PPC64 #include asm/firmware.h +#include asm/hw_breakpoint.h #endif #include linux/kprobes.h #include linux/kdebug.h @@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig 11, SIGSEGV) == NOTIFY_STOP) return; +#ifndef CONFIG_PPC64 if (debugger_dabr_match(regs)) return; +#endif Won't this disable the check for breakpoints set by xmon - but I don't see anything in this patch series to convert xmon to use the new breakpoint interface instead. As noted by me here: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/071832.html the Xmon integration is pending. When I tried to study and integrate Xmon, I found that the HW Breakpoint triggering was broken as of 2.6.29 kernel (tested on a Power5 box). This would mean that if Xmon's hardware breakpoint infrastructure is used in tandem with the given breakpoint interfaces, they would conflict with each other resulting in difficult-to-predict behaviour (the last to grab the register will use it). I think that tidying up do_dabr() is best done along with Xmon integration. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au| minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
Ira Snyder wrote: I can do something similar by calling device_prep_dma_memcpy() lots of times. Once for each page in the scatterlist. This has the advantage of not changing the DMAEngine API. This has the disadvantage of not being a single transaction. The DMA controller will get an interrupt after each memcpy() transaction, clean up descriptors, etc. Why would it need an interrupt per memcpy? There is a DMA_PREP_INTERRUPT flag to gate interrupt generation to the last descriptor. This is how async_tx delays callbacks until the last operation in a chain has completed. Also, I am not currently seeing how your implementation achieves a single hardware transaction. It still calls fsl_dma_alloc_descriptor() per address pair? The api currently allows a call to -prep_* to generate multiple internal descriptors for a single input address (i.e. memcpy in the case where the transfer length exceeds the hardware maximum). The slave api allows for transfers from a scatterlist to a slave context. I think what is bothering me is that the fsldma slave implementation is passing a list of sideband addresses rather than a constant address context like the existing dw_dmac, so it is different. However, I can now see that trying to enforce uniformity in this area is counterproductive. The DMA_SLAVE interface will always have irreconcilable differences across architectures. It also has the disadvantage of not being able to change the controller-specific features I'm using: external start. This feature lets the 3rd device control the DMA controller. It looks like the atmel-mci driver has a similar feature. The DMAEngine API has no way to expose this type of feature except through DMA_SLAVE. Yeah, an example of an architecture specific quirk that has no chance of being uniformly handled in a generic api. If it is just the 3 helper routines that are the issue with this patch, I have no problem dropping them and letting each user re-create them themselves. I think this makes the most sense at this point. We can reserve judgement on the approach until the next fsldma-slave user arrives and tries to use this implementation for their device. Can we move the header file under arch/powerpc/include? [..] A single-transaction scatterlist-to-scatterlist copy would be nice. One of the major advantages of working with the DMA controller is that it automatically handles scatter/gather. Almost all DMA controllers have the feature, but it is totally missing from the high-level API. The engines I am familiar with (ioatdma and iop-adma) still need a hardware descriptor per address pair I do not see how fsldma does this any more automatically than those engines? I could see having a helper routine that does the mapping and iterating, but in the end the driver still sees multiple calls to -prep (unless of course you are doing this in a DMA_SLAVE context, then anything goes). Thanks, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
On Wed, Jun 17, 2009 at 02:32:24PM +1000, David Gibson wrote:
On Wed, Jun 10, 2009 at 02:38:06PM +0530, K.Prasad wrote:
Introduce PPC64 implementation for the generic hardware breakpoint
interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and
the
Makefile.
[snip]
+int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
+{
+ /* Symbol names from user-space are rejected */
+ if (tsk) {
+ if (bp-info.name)
+ return -EINVAL;
+ else
+ return 0;
+ }
+ /*
+* User-space requests will always have the address field populated
+* For kernel-addresses, either the address or symbol name can be
+* specified.
+*/
+ if (bp-info.name)
+ bp-info.address = (unsigned long)
+ kallsyms_lookup_name(bp-info.name);
+ if (bp-info.address)
+ if (kallsyms_lookup_size_offset(bp-info.address,
+ (bp-info.symbolsize), NULL))
+ return 0;
+ return -EINVAL;
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk)
+{
+ int is_kernel, ret = -EINVAL;
+
+ if (!bp)
+ return ret;
+
+ switch (bp-info.type) {
+ case HW_BREAKPOINT_READ:
+ case HW_BREAKPOINT_WRITE:
+ case HW_BREAKPOINT_RW:
+ break;
+ default:
+ return ret;
+ }
+
+ if (bp-triggered)
+ ret = arch_store_info(bp, tsk);
Under what circumstances would triggered be NULL? It's not clear to
me that you wouldn't still need arch_store_info() in this case.
Simple, triggered would be NULL when a user fails to specify it!
This function would return EINVAL if that's the case.
+
+ is_kernel = is_kernel_addr(bp-info.address);
+ if ((tsk is_kernel) || (!tsk !is_kernel))
+ return -EINVAL;
+
+ return ret;
+}
+
snipped
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ int rc = NOTIFY_STOP;
+ struct hw_breakpoint *bp;
+ struct pt_regs *regs = args-regs;
+ unsigned long dar = regs-dar;
+ int cpu, is_one_shot, stepped = 1;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+
+ cpu = get_cpu();
+ /* Determine whether kernel- or user-space address is the trigger */
+ bp = (hbp_kernel_pos == HBP_NUM) ? current-thread.hbp[0] :
+ per_cpu(this_hbp_kernel[0], cpu);
+ /*
+* bp can be NULL due to lazy debug register switching
+* or due to the delay between updates of hbp_kernel_pos
+* and this_hbp_kernel.
+*/
+ if (!bp)
+ goto out;
+
+ is_one_shot = (bp-triggered == ptrace_triggered) ? 1 : 0;
+ per_cpu(dabr_data, cpu) = (hbp_kernel_pos == HBP_NUM) ?
+ current-thread.dabr : kdabr;
+
+ /* Verify if dar lies within the address range occupied by the symbol
+* being watched. Since we cannot get the symbol size for
+* user-space requests we skip this check in that case
+*/
+ if ((hbp_kernel_pos == 0)
+ !((bp-info.address = dar)
+(dar = (bp-info.address + bp-info.symbolsize
+ /*
+* This exception is triggered not because of a memory access on
+* the monitored variable but in the double-word address range
+* in which it is contained. We will consume this exception,
+* considering it as 'noise'.
+*/
+ goto out;
+
+ (bp-triggered)(bp, regs);
So this confuses me. You go to great efforts to step over the
instruction to generate a SIGTRAP after the instruction, for
consistency with x86. But that SIGTRAP is *never* used, since the
only way to set userspace breakpoints is through ptrace at the moment.
At the same time, the triggered function is called here before the
instruction is executed, so not consistent with x86 anyway.
It just seems strange to me that sending a SIGTRAP is a special case
anyway. Why can't sending a SIGTRAP be just a particular triggered
function.
The consistency in the interface across architectures that I referred to
in my previous mail was w.r.t. continuous triggering of breakpoints and
not to implement a trigger-before or trigger-after behaviour across
architectures. In fact, this behaviour differs even on the same
processor depending upon the breakpoint type (trigger-before for
instructions and trigger-after for data in x86), and introducing
uniformity might be a) at the cost of loss of some unique innovative
uses for each of them b) may not be always possible e.g.
Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
Hi Ben et al,
Benjamin Herrenschmidt wrote:
On Tue, 2009-06-16 at 10:28 -0400, Geoff Thorpe wrote:
[snip]
Maybe we can shrink that file significantly (and avoid the risk for
typos etc...) by generating them all from a macro.
Something like (typed directly into the mailer :-)
#define DEFINE_BITOP(op, prefix, postfix) \
asm volatile (\
prefix\
1:PPC_LLARX %0,0,%3\n \
__stringify(op) %1,%0,%2\n \
PPC405_ERR77(0,%3)\
PPC_STLCX %1,0,%3\n \
bne- 1b\n \
postfix \
: =r (old), =r (t)
: r (mask), r (p)
: cc, memory)
and so:
static inline void set_bits(unsigned long mask, volatile unsigned long
*addr)
{
unsigned long old, t;
DEFINE_BITOP(or, , );
}
static inline void test_and_set_bits(unsigned long mask, volatile unsigned
long *addr)
{
unsigned long old, t;
DEFINE_BITOP(or, LWSYNC_ON_SMP, ISYNC_ON_SMP);
return (old mask) != 0;
}
etc...
Sounds good, I'll try working this up and I'll send a new patch shortly.
You can also go totally mad and generate the whole function (both -s and
non -s variants) from one macro but I wouldn't go that far :-)
I've prepared a new patch, will send it in a moment. It uses two macros
rather than one - as the test_and_***() APIs have a fundamentally
different asm because of the arguments to 'op' as well as the output
operands. However, this split made it possible to generate the entire
inner (single-word) function using the macro, rather than just the
inline asm part.
So can I assume implicitly that changing the set_bits() function to add
the 'volatile' qualifier to the prototype (and the missing
PPC405_ERR77() workaround) was OK?
The PPC405_ERR77 workaround is definitely needed. The volatile, well, I
suspect it's useless, but it will remove warnings when callers call
these on something that is declared as volatile in the first place.
Do x86 use volatile there ? If not, then don't do it on powerpc neither,
it could well be an historical remain. It's not functionally useful, the
memory clobber in the asm takes care of telling the compiler not to
mess around I believe.
I've left the volatile qualifier in the generated API because I didn't
feel so comfortable changing APIs, but I also added the memory clobber
for all cases - whereas it seems the existing set_bits(), clear_bits(),
[...] functions didn't declare this... Do you see any issue with having
the 'volatile' in the prototype as well as the clobber in the asm?
Actually, might as well just respond to the new patch instead... :-) Thx.
Cheers,
Geoff
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
On Thu, Jun 18, 2009 at 11:16:03AM -0700, Dan Williams wrote: Ira Snyder wrote: I can do something similar by calling device_prep_dma_memcpy() lots of times. Once for each page in the scatterlist. This has the advantage of not changing the DMAEngine API. This has the disadvantage of not being a single transaction. The DMA controller will get an interrupt after each memcpy() transaction, clean up descriptors, etc. Why would it need an interrupt per memcpy? There is a DMA_PREP_INTERRUPT flag to gate interrupt generation to the last descriptor. This is how async_tx delays callbacks until the last operation in a chain has completed. Also, I am not currently seeing how your implementation achieves a single hardware transaction. It still calls fsl_dma_alloc_descriptor() per address pair? Ok, there are a few things here: 1) an interrupt per memcpy The *software* using DMAEngine doesn't need one interrupt per memcpy. That is controlled by the DMA_PREP_INTERRUPT flag, exactly as you describe. The Freescale DMA driver DOES use one interrupt per async_tx descriptor. See drivers/dma/fsldma.c dma_init() and append_ld_queue(). The FSL_DMA_MR_EOTIE flag in dma_init() tells the controller to generate an interrupt at the end of each transfer. A transfer is (potentially long) list of address pairs / hardware descriptors. The FSL_DMA_MR_EOSIE flag in append_ld_queue() tells the controller to generate an interrupt at the end of transferring this hardware descriptor (AKA segment). The driver combines multiple memcpy operations into a single transfer. When the driver combines operations, it adds the EOSIE flag to the descriptor that would-have-been the end of a transfer. It uses this interrupt to update the DMA cookie, presumably to speed up users of dma_sync_wait() when there are lots of users sharing the DMA controller. Let me try to explain what will happen with some code: === Case 1: Two seperate transfers === dma_cookie_t t1, t2; t1 = dma_async_memcpy_buf_to_buf(...); dma_async_memcpy_issue_pending(); /* * some time goes by, the DMA transfer completes, * and the controller gets the end-of-transfer interrupt */ t2 = dma_async_memcpy_buf_to_buf(...); dma_async_memcpy_issue_pending(); /* * some time goes by, the DMA transfer completes, * and the controller gets the end-of-transfer interrupt */ This is exactly what I would expect from the API. There are two seperate transfers, and there are two hardware interrupts. Here is a crude timeline. |--||--|--- | || | t1 start t1 end, EOT interruptt2 start t2 end, EOT interrupt === Case 2: Two seperate transfers, merged by the driver === t1 = dma_async_memcpy_buf_to_buf(...); dma_async_memcpy_issue_pending(); /* * the controller starts executing the transfer, but has not * finished yet */ t2 = dma_async_memcpy_buf_to_buf(...); /* * append_ld_queue() sets the EOSIE flag on the last hardware * descriptor in t1, then sets the next link descriptor to the * first descriptor in t2 */ Now there are two transfers, and again two hardware interrupts. Again, not really a problem. Every part of the API still works as expected. |---|---|-| | | | | t1 startt2 tx_submit() t1 end, EOS interrupt, t2 start t2 end, EOT interrupt === Case 3: Two transfers, merged by the driver === t1 = dma_async_memcpy_buf_to_buf(...); t2 = dma_async_memcpy_buf_to_buf(...); dma_async_memcpy_issue_pending(); After a very careful reading of the driver, I just noticed that if there is no transfer in progress (as would be expected on a private channel) then the EOS interrupt never gets set, and the requests are simply merged together. This would lead to a timeline like this: ||--|-- || | t1 start t1 end, t2 start t2 end, EOT interrupt This is perfectly fine as well. It is the behavior I want. Some more study of the code shows that the Freescale DMA driver will not halt the channel as long as the channel is busy, meaning that it will not clear the external start bits during a transfer. So, in conclusion, I can call memcpy multiple times and have it all merged into a single transfer by the driver, with a single hardware interrupt (at the end-of-transfer) and have everything complete without halting the DMA controller. 2) Single transaction I think we're using different terms here. I define a single transaction to be the time while the DMA controller is busy transferring things. In case #1 above, there are two transfers. In case #2 above, one transfer, and two interrupts. In case #3 above, one transfer, one interrupt. 3) Hardware descriptor per address pair Yes, there can be many
Re: [RFC PATCH] fsldma: Add DMA_SLAVE support
Ira Snyder wrote: So, I see a couple of ways of moving forward: 1) Keep my implementation, moving the includes to arch/powerpc/include. Do we drop the allocation functions? +1 for option 1. Having it under arch/powerpc/include makes it clear that it is a powerpc specific api, so keep the allocation routines. Copy Kumar on the updated patch as I'll need a ppc-dev ack for carrying this file addition through the dmaengine tree. Thanks for all the input Dan. I finally feel like we're getting somewhere :) Thanks for the exchange it always helps to get a good picture of the underlying design rationale. Regards, Dan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: killing use of ppc_md.init
On Thu, 2009-06-18 at 09:38 -0500, Kumar Gala wrote: ppc_md.init only exists on ppc32 and seems like its pretty useless today. The users seem to fall into two classes: 1. called to do of_platform_bus_probe() - most platforms use machine_device_initcall() for this 2. some platform init code which seems like it could move into setup_arch(). The second one seems to only be on amigaone and chrp. Anyone know if there is any harm in moving the amigaone_init() into amigaone_setup_arch() and similarly on chrp chrp_init2() into chrp_setup_arch(). We might kill it ... and revive it differently :-) Yes, the current ppc_init() can probably just go. However, we probably also want to add a call from init/main.c back to the architectures and ppc_md. in our case that is right after mm_init(). Right now, we do way too many things at setup_arch() (or even before that on ppc64) which induces all sorts of pain due to having to use bootmem etc... Now that slab is available much earlier, before init_IRQ() and time_init(), we should consider moving a whole bunch of stuff somewhere later in the boot process to simplify the code etc... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
On Thu, 2009-06-18 at 16:30 -0400, Geoff Thorpe wrote: I've left the volatile qualifier in the generated API because I didn't feel so comfortable changing APIs, but I also added the memory clobber for all cases - whereas it seems the existing set_bits(), clear_bits(), [...] functions didn't declare this... Do you see any issue with having the 'volatile' in the prototype as well as the clobber in the asm? Actually, might as well just respond to the new patch instead... :-) Thx. I think the story with the memory clobber is that it depends whether we consider the functions as ordering accesses or not (ie, can potentially be used with lock/unlock semantics). The general rule is that those who don't return anything don't need to have those semantics, and thus could only be advertised as clobbering p[word] -but- there are issues there. For example, despite the (relatively new) official _lock/_unlock variants, there's still code that abuses constructs like test_and_set_bit/clear_bit as locks and in that case, clear bits needs a clobber. So I would say at this stage better safe than having to track down incredibly hard to find bugs, and let's make them all take that clobber. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/6] perf_counter: powerpc: Add processor back-end for MPC7450 family
Kumar Gala writes: In looking at doing this what suggestions do you have in implementing perf_instruction_pointer() if we don't have the equivalent of SIAR. Just use regs-nip ? Yes, exactly. If you don't have SIAR/SDAR/MMCRA, the default definitions for perf_instruction_pointer and perf_misc_flags in include/linux/perf_counter.h are fine, and you get them if perf_misc_flags is not defined. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] fsldma: Add DMA_SLAVE support
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some controller-specific features such as
external start and external pause for a DMA transaction.
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
After discussion with Dan Williams, this is the second version of the
DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
with both drivers I have written against this API, an FPGA programmer
and an FPGA data grabber.
Kumar, Dan asked me to add you to the CC list, so you can have a look at
this patch before he adds it to his tree.
The other two small patches I posted earlier are very helpful in testing
this functionality. They make the fsldma driver leave the BWC (bandwidth
control) bits alone on the 83xx controller, as well as making the
external start feature available on 83xx.
In order for the external start/pause features to be useful, the
bandwidth control bits (in the mode register) need to be set before
attempting to use the controller. I could spin a v3 of this patch that
adds a field to struct fsl_dma_slave to set the bits appropriately. Or I
could send another patch for that. Thoughts?
Many thanks to all that have participated in the discussion about this
patch.
v1 - v2:
* move fsldma.h from include/linux to arch/powerpc/include/asm
* add kerneldoc documentation
arch/powerpc/include/asm/fsldma.h | 134 ++
drivers/dma/fsldma.c | 224 +
2 files changed, 358 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
diff --git a/arch/powerpc/include/asm/fsldma.h
b/arch/powerpc/include/asm/fsldma.h
new file mode 100644
index 000..1bc71fb
--- /dev/null
+++ b/arch/powerpc/include/asm/fsldma.h
@@ -0,0 +1,134 @@
+/*
+ * Freescale MPC83XX / MPC85XX DMA Controller
+ *
+ * Copyright (c) 2009 Ira W. Snyder i...@ovro.caltech.edu
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __ARCH_POWERPC_ASM_FSLDMA_H__
+#define __ARCH_POWERPC_ASM_FSLDMA_H__
+
+#include linux/dmaengine.h
+
+/*
+ * Definitions for the Freescale DMA controller's DMA_SLAVE implemention
+ *
+ * The Freescale DMA_SLAVE implementation was designed to handle many-to-many
+ * transfers. An example usage would be an accelerated copy between two
+ * scatterlists. Another example use would be an accelerated copy from
+ * multiple non-contiguous device buffers into a single scatterlist.
+ *
+ * A DMA_SLAVE transaction is defined by a struct fsl_dma_slave. This
+ * structure contains a list of hardware addresses that should be copied
+ * to/from the scatterlist passed into device_prep_slave_sg(). The structure
+ * also has some fields to enable hardware-specific features.
+ */
+
+/**
+ * struct fsl_dma_hw_addr
+ * @entry: linked list entry
+ * @address: the hardware address
+ * @length: length to transfer
+ *
+ * Holds a single physical hardware address / length pair for use
+ * with the DMAEngine DMA_SLAVE API.
+ */
+struct fsl_dma_hw_addr {
+ struct list_head entry;
+
+ dma_addr_t address;
+ size_t length;
+};
+
+/**
+ * struct fsl_dma_slave
+ * @addresses: a linked list of struct fsl_dma_hw_addr structures
+ * @src_loop_size: setup and enable constant source-address DMA transfers
+ * @dst_loop_size: setup and enable constant destination address DMA transfers
+ * @external_start: enable externally started DMA transfers
+ * @external_pause: enable externally paused DMA transfers
+ *
+ * Holds a list of address / length pairs for use with the DMAEngine
+ * DMA_SLAVE API implementation for the Freescale DMA controller.
+ */
+struct fsl_dma_slave {
+
+ /* List of hardware address/length pairs */
+ struct list_head addresses;
+
+ /* Support for extra controller features */
+ unsigned int src_loop_size;
+ unsigned int dst_loop_size;
+ bool external_start;
+ bool external_pause;
+};
+
+/**
+ * fsl_dma_slave_append - add an address/length pair to a struct fsl_dma_slave
+ * @slave: the struct fsl_dma_slave to add to
+ * @address: the hardware address to add
+ * @length: the length of bytes to transfer from @address
+ *
+ * Add a hardware address/length pair to a struct fsl_dma_slave. Returns 0 on
+ * success, -ERRNO otherwise.
+ */
+static inline int fsl_dma_slave_append(struct fsl_dma_slave *slave,
+ dma_addr_t address, size_t length)
+{
+ struct fsl_dma_hw_addr *addr;
+
+ addr = kzalloc(sizeof(*addr), GFP_ATOMIC);
+ if (!addr)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(addr-entry);
+ addr-address = address;
Re: MPC83xx watchdog reset board dead lock
Hello, On Wed, Jun 17, 2009 at 2:16 PM, Norbert van Bolhuisnvbolh...@aimvalley.nl wrote: I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Interesting. Looking forward to the results. Design works as expected on the now slightly modified MPC8313E-RDB board. Kudos to David. Cheers, -- Leon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
On Wed, 2009-06-17 at 16:21 +0200, Ingo Molnar wrote: This depends on the generic atomic64_t patches, which are now in Linus' tree. Ingo, if you're putting these in, please pull Linus' tree in first. Note, i've created a new branch, tip:perfcounters/powerpc, so we can keep these things separate and Ben can pull them too. I see there was some review feedback - do you want to send a v2 version perhaps? At this stage, I'm happy for you to push them. I was thinking about moving the files around but that can wait. No serious comments on the patches themselves on my side. Cheers Ben ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/6] perf_counter: powerpc: Enable use of software counters on 32-bit powerpc
On Wed, 2009-06-17 at 16:27 +0200, Ingo Molnar wrote: I think it would be nice to have more platform support in .31. Perfcounters is a brand-new feature so there's no risk of regression. In the end it will depend on Linus to pull of course, and BenH can veto it too if he'd like no more PowerPC changes in this cycle. Worst-case it's all .32 material. There have been little PowerPC changes in this cycle and I agree with you on that it's a nice feature to have with little risk of regression. In fact, I also have an up-to-date (and hopefully working) irqtrace/lockdep patch for 32-bit powerpc (we only do 64-bit right now) that I'm considering merging this time around, the benefit it brings is worth the risk I believe. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC83xx watchdog reset board dead lock
Hi Leon, I'll be testing the design tomorrow on the reference board, I'll report results in this thread. Interesting. Looking forward to the results. Design works as expected on the now slightly modified MPC8313E-RDB board. That's great! Kudos to David. I'm sure you would have come up with a similar solution, had you had a chance to sleep on it :) Glad to help out. Cheers, Dave ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Fix FSL RapidIO probing on MDS boards
From: Randy Vinson rvin...@mvista.com
FSL RapidIO won't probe without a proper compatible entry. This
patch fixes the issue by adding fsl,rapidio-delta compatible to
mpc85xx_ids.
Signed-off-by: Randy Vinson rvin...@mvista.com
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
index b2c0a43..daf6711 100644
--- a/arch/powerpc/platforms/85xx/mpc85xx_mds.c
+++ b/arch/powerpc/platforms/85xx/mpc85xx_mds.c
@@ -268,6 +268,7 @@ static struct of_device_id mpc85xx_ids[] = {
{ .type = qe, },
{ .compatible = fsl,qe, },
{ .compatible = gianfar, },
+ { .compatible = fsl,rapidio-delta, },
{},
};
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards,
so make 1-bit mode default. When we resolve the issue, u-boot will
remove sdhci,1-bit-only property from the device tree, while SDHCI
will still work with older u-boots.
Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com
---
arch/powerpc/boot/dts/mpc8569mds.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts
b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..63e8109 100644
--- a/arch/powerpc/boot/dts/mpc8569mds.dts
+++ b/arch/powerpc/boot/dts/mpc8569mds.dts
@@ -229,6 +229,7 @@
/* Filled in by U-Boot */
clock-frequency = 0;
status = disabled;
+ sdhci,1-bit-only;
};
cry...@3 {
--
1.6.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem with memcpy on ppc8536
Hello, I am trying to debug a crash during memcpy while copying data from the FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough through my BDI3000 to see that the entire contents of the fcm buffer I want moved are actually moved off to memory location I specify. The crash comes after it memcpy finishes copying and performs the instruction 2: cmplwi 0,r5,4: memcpy: rlwinm. r7,r5,32-3,3,31 /* r0 = r5 3 */ addi r6,r3,-4 addi r4,r4,-4 beq 2f /* if less than 8 bytes to do */ andi. r0,r6,3 /* get dest word aligned */ mtctr r7 bne 5f 1: lwz r7,4(r4) lwzu r8,8(r4) stw r7,4(r6) stwu r8,8(r6) bdnz 1b andi. r5,r5,7 2: cmplwi 0,r5,4 contents of r5 are 0x0 showing that the entire 0x1000 size transfer I specified correctly finished. At this point I can check the memory contents through my BDI and verify all the data is in the ddr as I expect. Now the strange thing happens, if I execute the cmplwi 0,r5,4 the program takes an exception and eventually gets struck at exception vector 0x700 which I saw from start.S is an Alignment exception. I am not sure what this exception means, can someone help me understand what is happening? Does this exception somehow mean that memcpy did not move all the data? Does memcpy expect contents of r5 to be 4 and not 0 when it hits the cmplwi instruction? Fahd Abidi Product Manager - Technical Tools and Development Ultimate Solutions, Inc. Your Single Source for Professional Development Tools and Embedded Solutions Ph: 978-455-3383 x255 Fx: 978-926-3091 Email: fab...@ultsol.com Visit: http://www.ultsol.com http://www.ultsol.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: expose the multi-bit ops that underlie single-bit ops.
The bitops.h functions that operate on a single bit in a bitfield are
implemented by operating on the corresponding word location. In all cases
the inner logic is valid if the mask being applied has more than one bit
set, so this patch exposes those inner operations. Indeed, set_bits() was
already available, but it duplicated code from set_bit() (rather than
making the latter a wrapper) - it was also missing the PPC405_ERR77()
workaround and the volatile address qualifier present in other APIs.
This corrects that, and exposes the other multi-bit equivalents.
One advantage of these multi-bit forms is that they allow word-sized
variables to essentially be their own spinlocks, eg. very useful for
state machines where an atomic flags variable can obviate the need for
any additional locking.
Signed-off-by: Geoff Thorpe ge...@geoffthorpe.net
---
arch/powerpc/include/asm/bitops.h | 194 -
1 files changed, 61 insertions(+), 133 deletions(-)
diff --git a/arch/powerpc/include/asm/bitops.h
b/arch/powerpc/include/asm/bitops.h
index 897eade..56f2f2e 100644
--- a/arch/powerpc/include/asm/bitops.h
+++ b/arch/powerpc/include/asm/bitops.h
@@ -56,174 +56,102 @@
#define BITOP_WORD(nr) ((nr) / BITS_PER_LONG)
#define BITOP_LE_SWIZZLE ((BITS_PER_LONG-1) ~0x7)
+/* Macro for generating the ***_bits() functions */
+#define DEFINE_BITOP(fn, op, prefix, postfix) \
+static __inline__ void fn(unsigned long mask, \
+ volatile unsigned long *_p) \
+{ \
+ unsigned long old; \
+ unsigned long *p = (unsigned long *)_p; \
+ __asm__ __volatile__ ( \
+ prefix \
+1: PPC_LLARX %0,0,%3\n \
+ stringify_in_c(op) %0,%0,%2\n \
+ PPC405_ERR77(0,%3) \
+ PPC_STLCX %0,0,%3\n \
+ bne- 1b\n \
+ postfix \
+ : =r (old), +m (*p)\
+ : r (mask), r (p) \
+ : cc, memory); \
+}
+
+DEFINE_BITOP(set_bits, or, , )
+DEFINE_BITOP(clear_bits, andc, , )
+DEFINE_BITOP(clear_bits_unlock, andc, LWSYNC_ON_SMP, )
+DEFINE_BITOP(change_bits, xor, , )
+
static __inline__ void set_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-1: PPC_LLARX %0,0,%3 # set_bit\n
- or %0,%0,%2\n
- PPC405_ERR77(0,%3)
- PPC_STLCX %0,0,%3\n
- bne- 1b
- : =r (old), +m (*p)
- : r (mask), r (p)
- : cc );
+ set_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void clear_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-1: PPC_LLARX %0,0,%3 # clear_bit\n
- andc %0,%0,%2\n
- PPC405_ERR77(0,%3)
- PPC_STLCX %0,0,%3\n
- bne- 1b
- : =r (old), +m (*p)
- : r (mask), r (p)
- : cc );
+ clear_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void clear_bit_unlock(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
- LWSYNC_ON_SMP
-1: PPC_LLARX %0,0,%3 # clear_bit_unlock\n
- andc %0,%0,%2\n
- PPC405_ERR77(0,%3)
- PPC_STLCX %0,0,%3\n
- bne- 1b
- : =r (old), +m (*p)
- : r (mask), r (p)
- : cc, memory);
+ clear_bits_unlock(BITOP_MASK(nr), addr + BITOP_WORD(nr));
}
static __inline__ void change_bit(int nr, volatile unsigned long *addr)
{
- unsigned long old;
- unsigned long mask = BITOP_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BITOP_WORD(nr);
-
- __asm__ __volatile__(
-1: PPC_LLARX %0,0,%3 # change_bit\n
- xor%0,%0,%2\n
- PPC405_ERR77(0,%3)
- PPC_STLCX %0,0,%3\n
- bne- 1b
- : =r (old), +m (*p)
- : r (mask), r (p)
- : cc );
+ change_bits(BITOP_MASK(nr), addr + BITOP_WORD(nr));
+}
+
+/* Like DEFINE_BITOP(), with changes to the arguments to 'op' and the output
+ * operands. */
+#define DEFINE_TESTOP(fn, op, prefix, postfix) \
+static __inline__ unsigned long fn(\
+ unsigned long mask, \
+ volatile unsigned long *_p) \
+{ \
+ unsigned long old, t; \
+ unsigned long *p = (unsigned long *)_p; \
+ __asm__ __volatile__ (
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
On Thu, 2009-06-18 at 19:55 -0400, Mike Frysinger wrote:
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
Since the counter is only accessed within a spinlock, the volatile
wouldn't be very useful here.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
Mike Frysinger writes:
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
-mike
It's only accessed under a spinlock, so I don't think it needs to be
volatile. On UP it's accessed within local_irq_save/restore which
should also be compiler barriers and prevent memory access reordering,
so again volatile isn't needed.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] lib: Provide generic atomic64_t implementation
On Thu, Jun 18, 2009 at 20:47, Paul Mackerras wrote:
Mike Frysinger writes:
On Sat, Jun 13, 2009 at 03:10, Paul Mackerras wrote:
+typedef struct {
+ long long counter;
+} atomic64_t;
lack of volatile seems odd compared to:
include/linux/types.h:
typedef struct {
volatile int counter;
} atomic_t;
It's only accessed under a spinlock, so I don't think it needs to be
volatile. On UP it's accessed within local_irq_save/restore which
should also be compiler barriers and prevent memory access reordering,
so again volatile isn't needed.
i'm not suggesting it is needed, i'm saying it's a bit confusing. a
simple comment above the atomic64_t type with your simple explanation
here would go a long way.
-mike
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Fix BSR to allow mmap of small BSR on 64k kernel
On Mon, Nov 17, 2008 at 01:26:13AM -0600, Sonny Rao wrote:
On Fri, Nov 07, 2008 at 04:28:29PM +1100, Paul Mackerras wrote:
Sonny Rao writes:
Fix the BSR driver to allow small BSR devices, which are limited to a
single 4k space, on a 64k page kernel. Previously the driver would
reject the mmap since the size was smaller than PAGESIZE (or because
the size was greater than the size of the device). Now, we check for
this case use remap_4k_pfn(). Also, take out code to set vm_flags,
as the remap_pfn functions will do this for us.
Thanks.
Do we know that the BSR size will always be 4k if it's not a multiple
of 64k? Is it possible that we could get 8k, 16k or 32k or BSRs?
If it is possible, what does the user need to be able to do? Do they
just want to map 4k, or might then want to map the whole thing?
Hi Paul, I took a look at changing the driver to reject a request for
mapping more than a single 4k page, however the only indication we get
of the requested size in the mmap function is the vma size, and this
is always one page at minimum. So, it's not possible to determine if
the user wants one 4k page or more. As I noted in my first response,
there is only one case where this is even possible and I don't think
it is a significant concern.
I did notice that I left out the check to see if the user is trying to
map more than the device length, so I fixed that. Here's the revised
patch.
Alright, I've reworked this now so that if we get one of these cases
where there's a bsr that's 4k and 64k on a 64k kernel we'll only
advertise that it is a 4k BSR to userspace. I think this is the best
solution since user programs are only supposed to look at sysfs to
determine how much can be mapped, and libbsr does this as well.
Please consider for 2.6.31 as a fix, thanks.
---
Fix the BSR driver to allow small BSR devices on a 64k page kernel.
Previously the driver would reject the mmap since the size was smaller
than PAGESIZE. This patch adds a check for this case and uses remap_4k_pfn().
There are also casees where we have a size that is greater than 4k but
smaller than 64k, and in that case we would only map the first 4k using
remap_4k_pfn, so we also change the length that we advertise in sysfs,
so the user knows they can only map 4k.
Also, take out code to set vm_flags, as the remap_pfn functions will
do this for us.
Signed-off-by: Sonny Rao sonny...@us.ibm.com
Index: linux-2.6.30/drivers/char/bsr.c
===
--- linux-2.6.30.orig/drivers/char/bsr.c2009-06-18 13:02:16.0
-0500
+++ linux-2.6.30/drivers/char/bsr.c 2009-06-18 18:18:29.0 -0500
@@ -27,6 +27,7 @@
#include linux/cdev.h
#include linux/list.h
#include linux/mm.h
+#include asm/pgtable.h
#include asm/io.h
/*
@@ -117,15 +118,22 @@
{
unsigned long size = vma-vm_end - vma-vm_start;
struct bsr_dev *dev = filp-private_data;
+ int ret;
- if (size dev-bsr_len || (size (PAGE_SIZE-1)))
- return -EINVAL;
-
- vma-vm_flags |= (VM_IO | VM_DONTEXPAND);
vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
- if (io_remap_pfn_range(vma, vma-vm_start, dev-bsr_addr PAGE_SHIFT,
- size, vma-vm_page_prot))
+ /* check for the case of a small BSR device and map one 4k page for it*/
+ if (dev-bsr_len PAGE_SIZE size == PAGE_SIZE)
+ ret = remap_4k_pfn(vma, vma-vm_start, dev-bsr_addr 12,
+ vma-vm_page_prot);
+ else if (size = dev-bsr_len)
+ ret = io_remap_pfn_range(vma, vma-vm_start,
+dev-bsr_addr PAGE_SHIFT,
+size, vma-vm_page_prot);
+ else
+ return -EINVAL;
+
+ if (ret)
return -EAGAIN;
return 0;
@@ -205,6 +213,11 @@
cur-bsr_stride = bsr_stride[i];
cur-bsr_dev= MKDEV(bsr_major, i + total_bsr_devs);
+ /* if we have a bsr_len of 4k and less then PAGE_SIZE (64k
pages) */
+ /* we can only map 4k of it, so only advertise the 4k in sysfs
*/
+ if (cur-bsr_len 4096 cur-bsr_len PAGE_SIZE)
+ cur-bsr_len = 4096;
+
switch(cur-bsr_bytes) {
case 8:
cur-bsr_type = BSR_8;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] BSR: add 4096 byte BSR size
Add a 4096 byte BSR size which will be used on new machines. Also, remove
the warning when we run into an unknown size, as this can spam the kernel
log excessively.
Signed-off-by: Sonny Rao sonny...@us.ibm.com
Index: linux-2.6.27/drivers/char/bsr.c
===
--- linux-2.6.27.orig/drivers/char/bsr.c2009-06-18 17:50:41.0
-0500
+++ linux-2.6.27/drivers/char/bsr.c 2009-06-18 17:50:58.0 -0500
@@ -76,12 +76,13 @@
static int bsr_major;
enum {
- BSR_8 = 0,
- BSR_16 = 1,
- BSR_64 = 2,
- BSR_128 = 3,
- BSR_UNKNOWN = 4,
- BSR_MAX = 5,
+ BSR_8= 0,
+ BSR_16 = 1,
+ BSR_64 = 2,
+ BSR_128 = 3,
+ BSR_4096 = 4,
+ BSR_UNKNOWN = 5,
+ BSR_MAX = 6,
};
static unsigned bsr_types[BSR_MAX];
@@ -231,9 +232,11 @@
case 128:
cur-bsr_type = BSR_128;
break;
+ case 4096:
+ cur-bsr_type = BSR_4096;
+ break;
default:
cur-bsr_type = BSR_UNKNOWN;
- printk(KERN_INFO unknown BSR size
%d\n,cur-bsr_bytes);
}
cur-bsr_num = bsr_types[cur-bsr_type];
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Make eSDHC 1-bit only transfer mode default for MPC8569E-MDS
On Jun 18, 2009, at 6:37 PM, Anton Vorontsov wrote: For yet unknown reason 4-bit mode doesn't work on MPC8569E-MDS boards, so make 1-bit mode default. When we resolve the issue, u-boot will remove sdhci,1-bit-only property from the device tree, while SDHCI will still work with older u-boots. Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/boot/dts/mpc8569mds.dts |1 + 1 files changed, 1 insertions(+), 0 deletions(-) Did I miss the patch that adds this property defn. to our docs? - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] RFC: powerpc: expose the multi-bit ops that underlie single-bit ops.
Benjamin Herrenschmidt wrote: On Thu, 2009-06-18 at 16:30 -0400, Geoff Thorpe wrote: I've left the volatile qualifier in the generated API because I didn't feel so comfortable changing APIs, but I also added the memory clobber for all cases - whereas it seems the existing set_bits(), clear_bits(), [...] functions didn't declare this... Do you see any issue with having the 'volatile' in the prototype as well as the clobber in the asm? Actually, might as well just respond to the new patch instead... :-) Thx. I think the story with the memory clobber is that it depends whether we consider the functions as ordering accesses or not (ie, can potentially be used with lock/unlock semantics). The general rule is that those who don't return anything don't need to have those semantics, and thus could only be advertised as clobbering p[word] -but- there are issues there. For example, despite the (relatively new) official _lock/_unlock variants, there's still code that abuses constructs like test_and_set_bit/clear_bit as locks and in that case, clear bits needs a clobber. So I would say at this stage better safe than having to track down incredibly hard to find bugs, and let's make them all take that clobber. Well I'm tempted agree because I'm abusing these constructs in exactly the manner you describe. :-) However I didn't know that this was abuse until you mentioned it. Some time ago I noticed that the bitops code was very similar to spinlocks, and so I presumed that a bitops word could act as its own spinlock (ie. rather than spinlocking access to a u32). Now that I look at spinlocks again, I see the presence of those CLEAR_IO_SYNC definitions in the function preambles - is that the distinction I'm abusing? CLEAR_IO_SYNC appears to be undefined except on 64-bit, in which case it's (get_paca()-io_sync = 0). W.r.t the _lock/_unlock variants on the bitops side, the lock particulars appear to depend on LWSYNC_ON_SMP and ISYNC_ON_SMP, which are isync and lwsync for all platforms IIUC. So it seems the locking intentions here are different from that of spinlocks? Is there something I can look at that describes what semantics these primitives (are supposed to) guarantee? I may be assuming other things that I shouldn't be ... Cheers, Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/85xx: Stop using ppc_md.init on socrates
Match what other 85xx platforms do for of_platform_bus_probe and use
machine_device_initcall. This is one small step in killing of
ppc_md.init.
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
arch/powerpc/platforms/85xx/socrates.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/socrates.c
b/arch/powerpc/platforms/85xx/socrates.c
index d0e8443..747d8fb 100644
--- a/arch/powerpc/platforms/85xx/socrates.c
+++ b/arch/powerpc/platforms/85xx/socrates.c
@@ -102,10 +102,11 @@ static struct of_device_id __initdata
socrates_of_bus_ids[] = {
{},
};
-static void __init socrates_init(void)
+static int __init socrates_publish_devices(void)
{
- of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
+ return of_platform_bus_probe(NULL, socrates_of_bus_ids, NULL);
}
+machine_device_initcall(socrates, socrates_publish_devices);
/*
* Called very early, device-tree isn't unflattened
@@ -124,7 +125,6 @@ define_machine(socrates) {
.name = Socrates,
.probe = socrates_probe,
.setup_arch = socrates_setup_arch,
- .init = socrates_init,
.init_IRQ = socrates_pic_init,
.get_irq= mpic_get_irq,
.restart= fsl_rstcr_restart,
--
1.6.0.6
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: Problem with memcpy on ppc8536
I believe the question should be sent to u-b...@lists.denx.de, not linuxppc-dev list. What is the TLB settings for NAND FCM buffer? Pay attention to set the TLB as cache inhibited and guarded attribute. If not set the guarded bit, it is possible to cause the speculate load from FCM buffer below the cmplwi and blt inst. IIRC, the FCM buffer only has the 4KB. So if it has one speculated Load above the 4KB, it will run into problem. The 0x700 is not alignment exception, it is program exception. If you can dump the exception error information from console to us, maybe we can give better help. Thanks, Dave From: linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org [mailto:linuxppc-dev-bounces+daveliu=freescale@lists.ozlabs.org] On Behalf Of Fahd Abidi Sent: Friday, June 19, 2009 4:34 AM To: linuxppc-...@ozlabs.org Subject: Problem with memcpy on ppc8536 Hello, I am trying to debug a crash during memcpy while copying data from the FCM buffer of an mpc8536 to the ddr ram. I debugged memcpy enough through my BDI3000 to see that the entire contents of the fcm buffer I want moved are actually moved off to memory location I specify. The crash comes after it memcpy finishes copying and performs the instruction 2: cmplwi 0,r5,4: memcpy: rlwinm. r7,r5,32-3,3,31 /* r0 = r5 3 */ addi r6,r3,-4 addi r4,r4,-4 beq 2f /* if less than 8 bytes to do */ andi. r0,r6,3 /* get dest word aligned */ mtctr r7 bne 5f 1: lwz r7,4(r4) lwzu r8,8(r4) stw r7,4(r6) stwu r8,8(r6) bdnz 1b andi. r5,r5,7 2: cmplwi 0,r5,4 contents of r5 are 0x0 showing that the entire 0x1000 size transfer I specified correctly finished. At this point I can check the memory contents through my BDI and verify all the data is in the ddr as I expect. Now the strange thing happens, if I execute the cmplwi 0,r5,4 the program takes an exception and eventually gets struck at exception vector 0x700 which I saw from start.S is an Alignment exception. I am not sure what this exception means, can someone help me understand what is happening? Does this exception somehow mean that memcpy did not move all the data? Does memcpy expect contents of r5 to be 4 and not 0 when it hits the cmplwi instruction? Fahd Abidi Product Manager - Technical Tools and Development Ultimate Solutions, Inc. Your Single Source for Professional Development Tools and Embedded Solutions Ph: 978-455-3383 x255 Fx: 978-926-3091 Email: fab...@ultsol.com Visit: http://www.ultsol.com http://www.ultsol.com/ ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
On Thu, Jun 18, 2009 at 11:26:23PM +0530, K.Prasad wrote: On Wed, Jun 17, 2009 at 02:14:20PM +1000, David Gibson wrote: On Wed, Jun 10, 2009 at 02:38:18PM +0530, K.Prasad wrote: [snip] @@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig 11, SIGSEGV) == NOTIFY_STOP) return; +#ifndef CONFIG_PPC64 if (debugger_dabr_match(regs)) return; +#endif Won't this disable the check for breakpoints set by xmon - but I don't see anything in this patch series to convert xmon to use the new breakpoint interface instead. As noted by me here: http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-May/071832.html the Xmon integration is pending. When I tried to study and integrate Xmon, I found that the HW Breakpoint triggering was broken as of 2.6.29 kernel (tested on a Power5 box). This would mean that if Xmon's hardware breakpoint infrastructure is used in tandem with the given breakpoint interfaces, they would conflict with each other resulting in difficult-to-predict behaviour (the last to grab the register will use it). I think that tidying up do_dabr() is best done along with Xmon integration. Hmm, ok. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
On Thu, Jun 18, 2009 at 11:50:45PM +0530, K.Prasad wrote:
On Wed, Jun 17, 2009 at 02:32:24PM +1000, David Gibson wrote:
On Wed, Jun 10, 2009 at 02:38:06PM +0530, K.Prasad wrote:
[snip]
+int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk)
+{
+ int is_kernel, ret = -EINVAL;
+
+ if (!bp)
+ return ret;
+
+ switch (bp-info.type) {
+ case HW_BREAKPOINT_READ:
+ case HW_BREAKPOINT_WRITE:
+ case HW_BREAKPOINT_RW:
+ break;
+ default:
+ return ret;
+ }
+
+ if (bp-triggered)
+ ret = arch_store_info(bp, tsk);
Under what circumstances would triggered be NULL? It's not clear to
me that you wouldn't still need arch_store_info() in this case.
Simple, triggered would be NULL when a user fails to specify it!
This function would return EINVAL if that's the case.
Ah, right, yes. This seems a really non obvious control flow for a
NULL triggered value to lead to EINVAL. I'd prefer:
if (!bp-triggered)
return -EINVAL
/* Then the kernel address test */
return arch_store_info(bp, tsk);
[snip]
+ /* Verify if dar lies within the address range occupied by the symbol
+ * being watched. Since we cannot get the symbol size for
+ * user-space requests we skip this check in that case
+ */
+ if ((hbp_kernel_pos == 0)
+ !((bp-info.address = dar)
+ (dar = (bp-info.address + bp-info.symbolsize
+ /*
+ * This exception is triggered not because of a memory access on
+ * the monitored variable but in the double-word address range
+ * in which it is contained. We will consume this exception,
+ * considering it as 'noise'.
+ */
+ goto out;
+
+ (bp-triggered)(bp, regs);
So this confuses me. You go to great efforts to step over the
instruction to generate a SIGTRAP after the instruction, for
consistency with x86. But that SIGTRAP is *never* used, since the
only way to set userspace breakpoints is through ptrace at the moment.
At the same time, the triggered function is called here before the
instruction is executed, so not consistent with x86 anyway.
It just seems strange to me that sending a SIGTRAP is a special case
anyway. Why can't sending a SIGTRAP be just a particular triggered
function.
The consistency in the interface across architectures that I referred to
in my previous mail was w.r.t. continuous triggering of breakpoints and
not to implement a trigger-before or trigger-after behaviour across
architectures. In fact, this behaviour differs even on the same
processor depending upon the breakpoint type (trigger-before for
instructions and trigger-after for data in x86), and introducing
uniformity might be a) at the cost of loss of some unique innovative
uses for each of them b) may not be always possible e.g. trigger-after
to trigger-before.
Hrm. Well (a) is why I was suggesting an option to allow trigger
before on powerpc. Plus, I don't see why you think (a) is important
for the triggered function, but not for the timing of a SIGTRAP to
userspace.
As for (b), well there are already a bunch of things which can only be
done on certain archs/processors, so I don't see that's anything
really new.
How do you handle continuous breakpoints in the trigger-before case
(instruction breakpoints) on x86? Do you need to step over an
instruction is the same manner as you do for powerpc? In this case
where does x86 send the SIGTRAP?
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Map more memory early on 601 processors
The 32-bit kernel relies on some memory being mapped covering the kernel text,data and bss at least, early during boot before the full MMU setup is done. On 32-bit classic processors, this is done using BAT registers. On 601, the size of BATs is limited to 8M and we use 2 of them for that initial mapping. This can become quite tight when enabling features like lockdep, so let's use a 3rd one to bump that mapping from 16M to 24M. We keep the 4th BAT free as it can be useful for debugging early boot code to map things like serial ports. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- arch/powerpc/kernel/head_32.S | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) --- linux-work.orig/arch/powerpc/kernel/head_32.S 2009-06-19 10:31:41.0 +1000 +++ linux-work/arch/powerpc/kernel/head_32.S2009-06-19 10:32:13.0 +1000 @@ -1124,9 +1124,8 @@ mmu_off: RFI /* - * Use the first pair of BAT registers to map the 1st 16MB - * of RAM to PAGE_OFFSET. From this point on we can't safely - * call OF any more. + * On 601, we use 3 BATs to map up to 24M of RAM at _PAGE_OFFSET + * (we keep one for debugging) and on others, we use one 256M BAT. */ initial_bats: lis r11,page_off...@h @@ -1136,12 +1135,16 @@ initial_bats: bne 4f ori r11,r11,4 /* set up BAT registers for 601 */ li r8,0x7f /* valid, block length = 8MB */ - orisr9,r11,0x800...@h /* set up BAT reg for 2nd 8M */ - orisr10,r8,0x800...@h /* set up BAT reg for 2nd 8M */ mtspr SPRN_IBAT0U,r11 /* N.B. 601 has valid bit in */ mtspr SPRN_IBAT0L,r8 /* lower BAT register */ - mtspr SPRN_IBAT1U,r9 - mtspr SPRN_IBAT1L,r10 + addis r11,r11,0x800...@h + addis r8,r8,0x800...@h + mtspr SPRN_IBAT1U,r11 + mtspr SPRN_IBAT1L,r8 + addis r11,r11,0x800...@h + addis r8,r8,0x800...@h + mtspr SPRN_IBAT2U,r11 + mtspr SPRN_IBAT2L,r8 isync blr ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/pmac: Fix DMA ops for MacIO devices
The macio_dev's created to map devices inside the MacIO ASICs don't have proper dma_ops. This causes crashes on some machines since the SCSI code calls dma_map_* on our behalf using the device we hang from. This fixes it by copying the parent PCI device dma_ops into the macio_dev when creating it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/macintosh/macio_asic.c | 11 +++ 1 file changed, 11 insertions(+) --- linux-work.orig/drivers/macintosh/macio_asic.c 2009-06-19 10:38:17.0 +1000 +++ linux-work/drivers/macintosh/macio_asic.c 2009-06-19 10:38:33.0 +1000 @@ -378,6 +378,17 @@ static struct macio_dev * macio_add_one_ dev-ofdev.dev.bus = macio_bus_type; dev-ofdev.dev.release = macio_release_dev; +#ifdef CONFIG_PCI + /* Set the DMA ops to the ones from the PCI device, this could be +* fishy if we didn't know that on PowerMac it's always direct ops +* or iommu ops that will work fine +*/ + dev-ofdev.dev.archdata.dma_ops = + chip-lbus.pdev-dev.archdata.dma_ops; + dev-ofdev.dev.archdata.dma_data = + chip-lbus.pdev-dev.archdata.dma_data; +#endif /* CONFIG_PCI */ + #ifdef DEBUG printk(preparing mdev @%p, ofdev @%p, dev @%p, kobj @%p\n, dev, dev-ofdev, dev-ofdev.dev, dev-ofdev.dev.kobj); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mm: Make k(un)map_atomic out of line
On Thu, 2009-06-18 at 13:39 +1000, Benjamin Herrenschmidt wrote:
Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Missing a quilt ref ... this one won't build.
Ben.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/highmem.h | 55 +--
arch/powerpc/mm/Makefile |1
arch/powerpc/mm/highmem.c | 75
+
3 files changed, 80 insertions(+), 51 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/highmem.h2009-06-18
11:34:42.0 +1000
+++ linux-work/arch/powerpc/include/asm/highmem.h 2009-06-18
11:34:45.0 +1000
@@ -62,6 +62,9 @@ extern pte_t *pkmap_page_table;
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
+extern void *kmap_atomic_prot(struct page *page, enum km_type type,
+ pgprot_t prot);
+extern void kunmap_atomic(void *kvaddr, enum km_type type);
static inline void *kmap(struct page *page)
{
@@ -79,62 +82,11 @@ static inline void kunmap(struct page *p
kunmap_high(page);
}
-/*
- * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
- * gives a more generic (and caching) interface. But kmap_atomic can
- * be used in IRQ contexts, so in some (very limited) cases we need
- * it.
- */
-static inline void *kmap_atomic_prot(struct page *page, enum km_type type,
pgprot_t prot)
-{
- unsigned int idx;
- unsigned long vaddr;
-
- /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
- debug_kmap_atomic(type);
- idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
-#ifdef CONFIG_DEBUG_HIGHMEM
- BUG_ON(!pte_none(*(kmap_pte-idx)));
-#endif
- __set_pte_at(init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
- local_flush_tlb_page(NULL, vaddr);
-
- return (void*) vaddr;
-}
-
static inline void *kmap_atomic(struct page *page, enum km_type type)
{
return kmap_atomic_prot(page, type, kmap_prot);
}
-static inline void kunmap_atomic(void *kvaddr, enum km_type type)
-{
-#ifdef CONFIG_DEBUG_HIGHMEM
- unsigned long vaddr = (unsigned long) kvaddr PAGE_MASK;
- enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
-
- if (vaddr __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- return;
- }
-
- BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
-
- /*
- * force other mappings to Oops if they'll try to access
- * this pte without first remap it
- */
- pte_clear(init_mm, vaddr, kmap_pte-idx);
- local_flush_tlb_page(NULL, vaddr);
-#endif
- pagefault_enable();
-}
-
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
@@ -148,6 +100,7 @@ static inline struct page *kmap_atomic_t
return pte_page(*pte);
}
+
#define flush_cache_kmaps() flush_cache_all()
#endif /* __KERNEL__ */
Index: linux-work/arch/powerpc/mm/Makefile
===
--- linux-work.orig/arch/powerpc/mm/Makefile 2009-06-18 11:34:42.0
+1000
+++ linux-work/arch/powerpc/mm/Makefile 2009-06-18 11:34:45.0
+1000
@@ -30,3 +30,4 @@ obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
+obj-$(CONFIG_HIGHMEM)+= highmem.o
Index: linux-work/arch/powerpc/mm/highmem.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/mm/highmem.c 2009-06-18 11:35:51.0
+1000
@@ -0,0 +1,75 @@
+/*
+ * highmem.c: virtual kernel memory mappings for high memory
+ *
+ * PowerPC version, stolen from the i386 version.
+ *
+ * Used in CONFIG_HIGHMEM systems for memory pages which
+ * are not addressable by direct kernel virtual addresses.
+ *
+ * Copyright (C) 1999 Gerhard Wichert, Siemens AG
+ * gerhard.wich...@pdb.siemens.de
+ *
+ *
+ * Redesigned the x86 32-bit VM architecture to deal with
+ * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * we now support up to 64 Gigabytes physical RAM.
+ *
+ * Copyright (C) 1999 Ingo Molnar mi...@redhat.com
+ *
+ * Reworked for PowerPC by various contributors. Moved from
+ * highmem.h by Benjamin Herrenschmidt (c) 2009 IBM Corp.
+ */
+
+
+/*
+ * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
+ * gives a
[PATCH] powerpc/mm: Make k(un)map_atomic out of line
Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/highmem.h | 57 +--
arch/powerpc/mm/Makefile |1
arch/powerpc/mm/highmem.c | 77 +
3 files changed, 82 insertions(+), 53 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/highmem.h 2009-06-18
11:34:42.0 +1000
+++ linux-work/arch/powerpc/include/asm/highmem.h 2009-06-18
11:38:06.0 +1000
@@ -22,9 +22,7 @@
#ifdef __KERNEL__
-#include linux/init.h
#include linux/interrupt.h
-#include linux/highmem.h
#include asm/kmap_types.h
#include asm/tlbflush.h
#include asm/page.h
@@ -62,6 +60,9 @@ extern pte_t *pkmap_page_table;
extern void *kmap_high(struct page *page);
extern void kunmap_high(struct page *page);
+extern void *kmap_atomic_prot(struct page *page, enum km_type type,
+ pgprot_t prot);
+extern void kunmap_atomic(void *kvaddr, enum km_type type);
static inline void *kmap(struct page *page)
{
@@ -79,62 +80,11 @@ static inline void kunmap(struct page *p
kunmap_high(page);
}
-/*
- * The use of kmap_atomic/kunmap_atomic is discouraged - kmap/kunmap
- * gives a more generic (and caching) interface. But kmap_atomic can
- * be used in IRQ contexts, so in some (very limited) cases we need
- * it.
- */
-static inline void *kmap_atomic_prot(struct page *page, enum km_type type,
pgprot_t prot)
-{
- unsigned int idx;
- unsigned long vaddr;
-
- /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
- pagefault_disable();
- if (!PageHighMem(page))
- return page_address(page);
-
- debug_kmap_atomic(type);
- idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
-#ifdef CONFIG_DEBUG_HIGHMEM
- BUG_ON(!pte_none(*(kmap_pte-idx)));
-#endif
- __set_pte_at(init_mm, vaddr, kmap_pte-idx, mk_pte(page, prot), 1);
- local_flush_tlb_page(NULL, vaddr);
-
- return (void*) vaddr;
-}
-
static inline void *kmap_atomic(struct page *page, enum km_type type)
{
return kmap_atomic_prot(page, type, kmap_prot);
}
-static inline void kunmap_atomic(void *kvaddr, enum km_type type)
-{
-#ifdef CONFIG_DEBUG_HIGHMEM
- unsigned long vaddr = (unsigned long) kvaddr PAGE_MASK;
- enum fixed_addresses idx = type + KM_TYPE_NR*smp_processor_id();
-
- if (vaddr __fix_to_virt(FIX_KMAP_END)) {
- pagefault_enable();
- return;
- }
-
- BUG_ON(vaddr != __fix_to_virt(FIX_KMAP_BEGIN + idx));
-
- /*
-* force other mappings to Oops if they'll try to access
-* this pte without first remap it
-*/
- pte_clear(init_mm, vaddr, kmap_pte-idx);
- local_flush_tlb_page(NULL, vaddr);
-#endif
- pagefault_enable();
-}
-
static inline struct page *kmap_atomic_to_page(void *ptr)
{
unsigned long idx, vaddr = (unsigned long) ptr;
@@ -148,6 +98,7 @@ static inline struct page *kmap_atomic_t
return pte_page(*pte);
}
+
#define flush_cache_kmaps()flush_cache_all()
#endif /* __KERNEL__ */
Index: linux-work/arch/powerpc/mm/Makefile
===
--- linux-work.orig/arch/powerpc/mm/Makefile2009-06-18 11:34:42.0
+1000
+++ linux-work/arch/powerpc/mm/Makefile 2009-06-18 11:34:45.0 +1000
@@ -30,3 +30,4 @@ obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
obj-$(CONFIG_PPC_SUBPAGE_PROT) += subpage-prot.o
obj-$(CONFIG_NOT_COHERENT_CACHE) += dma-noncoherent.o
+obj-$(CONFIG_HIGHMEM) += highmem.o
Index: linux-work/arch/powerpc/mm/highmem.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/mm/highmem.c2009-06-18 11:38:33.0
+1000
@@ -0,0 +1,77 @@
+/*
+ * highmem.c: virtual kernel memory mappings for high memory
+ *
+ * PowerPC version, stolen from the i386 version.
+ *
+ * Used in CONFIG_HIGHMEM systems for memory pages which
+ * are not addressable by direct kernel virtual addresses.
+ *
+ * Copyright (C) 1999 Gerhard Wichert, Siemens AG
+ * gerhard.wich...@pdb.siemens.de
+ *
+ *
+ * Redesigned the x86 32-bit VM architecture to deal with
+ * up to 16 Terrabyte physical memory. With current x86 CPUs
+ * we now support up to 64 Gigabytes physical RAM.
+ *
+ * Copyright (C) 1999 Ingo Molnar mi...@redhat.com
+ *
+ * Reworked for PowerPC by various contributors. Moved from
+ * highmem.h by Benjamin Herrenschmidt (c) 2009 IBM Corp.
+ */
+
+#include linux/highmem.h
+#include linux/module.h
+
+/*
+ * The use of kmap_atomic/kunmap_atomic is
[git pull] Please pull powerpc.git merge branch
Hi Linus ! Here's another batch to finally drain my queue. There will be bug fixes coming but they don't need to be before -rc1. The only feature I'm still considering merging this time around and that isn't there yet is the support for irqtrace/lockdep on ppc32 since it's a useful debug tool, and mostly should be a nop unless lockdep is enabled. The following changes since commit 0732f87761dbe417cb6e084b712d07e879e876ef: Linus Torvalds (1): Merge branch 'for_linus' of git://git.kernel.org/.../tytso/ext4 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge Anton Vorontsov (2): powerpc/83xx: Update sdhci nodes per new bindings powerpc/5200: convert mpc52xx_psc_spi to use cs_control callback Becky Bruce (1): powerpc: Add 86xx support for SWIOTLB Benjamin Herrenschmidt (5): powerpc: Fix invalid construct in our CPU selection Kconfig powerpc: Add memory clobber to mtspr() Merge commit 'origin/master' into next Merge commit 'origin/master' into next Merge commit 'gcl/merge' into next Dave Liu (1): serial: Make ucc_uart work in HW UART mode Dave Mitchell (1): of_serial: Add UPF_FIXED_TYPE flag Geert Uytterhoeven (3): net/ps3: gelic - Add missing annotations ps3rom: Use ps3_system_bus_[gs]et_drvdata() instead of direct access usb/ps3: Add missing annotations Gerhard Pircher (1): powerpc: Enable additional BAT registers in setup_745x_specifics() Grant Likely (1): fbdev/xilinxfb: Fix improper casting and tighen up probe path Haiying Wang (1): powerpc/85xx: Add UCC6 and UCC8 nodes in SGMII mode for MPC8569MDS Heiko Schocher (1): 83xx: add support for the kmeter1 board. Kevin Hao (1): powerpc/85xx: Add nor flash partitions for mpc8569mds Kumar Gala (1): powerpc/85xx: Add SWIOTLB support to FSL boards Martyn Welch (1): powerpc/86xx: Add I2C device mappings in DTS for SBC610 Michael Ellerman (1): powerpc: Add configurable -Werror for arch/powerpc Mike Frysinger (1): drivers/hvc: Add missing __devexit_p() Nate Case (6): powerpc/fsl-booke: Enable L1 cache on e500v1/e500v2/e500mc CPUs powerpc/85xx: cuboot - Fix up ethernet3 MAC address on MPC85xx powerpc/85xx: Add platform support for X-ES MPC85xx boards powerpc/85xx: Add dts files for X-ES MPC85xx boards powerpc/85xx: Add defconfig for X-ES MPC85xx boards powerpc/bootwrapper: Custom build options for XPedite52xx targets Peter Korsgaard (1): powerpc/mpc83xx: Fix usb mux setup for mpc834x Sean MacLennan (1): powerpc/warp: Fix ISA_DMA_THRESHOLD default Timur Tabi (1): powerpc: Introduce macro spin_event_timeout() Wolfgang Denk (2): powerpc/mpc8272ads: fix device tree for 8 MB flash size powerpc/5xxx: Add common mpc5xxx_get_bus_frequency() function Wolfram Sang (2): powerpc/5200: Update pcm030.dts to add i2c eeprom and delete cruft powerpc/5121: make clock debug output more readable Yang Li (1): rio: warn_unused_result warnings fix leon.woestenb...@gmail.com (1): powerpc/83xx: Add MSI interrupts to DTS of MPC8315E-RDB mw...@internode.on.net (1): powerpc/fsl: Increase the number of possible localbus banks arch/powerpc/Kconfig.debug| 17 + arch/powerpc/boot/cuboot-85xx.c |2 + arch/powerpc/boot/dts/asp834x-redboot.dts |2 +- arch/powerpc/boot/dts/gef_sbc610.dts | 10 + arch/powerpc/boot/dts/kmeter1.dts | 520 ++ arch/powerpc/boot/dts/mpc8272ads.dts | 19 +- arch/powerpc/boot/dts/mpc8315erdb.dts | 15 + arch/powerpc/boot/dts/mpc8349emitx.dts|2 +- arch/powerpc/boot/dts/mpc834x_mds.dts |2 +- arch/powerpc/boot/dts/mpc8377_mds.dts |2 +- arch/powerpc/boot/dts/mpc8377_rdb.dts |2 +- arch/powerpc/boot/dts/mpc8378_mds.dts |2 +- arch/powerpc/boot/dts/mpc8378_rdb.dts |2 +- arch/powerpc/boot/dts/mpc8379_mds.dts |2 +- arch/powerpc/boot/dts/mpc8379_rdb.dts |2 +- arch/powerpc/boot/dts/mpc8569mds.dts | 87 +- arch/powerpc/boot/dts/pcm030.dts | 26 +- arch/powerpc/boot/dts/sbc8349.dts |2 +- arch/powerpc/boot/dts/xcalibur1501.dts| 696 arch/powerpc/boot/dts/xpedite5200.dts | 466 ++ arch/powerpc/boot/dts/xpedite5200_xmon.dts| 506 ++ arch/powerpc/boot/dts/xpedite5301.dts | 640 arch/powerpc/boot/dts/xpedite5330.dts | 707 arch/powerpc/boot/dts/xpedite5370.dts | 638 arch/powerpc/boot/wrapper |4 + arch/powerpc/configs/83xx/kmeter1_defconfig | 908 ++ arch/powerpc/configs/85xx/xes_mpc85xx_defconfig | 1821
Re: [PATCH] powerpc/85xx: Fix FSL RapidIO probing on MDS boards
On Jun 18, 2009, at 6:22 PM, Anton Vorontsov wrote: From: Randy Vinson rvin...@mvista.com FSL RapidIO won't probe without a proper compatible entry. This patch fixes the issue by adding fsl,rapidio-delta compatible to mpc85xx_ids. Signed-off-by: Randy Vinson rvin...@mvista.com Signed-off-by: Anton Vorontsov avoront...@ru.mvista.com --- arch/powerpc/platforms/85xx/mpc85xx_mds.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
