* patch powerpc-fix-size-check-for-hugetlbfs.patch queued to -stable tree
From: gregkh @ 2007-08-13 23:26 UTC (permalink / raw)
To: benh, gregkh, linuxppc-dev, paulus; +Cc: stable-commits
In-Reply-To: <1186551855.938.164.camel@localhost.localdomain>
This is a note to let you know that we have just queued up the patch titled
Subject: powerpc: Fix size check for hugetlbfs
to the 2.6.22-stable tree. Its filename is
powerpc-fix-size-check-for-hugetlbfs.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>From benh@kernel.crashing.org Mon Aug 13 16:17:09 2007
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Wed, 08 Aug 2007 15:44:15 +1000
Subject: powerpc: Fix size check for hugetlbfs
To: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Cc: Paul Mackerras <paulus@samba.org>, stable@kernel.org
Message-ID: <1186551855.938.164.camel@localhost.localdomain>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
My "slices" address space management code that was added in 2.6.22
implementation of get_unmapped_area() doesn't properly check that the
size is a multiple of the requested page size. This allows userland to
create VMAs that aren't a multiple of the huge page size with hugetlbfs
(since hugetlbfs entirely relies on get_unmapped_area() to do that
checking) which leads to a kernel BUG() when such areas are torn down.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
--- linux-work.orig/arch/powerpc/mm/slice.c 2007-08-08 15:16:06.000000000 +1000
+++ linux-work/arch/powerpc/mm/slice.c 2007-08-08 15:16:41.000000000 +1000
@@ -405,6 +405,8 @@ unsigned long slice_get_unmapped_area(un
if (len > mm->task_size)
return -ENOMEM;
+ if (len & ((1ul << pshift) - 1))
+ return -EINVAL;
if (fixed && (addr & ((1ul << pshift) - 1)))
return -EINVAL;
if (fixed && addr > (mm->task_size - len))
_______________________________________________
stable mailing list
stable@linux.kernel.org
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from benh@kernel.crashing.org are
queue-2.6.22/ppc-revert-don-t-complain-if-size-cells-0-in-prom_parse.patch
queue-2.6.22/ppc-revert-add-mdio-to-bus-scan-id-list-for-platforms-with-qe-uec.patch
queue-2.6.22/powerpc-fix-size-check-for-hugetlbfs.patch
^ permalink raw reply
* [PATCH] [UPDATED] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-13 22:37 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
---
Please ignore the last patch - I missed a cut & paste error on the range
that my testing didn't catch.
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 81ef81c..b4813d9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,6 +2276,14 @@ config GFAR_NAPI
bool "NAPI Support"
depends on GIANFAR
+config GFAR_TBIPA_VALUE
+ hex "Ten Bit Interface Port Address Value"
+ depends on GIANFAR
+ range 0 0x1f
+ default "0x1f"
+ help
+ Select an address that does not conflict with other addresses on the board.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f926905..91ae0d3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev)
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev)
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
/* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
+ gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..0fd1c02 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -131,7 +131,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE 0x1f
#define MIIMCFG_INIT_VALUE 0x00000007
#define MIIMCFG_RESET 0x80000000
#define MIIMIND_BUSY 0x00000001
^ permalink raw reply related
* [PATCH] tsec: Allow Ten Bit Interface to be configurable
From: Joe Hamman @ 2007-08-13 22:28 UTC (permalink / raw)
To: galak; +Cc: linuxppc-embedded
Allow the address of the Ten Bit Interface (TBI) to be changed in the
event of a conflict with another device.
Signed-off by: Joe Hamman <joe.hamman@embeddedspecialties.com>
---
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 81ef81c..ba67b3b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,6 +2276,14 @@ config GFAR_NAPI
bool "NAPI Support"
depends on GIANFAR
+config GFAR_TBIPA_VALUE
+ hex "Ten Bit Interface Port Address Value"
+ depends on GIANFAR
+ range 0 0x1f if BFIN_MAC_USE_L1
+ default "0x1f"
+ help
+ Select an address that does not conflict with other addresses on the board.
+
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index f926905..91ae0d3 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
@@ -490,15 +490,15 @@ static void gfar_configure_serdes(struct net_device *dev)
/* Initialise TBI i/f to communicate with serdes (lynx phy) */
/* Single clk mode, mii mode off(for aerdes communication) */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_TBICON, TBICON_CLK_SELECT);
/* Supported pause and full-duplex, no half-duplex */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_ADVERTISE,
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_ADVERTISE,
ADVERTISE_1000XFULL | ADVERTISE_1000XPAUSE |
ADVERTISE_1000XPSE_ASYM);
/* ANEG enable, restart ANEG, full duplex mode, speed[1] set */
- gfar_local_mdio_write(regs, TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
+ gfar_local_mdio_write(regs, CONFIG_GFAR_TBIPA_VALUE, MII_BMCR, BMCR_ANENABLE |
BMCR_ANRESTART | BMCR_FULLDPLX | BMCR_SPEED1000);
}
@@ -547,7 +547,7 @@ static void init_registers(struct net_device *dev)
gfar_write(&priv->regs->minflr, MINFLR_INIT_SETTINGS);
/* Assign the TBI an address which won't conflict with the PHYs */
- gfar_write(&priv->regs->tbipa, TBIPA_VALUE);
+ gfar_write(&priv->regs->tbipa, CONFIG_GFAR_TBIPA_VALUE);
}
diff --git a/drivers/net/gianfar.h b/drivers/net/gianfar.h
index d8e779c..0fd1c02 100644
--- a/drivers/net/gianfar.h
+++ b/drivers/net/gianfar.h
@@ -131,7 +131,6 @@ extern const char gfar_driver_version[];
#define DEFAULT_RXCOUNT 16
#define DEFAULT_RXTIME 4
-#define TBIPA_VALUE 0x1f
#define MIIMCFG_INIT_VALUE 0x00000007
#define MIIMCFG_RESET 0x80000000
#define MIIMIND_BUSY 0x00000001
^ permalink raw reply related
* Re: [PATCH, RFC] wake up from a serial port
From: Greg KH @ 2007-08-13 22:28 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial
In-Reply-To: <Pine.LNX.4.60.0708132307200.5643@poirot.grange>
On Mon, Aug 13, 2007 at 11:14:22PM +0200, Guennadi Liakhovetski wrote:
> On Mon, 13 Aug 2007, Scott Wood wrote:
>
> > Guennadi Liakhovetski wrote:
> > >
> > > # ls -l /sys/devices/platform/serial8250.0/tty*
> > > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > > /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> > > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > > /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
> > >
> > > And placing some wakeup file under the class/tty/ directory doesn't seem
> > > very consistent with the current policy - until now they only live under
> > > devices/... (Greg added to cc:).
> >
> > Hmm... I'd assumed each port would have its own device directory. Would
> > anything break horribly if it were changed so that each tty:ttySx is a
> > directory, which contains both a wakeup file and the symlink?
No, you are already in the tty device directory in the first place, the
tty:ttyS1 is just a symlink to the class in case you need the thing.
Let's follow things around:
~ $ cd /sys/class/tty
/sys/class/tty $ ls -l | grep ttyS
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS0 -> ../../devices/platform/serial8250/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS1 -> ../../devices/platform/serial8250/tty/ttyS1
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS2 -> ../../devices/platform/serial8250/tty/ttyS2
lrwxrwxrwx 1 root root 0 Aug 12 20:12 ttyS3 -> ../../devices/platform/serial8250/tty/ttyS3
/sys/class/tty $ cd ../../devices/platform/serial8250/tty/ttyS0
/sys/devices/platform/serial8250/tty/ttyS0 $ ls
dev device power subsystem uevent
/sys/devices/platform/serial8250/tty/ttyS0 $ cd ..
/sys/devices/platform/serial8250/tty $ $ ls -l
total 0
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS0
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS1
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS2
drwxr-xr-x 3 root root 0 Aug 12 20:12 ttyS3
/sys/devices/platform/serial8250/tty $ cd ..
gregkh@mini /sys/devices/platform/serial8250 $ ls -l
total 0
lrwxrwxrwx 1 root root 0 Aug 12 20:13 driver -> ../../../bus/platform/drivers/serial8250
-r--r--r-- 1 root root 4096 Aug 13 15:24 modalias
drwxr-xr-x 2 root root 0 Aug 13 15:24 power
lrwxrwxrwx 1 root root 0 Aug 12 20:13 subsystem -> ../../../bus/platform
drwxr-xr-x 6 root root 0 Aug 12 20:12 tty
-rw-r--r-- 1 root root 4096 Aug 12 20:12 uevent
So, the serial8250 device is the "bridge" for the 4 different serial
ports in my machine. You have the tty:ttyS? symlinks in that directory
as you have CONFIG_SYSFS_DEPRECATED still enabled, but the directory
structure should all still be the same for you.
So, if you want to put things into the tty device's directory, you can,
they will just show up in the proper place, under
/sys/devices/platform/serial8250/tty/ttyS0 for the first serial port.
Does that make sense?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT
From: Joe Perches @ 2007-08-13 22:36 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, cbe-oss-dev
In-Reply-To: <46C0DA2B.6080407@am.sony.com>
On Mon, 2007-08-13 at 15:24 -0700, Geoff Levand wrote:
> +F: include/asm-powerpc/lv1call.h
Added to my tree.
PS3 PLATFORM SUPPORT
P: Geoff Levand
M: geoffrey.levand@am.sony.com
L: linuxppc-dev@ozlabs.org
L: cbe-oss-dev@ozlabs.org
S: Supported
F: arch/powerpc/boot/ps3*
F: arch/powerpc/platforms/ps3/
F: drivers/*/ps3*
F: drivers/ps3/
F: drivers/usb/host/*ps3.c
F: include/asm-powerpc/ps3*
F: include/asm-powerpc/lv1call.h
^ permalink raw reply
* Re: [PATCH] [392/2many] MAINTAINERS - PS3 PLATFORM SUPPORT
From: Geoff Levand @ 2007-08-13 22:24 UTC (permalink / raw)
To: joe; +Cc: linuxppc-dev, akpm, torvalds, linux-kernel, cbe-oss-dev
In-Reply-To: <46bffb71.JWcVvIR5pg3biTEh%joe@perches.com>
From: joe@perches.com
Add file pattern to MAINTAINER entry
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
I also maintain the file include/asm-powerpc/lv1call.h.
This updated patch adds that file.
-Geoff
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3015,6 +3015,13 @@ M: geoffrey.levand@am.sony.com
L: linuxppc-dev@ozlabs.org
L: cbe-oss-dev@ozlabs.org
S: Supported
+F: arch/powerpc/boot/ps3*
+F: arch/powerpc/platforms/ps3/
+F: drivers/*/ps3*
+F: drivers/ps3/
+F: drivers/usb/host/*ps3.c
+F: include/asm-powerpc/ps3*
+F: include/asm-powerpc/lv1call.h
PVRUSB2 VIDEO4LINUX DRIVER
P: Mike Isely
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Guennadi Liakhovetski @ 2007-08-13 21:14 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <46C0C419.6060009@freescale.com>
On Mon, 13 Aug 2007, Scott Wood wrote:
> Guennadi Liakhovetski wrote:
> >
> > # ls -l /sys/devices/platform/serial8250.0/tty*
> > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> > lrwxrwxrwx 1 root root 0 Aug 13 22:05
> > /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
> >
> > And placing some wakeup file under the class/tty/ directory doesn't seem
> > very consistent with the current policy - until now they only live under
> > devices/... (Greg added to cc:).
>
> Hmm... I'd assumed each port would have its own device directory. Would
> anything break horribly if it were changed so that each tty:ttySx is a
> directory, which contains both a wakeup file and the symlink?
Yeah, I'd love to know the answer too:-) As you see, atm it is one
platform device as defined in arch/powerpc/kernel/legacy_serial.c:
static struct platform_device serial_device = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = legacy_serial_ports,
},
};
with a list of ports in platform data:
static struct plat_serial8250_port legacy_serial_ports[MAX_LEGACY_SERIAL_PORTS+1];
Hence one device directory. Same on a PC
$ ls -l /sys/devices/platform/serial8250/tty*
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS0 -> ../../../class/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS1 -> ../../../class/tty/ttyS1
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS2 -> ../../../class/tty/ttyS2
lrwxrwxrwx 1 root root 0 Aug 13 23:10 /sys/devices/platform/serial8250/tty:ttyS3 -> ../../../class/tty/ttyS3
> You should get the interrupt, but not until after the PM code enables IRQs.
> Are you saying that the interrupt handler runs before then?
Great, it is working correctly then! Don't think the ISR runs return from
PM, no.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Sequoia 440EPx patches not working
From: Jerone Young @ 2007-08-13 21:04 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46BB41EB.5030207@ru.mvista.com>
I got it to load now cuImage.sequoia and loading at address 0x200000. I
had been trying to load at 0x400000...apparently this was not good. So
moving to 0x300000 it loads but stops after setting up the device tree.
So the image was clobbering something but now is not at 0x200000.
Thanks for the help.
Jerone
On Thu, 2007-08-09 at 20:33 +0400, Valentine Barshak wrote:
> Jerone Young wrote:
> > So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
> > git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
> > that came with the board. It still appears to hang during early boot on
> > my Sequoia.
> >
> > Trying the cuImage.sequoia.bin.gz just result in Uboot giving "Bad Magic
> > Number" when trying to boot it. This is also the same for using
> > cuImage.sequoia.elf.
> >
> > So when I use the uImage file it will load but just hang after it's
> > loaded. I'm building it using "make uImage CROSS_COMPILE=<cross prefix>
> > ARCH=powerpc" on an x86 box.
> >
> > I'll see what else I could possibly be doing wrong (maybe something
> > happened to the patch when I grabbed it off of gmane and the web filters
> > did something to it, I did have to fix a problem where in the
> > sequoia.dts file the web filter replace "@" with " at ". This was simple
> > enough to fix. Maybe something else when wrong. I'll see what else I can
> > look at.
> >
> > On Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote:
> >> On Wed, 08 Aug 2007 13:45:10 -0500
> >> Jerone Young wrote:
> >>
> >>> Using the Sequoia (AMCC 440EPx) patches recently submitted to the
> >>> list I am unable to boot to fully boot a uImage built with these
> >>> patches under Uboot. It appears to hang in very early boot.
> >>>
> >>>
> >>> Here is the output:
> >>> => tftp 400000
> >>> sequoia/uImage ENET Speed is 100 Mbps - FULL duplex connection
> >>> (EMAC0) Using ppc_4xx_eth0
> >>> device TFTP from server 9.53.41.24; our IP address is
> >>> 9.53.41.38 Filename
> >>> 'sequoia/uImage'. Load address:
> >>> 0x400000 Loading:
> >>> #################################################################
> >>> #################################################################
> >>> #################################################################
> >>> #######################
> >>> done Bytes transferred = 1112434 (10f972
> >>> hex) => bootm
> >>> 400000 ## Booting image at
> >>> 00400000 ... Image Name:
> >>> Linux-2.6.23-rc2 Image Type: PowerPC Linux Kernel Image (gzip
> >>> compressed) Data Size: 1112370 Bytes = 1.1
> >>> MB Load Address:
> >>> 00000000 Entry Point:
> >>> 00000000 Verifying Checksum ...
> >>> OK Uncompressing Kernel Image ... OK
> >>>
> >>> _______________________________________________
> >>> Linuxppc-dev mailing list
> >>> Linuxppc-dev@ozlabs.org
> >>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >> This seems to be a wrong image..
> >>
> >> Are you using "make zImage" ?
> >>
> >> The proper uImage after that command would be smth like cuImage* then...
> >>
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
> Please, apply clean patches (not filtered by web filters) and
> try make ARCH=powerpc CROSS_COMPILE=<cross_prefix> zImage
> The image should be at arch/powerpc/boot/cuImage.sequoia
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Scott Wood @ 2007-08-13 20:50 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <Pine.LNX.4.60.0708132207530.5643@poirot.grange>
Guennadi Liakhovetski wrote:
> Well, sort of. One of them is more "natural" - it has a button on the
> front panel, to use the other one you have to modify the hardware.
> However, I like the idea - generally it does seem to be a better approach
> to have it run-time configurable over sysfs... Only - how? The only
> differentitaion ATM between the two ports are these two links:
>
> # ls -l /sys/devices/platform/serial8250.0/tty*
> lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
> lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
>
> And placing some wakeup file under the class/tty/ directory doesn't seem
> very consistent with the current policy - until now they only live under
> devices/... (Greg added to cc:).
Hmm... I'd assumed each port would have its own device directory. Would
anything break horribly if it were changed so that each tty:ttySx is a
directory, which contains both a wakeup file and the symlink?
> Actually, it is good you replied, Scott:-) I wanted to ask you about the
> following: I've switched to your generic suspend/resume routines using the
> _TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup
> your _TLF_NAPPING trick should bypass calling the ISR and jump directly to
> the resume code. However, on wakeup, it looks like I do get the wakeup
> interrupt too.
You should get the interrupt, but not until after the PM code enables
IRQs. Are you saying that the interrupt handler runs before then?
> Is it the correct behaviour and is this the (approximately)
> correct explanation why:
>
> 1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on
> button release. So, normally you would get 2 bytes and 2 interupts for one
> such button down-up.
>
> 2. Interrupt is configured as edge (is it correct - haven't found in
> mpc8245um, UARTs are usually edge), so,
>
> --- button down -> byte #1 -> IRQ line active -> IC interrupts
> --- on resume interrupts are disabled, an EOI is performed (the line is
> still active)
> --- interrupts are re-enabled
>
> 3. a second interrupt for the same byte is delivered.
No EOI is performed -- the idea is to defer the interrupt, not swallow
it. All that is done to defer the interrupt is clearing MSR[EE].
-Scott
^ permalink raw reply
* Re: [PATCH, RFC] wake up from a serial port
From: Guennadi Liakhovetski @ 2007-08-13 20:41 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, linux-serial, Greg KH
In-Reply-To: <20070813155734.GB17535@ld0162-tx32.am.freescale.net>
On Mon, 13 Aug 2007, Scott Wood wrote:
> On Mon, Aug 13, 2007 at 12:27:30AM +0200, Guennadi Liakhovetski wrote:
> > A number of Linkstation models from Buffalo Technology with PPC, ARM, and
> > also MIPS (I think) CPUs have a power-management controller connected to a
> > UART. Among other things that chip controlls power and reset buttons.
> > Working on a standby support for one of these systems (ppc mpc8241 based),
> > the only suitable wakeup source there is the power button, which means, I
> > have to configure one of the two system UARTs to not be suspendsd. Using
> > the device_*_wakeup API doesn't quite work because both serial ports share
> > one device. The below patch proposes a new port flag UPF_MAY_WAKEUP to
> > configure such UARTs. It also adds support for a new "can-wakeup" serial
> > node property to the legacy_serial driver.
>
> Shouldn't the ability to wakeup be configured through sysfs, rather than
> encoded into the device tree? I'm assuming this is just a matter of
> configuration, and not that the hardware supports waking from one and not
> the other.
Well, sort of. One of them is more "natural" - it has a button on the
front panel, to use the other one you have to modify the hardware.
However, I like the idea - generally it does seem to be a better approach
to have it run-time configurable over sysfs... Only - how? The only
differentitaion ATM between the two ports are these two links:
# ls -l /sys/devices/platform/serial8250.0/tty*
lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS0 -> ../../../class/tty/ttyS0
lrwxrwxrwx 1 root root 0 Aug 13 22:05 /sys/devices/platform/serial8250.0/tty:ttyS1 -> ../../../class/tty/ttyS1
And placing some wakeup file under the class/tty/ directory doesn't seem
very consistent with the current policy - until now they only live under
devices/... (Greg added to cc:).
Actually, it is good you replied, Scott:-) I wanted to ask you about the
following: I've switched to your generic suspend/resume routines using the
_TLF_NAPPING bit, the arch_suspend_{dis,en}able_irqs() hooks... On wakeup
your _TLF_NAPPING trick should bypass calling the ISR and jump directly to
the resume code. However, on wakeup, it looks like I do get the wakeup
interrupt too. Is it the correct behaviour and is this the (approximately)
correct explanation why:
1. the AVR connected to ttyS0 sends 1 byte on button press and 1 byte on
button release. So, normally you would get 2 bytes and 2 interupts for one
such button down-up.
2. Interrupt is configured as edge (is it correct - haven't found in
mpc8245um, UARTs are usually edge), so,
--- button down -> byte #1 -> IRQ line active -> IC interrupts
--- on resume interrupts are disabled, an EOI is performed (the line is
still active)
--- interrupts are re-enabled
3. a second interrupt for the same byte is delivered.
I'm just trying to understand whether this is the correct and expected
behaviour or something is wrong here.
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* PCI BAR mapping problem
From: Johan Borkhuis @ 2007-08-13 20:23 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I am having some problems with the initialization of BAR registers of
the PCI bus. I have a number of devices connected to the bus, which have
a BAR-size of less than PAGE_SIZE. For example:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeffe00 (32-bit, non-prefetchable) [size=512]
I/O ports at e0ffff00 [size=256]
Memory at 00000000dfeffdc0 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
I want to access the PCI-areas from from user space, so I try to do an
mmap. The returned address is however rounded to multiple of PAGE_SIZE
(=0x1000). To access for example BAR0, I have to use the return-value
from mmap+0xE00. And in the above case, I am able to access the BAR0 and
BAR2 areas with only 1 mmap call, as the 2 addresses are within one page.
The problem is that, when running my code on a I386 platform the BAR
registers are mapped at address 0x0 of the returned area.
When looking at the PCI init code (arch/ppc/syslib/pci_auto.c) I see
that the BAR-base address and/or size is not corrected for PAGE_SIZE. Is
this correct behaviour?
I could image the following line being changed from:
bar_value = (*upper_limit - bar_size) & ~(bar_size - 1);
to:
bar_value = ((*upper_limit - bar_size) & ~(bar_size - 1)) &
~(PAGE_SIZE-1);
The PCI area is assigned using a top-down method. Using this statement
the bar_value is rounded down to the first PAGE_SIZE boundary.
This gives the following output:
01:00.0 Network controller: VMIC: Unknown device 5565 (rev 01)
Subsystem: PLX Technology, Inc.: Unknown device 9656
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 52
Memory at 00000000dfeff000 (32-bit, non-prefetchable) [size=512]
I/O ports at e0fff000 [size=256]
Memory at 00000000dfefe000 (32-bit, non-prefetchable) [size=64]
Memory at 00000000d8000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [40] Power Management version 0
Capabilities: [48] #00 [0080]
My architecture: MVME3100 board with PPC8540 processor.
Note:
I posted this message to the embedded PPC mailing list, but as this is a
more generic linux-ppc issue, it could be discussed here as well.
Kind regards,
Johan Borkhuis
--
o o o o o o o . . . ___J_o_h_a_n___B_o_r_k_h_u_i_s___
o _____ || http://www.borkhuis.com |
.][__n_n_|DD[ ====_____ | johan@borkhuis.com |
>(________|__|_[_________]_|______________________________|
_/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
=== VxWorks-FAQ: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ===
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 18:32 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-embedded
In-Reply-To: <46C0985B.9040401@genesi-usa.com>
On 8/13/07, Matt Sealey <matt@genesi-usa.com> wrote:
> I'll put in a decent request here for any work on this subject to
> please at least attempt to retrieve the tasks from the Efika
> firmware rather than replacing them in Linux gratuituously.
> I understand this doesn't help the Lite5200 guys.. but.. pretty
> please with a cherry on top? :]
We're making an open device with all software being replaceable. I
already have u-boot. Is there a free open firmware option? Which is
the recommended path?
Matt, I'll buy some Efikas as soon as you're selling them again.,
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: DTC 1.0.0 Release
From: Jon Loeliger @ 2007-08-13 18:30 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org, Olaf Hering, Jon Loeliger
In-Reply-To: <20070813005055.GC15738@localhost.localdomain>
On Sun, 2007-08-12 at 19:50, David Gibson wrote:
> On Fri, Aug 10, 2007 at 11:21:29PM +0200, Olaf Hering wrote:
> > On Thu, Aug 09, Jon Loeliger wrote:
> >
> > > As usual, please let me know of any issues with it.
> >
> > tests/truncated_property.c:45: warning: 'err' is used uninitialized
> > in this function
>
> Looks good. If you had a Signed-off-by, I'd add an Acked-by...
... I'd apply it and start us on the way to some
other release!
Thanks,
jdl
^ permalink raw reply
* On the other side of early_debug...
From: Morrison, Tom @ 2007-08-13 18:24 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.1.1186797602.26064.linuxppc-dev@ozlabs.org>
It looks like I am getting up to the point where the=20
rootfs has been NFS mounted correctly. Whew, but the
first thing the INIT program does it try to open the
/dev/console device - and it goes oops:
>> kernel BUG at drivers/char/tty_io.c:781!
>> Oops: Exception in kernel mode, sig: 5 [#1]
>> Empirix MPC848 Cheetah Board
>> Modules linked in:
>> NIP: c01390d4 LR: c013abe4 CTR: 00000000
>> REGS: effc3d50 TRAP: 0700 Not tainted
(2.6.23-r3_tom-g46b28357-dirty)
>> MSR: 00021000 <ME> CR: 24242422 XER: 00000000
>> TASK =3D effc1a80[1] 'init' THREAD: effc2000
>> GPR00: 00000001 effc3e00 effc1a80 00000000 effc3de0 00000001 00000000
>> c02b60c8
>> GPR08: 00001aa3 00000000 c030b730 00000000 22242422 1001f2f8 fffffff0
>> 007fff94
>> GPR16: 20000000 00000000 00000000 effc3e30 c17c2528 c17c2530 00000130
>> 00000128
>> GPR24: c02c0000 00000001 00000001 00000000 00000000 00029000 c17c2400
>> 00000001
>> NIP [c01390d4] tty_ldisc_put+0x44/0x70
>> LR [c013abe4] release_dev+0x4ec/0x6a0
>> Call Trace:
>> [effc3e00] [c021d800] __mutex_unlock_slowpath+0x40/0xd4 (unreliable)
>> [effc3e20] [c013abe4] release_dev+0x4ec/0x6a0
>> [effc3ee0] [c013adac] tty_release+0x14/0x28
>> [effc3ef0] [c0068844] __fput+0x178/0x19c
>> [effc3f10] [c0066a5c] filp_close+0x54/0xac
>> [effc3f30] [c0066b34] sys_close+0x80/0xc0
>> [effc3f40] [c000c54c] ret_from_syscall+0x0/0x3c
>> Instruction dump:
>> 7c000110 7c0000d0 0f000000 7fa000a6 7c000146 1d43004c 3d20c031
3929b730
>> 7d4a4a14 816a0048 212b0000 7c095914 <0f000000> 396bffff 806a0044
916a0048
Now, it seems the root cause is that the tty's=20
console_init was NEVER being called.=20
I am wondering if there was a reason or rhyme for this?
^ permalink raw reply
* Re: [PATCH] [43/2many] MAINTAINERS - AOA (Apple Onboard Audio) ALSA DRIVER
From: Joe Perches @ 2007-08-13 18:08 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, johannes, torvalds, linux-kernel, akpm
In-Reply-To: <1186988077.32127.2.camel@concordia.ozlabs.ibm.com>
On Mon, 2007-08-13 at 16:54 +1000, Michael Ellerman wrote:
> > +F: sound/oao/
> Should be aoa.
AOA (Apple Onboard Audio) ALSA DRIVER
P: Johannes Berg
M: johannes@sipsolutions.net
L: linuxppc-dev@ozlabs.org
L: alsa-devel@alsa-project.org (subscribers-only)
S: Maintained
F: sound/aoa/
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Bartlomiej Sieka @ 2007-08-13 17:15 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40708130934v912eda2r691d2db30a9bc17c@mail.gmail.com>
Grant Likely wrote:
> On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>> We're starting a new MPC5200 project and I'm trying to track down
>> the best kernel to start from. Is Sylvain's tree at
>> http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
>> from the web page don't work. Everything 5200 related in the trees
>> at Secret Labs already appears to be merged.
>>
>> Most of this work also appears to be in the Open Embedded tree's
>> Ekifa support. Is that a better place to start?
>
> It might be. The major problem with MPC5200 is the Ethernet driver.
> I believe both Domen and Sylvain have been working on drivers
> suitable for arch/powerpc inclusion.
We have integrated FEC code floating around into DENX Linux 2.6 tree,
and have it working on several boards in the arch/powerpc context.
It might be worthwhile to check out
git://www.denx.de/git/linux-2.6-denx.git#linux-2.6-denx
HTH,
Bartlomiej
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Matt Sealey @ 2007-08-13 17:43 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130952m9c5e512xe41fec3a02435298@mail.gmail.com>
The current (2.6.22) patchset for the Efika is being held here for
the moment; http://dev.gentoo.org/~nixnut/efika/
That's everything you 'really need' and it's probably the same as
this patch list.
However practically none of it is mainline-worthy at the moment,
Sylvain has detailed too many things he thinks is wrong with it.
I'm having a go with the new ethernet driver patch right now (a
customer asked me for a prebuilt kernel..) so I can get on with
testing that. The most important ones for rewrites besides that
are the AC97 driver (which is a little.. sparse) and actually
using the ATA task.
I'll put in a decent request here for any work on this subject to
please at least attempt to retrieve the tasks from the Efika
firmware rather than replacing them in Linux gratuituously.
I understand this doesn't help the Lite5200 guys.. but.. pretty
please with a cherry on top? :]
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Jon Smirl wrote:
> Another series is being posted to the Efika boards.
>
> 0001-powerpc-exports-rheap-symbol-to-modules.patch
> 0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
> 0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
> 0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
> 0005-powerpc-BestcComm-ATA-task-support.patch
> 0006-powerpc-BestcComm-FEC-task-support.patch
> 0007-powerpc-BestcComm-GenBD-task-support.patch
> 0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
> 0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
> 0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
> 0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
> 0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
> 0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
> 0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
> 0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
> 0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
> 0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
> 0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
> 0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
> 0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
> 0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
> 0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch
> 0082-powerpc-pata_mpc52xx-suspend.patch
>
^ permalink raw reply
* Re: [PATCH] [298/2many] MAINTAINERS - LINUX FOR 64BIT POWERPC
From: Joe Perches @ 2007-08-13 17:40 UTC (permalink / raw)
To: Josh Boyer
Cc: anton, linux-kernel, linuxppc-dev, paulus, anton, paulus,
torvalds, akpm
In-Reply-To: <20070813061522.57ca3662@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:15 -0500, Josh Boyer wrote:
> Erm, there's a lot more to 64-bit PowerPC than those 3 files. You're
> better off just doing arch/powerpc/, include/asm-powerpc.
LINUX FOR 64BIT POWERPC
P: Paul Mackerras
M: paulus@samba.org
M: paulus@au.ibm.com
P: Anton Blanchard
M: anton@samba.org
M: anton@au.ibm.com
W: http://www.penguinppc.org/ppc64/
L: linuxppc-dev@ozlabs.org
S: Supported
F: arch/powerpc/
F: include/asm-powerpc/
^ permalink raw reply
* Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: Josh Boyer @ 2007-08-13 17:39 UTC (permalink / raw)
To: Joe Perches; +Cc: torvalds, linux-kernel, akpm, linuxppc-embedded
In-Reply-To: <1187026501.10249.158.camel@localhost>
On Mon, 13 Aug 2007 10:35:01 -0700
Joe Perches <joe@perches.com> wrote:
> On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote:
> > You're missing arch/ppc/platforms/4xx/, among other things.
> > Also, we're in the middle of merging 4xx to arch/powerpc.
>
> We can leave the whole block unmodified until you're ready.
>
> LINUX FOR POWERPC EMBEDDED PPC4XX
> P: Matt Porter
> M: mporter@kernel.crashing.org
> W: http://www.penguinppc.org/
> L: linuxppc-embedded@ozlabs.org
> S: Maintained
Yeah. I would actually prefer that, thanks.
josh
^ permalink raw reply
* Re: [PATCH] [289/2many] MAINTAINERS - LINUX FOR POWERPC
From: Joe Perches @ 2007-08-13 17:38 UTC (permalink / raw)
To: Josh Boyer; +Cc: paulus, akpm, torvalds, linux-kernel, linuxppc-dev
In-Reply-To: <20070813061601.50bbefe0@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:16 -0500, Josh Boyer wrote:
> There's also the arch/ppc, include/asm-ppc directories until they get
> removed.
LINUX FOR POWERPC
P: Paul Mackerras
M: paulus@samba.org
W: http://www.penguinppc.org/
L: linuxppc-dev@ozlabs.org
T: git kernel.org:/pub/scm/linux/kernel/git/paulus/powerpc.git
S: Supported
F: arch/powerpc/
F: arch/ppc/
F: include/asm-powerpc/
F: include/asm-ppc/
^ permalink raw reply
* Re: [PATCH] [292/2many] MAINTAINERS - LINUX FOR POWERPC EMBEDDED PPC4XX
From: Joe Perches @ 2007-08-13 17:35 UTC (permalink / raw)
To: Josh Boyer; +Cc: torvalds, linux-kernel, akpm, linuxppc-embedded
In-Reply-To: <20070813061854.644e6e5e@zod.rchland.ibm.com>
On Mon, 2007-08-13 at 06:18 -0500, Josh Boyer wrote:
> You're missing arch/ppc/platforms/4xx/, among other things.
> Also, we're in the middle of merging 4xx to arch/powerpc.
We can leave the whole block unmodified until you're ready.
LINUX FOR POWERPC EMBEDDED PPC4XX
P: Matt Porter
M: mporter@kernel.crashing.org
W: http://www.penguinppc.org/
L: linuxppc-embedded@ozlabs.org
S: Maintained
^ permalink raw reply
* Re: [PATCH] via-pmu: Fix typo in printk
From: Benjamin Herrenschmidt @ 2007-08-13 16:57 UTC (permalink / raw)
To: Michael Buesch; +Cc: linuxppc-dev
In-Reply-To: <200708122238.34985.mb@bu3sch.de>
On Sun, 2007-08-12 at 22:38 +0200, Michael Buesch wrote:
> This fixes a typo in a printk message.
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Index: linux-2.6/drivers/macintosh/via-pmu.c
> ===================================================================
> --- linux-2.6.orig/drivers/macintosh/via-pmu.c 2007-05-26 19:56:27.000000000 +0200
> +++ linux-2.6/drivers/macintosh/via-pmu.c 2007-08-12 22:36:27.000000000 +0200
> @@ -410,7 +410,7 @@ static int __init via_pmu_start(void)
>
> irq = irq_of_parse_and_map(vias, 0);
> if (irq == NO_IRQ) {
> - printk(KERN_ERR "via-pmu: can't map interruptn");
> + printk(KERN_ERR "via-pmu: can't map interrupt\n");
> return -ENODEV;
> }
> if (request_irq(irq, via_pmu_interrupt, 0, "VIA-PMU", (void *)0)) {
>
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 16:52 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130950y38f60687ma7957cf42a758cdd@mail.gmail.com>
Another series is being posted to the Efika boards.
0001-powerpc-exports-rheap-symbol-to-modules.patch
0002-powerpc-Changes-the-config-mechanism-for-rheap.patch
0003-powerpc-ppc32-Update-mpc52xx_psc-structure-with-B-r.patch
0004-powerpc-BestComm-core-support-for-Freescale-MPC5200.patch
0005-powerpc-BestcComm-ATA-task-support.patch
0006-powerpc-BestcComm-FEC-task-support.patch
0007-powerpc-BestcComm-GenBD-task-support.patch
0008-drivers-net-Add-support-for-Freescale-MPC5200-SoC-i.patch
0009-sound-Add-support-for-Freescale-MPC5200-AC97-interf.patch
0010-powerpc-In-rheap.c-move-the-EXPORT_SYMBOL-and-use.patch
0011-powerpc-BestComm-move-the-EXPORT_SYMBOL-and-use-th.patch
0012-powerpc-BestComm-ATA-task-move-the-EXPORT_SYMBOL-a.patch
0013-powerpc-BestComm-FEC-task-move-the-EXPORT_SYMBOL-a.patch
0014-powerpc-BestComm-GenBD-task-move-the-EXPORT_SYMBOL.patch
0015-powerpc-BestComm-Replace-global-variable-bcom-by-b.patch
0016-powerpc-Make-the-BestComm-driver-a-standard-of_plat.patch
0017-powerpc-Fix-typo-in-BestComm-ATA-task-support-code.patch
0018-powerpc-BestComm-ATA-task-microcode-insert-copyri.patch
0019-powerpc-BestComm-FEC-task-microcode-insert-copyri.patch
0020-powerpc-BestComm-GenBD-task-microcode-insert-copy.patch
0021-powerpc-Fix-errors-in-bcom-bcom_eng-renaming.patch
0081-mpc52xx-correct-calculation-of-FEC-RX-errors.patch
0082-powerpc-pata_mpc52xx-suspend.patch
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Jon Smirl @ 2007-08-13 16:50 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <fa686aa40708130934v912eda2r691d2db30a9bc17c@mail.gmail.com>
On 8/13/07, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> > We're starting a new MPC5200 project and I'm trying to track down the
> > best kernel to start from. Is Sylvain's tree at
> > http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
> > from the web page don't work. Everything 5200 related in the trees at
> > Secret Labs already appears to be merged.
> >
> > Most of this work also appears to be in the Open Embedded tree's Ekifa
> > support. Is that a better place to start?
>
> It might be. The major problem with MPC5200 is the Ethernet driver.
> I believe both Domen and Sylvain have been working on drivers suitable
> for arch/powerpc inclusion.
OpenEmbedded has this series against 2.6.20
0001-powerpc-serial-Dispose-irq-mapping-when-done-in-mpc52xx_serial.c.txt
0003-powerpc-Add-device-tree-fixups-for-the-EFIKA.txt
0004-powerpc-Use-common-52xx-of_platform-probe-code-for-EFIKA.txt
0005-powerpc-Restore-proper-link-order-in-platform.txt
0006-Rework-the-OHCI-quirk-mecanism-as-suggested-by-David.txt
0007-Implement-support-for-split-endian-OHCI.txt
0008-ohci-Rework-bus-glue-integration-to-allow-several-at-once.txt
0009-ohci-Add-support-for-OHCI-controller-on-the-of_platform-bus.txt
0010-libata-Add-support-for-the-MPC52xx-ATA-controller.txt
0011-ohci-Whitespace-and-typo-fix-in-ohci-ppc-of.c.txt
0012-ata-Fix-pata_mpc52xx.c-compatible-list.txt
0013-powerpc-serial-Fix-mpc52xx_uart.c-compatible-list.txt
0014-powerpc-Small-cleanup-of-EFIKA-platform.txt
0015-powerpc-Add-a-unified-uevent-handler-for-bus-based-on-of_device.txt
0016-macintosh-Use-the-new-of_device-common-uevent-handler.txt
0017-powerpc-Add-uevent-handler-for-of_platform_bus.txt
0018-powerpc-Add-uevent-handler-for-ibmebus.txt
0019-MPC5200-Bestcomm-platform-driver.txt
0020-Fec-MPC5200-eth-driver.txt
0021-POWERPC-Copy-bestcomm-support-files-into-arch-powerpc.txt
0022-MPC52xx-PCI-now-working-on-lite5200.-ugly-but-working.txt
0023-POWERPC-Make-FEC-work-on-the-lite5200.txt
0024-Add-missing-function-prototype.txt
0025-POWERPC-Misc-EFIKA-fixups-for-rtas-chrp.txt
0026-POWERPC-Cleanup-mpc52xx-PCI-support.txt
0027-POWERPC-Change-name-of-mpc52xx-pci-support-file-in-Makefile.txt
0028-POWERPC-Change-link-order-so-mpc52xx-fec-always-shows-up-as-eth0.txt
0029-POWERPC-Fixup-pr_print-format-for-mpc52xx-pci-support.txt
0030-POWERPC-Add-mpc52xx-lite5200-PCI-support.txt
0031-sound-Add-support-for-the-MPC52xx-PSC-AC97-Link.txt
0032-POWERPC-EFIKA-Adds-missing-interrupts-from-bestcomm-node.txt
0033-EFIKA-fullduplex-prpl_aln.txt
defconfig
v4l.diff
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: MPC5200 and Bestcomm
From: Grant Likely @ 2007-08-13 16:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: linuxppc-embedded
In-Reply-To: <9e4733910708130927l70163a80vf0362ee8649a6c29@mail.gmail.com>
On 8/13/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> We're starting a new MPC5200 project and I'm trying to track down the
> best kernel to start from. Is Sylvain's tree at
> http://www.246tnt.com/mpc52xx/ a good place to start? The git URLs
> from the web page don't work. Everything 5200 related in the trees at
> Secret Labs already appears to be merged.
>
> Most of this work also appears to be in the Open Embedded tree's Ekifa
> support. Is that a better place to start?
It might be. The major problem with MPC5200 is the Ethernet driver.
I believe both Domen and Sylvain have been working on drivers suitable
for arch/powerpc inclusion.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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