* RE: Power PC 440GX Jumbo Packets EMAC2/3
From: zDL Linux PPC @ 2005-02-24 13:12 UTC (permalink / raw)
To: 'Gerhard Jaeger', zML Linux PPC Dev; +Cc: zML Linux PPC Embedded
> On Thursday 24 February 2005 12:46, zDL Linux PPC wrote:
> > I have been doing some experiments with Jumbo packets (MTU
> 9000) and have
> > noticed that once you exceed the 2KB fifo size, I end up
> with no response
> > from the box.
> >
> > I can ping the box with no problem at all at sizes greater
> than 2KB, however
> > upon further investigation I noticed packets of size 2006
> bytes causes no
> > further packet to be transmitted (adding debug prints to
> ibm_emac_core.c,
> > the driver believes the packet has been transmitted), after
> adding a further
> > 42 bytes of header information this comes to the exact size
> of the Transmit
> > Fifo 2048 (2KB). I have also changed the Transmit Fifo
> Register to 1024
> > bytes, this solves the problem at 2006 bytes however now it
> has moved to 982
> > bytes of data (+42bytes of header = 1024)
> >
> > Has anyone else experienced this problem while either using
> a smaller
> > transmit fifo (512 or 1024 bytes) and MTU 1500 or a larger
> MTU (>2033) and
> > EMAC transmit fifo of 2048. I guess this will really apply
> to people with
> > larger MTU not many will decrease the Tx fifo, and I am
> further guessing
> > that not many are using 9000 MTU as not much hardware seems
> to support it, I
> > can only use it through a direct connection between PC's
> and not through a
> > switch!
> >
> > Any suggestions on how to overcome this problem??? My only
> idea is to either
> > add data to the packet (don't think this will work) or
> forceably fragment
> > the packet (if it is 2K in size) to ensure that it never
> uses the exact size
> > of the tx fifo.....
>
> Have you applied Matt Porters patch? It has been submitted at
> the beginning
> of this month?
No I haven't seen it on either of these lists, do you know where I can find
it
Thanks
^ permalink raw reply
* Linuxppc-embedded Digest, Vol 6, Issue 54
From: Srivatsan @ 2005-02-24 12:34 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20050224121917.D60E867A99@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]
Hi,
As I am not sure of the cause of the below mentioned error, I have
mailed this to both uboot and LinuxPPC group.
We are trying to port linux 2.4.20 for the mpc8280 Rattler board. Kernel
boot seems to stop after printing "Now booting the kernel".
But from the log buffer(Starting at 0x194654) dump it looks like it is
well crossing this stage.
The last message that was dumped in the log buffer is:
00194EB4: 3C 34 3E 65 74 68 30 3A 20 63 6F 6E 66 69 67 3A |<4>eth0:
config:|
00194EC4: 20 61 75 74 6F 2D 6E 65 67 6F 74 69 61 74 69 6F | auto-
negotiatio|
00194ED4: 6E 20 6F 6E 2C 20 31 30 30 48 44 58 2C 20 31 30 |n on,
100HDX, 10|
00194EE4: 48 44 58 2E 0A 00 00 00 00 00 00 00 00 00 00 00 |
HDX.............|
00194EF4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
The boot loader used is u-boot.
Any pointers to why messages after "Now booting the kernel" are not
getting on to the console ?.Is it that I am missing some patch?
Thanks everybody for your time.
regards,
C.R.Srivatsan
[-- Attachment #2: Type: text/html, Size: 11525 bytes --]
^ permalink raw reply
* Conole problem on MPC8280 based Rattler board
From: Srivatsan @ 2005-02-24 12:37 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
Hi,
Excuse me for posting this message again. I forgot to change the
subject.
As I am not sure of the cause of the below mentioned error, I have
mailed this to both uboot and LinuxPPC group.
We are trying to port linux 2.4.20 for the mpc8280 Rattler board. Kernel
boot seems to stop after printing "Now booting the kernel".
But from the log buffer(Starting at 0x194654) dump it looks like it is
well crossing this stage.
The last message that was dumped in the log buffer is:
00194EB4: 3C 34 3E 65 74 68 30 3A 20 63 6F 6E 66 69 67 3A |<4>eth0:
config:|
00194EC4: 20 61 75 74 6F 2D 6E 65 67 6F 74 69 61 74 69 6F | auto-
negotiatio|
00194ED4: 6E 20 6F 6E 2C 20 31 30 30 48 44 58 2C 20 31 30 |n on,
100HDX, 10|
00194EE4: 48 44 58 2E 0A 00 00 00 00 00 00 00 00 00 00 00 |
HDX.............|
00194EF4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
The boot loader used is u-boot.
Any pointers to why messages after "Now booting the kernel" are not
getting on to the console ?.Is it that I am missing some patch?
Thanks everybody for your time.
regards,
C.R.Srivatsan
[-- Attachment #2: Type: text/html, Size: 13015 bytes --]
^ permalink raw reply
* Re: Power PC 440GX Jumbo Packets EMAC2/3
From: Gerhard Jaeger @ 2005-02-24 12:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-embedded
In-Reply-To: <C18BA5DDB58DD511BD0700C0DF0DD450294284@NTSERVER4>
On Thursday 24 February 2005 12:46, zDL Linux PPC wrote:
> I have been doing some experiments with Jumbo packets (MTU 9000) and have
> noticed that once you exceed the 2KB fifo size, I end up with no response
> from the box.
>
> I can ping the box with no problem at all at sizes greater than 2KB, however
> upon further investigation I noticed packets of size 2006 bytes causes no
> further packet to be transmitted (adding debug prints to ibm_emac_core.c,
> the driver believes the packet has been transmitted), after adding a further
> 42 bytes of header information this comes to the exact size of the Transmit
> Fifo 2048 (2KB). I have also changed the Transmit Fifo Register to 1024
> bytes, this solves the problem at 2006 bytes however now it has moved to 982
> bytes of data (+42bytes of header = 1024)
>
> Has anyone else experienced this problem while either using a smaller
> transmit fifo (512 or 1024 bytes) and MTU 1500 or a larger MTU (>2033) and
> EMAC transmit fifo of 2048. I guess this will really apply to people with
> larger MTU not many will decrease the Tx fifo, and I am further guessing
> that not many are using 9000 MTU as not much hardware seems to support it, I
> can only use it through a direct connection between PC's and not through a
> switch!
>
> Any suggestions on how to overcome this problem??? My only idea is to either
> add data to the packet (don't think this will work) or forceably fragment
> the packet (if it is 2K in size) to ensure that it never uses the exact size
> of the tx fifo.....
Have you applied Matt Porters patch? It has been submitted at the beginning
of this month?
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de
^ permalink raw reply
* Power PC 440GX Jumbo Packets EMAC2/3
From: zDL Linux PPC @ 2005-02-24 11:46 UTC (permalink / raw)
To: zML Linux PPC Dev; +Cc: zML Linux PPC Embedded
I have been doing some experiments with Jumbo packets (MTU 9000) and have
noticed that once you exceed the 2KB fifo size, I end up with no response
from the box.
I can ping the box with no problem at all at sizes greater than 2KB, however
upon further investigation I noticed packets of size 2006 bytes causes no
further packet to be transmitted (adding debug prints to ibm_emac_core.c,
the driver believes the packet has been transmitted), after adding a further
42 bytes of header information this comes to the exact size of the Transmit
Fifo 2048 (2KB). I have also changed the Transmit Fifo Register to 1024
bytes, this solves the problem at 2006 bytes however now it has moved to 982
bytes of data (+42bytes of header = 1024)
Has anyone else experienced this problem while either using a smaller
transmit fifo (512 or 1024 bytes) and MTU 1500 or a larger MTU (>2033) and
EMAC transmit fifo of 2048. I guess this will really apply to people with
larger MTU not many will decrease the Tx fifo, and I am further guessing
that not many are using 9000 MTU as not much hardware seems to support it, I
can only use it through a direct connection between PC's and not through a
switch!
Any suggestions on how to overcome this problem??? My only idea is to either
add data to the packet (don't think this will work) or forceably fragment
the packet (if it is 2K in size) to ensure that it never uses the exact size
of the tx fifo.....
^ permalink raw reply
* PATCH: mv64x60: add watchdog support
From: James Chapman @ 2005-02-24 11:18 UTC (permalink / raw)
To: Wim Van Sebroeck; +Cc: linuxppc-embedded
In-Reply-To: <20050224074816.GB6650@infomag.infomag.iguana.be>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Wim,
Please review this patch that adds mv64x60 watchdog support.
Signed-off-by: James Chapman <jchapman@katalix.com>
I'm cc'ing linuxppc-embedded to get critical review from developers
who are more likely to know this chip. The Marvell mv64x60 chips are
found on ppc and mips boards.
/james
Wim Van Sebroeck wrote:
> Hi James,
>
>>Are you the Linux watchdog driver maintainer? I have a patch for a new
>>watchdog driver for Marvell Discovery (mv64x60) boards and I'm trying to
>>find the best place to post it...
>>
>>My patch is against the latest 2.6 bk tree. Should I create the patch
>>against a different tree? Is there a mailing list?
>
>
> You can sent it to me and I'll review it and include it in the linux-watchdog bitkeeper tree.
> We actually work first with the -mm tree for testing, after that it goes to linus.
>
> Hope this helps,
> Greetings,
> wim.
[-- Attachment #2: mv64x60_wdt.patch --]
[-- Type: text/plain, Size: 8771 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/24 10:40:40+00:00 jchapman@katalix.com
# Add mv64x60 (Marvell Discovery) watchdog support.
#
# drivers/char/watchdog/mv64x60_wdt.c
# 2005/02/24 10:40:31+00:00 jchapman@katalix.com +252 -0
#
# include/asm-ppc/mv64x60.h
# 2005/02/24 10:40:31+00:00 jchapman@katalix.com +8 -0
# Add mv64x60 (Marvell Discovery) watchdog support.
#
# drivers/char/watchdog/mv64x60_wdt.c
# 2005/02/24 10:40:31+00:00 jchapman@katalix.com +0 -0
# BitKeeper file /home/james/bk/linux-2.6.wdt/drivers/char/watchdog/mv64x60_wdt.c
#
# drivers/char/watchdog/Makefile
# 2005/02/24 10:40:31+00:00 jchapman@katalix.com +1 -0
# Add mv64x60 (Marvell Discovery) watchdog support.
#
# drivers/char/watchdog/Kconfig
# 2005/02/24 10:40:31+00:00 jchapman@katalix.com +4 -0
# Add mv64x60 (Marvell Discovery) watchdog support.
#
diff -Nru a/drivers/char/watchdog/Kconfig b/drivers/char/watchdog/Kconfig
--- a/drivers/char/watchdog/Kconfig 2005-02-24 10:45:36 +00:00
+++ b/drivers/char/watchdog/Kconfig 2005-02-24 10:45:36 +00:00
@@ -346,6 +346,10 @@
tristate "MPC8xx Watchdog Timer"
depends on WATCHDOG && 8xx
+config MV64X60_WDT
+ tristate "MV64X60 (Marvell Discovery) Watchdog Timer"
+ depends on WATCHDOG && MV64X60
+
# MIPS Architecture
config INDYDOG
diff -Nru a/drivers/char/watchdog/Makefile b/drivers/char/watchdog/Makefile
--- a/drivers/char/watchdog/Makefile 2005-02-24 10:45:36 +00:00
+++ b/drivers/char/watchdog/Makefile 2005-02-24 10:45:36 +00:00
@@ -39,3 +39,4 @@
obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
obj-$(CONFIG_IXP2000_WATCHDOG) += ixp2000_wdt.o
obj-$(CONFIG_8xx_WDT) += mpc8xx_wdt.o
+obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
diff -Nru a/drivers/char/watchdog/mv64x60_wdt.c b/drivers/char/watchdog/mv64x60_wdt.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/char/watchdog/mv64x60_wdt.c 2005-02-24 10:45:36 +00:00
@@ -0,0 +1,252 @@
+/*
+ * mv64x60_wdt.c - MV64X60 (Marvell Discovery) watchdog userspace interface
+ *
+ * Author: James Chapman <jchapman@katalix.com>
+ *
+ * Platform-specific setup code should configure the dog to generate
+ * interrupt or reset as required. This code only enables/disables
+ * and services the watchdog.
+ *
+ * Derived from mpc8xx_wdt.c, with the following copyright.
+ *
+ * 2002 (c) Florian Schirmer <jolt@tuxbox.org> This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <linux/config.h>
+#include <linux/fs.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/miscdevice.h>
+#include <linux/module.h>
+#include <linux/watchdog.h>
+#include <asm/mv64x60.h>
+#include <asm/uaccess.h>
+#include <asm/io.h>
+
+/* MV64x60 WDC (config) register access definitions */
+#define MV64x60_WDC_CTL1_MASK (3 << 24)
+#define MV64x60_WDC_CTL1(val) ((val & 3) << 24)
+#define MV64x60_WDC_CTL2_MASK (3 << 26)
+#define MV64x60_WDC_CTL2(val) ((val & 3) << 26)
+
+/* Flags bits */
+#define MV64x60_WDOG_FLAG_OPENED 0
+#define MV64x60_WDOG_FLAG_ENABLED 1
+
+static unsigned long wdt_flags;
+static int wdt_status;
+static void __iomem *mv64x60_regs;
+static int mv64x60_wdt_timeout;
+
+static void mv64x60_wdt_reg_write(u32 val)
+{
+ /* Allow write only to CTL1 / CTL2 fields, retaining values in
+ * other fields.
+ */
+ u32 data = readl(mv64x60_regs + MV64x60_WDT_WDC);
+ data &= ~(MV64x60_WDC_CTL1_MASK | MV64x60_WDC_CTL2_MASK);
+ data |= val;
+ writel(data, mv64x60_regs + MV64x60_WDT_WDC);
+}
+
+static void mv64x60_wdt_service(void)
+{
+ /* Write 01 followed by 10 to CTL2 */
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL2(0x01));
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL2(0x02));
+}
+
+static void mv64x60_wdt_handler_disable(void)
+{
+ if (test_and_clear_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags)) {
+ /* Write 01 followed by 10 to CTL1 */
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x01));
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x02));
+ printk(KERN_NOTICE "mv64x60_wdt: watchdog deactivated\n");
+ }
+}
+
+static void mv64x60_wdt_handler_enable(void)
+{
+ if (!test_and_set_bit(MV64x60_WDOG_FLAG_ENABLED, &wdt_flags)) {
+ /* Write 01 followed by 10 to CTL1 */
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x01));
+ mv64x60_wdt_reg_write(MV64x60_WDC_CTL1(0x02));
+ printk(KERN_NOTICE "mv64x60_wdt: watchdog activated\n");
+ }
+}
+
+static int mv64x60_wdt_open(struct inode *inode, struct file *file)
+{
+ if (test_and_set_bit(MV64x60_WDOG_FLAG_OPENED, &wdt_flags))
+ return -EBUSY;
+
+ mv64x60_wdt_service();
+ mv64x60_wdt_handler_enable();
+
+ return 0;
+}
+
+static int mv64x60_wdt_release(struct inode *inode, struct file *file)
+{
+ mv64x60_wdt_service();
+
+#if !defined(CONFIG_WATCHDOG_NOWAYOUT)
+ mv64x60_wdt_handler_disable();
+#endif
+
+ clear_bit(MV64x60_WDOG_FLAG_OPENED, &wdt_flags);
+
+ return 0;
+}
+
+static ssize_t mv64x60_wdt_write(struct file *file, const char *data,
+ size_t len, loff_t * ppos)
+{
+ if (*ppos != file->f_pos)
+ return -ESPIPE;
+
+ if (len)
+ mv64x60_wdt_service();
+
+ return len;
+}
+
+static int mv64x60_wdt_ioctl(struct inode *inode, struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+ int timeout;
+ static struct watchdog_info info = {
+ .options = WDIOF_KEEPALIVEPING,
+ .firmware_version = 0,
+ .identity = "MV64x60 watchdog",
+ };
+
+ switch (cmd) {
+ case WDIOC_GETSUPPORT:
+ if (copy_to_user((void *)arg, &info, sizeof(info)))
+ return -EFAULT;
+ break;
+
+ case WDIOC_GETSTATUS:
+ case WDIOC_GETBOOTSTATUS:
+ if (put_user(wdt_status, (int *)arg))
+ return -EFAULT;
+ wdt_status &= ~WDIOF_KEEPALIVEPING;
+ break;
+
+ case WDIOC_GETTEMP:
+ return -EOPNOTSUPP;
+
+ case WDIOC_SETOPTIONS:
+ return -EOPNOTSUPP;
+
+ case WDIOC_KEEPALIVE:
+ mv64x60_wdt_service();
+ wdt_status |= WDIOF_KEEPALIVEPING;
+ break;
+
+ case WDIOC_SETTIMEOUT:
+ return -EOPNOTSUPP;
+
+ case WDIOC_GETTIMEOUT:
+ timeout = mv64x60_wdt_timeout * HZ;
+ if (put_user(timeout, (int *)arg))
+ return -EFAULT;
+ break;
+
+ default:
+ return -ENOIOCTLCMD;
+ }
+
+ return 0;
+}
+
+static struct file_operations mv64x60_wdt_fops = {
+ .owner = THIS_MODULE,
+ .llseek = no_llseek,
+ .write = mv64x60_wdt_write,
+ .ioctl = mv64x60_wdt_ioctl,
+ .open = mv64x60_wdt_open,
+ .release = mv64x60_wdt_release,
+};
+
+static struct miscdevice mv64x60_wdt_miscdev = {
+ .minor = WATCHDOG_MINOR,
+ .name = "watchdog",
+ .fops = &mv64x60_wdt_fops,
+};
+
+static int __devinit mv64x60_wdt_probe(struct device *dev)
+{
+ struct platform_device *pd = to_platform_device(dev);
+ struct mv64x60_wdt_pdata *pdata = pd->dev.platform_data;
+ int bus_clk = 133;
+
+ mv64x60_wdt_timeout = 10;
+ if (pdata) {
+ mv64x60_wdt_timeout = pdata->timeout;
+ bus_clk = pdata->bus_clk;
+ }
+
+ mv64x60_regs = mv64x60_get_bridge_vbase();
+
+ writel((mv64x60_wdt_timeout * (bus_clk * 1000000)) >> 8,
+ mv64x60_regs + MV64x60_WDT_WDC);
+
+ return misc_register(&mv64x60_wdt_miscdev);
+}
+
+static int __devexit mv64x60_wdt_remove(struct device *dev)
+{
+ misc_deregister(&mv64x60_wdt_miscdev);
+
+ mv64x60_wdt_service();
+ mv64x60_wdt_handler_disable();
+
+ return 0;
+}
+
+static struct device_driver mv64x60_wdt_driver = {
+ .name = MV64x60_WDT_NAME,
+ .bus = &platform_bus_type,
+ .probe = mv64x60_wdt_probe,
+ .remove = __devexit_p(mv64x60_wdt_remove),
+};
+
+static struct platform_device *mv64x60_wdt_dev;
+
+static int __init mv64x60_wdt_init(void)
+{
+ int ret;
+
+ printk(KERN_INFO "MV64x60 watchdog driver\n");
+
+ mv64x60_wdt_dev = platform_device_register_simple(MV64x60_WDT_NAME,
+ -1, NULL, 0);
+ if (IS_ERR(mv64x60_wdt_dev)) {
+ ret = PTR_ERR(mv64x60_wdt_dev);
+ goto out;
+ }
+
+ ret = driver_register(&mv64x60_wdt_driver);
+ out:
+ return ret;
+}
+
+static void __exit mv64x60_wdt_exit(void)
+{
+ driver_unregister(&mv64x60_wdt_driver);
+ platform_device_unregister(mv64x60_wdt_dev);
+}
+
+module_init(mv64x60_wdt_init);
+module_exit(mv64x60_wdt_exit);
+
+MODULE_AUTHOR("James Chapman <jchapman@katalix.com>");
+MODULE_DESCRIPTION("MV64x60 watchdog driver");
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_MISCDEV(WATCHDOG_MINOR);
diff -Nru a/include/asm-ppc/mv64x60.h b/include/asm-ppc/mv64x60.h
--- a/include/asm-ppc/mv64x60.h 2005-02-24 10:45:36 +00:00
+++ b/include/asm-ppc/mv64x60.h 2005-02-24 10:45:36 +00:00
@@ -119,6 +119,14 @@
#define MV64x60_64BIT_WIN_COUNT 24
+/* Watchdog Platform Device, Driver Data */
+#define MV64x60_WDT_NAME "wdt"
+
+struct mv64x60_wdt_pdata {
+ int timeout; /* watchdog expiry in seconds, default 10 */
+ int bus_clk; /* bus clock in MHz, default 133 */
+};
+
/*
* Define a structure that's used to pass in config information to the
* core routines.
^ permalink raw reply
* Re: PATCH: add mv64x60 GPP IO pin/IRQ register definitions
From: James Chapman @ 2005-02-24 9:37 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20050223222637.GN345@smtp.west.cox.net>
[-- Attachment #1: Type: text/plain, Size: 376 bytes --]
New version with whitespace fixed is attached. My mv64360 pic patch must
be applied first.
Tom Rini wrote:
> On Wed, Feb 23, 2005 at 08:59:14PM +0000, James Chapman wrote:
>
>
>>Add mv64x60 GPP IO pin/IRQ register definitions
>
>
> [snip]
>
>> #define MV64x60_IRQ_TIMER_6_7 11
>>+#define MV64x60_IRQ_P1_GPP_0_7 24
>
>
> Please use consistent spacing. Thanks.
>
[-- Attachment #2: mv64x60_gpp_defs.patch --]
[-- Type: text/plain, Size: 2400 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/23 16:14:11+00:00 jchapman@katalix.com
# Add mv64x60 GPP IO pin/IRQ register definitions.
#
# include/asm-ppc/mv64x60_defs.h
# 2005/02/23 16:14:03+00:00 jchapman@katalix.com +41 -0
# Add mv64x60 GPP IO pin/IRQ register definitions.
#
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:14:56 +00:00
+++ b/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:14:56 +00:00
@@ -43,6 +43,10 @@
#define MV64x60_IRQ_TIMER_2_3 9
#define MV64x60_IRQ_TIMER_4_5 10
#define MV64x60_IRQ_TIMER_6_7 11
+#define MV64x60_IRQ_P1_GPP_0_7 24
+#define MV64x60_IRQ_P1_GPP_8_15 25
+#define MV64x60_IRQ_P1_GPP_16_23 26
+#define MV64x60_IRQ_P1_GPP_24_31 27
#define MV64x60_IRQ_DOORBELL 28
#define MV64x60_IRQ_ETH_0 32
#define MV64x60_IRQ_ETH_1 33
@@ -53,11 +57,48 @@
#define MV64x60_IRQ_MPSC_0 40
#define MV64x60_IRQ_MPSC_1 42
#define MV64x60_IRQ_COMM 43
+#define MV64x60_IRQ_P0_GPP_0_7 56
+#define MV64x60_IRQ_P0_GPP_8_15 57
+#define MV64x60_IRQ_P0_GPP_16_23 58
+#define MV64x60_IRQ_P0_GPP_24_31 59
#define MV64360_IRQ_PCI0 12
#define MV64360_IRQ_SRAM_PAR_ERR 13
#define MV64360_IRQ_PCI1 16
#define MV64360_IRQ_SDMA_1 38
+
+#define MV64x60_IRQ_GPP0 64
+#define MV64x60_IRQ_GPP1 65
+#define MV64x60_IRQ_GPP2 66
+#define MV64x60_IRQ_GPP3 67
+#define MV64x60_IRQ_GPP4 68
+#define MV64x60_IRQ_GPP5 69
+#define MV64x60_IRQ_GPP6 70
+#define MV64x60_IRQ_GPP7 71
+#define MV64x60_IRQ_GPP8 72
+#define MV64x60_IRQ_GPP9 73
+#define MV64x60_IRQ_GPP10 74
+#define MV64x60_IRQ_GPP11 75
+#define MV64x60_IRQ_GPP12 76
+#define MV64x60_IRQ_GPP13 77
+#define MV64x60_IRQ_GPP14 78
+#define MV64x60_IRQ_GPP15 79
+#define MV64x60_IRQ_GPP16 80
+#define MV64x60_IRQ_GPP17 81
+#define MV64x60_IRQ_GPP18 82
+#define MV64x60_IRQ_GPP19 83
+#define MV64x60_IRQ_GPP20 84
+#define MV64x60_IRQ_GPP21 85
+#define MV64x60_IRQ_GPP22 86
+#define MV64x60_IRQ_GPP23 87
+#define MV64x60_IRQ_GPP24 88
+#define MV64x60_IRQ_GPP25 89
+#define MV64x60_IRQ_GPP26 90
+#define MV64x60_IRQ_GPP27 91
+#define MV64x60_IRQ_GPP28 92
+#define MV64x60_IRQ_GPP29 93
+#define MV64x60_IRQ_GPP30 94
+#define MV64x60_IRQ_GPP31 95
/* Offsets for register blocks */
#define GT64260_ENET_PHY_ADDR 0x2000
^ permalink raw reply
* Re: PATCH: fix mv64360 pic code to handle non-zero mv64x60_irq_base
From: James Chapman @ 2005-02-24 9:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <421CED8F.6040300@katalix.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
Resubmitting mv64360_pic patch with fixed whitespace in my
mv64x60_defs.h change.
James Chapman wrote:
> New version of patch addressing Mark Greer's comments.
>
> - Fix mv64360 pic code to handle non-zero mv64x60_irq_base
> - Cleanup mv64360 entries in /proc/interrupts
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
>
[-- Attachment #2: mv64360_pic.patch --]
[-- Type: text/plain, Size: 4579 bytes --]
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2005/02/23 16:01:12+00:00 jchapman@katalix.com
# Fix mv64360 pic to handle non-zero IRQ offset.
# Cleanup /proc/interrupts.
#
# include/asm-ppc/mv64x60_defs.h
# 2005/02/23 16:01:02+00:00 jchapman@katalix.com +1 -0
# Add #define for doorbell interrupt bit value (28).
#
# arch/ppc/syslib/mv64360_pic.c
# 2005/02/23 16:01:02+00:00 jchapman@katalix.com +17 -12
# Cleanup /proc/interrupts output to make mv64360 entries line up.
# Use #define for dorrbell interrupt bit (28).
# Fix several bugs to do with non-zero mv64360_irq_base.
#
diff -Nru a/arch/ppc/syslib/mv64360_pic.c b/arch/ppc/syslib/mv64360_pic.c
--- a/arch/ppc/syslib/mv64360_pic.c 2005-02-23 16:07:02 +00:00
+++ b/arch/ppc/syslib/mv64360_pic.c 2005-02-23 16:07:02 +00:00
@@ -64,7 +64,7 @@
/* ========================== local declarations =========================== */
struct hw_interrupt_type mv64360_pic = {
- .typename = " mv64360_pic ",
+ .typename = " mv64360 ",
.enable = mv64360_unmask_irq,
.disable = mv64360_mask_irq,
.ack = mv64360_mask_irq,
@@ -155,9 +155,10 @@
*/
int cpu_nr = smp_processor_id();
if (cpu_nr == 1) {
- if (!(mv64x60_read(&bh, MV64360_IC_MAIN_CAUSE_LO) & (1 << 28)))
+ if (!(mv64x60_read(&bh, MV64360_IC_MAIN_CAUSE_LO) &
+ (1 << MV64x60_IRQ_DOORBELL)))
return -1;
- return 28;
+ return mv64360_irq_base + MV64x60_IRQ_DOORBELL;
}
#endif
@@ -171,7 +172,7 @@
if (irq == -1)
irq = -2; /* bogus interrupt, should never happen */
else {
- if ((irq >= 24) && (irq < 28)) {
+ if ((irq >= 24) && (irq < MV64x60_IRQ_DOORBELL)) {
irq_gpp = mv64x60_read(&bh,
MV64x60_GPP_INTR_CAUSE);
irq_gpp = __ilog2(irq_gpp &
@@ -217,8 +218,9 @@
{
#ifdef CONFIG_SMP
/* second CPU gets only doorbell interrupts */
- if ((irq - mv64360_irq_base) == 28) {
- mv64x60_set_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO, (1 << 28));
+ if ((irq - mv64360_irq_base) == MV64x60_IRQ_DOORBELL) {
+ mv64x60_set_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO,
+ (1 << MV64x60_IRQ_DOORBELL));
return;
}
#endif
@@ -257,8 +259,9 @@
mv64360_mask_irq(unsigned int irq)
{
#ifdef CONFIG_SMP
- if ((irq - mv64360_irq_base) == 28) {
- mv64x60_clr_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO, (1 << 28));
+ if ((irq - mv64360_irq_base) == MV64x60_IRQ_DOORBELL) {
+ mv64x60_clr_bits(&bh, MV64360_IC_CPU1_INTR_MASK_LO,
+ (1 << MV64x60_IRQ_DOORBELL));
return;
}
#endif
@@ -371,7 +374,7 @@
/* Clear old errors and register CPU interface error intr handler */
mv64x60_write(&bh, MV64x60_CPU_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64x60_IRQ_CPU_ERR,
+ if ((rc = request_irq(MV64x60_IRQ_CPU_ERR + mv64360_irq_base,
mv64360_cpu_error_int_handler, SA_INTERRUPT, CPU_INTR_STR, 0)))
printk(KERN_WARNING "Can't register cpu error handler: %d", rc);
@@ -380,7 +383,7 @@
/* Clear old errors and register internal SRAM error intr handler */
mv64x60_write(&bh, MV64360_SRAM_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR,
+ if ((rc = request_irq(MV64360_IRQ_SRAM_PAR_ERR + mv64360_irq_base,
mv64360_sram_error_int_handler,SA_INTERRUPT,SRAM_INTR_STR, 0)))
printk(KERN_WARNING "Can't register SRAM error handler: %d",rc);
@@ -397,7 +400,8 @@
/* Clear old errors and register PCI 0 error intr handler */
mv64x60_write(&bh, MV64x60_PCI0_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_PCI0, mv64360_pci_error_int_handler,
+ if ((rc = request_irq(MV64360_IRQ_PCI0 + mv64360_irq_base,
+ mv64360_pci_error_int_handler,
SA_INTERRUPT, PCI0_INTR_STR, (void *)0)))
printk(KERN_WARNING "Can't register pci 0 error handler: %d",
rc);
@@ -407,7 +411,8 @@
/* Clear old errors and register PCI 1 error intr handler */
mv64x60_write(&bh, MV64x60_PCI1_ERR_CAUSE, 0);
- if ((rc = request_irq(MV64360_IRQ_PCI1, mv64360_pci_error_int_handler,
+ if ((rc = request_irq(MV64360_IRQ_PCI1 + mv64360_irq_base,
+ mv64360_pci_error_int_handler,
SA_INTERRUPT, PCI1_INTR_STR, (void *)1)))
printk(KERN_WARNING "Can't register pci 1 error handler: %d",
rc);
diff -Nru a/include/asm-ppc/mv64x60_defs.h b/include/asm-ppc/mv64x60_defs.h
--- a/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:07:02 +00:00
+++ b/include/asm-ppc/mv64x60_defs.h 2005-02-23 16:07:02 +00:00
@@ -43,6 +43,7 @@
#define MV64x60_IRQ_TIMER_2_3 9
#define MV64x60_IRQ_TIMER_4_5 10
#define MV64x60_IRQ_TIMER_6_7 11
+#define MV64x60_IRQ_DOORBELL 28
#define MV64x60_IRQ_ETH_0 32
#define MV64x60_IRQ_ETH_1 33
#define MV64x60_IRQ_ETH_2 34
^ permalink raw reply
* Re: PATCH: add ppc PVR register values for 7447A and 7457 CPUs
From: James Chapman @ 2005-02-24 9:01 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050223222534.GM345@smtp.west.cox.net>
Tom Rini wrote:
> On Wed, Feb 23, 2005 at 08:48:25PM +0000, James Chapman wrote:
>
>>Signed-off-by: James Chapman <jchapman@katalix.com>
>>
>>Trivial patch to add 7447A and 7457 CPU defs.
>
>
> Why? Most of the PVR definitions here can be removed (*muttering about
> 85xx ones being added).
>
I'm in the process of submitting a patch for a new board (Radstone
PPC7D). Since other boards test CPU type using definitions in this file,
I was trying to be consistent.
If the community don't think those definitions are useful, I'll just
move the ones I need into my board support stuff.
--
James Chapman
PGP key : http://www.katalix.com/~jchapman/pgpkey.txt
^ permalink raw reply
* [PATCH] Non-DMA mode for floppy on PowerPC, new version
From: Pavel Fedin @ 2005-02-24 16:53 UTC (permalink / raw)
To: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
Here is a cleaned up version of my 2.6.8 kernel patch.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC and AmigaOne machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type here using floppy=<Drive number>,<Drive type>,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system. Default drive type is 2.88 mb.
This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
[-- Attachment #2: ppc_floppy-vdma.diff --]
[-- Type: text/plain, Size: 4957 bytes --]
--- linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h.orig 2004-08-14 06:55:10.000000000 -0400
+++ linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h 2005-02-24 09:41:54.594830800 -0500
@@ -11,30 +11,163 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include <linux/vmalloc.h>
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port) outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma() disable_dma(FLOPPY_DMA)
-#define fd_request_dma() request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma() CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue() CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ unsigned char st;
+
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+ {
+ int lcount;
+ char *lptr;
+
+ st = 1;
+ for (lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if (st != 0xa0)
+ break;
+ if (virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+ if (st == 0x20)
+ return IRQ_HANDLED;
+ if (!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if (can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+ SA_INTERRUPT|SA_SAMPLE_RANDOM,
+ "floppy", NULL);
+
+}
+
+static unsigned long dma_mem_alloc(unsigned long size)
+{
+ return __get_dma_pages(GFP_KERNEL,get_order(size));
+}
+
+
+static unsigned long vdma_mem_alloc(unsigned long size)
+{
+ return __get_free_pages(GFP_KERNEL,get_order(size));
+}
+
+static int vdma_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ doing_pdma = 1;
+ virtual_dma_port = io;
+ virtual_dma_mode = (mode == DMA_MODE_WRITE);
+ virtual_dma_addr = addr;
+ virtual_dma_count = size;
+ virtual_dma_residue = 0;
+ return 0;
+}
+
+static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ /* actual, physical DMA */
+ doing_pdma = 0;
+ clear_dma_ff(FLOPPY_DMA);
+ set_dma_mode(FLOPPY_DMA,mode);
+ set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr));
+ set_dma_count(FLOPPY_DMA,size);
+ enable_dma(FLOPPY_DMA);
+ return 0;
+}
+
+struct fd_routine_l {
+ void (*_disable_dma)(unsigned int dmanr);
+ int (*_request_dma)(unsigned int dmanr, const char * device_id);
+ void (*_free_dma)(unsigned int dmanr);
+ int (*_get_dma_residue)(unsigned int dummy);
+ unsigned long (*_dma_mem_alloc) (unsigned long size);
+ int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
+} fd_routine[] = {
+ {
+ disable_dma,
+ request_dma,
+ free_dma,
+ get_dma_residue,
+ dma_mem_alloc,
+ hard_dma_setup
+ },
+ {
+ vdma_disable_dma,
+ vdma_request_dma,
+ vdma_nop,
+ vdma_get_dma_residue,
+ vdma_mem_alloc,
+ vdma_dma_setup
+ }
+};
+
static int FDC1 = 0x3f0;
static int FDC2 = -1;
^ permalink raw reply
* Re: [PATCH][PPC32] mv64x60 updates
From: Sven Luther @ 2005-02-24 8:25 UTC (permalink / raw)
To: Mark A. Greer; +Cc: nd, Embedded PPC Linux list
In-Reply-To: <41F6E0E1.6000803@mvista.com>
On Tue, Jan 25, 2005 at 05:14:25PM -0700, Mark A. Greer wrote:
> Hi Andrew.
>
> This patch briges the mv64x60 related code up to the latest that I have.
Mark, ...
I am a bit bewildered by what you are doing here. How does this mv64x60 code
relate to the mv643xx_eth driver from the mips folk ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
From: Sven Luther @ 2005-02-24 7:47 UTC (permalink / raw)
To: Meelis Roos
Cc: Tom Rini, Sven Hartge, Kernel Mailing List, Christian Kujau,
linuxppc-dev
In-Reply-To: <Pine.SOC.4.61.0502221031230.6097@math.ut.ee>
On Tue, Feb 22, 2005 at 10:36:36AM +0200, Meelis Roos wrote:
> >The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was
> >incorrect, but this breakage wasn't exposed until 2.5, and finally fixed
> >until recently by Sebastian Heutling <sheutlin@gmx.de>.
>
> Yesterday I finally got around to testing it. It seems the patch has
> been applied in Linus's tree so I downloaded the latest BK and tried it.
>
> Still does not work for me but this time it's different. Before the
> patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI
> NICs because even the onboard 53c825 SCSI hangs - seems it gets no
> interrupts.
>
> It detects the HBA, tries device discovery, gets a timeout, ABORT,
> timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and there
> it hangs.
>
> Does it work for anyone else on Powerstack II Pro4000 (Utah)?
Can you try :
http://people.debian.org/~luther/d-i/images/daily/powerpc/netboot/vmlinuz-prep.initrd
It works for me, and the kernel (2.6.8) has the irqs patched, but not the scsi
stuff touched, i think.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] Non-DMA mode for floppy on PowerPC, new version
From: Pavel Fedin @ 2005-02-24 15:30 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
Here is a cleaned up version of my 2.6.8 kernel patch.
This patch allows to use floppy drive in non-DMA mode on PegasosPPC and AmigaOne machines. To use it:
1. Do not build floppy driver as a module, link it statically. Transferring parameters to it from insmod is still problematic, at least it doesn't work properly on my system. May be i'll clean it up in future.
2. Specify floppy=nodma in kernel's arguments. Also you'll need to specify your drive type here using floppy=<Drive number>,<Drive type>,cmos. For example, floppy=0,4,cmos specifies type 4 (1.44 mb 3.5") for drive 0 on my system. Default drive type is 2.88 mb.
This patch does not affect operation of the driver in DMA mode so it's safe to use on any platform.
--
Best regards,
Pavel Fedin, mailto:sonic_amiga@rambler.ru
[-- Attachment #2: ppc_floppy-vdma.diff --]
[-- Type: text/plain, Size: 5137 bytes --]
--- linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h.orig 2004-08-14 06:55:10.000000000 -0400
+++ linux-2.6.8.1-10mdk/include/asm-ppc/floppy.h 2005-02-24 09:41:54.594830800 -0500
@@ -11,30 +11,163 @@
#ifndef __ASM_PPC_FLOPPY_H
#define __ASM_PPC_FLOPPY_H
+#include <linux/vmalloc.h>
+
+#define CSW fd_routine[can_use_virtual_dma & 1]
+
#define fd_inb(port) inb_p(port)
#define fd_outb(value,port) outb_p(value,port)
-#define fd_enable_dma() enable_dma(FLOPPY_DMA)
-#define fd_disable_dma() disable_dma(FLOPPY_DMA)
-#define fd_request_dma() request_dma(FLOPPY_DMA,"floppy")
-#define fd_free_dma() free_dma(FLOPPY_DMA)
-#define fd_clear_dma_ff() clear_dma_ff(FLOPPY_DMA)
-#define fd_set_dma_mode(mode) set_dma_mode(FLOPPY_DMA,mode)
-#define fd_set_dma_addr(addr) set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr))
-#define fd_set_dma_count(count) set_dma_count(FLOPPY_DMA,count)
+#define fd_disable_dma() CSW._disable_dma(FLOPPY_DMA)
+#define fd_request_dma() CSW._request_dma(FLOPPY_DMA,"floppy")
+#define fd_free_dma() CSW._free_dma(FLOPPY_DMA)
+#define fd_get_dma_residue() CSW._get_dma_residue(FLOPPY_DMA)
+#define fd_dma_mem_alloc(size) CSW._dma_mem_alloc(size)
+#define fd_dma_setup(addr, size, mode, io) CSW._dma_setup(addr, size, mode, io)
#define fd_enable_irq() enable_irq(FLOPPY_IRQ)
#define fd_disable_irq() disable_irq(FLOPPY_IRQ)
-#define fd_cacheflush(addr,size) /* nothing */
-#define fd_request_irq() request_irq(FLOPPY_IRQ, floppy_interrupt, \
- SA_INTERRUPT|SA_SAMPLE_RANDOM, \
- "floppy", NULL)
#define fd_free_irq() free_irq(FLOPPY_IRQ, NULL);
-__inline__ void virtual_dma_init(void)
+static int virtual_dma_count;
+static int virtual_dma_residue;
+static char *virtual_dma_addr;
+static int virtual_dma_mode;
+static int doing_pdma;
+
+static irqreturn_t floppy_hardint(int irq, void *dev_id, struct pt_regs * regs)
+{
+ unsigned char st;
+
+ if (!doing_pdma)
+ return floppy_interrupt(irq, dev_id, regs);
+
+ {
+ int lcount;
+ char *lptr;
+
+ st = 1;
+ for (lcount=virtual_dma_count, lptr=virtual_dma_addr;
+ lcount; lcount--, lptr++) {
+ st=inb(virtual_dma_port+4) & 0xa0 ;
+ if (st != 0xa0)
+ break;
+ if (virtual_dma_mode)
+ outb_p(*lptr, virtual_dma_port+5);
+ else
+ *lptr = inb_p(virtual_dma_port+5);
+ }
+ virtual_dma_count = lcount;
+ virtual_dma_addr = lptr;
+ st = inb(virtual_dma_port+4);
+ }
+
+ if (st == 0x20)
+ return IRQ_HANDLED;
+ if (!(st & 0x20)) {
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
+ doing_pdma = 0;
+ floppy_interrupt(irq, dev_id, regs);
+ return IRQ_HANDLED;
+ }
+ return IRQ_HANDLED;
+}
+
+static void vdma_disable_dma(unsigned int dummy)
{
- /* Nothing to do on PowerPC */
+ doing_pdma = 0;
+ virtual_dma_residue += virtual_dma_count;
+ virtual_dma_count=0;
}
+static int vdma_request_dma(unsigned int dmanr, const char * device_id)
+{
+ return 0;
+}
+
+static void vdma_nop(unsigned int dummy)
+{
+}
+
+
+static int vdma_get_dma_residue(unsigned int dummy)
+{
+ return virtual_dma_count + virtual_dma_residue;
+}
+
+
+static int fd_request_irq(void)
+{
+ if (can_use_virtual_dma)
+ return request_irq(FLOPPY_IRQ, floppy_hardint,SA_INTERRUPT,
+ "floppy", NULL);
+ else
+ return request_irq(FLOPPY_IRQ, floppy_interrupt,
+ SA_INTERRUPT|SA_SAMPLE_RANDOM,
+ "floppy", NULL);
+
+}
+
+static unsigned long dma_mem_alloc(unsigned long size)
+{
+ return __get_dma_pages(GFP_KERNEL,get_order(size));
+}
+
+
+static unsigned long vdma_mem_alloc(unsigned long size)
+{
+ return __get_free_pages(GFP_KERNEL,get_order(size));
+}
+
+static int vdma_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ doing_pdma = 1;
+ virtual_dma_port = io;
+ virtual_dma_mode = (mode == DMA_MODE_WRITE);
+ virtual_dma_addr = addr;
+ virtual_dma_count = size;
+ virtual_dma_residue = 0;
+ return 0;
+}
+
+static int hard_dma_setup(char *addr, unsigned long size, int mode, int io)
+{
+ /* actual, physical DMA */
+ doing_pdma = 0;
+ clear_dma_ff(FLOPPY_DMA);
+ set_dma_mode(FLOPPY_DMA,mode);
+ set_dma_addr(FLOPPY_DMA,(unsigned int)virt_to_bus(addr));
+ set_dma_count(FLOPPY_DMA,size);
+ enable_dma(FLOPPY_DMA);
+ return 0;
+}
+
+struct fd_routine_l {
+ void (*_disable_dma)(unsigned int dmanr);
+ int (*_request_dma)(unsigned int dmanr, const char * device_id);
+ void (*_free_dma)(unsigned int dmanr);
+ int (*_get_dma_residue)(unsigned int dummy);
+ unsigned long (*_dma_mem_alloc) (unsigned long size);
+ int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
+} fd_routine[] = {
+ {
+ disable_dma,
+ request_dma,
+ free_dma,
+ get_dma_residue,
+ dma_mem_alloc,
+ hard_dma_setup
+ },
+ {
+ vdma_disable_dma,
+ vdma_request_dma,
+ vdma_nop,
+ vdma_get_dma_residue,
+ vdma_mem_alloc,
+ vdma_dma_setup
+ }
+};
+
static int FDC1 = 0x3f0;
static int FDC2 = -1;
^ permalink raw reply
* Re: PATCH: add ppc PVR register values for 7447A and 7457 CPUs
From: Kumar Gala @ 2005-02-24 5:16 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev list
In-Reply-To: <3609259af610006a1a0b7b016f727500@freescale.com>
Tom,
Here are the only usages of PVR_<CPU> that are in arch/ppc:
boot/simple/misc-ev64260.S: cmplwi r25,(PVR_7450 >> 16)
platforms/ev64260.c: if (pvr !=3D PVR_VER(PVR_7450)) {
platforms/4xx/ebony.c: case PVR_REV(PVR_440GP_RB):
platforms/4xx/ebony.c: case PVR_REV(PVR_440GP_RC1):
syslib/ibm440gx_common.c: if (pvr =3D=3D PVR_440GX_RA || pvr =3D=3D=20=
PVR_440GX_RB ||
syslib/ibm440gx_common.c: (pvr =3D=3D PVR_440GX_RC && p->cpu >=20=
667000000))
What do you think should we just get ride of all the other cases that=20
are not actually used and leave these in asm/regs.h or should we move=20
them as follows:
PVR_7450 -> into platforms/ev64260.h
PVR_440GP* -> into platforms/4xx/ebony.c (or include/asm/ibm4xx.h)
PVR_440GX* -> into syslib/ibm440gx_common.h
- kumar
On Feb 23, 2005, at 4:52 PM, Kumar Gala wrote:
>
>
> On Feb 23, 2005, at 4:25 PM, Tom Rini wrote:
>
> > On Wed, Feb 23, 2005 at 08:48:25PM +0000, James Chapman wrote:
> >=A0 > Signed-off-by: James Chapman <jchapman@katalix.com>
> > >
> > > Trivial patch to add 7447A and 7457 CPU defs.
> >
> > Why?=A0 Most of the PVR definitions here can be removed (*muttering=20=
> about
> >=A0 85xx ones being added).
>
> Yeah, yeah, will work on removing them.
>
> - kumar
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: ppc32 weirdness with gcc-4.0 in 2.6.11-rc4
From: Benjamin Herrenschmidt @ 2005-02-24 2:04 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: linuxppc-dev list, Linux Kernel list
In-Reply-To: <16924.59237.581247.498382@alkaid.it.uu.se>
> -Memory: 255872k available (1788k kernel code, 976k data, 144k init, 0k highmem)
> +Memory: 255872k available (1776k kernel code, 0k data, 144k init, 0k highmem)
That is weird... (0k data)
> AGP special page: 0xcffff000
> Calibrating delay loop... 830.66 BogoMIPS (lpj=4153344)
> Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
> @@ -132,13 +132,7 @@
> VFS: Mounted root (ext3 filesystem) readonly.
> Freeing unused kernel memory: 144k init 4k chrp 8k prep
> usb 3-2: new full speed USB device using ohci_hcd and address 2
> -hub 3-2:1.0: USB hub found
> -hub 3-2:1.0: 3 ports detected
> -usb 3-2.1: new low speed USB device using ohci_hcd and address 3
> -input: USB HID v1.10 Mouse [Logitech Apple Optical USB Mouse] on usb-0001:10:1b.0-2.1
> -usb 3-2.3: new full speed USB device using ohci_hcd and address 4
> -input: USB HID v1.10 Keyboard [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-2.3
> -input: USB HID v1.10 Device [Mitsumi Electric Apple Extended USB Keyboard] on usb-0001:10:1b.0-2.3
> +usb 3-2: can't connect bus-powered hub to this port
> EXT3 FS on hda5, internal journal
> Adding 1048568k swap on /dev/hda3. Priority:-1 extents:1
> SCSI subsystem initialized
>
> Note: "Memory: ... 0k data ..." !? Surely that can't be correct.
Not sure what's up, but it's probably something beeing miscompiled. Can
you check if the udelay/medlay loops are correct ?
Ben.
^ permalink raw reply
* [PATCH] ppc32: Bogus definition of __cmpxchg_u32()
From: Benjamin Herrenschmidt @ 2005-02-24 0:22 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: linuxppc-dev list
Hi !
This patch fix bogus types in the definition of __cmpxchg_u32() on
ppc32, please apply.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/include/asm-ppc/system.h
===================================================================
--- linux-work.orig/include/asm-ppc/system.h 2005-01-24 17:09:50.000000000 +1100
+++ linux-work/include/asm-ppc/system.h 2005-02-24 10:55:11.000000000 +1100
@@ -152,9 +152,9 @@
#define __HAVE_ARCH_CMPXCHG 1
static __inline__ unsigned long
-__cmpxchg_u32(volatile int *p, int old, int new)
+__cmpxchg_u32(volatile unsigned int *p, unsigned int old, unsigned int new)
{
- int prev;
+ unsigned int prev;
__asm__ __volatile__ ("\n\
1: lwarx %0,0,%2 \n\
^ permalink raw reply
* Re: PowerPC4xx Watchdog
From: Takeharu KATO @ 2005-02-23 23:36 UTC (permalink / raw)
To: Takeharu KATO; +Cc: ppcembed
In-Reply-To: <421D1085.5080602@ybb.ne.jp>
Hi
>> Are you looking for the old "ppc405 watchdog" driver that simply
>> hooked into the generic PPC heartbeat facility? Or are you looking
>> for a driver that utilizes the 4xx/booke hardware watchdog facility?
>>
> I am looking for a driver that utilizes the 4xx/booke hardware watchdog
> facility.
>
>
FYI, I wrote a driver uses 4xx/booke hardware watchdog.
BTW, is hooking PPC heartbeat facility obsoleted?
--
Takeharu KATO
^ permalink raw reply
* Re: PowerPC4xx Watchdog
From: Takeharu KATO @ 2005-02-23 23:23 UTC (permalink / raw)
To: Matt Porter; +Cc: ppcembed
In-Reply-To: <20050223142720.C13087@cox.net>
Hi
>
> Are you looking for the old "ppc405 watchdog" driver that simply
> hooked into the generic PPC heartbeat facility? Or are you looking
> for a driver that utilizes the 4xx/booke hardware watchdog facility?
>
I am looking for a driver that utilizes the 4xx/booke hardware watchdog
facility.
--
Takeharu KATO
^ permalink raw reply
* Re: PATCH: add ppc PVR register values for 7447A and 7457 CPUs
From: Kumar Gala @ 2005-02-23 22:52 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
In-Reply-To: <20050223222534.GM345@smtp.west.cox.net>
On Feb 23, 2005, at 4:25 PM, Tom Rini wrote:
> On Wed, Feb 23, 2005 at 08:48:25PM +0000, James Chapman wrote:
> > Signed-off-by: James Chapman <jchapman@katalix.com>
> >
> > Trivial patch to add 7447A and 7457 CPU defs.
>
> Why?=A0 Most of the PVR definitions here can be removed (*muttering =
about
> 85xx ones being added).
Yeah, yeah, will work on removing them.
- kumar
^ permalink raw reply
* Re: linux-2.5-marvell tree deletion
From: Mark A. Greer @ 2005-02-23 22:40 UTC (permalink / raw)
To: Embedded PPC Linux list; +Cc: Brian Waite, Steven J. Hill, David Woodhouse
In-Reply-To: <421679DA.60005@mvista.com>
Mark A. Greer wrote:
> Dale Farnsworth has moved the mv64[34]60 enet driver to
> bk://dfarnsworth.bkbits.net/linux-2.5-mv643xx-enet and all of the code
> that I've worked on is either in linux-2.5 or on a queue to go in so
> this tree should evaporate.
>
> If you have an issue with this please let me know before the morning
> of Wednesday, Feb 23, 2005; otherwise, I will delete it on Wednesday.
This tree is now gone.
Mark
^ permalink raw reply
* [PATCH][PPC32] Incorrect #define in include/asm-ppc/cpm2.h
From: Mark A. Greer @ 2005-02-23 22:36 UTC (permalink / raw)
To: akpm; +Cc: Embedded PPC Linux list
[-- Attachment #1: Type: text/plain, Size: 212 bytes --]
This patch fixes the incorrect definition of a macro that sets the
transmit parity to even on a cpm uart device.
Please apply (once 2.6.12 is open). Thanks.
Signed-off-by: Mark A. Greer <mgreer@mista.com>
--
[-- Attachment #2: cpm2_1.patch --]
[-- Type: text/plain, Size: 432 bytes --]
diff -Nru a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h 2005-02-22 16:26:07 -07:00
+++ b/include/asm-ppc/cpm2.h 2005-02-22 16:26:07 -07:00
@@ -531,7 +531,7 @@
#define SCU_PSMR_RPM ((ushort)0x000c)
#define SCU_PSMR_REVP ((ushort)0x0008)
#define SCU_PSMR_TPM ((ushort)0x0003)
-#define SCU_PSMR_TEVP ((ushort)0x0003)
+#define SCU_PSMR_TEVP ((ushort)0x0002)
/* CPM Transparent mode SCC.
*/
^ permalink raw reply
* Re: PATCH: add mv64x60 GPP IO pin/IRQ register definitions
From: Tom Rini @ 2005-02-23 22:26 UTC (permalink / raw)
To: James Chapman; +Cc: linuxppc-embedded
In-Reply-To: <421CEEA2.2080308@katalix.com>
On Wed, Feb 23, 2005 at 08:59:14PM +0000, James Chapman wrote:
> Add mv64x60 GPP IO pin/IRQ register definitions
[snip]
> #define MV64x60_IRQ_TIMER_6_7 11
> +#define MV64x60_IRQ_P1_GPP_0_7 24
Please use consistent spacing. Thanks.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PATCH: add ppc PVR register values for 7447A and 7457 CPUs
From: Tom Rini @ 2005-02-23 22:25 UTC (permalink / raw)
To: James Chapman; +Cc: linuxppc-dev
In-Reply-To: <421CEC19.2010703@katalix.com>
On Wed, Feb 23, 2005 at 08:48:25PM +0000, James Chapman wrote:
> Signed-off-by: James Chapman <jchapman@katalix.com>
>
> Trivial patch to add 7447A and 7457 CPU defs.
Why? Most of the PVR definitions here can be removed (*muttering about
85xx ones being added).
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: PowerPC4xx Watchdog
From: Matt Porter @ 2005-02-23 21:27 UTC (permalink / raw)
To: Takeharu KATO; +Cc: ppcembed
In-Reply-To: <421CD669.1040002@ybb.ne.jp>
On Thu, Feb 24, 2005 at 04:15:53AM +0900, Takeharu KATO wrote:
> Hi
>
> Sorry, I sent the mail before checking it by mistake.
> I meant to say as follows:
> I am working on developing WatchDog Driver for PowerPC4xx on Linux-2.6.
> Does anyone have a plan or a patch to make WatchDog Driver on
> PowerPC4xx(405GP/405GPr/440GP/440GX) for Linux-2.6?
Are you looking for the old "ppc405 watchdog" driver that simply
hooked into the generic PPC heartbeat facility? Or are you looking
for a driver that utilizes the 4xx/booke hardware watchdog facility?
-Matt
^ permalink raw reply
* Re: [PATCH] Ebony's UBoot awareness
From: Matt Porter @ 2005-02-23 21:24 UTC (permalink / raw)
To: Shawn Jin; +Cc: ppcembed
In-Reply-To: <c3d0340b05022310396240c8ac@mail.gmail.com>
On Wed, Feb 23, 2005 at 10:39:34AM -0800, Shawn Jin wrote:
> Hi,
>
> This adds UBoot support on Ebony board and also sets emac's PHY mode
> explicitly during initialization as Eugene Surovegin provided.
<snip>
> + if (!strncmp(__res.bi_enetaddr, "\0xFF\0xFF\0xFF\0xFF\0xFF\0xFF", 6))
> + memcpy(emacdata->mac_addr, __res.bi_enetaddr, 6);
> + else
> + memcpy(emacdata->mac_addr, EBONY_NA0_ADDR(vpd_base), 6);
Can you use the ocotea/luan approach and create an openbios stub
in arch/ppc/boot to create the bi_enetaddr infos? The PIBS stub
in arch/ppc/boot does this so we can have one path in the platform
file that parses the bootinfos.
-Matt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox