Re: MPC5200b jffs2 memcpy alignment problem

[Albrecht Dreß]

Hi Stephan:

Am 30.06.12 21:16 schrieb(en) Stephan Gatzka:

I have a problem running jffs2 on an MPC5200b board. I run kernel 3.4, but 
older kernels like 3.1.5 are also affected. Every time I mount jffs2, 
previously written content gets garbled.

The problem was nailed down to memcpy(&fd->name, rd->name, checkedlen); in 
jffs2_scan_dirent_node in fs/jffs2/scan.c.

[snip]

2. use memcpy_fromio in the jffs2 code. memcpy_fromio behaves exactly in the 
way I described above. This could be also a good solution because flash access 
via LocalPlus bus is clearly IO.


I don't recall who proposed this patch, but exactly this solution is around for 
a longer time (mayby you search archives...).  On my board, I have a flash chip 
attached to the LocalBus in 16-bit mode.  Based on 3.2.16, the patch is:

---8<
--- linux-3.2.16-orig/fs/jffs2/scan.c   2012-04-23 00:31:32.0 +0200
+++ linux-3.2.16/fs/jffs2/scan.c2012-04-27 13:23:06.0 +0200
@@ -509,7 +509,11 @@
sumptr = kmalloc(sumlen, GFP_KERNEL);
if (!sumptr)
return -ENOMEM;
+#ifdef CONFIG_PPC_MPC52xx
+   memcpy_fromio(sumptr + sumlen - 
buf_len, buf + buf_size - buf_len, buf_len);
+#else
memcpy(sumptr + sumlen - buf_len, buf + 
buf_size - buf_len, buf_len);
+#endif
}
if (buf_len < sumlen) {
/* Need to read more so that the entire 
summary node is present */
@@ -1039,7 +1043,11 @@
if (!fd) {
return -ENOMEM;
}
+#ifdef CONFIG_PPC_MPC52xx
+   memcpy_fromio(&fd->name, rd->name, checkedlen);
+#else
memcpy(&fd->name, rd->name, checkedlen);
+#endif
fd->name[checkedlen] = 0;

crc = crc32(0, fd->name, rd->nsize);
---8<

Works perfectly with it...

Hope this helps,
Albrecht.

pgpGSw8l7RNeH.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [OT - MPC5200B] strange framing, break problems with uart

[Albrecht Dreß]

Hi Henk:

Am 01.03.11 23:28 schrieb(en) Henk Stegeman:

Today I noticed corrupted and missing chunks of data on the 5200 with the 
2.6.37 uart driver in 2.6.37.
I don't have these problems when I use the driver from 2.6.33 (with minor 
changes to make it fit in 2.6.37).


Hmm, I hope it's not related to my my baud rate divisor selection patch... :-/


While looking for a reason/solution online I came across your problem report. I 
hope to investigate my problem further soon, but was also wondering if you 
found a cause/early solution for your problem yet, just in case they could be 
related.


Well, my problem occurs when the '5200B is connected to a FTDI usb/serial 
converter (FT2232D) chip, and when both are configured to use rts/cts hw 
handshake.

After some discussions with Freescale's and FTDI's support, the reason seems to 
be that the FTDI chips continues to send zero up to 4 chars *after* the RTSn 
line has been deactivated by the '5200B (actually, this is the behaviour of 
many uart's).  However, the manual says that the '5200B should report overruns 
(and not breaks and/or framing errors) in this case.  Although I asked several 
times, the guy at Freescale did not say a word about this, but just blamed 
FTDI.  So, at best their manual is plain wrong...  Interestingly, if I switch 
rts/cts off, I *do* get overrun errors.  Strange!

The solution for me seems to write my own driver - as I know (unlike "usual" 
serial connections) the packet sizes I expect, I can utilise the PSC's fifo and issue an 
IRQ when it's almost (FIFO size minus 16 chars seems to be bullet-proof after first tests 
even at 3 MBaud) full.  In the ISR I /manually/ deactivate RTSn, a tasklet empties the 
FIFO and asserts RTSn again.  As a positive side effect, it drastically reduces the 
number of interrupts.  Using Bestcomm would probably be better, but I didn't get it 
working (still get the cpu irq's, and the task doesn't run).

Not sure if this information is helpful for you...

Cheers,
Albrecht.


pgpVy9U1djWkG.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[5200B/slightly ot] MPC52xx LPB FIFO memory requirements

[Albrecht Dreß]

Hi all,

I have a slightly off-topic question regarding the use of mpc52xx_lpbfifo_submit() 
& friends...

In struct mpc52xx_lpbfifo_request, the element 'data' (with address 'data_phys') is 
apparently the chunk of data which is transferred through bestcomm, right?  Dumb 
question: has this chunk of memory to be DMA mem (i.e. allocated via dma_alloc_coherent), 
or is "normal" kernel memory (kmalloc) sufficient?

Thanks,
Albrecht.


pgpxTthIqOPdu.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Kernel hangs after "Loading Device Tree" after update

[Albrecht Dreß]

Hi all,

I have a strange problem on a self-developed MPC5200B system (more or less like the 
Freescale "Lite" board).  On that board, I use kernel 3.2.68 with my own 
machine init file, which is almost the same as for Lite 
(arch/powerpc/platforms/52xx/lite5200.c).  Everything works just fine.

When I use 3.18.9 with the same init file modifications and compiled with more or less the same 
.config, plus an adjusted DTB (e.g. rename the "fsl,mpc5200b-psc-uart" entries to 
"fsl,mpc5200b-psc"), the boot process from u-boot simply hangs after:


## Booting kernel from Legacy Image at 0100 ...
   Image Name:   Linux-3.18.9
   Created:  2015-03-30   7:23:52 UTC
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1972101 Bytes =  1.9 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0120
   Booting using the fdt blob at 0x120
   Uncompressing Kernel Image ... OK
   Loading Device Tree to 007fa000, end 007ff2d9 ... OK


Any idea what goes wrong here?  I recall that I used the same approach outlined 
above to move from 2.6.32 to 3.2, which worked immediately.  Might my U-Boot be 
too old (I use 2009.03)?

Thanks in advance,
Albrecht.

pgpp8gyhfG26V.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[OT - MPC5200B] strange framing, break problems with uart

[Albrecht Dreß]

Hi all,

sorry for a slightly off-topic question, but I hope someone here on the list 
may be able to help me...

I have a strange problem with the psc uart of the mpc5200b, running 2.6.32.26 
(still), with my baud rate divisor selection patch [1].

The uart runs at 115.2 kBaud with rtc/cts handshake to send bigger chunks of data to the '5200.  I 
noticed "missing" data in the input stream, and inspected the uart status using the 
TIOCGICOUNT ioctl which tells me that a bunch of framing and break errors occurred.  I 
"tapped" the RxD line and connected it via a level shifter to a standard 16450-style uart 
in a (much faster) Linux PC, and *that* one receives the *complete* stream *without any* break or 
framing errors!

I also looked at the waveforms with an oscilloscope, and they look pretty fine. 
 The port configuration should also be ok, re-checked with a bdi3000 jtag 
debugger - it's PSC3, set to '1100', with PSC3_0 .. PSC3_3 being used here.

This leads me to the assumption that either the hardware handshake or the Linux 
driver or both are broken...  any insight would be highly appreciated!

Cheers,
Albrecht.


[1] ; included in 2.6.37


pgpiuP4ghbD7P.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Fwd: [PATCH] arch/powerpc: Improve _memcpy

[Albrecht Dreß]

See .   
Any chance to get this one into the tree?  Grant?


Cheers, Albrecht.

Am 03.11.09 20:30 schrieb(en) Chris Friesen:


Forwarding to the ppc mailing list.

Chris


 Original Message 
Subject: [PATCH] arch/powerpc: Improve _memcpy
Date: Tue,  3 Nov 2009 15:20:56 +0100
From: Dirk Eibach 
To: linux-ker...@vger.kernel.org
CC: Dirk Eibach 

The implementation of _memcpy_fromio and _memcpy_toio seems to be
suboptimal for size 4.

Signed-off-by: Dirk Eibach 
---
 arch/powerpc/kernel/io.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/io.c b/arch/powerpc/kernel/io.c
index 1882bf4..8dc7547 100644
--- a/arch/powerpc/kernel/io.c
+++ b/arch/powerpc/kernel/io.c
@@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const volatile void
__iomem *src,
dest++;
n--;
}
-   while(n > 4) {
+   while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
vsrc += 4;
@@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem *dest, const
void *src, unsigned long n)
vdest++;
n--;
}
-   while(n > 4) {
+   while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
vdest += 4;
--
1.5.6.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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






pgp1gpEWeEASu.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Albrecht Dreß]

Add the "wdt,on-boot" OF property as to reserve a GPT as WDT which may be a
requirement in safety-related (e.g. ISO 61508) applications.

Signed-off-by: Albrecht Dreß 
---

 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   15 ++-
 1 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt 
b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
index 8447fd7..1eecb06 100644
--- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
@@ -103,7 +103,20 @@ fsl,mpc5200-gpt nodes
 -
 On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
 design supports the internal wdt, then the device node for GPT0 should
-include the empty property 'fsl,has-wdt'.
+include the empty property 'fsl,has-wdt'.  Note that this does not activate
+the watchdog.  The timer will function as a GPT if the timer api is used, and
+it will function as watchdog if the watchdog device is used.  The watchdog
+mode has priority over the gpt mode, i.e. if the watchdog is activated, any
+gpt api call to this timer will fail with -EBUSY.
+
+If you add the property
+   wdt,on-boot = ;
+GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
+If n>0, the watchdog is started with a timeout of n seconds.  If n=0, the
+configuration of the watchdog is not touched.  This is useful in two cases:
+- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
+- do not touch a configuration assigned by the boot loader which supervises
+  the boot process itself.
 
 An mpc5200-gpt can be used as a single line GPIO controller.  To do so,
 add the following properties to the gpt node:

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

[PATCH 0/3] mpc52xx/wdt: re-enable the MPC5200 WDT

[Albrecht Dreß]

This set of patches merges the MPC5200 WDT into the GPT code, making it
functional again - currently, the MPC5200 GPT code blocks using the WDT.

Additionally, it defines a new OF property as to reserve and/or enable the
WDT during the boot process which may be a requirement for safety-related
(e.g. ISO/EN 61508) applications.

Note that all patches are against Grant Likely's "next" tree.

Cheers, Albrecht.

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

[PATCHv2 0/3] mpc52xx/wdt: re-enable the MPC5200 WDT

[Albrecht Dreß]

This set of patches merges the MPC5200 WDT into the GPT code, making it
functional again - currently, the MPC5200 GPT code blocks using the WDT.

Additionally, it defines a new OF property as to reserve and/or enable the
WDT during the boot process which may be a requirement for safety-related
(e.g. ISO/EN 61508) applications.

Note that all patches are against Grant Likely's "next" tree.

Compared to the first version of the patch, the basic change is a full merge
of the WDT code into the GPT implementation in arch/powerpc/platforms/52xx.
It makes the old WDT implementation file obsolete.  As a side effect, it is
not possible any more to build the 52xx WDT support as module which shouldn't
be a big issue, though.

Cheers, Albrecht.

---

 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   17 +-
 arch/powerpc/include/asm/mpc52xx.h |5 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c  |  328 ++--
 drivers/watchdog/Kconfig   |4 +-
 drivers/watchdog/Makefile  |1 -
 5 files changed, 331 insertions(+), 24 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCHv2 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Albrecht Dreß]

Add the "fsl,wdt-on-boot" OF property as to reserve a GPT as WDT which may
be a requirement in safety-related (e.g. ISO/EN 61508) applications.

Signed-off-by: Albrecht Dreß 

---

Change against v1: rename the new property.

 Documentation/powerpc/dts-bindings/fsl/mpc5200.txt |   17 -
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt 
b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
index 8447fd7..ddd5ee3 100644
--- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt
@@ -103,7 +103,22 @@ fsl,mpc5200-gpt nodes
 -
 On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the board
 design supports the internal wdt, then the device node for GPT0 should
-include the empty property 'fsl,has-wdt'.
+include the empty property 'fsl,has-wdt'.  Note that this does not activate
+the watchdog.  The timer will function as a GPT if the timer api is used, and
+it will function as watchdog if the watchdog device is used.  The watchdog
+mode has priority over the gpt mode, i.e. if the watchdog is activated, any
+gpt api call to this timer will fail with -EBUSY.
+
+If you add the property
+   fsl,wdt-on-boot = ;
+GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
+If n>0, the watchdog is started with a timeout of n seconds.  If n=0, the
+configuration of the watchdog is not touched.  This is useful in two cases:
+- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
+- do not touch a configuration assigned by the boot loader which supervises
+  the boot process itself.
+
+The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.
 
 An mpc5200-gpt can be used as a single line GPIO controller.  To do so,
 add the following properties to the gpt node:

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

[PATCHv2 2/3] mpc52xx/wdt: merge WDT code into the GPT driver

[Albrecht Dreß]

Merge the WDT code into the GPT interface.

Signed-off-by: Albrecht Dreß 
---

Change against v1: fully merge the wdt api into this file.
Note: The patch does also include the tiny GPT api changes from
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-November/077647.html>.

 arch/powerpc/include/asm/mpc52xx.h|5 +-
 arch/powerpc/platforms/52xx/mpc52xx_gpt.c |  328 +++--
 2 files changed, 312 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/include/asm/mpc52xx.h 
b/arch/powerpc/include/asm/mpc52xx.h
index 707ab75..b664ce7 100644
--- a/arch/powerpc/include/asm/mpc52xx.h
+++ b/arch/powerpc/include/asm/mpc52xx.h
@@ -279,9 +279,10 @@ extern void mpc52xx_restart(char *cmd);
 /* mpc52xx_gpt.c */
 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, int period,
+extern int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, u64 period,
 int continuous);
-extern void mpc52xx_gpt_stop_timer(struct mpc52xx_gpt_priv *gpt);
+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)
diff --git a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c 
b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
index 2c3fa13..42caecf 100644
--- a/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
+++ b/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
@@ -16,8 +16,14 @@
  * output signals or measure input signals.
  *
  * This driver supports the GPIO and IRQ controller functions of the GPT
- * device.  Timer functions are not yet supported, nor is the watchdog
- * timer.
+ * device.  Timer functions are not yet supported.
+ *
+ * The timer gpt0 can be used as watchdog (wdt).  If the wdt mode is used,
+ * this prevents the use of any gpt0 gpt function (i.e. they will fail with
+ * -EBUSY).  Thus, the safety wdt function always has precedence over the gpt
+ * function.  If the kernel has been compiled with CONFIG_WATCHDOG_NOWAYOUT,
+ * this means that gpt0 is locked in wdt mode until the next reboot - this
+ * may be a requirement in safety applications.
  *
  * To use the GPIO function, the following two properties must be added
  * to the device tree node for the gpt device (typically in the .dts file
@@ -56,11 +62,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 

 MODULE_DESCRIPTION("Freescale MPC52xx gpt driver");
-MODULE_AUTHOR("Sascha Hauer, Grant Likely");
+MODULE_AUTHOR("Sascha Hauer, Grant Likely, Albrecht Dreß");
 MODULE_LICENSE("GPL");

 /**
@@ -70,6 +79,9 @@ MODULE_LICENSE("GPL");
  * @lock: spinlock to coordinate between different functions.
  * @of_gc: of_gpio_chip instance structure; used when GPIO is enabled
  * @irqhost: Pointer to irq_host instance; used when IRQ mode is supported
+ * @wdt_mode: only relevant for gpt0: bit 0 (MPC52xx_GPT_CAN_WDT) indicates
+ *   if the gpt may be used as wdt, bit 1 (MPC52xx_GPT_IS_WDT) indicates
+ *   if the timer is actively used as wdt which blocks gpt functions
  */
 struct mpc52xx_gpt_priv {
struct list_head list;  /* List of all GPT devices */
@@ -78,6 +90,7 @@ struct mpc52xx_gpt_priv {
spinlock_t lock;
struct irq_host *irqhost;
u32 ipb_freq;
+   u8 wdt_mode;

 #if defined(CONFIG_GPIOLIB)
struct of_gpio_chip of_gc;
@@ -101,14 +114,21 @@ DEFINE_MUTEX(mpc52xx_gpt_list_mutex);
 #define MPC52xx_GPT_MODE_CONTINUOUS(0x0400)
 #define MPC52xx_GPT_MODE_OPEN_DRAIN(0x0200)
 #define MPC52xx_GPT_MODE_IRQ_EN(0x0100)
+#define MPC52xx_GPT_MODE_WDT_EN(0x8000)

 #define MPC52xx_GPT_MODE_ICT_MASK  (0x03)
 #define MPC52xx_GPT_MODE_ICT_RISING(0x01)
 #define MPC52xx_GPT_MODE_ICT_FALLING   (0x02)
 #define MPC52xx_GPT_MODE_ICT_TOGGLE(0x03)

+#define MPC52xx_GPT_MODE_WDT_PING  (0xa5)
+
 #define MPC52xx_GPT_STATUS_IRQMASK (0x000f)

+#define MPC52xx_GPT_CAN_WDT(1 << 0)
+#define MPC52xx_GPT_IS_WDT (1 << 1)
+
+
 /* -
  * Cascaded interrupt controller hooks
  */
@@ -375,16 +395,8 @@ struct mpc52xx_gpt_priv *mpc52xx_gpt_from_irq(int irq)
 }
 EXPORT_SYMBOL(mpc52xx_gpt_from_irq);

-/**
- * mpc52xx_gpt_start_timer - Set and enable the GPT timer
- * @gpt: Pointer to gpt private data structure
- * @period: period of timer
- * @continuous: set to 1 to make timer continuous free running
- *
- * An interrupt will be generated every time the timer fires
- */
-int mpc52xx_gpt_start_timer(struct mpc52xx_gpt_priv *gpt, int period,
-int continuous)
+static int mpc52xx_gpt_do_start(struct mpc52xx_gpt_priv *gpt, u64 period,
+   int continuous, i

[PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Albrecht Dreß]

Remove the old WDT implementation.

Signed-off-by: Albrecht Dreß 
---

Change against v1: WDT stuff now fully merged into the file
arch/powerpc/platforms/52xx/mpc52xx_gpt.c.

Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
removed.

 drivers/watchdog/Kconfig  |4 +++-
 drivers/watchdog/Makefile |1 -
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3711b88..d958b76 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -861,8 +861,10 @@ config GEF_WDT
  Watchdog timer found in a number of GE Fanuc single board computers.
 
 config MPC5200_WDT
-   tristate "MPC5200 Watchdog Timer"
+   bool "MPC52xx Watchdog Timer"
depends on PPC_MPC52xx
+   help
+ Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.
 
 config 8xxx_WDT
tristate "MPC8xxx Platform Watchdog Timer"
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 699199b..89c045d 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -118,7 +118,6 @@ obj-$(CONFIG_TXX9_WDT) += txx9wdt.o
 
 # POWERPC Architecture
 obj-$(CONFIG_GEF_WDT) += gef_wdt.o
-obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
 obj-$(CONFIG_8xxx_WDT) += mpc8xxx_wdt.o
 obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
 obj-$(CONFIG_PIKA_WDT) += pika_wdt.o

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

Re: [PATCHv2 1/3] mpc52xx/wdt: OF property to enable the WDT on boot

[Albrecht Dreß]

Hi Grant!

Am 12.11.09 20:06 schrieb(en) Grant Likely:

> +The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.

I think it would be better to use a device tree property to enable up
NOWAYOUT.  The static config isn't multiplatform-friendly.  Thoughts?


I fully agree with you that this property would fit perfectly in the device tree.  However, if we now add it *only* for the 52xx, but not for other device tree-aware platforms, this might be somewhat confusing.  The good thing is that it wouldn't break  
anything for the 5200 as the old wdt driver didn't work anyway.


One *real* advantage of the compile-time option is that it actually removes the code which stops the wdt.  I'm not a real expert in that, but if we argue that the system is "safe" as required by IEC/EN 61508 part 3, it's probably beneficial if we can show  
that there *is* no code to stop the wdt, not a snipplet only disabled by a flag.


Just my €0.01, though - maybe more insight from the WDT gurus?

Cheers, Albrecht.


pgpA6VAeKAhq0.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCHv2 3/3] mpc52xx/wdt: remove obsolete old WDT implementation

[Albrecht Dreß]

Hi Wolfram:

Am 12.11.09 20:56 schrieb(en) Wolfram Sang:

> Note: The file drivers/watchdog/mpc5200_wdt.c is now obsolete and should be 
removed.

Ehrm, this is possible within a patch :)


Ummm, I tried that (removed the file from git locally), but apparently I'm too 
dumb to find the proper options to get this into the diff (to my defence, I'm 
still using cvs/svn for my projects).  Can you give me a hint?


>  config MPC5200_WDT
> -  tristate "MPC5200 Watchdog Timer"
> +  bool "MPC52xx Watchdog Timer"
>depends on PPC_MPC52xx
> +  help
> +Use General Purpose Timer (GPT) 0 on the MPC5200 as Watchdog.

s/5200/52xx/ here too.


Yes, you're right.  The config option should still be 'MPC5200_WDT', though, as 
otherwise all the default configs had to be touched - IMO, on the low level, 
this does no harm.  Thoughts?

Cheers, Albrecht.


pgperL44f7Cq2.pgp
Description: PGP signature
___
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

[Albrecht Dreß]

Hi Roman:

Am 16.12.09 12:37 schrieb(en) Roman Fietze:
The board is using the MPC5200B on a board derived from the old lite5200, but with the fixes for the MPC5200B. All tests are run using an ST940813AM hard drive with an ext2 and an ext3 of 10GB each, default mkfs options. The OS is Debian 4.0. The  
network connection is between a fast Athlon XP2 6400 and the target, using 100MBit/s wiring and a 100MBit/s switch.


Are there any "final" conclusions from your tests?

I am using a board derived from the Lite5200b, running u-boot 2009.03 and a 
recent stock kernel, where I performed tests concurrently reading and writing 
data to and from
- 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;
- a signal processor attached to the localbus, using bestcomm and the fifo for 
the bulk transfer.

I did not observe any issues, but your statements are making me really 
nervous...

Thanks,
Albrecht.


pgpfFd4kle3Nf.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH/RFC 2/2] 5200: improve i2c bus error recovery

[Albrecht Dreß]

Make the I2C adapter timeout configurable through a Device Tree property
which gives the timeout in microseconds.

Signed-off-by: Albrecht Dreß 

---

--- linux-2.6.32-orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt
2009-12-03 04:51:21.0 +0100
+++ linux-2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2010-01-22 
16:04:56.0 +0100
@@ -21,6 +21,7 @@
  - fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
  - clock-frequency : desired I2C bus clock frequency in Hz.
+ - timeout : I2C timeout in microseconds.
 
 Examples :
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH/RFC 2/2] 5200: improve i2c bus error recovery

[Albrecht Dreß]

Am 25.01.10 08:55 schrieb(en) Wolfgang Grandegger:

Albrecht Dreß wrote:

Make the I2C adapter timeout configurable through a Device Tree property which 
gives the timeout in microseconds.


My understanding is that software properties should not be defined via the 
device tree. I think a sysfs entry is more appropriate.


Is the timeout really a /software/ property?  My feeling is that the timeout 
basically depends upon the bus clock and the chips attached to the bus.  
Therefore, it is linked closer to the composition of the board's hardware as 
described in the device tree, than to any userland software.  Or am I totally 
wrong here?

Thanks, Albrecht.


pgpoRDOx1jjyq.pgp
Description: PGP signature
___
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

[Albrecht Dreß]

Hi Roman:

Am 03.02.10 07:16 schrieb(en) Roman Fietze:

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


Never mind.  I didn't know yet that I'm *such* a nasty guy... ;-)


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


Actually, I forgot that I have to explicitly enable libata dma on the 5200b, 
due to the known silicon bugs...  I will repeat my tests with the proper 
configuration, stay tuned.


... 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?


Basically Grant's driver, but with a slightly modified variant of the gen_bd task.  
The signal processor is a LE, and I managed to insert the LE/BE conversion into the 
bestcomm task (see also ).  
Unfortunately, there is no good documentation of the engine; I would like to also 
shift crc calculation into bestcomm, which seems to be possible in principle, but I 
never got it running.


The best thing is to run very ugly tests with very high load for at least 24h.


Thanks again for this tip!  I hope I manage to run a test over the weekend.  
Throughput onto the cf cards is not critical for me (so I could live with pio 
there), but I'm a little afraid I might also see similar effects with fec and 
the signal processor (in particular, the latter *is* critical).

Thanks, Albrecht.


pgpYvbtKoluWE.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[Patch v2 2/2] 5200/mpc: improve i2c bus error recovery

[Albrecht Dreß]

Make the I2C adapter timeout configurable through a Device Tree property
which gives the timeout in microseconds.

Change vs. v.1: use "fsl,timeout" as property name (Thanks, Grant)

Signed-off-by: Albrecht Dreß 

---

--- linux-2.6.32-orig/Documentation/powerpc/dts-bindings/fsl/i2c.txt
2009-12-03 04:51:21.0 +0100
+++ linux-2.6.32/Documentation/powerpc/dts-bindings/fsl/i2c.txt 2010-02-17 
14:18:01.0 +0100
@@ -21,6 +21,7 @@ Recommended properties :
  - fsl,preserve-clocking : boolean; if defined, the clock settings
from the bootloader are preserved (not touched).
  - clock-frequency : desired I2C bus clock frequency in Hz.
+ - fsl,timeout : I2C bus timeout in microseconds.

 Examples :

@@ -44,5 +45,6 @@ Examples :
interrupts = <43 2>;
interrupt-parent = <&mpic>;
clock-frequency = <40>;
+   fsl,timeout = <1>;
};

___
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

[Albrecht Dreß]

Hi Roman:

Sorry for the long delay, I had to fix some other stuff first, before I could 
launch the test...  Here is just a short intermediate result.

Am 04.02.10 20:35 schrieb(en) Albrecht Dreß:

Actually, I forgot that I have to explicitly enable libata dma on the 5200b, 
due to the known silicon bugs...  I will repeat my tests with the proper 
configuration, stay tuned.


... 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?


Basically Grant's driver, but with a slightly modified variant of the gen_bd task.  
The signal processor is a LE, and I managed to insert the LE/BE conversion into the 
bestcomm task (see also <http://patchwork.ozlabs.org/patch/35038/>).  
Unfortunately, there is no good documentation of the engine; I would like to also 
shift crc calculation into bestcomm, which seems to be possible in principle, but I 
never got it running.


The best thing is to run very ugly tests with very high load for at least 24h.


I today launched my test application, on kernel 2.6.32 with a few minor tweaks, 
which runs 4 threads in parallel, all first writing a number of data blocks, 
then doing a sync() when appropriate, and reading reading them all back and 
checking the contents (md5 hash):
- one writes/reads back 256 files of 256k each to a nfs3 share on a Xeon 
server, using a 100 MBit line;
- one writes/reads back one 1 MByte block using BestComm to a Localbus device 
(see quote above);
- two write/read back 128 files of 64k each to two CF cards w/ vfat, both 
attached to the ata (master/slave).

Booting with 'libata.force=mwdma2', this tests reproducibly freezes the system 
*within a few minutes*, in one case leaving the vfat fs on one card completely 
broken.  The system didn't throw a panic, it was always simply stuck - no 
response to the serial console, nothing.

Booting *without* this option (i.e. using pio for the cf cards), the system 
seems to run flawlessly.  I will continue the test over the weekend (now active 
for ~5 hours), but it looks as if I can reproduce your problem.  Next week, 
I'll try your fix (hope I don't wear out the cf cards...), and re-run the test.

Best, Albrecht.


pgpXPDVyEnoYv.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[Patch] mpc5200b: improve baud rate calculation (reach high baud rates, better accuracy)

[Albrecht Dreß]

On the MPC5200B, select the baud rate prescaler as /4 by default to make very
high baud rates (e.g. 3 MBaud) accessible and to achieve a higher precision
for high baud rates in general. For baud rates below ~500 Baud, the code will
automatically fall back to the /32 prescaler.  The original MPC5200 does only
have a /32 prescaler which is detected only once and stored in a global.  A
new chip-dependent method is used to set the divisor.

Tested on a custom 5200B based board, with up to 3 MBaud.

Signed-off-by: Albrecht Dreß 

---

--- linux-2.6.33/drivers/serial/mpc52xx_uart.c.orig 2010-02-24 
19:52:17.0 +0100
+++ linux-2.6.33/drivers/serial/mpc52xx_uart.c  2010-02-26 21:12:51.0 
+0100
@@ -144,9 +144,17 @@ struct psc_ops {
unsigned char   (*read_char)(struct uart_port *port);
void(*cw_disable_ints)(struct uart_port *port);
void(*cw_restore_ints)(struct uart_port *port);
+   void(*set_divisor)(struct uart_port *port,
+  unsigned int divisor);
unsigned long   (*getuartclk)(void *p);
 };
 
+/* We need to distinguish between the MPC5200 which has only a /32 prescaler,
+ * and the MPC5200B which has a /32 and a /4 prescaler.  The global is fine,
+ * as the chip can be only either a 5200B or not. */
+static int is_mpc5200b = -1;
+
+
 #ifdef CONFIG_PPC_MPC52xx
 #define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
 static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -154,9 +162,6 @@ static void mpc52xx_psc_fifo_init(struct
struct mpc52xx_psc __iomem *psc = PSC(port);
struct mpc52xx_psc_fifo __iomem *fifo = FIFO_52xx(port);
 
-   /* /32 prescaler */
-   out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
-
out_8(&fifo->rfcntl, 0x00);
out_be16(&fifo->rfalarm, 0x1ff);
out_8(&fifo->tfcntl, 0x07);
@@ -245,15 +250,40 @@ static void mpc52xx_psc_cw_restore_ints(
out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
 }
 
+static void mpc52xx_psc_set_divisor(struct uart_port *port,
+   unsigned int divisor)
+{
+   struct mpc52xx_psc __iomem *psc = PSC(port);
+
+   /* prescaler */
+   if (is_mpc5200b != 1)
+   out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00); /* /32 */
+   else if (divisor > 0x) {
+   out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00); /* /32 */
+   divisor = (divisor + 4) / 8;
+   } else
+   out_be16(&psc->mpc52xx_psc_clock_select, 0xff00); /* /4 */
+
+   /* ctr */
+   divisor &= 0x;
+   out_8(&psc->ctur, divisor >> 8);
+   out_8(&psc->ctlr, divisor & 0xff);
+}
+
 /* Search for bus-frequency property in this node or a parent */
 static unsigned long mpc52xx_getuartclk(void *p)
 {
/*
-* 5200 UARTs have a / 32 prescaler
-* but the generic serial code assumes 16
-* so return ipb freq / 2
+* The 5200 has only /32 prescalers.
+* 5200B UARTs have a /4 or a /32 prescaler.  For higher accuracy, we
+* do all calculations using the /4 prescaler for this chip.
+* The generic serial code assumes /16 so return ipb freq / 2 (5200)
+* or ipb freq * 4 (5200B).
 */
-   return mpc5xxx_get_bus_frequency(p) / 2;
+   if (is_mpc5200b == 1)
+   return mpc5xxx_get_bus_frequency(p) * 4;
+   else
+   return mpc5xxx_get_bus_frequency(p) / 2;
 }
 
 static struct psc_ops mpc52xx_psc_ops = {
@@ -272,6 +302,7 @@ static struct psc_ops mpc52xx_psc_ops = 
.read_char = mpc52xx_psc_read_char,
.cw_disable_ints = mpc52xx_psc_cw_disable_ints,
.cw_restore_ints = mpc52xx_psc_cw_restore_ints,
+   .set_divisor = mpc52xx_psc_set_divisor,
.getuartclk = mpc52xx_getuartclk,
 };
 
@@ -388,6 +419,16 @@ static void mpc512x_psc_cw_restore_ints(
out_be32(&FIFO_512x(port)->rximr, port->read_status_mask & 0x7f);
 }
 
+static void mpc512x_psc_set_divisor(struct uart_port *port,
+   unsigned int divisor)
+{
+   struct mpc52xx_psc __iomem *psc = PSC(port);
+
+   divisor &= 0x;
+   out_8(&psc->ctur, divisor >> 8);
+   out_8(&psc->ctlr, divisor & 0xff);
+}
+
 static unsigned long mpc512x_getuartclk(void *p)
 {
return mpc5xxx_get_bus_frequency(p);
@@ -409,6 +450,7 @@ static struct psc_ops mpc512x_psc_ops = 
.read_char = mpc512x_psc_read_char,
.cw_disable_ints = mpc512x_psc_cw_disable_ints,
.cw_restore_ints = mpc512x_psc_cw_restore_ints,
+   .set_divisor = mpc512x_psc_set_divisor,
.getuartclk = mpc512x_getuartclk,
 };
 #endif
@@ -564,7 +606,6 @@ mpc52xx_uart_set_termios(struct uart_por
struct mpc52xx_psc __iomem *psc = PS

[Patch v.3] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)

[Albrecht Dreß]

On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general.  This is done by
selecting the appropriate prescaler (/4 or /32).  As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done in a
new set_baudrate method.

Notes: only "fsl,mpc5200b-psc-uart" compatible devices benefit from these
improvements.
The 512x may or may not work; the patch keeps the current implementation
(using a /16 prescaler), but according to the data sheet, this is plain
wrong.  See the comment in mpc512x_psc_set_baudrate().  Any insight and
testing of the code would be appreciated.

Tested on a custom 5200B based board, from 110 baud up to 3 MBaud, and with
both "fsl,mpc5200b-psc-uart" and "fsl,mpc5200-psc-uart" devices.

Signed-off-by: Albrecht Dreß 

---

Changes vs. v.2: Pick up Grant's comments by shifting the calculations to the
new set_baudrate method.


--- linux-2.6.33-orig/drivers/serial/mpc52xx_uart.c 2010-02-24 
19:52:17.0 +0100
+++ linux-2.6.33/drivers/serial/mpc52xx_uart.c  2010-03-04 17:13:47.0 
+0100
@@ -144,9 +144,21 @@ struct psc_ops {
unsigned char   (*read_char)(struct uart_port *port);
void(*cw_disable_ints)(struct uart_port *port);
void(*cw_restore_ints)(struct uart_port *port);
-   unsigned long   (*getuartclk)(void *p);
+   unsigned int(*set_baudrate)(struct uart_port *port,
+   struct ktermios *new,
+   struct ktermios *old);
 };
 
+/* setting the prescaler and divisor reg is common for all chips */
+static inline void mpc52xx_set_divisor(struct mpc52xx_psc __iomem *psc,
+  u16 prescaler, unsigned int divisor)
+{
+   /* select prescaler */
+   out_be16(&psc->mpc52xx_psc_clock_select, prescaler);
+   out_8(&psc->ctur, divisor >> 8);
+   out_8(&psc->ctlr, divisor & 0xff);
+}
+
 #ifdef CONFIG_PPC_MPC52xx
 #define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
 static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -154,9 +166,6 @@ static void mpc52xx_psc_fifo_init(struct
struct mpc52xx_psc __iomem *psc = PSC(port);
struct mpc52xx_psc_fifo __iomem *fifo = FIFO_52xx(port);
 
-   /* /32 prescaler */
-   out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
-
out_8(&fifo->rfcntl, 0x00);
out_be16(&fifo->rfalarm, 0x1ff);
out_8(&fifo->tfcntl, 0x07);
@@ -245,15 +254,47 @@ static void mpc52xx_psc_cw_restore_ints(
out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
 }
 
-/* Search for bus-frequency property in this node or a parent */
-static unsigned long mpc52xx_getuartclk(void *p)
-{
-   /*
-* 5200 UARTs have a / 32 prescaler
-* but the generic serial code assumes 16
-* so return ipb freq / 2
-*/
-   return mpc5xxx_get_bus_frequency(p) / 2;
+static unsigned int mpc5200_psc_set_baudrate(struct uart_port *port,
+struct ktermios *new,
+struct ktermios *old)
+{
+   unsigned int baud;
+   unsigned int divisor;
+
+   /* The 5200 has a fixed /32 prescaler, uartclk contains the ipb freq */
+   baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 32);
+   divisor = (port->uartclk + 16 * baud) / (32 * baud);
+
+   /* enable the /32 prescaler and set the divisor */
+   mpc52xx_set_divisor(PSC(port), 0xdd00, divisor);
+   return baud;
+}
+
+static unsigned int mpc5200b_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
+{
+   unsigned int baud;
+   unsigned int divisor;
+   u16 prescaler;
+
+   /* The 5200B has a selectable /4 or /32 prescaler, uartclk contains the
+* ipb freq */
+   baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 4);
+   divisor = (port->uartclk + 2 * baud) / (4 * baud);
+
+   /* select the proper prescaler and set the divisor */
+   if (divisor > 0x) {
+   divisor = (divisor + 4) / 8;
+   prescaler = 0xdd00; /* /32 */
+   } else
+   prescaler = 0xff00; /* /4 */
+   mpc52xx_set_divisor(PSC(port), prescaler, divisor);
+   return baud;
 }
 
 static struct psc_ops mpc52xx_psc_ops = {
@@ -272,7 +313,26 @@ static struct psc_ops mpc52xx_psc_ops = 
.read_char = mpc52xx_psc_read_char,
  

[OT] Lite5200B w/ nfs root hangs after some time

[Albrecht Dreß]

Hi,

this question is maybe off-topic on this list...

I use the Lite5200B board with stock kernel 2.6.29, and boot with the  
root fs on nfs on an Ubuntu 8.10 PC.  Both the Lite5200B and the Ubuntu  
PC are part of a corporate network.  On the root fs, I have busybox and  
everything else needed.  Being connected with minicom to the serial  
console, after some time I always see a message like


[ 4912.350855] nfs: server 10.16.10.29 not responding, still trying

an the the system is *completely* dead, i.e. it doesn't respond to  
-, it doesn't (as a desktop pc sometimes does) print more than  
one of these or any other kernel messages, and it doesn't recover from  
this condition.  Apparently it doesn't matter if just the busybox shell  
is waiting or if an application is running.


Any idea what goes wrong here, and how I could fix it?

Thanks, Albrecht.


pgp3Mex3ikFRB.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [OT] Lite5200B w/ nfs root hangs after some time

[Albrecht Dreß]

Am 23.04.09 02:05 schrieb(en) Grant Likely:

http://patchwork.ozlabs.org/patch/24487/


That patch is already included in 2.6.29...

No, that's not the problem in this case.  2.6.29 networking is broken  
for a lot of platforms, not just mpc5200.  Use 2.6.29.1 instead.


...and with 2.6.29.1, everything works flawlessly again!

Thanks a lot for your help,
Cheers, Albrecht.


pgppJPSHC7BKA.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

How to use Localbus on 5200B w/ 2.6.29.1

[Albrecht Dreß]

Hi all,

I have a question about the definition of the localbus on the Freescale  
5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which  
I could not figure out with the docs and the list archives...


When I use 'compatible = "fsl,mpc5200b-lpb";' in the dts file, the  
localbus and any nodes below it don't show up in /sys/devices.


When I use the following (top-level, not under the soc node) in the dts  
file



localbus {
compatible = "fsl,lpb";
#address-cells = <2>;
#size-cells = <1>;
reg = <0xf300 0x32>;
ranges = < 0 0 0xfc00 0x0200
   3 0 0xf002 0x0001 >;
fl...@0,0 {
compatible = "cfi-flash";
reg = <0 0x0 0x200>;  // 32 MB
		bank-width = <1>;		// width in bytes of  
the flash bank
		device-width = <1>;		// one devices on each  
bank

#size-cells = <1>;
#address-cells = <1>;
};

my...@3,0 {
compatible = "mydev";
reg = <0 0x0 0x100>;  // 256 Bytes, 32 used
interrupts = <1 3 2>; // todo - level?
interrupt-parent = <&mpc5200_pic>;
};
};


I see in /sys/devices


# ls -al /sys/devices/
drwxr-xr-x7 00   0 Jan  1 00:00 .
drwxr-xr-x   11 00   0 Jan  1 00:00 ..
drwxr-xr-x   31 00   0 Jan  1 00:00 f000.soc5200
drwxr-xr-x4 00   0 Jan  1 00:00  
f300.localbus

drwxr-xr-x2 00   0 Jan  1 00:00 platform
drwxr-xr-x5 00   0 Jan  1 00:00 system
drwxr-xr-x8 00   0 Jan  1 00:00 virtual


Does this mean that the documentation (and some existing dts files) are  
inaccurate?  What is the proper way to specify the localbus (or, in  
particular, it's child nodes) on the 5200B?


In /sys/devices/f300.localbus, I see


# ls -al /sys/devices/f300.localbus/
drwxr-xr-x4 00   0 Jan  1 00:00 .
drwxr-xr-x7 00   0 Jan  1 00:00 ..
-r--r--r--1 004096 Jan  1 00:00 devspec
drwxr-xr-x2 00   0 Jan  1 00:00 fc00.flash
drwxr-xr-x2 00   0 Jan  1 00:00 fc00.mydev
-r--r--r--1 004096 Jan  1 00:00 modalias
-r--r--r--1 004096 Jan  1 00:00 name
lrwxrwxrwx1 00   0 Jan  1 00:00 subsystem ->  
../../bus/of_platform

-rw-r--r--1 004096 Jan  1 00:00 uevent


which is also confusing, as both devices appear to have the same  
address?  Any idea what goes wrong here?


The flash device itself (mydev isn't present yet...) also doesn't work  
although mtd is enabled, but that's probably a different problem.


Any help would be really welcome!

Thanks in advance,
Albrecht.


pgpP00KTgQBWJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: How to use Localbus on 5200B w/ 2.6.29.1

[Albrecht Dreß]

Hi Grant:

Am 27.04.09 19:36 schrieb(en) Grant Likely:
For completeness use: compatible =  
"fsl,mpc5200b-lpb","fsl,mpc5200-lpb","simple-bus";  Then it will work.


I doesn't.  I had to add "fsl,lpb", without no localbus nodes show up.   
The file arch/powerpc/platforms/52xx/mpc52xx_common.c lists only  
"fsl,lpb"  as "compatible".  Or did I miss something here?



If this is on CS3, then reg should be:
   reg = <3 0x0 0x100>;// 256 Bytes, 32 used


Ouch.  Sorry, that was the error.  Works perfectly now...

Thanks a lot for your help,
Albrecht.


pgp5Pt9fMMjCI.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

[PATCH] powerpc: tiny memcpy_(to|from)io optimisation

[Albrecht Dreß]

This trivial patch changes memcpy_(to|from)io as to transfer as many  
32-bit words as possible in 32-bit accesses (in the current solution,  
the last 32-bit word was transferred as 4 byte accesses).


Signed-off-by: Albrecht Dreß 
---

diff -urpN -X linux-2.6.29.1.orig/Documentation/dontdiff  
linux-2.6.29.1.orig/arch/powerpc/kernel/io.c  
linux-2.6.29.1/arch/powerpc/kernel/io.c
--- linux-2.6.29.1.orig/arch/powerpc/kernel/io.c	2009-04-02  
22:55:27.0 +0200
+++ linux-2.6.29.1/arch/powerpc/kernel/io.c	2009-05-27  
11:36:09.0 +0200

@@ -161,7 +161,7 @@ void _memcpy_fromio(void *dest, const vo
dest++;
n--;
}
-   while(n > 4) {
+   while(n >= 4) {
*((u32 *)dest) = *((volatile u32 *)vsrc);
eieio();
vsrc += 4;
@@ -190,7 +190,7 @@ void _memcpy_toio(volatile void __iomem
vdest++;
n--;
}
-   while(n > 4) {
+   while(n >= 4) {
*((volatile u32 *)vdest) = *((volatile u32 *)src);
src += 4;
vdest += 4;


pgpfUatqLUV9j.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation

[Albrecht Dreß]

Am 28.05.09 18:13 schrieb(en) Joakim Tjernlund:
hmm, these do look a bit unoptimal anyway. Any reason not to write  
them something like below(written by me for uClibc long time ago).  
You will have to add eieio()/sync


No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I just  
stumbled over this while fixing mtd accesses to the MPC5200's Local Bus  
in 16-bit mode which doesn't allow byte accesses.  And I didn't want to  
go too deep into this as the real fix for me is actually somewhat  
different...


/* PPC can do pre increment and load/store, but not post increment  
and load/store.

   Therefore use *++ptr instead of *ptr++. */

[snip]

 copy_chunks:
do {
/* make gcc to load all data, then store it */
tmp1 = *(unsigned long *)(tmp_from+4);
tmp_from += 8;
tmp2 = *(unsigned long *)tmp_from;
*(unsigned long *)(tmp_to+4) = tmp1;
tmp_to += 8;
*(unsigned long *)tmp_to = tmp2;
} while (--chunks);


Is this the same for all PPC cores, i.e. do they all benefit from  
loading/storing 8 instead of 4 bytes?


Best, Albrecht.


pgp51rCL2tmWP.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation

[Albrecht Dreß]

Hi Jocke:

Am 29.05.09 08:31 schrieb(en) Joakim Tjernlund:
> No (and I wasn't aware of the PPC pre-inc vs. post-inc stuff) - I  
just


I think this is true for most RISC based CPU's. It is a pity as
post ops are a lot more common. The do {} while(--chunks) is also
better. Basically the "while(--chunks)" is free(but only if you don't  
use

chunks inside the loop).


Just a side note:  I looked at the assembly output of gcc 4.3.3 coming  
with Ubuntu Jaunty/PowerPC for



  n >>= 2;
  do {
*++dst = *++src;
  } while (--n);


and


  n >>= 2;
  while (n--)
*dst++ = *src++;


Using the gcc options "-O2 -mcpu=603e -mtune=603e" (same effect with  
"-O3" instead of "-O2") the loop core is *exactly* the same in both  
cases.


With gcc 4.2.2 (coming with ELDK 4.2) the loop core in case 2 is indeed  
one statement longer, though...


Best, Albrecht.


pgpPEJlVUM1dF.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation

[Albrecht Dreß]

Am 01.06.09 08:14 schrieb(en) Joakim Tjernlund:
.. not even 4.2.2 which is fairly modern will get it right. It breaks  
very easy as gcc has never been any good at this type of  
optimization. Sometimes small changes will make gcc unhappy and it  
won't do the right optimization.


It's even worse...  Looking at the assembly output of the simple  
function



void loop2(void * src, void * dst, int n)
{
  volatile uint32_t * _dst = (volatile uint32_t *) (dst - 4);
  volatile uint32_t * _src = (volatile uint32_t *) (src - 4);
  n >>= 2;
  do {
*(++_dst) = *(++_src);
  } while (--n);
}


gcc 4.0.1 coming with Apple's Developer Tools (on Tiger) with options  
"-O3 -mcpu=603e -mtune=603e" produces



_loop2:
srawi r5,r5,2
mtctr r5
addi r4,r4,-4
addi r3,r3,-4
L11:
lwzu r0,4(r3)
stwu r0,4(r4)
bdnz L11
blr


which looks perfect to me.  However, gcc 4.3.3 on Ubuntu/PPC produces  
with the same options



loop2:
srawi 5,5,2
stwu 1,-16(1)
mtctr 5
li 9,0
.L8:
lwzx 0,3,9
stwx 0,4,9
addi 9,9,4
bdnz .L8
addi 1,1,16
blr


wasting a register and a statement in the loop core, and fiddles around  
with the stack pointer for no good reason.  Gcc 4.4.0 produces



loop2:
srawi 5,5,2
mtctr 5
li 9,0
.L9:
lwzx 0,3,9
stwx 0,4,9
addi 9,9,4
bdnz .L9
blr


which drops the r1 accesses, but still produces the sub-optimal loop.   
Is this a gcc regression, or did I miss something here?  Probably the  
only bullet-proof way is to write some core loops in assembly... :-/


Thanks, Albrecht.


pgpMRQRHxmbwt.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Re: [PATCH] powerpc: tiny memcpy_(to|from)io optimisation

[Albrecht Dreß]

Am 03.06.09 16:36 schrieb(en) Kenneth Johansson:
On an e300 core using the lwzu/stwu is about 20% faster so at least  
one core prefer that optimization.


Bingo.  The '5200 on my test system has that core.  So "-mcpu=603e"  
should select this strategy!


Cheers, Albrecht.



pgpAeWzL3wfxw.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

5200B: BUG in 2.6.34-rc1-dirty while loading at24 driver

[Albrecht Dreß]

Hi all,

not sure if this is the right place to ask:  When I boot a custom 5200B (more 
or less Lite-based) board with Linus' git tree (2.6.34-rc1-dirty), I always get 
the following bug:

[1.110693] i2c /dev entries driver
[1.117285] mpc-i2c f0003d00.i2c: clock 375000 Hz (fdr=137)
[1.123156] mpc-i2c f0003d00.i2c: timeout 100 us
[1.146528] mpc-i2c f0003d40.i2c: clock 375000 Hz (fdr=137)
[1.152637] mpc-i2c f0003d40.i2c: timeout 100 us
[1.170628] rtc-ds1307 1-0068: rtc core: registered ds1337 as rtc0
[1.181003] BUG: key cf9ea5ac not in .data!
[1.185510] [ cut here ]
[1.190257] Badness at kernel/lockdep.c:2706
[1.194627] NIP: c004d2b4 LR: c004d29c CTR: c01aeb30
[1.199714] REGS: cf82db70 TRAP: 0700   Not tainted  (2.6.34-rc1-dirty)
[1.206483] MSR: 00029032   CR: 22084022  XER: 2000
[1.213305] TASK = cf83[1] 'swapper' THREAD: cf82c000
[1.218651] GPR00:  cf82dc20 cf83 0001 0001 c0023fb4 
 0001
[1.227243] GPR08:  c03f c03c 0001 42084024 100958e4 
0ffef000 0ffe41a4
[1.235834] GPR16: 0ffbf298 0ffe4180 0ff72db4 0ff72cb4 c03d685c c03d6830 
 
[1.244423] GPR24: fff4 0001 c03f 0080 cfa1c2d8 cf9ea5ac 
 cfa1c4d8
[1.253225] NIP [c004d2b4] lockdep_init_map+0xc4/0x4e4
[1.258489] LR [c004d29c] lockdep_init_map+0xac/0x4e4
[1.263657] Call Trace:
[1.266165] [cf82dc20] [c004d28c] lockdep_init_map+0x9c/0x4e4 (unreliable)
[1.273236] [cf82dc50] [c00de478] sysfs_add_file_mode+0x5c/0xe0
[1.279308] [cf82dc80] [c00e0bbc] sysfs_create_bin_file+0x34/0x50
[1.285575] [cf82dc90] [c01b8764] at24_probe+0x314/0x460
[1.291034] [cf82dcd0] [c0215768] i2c_device_probe+0xac/0xc0
[1.296840] [cf82dcf0] [c01b334c] driver_probe_device+0xa4/0x190
[1.303000] [cf82dd10] [c01b23c0] bus_for_each_drv+0x70/0xac
[1.308806] [cf82dd40] [c01b3620] device_attach+0x84/0xa8
[1.314343] [cf82dd60] [c01b1fd8] bus_probe_device+0x3c/0x54
[1.320166] [cf82dd70] [c01b0588] device_add+0x374/0x5f4
[1.325619] [cf82ddc0] [c0216ac4] i2c_new_device+0xf0/0x144
[1.331344] [cf82dde0] [c021b078] of_register_i2c_devices+0x12c/0x158
[1.337966] [cf82de60] [c02c1280] fsl_i2c_probe+0x190/0x324
[1.343687] [cf82de90] [c021abe8] of_platform_device_probe+0x5c/0x84
[1.350208] [cf82deb0] [c01b334c] driver_probe_device+0xa4/0x190
[1.356371] [cf82ded0] [c01b36e8] __driver_attach+0xa4/0xa8
[1.362087] [cf82def0] [c01b259c] bus_for_each_dev+0x60/0x9c
[1.367890] [cf82df20] [c01b3164] driver_attach+0x24/0x34
[1.373429] [cf82df30] [c01b2ef4] bus_add_driver+0x1a8/0x264
[1.379235] [cf82df60] [c01b3964] driver_register+0x6c/0x160
[1.385043] [cf82df80] [c021aac0] of_register_driver+0x54/0x70
[1.391040] [cf82df90] [c03ae9fc] fsl_i2c_init+0x24/0x54
[1.396497] [cf82dfa0] [c00038a0] do_one_initcall+0x40/0x1d4
[1.402305] [cf82dfd0] [c039a1e0] kernel_init+0xc4/0x16c
[1.407771] [cf82dff0] [c00110d8] kernel_thread+0x4c/0x68
[1.413300] Instruction dump:
[1.416341] 3863256c 4bfd758d 801ac11c 2f80 40beffd4 48140b11 2f83 
41beffc8
[1.424309] 3d20c03f 8009c2a0 2f80 40beffb8 <0fe0> 80010034 bac10008 
38210030
[1.432600] at24 1-0050: 65536 byte 24c512 EEPROM (writable)

Stock 2.6.33 runs flawlessly.  Maybe I should add here that there is no eeprom 
connected to the I2C bus (just a placeholder in the dts file, for a chip on a 
separate board).  Any idea what goes wrong here?

Thanks, Albrecht.


pgpEVjOjQreEN.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

[Albrecht Dreß]

Am 26.03.10 23:59 schrieb(en) Josh Triplett:
[snip]

Any other ideas for things we could check to try to track down this problem?


Might your issue be related to this thread: 
?

Cheers, Albrecht.


pgpEywOLv7gWI.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Failing to get DMA working with MPC5200 (TQM5200) and CompactFlash

[Albrecht Dreß]

Hi Josh:

Am 29.03.10 00:24 schrieb(en) Josh Triplett:

We have the MPC5200C rev of the board, not the MPC5200B rev which


Ummm - I didn't know that there is a 5200C available.  The Freescale web site 
only mentions the 5200 and the 5200B.  Do you have any pointers to data 
sheets/docs?

Thanks, Albrecht.


pgptFWfkVYLQV.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[Patch v.3a] mpc5200b/uart: improve baud rate calculation (reach high baud rates, better accuracy)

[Albrecht Dreß]

On the MPC5200B, make very high baud rates (e.g. 3 MBaud) accessible and
achieve a higher precision for high baud rates in general.  This is done by
selecting the appropriate prescaler (/4 or /32).  As to keep the code clean,
the getuartclk method has been dropped, and all calculations are done in a
new set_baudrate method.

Notes: only "fsl,mpc5200b-psc-uart" compatible devices benefit from these
improvements.
The 512x may or may not work; the patch keeps the current implementation
(using a /16 prescaler), but according to the data sheet, this is plain
wrong.  See the comment in mpc512x_psc_set_baudrate().  Any insight and
testing of the code (maybe Anatolij, when he's back from his vacation)
would be appreciated.

Tested on a custom 5200B based board, from 110 baud up to 3 MBaud, and with
both "fsl,mpc5200b-psc-uart" and "fsl,mpc5200-psc-uart" devices.

Signed-off-by: Albrecht Dreß 

---

Change vs. v.3: re-based against Linus' git tree (2.6.34-rc1-dirty)

diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index 3119fdd..e349514 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -146,7 +146,9 @@ struct psc_ops {
unsigned char   (*read_char)(struct uart_port *port);
void(*cw_disable_ints)(struct uart_port *port);
void(*cw_restore_ints)(struct uart_port *port);
-   unsigned long   (*getuartclk)(void *p);
+   unsigned int(*set_baudrate)(struct uart_port *port,
+   struct ktermios *new,
+   struct ktermios *old);
int (*clock)(struct uart_port *port, int enable);
int (*fifoc_init)(void);
void(*fifoc_uninit)(void);
@@ -154,6 +156,16 @@ struct psc_ops {
irqreturn_t (*handle_irq)(struct uart_port *port);
 };
 
+/* setting the prescaler and divisor reg is common for all chips */
+static inline void mpc52xx_set_divisor(struct mpc52xx_psc __iomem *psc,
+  u16 prescaler, unsigned int divisor)
+{
+   /* select prescaler */
+   out_be16(&psc->mpc52xx_psc_clock_select, prescaler);
+   out_8(&psc->ctur, divisor >> 8);
+   out_8(&psc->ctlr, divisor & 0xff);
+}
+
 #ifdef CONFIG_PPC_MPC52xx
 #define FIFO_52xx(port) ((struct mpc52xx_psc_fifo __iomem *)(PSC(port)+1))
 static void mpc52xx_psc_fifo_init(struct uart_port *port)
@@ -161,9 +173,6 @@ static void mpc52xx_psc_fifo_init(struct uart_port *port)
struct mpc52xx_psc __iomem *psc = PSC(port);
struct mpc52xx_psc_fifo __iomem *fifo = FIFO_52xx(port);
 
-   /* /32 prescaler */
-   out_be16(&psc->mpc52xx_psc_clock_select, 0xdd00);
-
out_8(&fifo->rfcntl, 0x00);
out_be16(&fifo->rfalarm, 0x1ff);
out_8(&fifo->tfcntl, 0x07);
@@ -252,15 +261,47 @@ static void mpc52xx_psc_cw_restore_ints(struct uart_port 
*port)
out_be16(&PSC(port)->mpc52xx_psc_imr, port->read_status_mask);
 }
 
-/* Search for bus-frequency property in this node or a parent */
-static unsigned long mpc52xx_getuartclk(void *p)
+static unsigned int mpc5200_psc_set_baudrate(struct uart_port *port,
+struct ktermios *new,
+struct ktermios *old)
 {
-   /*
-* 5200 UARTs have a / 32 prescaler
-* but the generic serial code assumes 16
-* so return ipb freq / 2
-*/
-   return mpc5xxx_get_bus_frequency(p) / 2;
+   unsigned int baud;
+   unsigned int divisor;
+
+   /* The 5200 has a fixed /32 prescaler, uartclk contains the ipb freq */
+   baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 32);
+   divisor = (port->uartclk + 16 * baud) / (32 * baud);
+
+   /* enable the /32 prescaler and set the divisor */
+   mpc52xx_set_divisor(PSC(port), 0xdd00, divisor);
+   return baud;
+}
+
+static unsigned int mpc5200b_psc_set_baudrate(struct uart_port *port,
+ struct ktermios *new,
+ struct ktermios *old)
+{
+   unsigned int baud;
+   unsigned int divisor;
+   u16 prescaler;
+
+   /* The 5200B has a selectable /4 or /32 prescaler, uartclk contains the
+* ipb freq */
+   baud = uart_get_baud_rate(port, new, old,
+ port->uartclk / (32 * 0x) + 1,
+ port->uartclk / 4);
+   divisor = (port->uartclk + 2 * baud) / (4 * baud);
+
+   /* select the proper prescaler and set the divisor */
+   if (divisor > 0x) {
+   divisor = (divisor + 4) / 8;
+   prescaler = 0xdd0

Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx

[Albrecht Dreß]

Am 08.07.10 17:22 schrieb(en) Grant Likely:

Just out of curiousity, what configuration might cause a byte-wise alignment 
not to work?


Can't remember the register configuration, but I worked on one project where 
this was the case.  In hindsight, it was probably a mis-configuration of the 
localbus CS for the particular device.


Not sure if you're thinking of this configuration, but if you attach a device 
in 16-bit mode (i.e. 16 data lines) to the LPB, byte writes simply don't work.  
I ran into that problem as I have a nvram attached this way to a 5200b.  Using 
the device as mtd-ram with a jffs2 file system on it I also sometimes saw 
corruption after a write.

I had a patch for that last year, but it was actually badly crafted (see 
).  I 
still use the mpc52xx_memcpy2lpb16() function somewhere in my current code which is 
actually an ugly hack (but it works...).

Actually, this is something which might need closer attention - and maybe some 
support in the device tree indicating which read or write width a device can 
accept?

Best, Albrecht.


pgpQDQ2The7jf.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] arch/powerpc/lib/copy_32.S: Use alternate memcpy for MPC512x and MPC52xx

[Albrecht Dreß]

Am 08.07.10 21:30 schrieb(en) Segher Boessenkool:

Actually, this is something which might need closer attention - and maybe some 
support in the device tree indicating which read or write width a device can 
accept?


There already is "device-width"; the drivers never should use any other access 
width unless they *know* that will work.


Hmm, unfortunately, it's usage is not clearly documented in mtd-physmap.txt, so I never 
thought of this parameter.  And IMHO the problem goes further - basically *any* chip 
which is attached to the LPB can be affected by this problem, so it might be better to 
have a more general approach like a "chip select property".

Cheers, Albrecht.


pgpyhtduU1Hps.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver

[Albrecht Dreß]

Am 05.06.09 14:05 schrieb(en) Wolfram Sang:
Create an of-aware driver using the now exported generic functions  
from plat-ram.c. Also add the documentation for the binding.  
Partitions are not yet supported. Tested on a phyCORE-MPC5200B-IO.


Signed-off-by: Wolfram Sang 
Cc: Albrecht Dreß 
Cc: Grant Likely 
Cc: Ben Dooks 
Cc: David Woodhouse 
Cc: linuxppc-...@ozlabs.org
Cc: devicetree-disc...@ozlabs.org
Cc: linux-...@lists.infradead.org


These patches work great for me on a self-designed, roughly Icecube  
based, 5200B board, with a 512kB NV Ram.  As I use 16-bit accesses via  
the Local Plus bus to the chip, I had to add some more tweaks to other  
files, which I promise to post next week...


Thanks, Albrecht.

Acked-by: Albrecht Dreß 



pgpUZGg1UIpjy.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver

[Albrecht Dreß]

Am 06.06.09 18:05 schrieb(en) Grant Likely:

> + - bank-width : Width (in bytes) of the RAM bank.

Question: why is bank-width even relevant for a RAM device?


At least if the RAM is attached to the 5200's Local Plus Bus in 16-bit  
mode, no byte write accesses are allowed (byte /reads/ work, though).   
I have a tweak (which I will post next week) to address this case,  
which depends upon this setting.  No idea if the same happens on other  
chips and/or on 5200 in 32-bit (muxed) mode, but I guess similar  
effects will pop up there, too.


Cheers, Albrecht.


pgpcv5MnhXQZ1.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver

[Albrecht Dreß]

Am 08.06.09 18:35 schrieb(en) Wolfram Sang:

Question: why is bank-width even relevant for a RAM device?


The underlying map_ram-driver uses it once while erasing. The  
question remains if this is really needed?


Am 06.06.09 18:16 schrieb(en) Albrecht Dreß:
At least if the RAM is attached to the 5200's Local Plus Bus in  
16-bit mode, no byte write accesses are allowed (byte /reads/ work,  
though).  I have a tweak (which I will post next week) to address  
this case, which depends upon this setting.


To put this clearer: on '5200 based systems, the driver (more specific:  
the function inline_map_copy_to()) *must* know whether the hardware is  
connected in 8-bit or 16-bit mode to the Local Plus Bus, as byte writes  
(issued by memcpy_toio()) will fail for the latter setup (probably the  
same applies for byte and word writes in 32-bit mode).


IMHO, this information should be passed using the device tree.  The  
"bank-width" seems to be an obvious choice for that.


Best, Albrecht.


pgph3gL6hLYbg.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus

[Albrecht Dreß]

Hi all,

this patch adds support for RAM chips connected to the Local Plus Bus  
of a MPC5200B in 16-bit mode.  As no single byte write accesses are  
allowed by the bus in this mode, a byte write has to be split into a  
word read - modify - write sequence (mpc52xx_memcpy2lpb16, as  
fix/extension for memcpy_toio; note that memcpy_fromio *does* work just  
fine).  It has been tested in conjunction with Wolfram Sang's mtd-ram  
[1] and Sascha Hauer's jffs unaligned access [2] patches on 2.6.29.1,  
with a Renesas static RAM connected in 16-bit "Large Flash" mode.


[1]  
<http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-June/072794.html>

[2] <http://article.gmane.org/gmane.linux.drivers.mtd/21521>

Signed-off-by: Albrecht Dreß 
Cc: Grant Likely 
Cc: David Woodhouse 
Cc: linuxppc-...@ozlabs.org

---

diff -u  
linux-2.6.29.1.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c  
linux-2.6.29.1/arch/powerpc/platforms/52xx/mpc52xx_common.c
--- linux-2.6.29.1.orig/arch/powerpc/platforms/52xx/mpc52xx_common.c 
2009-04-02 22:55:27.0 +0200
+++ linux-2.6.29.1/arch/powerpc/platforms/52xx/mpc52xx_common.c  
2009-06-09 21:16:22.0 +0200

@@ -225,3 +225,59 @@

while (1);
 }
+
+/**
+ * mpc52xx_memcpy2lpb16: copy data to the Local Plus Bus in 16-bit  
mode which

+ * doesn't allow byte accesses
+ */
+void
+mpc52xx_memcpy2lpb16(volatile void __iomem *dest, const void *src,
+unsigned long n)
+{
+   void *vdest = (void __force *) dest;
+
+   __asm__ __volatile__ ("sync" : : : "memory");
+
+   if (((unsigned long) vdest & 1) != 0) {
+   u8 buf[2];
+
+   *(u16 *)buf = *((volatile u16 *)(vdest - 1));
+   buf[1] = *((u8 *)src);
+   *((volatile u16 *)(vdest - 1)) = *(u16 *)buf;
+   src++;
+   vdest++;
+   n--;
+   }
+
+   /* looks weird, but helps the optimiser... */
+   if (n >= 4) {
+   unsigned long chunks = n >> 2;
+   volatile u32 * _dst = (volatile u32 *)(vdest - 4);
+   volatile u32 * _src = (volatile u32 *)(src - 4);
+
+   vdest += chunks << 2;
+   src += chunks << 2;
+   do {
+   *++_dst = *++_src;
+   } while (--chunks);
+   n &= 3;
+   }
+
+   if (n >= 2) {
+   *((volatile u16 *)vdest) = *((volatile u16 *)src);
+   src += 2;
+   vdest += 2;
+   n -= 2;
+   }
+
+   if (n > 0) {
+   u8 buf[2];
+
+   *(u16 *)buf = *((volatile u16 *)vdest);
+   buf[0] = *((u8 *)src);
+   *((volatile u16 *)vdest) = *(u16 *)buf;
+   }
+
+   __asm__ __volatile__ ("sync" : : : "memory");
+}
+EXPORT_SYMBOL(mpc52xx_memcpy2lpb16);
diff -u linux-2.6.29.1.orig/arch/powerpc/include/asm/mpc52xx.h  
linux-2.6.29.1/arch/powerpc/include/asm/mpc52xx.h
--- linux-2.6.29.1.orig/arch/powerpc/include/asm/mpc52xx.h   
2009-04-02 22:55:27.0 +0200
+++ linux-2.6.29.1/arch/powerpc/include/asm/mpc52xx.h   2009-06-09  
21:14:31.0 +0200

@@ -274,6 +274,8 @@
 extern void mpc52xx_map_common_devices(void);
 extern int mpc52xx_set_psc_clkdiv(int psc_id, int clkdiv);
 extern void mpc52xx_restart(char *cmd);
+extern void mpc52xx_memcpy2lpb16(volatile void __iomem *dest, const  
void *src,

+unsigned long n);

 /* mpc52xx_pic.c */
 extern void mpc52xx_init_irq(void);
diff -u linux-2.6.29.1.orig/include/linux/mtd/map.h  
linux-2.6.29.1/include/linux/mtd/map.h
--- linux-2.6.29.1.orig/include/linux/mtd/map.h 2009-04-02  
22:55:27.0 +0200
+++ linux-2.6.29.1/include/linux/mtd/map.h  2009-06-08  
14:28:05.0 +0200

@@ -13,6 +13,9 @@
 #include 
 #include 
 #include 
+#ifdef CONFIG_PPC_MPC52xx
+#include 
+#endif

 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
 #define map_bankwidth(map) 1
@@ -417,6 +420,11 @@

 static inline void inline_map_copy_to(struct map_info *map, unsigned  
long to, const void *from, ssize_t len)

 {
+#ifdef CONFIG_PPC_MPC52xx
+   if (map->bankwidth == 2)
+   mpc52xx_memcpy2lpb16(map->virt + to, from, len);
+   else
+#endif
memcpy_toio(map->virt + to, from, len);
 }



pgpVaj8YdBwdW.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mpc52xx/mtd: fix mtd-ram access for 16-bit Local Plus Bus

[Albrecht Dreß]

Am 11.06.09 18:27 schrieb(en) Grant Likely:

+               *(u16 *)buf = *((volatile u16 *)(vdest - 1));
+               buf[1] = *((u8 *)src);
+               *((volatile u16 *)(vdest - 1)) = *(u16 *)buf;


what is the purpose of volatile here?  If you need io barriers, then  
use the in_/out_be16 macros.


Yes, you're right - should be completely superfluous here.  A result of  
copy & paste without thinking... :-(


Blech.  ugly #ifdef and not really multiplatform safe (yeah, I know  
it shouldn't break non-5200 platforms, but it does have an  
undesirable impact).  There's got to be a better way.


Ouch, yes - I completely forgot the possibility of multi-platform  
builds.


Am 11.06.09 19:28 schrieb(en) Grant Likely:
So; the solution to me seems to be on an MPC5200 platform replace the  
offending hooks with MPC5200 specific variants at runtime.


Will re-work the patch that way!  BTW, a dumb question: what is the  
proper way to determine which cpu the system is running on?  Check the  
CPU node of the of tree?


Thanks, Albrecht.


pgpK0T238yLSx.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver

[Albrecht Dreß]

Am 05.06.09 14:05 schrieb(en) Wolfram Sang:
Create an of-aware driver using the now exported generic functions  
from plat-ram.c. Also add the documentation for the binding.  
Partitions are not yet supported. Tested on a phyCORE-MPC5200B-IO.


Dumb question: what is the current status of this patch?  I ask because  
I re-wrote my '5200 16-bit Local Plus Bus patch' according to Grant's  
suggestions, and I believe of_ram_probe() of your patch is the right  
place to check if it's attached to "fsl,mpc5200-lpb", and to change the  
write cb if the bankwidth equals 2.


Thanks, Albrecht.


pgpvKEEP7i7Zg.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH V2 2/2] mtd/maps/mtd-ram: add an of-platform driver

[Albrecht Dreß]

Am 16.06.09 14:53 schrieb(en) Grant Likely:
I'm not happy about the use case though.  It probably shouldn't  
appear in this binding, or if it does it should be tagged as an  
optional property.


I agree with you that the naming is really misleading - other devices  
which are not mtd's may suffer from the same problem of the lpb (in my  
case, I have an extra memory-mapped Ethernet chip which I didn't try to  
access yet...).


As it is actually a chip select property, what about defining an  
optional property like "cs-width = (8|16|32)" which defaults to 8 and  
may be added to each 5200 lpb child?


It is only in the 5200 localplus case that bank-width is needed to  
figure out how to apply the workaround.


Just out of curiosity: what about the "localbus" of other Freescale  
chips (82xx? 83xx? Maybe others?)?


Thanks, Albrecht.


pgpLbC13BupnH.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Problem with memcpy on ppc8536

[Albrecht Dreß]

Am 19.06.09 19:06 schrieb(en) Lorenz Kolb:
Could you please try the following patch, I am quite sure that  
checking for > 4 was accidentially done within io.c instead of >= 4  
as if it's 4 we still can copy a 32-bit word. Some hardware might not  
be happy about 8-bit accesses...


I submitted the same patch a while ago, see  
  
and  
,  
maybe you can add a tested/revied for it?


If it is a problem with *byte* accesses, you might want to have a look  
at  
.


Best, Albrecht.


pgp3SiMGPWYf4.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of

[Albrecht Dreß]

Am 17.07.09 14:39 schrieb(en) Wolfram Sang:
Use physmap_of to access RAMs as mtd and add documenation for it.  
This approach is a lot less intrusive as adding an of-wrapper around  
plat-ram.c. As most extensions of plat-ram.c (e.g. custom  
map-functions) can't be mapped to the device tree anyhow, extending  
physmap_of seems to be the cleanest approach.


The patch works nicely on a custom (roughly Icecube) based 5200B board,  
with a Renesas static ram, no partitions and a jffs2 file system on  
it.  I had to add some more tweaks to physmap_of.c as to work around  
the 5200's limitations accessing chips in 16-bit mode through the local  
bus, which is a lot easier and cleaner with this patch than with the  
old one (of 05 June 09).


Acked-by: Albrecht Dreß 


pgplqcxh10c73.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt

[Albrecht Dreß]

In the current code, all MPC5200 timers are registered by the  
mpc52xx_gpt driver, even if gpt0 (the only one with this capability)  
shall be used as hardware watchdog which is indicated by the  
"fsl,has-wdt" or "has-wdt" property in the device tree.  Thus, the  
watchdog driver does never find any watchdog and simply doesn't work.


This trivial patch protects timers with a "(fsl,)?has-wdt" property  
from being probed as gpt's.  The watchdog timer now works just fine.


Tested on a custom (roughly Icecube based) MPC5200B board, with the  
5200 watchdog driver built into the kernel.


Signed-off-by: Albrecht Dreß 

---

--- linux-2.6.30.3.orig/arch/powerpc/platforms/52xx/mpc52xx_gpt.c	 
2009-07-24 23:47:51.0 +0200
+++ linux-2.6.30.3/arch/powerpc/platforms/52xx/mpc52xx_gpt.c	 
2009-08-03 14:20:10.0 +0200

@@ -343,6 +343,14 @@
 {
struct mpc52xx_gpt_priv *gpt;

+   /* do not grab devices which shall be used as watchdog */
+   if (of_get_property(ofdev->node, "fsl,has-wdt", NULL) ||
+   of_get_property(ofdev->node, "has-wdt", NULL)) {
+   pr_notice("%s: ignore wdt %s\n", __func__,
+ ofdev->node->full_name);
+   return -ENODEV;
+   }
+
gpt = kzalloc(sizeof *gpt, GFP_KERNEL);
if (!gpt)
return -ENOMEM;



pgpe9HqkyMwKg.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt

[Albrecht Dreß]

Am 03.08.09 19:50 schrieb(en) Grant Likely:
Just about all mpc5200 device trees have the fsl,has-wdt property on  
GPT0 even when it isn't used as a watchdog.


Sorry, I do not understand...  The file  
Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says



On the mpc5200 and 5200b, GPT0 has a watchdog timer function.  If the  
board design supports the internal wdt, then the device node for GPT0  
should include the empty property 'fsl,has-wdt'.



I interpreted this as "if you don't want to have the wdt function of  
gpt0, remove this property".  If this assumption is wrong, how is the  
kernel supposed to decide if a device shall be used as gpt or as wdt?



The boards using GPT0 as a GPIO or timer will be broken by this patch.


A wdt is a security device which will (IMHO) either not be used as  
such, or it is a *must not* be used for something else on a particular  
board (you may even want u-boot to activate it, e.g. to detect a  
hanging boot process).  In both cases, a "tuned" device tree is needed.


I know it is a lot more work, but the correct solution is to merge  
the GPT watchdog driver into the regular GPT driver so that we don't  
have two device drivers trying to bind against the same device.


I see the benefit of removing some duplicate code and of having gpio  
access in parallel with the wdt, but it wouldn't solve the general  
confusion above!  Will look into that, though...


Best, Albrecht.


pgpcGH5BRaljs.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

MPC5200/BestComm functions question

[Albrecht Dreß]

Hi all,

I have a MPC5200B based system with a 16-bit peripheral attached to the  
Local Bus, and I am looking into possibilities to use BestComm for the  
data transfer.


I found Grant Likely's cool 'mpc5200-localplus-test.c' driver which  
demonstrates this using the 'gen_bd' driver, and which is apparently a  
great starting point.


However, I also have to (a) 32-bit endianess-swap the data and (b)  
calculate a 32-bit crc on it.  Of course, this is possible with the  
buffers using the cpu, but I saw some remarks that the Bestcomm engine  
also includes functions which can perform swapping and crc  
calculation.  I believe it would unload the cpu if the BestComm engine  
could perform these tasks, but I cannot find a good  
documentation/example for that.  Does anyone know any pointers for  
that?  Or maybe even a tool to create the bestcomm tasks from a  
'readable' source?


Thanks in advance,
Albrecht.


pgpdE9qYr3kFR.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: MPC5200/BestComm functions question

[Albrecht Dreß]

Am 12.09.09 16:01 schrieb(en) Grant Likely:

I've actually got a better driver which exports an API for doing  
local plus bus FIFO transfers.  It's been posted to the mailing list  
a couple of times.  I'll cc: you the next time I post it (real soon  
now).


Thanks a lot, that will be really helpful! :-)

Bestcomm can do that, but Freescale has not publically released the  
bestcomm documentation, and they do not support writing custom  
bestcomm tasks.  From what I understand there are a number of hidden  
bugs in the bestcomm engine which you could run into if you deviate  
from the provided tasks.  You're very much on your own if you go down  
that route.  :-(


I see - that's a pity, shifting those tasks to a "coprocessor" sounds  
like an attractive idea!


BTW, I didn't forget about the 5200 GPT/WDT issue, I just didn't have  
the time yet to implement it.  The old work vs. what I would like to do  
conflict, but I will try to find a reasonable solution.


Thanks, Albrecht.


pgpKQ1VDwIUBI.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: lite5200b kernel not booting

[Albrecht Dreß]

Am 25.09.09 14:15 schrieb(en) Jon Smirl:
No one has tried the Macraigor USB wiggler on the mpc5200 and  
reported back if it works.


I'm working on a self-designed, roughly Lite5200B based board, and  
first thought about buying this device.  However, I tried to contact  
their support several times (as to get a confirmation that it will work  
with our flash and board-specific design), but never got a reply.  So  
we ended up with the Abatron BDI3000, which is rather expensive, but  
works really flawlessly, and Abatron's (and their German distributor's)  
support is just *excellent* (fast and professional).


uboot 1.2 is very old. That may be the cause of your problems. For  
example old u-boots don't initialize the PCI hardware correctly on  
systems that don't have PCI implemented.


U-Boot 2009.03 together with ELDK 4.2 work flawlessly on both the  
Lite5200B and on our design.


In general the current powerpc kernel works fine on the mpc5200b. We  
are running it on four different CPU boards but I don't have a  
lite5200b.


I can only confirm that the stock (from kernel.org) kernels run  
flawlessly on our boards (the latest I tried was 2.6.30.3, though, but  
I don't expect any issues with 2.6.31.1).


Hope this helps,
Albrecht.


pgpxaqtJ5Ljpc.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

[Albrecht Dreß]

Hi John:

Cool stuff - Grant's original one also helped me a lot to get Bestcomm  
running for me (I use it only for read dma)!


Am 29.09.09 22:43 schrieb(en) John Bonesio:
[snip]
+		 * It may be worth experimenting with the ALARM value  
to see if
+		 * 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 + LPBFIFO_REG_FIFO_ALARM,  
0x1e4);
+			out_8(lpbfifo.regs + LPBFIFO_REG_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);

+   lpbfifo.bcom_cur_task = lpbfifo.bcom_rx_task;


Hmmm, the MPC5200B User's manual, sect. 9.7.3.3 LPC Rx/Tx FIFO Control  
Register (pg. 323) seems to imply that only 0 or 1 are valid settings  
here.  Where does the 7 come from?


[snip]
+			 * In the DMA read case, the DMA doesn't  
complete,
+			 * possibly due to incorrect watermarks in the  
ALARM
+			 * and CONTROL regs. For now instead of trying  
to
+			 * determine the right watermarks that will  
make this
+			 * work, just increase the number of bytes the  
FIFO is

+* expecting.


My experience is that for reads I have to set a granularity of 0 (as  
you already do) *and* set the 'flush' bit in the SCLPC Control  
Register.  See the remarks for that bit in the MPC5200B User's manual,  
pg. 318.  With these settings and my driver, I made several tests  
reading blocks (in one Bestcomm operation) between 16 bytes and 2  
MBytes, and *never* had any problem, so your remark here makes me  
somewhat nervous!


In my dma read tests, the watermark (LPC Rx/Tx FIFO Alarm Register)  
seems to have only a (small) performance impact.  If I set the  
watermark to 0 (i.e. fill the fifo completely), I *never* saw any  
under- or overruns.  My assumption is that the fifo would stop reading  
the peripheral when it is full, and only resume when Bestcomm emptied  
it at least partly.  You you know if that is really the case?


[snip]

+
+   bit_fields = req->cs << 24 | 0x08;
+   if (!write)
+   bit_fields |= 0x01; /* read mode */


See above - should be "bit_fields |= 0x03" IMHO...

[snip]
+	/* Request the Bestcomm receive (fifo --> memory) task and IRQ  
*/

+   lpbfifo.bcom_rx_task =
+		bcom_gen_bd_rx_init(2, res.start +  
LPBFIFO_REG_FIFO_DATA,
+BCOM_INITIATOR_SCLPC,  
BCOM_IPR_SCLPC,

+   16*1024*1024);


Is the limit really correct?  The manual (sect. 9.7.2.1 SCLPC Packet  
Size Register, pg. 316) says the maximum packet size is 16 M - 1 byte.


Cheers,
Albrecht.


pgprcpybTBzEx.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

[Albrecht Dreß]

Hi John:

Am 01.10.09 20:45 schrieb(en) John Bonesio:
Nowhere in the text does it say 0 and 1 are the only possible values.  
And since GR is a 3 bit field instead of a 1 bit field, that implied  
that to me that other values are allowed.


I can see how one could read the text as saying 0 and 1 are the only  
values allowed. However, empirical the testing I've done, seems to  
indicate that the '7' is a valid value, as it produced different  
behavior than 1.


Thanks for the clarification!

I've put in the suggested change to set the 'flush' bit. It didn't  
seem to help. I'm not sure what else might be different between my  
system and yours.


My board is a self-designed one, roughly Icecube-based, with a 5200B.   
The peripheral (actually a second processor) is attached in 16-bit mode  
to the LPB.  The main data flow goes to the 5200, so I have only a task  
for reading data.  As the block transfer is only one part (but with a  
huge block size) in a transaction, I allocate only one block for the  
task, i.e. I call bcom_gen_bd_rx_init(1, ...).


The transaction size is always a multiple of 4 bytes, and I use the  
same value for the FIFO packet size and struct bcom_bd::status.  In the  
Control reg, I set CS, BPT=4, DAI, RWb and Flush.  I can isolate the  
code launching Bestcomm if you're interested.


I ran some further tests today, which are a little confusing...

When a Bestcomm IRQ arrives, the call to bcom_buffer_done() (in the  
isr) will always return 0.  If I just ignore that, and call  
bcom_retrieve_buffer() anyway, the status value will also be 0.   
However, the data block is transferred completely, and it is correct (I  
separately transmit a crc32, which matches, and the data block itself  
looks fine).  Actually, I'm not really sure what this means...


BTW, I noticed that the Bestcomm IRQ arrives *before* the FIFO IRQ,  
which IMHO is a little unlogical.  It may be a result of setting the  
granularity to 0 and the FIFO Alarm level to 4 (which should trigger  
Bestcomm only if one u32 is free in the FIFO - is that correct?  At  
least the drawing on Pg. 11 in Freescale's AN2604 implies that.).


We were testing using the Bestcomm on a framebuffer to refresh the  
display. Without the watermarks, the DMA was getting clogged.


I see.  In my case, only the /overall/ time and cpu load for the  
transaction are critical, and there I didn't notice significant  
differences.


Cheers,
Albrecht.


pgplZeWfIy57b.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/5200: make BestComm gen_bd microcode exchangeable

[Albrecht Dreß]

This patch adds a method for defining different microcodes than the  
pe-defined ones for the MPC52xx processor's BestComm General Buffer  
Descriptor (gen_db) tasks.  The default microcode is still the one from  
bcom_gen_bd_[rt]x_task, but it can be replaced by calling  
bcom_gen_bd_set_microcode() which is more efficient than explicitly  
loading it via bcom_load_image() after each bcom_gen_bd_[rt]x_reset().


Signed-off-by: Albrecht Dreß 


---


diff -uprN -X linux-2.6.30.3/Documentation/dontdiff  
linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.c  
linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.c
--- linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.c	 
2009-07-24 23:47:51.0 +0200
+++ linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.c	 
2009-10-01 14:26:33.0 +0200

@@ -78,6 +78,7 @@ struct bcom_gen_bd_priv {
int initiator;
int ipr;
int maxbufsize;
+   u32*microcode;
 };


@@ -104,6 +105,7 @@ bcom_gen_bd_rx_init(int queue_len, phys_
priv->initiator  = initiator;
priv->ipr= ipr;
priv->maxbufsize = maxbufsize;
+   priv->microcode = bcom_gen_bd_rx_task;

if (bcom_gen_bd_rx_reset(tsk)) {
bcom_task_free(tsk);
@@ -128,7 +130,7 @@ bcom_gen_bd_rx_reset(struct bcom_task *t
var = (struct bcom_gen_bd_rx_var *) bcom_task_var(tsk->tasknum);
inc = (struct bcom_gen_bd_rx_inc *) bcom_task_inc(tsk->tasknum);

-   if (bcom_load_image(tsk->tasknum, bcom_gen_bd_rx_task))
+   if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;

var->enable  = bcom_eng->regs_base +
@@ -188,6 +190,7 @@ bcom_gen_bd_tx_init(int queue_len, phys_
priv->fifo   = fifo;
priv->initiator  = initiator;
priv->ipr= ipr;
+   priv->microcode = bcom_gen_bd_tx_task;

if (bcom_gen_bd_tx_reset(tsk)) {
bcom_task_free(tsk);
@@ -212,7 +215,7 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
var = (struct bcom_gen_bd_tx_var *) bcom_task_var(tsk->tasknum);
inc = (struct bcom_gen_bd_tx_inc *) bcom_task_inc(tsk->tasknum);

-   if (bcom_load_image(tsk->tasknum, bcom_gen_bd_tx_task))
+   if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;

var->enable  = bcom_eng->regs_base +
@@ -253,6 +256,16 @@ bcom_gen_bd_tx_release(struct bcom_task
 }
 EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_release);

+void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode)
+{
+   struct bcom_gen_bd_priv *priv = tsk->priv;
+
+   priv->microcode = microcode;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_set_microcode);
+
+
 /*  
-

  * PSC support code
  */
diff -uprN -X linux-2.6.30.3/Documentation/dontdiff  
linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.h  
linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.h
--- linux-2.6.30.3.orig/arch/powerpc/sysdev/bestcomm/gen_bd.h	 
2009-07-24 23:47:51.0 +0200
+++ linux-2.6.30.3/arch/powerpc/sysdev/bestcomm/gen_bd.h	 
2009-10-01 14:26:50.0 +0200

@@ -43,6 +43,9 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
 extern void
 bcom_gen_bd_tx_release(struct bcom_task *tsk);

+extern void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode);
+

 /* PSC support utility wrappers */
 struct bcom_task * bcom_psc_gen_bd_rx_init(unsigned psc_num, int  
queue_len,




pgp99g4xgYRjM.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/5200: make BestComm gen_bd microcode exchangeable

[Albrecht Dreß]

Hi Wolfram:

Am 03.10.09 11:44 schrieb(en) Wolfram Sang:

you wrote your own microcode? :)


I modified the bcom_gen_bd_rx_task for a LPB peripheral as to perform  
Endianess swapping during the transfer (works meanwhile :-).
Modifying the standard kernel code for testing seemed to be the wrong  
approach for me, so I wrote that patch...


If possible, I would also like to have a crc32 calculation performed by  
BestComm, but unfortunately there is no documentation and Freescale  
doesn't give any support, so it's all trial and error and error and  
error...  If you have any idea, pointers would be appreciated!



approach looks ok to me in general, but this patch is line-wrapped.


I don't think so - the message body is a "format=flowed" (RFC 3676)  
text/plain part.  Maybe your MUA doesn't display that format correctly  
(Outlook?)?  Or is '3676 in general not acceptable for patches?


[snip]

spaces instead of tabs

[snip]

Two empty lines.


Thanks - will submit a fixed patch next week, stay tuned...

Cheers, Albrecht.


P.S.: Did your mtd-ram/physmap_of patch you submitted a while ago make  
it into the stock kernel?  I have some pending extra work (16-bit LPB  
RAM access) building on top of it...


pgpuZR04a1Z6t.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/5200: make BestComm gen_bd microcode exchangeable

[Albrecht Dreß]

Am 03.10.09 16:40 schrieb(en) Wolfram Sang:
Sorry, I hardly know anything about the microcode. From what I know,  
it shouldn't be much fun due to various bugs in the Bestcomm engine.


Ummm.  That's not encouraging! :-/


Hey! No need for insults! ;)


Sorry, that wasn't my intention, but it's a MUA I *know* it doesn't  
understand it...  most OSS clients do (like Balsa, Thunderbird, kmail,  
etc.).



> Or is '3676 in general not acceptable for patches?

Maybe. Could you try without next time, and we will see if it works  
better?


Actually, it's in Documentation/email-clients.txt - '3676 must not be  
used.  Sorry, should have read that before!  (However, messages  
*without* folding *and* with lines > 78 characters violate RFC2822...)



Yup, since -rc1. (git log --grep=mtd-ram)


Thanks!

Cheers, Albrecht.


pgpabV8sgc1kV.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable

[Albrecht Dreß]

This patch adds a method for defining different microcodes than the pe-defined 
ones for the MPC52xx's BestComm General Buffer Descriptor (gen_db) tasks.  The 
default microcode is still the one from bcom_gen_bd_[rt]x_task, but it can be 
replaced by calling bcom_gen_bd_set_microcode() which is more efficient than 
explicitly loading it via bcom_load_image() after each 
bcom_gen_bd_[rt]x_reset().

Except for a fixed tab vs. space formatting and the transfer format, there are 
no diffierences to the initial attempt.

Signed-off-by: Albrecht Dreß 


---


diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff 
linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.c 
linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.c
--- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.c 2009-10-05 
02:12:30.0 +0200
+++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.c  2009-10-05 
14:52:31.0 +0200
@@ -78,6 +78,7 @@ struct bcom_gen_bd_priv {
int initiator;
int ipr;
int maxbufsize;
+   u32 *microcode;
 };
 
 
@@ -104,6 +105,7 @@ bcom_gen_bd_rx_init(int queue_len, phys_
priv->initiator = initiator;
priv->ipr   = ipr;
priv->maxbufsize = maxbufsize;
+   priv->microcode = bcom_gen_bd_rx_task;
 
if (bcom_gen_bd_rx_reset(tsk)) {
bcom_task_free(tsk);
@@ -128,7 +130,7 @@ bcom_gen_bd_rx_reset(struct bcom_task *t
var = (struct bcom_gen_bd_rx_var *) bcom_task_var(tsk->tasknum);
inc = (struct bcom_gen_bd_rx_inc *) bcom_task_inc(tsk->tasknum);
 
-   if (bcom_load_image(tsk->tasknum, bcom_gen_bd_rx_task))
+   if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;
 
var->enable = bcom_eng->regs_base +
@@ -188,6 +190,7 @@ bcom_gen_bd_tx_init(int queue_len, phys_
priv->fifo  = fifo;
priv->initiator = initiator;
priv->ipr   = ipr;
+   priv->microcode = bcom_gen_bd_tx_task;
 
if (bcom_gen_bd_tx_reset(tsk)) {
bcom_task_free(tsk);
@@ -212,7 +215,7 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
var = (struct bcom_gen_bd_tx_var *) bcom_task_var(tsk->tasknum);
inc = (struct bcom_gen_bd_tx_inc *) bcom_task_inc(tsk->tasknum);
 
-   if (bcom_load_image(tsk->tasknum, bcom_gen_bd_tx_task))
+   if (bcom_load_image(tsk->tasknum, priv->microcode))
return -1;
 
var->enable = bcom_eng->regs_base +
@@ -253,6 +256,15 @@ bcom_gen_bd_tx_release(struct bcom_task 
 }
 EXPORT_SYMBOL_GPL(bcom_gen_bd_tx_release);
 
+void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode)
+{
+   struct bcom_gen_bd_priv *priv = tsk->priv;
+
+   priv->microcode = microcode;
+}
+EXPORT_SYMBOL_GPL(bcom_gen_bd_set_microcode);
+
 /* -
  * PSC support code
  */
diff -uprN -X linux-2.6.32-rc3/Documentation/dontdiff 
linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.h 
linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.h
--- linux-2.6.32-rc3-orig/arch/powerpc/sysdev/bestcomm/gen_bd.h 2009-10-05 
02:12:30.0 +0200
+++ linux-2.6.32-rc3/arch/powerpc/sysdev/bestcomm/gen_bd.h  2009-10-05 
14:52:31.0 +0200
@@ -43,6 +43,9 @@ bcom_gen_bd_tx_reset(struct bcom_task *t
 extern void
 bcom_gen_bd_tx_release(struct bcom_task *tsk);
 
+extern void
+bcom_gen_bd_set_microcode(struct bcom_task *tsk, u32 *microcode);
+
 
 /* PSC support utility wrappers */
 struct bcom_task * bcom_psc_gen_bd_rx_init(unsigned psc_num, int queue_len,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH/v2] powerpc/5200: make BestComm gen_bd microcode exchangeable

[Albrecht Dreß]

Am 05.10.09 20:16 schrieb(en) Grant Likely:

Hmmm.  I've not been comfortable with this change, but it took me a while to 
put my finger on exactly why.  In principle, I think it is a good idea.  
However, I don't want to merge it without any in-tree users.


I could provide my modified microcode (which differs in two words only), for the 
"standard" task, just with byte swapping for the LPB, but I wonder if it is of 
much use.  No progress with crc32 calculation in BestComm so far... :-(


The other concern is that I don't like that the patch is only applicable to 
gen_bd tasks.


IMHO the big difference between gen_bd on one hand and ATA and FEC on the other 
is that (afaik) we have *no* other choice than using the implemented tasks for 
the latter two, obviously using the Freescale's example microcode.  Gen_bd can 
apparently be used for a plenty of purposes, including LPB (as shown in your 
driver), maybe PCI (there are examples in Freescale's code), PSC, etc.  Thus, 
the FEC and ATA drivers should not have an option as to change the microcode, 
whereas it is just convenient for gen_bd.


I've been thinking about this for a while, and I'm not exactly thrilled with the 
bestcomm layout which keeps the bestcomm firmware separate from the only driver 
that actually uses it (ie FEC firmware & support code is separate from the FEC 
driver.  Same for ATA).  I don't like the fact that code which is only ever used by 
the ATA driver is maintained completely separate from it.


That's a good point!  The separate microcode files for ATA and FEC are somewhat 
confusing.  I guess it's a result of simply copying the Freescale examples into 
separate files (and that might be a good reason for keeping the microcode 
separated).  Maybe create new sub-folders below arch/powerpc/sysdev/bestcomm 
for fec, ata, and gen_bd?  At least some documentation would be great.


But I may be splitting hairs here and maybe I shouldn't be too concerned about 
it.  Regardless, I'd think I'd rather see something that isn't totally gen_bd 
specific.  Perhaps *microcode should be part of the bcom_task structure?


See above - I believe FEC and ATA are somewhat special as they need *exactly* 
the provided microcode.  And if something cannot be changed without breaking 
the functionality, there should not be a chance to do so... ;-)

Just my €0.01, though...

Cheers, Albrecht.


pgpCftKGL6brt.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev