Re: [PATCH #upstream-fixes] pata_mpc52xx: inherit from ata_bmdma_port_ops

2011-01-09 Thread Roman Fietze
Hello Tejun,

On Sunday, 09.January.2011 23:48:20 Tejun Heo wrote:

 Fix it.

I can confirm that, it's fixed.

Thank's a lot. Should have looked into it, that was really a simple
fix.


Roman

-- 
Roman Fietze  Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


PowerPC MPC5200B ATA MWDMA regression

2011-01-03 Thread Roman Fietze
: status: { DRDY }
[1.981416] ata1.00: configured for MWDMA2
[1.985755] ata1: EH complete
[1.989027] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[1.995707] ata1.00: failed command: READ DMA
[2.000262] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 
in
[2.000275]  res 50/00:00:7f:29:54/00:00:00:00:00/a0 Emask 0x40 
(internal error)
[2.015971] ata1.00: status: { DRDY }
[2.041420] ata1.00: configured for MWDMA2
[2.045767] ata1: EH complete
[2.049044] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[2.055730] ata1.00: failed command: READ DMA
[2.060287] ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 
in
[2.060301]  res 50/00:00:7f:29:54/00:00:00:00:00/a0 Emask 0x40 
(internal error)
[2.075997] ata1.00: status: { DRDY }
...

and then while operating the drive e.g. using dd if=/dev/sda ...:

[   81.936231] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   81.942966] ata1.00: failed command: READ DMA
[   81.947534] ata1.00: cmd c8/00:00:00:00:00/00:00:00:00:00/e0 tag 0 dma 
131072 in
[   81.947550]  res 50/00:00:7f:29:54/00:00:00:00:00/a0 Emask 0x40 
(internal error)
[   81.963422] ata1.00: status: { DRDY }
[   81.983316] ata1.00: configured for MWDMA2
[   81.987690] ata1: EH complete
[   81.990974] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   81.997661] ata1.00: failed command: READ DMA
[   82.002219] ata1.00: cmd c8/00:00:00:00:00/00:00:00:00:00/e0 tag 0 dma 
131072 in
[   82.002234]  res 50/00:00:7f:29:54/00:00:00:00:00/a0 Emask 0x40 
(internal error)
[   82.018186] ata1.00: status: { DRDY }
[   82.047323] ata1.00: configured for MWDMA2
[   82.051695] ata1: EH complete
...

and so on.

If I would understand more of IDE/ATA/libata I would have tried own
fixes, so I'm sorry to bother you with test results instead of
patches.


Roman

-- 
Roman Fietze  Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: PowerPC MPC5200B ATA MWDMA regression

2011-01-03 Thread Roman Fietze
Hallo Tejun,

On Monday, 03.January.2011 14:59:29 Tejun Heo wrote:

 Which driver is it?

drivers/ata/pata_mpc52xx.c from the standard tree, 100% unchanged. As
I said, for the bisect I was using the original, unchanged
torvalds/master tree from git.kernel.org.

 You probably now want to use ata_bmdma_qc_issue() ...

I'm sorry, but if I would know about the details, and would know more
about ATA I would have tried to patch pata_mpc52xx.c by myself.

  Even better, just send the driver upstream.

It has been there for a long while. You even patched it last summer.


Roman

-- 
Roman Fietze  Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/mpc5200: MPC5200 ATA driver requires BMDMA to be configured

2010-10-25 Thread Roman Fietze
Hello List Members,

I updated to v2.6.34 from torvalds/master.

While playing around with ATA settings (I have problems with MWDMA2 on
a Lite5200B compatible board, the problems are not related to this
patch here), I also turned off BMDMA, which caused compile errors on
pata_mpc52xx. So my question is, is the patch below correct? Should we
only offer the pata_mpc52xx if BMDMA is configured?


Subject: [PATCH] powerpc/mpc5200: MPC5200 ATA driver requires BMDMA to be 
configured

The driver uses e.g. bmdma_setup which is only available with
ATA_BMDMA beeing configured.

Move the configuration of the driver pata_mpc52xx down in Kconfig to
the section PATA SFF controllers with BMDMA.

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 drivers/ata/Kconfig |   20 ++--
 1 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 11ec911..85756b8 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -128,16 +128,6 @@ config PDC_ADMA
 
  If unsure, say N.
 
-config PATA_MPC52xx
-   tristate Freescale MPC52xx SoC internal IDE
-   depends on PPC_MPC52xx  PPC_BESTCOMM
-   select PPC_BESTCOMM_ATA
-   help
- This option enables support for integrated IDE controller
- of the Freescale MPC52xx SoC.
-
- If unsure, say N.
-
 config PATA_OCTEON_CF
tristate OCTEON Boot Bus Compact Flash support
depends on CPU_CAVIUM_OCTEON
@@ -491,6 +481,16 @@ config PATA_MARVELL
 
  If unsure, say N.
 
+config PATA_MPC52xx
+   tristate Freescale MPC52xx SoC internal IDE
+   depends on PPC_MPC52xx  PPC_BESTCOMM
+   select PPC_BESTCOMM_ATA
+   help
+ This option enables support for integrated IDE controller
+ of the Freescale MPC52xx SoC.
+
+ If unsure, say N.
+
 config PATA_NETCELL
tristate NETCELL Revolution RAID support
depends on PCI
-- 
1.7.3.1



Roman

-- 
Roman Fietze  Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


MPC5200B MWDMA2 with recent 2.6.36 kernels

2010-10-25 Thread Roman Fietze
Hello,

I recently tried to switch to 2.6.36 (torvalds/master) using a
Lite5200B compatible board.

Using 2.6.34 we were running ATA in MWDMA 2 to avoid MPC5200B HW
problems with UDMA.

But with 2.6.36 I get only ATA errors (PIO4 is working fine):

...
ata: MPC52xx IDE/ATA libata driver
scsi0 : mpc52xx_ata
ata1: PATA max MWDMA2 ata_regs 0xf0003a00 irq 135
...
ata1.00: ATA-6: Hitachi HEJ421010G9AT00, F5DJA40B, max UDMA/100
ata1.00: 195371568 sectors, multi 0: LBA48 
ata1.00: configured for MWDMA2
scsi 0:0:0:0: Direct-Access ATA  Hitachi HEJ42101 F5DJ PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 195371568 512-byte logical blocks: (100 GB/93.1 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO749060] [ cut here ]
WARNING: at /home/fietze/src/linux-2.6-telemotive/drivers/ata/libata-sff.c:1468
Modules linked in:
NIP: c01b1680 LR: c01b1654 CTR: c01b06d0
REGS: c7843ad0 TRAP: 0700   Not tainted  (2.6.36.00.02-obelix)
MSR: 00021032 ME,CE,IR,DR  CR: 24008084  XER: 
TASK = c7829b20[8] 'kworker/u:1' THREAD: c7842000
GPR00: 0001 c7843b80 c7829b20 0050 c9088a78 0001   
GPR08:  c03432d8 0003  44008082 1001a7f0 c02adb28 c0269df8 
GPR16: c02adb20 c02adbc4 c02adbec c6f2bc60 c6f48000 c02647a0 c74081a0 c000f060 
GPR24: c780baa0 0002 c6f21430 c6f21430 0003  c6f2 c6f200a4 
NIP [c01b1680] ata_sff_qc_issue+0x78/0x24c
LR [c01b1654] ata_sff_qc_issue+0x4c/0x24c
Call Trace:
[c7843b80] [c01b1654] ata_sff_qc_issue+0x4c/0x24c (unreliable)
[c7843ba0] [c01a087c] ata_qc_issue+0x208/0x330
[c7843bd0] [c01a5ca4] ata_scsi_translate+0x104/0x1b0
[c7843bf0] [c018d208] scsi_dispatch_cmd+0xf4/0x208
[c7843c10] [c0193b64] scsi_request_fn+0x270/0x404
[c7843c40] [c01405b0] __generic_unplug_device+0x48/0x5c
[c7843c50] [c0140ee4] generic_unplug_device+0x28/0x44
[c7843c60] [c013e480] blk_unplug+0x20/0x30
[c7843c70] [c00b14b4] block_sync_page+0x54/0x70
[c7843c80] [c005b37c] sync_page+0x50/0x74
[c7843c90] [c0259b50] __wait_on_bit_lock+0x94/0x124
[c7843cb0] [c005b2f8] __lock_page+0x50/0x60
[c7843ce0] [c005baac] do_read_cache_page+0x18c/0x190
[c7843d10] [c005bb08] read_cache_page+0x14/0x28
[c7843d20] [c00d7ca8] read_dev_sector+0x40/0xb0
[c7843d40] [c00d8c24] msdos_partition+0xb4/0x98c
[c7843e20] [c00d885c] rescan_partitions+0x1c0/0x4bc
[c7843e80] [c00b960c] __blkdev_get+0x1a0/0x368
[c7843ec0] [c00d85ec] register_disk+0x17c/0x194
[c7843ef0] [c0147e04] add_disk+0xf4/0x144
[c7843f20] [c019b658] sd_probe_async+0xf4/0x1bc
[c7843f40] [c004339c] async_run_entry_fn+0x84/0x1cc
[c7843f60] [c0035c1c] process_one_work+0x10c/0x330
[c7843f90] [c003730c] worker_thread+0x1ec/0x32c
[c7843fb0] [c003ba60] kthread+0x7c/0x80
[c7843ff0] [c000f5c4] kernel_thread+0x4c/0x68
Instruction dump:
4bfff65d 8b9f0014 2f9c0002 419e00e8 2b9c0002 419d0040 2f9c0001 419e0158 
3d20c034 392932d8 89690005 6961 0f00 2f8b 38600040 419e01bc 
---[ end trace 69c43b02b90e3750 ]---
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
 res 50/00:00:2f:22:a5/00:00:00:00:00/a0 Emask 0x40 (internal error)
ata1.00: status: { DRDY }
ata1.00: configured for MWDMA2
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: failed command: READ DMA
ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 dma 4096 in
 res 50/00:00:2f:22:a5/00:00:00:00:00/a0 Emask 0x40 (internal error)
ata1.00: status: { DRDY }
ata1.00: configured for MWDMA2
...
... and so on


Any ideas? Same behavious on some of your boxes? Too bad my current
know how when it comes to ATA is not too much above zero.


Roman

-- 
Roman Fietze  Telemotive AG Buero Muehlhausen
Breitwiesen 73347 Muehlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] mpc52xx_gpio: support MPC52xx simple interrupt GPIO

2010-07-07 Thread Roman Fietze
Hello Sascha, hello List Members,

I could not find a way to access the MPC5200(B) simple interrupt pins
using the 52xx platform GPIO driver. So I added the simple interrupt
pins when the mpc5200-gpio is probed. Is there something I overlooked?
If not, here's the patch.


From 749b58686384275d253eeca8f3f0bd7a12daebe2 Mon Sep 17 00:00:00 2001
From: Roman Fietze roman.fie...@telemotive.de
Date: Wed, 7 Jul 2010 13:21:12 +0200
Subject: [PATCH] mpc52xx_gpio: support MPC52xx simple interrupt GPIO

Add two OF GPIO chips when probing fsl,mpc5200-gpio, one for the 32
simple GPIO pins and one for the 8 simple interrupt GPIO pins.

The current order of driver registrations will cause the simple
interrupt GPIO pin numbers be below the ones of the simple GPIO pins,
so current code will not have to be changed, except if there are more
GPIO pins with dynamic pin numbers registered after the platform
driver.

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_gpio.c |  128 
+++-
 1 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
index fda7c2a..d0a9fce 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpio.c
@@ -308,7 +308,107 @@ mpc52xx_simple_gpio_dir_out(struct gpio_chip *gc, 
unsigned int gpio, int val)
return 0;
 }
 
-static int __devinit mpc52xx_simple_gpiochip_probe(struct of_device *ofdev,
+/*
+ * GPIO LIB API implementation for simple interrupt GPIOs
+ *
+ * There's a maximum of 8 simple interrupt GPIOs. Which of these are
+ * available for use depends on your board setup.  The numbering
+ * reflects the bit numbering in the port registers:
+ *
+ *  0.. 3  ETH_16..ETH_13
+ *  4  USB1_9
+ *  5  PSC3_8
+ *  6.. 7  PSC3_5..PSC3_4
+ */
+static int mpc52xx_sint_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
+   unsigned int ret;
+
+   ret = (in_8(regs-sint_ival)  (7 - gpio))  1;
+
+   return ret;
+}
+
+static inline void
+__mpc52xx_sint_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct mpc52xx_gpiochip *chip = container_of(mm_gc,
+struct mpc52xx_gpiochip, 
mmchip);
+   struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
+
+   if (val)
+   chip-shadow_dvo |= 1  (7 - gpio);
+   else
+   chip-shadow_dvo = ~(1  (7 - gpio));
+   out_8(regs-sint_dvo, chip-shadow_dvo);
+}
+
+static void
+mpc52xx_sint_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(gpio_lock, flags);
+
+   __mpc52xx_sint_gpio_set(gc, gpio, val);
+
+   spin_unlock_irqrestore(gpio_lock, flags);
+}
+
+static int mpc52xx_sint_gpio_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct mpc52xx_gpiochip *chip = container_of(mm_gc,
+struct mpc52xx_gpiochip, 
mmchip);
+   struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
+   unsigned long flags;
+
+   spin_lock_irqsave(gpio_lock, flags);
+
+   /* set the direction */
+   chip-shadow_ddr = ~(1  (7 - gpio));
+   out_8(regs-sint_ddr, chip-shadow_ddr);
+
+   /* and enable the pin */
+   chip-shadow_gpioe |= 1  (7 - gpio);
+   out_8(regs-sint_gpioe, chip-shadow_gpioe);
+
+   spin_unlock_irqrestore(gpio_lock, flags);
+
+   return 0;
+}
+
+static int
+mpc52xx_sint_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+   struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+   struct mpc52xx_gpiochip *chip = container_of(mm_gc,
+struct mpc52xx_gpiochip, 
mmchip);
+   struct mpc52xx_gpio __iomem *regs = mm_gc-regs;
+   unsigned long flags;
+
+   spin_lock_irqsave(gpio_lock, flags);
+
+   /* First set initial value */
+   __mpc52xx_sint_gpio_set(gc, gpio, val);
+
+   /* Then set direction */
+   chip-shadow_ddr |= 1  (7 - gpio);
+   out_8(regs-sint_ddr, chip-shadow_ddr);
+
+   /* Finally enable the pin */
+   chip-shadow_gpioe |= 1  (7 - gpio);
+   out_8(regs-sint_gpioe, chip-shadow_gpioe);
+
+   spin_unlock_irqrestore(gpio_lock, flags);
+
+   return 0;
+}
+
+static int __devinit mpc52xx_simple_sint_gpiochip_probe(struct of_device 
*ofdev,
const struct of_device_id *match)
 {
struct mpc52xx_gpiochip *chip;
@@ -316,6 +416,7 @@ static int __devinit mpc52xx_simple_gpiochip_probe(struct 
of_device *ofdev,
struct mpc52xx_gpio __iomem *regs;
int ret

CAN Subsystem and MPC52xx onboard controller

2010-06-10 Thread Roman Fietze
Hello List Members,

I have tried multiple versions/branches and git repos (torvalds,
benh/{next,master}, denx, pengutronix, ...) to get a 2.6.34 or HEAD
version of that repos that compiles w/o errors when the CAN subsystem
is enabled and the MPC5xxx onboard driver is selected starting with
the lite5200b_defconfig.

Until now I'm out of luck. If other's also have compile problems I can
of course offer to try to dig into the sources.

Q0:

I'm somewhat unsure what repos to use in general to develop using the
2.6 on a Lite5200B compatible board (for the 2.4 we always used the
DENX repos).

Q1:

And which one is good or better for CAN+MPC52xx if that's
different?


Thanks for any enlightenment


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: CAN Subsystem and MPC52xx onboard controller

2010-06-10 Thread Roman Fietze
Hello Wolfram,

On Thursday 10 June 2010 10:59:23 Wolfram Sang wrote:

 The mainline kernel works fine here with Phytec based MPC5xxx-boards.

Reading your answer made me hope again, and I just pulled the newest
HEAD from the mainline kernel and tried it once more. Now it compiles.
Thanks for retriggering me again.

All the other's sill have problems, except pengutronix, most of them
with an inconsistency (with the socket CAN files?), which shows up as

  'struct can_bittime_std' declared inside parameter list

in net/can/dev.c:69

So I assume we will switch to the mainline kernel, which we already
use for Atom based x86 development on the MEN boards.


Thanks once more

Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Xorg on Fujitsu Lime with MPC5200b?

2010-04-16 Thread Roman Fietze
Hello Bill,

On Thursday 15 April 2010 22:14:09 Bill Gatliff wrote:

 I'm not sure what the *Weak stuff is doing. Can I just hack
 shadowUpdatePacked() itself?

I think so. But take care if you want to use that code on other
systems or without shadowfb. If I search for shadowUpdatePacked, then
I'll find it in quite some other locations.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de

Amtsgericht UlmHRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Xorg on Fujitsu Lime with MPC5200b?

2010-04-16 Thread Roman Fietze
) {
/* how much remains in this window */
i = scrBase + winSize - scr;
if (i = 0 || scr  scrBase)
{
winBase = (FbBits *) (*pBuf-window) (pScreen,
  y,
  scr * sizeof (FbBits),
  SHADOW_WINDOW_WRITE,
  winSize,
  pBuf-closure);
if(!winBase)
return;
scrBase = scr;
winSize /= sizeof (FbBits);
i = winSize;
}
win = winBase + (scr - scrBase);
if (i  width)
i = width;
width -= i;
scr += i;

while (i--)
*win++ = bswap_32(*sha++);
}
shaLine += shaStride;
y++;
}
pbox++;
}
}


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Xorg on Fujitsu Lime with MPC5200b?

2010-04-16 Thread Roman Fietze
Hello Bill,

On Friday 16 April 2010 04:51:38 Bill Gatliff wrote:

 Apparently, there are several similar modifications that need to be
 made, ...

I'm SW-Engineer, so I assume HW, that's always a good bet. ;)

Please take care, that I forgot to tell you that my X server runs well
on a Futjitsu 86295 chip, also connected to a MPC5200(B). I silently
assumed that those two are identical in terms of byte ordering and
(non) existant automatic byte swapping.

At least, when you get a black screen when copying out nothing, you
might be able to copy over some fixed pattern to find out what bits
cause what, e.g. start writing 0x03 and shift that pattern left every
16 scanlines.

In what mode is your X server running? 16/24/32 bit? DirectColor, etc?


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Xorg on Fujitsu Lime with MPC5200b?

2010-04-15 Thread Roman Fietze
Hallo Bill,

On Thursday 15 April 2010 05:07:08 Bill Gatliff wrote:

 Actually, I *have* Debian squeeze's xorg running on the platform just
 fine, with a 2.6.34-rc1 kernel (kernel.org).  Problem is, every single
 diagonal line is very blocky--- not smooth at all.

I'm 95% sure it's an endianess problem, on our boards we had to modify
the X11 driver. What I did was swapping bytes when updating the device
from the shadowfb inside programs/Xserver/miext/shadow/shpacked.c


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Xorg on Fujitsu Lime with MPC5200b?

2010-04-15 Thread Roman Fietze
Hello Bill,

On Thursday 15 April 2010 15:01:59 Bill Gatliff wrote:

 Are you talking about this code here?
 
 void
 shadowUpdatePacked (ScreenPtr pScreen,
 shadowBufPtr pBuf)
 {
 ...
 while (i--)
 *win++ = *sha++;

Yes. I added a routine like

/* Swap frame buffer bytes in 32 bit value.  */
static __inline unsigned int
fbbits_swap32(unsigned int __bsx)
{
return __bsx)  0xff00)  8) | (((__bsx)  0x00ff)  8) |
(((__bsx)  0xff00)  8) | (((__bsx)  0x00ff)  8));
}


Then I added void shadowUpdatePackedSwapped16() and
shadowUpdatePackedSwapped32() which I was using instead of the
original *Weak functions, which in turn uses the above swap routine
when copying from shadow to the device.

If you want I can post (in the ML) or mail you the files that I
changed. A diff probably won't help a lot, because I think we changed
more than that, and we are using a pretty old XFree version.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down

2010-04-01 Thread Roman Fietze
Hallo Wolfgang,

On Wednesday 31 March 2010 12:15:47 Wolfgang Grandegger wrote:

 I just sent out the patch.

Thanks a lot.

 Would be nice if you, or somebody else, could do some testing and
 provide some feedback.

I tested the patches with the following setup:

- DENX 2.6.33 plus NAPI patch, kernel config with and w/o NAPI enabled

- Own Icecube based board using MPC5200B

- Two different hard drives (because the Toshiba gave my headaches),
  ext3 default settings of mkfs.ext3, MWDMA2

- FPGA on LPC receiving high bandwidth MOST150 data in PIO mode (for
  the test: generating them internally), small app writing the data to
  disk. Why PIO? SCLPC FIFO gave 

- netcat receving data optionally writing the data to HD, sender is a
  Gigabit Intel NIC feeded using netcat (and /dev/zero) as well via a
  100MBit/s switch


And now the first and preliminary results of the tests (see legend and
description of the results below the table):

NAPIMOSTHD load bw  rx_irq  rfifo
--+---+---+---+---+---+---
nc  most
==+===+===+===+===+===+===

on  off MK4036GA93  5.1532000-35000
-   99  10.572000-74000

on  MK4036GA49  46  crash   15000-17500 none 
seen
on  HEJ421010G9AT00 48  47  15000-17500 
~100-500, recovers

--+---+---+---+---+---+---

off off MK4036GA90  5.1534000-36000
-   99  10.576000-77000

on  MK4036GA48  47  crash   17500-19000 ~200, 
network down

Legend:
---

MOST:   PIO mode access to FPGA receiving generated MOST150 data
very high data rates possible
HD: used disk type
load/nc:load netcat, %
load/most:  load MOST receiver app, %
load/idle:  was always 0%
bw: netcat network band width, MB/s
rx_irq: FEX RX IRQ, rate in Hz
rfifo:  RX FIFO errors, time in between in seconds

Results:


Using the MK4036GA HD always crashes IDE after a few seconds. A reboot
does not recover the disk, I always need a power cycle. That's why I
switched to a HEJ421010G9AT00.

NAPI reduces the FEC RX interrupt rate (/proc/interrupts) somewhat.
Could not detect an increase of the maximum bandwidth, but that's not
the problem of NAPI.

NAPI nicely recovers more or less nicely from link down (link down to
up about 1 second), without NAPI I have to do that manually (e.g. ip
set link down/up). That's something I was looking for since the
modular PHY drivers.

Some network applications (e.g. our Car Head Unit GN Protocol Logger)
break up their connection when the link goes down (e.g. due to
internal timeouts? Probably fixable). Ssh and netcat connections stay
up.

Transferred many GiB of data to the MPC w/o any problems except those
recoverable FEC_IEVENT_RFIFO_ERRORs.

This patch really looks good to me.

I will run some additional tests e.g. with mixed RX and TX, different
and varying data rates, etc.


 FYI, I will be out of office next week.

Lucky Guy


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


MPC5200B, many FEC_IEVENT_RFIFO_ERRORs until link down

2010-03-30 Thread Roman Fietze
Hello,

I think this is a never ending story. This error still happens under
higher load every few seconds, until I get a PHY: f0003000:00 - Link
is Down, on my box easiliy reproducable after maybe 15 to 30 seconds.
I can recover using ip link set down/up dev eth0.

I double checked that I'm using the most recent version of this driver
(checked with DENX, benh master/next, using Wolfgang Denk's version of
the 2.6.33), this includes the locking patches from Asier Llano, the
hard setting of mii_speed in the PHY mdio transfer routine of course.
I tried all 8 combinations of PLDIS, BSDIS and SE, with and without
CONFIG_NOT_COHERENT_CACHE.

As some of you probably remember, I'm running this controller under
high load on FEC, ATA and LPC. As soon as the load is going above a
certain level I get those FEC RFIFO errors, sometimes ATA errors
(MWDMA2) and sometimes even lost SDMA interrupts using BestComm with
the SCLPC (now switched back to simple PIO). I quite sure almost all
of this is the BestComm's fault.

Did somebody already try the latest NAPI patches, which might give me
a slight chance to have a workaround? Any idea or upcoming patch to
address this problem once more, and if it's just by recovering e.g.
within mpc52xx_fec_mdio_transfer's timeout using some other dirty
workaround?


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


BestComm BD tasks, buffer done flag question

2010-03-19 Thread Roman Fietze
Hello,

I'm using Grant's platform SCLPC/BestComm driver to transfer data from
an FPGA (to disk). Very often I get a negative result from
bcom_buffer_done because BCOM_BD_READY is not set.

When searching for a solution I found this mail from Rob Broersen
talking about a similar promlem in the MPC5200's FEC interrupt
handler:

http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg16324.html

When I now do something ugly like

if (!bcom_buffer_done(lpbfifo-bcom_cur_task))
mdelay(1);

/* retry */
if (!bcom_buffer_done(lpbfifo-bcom_cur_task)) {
ERROR!!!
return IRQ_HANDLED;
}

HANDLE BD

in the ISR I always succeed, even in the cases where the first check
fails and I call the mdelay. Before that I very often ran into the
ERROR!!! case and my transfer failed.

Is there a better solution? Does the FEC interrupt handler really work
fine as it is right now? I ask, because when I assume that there would
be just one active DB (as it always is with the SCLPC platform driver)
this one would evt. stall if there wasn't a second interrupt causing
the loop to handle it in this second interrupt.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] mpc52xx_lpbfifo: flag DMA irqs as enabled after requesting them

2010-03-11 Thread Roman Fietze
Hello,

This patch avoids unbalanced enable/disable messages for the DMA
interrupts when running the 5200 platform SCLPC/BestComm driver in DMA
mode.


Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 929d017..d4f8be3 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -481,6 +481,8 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
if (rc)
goto err_bcom_rx_irq;
 
+   lpbfifo.dma_irqs_enabled = 1;
+
/* Request the Bestcomm transmit (memory -- fifo) task and IRQ */
lpbfifo.bcom_tx_task =
bcom_gen_bd_tx_init(2, res.start + LPBFIFO_REG_FIFO_DATA,
-- 
1.7.0.1


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

2010-02-02 Thread Roman Fietze
Hello Albrecht,

Sorry for the delay ... your mail got stuck in a Notes spam filter.

On Friday 22 January 2010 21:11:39 Albrecht Dreß wrote:

 Are there any final conclusions from your tests?

Yes.

For the small product using the 2.6 kernel we turned all snooping and
the kernel coherent flag off, which avoided crashes of the FEC and/or
hard disk since we introduced that change.

We are currently investigating problems that we are seeing on the
2.4.25 (DENX and Lite5200B based) boards for a long time. Here we are
having problems with corrupt filesystems and FEC hick ups. In this
case we are using UDMA2, because we cannot yet get MWDMA2 work on
2.4.25, well knowing that there might be a problem with UDMA2 and LPC.
So we also turned of snooping and are currently in the testing phase
(again).

 ... two compactflash cards with vfat file systems attached to the
 ata bus; - a nfs3 network drive, connected via a 100MBit line, on a
 Xeon serve

Are you using MWDMA2 with the compact flash cards? What is the load on
the different (DMA) channels? ATA reads or writes?

 ... a signal processor attached to the localbus, using bestcomm and
 the fifo for the bulk transfer

Are you using an own driver, or are you using Grant's SCLPC+SDMA
driver? BD task?


Our latest product uses an SMSC MOST150 Spynic and an FPGA to sample
data from a MOST ring via SCLPC+SDMA (single non BD task from the old
Freescale Betstcomm API) on the 2.4.25. Here moving from memory
accesses to SCLPC+SDMA helped somewhat, probably by avoiding the
UDMA2/LPC problem by mainly letting the SDMA scheduler do the
scheduling of the LPC traffic, which avoids the LPC arbiter problem
somehow.

The probability for seeing problems or crashes increases a lot with
the bandwidth. I think, and I might be wrong, esp. when an arbiter or
scheduler (LPC/PCI or SDMA) needs to switch users or tasks. In our
case we have data running with about 3-6 MB/s (avg.) via the LPC to
the hard disks or somewhat more using FTP from the hard disk to the
FEC.

 I did not observe any issues

The filesystem crashes are seldom, but happen often enough to be able
to reproduce them once every 1 or 2 days under heavy load, and to
produce failures in the field, what's even worse. And they
statistically increased a lot wen we ran out of GPIO on the MPC5200B
and then used an CPLD or FPGA to replace them, just a few bits to MUX
SPI lines, but that was enough.

 but your statements are making me really nervous...

That was not my intention. The best thing is to run very ugly tests
with very high load for at least 24h. Due to the fact that we see
those problems on different boards we (the SW guys) no longer can
assume self made HW problems (HW guys), esp. when reading Freescale's
advice with the XLB config.

It might happen that we switch to 2.6 on our older products, hoping
that at least the LPC/IDE problem disappears by using MWDMA2 instead
of UDMA2.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure

2010-01-11 Thread Roman Fietze
Hello Grant,

On Monday 11 January 2010 20:15:58 Grant Likely wrote:

 No patch description?  Very few patches are sufficiently described by
 the subject line alone.  Tell me what the problem is, what the patch
 changes, and why.

And a lot of other information. Thank you very much for the effort you
put into those patches. I almost knew that you will criticize e.g.
patches that mix functional and optical changes, patches that are
not describing more exactly what I did.

As soon as I have some time left I will try to go once more from the
original driver to the final driver using clear and separate, well
bescribed patches, of course taking care of your and other people
comments.

Again, thanks


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de

Amtsgericht UlmHRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 10/13] powerpc/5200: LocalPlus driver: fix problem caused by unpredictable IRQ order

2010-01-11 Thread Roman Fietze
Hello Grant,

On Monday 11 January 2010 21:19:14 Grant Likely wrote:

 I'm really not convinced.

At least you made me think about that some more. And of course, you
are right, the order must be fixed, one way using TX, the other way
using RX.

I think delayed BCOM IRQs in TX direction, caused by a high FEC or ATA
BCOM load, could cause starting the next job with a not yet cleand up
BD ring.

Please give me another change to come up with a hopefully much cleaner
design, esp. after some tests under low and high load with alternating
transfer directions. Probably we can stay with the original design,
and only take some extra effort when the transfer directions changes.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de

Amtsgericht UlmHRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 03/13] mpc52xx: add SCLPC register bit definitions

2010-01-11 Thread Roman Fietze
Hello Grant,

On Monday 11 January 2010 20:21:22 Grant Likely wrote:

 Unrelated whitespace change?

My fault, as with some other white space changes. My Emacs is
configured using some older setup found in a 2.4
Documentation/CodingStyle. Before saving a file my spine is used to
reformat the whole source file, which then causes those artefacts.
I'll fix the Emacs setup and try to fix my spine, and double check
before commits.

BTW: no Emacs users amongst the kernel coders any more? At least I
have to read So, you can either get rid of GNU emacs, or 


 I prefer the (1n) style myself.

Ok. Looking at it a second time you and Wolfgang are definitively
right. And I prefer the (1n) style a lot more than the 0x0080 style.


 Why is the list head being removed?

Not used at all, except in initialization?

Of course a seperate patch would have been needed.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de

Amtsgericht UlmHRB 541321
Vorstand:
Peter Kersten, Markus Fischer, Franz Diller, Markus Stolz


signature.asc
Description: This is a digitally signed message part.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 0/13] MPC5200B LocalPlus Platform Driver Changes

2009-12-21 Thread Roman Fietze
Hello Grant,

On Tuesday 22 December 2009 01:11:30 Grant Likely wrote:

 Access Forbidden!

git-fetch should have worked. It's a git tree prepared using
git-update-server-info.

 It is easier for me though if you post them to the list. Then I can
 just hit reply to all and make comments on the code.

Ok, I'll do so. I hope I've understood what
http://www.kernel.org/pub/linux/docs/lkml/ says about creating
suitable patches for mailing lists.


Patch description:

This is a series of patches on top of the benh next branch modifying
the platform LocalPlus driver for the MPC5200B. This includes
formatting changes in the first step, switching to a structure
describing the SCLPC registers, making DMA work, making unloading the
module work and so on.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 01/13] powerpc/5200: LocalPlus driver: fix indentation and white space

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   18 +-
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 929d017..4c84aa5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -165,7 +165,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
bit_fields = req-cs  24 | 0x08;
if (!write)
-   bit_fields |= 0x01; /* read mode */
+   bit_fields |= 0x01; /* read mode */
out_be32(lpbfifo.regs + LPBFIFO_REG_CONTROL, bit_fields);
 
/* Kick it off */
@@ -279,7 +279,7 @@ static irqreturn_t mpc52xx_lpbfifo_irq(int irq, void 
*dev_id)
else
do_callback = 1;
 
- out:
+out:
/* Clear the IRQ */
out_8(lpbfifo.regs + LPBFIFO_REG_BYTES_DONE_STATUS, 0x01);
 
@@ -379,11 +379,11 @@ void mpc52xx_lpbfifo_poll(void)
int write = req-flags  MPC52XX_LPBFIFO_FLAG_WRITE;
 
/*
-* For more information, see comments on the Fat Lady 
+* For more information, see comments on the Fat Lady
 */
if (dma  write)
mpc52xx_lpbfifo_irq(0, NULL);
-   else 
+   else
mpc52xx_lpbfifo_bcom_irq(0, NULL);
 }
 EXPORT_SYMBOL(mpc52xx_lpbfifo_poll);
@@ -491,12 +491,12 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
lpbfifo.dev = op-dev;
return 0;
 
- err_bcom_tx:
+err_bcom_tx:
free_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task), lpbfifo);
- err_bcom_rx_irq:
+err_bcom_rx_irq:
bcom_gen_bd_rx_release(lpbfifo.bcom_rx_task);
- err_bcom_rx:
- err_irq:
+err_bcom_rx:
+err_irq:
iounmap(lpbfifo.regs);
lpbfifo.regs = NULL;
 
@@ -516,7 +516,7 @@ static int __devexit mpc52xx_lpbfifo_remove(struct 
of_device *op)
/* Release the bestcomm transmit task */
free_irq(bcom_get_task_irq(lpbfifo.bcom_tx_task), lpbfifo);
bcom_gen_bd_tx_release(lpbfifo.bcom_tx_task);
-   
+
/* Release the bestcomm receive task */
free_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task), lpbfifo);
bcom_gen_bd_rx_release(lpbfifo.bcom_rx_task);
-- 
1.6.5.5


-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 02/13] powerpc/5200: LocalPlus driver: use SCLPC register structure

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/include/asm/mpc52xx.h|   24 
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   79 +++--
 2 files changed, 59 insertions(+), 44 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index b664ce7..57f8335 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -193,6 +193,30 @@ struct mpc52xx_xlb {
 #define MPC52xx_XLB_CFG_PLDIS  (1  31)
 #define MPC52xx_XLB_CFG_SNOOP  (1  15)
 
+/* SCLPC */
+struct mpc52xx_sclpc {
+   union {
+   u8 restart; /* 0x00 restart bit */
+   u32 packet_size; /* 0x00 packet size register */
+   } packet_size;
+   u32 start_address;  /* 0x04 start Address register */
+   u32 control;/* 0x08 control register */
+   u32 enable; /* 0x0C enable register */
+   u32 unused0;/* 0x10 */
+   union {
+   u8 status;  /* 0x14 status register bits */
+   u32 bytes_done; /* 0x14 bytes done register bits, read only */
+   } bytes_done_status;
+
+   u32 reserved1[(0x40-0x18) / sizeof(u32)];   /* 0x18 .. 0x3c */
+
+   u32 fifo_data;  /* 0x40 FIFO data word register */
+   u32 fifo_status;/* 0x44 FIFO status register */
+   u8 fifo_control;/* 0x48 FIFO control register */
+   u8 reserved2[3];
+   u32 fifo_alarm; /* 0x4C FIFO alarm register */
+};
+
 /* Clock Distribution control */
 struct mpc52xx_cdm {
u32 jtag_id;/* CDM + 0x00  reg0 read only */
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 4c84aa5..2763d5e 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -27,20 +27,10 @@ MODULE_AUTHOR(Grant Likely grant.lik...@secretlab.ca);
 MODULE_DESCRIPTION(MPC5200 LocalPlus FIFO device driver);
 MODULE_LICENSE(GPL);
 
-#define LPBFIFO_REG_PACKET_SIZE(0x00)
-#define LPBFIFO_REG_START_ADDRESS  (0x04)
-#define LPBFIFO_REG_CONTROL(0x08)
-#define LPBFIFO_REG_ENABLE (0x0C)
-#define LPBFIFO_REG_BYTES_DONE_STATUS  (0x14)
-#define LPBFIFO_REG_FIFO_DATA  (0x40)
-#define LPBFIFO_REG_FIFO_STATUS(0x44)
-#define LPBFIFO_REG_FIFO_CONTROL   (0x48)
-#define LPBFIFO_REG_FIFO_ALARM (0x4C)
-
 struct mpc52xx_lpbfifo {
struct device *dev;
phys_addr_t regs_phys;
-   void __iomem *regs;
+   struct mpc52xx_sclpc __iomem *regs;
int irq;
spinlock_t lock;
 
@@ -72,10 +62,10 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
int poll_dma = req-flags  MPC52XX_LPBFIFO_FLAG_POLL_DMA;
 
/* Set and clear the reset bits; is good practice in User Manual */
-   out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x0101);
+   out_be32(lpbfifo.regs-enable, 0x0101);
 
/* set master enable bit */
-   out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x0001);
+   out_be32(lpbfifo.regs-enable, 0x0001);
if (!dma) {
/* While the FIFO can be setup for transfer sizes as large as
 * 16M-1, the FIFO itself is only 512 bytes deep and it does
@@ -91,14 +81,14 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
/* Load the FIFO with data */
if (write) {
-   reg = lpbfifo.regs + LPBFIFO_REG_FIFO_DATA;
+   reg = lpbfifo.regs-fifo_data;
data = req-data + req-pos;
for (i = 0; i  transfer_size; i += 4)
out_be32(reg, *data++);
}
 
/* Unmask both error and completion irqs */
-   out_be32(lpbfifo.regs + LPBFIFO_REG_ENABLE, 0x0301);
+   out_be32(lpbfifo.regs-enable, 0x0301);
} else {
/* Choose the correct direction
 *
@@ -108,12 +98,12 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 * is a risk of DMA not transferring the last chunk of data
 */
if (write) {
-   out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM, 0x1e4);
-   out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL, 7);
+   out_be32(lpbfifo.regs-fifo_alarm, 0x1e4);
+   out_8(lpbfifo.regs-fifo_control, 7);
lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
} else {
-   out_be32(lpbfifo.regs + LPBFIFO_REG_FIFO_ALARM, 0x1ff);
-   out_8(lpbfifo.regs + LPBFIFO_REG_FIFO_CONTROL, 0);
+   out_be32(lpbfifo.regs-fifo_alarm, 0x1ff

[PATCH 03/13] mpc52xx: add SCLPC register bit definitions

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/include/asm/mpc52xx.h |   40 +++
 1 files changed, 31 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index 57f8335..c659d1d 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -17,6 +17,7 @@
 #include asm/types.h
 #include asm/prom.h
 #include asm/mpc5xxx.h
+#include linux/bitops.h
 #endif /* __ASSEMBLY__ */
 
 #include linux/suspend.h
@@ -212,11 +213,34 @@ struct mpc52xx_sclpc {
 
u32 fifo_data;  /* 0x40 FIFO data word register */
u32 fifo_status;/* 0x44 FIFO status register */
-   u8 fifo_control;/* 0x48 FIFO control register */
-   u8 reserved2[3];
+   u32 fifo_control;   /* 0x48 FIFO control register */
u32 fifo_alarm; /* 0x4C FIFO alarm register */
 };
 
+#define MPC52xx_SCLPC_FIFO_SIZE(0x200) /* FIFO 
size 512 bytes */
+
+#define MPC52xx_SCLPC_CONTROL_CS(cs)   ((uint32_t)(cs)  24)  /* CSX 
bits */
+#define MPC52xx_SCLPC_CONTROL_FLUSHBIT(17) /* flush, used 
in last packet  */
+#define MPC52xx_SCLPC_CONTROL_RWB_RECEIVE  BIT(16) /* RWb bit, 1 = 
receive */
+#define MPC52xx_SCLPC_CONTROL_DAI  BIT(8)
+
+#define MPC52xx_SCLPC_ENABLE_RCBIT(24) /* 
reset controller bit */
+#define MPC52xx_SCLPC_ENABLE_RFBIT(16) /* 
reset FIFO bit */
+#define MPC52xx_SCLPC_ENABLE_AIE   BIT(9)  /* abort 
interrupt enable bit */
+#define MPC52xx_SCLPC_ENABLE_NIE   BIT(8)  /* normal 
interrupt enable bit */
+#define MPC52xx_SCLPC_ENABLE_MEBIT(0)  /* 
master enable bit */
+
+#define MPC52xx_SCLPC_PACKET_SIZE_RESTART  BIT(24)
+
+#define MPC52xx_SCLPC_STATUS_ATBIT(28) /* 
abort termination */
+#define MPC52xx_SCLPC_STATUS_NTBIT(24) /* 
normal termination */
+#define MPC52xx_SCLPC_STATUS_BYTES_DONE_MASK   (0x00FFU)   /* bytes done 
bit mask */
+
+#define MPC52xx_SLPC_FIFO_STATUS_ERR   BIT(22) /* error bit */
+
+#define MPC52xx_SLPC_FIFO_CONTROL_GR(gr)   ((gr)  24)/* granularity 
bits */
+
+
 /* Clock Distribution control */
 struct mpc52xx_cdm {
u32 jtag_id;/* CDM + 0x00  reg0 read only */
@@ -304,19 +328,18 @@ extern void mpc52xx_restart(char *cmd);
 struct mpc52xx_gpt_priv;
 extern struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq);
 extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
-int continuous);
+  int continuous);
 extern u64 mpc52xx_gpt_timer_period(struct mpc52xx_gpt_priv *gpt);
 extern int mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
 
 /* mpc52xx_lpbfifo.c */
 #define MPC52XX_LPBFIFO_FLAG_READ  (0)
-#define MPC52XX_LPBFIFO_FLAG_WRITE (10)
-#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT  (11)
-#define MPC52XX_LPBFIFO_FLAG_NO_DMA(12)
-#define MPC52XX_LPBFIFO_FLAG_POLL_DMA  (13)
+#define MPC52XX_LPBFIFO_FLAG_WRITE BIT(0)
+#define MPC52XX_LPBFIFO_FLAG_NO_INCREMENT  BIT(1)
+#define MPC52XX_LPBFIFO_FLAG_NO_DMABIT(2)
+#define MPC52XX_LPBFIFO_FLAG_POLL_DMA  BIT(3)
 
 struct mpc52xx_lpbfifo_request {
-   struct list_head list;
 
/* localplus bus address */
unsigned int cs;
@@ -383,4 +406,3 @@ extern char saved_sram[0x4000]; /* reuse buffer from 
mpc52xx suspend */
 #endif /* CONFIG_PM */
 
 #endif /* __ASM_POWERPC_MPC52xx_H__ */
-
-- 
1.6.5.5


-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 04/13] mpc52xx: LocalPlus driver: rewrite interrupt routines, fix errors

2009-12-21 Thread Roman Fietze

Use SCLPC bit definitions from mpc52xx.h for better readability.
Rewrite IRQ handlers, make them work for DMA.
Fix module unload error.

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |  306 -
 1 files changed, 149 insertions(+), 157 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 2763d5e..2fd1f3f 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -46,6 +46,34 @@ struct mpc52xx_lpbfifo {
 /* The MPC5200 has only one fifo, so only need one instance structure */
 static struct mpc52xx_lpbfifo lpbfifo;
 
+
+/**
+ * mpc52xx_lpbfifo_is_write - return true if it's a WRITE request
+ */
+static inline int mpc52xx_lpbfifo_is_write(int flags)
+{
+   return flags  MPC52XX_LPBFIFO_FLAG_WRITE;
+}
+
+
+/**
+ * mpc52xx_lpbfifo_is_dma - return true if it's a DMA request
+ */
+static inline int mpc52xx_lpbfifo_is_dma(int flags)
+{
+   return !(flags  MPC52XX_LPBFIFO_FLAG_NO_DMA);
+}
+
+
+/**
+ * mpc52xx_lpbfifo_is_poll_dma - return true if it's a polled DMA request
+ */
+static inline int mpc52xx_lpbfifo_is_poll_dma(int flags)
+{
+   return flags  MPC52XX_LPBFIFO_FLAG_POLL_DMA;
+}
+
+
 /**
  * mpc52xx_lpbfifo_kick - Trigger the next block of data to be transfered
  */
@@ -57,16 +85,23 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
u32 *data;
int i;
int bit_fields;
-   int dma = !(req-flags  MPC52XX_LPBFIFO_FLAG_NO_DMA);
-   int write = req-flags  MPC52XX_LPBFIFO_FLAG_WRITE;
-   int poll_dma = req-flags  MPC52XX_LPBFIFO_FLAG_POLL_DMA;
+   int rflags = req-flags;
 
/* Set and clear the reset bits; is good practice in User Manual */
-   out_be32(lpbfifo.regs-enable, 0x0101);
+   out_be32(lpbfifo.regs-enable, MPC52xx_SCLPC_ENABLE_RC | 
MPC52xx_SCLPC_ENABLE_RF);
+
+   /* Set width, chip select and READ mode */
+   out_be32(lpbfifo.regs-start_address, req-offset + req-pos);
+
+   /* Set CS and BPT */
+   bit_fields = MPC52xx_SCLPC_CONTROL_CS(req-cs) | 0x8;
+   if (!(mpc52xx_lpbfifo_is_write(rflags))) {
+   bit_fields |= MPC52xx_SCLPC_CONTROL_RWB_RECEIVE;/* read 
mode */
+   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
+   }
+   out_be32(lpbfifo.regs-control, bit_fields);
 
-   /* set master enable bit */
-   out_be32(lpbfifo.regs-enable, 0x0001);
-   if (!dma) {
+   if (!mpc52xx_lpbfifo_is_dma(rflags)) {
/* While the FIFO can be setup for transfer sizes as large as
 * 16M-1, the FIFO itself is only 512 bytes deep and it does
 * not generate interrupts for FIFO full events (only transfer
@@ -80,7 +115,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
transfer_size = 512;
 
/* Load the FIFO with data */
-   if (write) {
+   if (mpc52xx_lpbfifo_is_write(rflags)) {
reg = lpbfifo.regs-fifo_data;
data = req-data + req-pos;
for (i = 0; i  transfer_size; i += 4)
@@ -88,7 +123,9 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
}
 
/* Unmask both error and completion irqs */
-   out_be32(lpbfifo.regs-enable, 0x0301);
+   out_be32(lpbfifo.regs-enable, (MPC52xx_SCLPC_ENABLE_AIE |
+MPC52xx_SCLPC_ENABLE_NIE |
+MPC52xx_SCLPC_ENABLE_ME));
} else {
/* Choose the correct direction
 *
@@ -97,16 +134,16 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 * there is a performance impacit.  However, if it is wrong 
there
 * is a risk of DMA not transferring the last chunk of data
 */
-   if (write) {
-   out_be32(lpbfifo.regs-fifo_alarm, 0x1e4);
-   out_8(lpbfifo.regs-fifo_control, 7);
+   if (mpc52xx_lpbfifo_is_write(rflags)) {
+   out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 28);
+   out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(7));
lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
} else {
-   out_be32(lpbfifo.regs-fifo_alarm, 0x1ff);
-   out_8(lpbfifo.regs-fifo_control, 0);
+   out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 1);
+   out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(0));
lpbfifo.bcom_cur_task = lpbfifo.bcom_rx_task

[PATCH 05/13] powerpc/5200: LocalPlus driver: fix DMA TX interrupt request

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 2fd1f3f..1e4f725 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -460,9 +460,9 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
if (!lpbfifo.bcom_tx_task)
goto err_bcom_tx;
 
-   rc = request_irq(bcom_get_task_irq(lpbfifo.bcom_rx_task),
+   rc = request_irq(bcom_get_task_irq(lpbfifo.bcom_tx_task),
 mpc52xx_lpbfifo_bcom_irq, 0,
-mpc52xx-lpbfifo-rx, lpbfifo);
+mpc52xx-lpbfifo-tx, lpbfifo);
if (rc)
goto err_bcom_tx_irq;
 
-- 
1.6.5.5



-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 06/13] powerpc/5200: LocalPlus driver: map and unmap DMA areas

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/include/asm/mpc52xx.h|2 +-
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   26 +++-
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index c659d1d..043458e 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -347,7 +347,7 @@ struct mpc52xx_lpbfifo_request {
 
/* Memory address */
void *data;
-   phys_addr_t data_phys;
+   dma_addr_t data_dma;
 
/* Details of transfer */
size_t size;
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 1e4f725..8d8a63a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -14,6 +14,7 @@
 #include linux/of.h
 #include linux/of_platform.h
 #include linux/spinlock.h
+#include linux/dma-mapping.h
 #include asm/io.h
 #include asm/prom.h
 #include asm/mpc52xx.h
@@ -138,6 +139,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 28);
out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(7));
lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
+   req-data_dma = dma_map_single(lpbfifo.dev, req-data, 
req-size, DMA_TO_DEVICE);
} else {
out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 1);
out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(0));
@@ -154,6 +156,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
lpbfifo.dma_irqs_enabled = 1;
}
}
+   req-data_dma = dma_map_single(lpbfifo.dev, req-data, 
req-size, DMA_FROM_DEVICE);
}
 
/* error irq  master enabled bit */
@@ -161,7 +164,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
bd = bcom_prepare_next_buffer(lpbfifo.bcom_cur_task);
bd-status = transfer_size;
-   bd-data[0] = req-data_phys + req-pos;
+   bd-data[0] = req-data_dma + req-pos;
bcom_submit_next_buffer(lpbfifo.bcom_cur_task, NULL);
}
 
@@ -236,12 +239,13 @@ static irqreturn_t mpc52xx_lpbfifo_sclpc_irq(int irq, 
void *dev_id)
}
 
rflags = req-flags;
+   status_count = in_be32(lpbfifo.regs-bytes_done_status.bytes_done);
 
-   /* check normal termination bit */
+   /* Check normal termination bit */
if (!(status_count  MPC52xx_SCLPC_STATUS_NT))
goto out;
 
-   /* check abort bit */
+   /* Check abort bit */
if (status_count  MPC52xx_SCLPC_STATUS_AT) {
out_be32(lpbfifo.regs-enable, MPC52xx_SCLPC_ENABLE_RC | 
MPC52xx_SCLPC_ENABLE_RF);
do_callback = 1;
@@ -250,7 +254,7 @@ static irqreturn_t mpc52xx_lpbfifo_sclpc_irq(int irq, void 
*dev_id)
 
if (!mpc52xx_lpbfifo_is_dma(rflags)) {
 
-   /* bytes done */
+   /* Bytes done */
status_count = MPC52xx_SCLPC_STATUS_BYTES_DONE_MASK;
 
if (!mpc52xx_lpbfifo_is_write(rflags)) {
@@ -336,6 +340,16 @@ static irqreturn_t mpc52xx_lpbfifo_bcom_irq(int irq, void 
*dev_id)
bcom_retrieve_buffer(lpbfifo-bcom_cur_task, NULL, NULL);
// req-irq_ticks += get_tbl() - ts;
 
+   if (lpbfifo-req) {
+   if (mpc52xx_lpbfifo_is_write(lpbfifo-req-flags))
+   dma_unmap_single(lpbfifo-dev, lpbfifo-req-data_dma, 
lpbfifo-req-size, DMA_TO_DEVICE);
+   else
+   dma_unmap_single(lpbfifo-dev, lpbfifo-req-data_dma, 
lpbfifo-req-size, DMA_FROM_DEVICE);
+   } else
+   {
+   dev_err(lpbfifo-dev, request is NULL\n);
+   }
+
spin_unlock_irqrestore(lpbfifo-lock, flags);
 
return IRQ_HANDLED;
@@ -439,7 +453,7 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
goto err_irq;
 
/* Request the Bestcomm receive (fifo -- memory) task and IRQ */
-   lpbfifo.bcom_rx_task = bcom_gen_bd_rx_init(16,
+   lpbfifo.bcom_rx_task = bcom_gen_bd_rx_init(4,
   res.start + offsetof(struct 
mpc52xx_sclpc, fifo_data),
   BCOM_INITIATOR_SCLPC, 
BCOM_IPR_SCLPC,
   16*1024*1024);
@@ -453,7 +467,7 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
goto err_bcom_rx_irq;
 
/* Request the Bestcomm transmit (memory -- fifo) task

[PATCH 07/13] powerpc/5200: LocalPlus driver: reset BestComm when committing new request

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 8d8a63a..a7cd585 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -398,6 +398,8 @@ int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request 
*req)
req-buffer_not_done_cnt = 0;
req-pos = 0;
 
+   bcom_gen_bd_rx_reset(lpbfifo.bcom_rx_task);
+   bcom_gen_bd_tx_reset(lpbfifo.bcom_tx_task);
mpc52xx_lpbfifo_kick(req);
spin_unlock_irqrestore(lpbfifo.lock, flags);
 
@@ -456,7 +458,7 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
lpbfifo.bcom_rx_task = bcom_gen_bd_rx_init(4,
   res.start + offsetof(struct 
mpc52xx_sclpc, fifo_data),
   BCOM_INITIATOR_SCLPC, 
BCOM_IPR_SCLPC,
-  16*1024*1024);
+  16 * 1024 * 1024);
if (!lpbfifo.bcom_rx_task)
goto err_bcom_rx;
 
-- 
1.6.5.5



-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 08/13] powerpc/5200: LocalPlus driver: smart flush of receive FIFO

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   40 -
 1 files changed, 26 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index a7cd585..48f2b4f 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -84,8 +84,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
struct bcom_bd *bd;
void __iomem *reg;
u32 *data;
-   int i;
-   int bit_fields;
+   u32 bit_fields;
int rflags = req-flags;
 
/* Set and clear the reset bits; is good practice in User Manual */
@@ -96,27 +95,32 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
/* Set CS and BPT */
bit_fields = MPC52xx_SCLPC_CONTROL_CS(req-cs) | 0x8;
-   if (!(mpc52xx_lpbfifo_is_write(rflags))) {
+   if (!(mpc52xx_lpbfifo_is_write(rflags)))
bit_fields |= MPC52xx_SCLPC_CONTROL_RWB_RECEIVE;/* read 
mode */
-   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
-   }
-   out_be32(lpbfifo.regs-control, bit_fields);
 
if (!mpc52xx_lpbfifo_is_dma(rflags)) {
-   /* While the FIFO can be setup for transfer sizes as large as
-* 16M-1, the FIFO itself is only 512 bytes deep and it does
-* not generate interrupts for FIFO full events (only transfer
-* complete will raise an IRQ).  Therefore when not using
-* Bestcomm to drive the FIFO it needs to either be polled, or
-* transfers need to constrained to the size of the fifo.
+   /* While the FIFO can be setup for transfer sizes as
+* large as 16M-1, the FIFO itself is only 512 bytes
+* deep and it does not generate interrupts for FIFO
+* full events (only transfer complete will raise an
+* IRQ). Therefore when not using Bestcomm to drive the
+* FIFO it needs to either be polled, or transfers need
+* to constrained to the size of the fifo.
 *
 * This driver restricts the size of the transfer
+*
+* The last block of data will be received with the
+* flush bit set. This avoids stale read data.
 */
if (transfer_size  512)
transfer_size = 512;
+   else if (!(mpc52xx_lpbfifo_is_write(rflags)))
+   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
 
/* Load the FIFO with data */
if (mpc52xx_lpbfifo_is_write(rflags)) {
+   size_t i;
+
reg = lpbfifo.regs-fifo_data;
data = req-data + req-pos;
for (i = 0; i  transfer_size; i += 4)
@@ -128,6 +132,12 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 MPC52xx_SCLPC_ENABLE_NIE |
 MPC52xx_SCLPC_ENABLE_ME));
} else {
+
+   /* In DMA mode we can always set the flush bit to avoid
+* stale read data. */
+   if (!(mpc52xx_lpbfifo_is_write(rflags)))
+   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
+
/* Choose the correct direction
 *
 * Configure the watermarks so DMA will always complete 
correctly.
@@ -168,6 +178,8 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
bcom_submit_next_buffer(lpbfifo.bcom_cur_task, NULL);
}
 
+   out_be32(lpbfifo.regs-control, bit_fields);
+
/* Set packet size and kick it off */
out_be32(lpbfifo.regs-packet_size.packet_size, 
MPC52xx_SCLPC_PACKET_SIZE_RESTART | transfer_size);
if (mpc52xx_lpbfifo_is_dma(rflags))
@@ -455,7 +467,7 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
goto err_irq;
 
/* Request the Bestcomm receive (fifo -- memory) task and IRQ */
-   lpbfifo.bcom_rx_task = bcom_gen_bd_rx_init(4,
+   lpbfifo.bcom_rx_task = bcom_gen_bd_rx_init(2,
   res.start + offsetof(struct 
mpc52xx_sclpc, fifo_data),
   BCOM_INITIATOR_SCLPC, 
BCOM_IPR_SCLPC,
   16 * 1024 * 1024);
@@ -469,7 +481,7 @@ mpc52xx_lpbfifo_probe(struct of_device *op, const struct 
of_device_id *match)
goto err_bcom_rx_irq;
 
/* Request the Bestcomm transmit (memory -- fifo) task and IRQ */
-   lpbfifo.bcom_tx_task = bcom_gen_bd_tx_init(4,
+   lpbfifo.bcom_tx_task

[PATCH 09/13] powerpc/5200: LocalPlus driver: smarter calculation of BPT, bytes per transfer

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   33 +++--
 1 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 48f2b4f..21b2a40 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -80,11 +80,11 @@ static inline int mpc52xx_lpbfifo_is_poll_dma(int flags)
  */
 static void mpc52xx_lpbfifo_kick(struct mpc52xx_lpbfifo_request *req)
 {
-   size_t transfer_size = req-size - req-pos;
+   size_t tc = req-size - req-pos;
struct bcom_bd *bd;
void __iomem *reg;
u32 *data;
-   u32 bit_fields;
+   u32 control;
int rflags = req-flags;
 
/* Set and clear the reset bits; is good practice in User Manual */
@@ -93,10 +93,10 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
/* Set width, chip select and READ mode */
out_be32(lpbfifo.regs-start_address, req-offset + req-pos);
 
-   /* Set CS and BPT */
-   bit_fields = MPC52xx_SCLPC_CONTROL_CS(req-cs) | 0x8;
+   /* Setup CS */
+   control = MPC52xx_SCLPC_CONTROL_CS(req-cs);
if (!(mpc52xx_lpbfifo_is_write(rflags)))
-   bit_fields |= MPC52xx_SCLPC_CONTROL_RWB_RECEIVE;/* read 
mode */
+   control |= MPC52xx_SCLPC_CONTROL_RWB_RECEIVE;   /* read mode */
 
if (!mpc52xx_lpbfifo_is_dma(rflags)) {
/* While the FIFO can be setup for transfer sizes as
@@ -112,10 +112,10 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 * The last block of data will be received with the
 * flush bit set. This avoids stale read data.
 */
-   if (transfer_size  512)
-   transfer_size = 512;
+   if (tc  512)
+   tc = 512;
else if (!(mpc52xx_lpbfifo_is_write(rflags)))
-   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
+   control |= MPC52xx_SCLPC_CONTROL_FLUSH;
 
/* Load the FIFO with data */
if (mpc52xx_lpbfifo_is_write(rflags)) {
@@ -123,7 +123,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
reg = lpbfifo.regs-fifo_data;
data = req-data + req-pos;
-   for (i = 0; i  transfer_size; i += 4)
+   for (i = 0; i  tc; i += 4)
out_be32(reg, *data++);
}
 
@@ -136,7 +136,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
/* In DMA mode we can always set the flush bit to avoid
 * stale read data. */
if (!(mpc52xx_lpbfifo_is_write(rflags)))
-   bit_fields |= MPC52xx_SCLPC_CONTROL_FLUSH;
+   control |= MPC52xx_SCLPC_CONTROL_FLUSH;
 
/* Choose the correct direction
 *
@@ -173,15 +173,17 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
out_be32(lpbfifo.regs-enable, MPC52xx_SCLPC_ENABLE_AIE | 
MPC52xx_SCLPC_ENABLE_NIE | MPC52xx_SCLPC_ENABLE_ME);
 
bd = bcom_prepare_next_buffer(lpbfifo.bcom_cur_task);
-   bd-status = transfer_size;
+   bd-status = tc;
bd-data[0] = req-data_dma + req-pos;
bcom_submit_next_buffer(lpbfifo.bcom_cur_task, NULL);
}
 
-   out_be32(lpbfifo.regs-control, bit_fields);
+   /* Setup BPT. tc is already screened and a multiple of 4 */
+   control |= tc  7 ? 4 : 8;
+   out_be32(lpbfifo.regs-control, control);
 
/* Set packet size and kick it off */
-   out_be32(lpbfifo.regs-packet_size.packet_size, 
MPC52xx_SCLPC_PACKET_SIZE_RESTART | transfer_size);
+   out_be32(lpbfifo.regs-packet_size.packet_size, 
MPC52xx_SCLPC_PACKET_SIZE_RESTART | tc);
if (mpc52xx_lpbfifo_is_dma(rflags))
bcom_enable(lpbfifo.bcom_cur_task);
 }
@@ -395,6 +397,11 @@ int mpc52xx_lpbfifo_submit(struct mpc52xx_lpbfifo_request 
*req)
if (!lpbfifo.regs)
return -ENODEV;
 
+   /* The gen bd BestComm task currently only allows an increment
+* of 4 */
+   if (!req-size || req-size  0x03)
+   return -EINVAL;
+
spin_lock_irqsave(lpbfifo.lock, flags);
 
/* If the req pointer is already set, then a transfer is in progress */
-- 
1.6.5.5



-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc

[PATCH 10/13] powerpc/5200: LocalPlus driver: fix problem caused by unpredictable IRQ order

2009-12-21 Thread Roman Fietze

The order of the raised interrupts of SCLPC and BCOM cannot be
predicted, because it depends on the individual BCOM and CPU loads. So
in DMA mode we just wait for both until we finish the transaction.

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   94 +
 1 files changed, 64 insertions(+), 30 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index 21b2a40..cd8dc69 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -32,7 +32,7 @@ struct mpc52xx_lpbfifo {
struct device *dev;
phys_addr_t regs_phys;
struct mpc52xx_sclpc __iomem *regs;
-   int irq;
+   int sclpc_irq;
spinlock_t lock;
 
struct bcom_task *bcom_tx_task;
@@ -41,6 +41,7 @@ struct mpc52xx_lpbfifo {
 
/* Current state data */
struct mpc52xx_lpbfifo_request *req;
+   unsigned short irqs_pending;
int dma_irqs_enabled;
 };
 
@@ -48,6 +49,14 @@ struct mpc52xx_lpbfifo {
 static struct mpc52xx_lpbfifo lpbfifo;
 
 
+/* The order of the raised interrupts of SCLPC and BCOM cann not be
+ * predicted, because it depends on the individual BCOM and CPU
+ * loads. So in DMA mode we just wait for both until we finish the
+ * transaction. */
+#define MPC52XX_LPBFIFO_PENDING_SCLPC  BIT(0)
+#define MPC52XX_LPBFIFO_PENDING_BCOM   BIT(1)
+
+
 /**
  * mpc52xx_lpbfifo_is_write - return true if it's a WRITE request
  */
@@ -127,6 +136,8 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
out_be32(reg, *data++);
}
 
+   lpbfifo.irqs_pending = MPC52XX_LPBFIFO_PENDING_SCLPC;
+
/* Unmask both error and completion irqs */
out_be32(lpbfifo.regs-enable, (MPC52xx_SCLPC_ENABLE_AIE |
 MPC52xx_SCLPC_ENABLE_NIE |
@@ -172,6 +183,8 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
/* error irq  master enabled bit */
out_be32(lpbfifo.regs-enable, MPC52xx_SCLPC_ENABLE_AIE | 
MPC52xx_SCLPC_ENABLE_NIE | MPC52xx_SCLPC_ENABLE_ME);
 
+   lpbfifo.irqs_pending = MPC52XX_LPBFIFO_PENDING_BCOM | 
MPC52XX_LPBFIFO_PENDING_SCLPC;
+
bd = bcom_prepare_next_buffer(lpbfifo.bcom_cur_task);
bd-status = tc;
bd-data[0] = req-data_dma + req-pos;
@@ -188,6 +201,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
bcom_enable(lpbfifo.bcom_cur_task);
 }
 
+
 /**
  * mpc52xx_lpbfifo_sclpc_irq - IRQ handler for LPB FIFO
  *
@@ -232,8 +246,9 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
  */
 static irqreturn_t mpc52xx_lpbfifo_sclpc_irq(int irq, void *dev_id)
 {
+   struct mpc52xx_lpbfifo *lpbfifo = dev_id;
struct mpc52xx_lpbfifo_request *req;
-   u32 status_count = in_be32(lpbfifo.regs-bytes_done_status.bytes_done);
+   u32 status_count = 
in_be32(lpbfifo-regs-bytes_done_status.bytes_done);
void __iomem *reg;
u32 *data;
size_t i;
@@ -242,18 +257,20 @@ static irqreturn_t mpc52xx_lpbfifo_sclpc_irq(int irq, 
void *dev_id)
unsigned long flags;
int rflags;
 
-   spin_lock_irqsave(lpbfifo.lock, flags);
+   spin_lock_irqsave(lpbfifo-lock, flags);
ts = get_tbl();
 
-   req = lpbfifo.req;
+   req = lpbfifo-req;
if (!req) {
-   spin_unlock_irqrestore(lpbfifo.lock, flags);
+   spin_unlock_irqrestore(lpbfifo-lock, flags);
pr_err(bogus SCLPC IRQ\n);
return IRQ_HANDLED;
}
 
+   lpbfifo-irqs_pending = ~MPC52XX_LPBFIFO_PENDING_SCLPC;
+
rflags = req-flags;
-   status_count = in_be32(lpbfifo.regs-bytes_done_status.bytes_done);
+   status_count = in_be32(lpbfifo-regs-bytes_done_status.bytes_done);
 
/* Check normal termination bit */
if (!(status_count  MPC52xx_SCLPC_STATUS_NT))
@@ -261,19 +278,23 @@ static irqreturn_t mpc52xx_lpbfifo_sclpc_irq(int irq, 
void *dev_id)
 
/* Check abort bit */
if (status_count  MPC52xx_SCLPC_STATUS_AT) {
-   out_be32(lpbfifo.regs-enable, MPC52xx_SCLPC_ENABLE_RC | 
MPC52xx_SCLPC_ENABLE_RF);
+   out_be32(lpbfifo-regs-enable, MPC52xx_SCLPC_ENABLE_RC | 
MPC52xx_SCLPC_ENABLE_RF);
do_callback = 1;
goto out;
}
 
-   if (!mpc52xx_lpbfifo_is_dma(rflags)) {
+   if (mpc52xx_lpbfifo_is_dma(rflags)) {
+   if (!lpbfifo-irqs_pending)
+   do_callback = 1;
+   }
+   else {
 
/* Bytes done */
status_count = MPC52xx_SCLPC_STATUS_BYTES_DONE_MASK;
 
if (!mpc52xx_lpbfifo_is_write(rflags)) {
/* copy the data

[PATCH 11/13] powerpc/5200: LocalPlus driver: move RAM DMA address from request to driver

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/include/asm/mpc52xx.h|1 -
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   13 +++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index 043458e..91c65d0 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -347,7 +347,6 @@ struct mpc52xx_lpbfifo_request {
 
/* Memory address */
void *data;
-   dma_addr_t data_dma;
 
/* Details of transfer */
size_t size;
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index cd8dc69..b2c92f5 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -41,6 +41,7 @@ struct mpc52xx_lpbfifo {
 
/* Current state data */
struct mpc52xx_lpbfifo_request *req;
+   dma_addr_t data_dma;
unsigned short irqs_pending;
int dma_irqs_enabled;
 };
@@ -49,7 +50,7 @@ struct mpc52xx_lpbfifo {
 static struct mpc52xx_lpbfifo lpbfifo;
 
 
-/* The order of the raised interrupts of SCLPC and BCOM cann not be
+/* The order of the raised interrupts of SCLPC and BCOM cannot be
  * predicted, because it depends on the individual BCOM and CPU
  * loads. So in DMA mode we just wait for both until we finish the
  * transaction. */
@@ -160,7 +161,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 28);
out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(7));
lpbfifo.bcom_cur_task = lpbfifo.bcom_tx_task;
-   req-data_dma = dma_map_single(lpbfifo.dev, req-data, 
req-size, DMA_TO_DEVICE);
+   lpbfifo.data_dma = dma_map_single(lpbfifo.dev, 
req-data, req-size, DMA_TO_DEVICE);
} else {
out_be32(lpbfifo.regs-fifo_alarm, 
MPC52xx_SCLPC_FIFO_SIZE - 1);
out_be32(lpbfifo.regs-fifo_control, 
MPC52xx_SLPC_FIFO_CONTROL_GR(0));
@@ -177,7 +178,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
lpbfifo.dma_irqs_enabled = 1;
}
}
-   req-data_dma = dma_map_single(lpbfifo.dev, req-data, 
req-size, DMA_FROM_DEVICE);
+   lpbfifo.data_dma = dma_map_single(lpbfifo.dev, 
req-data, req-size, DMA_FROM_DEVICE);
}
 
/* error irq  master enabled bit */
@@ -187,7 +188,7 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 
bd = bcom_prepare_next_buffer(lpbfifo.bcom_cur_task);
bd-status = tc;
-   bd-data[0] = req-data_dma + req-pos;
+   bd-data[0] = lpbfifo.data_dma + req-pos;
bcom_submit_next_buffer(lpbfifo.bcom_cur_task, NULL);
}
 
@@ -378,9 +379,9 @@ static irqreturn_t mpc52xx_lpbfifo_bcom_irq(int irq, void 
*dev_id)
 
if (req) {
if (mpc52xx_lpbfifo_is_write(lpbfifo-req-flags))
-   dma_unmap_single(lpbfifo-dev, 
lpbfifo-req-data_dma, lpbfifo-req-size, DMA_TO_DEVICE);
+   dma_unmap_single(lpbfifo-dev, 
lpbfifo-data_dma, lpbfifo-req-size, DMA_TO_DEVICE);
else
-   dma_unmap_single(lpbfifo-dev, 
lpbfifo-req-data_dma, lpbfifo-req-size, DMA_FROM_DEVICE);
+   dma_unmap_single(lpbfifo-dev, 
lpbfifo-data_dma, lpbfifo-req-size, DMA_FROM_DEVICE);
 
lpbfifo-req = NULL;
out_be32(lpbfifo-regs-enable, 
MPC52xx_SCLPC_ENABLE_RC | MPC52xx_SCLPC_ENABLE_RF);
-- 
1.6.5.5



-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 12/13] mpc52xx: add mpc5200-localplus-test LocalPlus test driver

2009-12-21 Thread Roman Fietze

The original version was done by Grant Likely. This is a modified
version using the platform LocalPlus driver.

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 drivers/misc/mpc5200-localplus-test.c |  879 +
 1 files changed, 879 insertions(+), 0 deletions(-)
 create mode 100644 drivers/misc/mpc5200-localplus-test.c

diff --git a/drivers/misc/mpc5200-localplus-test.c 
b/drivers/misc/mpc5200-localplus-test.c
new file mode 100644
index 000..dcfb282
--- /dev/null
+++ b/drivers/misc/mpc5200-localplus-test.c
@@ -0,0 +1,879 @@
+/*
+ * LocalPlusBus performance tests.
+ *
+ * Copyright (C) Secret Lab Technologies Ltd. 2008-2009
+ *
+ * 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.
+ *
+ * This file implements a set of LocalPlus bus performance tests when using
+ * direct Programmed IO (PIO), the LocalPlus FIFO, and when using the
+ * Bestcomm DMA engine to transfer data.  It can be compiled into the
+ * kernel or loaded as a module.
+ *
+ * The test module is controlled via files in the sysfs filesystem.
+ * Special control files are created in
+ * /sys/devices/platform/lpbtest.0 which control the tests and report
+ * the results. Test parameters are set by writing values into the
+ * parameter files (blocksize, blockcount, bpt, period, and type).
+ * The test is started and stopped with the 'action' file.  Results
+ * are retrieved by reading the contents of the 'results' file.
+ *
+ * The following parameters can be modified:
+ * blocksize: number of bytes to transfer in each block.
+ * blockcount: number of blocks to transfer per timer tick.
+ * period: period of timer or distance (leading '+') in jiffies
+ * ([1-9]{1,}j) or microseconds.  Every timer tick will
+ * start a new transfer of data blocks. If this value is 0,
+ * new transfers will be started as quickly as possible using
+ * a tasklet.
+ * type: type of test; may be 'ram', 'fifo' or 'bcom'.
+ * chipselect: chipselect to use for transfer
+ *
+ * The first test copies contents of an LPB address range using a memcpy.
+ * Usage:
+ * $ echo ram  /sys/devices/platform/lpbtest.0/type
+ * $ echo start  /sys/devices/platform/lpbtest.0/action
+ * $ sleep 5s
+ * $ echo stop  /sys/devices/platform/lpbtest.0/action
+ *
+ * The second test copies contents of an LPB range to RAM using the
+ * LocalPlus FIFO. The FIFO ISR copies each packet from the FIFO to RAM.
+ * Usage:
+ * $ echo fifo  /sys/devices/platform/lpbtest.0/type
+ * $ echo start  /sys/devices/platform/lpbtest.0/action
+ * $ sleep 5s
+ * $ echo stop  /sys/devices/platform/lpbtest.0/action
+ *
+ * The third test copies contents of an LPB range to RAM using both the FIFO
+ * and the Bestcomm DMA engine.
+ *
+ * Usage:
+ * $ echo bcom  /sys/devices/platform/lpbtest.0/type
+ * $ echo start  /sys/devices/platform/lpbtest.0/action
+ * $ sleep 5s
+ * $ echo stop  /sys/devices/platform/lpbtest.0/action
+ *
+ * All sysfs entries can be read by using cat parameter
+ * e.g. cat /sys/devices/platform/lpbtest.0/type will show the test type
+ *
+ * The following is a useful command to dump out all the state of the module:
+ * $ grep '' *
+ *
+ */
+
+// #define DEBUG
+
+#include linux/ctype.h
+#include linux/device.h
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/string.h
+#include linux/mempool.h
+#include linux/timer.h
+#include linux/jiffies.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/of_device.h
+#include linux/of_platform.h
+#include sysdev/bestcomm/bestcomm.h
+#include sysdev/bestcomm/gen_bd.h
+#include sysdev/bestcomm/bestcomm_priv.h
+#include asm/page.h
+#include asm/time.h
+#include asm/cacheflush.h
+#include asm/div64.h
+
+MODULE_AUTHOR(Steven Cavanagh scavan...@secretlab.ca);
+MODULE_LICENSE(GPL);
+
+
+#define DRVNAME lpbtest
+
+#define LPBTEST_FLASH_BASE_ADDR(0xff00)
+#define LPBTEST_FLASH_SIZE (0x0100)/* 16 MiB */
+
+#define LPBTEST_BLOCK_SIZE_MIN 4
+#define LPBTEST_BLOCK_SIZE_MAX (0x2)   /* 128 KiB */
+
+#define LPBTEST_JIFFIES_MIN0
+
+/* Address of SCLPC relative to MBAR
+ *
+ * TODO: move to OF tree?
+ */
+#define MPC52xx_SCLPC_OFFSET   0x3C00
+
+
+/**
+ * lpbtest - Private driver data
+ * @lpb_regs_base: pointer to the LPB's registers
+ * @irq: IRQ of this LPB FIFO
+ * @dev: struct device pointer
+ */
+struct lpbtest {
+   struct device *dev;
+
+   /* sysfs attributes */
+   int action;
+   size_t type;
+   int write;  /* true for write test */
+   size_t blockcount;
+   size_t blocksize;
+   unsigned long period;   /* in jiffies */
+   int period_us;  /* true: period is in us, false: in jiffies */
+   int period_delta;   /* true: period is time between

[PATCH 13/13] powerpc/5200: LocalPlus driver: clean up comments

2009-12-21 Thread Roman Fietze

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c |   14 --
 1 files changed, 0 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c 
b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
index b2c92f5..a89072a 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c
@@ -206,17 +206,6 @@ static void mpc52xx_lpbfifo_kick(struct 
mpc52xx_lpbfifo_request *req)
 /**
  * mpc52xx_lpbfifo_sclpc_irq - IRQ handler for LPB FIFO
  *
- * On transmit, the dma completion irq triggers before the fifo
- * completion triggers.  Handle the dma completion here instead of the
- * LPB FIFO Bestcomm task completion irq because everything is not
- * really done until the LPB FIFO completion irq triggers.
- *
- * In other words:
- * For DMA, on receive, the Fat Lady is the bestcom completion irq. on
- * transmit, the fifo completion irq is the Fat Lady. The opera (or in
- * this case the DMA/FIFO operation) is not finished until the Fat
- * Lady sings.
- *
  * Reasons for entering this routine:
  * 1) PIO mode rx and tx completion irq
  * 2) DMA interrupt mode tx completion irq
@@ -411,9 +400,6 @@ void mpc52xx_lpbfifo_poll(void)
 {
struct mpc52xx_lpbfifo_request *req = lpbfifo.req;
 
-   /*
-* For more information, see comments on the Fat Lady 
-*/
if (mpc52xx_lpbfifo_is_dma(req-flags)  (req-flags  
MPC52XX_LPBFIFO_FLAG_WRITE))
mpc52xx_lpbfifo_sclpc_irq(0, NULL);
else 
-- 
1.6.5.5



-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 05/13] powerpc/5200: LocalPlus driver: fix DMA TX interrupt request

2009-12-21 Thread Roman Fietze
Hello Grant,

On Tuesday 22 December 2009 08:20:16 Grant Likely wrote:

 Is this really what you want? In the TX path, it is the FIFO irq
 that indicates the transfer is complete (ie, the DMA fills the FIFO
 and finishes before the FIFO has drained). If both irqs were
 enabled, then the DMA irq would fire first, followed by the FIFO
 irq. For the use cases I was dealing with, the next transfer cannot
 be kicked off until the FIFO has drained.

I added another patch (PATCH 10/13) that takes care of this problem.
Debugging output (some tiny printk's when I detected the abnormal
case) showed, that when receiving data one cannot predict the order of
the the SDMA and SCLPC interrupt, esp. when e.g. the BestComm has
other tasks with higher prio running, in my case ATA+FEC. I hope I
didn't kill the TX side with this change, because, as I said, could
not yet test it.

Two possible solutions came into my mind:

1) let the SDMA interrupts run freely in parallel and just use the
SCLPC interrupt to detect a finished transaction.

2) Always wait for both, the second one defined the end of the
transaction. IMHO some waste of time.

 In the RX path, the DMA irq indicates that the transfer is complete
 (ie, the localbus fills the FIFO and finishes before the DMA drains
 the FIFO.

See above. That's not always true as stress tests showed. I had cases
where the BestComm was second. The SDMA beeing first is almost always
true for non BD tasks (there is one available in the 2.4.25, but not
in the 2.6 yet), and is mostly true even with BD tasks, but not 100%.

 For my use cases, the RX DMA irq was always required, but the TX DMA
 irq was never needed.

Unloading the module caused an oops when I did not request the TX SDMA
IRQ. Have to check that again.


 Does your use case differ?

I'm currently using your modified lpc test driver and I am currently
in the process of porting a 2.4.25 MOST150 FPGA driver to 2.6 using
the platform LPC driver. As soon as I have results using the FPGA
driver (very high load) I will come back with the results or probably
further patches.

One of them might be increasing the number of BDs again, because the
BestComm seems to take some time until it gives them back to the
world, and then sometimes in batches. I had a similar problem on a
high speed SPI link using the BestComm.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

2009-12-18 Thread Roman Fietze
Hello Wolfgang,

On Friday 18 December 2009 09:24:29 Wolfgang Grandegger wrote:

 What disc access modes, (pio, mwdma or udma) did you use for these tests.

MWDMA2.

On our hardware Linux 2.6 UDMA2 only works with very few disks. And on
top of that, UDMA seems to have problems on the MPC5200B with
concurrent traffic to or from the LPC (chips selects of peripherals
while a DMA transfer is active).

The same disks work without problems using UDMA2 on the old 2.4.25 on
exctly the same HW. Why? I don't know yet.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] PowerPC: const intspec pointers

2009-12-17 Thread Roman Fietze
Hello Grant,

On Tuesday 15 December 2009 20:50:05 Grant Likely wrote:

 Yes, I'm using the driver in a couple of projects.  It works for me
 for both RX and TX (although TX+DMA has been troublesome).

That's what I found out.

 The test driver on the other hand is pretty poor code.  Don't expect
 much from it other than some hints.  There's a reason I didn't merge
 that chunk.

I brought it up to speed before using it.

 Yes, please post the patches and cc: me. I'll review, test, and make
 comments.

I hope it's ok that I've copied them to my web space instead of
providing patches in a mail. The URL is:

  http://www.fietze-home.de/telemotive/linux-2.6-telemotive-mpc.git

Branches:

  benh-next-lpbfifo
the modified version of the LocalPlus platform driver

  benh-next-localplus-test
your old test driver, now using the platform driver


Both branches are on top of the benh next branch.


I could only test the driver using fifo and bcom mode in read mode,
using your old test driver, because I currently do not yet have a
target with a writeable device on the LocalPlus. The test ran fine
using different transer sizes starting at 4 up to 128KiB.

I will now port our FPGA driver to use the platform driver, which can
deliver a very high load, and supports writing.

The biggest problem using DMA is the unpredictable order of arrival of
the two interrupts. They both depend on the appropriate load of the
system generating them. In the case of the BestComm a parallel load on
e.g. FEC or ATA can delay the bcom gen bd interrupt until it's task
gets scheduled again, which can take some time due its low BestComm
prio of 2. The second problem was, that the original driver does not
use the flush bit to avoid stale RX data.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

2009-12-16 Thread Roman Fietze
 coherent setups.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] pata_mpc52xx: optimizing code size by change of ATA timing data types

2009-12-16 Thread Roman Fietze
Hello Everybody,

A totally simple patch that reduces the text size as of the
ppc_6xx-size command of pata_mpc52xx by more than 10%, by reducing the
rodata size from 0x4a4 to 0x17e bytes. This is simply done by changing
the data types of the ATA timing constants.

If you are interested at all, and it's worth the trouble, here the
details:

ppc_6xx-size:
 text data bss  dec  hex filename
old: 6532 1068   0 7600 1db0 pata_mpc52xx.o
new: 5718 1068   0 6786 1a82 pata_mpc52xx.o

The (assembler) code itself doesn't really change very much. I double
checked the final results inside mpc52xx_ata_apply_timings() and they
match.

BTW: Should I break lines at col 72 or 80?


From: Roman Fietze roman.fie...@telemotive.de
Date: Wed, 16 Dec 2009 13:10:31 +0100
Subject: [PATCH] pata_mpc52xx: reduce code size by simple change of constant 
data types

Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 drivers/ata/pata_mpc52xx.c |   78 ++--
 1 files changed, 39 insertions(+), 39 deletions(-)

diff --git a/drivers/ata/pata_mpc52xx.c b/drivers/ata/pata_mpc52xx.c
index 2bc2dbe..e4e5e82 100644
--- a/drivers/ata/pata_mpc52xx.c
+++ b/drivers/ata/pata_mpc52xx.c
@@ -64,13 +64,13 @@ struct mpc52xx_ata_priv {
 
 
 /* ATAPI-4 PIO specs (in ns) */
-static const int ataspec_t0[5]= {600, 383, 240, 180, 120};
-static const int ataspec_t1[5]= { 70,  50,  30,  30,  25};
-static const int ataspec_t2_8[5]  = {290, 290, 290,  80,  70};
-static const int ataspec_t2_16[5] = {165, 125, 100,  80,  70};
-static const int ataspec_t2i[5]   = {  0,   0,   0,  70,  25};
-static const int ataspec_t4[5]= { 30,  20,  15,  10,  10};
-static const int ataspec_ta[5]= { 35,  35,  35,  35,  35};
+static const u16 ataspec_t0[5] = {600, 383, 240, 180, 120};
+static const u16 ataspec_t1[5] = { 70,  50,  30,  30,  25};
+static const u16 ataspec_t2_8[5]   = {290, 290, 290,  80,  70};
+static const u16 ataspec_t2_16[5]  = {165, 125, 100,  80,  70};
+static const u16 ataspec_t2i[5]= {  0,   0,   0,  70,  25};
+static const u16 ataspec_t4[5] = { 30,  20,  15,  10,  10};
+static const u16 ataspec_ta[5] = { 35,  35,  35,  35,  35};
 
 #define CALC_CLKCYC(c,v) v)+(c)-1)/(c)))
 
@@ -78,13 +78,13 @@ static const int ataspec_ta[5]= { 35,  35,  35,  35,  
35};
 
 /* ATAPI-4 MDMA specs (in clocks) */
 struct mdmaspec {
-   u32 t0M;
-   u32 td;
-   u32 th;
-   u32 tj;
-   u32 tkw;
-   u32 tm;
-   u32 tn;
+   u8 t0M;
+   u8 td;
+   u8 th;
+   u8 tj;
+   u8 tkw;
+   u8 tm;
+   u8 tn;
 };
 
 static const struct mdmaspec mdmaspec66[3] = {
@@ -101,23 +101,23 @@ static const struct mdmaspec mdmaspec132[3] = {
 
 /* ATAPI-4 UDMA specs (in clocks) */
 struct udmaspec {
-   u32 tcyc;
-   u32 t2cyc;
-   u32 tds;
-   u32 tdh;
-   u32 tdvs;
-   u32 tdvh;
-   u32 tfs;
-   u32 tli;
-   u32 tmli;
-   u32 taz;
-   u32 tzah;
-   u32 tenv;
-   u32 tsr;
-   u32 trfs;
-   u32 trp;
-   u32 tack;
-   u32 tss;
+   u8 tcyc;
+   u8 t2cyc;
+   u8 tds;
+   u8 tdh;
+   u8 tdvs;
+   u8 tdvh;
+   u8 tfs;
+   u8 tli;
+   u8 tmli;
+   u8 taz;
+   u8 tzah;
+   u8 tenv;
+   u8 tsr;
+   u8 trfs;
+   u8 trp;
+   u8 tack;
+   u8 tss;
 };
 
 static const struct udmaspec udmaspec66[6] = {
@@ -270,7 +270,7 @@ mpc52xx_ata_compute_pio_timings(struct mpc52xx_ata_priv 
*priv, int dev, int pio)
 {
struct mpc52xx_ata_timings *timing = priv-timings[dev];
unsigned int ipb_period = priv-ipb_period;
-   unsigned int t0, t1, t2_8, t2_16, t2i, t4, ta;
+   u32 t0, t1, t2_8, t2_16, t2i, t4, ta;
 
if ((pio  0) || (pio  4))
return -EINVAL;
@@ -299,8 +299,8 @@ mpc52xx_ata_compute_mdma_timings(struct mpc52xx_ata_priv 
*priv, int dev,
if (speed  0 || speed  2)
return -EINVAL;
 
-   t-mdma1 = (s-t0M  24) | (s-td  16) | (s-tkw  8) | (s-tm);
-   t-mdma2 = (s-th  24) | (s-tj  16) | (s-tn  8);
+   t-mdma1 = ((u32)s-t0M  24) | ((u32)s-td  16) | ((u32)s-tkw  
8) | s-tm;
+   t-mdma2 = ((u32)s-th  24) | ((u32)s-tj  16) | ((u32)s-tn  8);
t-using_udma = 0;
 
return 0;
@@ -316,11 +316,11 @@ mpc52xx_ata_compute_udma_timings(struct mpc52xx_ata_priv 
*priv, int dev,
if (speed  0 || speed  2)
return -EINVAL;
 
-   t-udma1 = (s-t2cyc  24) | (s-tcyc  16) | (s-tds  8) | s-tdh;
-   t-udma2 = (s-tdvs  24) | (s-tdvh  16) | (s-tfs  8) | s-tli;
-   t-udma3 = (s-tmli  24) | (s-taz  16) | (s-tenv  8) | s-tsr;
-   t-udma4 = (s-tss  24) | (s-trfs  16) | (s-trp  8) | s-tack;
-   t-udma5 = (s-tzah  24);
+   t-udma1 = ((u32)s-t2cyc  24) | ((u32)s-tcyc  16) | ((u32)s-tds 
 8) | s-tdh;
+   t-udma2 = ((u32)s-tdvs  24) | ((u32)s-tdvh  16) | ((u32)s-tfs 
 8) | s-tli;
+   t-udma3 = ((u32)s-tmli

Re: [PATCH] PowerPC: const intspec pointers

2009-12-15 Thread Roman Fietze
Hallo Grant,

On Friday 11 December 2009 07:13:45 Grant Likely wrote:

 BTW, if you're interested, there is a driver for the SCLPC FIFO about
 to be merged into 2.6.33.  It's in Ben's tree waiting to be pulled
 into mainline.

I've had a look into it. This means I rewrote it in some parts to
get it running.

First I tried to do it in nice little steps, so the git commits are
clean and simple. But with my knowldege about the SCLPC, the code your
old SCLPC test driver and my 2.4.25 FPGA driver using SCLPS and
BestComm, one of the commits just got a big rewrite including fixes
for quite some bugs.

The driver is now running using DMA TX and RX. Without BestComm it's
running partly. I'm really windering if this code ever ran before?
There are some historical or future items in there like measurement of
the times, a list_header maybe for future request queueing, and so on.

If you or Ben are interested in my work I can post the patches
here. Of course just to get some comments, because the driver can't be
ready in the state it is. The commits would go on top of Ben's next
branch.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

2009-12-09 Thread Roman Fietze
Hallo,

I had a discussion with some Freescale support people about the
constant RFIFO Event errors or PATA hard disk crashes when stressing a
board with (very) high loads, in my case even with some additional
traffic from an FPGA (or just the FLASH) via the SCLPC FIFO using the
BestComm.

The latest recommendation from Freescale was to set BSDIS and PLDIS
and to clear SE, resulting in a XLB config register value of
0x80012006, at least for my MPC5200B PVR/SVR of
0x80822014/0x80110022. If I am correct, the current XLB config setting
using the current U-Boot and kernel is 0xa006.

In order to get cache coherency I had to set
CONFIG_NOT_COHERENT_CACHE=y for the MPC5200B boards. Please correct me
if I am wrong with this assumption.

With this setup, XLB config and kernel config, I do no longer have any
PATA crashes, I do no longer have any FEC RFIFO errors, and my SCLPC
driver runs w/o problems, too.

I would be interested in your opinion, maybe Wolfgang could make some
comments, because he is involved in the U-Boot a lot as well.


Here is the original text from the Freescale support person:

-- snippety snip --

Dear Roman Fietze, 

In reply to your message regarding Service Request SR 1-597437219:

Disable pipelining also. Test your software using the following
setting of the XLB arbiter: 0x80012006.

We have request from a customer with similar problem. Problem
disappeared if XLB pipelining and BestComm snooping were disabled.

Should you need to contact us with regard to this message, please see
the notes below.

Best Regards, 

Pavel 
Technical Support
Freescale Semiconductor

-- snappety snap --


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes

2009-12-09 Thread Roman Fietze
Hello Wolfram,

On Wednesday 09 December 2009 15:57:48 Wolfram Sang wrote:

 Do you have a way to measure performance penalties?

Yes, I do. I am using an SCLPC test driver derived from a driver
written or posted by Grant Likely named mpc5200-localplus-test. This
gives me some useful output about the SCLPC BestComm FIFO read
throughput.

Additional to that I'm running I relatively dumb ATA stress test
writing large files to an ext3 that gives me the data rate, as well as
an NFS mount where I read data from.

I will now run all three tests in a few combinations, those that do
not crash my system with the old setup, adding NFS writes and ATA
reads.

I will post the numbers here as soon as I'm done, please give me 2 or
3 days, and as soon as I have the confidence they reflect the reality
at least somewhat.

 I know that stability comes before performance, still I am wondering
 as it looks to me that the most interesting features are simply
 switched off.

We are seeing the same problem in our device, but having a return rate
of almost 100% due to corrupt file systems that can not be repaired in
the field is no alternative.

But, something that never happened before, the system is now running
SCLPC read, ATA write and NFS read for more that 20 hours without any
crash. That's an argument.

Probably the XLB setup has to be done in the U-Boot anyway, and here
the configuration can be flexible enough to enable those positive
features on boards that use only component that do not conflict. The
only thing left is the the cache coherency switch in the kernel
config.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] PowerPC: const intspec pointers

2009-12-08 Thread Roman Fietze
Hello,

Writing a driver using SCLPC on the MPC5200B I detected, that the
intspec arrays to map irqs to Linux virq cannot be const, because the
mapping and xlate functions only take non const pointers. All those
functions do not modify the intspec, so a const pointer could be used.

I tried to compile that patch on different platforms and got no
compiler errors, so I'd like to ask you to review that patch, and
check if it's worth using it.


Signed-off-by: Roman Fietze roman.fie...@telemotive.de
---
 arch/powerpc/include/asm/irq.h  |4 ++--
 arch/powerpc/kernel/irq.c   |2 +-
 arch/powerpc/platforms/52xx/media5200.c |2 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c   |2 +-
 arch/powerpc/platforms/52xx/mpc52xx_pic.c   |2 +-
 arch/powerpc/platforms/85xx/socrates_fpga_pic.c |2 +-
 arch/powerpc/platforms/86xx/gef_pic.c   |2 +-
 arch/powerpc/platforms/cell/beat_interrupt.c|4 ++--
 arch/powerpc/platforms/cell/interrupt.c |2 +-
 arch/powerpc/platforms/cell/spider-pic.c|2 +-
 arch/powerpc/platforms/powermac/pic.c   |2 +-
 arch/powerpc/platforms/pseries/xics.c   |2 +-
 arch/powerpc/sysdev/cpm2_pic.c  |2 +-
 arch/powerpc/sysdev/i8259.c |2 +-
 arch/powerpc/sysdev/ipic.c  |2 +-
 arch/powerpc/sysdev/mpc8xx_pic.c|2 +-
 arch/powerpc/sysdev/mpic.c  |2 +-
 arch/powerpc/sysdev/qe_lib/qe_ic.c  |2 +-
 arch/powerpc/sysdev/tsi108_pci.c|2 +-
 arch/powerpc/sysdev/uic.c   |2 +-
 arch/powerpc/sysdev/xilinx_intc.c   |2 +-
 21 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index bbcd1aa..a0bcafc 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -99,7 +99,7 @@ struct irq_host_ops {
 * interrupt controller has for that line)
 */
int (*xlate)(struct irq_host *h, struct device_node *ctrler,
-u32 *intspec, unsigned int intsize,
+const u32 *intspec, unsigned int intsize,
 irq_hw_number_t *out_hwirq, unsigned int *out_type);
 };
 
@@ -313,7 +313,7 @@ extern void irq_free_virt(unsigned int virq, unsigned int 
count);
  * of the of_irq_map_*() functions.
  */
 extern unsigned int irq_create_of_mapping(struct device_node *controller,
- u32 *intspec, unsigned int intsize);
+ const u32 *intspec, unsigned int 
intsize);
 
 /**
  * irq_of_parse_and_map - Parse and Map an interrupt into linux virq space
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index e5d1211..6e294e0 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -699,7 +699,7 @@ unsigned int irq_create_mapping(struct irq_host *host,
 EXPORT_SYMBOL_GPL(irq_create_mapping);
 
 unsigned int irq_create_of_mapping(struct device_node *controller,
-  u32 *intspec, unsigned int intsize)
+  const u32 *intspec, unsigned int intsize)
 {
struct irq_host *host;
irq_hw_number_t hwirq;
diff --git a/arch/powerpc/platforms/52xx/media5200.c 
b/arch/powerpc/platforms/52xx/media5200.c
index 68e4f16..b1ec9bb 100644
--- a/arch/powerpc/platforms/52xx/media5200.c
+++ b/arch/powerpc/platforms/52xx/media5200.c
@@ -127,7 +127,7 @@ static int media5200_irq_map(struct irq_host *h, unsigned 
int virq,
 }
 
 static int media5200_irq_xlate(struct irq_host *h, struct device_node *ct,
-u32 *intspec, unsigned int intsize,
+const u32 *intspec, unsigned int intsize,
 irq_hw_number_t *out_hwirq,
 unsigned int *out_flags)
 {
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index bfbcd41..78f0ab6 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -182,7 +182,7 @@ static int mpc52xx_gpt_irq_map(struct irq_host *h, 
unsigned int virq,
 }
 
 static int mpc52xx_gpt_irq_xlate(struct irq_host *h, struct device_node *ct,
-u32 *intspec, unsigned int intsize,
+const u32 *intspec, unsigned int intsize,
 irq_hw_number_t *out_hwirq,
 unsigned int *out_flags)
 {
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c 
b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
index 480f806..53d44f6 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c
@@ -355,7 +355,7 @@ static int mpc52xx_is_extirq(int l1, int l2

MPC5200B XLB BSDIS question

2009-12-01 Thread Roman Fietze
Hello list,

In our old, modified 2.4.25 I had a statement that sets the bit BSDIS
(real world bit 16, Freescale bit 15) in the XLB config register for
the MPC5200B.

Checking the XLB config of my 2.6.32-rc7 doesn't show this bit set
(XLB config reads 0xa006).

But this gives me trouble when running under high (BestComm) load. I
have a stress test programm that writes data via PATA to an ext3
filesystem as fast as possible. At the same time I'm using the SCLPC
together with BestComm to read data from FLASH as fast as possible in
64KiB blocks.

Without this bit set I have wrong data in the DMA receive buffer,
almost always only in the first data word (32 bits wide).

And I also have wrong data if I do not invalidate_dcache_range my DMA
buffer before starting the BC task. Looking at dma_map_single or the
old pci_map_single shows me, that they do the cache invalidation on
architecture with non coherent cache, the MPC5200 should be one of
them.

See this old thread that seems to second my theory about a problem in
the MPC5200B, which wouldn't be the first one:

http://www.mail-archive.com/linuxppc-embed...@ozlabs.org/msg02842.html


Is there a reason not to set that bit? Is it true, as I believe it,
that the polairity of this bit is documented the wrong way e.g. in
Freescale's AN3045?


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Micrel PHY KSZ8001 on MPC5200B FEC

2009-11-11 Thread Roman Fietze
Hello Suvidh,

On Wednesday 28 October 2009 16:19:04 suvidh kankariya wrote:

 I am sorry for the misguided statement.

No problem, help is always welcome.

 I indeed had patched it.

Allthough Grant's mail got stuck in our beloved Notes spam filter, we
found out how to use that KSZ8001 on our board.

As Grant mentioned as well, the key was and is a correct DTS. (At
least) one statement was missing:

  interrupt-parent = mpc5200_pic;

This statement seemed to move all the way up from the devices to the
root of the tree, and somehow we missed that move.

Thanks again to all who answered.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


MPC5200B FEC_IEVENT_RFIFO_ERROR leading to Link is Down

2009-11-10 Thread Roman Fietze
Hello,

When having high traffic on the MPC5200B ATA (MWDMA2), FEC (100MBit)
and LPC (MTD FLASH read) I will get the typical
FEC_IEVENT_RFIFO_ERROR's.

Without the FLASH reads, that we use to stress the probably existing
LPC arbiter or MPC5200B silicon bug when running UDMA2+LPC, and which
should not happen using MWDMA2+LPC, I could not yet reproduce the
FEC_IEVENT_RFIFO_ERROR.

Now comes the problem: since the PHY driver rework followed by John
Bonesio's fix (rev 37ccd92f55c6c6) to avoid accessing the DIO bus at
interrupt context, this now sometimes causes an irrecoverable link
down (PHY: f0003000:00 - Link is Down). This patch is of course
necessary to avoid a panic.

I can reproduce that on the current DENX/master using an own board
very close to the Lite5200B. This board runs fine under the old
2.4.25, of course also sometimes showing the FEC FIFO error.

Any ideas?


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Micrel PHY KSZ8001 on MPC5200B FEC

2009-10-27 Thread Roman Fietze
Hello,

We would need some help on how to make a Micrel KSZ8001 work on the
MPC5200B FEC using the kernel DENX-v2.6.3[01].

We can already boot the kernel and device tree using TFTP and this PHY
using a recent U-Boot version, so we would need some pointers how to
acomplish that.

Add a proper PHY driver in the drivers/net/phy/ directory?

Modify the DTS? If yes, how? A link to some documentation that's not
already in the kernel sources would already help.

Is it correct, when looking at the sources, that the MPC's FEC driver
switched to the generic PHY driver interface?


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Micrel PHY KSZ8001 on MPC5200B FEC

2009-10-27 Thread Roman Fietze
Hello Suvidh,

On Tuesday 27 October 2009 17:47:51 suvidh kankariya wrote:

 A driver for micrel phy exists in /drivers/net/phy/micrel.c. in
 2.6.30.

Am I somewhat blind, or do you have access to other 2.6.30's than I
have?

I searched git.kernel.org, git.denx.de and git.secretlab.ca, but could
not find that file, neither in the current master, nor in older tags
somewhat related to 2.6.30, nor in any local clone in any version of
the 2.6 since He created the repos.


 If you are using older kernel you may want to copy it.

2.6.30 and 2.6.31 from DENX or kernel.org.


Roman

-- 
Roman FietzeTelemotive AG Büro Mühlhausen
Breitwiesen  73347 Mühlhausen
Tel.: +49(0)7335/18493-45http://www.telemotive.de
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH]: [MPC5200] Add ATA DMA support

2009-07-09 Thread Roman Fietze
Hallo,

On Monday 05 January 2009 16:31:33 Grant Likely wrote:

 DMA support is now in mainline, but it is disabled by
 default ...

I had problems using ATA DMA on an own MPC5200B board, too. This board
has no problems at all using DMA33 with DENX 2.4.25, with all kinds of
automotive disks from 20 to 40GB. I definitively tested all three
listed drives below, but we are using other drives as well
(e.g. Hitachi 20 and 40 GB variants).

On exactly those boards I'm now running the 2.6.30 from DENX. The
following harddisks work well on this board, including network traffic
in parallel (which sometimes was a problem on old kernels or MPC5200's
w/o a 'B'):

- Toshiba MK4036GA
- Hitachi HEJ423020F9AT00


But an old 20GB Seagate ST940813AM shows the following problem when
booting the system:

PHY: f0003000:00 - Link is Up - 100/Half
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
ata1.00: BMDMA stat 0x5
ata1.00: cmd ca/00:08:1f:10:9c/00:00:00:00:00/e0 tag 0 dma 4096 out
 res 51/84:08:1f:10:9c/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
ata1.00: status: { DRDY ERR }
ata1.00: error: { ICRC ABRT }
ata1: soft resetting link
ata1.00: configured for UDMA/33
ata1: EH complete


I think this is similar to the errors reported after the ATA DMA patch
for the MPC5200B was introduced in this mailing list.

I even tried to use some modified timings from the 2.4.25 kernel, but
(of course) w/o success.

Are there any other patches I should try? Anything I could do to help
you to get this problem fixed?


Roman

-- 
Roman Fietze  Telemotive AG  Büro Mühlhausen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


MTD OF parser problem

2009-07-07 Thread Roman Fietze
Hallo,

I tried to define my MTD partitions in a device tree as
documented. The function of_flash_probe() inside teh file physmap_of.c
never compiled the code below

#ifdef CONFIG_MTD_OF_PARTS

because when the MTD subsystem is compiled as a module I can only find
CONFIG_MTD_OF_PARTS_MODULE beeing defined somewhere below my build
directory.

If I change the above define to

#if defined(CONFIG_MTD_OF_PARTS) || defined(CONFIG_MTD_OF_PARTS_MODULE)

everything is fine and MTD partition work as expected.

My fault? Other solution?

If not, I can submit that tiny patch.


Thanks


Roman

-- 
Roman Fietze  Telemotive AG  Büro Mühlhausen

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] Add MPC52xx simple interrupt GPIO support

2009-02-26 Thread Roman Fietze
 = mpc52xx_gpiochip_remove,
+};
+
+/*
  * GPIO LIB API implementation for gpt GPIOs.
  *
  * Each gpt only has a single GPIO.
@@ -444,6 +599,9 @@ static int __init mpc52xx_gpio_init(void)
if (of_register_platform_driver(mpc52xx_simple_gpiochip_driver))
printk(KERN_ERR Unable to register simple GPIO driver\n);
 
+   if 
(of_register_platform_driver(mpc52xx_simple_interrupt_gpiochip_driver))
+   printk(KERN_ERR Unable to register simple interrupt GPIO 
driver\n);
+
if (of_register_platform_driver(mpc52xx_gpt_gpiochip_driver))
printk(KERN_ERR Unable to register gpt GPIO driver\n);
 
-- 
1.6.1.2




Roman

-- 
Roman Fietze  Telemotive AG  Büro Mühlhausen

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev