* [PATCH v2] Configure PSC4 and PSC5 as UART.
From: Grzegorz Bernacki @ 2009-02-13 16:13 UTC (permalink / raw)
To: linuxppc-dev
On digsy MTC PSC4 and PSC5 should be configured as UART, not PSC3 and PSC4.
Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>
---
Version 2:
- rebased to Ben Herrenschmidt's -next
arch/powerpc/boot/dts/digsy_mtc.dts | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts
index 0e85ebf..4c36186 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -155,18 +155,18 @@
reg = <0x1f00 0x100>;
};
- serial@2400 { // PSC3
- compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
- reg = <0x2400 0x100>;
- interrupts = <2 3 0>;
- };
-
serial@2600 { // PSC4
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
reg = <0x2600 0x100>;
interrupts = <2 11 0>;
};
+ serial@2800 { // PSC5
+ compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
+ reg = <0x2800 0x100>;
+ interrupts = <2 12 0>;
+ };
+
ethernet@3000 {
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
reg = <0x3000 0x400>;
--
1.5.2.2
^ permalink raw reply related
* SCCx in Sync HDLC mode
From: James Black @ 2009-02-13 16:44 UTC (permalink / raw)
To: linuxppc-dev
Is there any work being proposed/done in this area? I'm looking at the
drivers/serial/cpm_uart files and see no support for sync/HDLC SCCx
channels. Can anyone offer some history or insight to this area?
--
Jim Black
Senior Software Engineer
Aztek Networks, Inc.
2477 55th Street, Suite 202
Boulder, CO 80301
www.azteknetworks.com
^ permalink raw reply
* Re: [MPC8272ADS]Problem adding flash partitions inside the device tree
From: Scott Wood @ 2009-02-13 16:53 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: linuxppc-dev
In-Reply-To: <8cad0aa0902130125h496f712bh809cfb1d45d6ad17@mail.gmail.com>
Jean-Michel Hautbois wrote:
> 2009/2/12 Scott Wood <scottwood@freescale.com>:
>> On Thu, Feb 12, 2009 at 03:26:58PM +0100, Jean-Michel Hautbois wrote:
>>> I think that the problem is in the reg part, but I can't understand why.
>>> Isn't it the RAM mpping of my MTD that is the first address ?
>> No, it's the offset into the chipselect.
>>
>> -Scott
>>
>
> OK.
> What means the word #adress-cells BTW ?
It's the number of cells that make up an address. 1 cell for 32-bit
addresses, 2 for 64-bit.
> When should I have 1, 2 or anything else ?
1 cell is sufficient in this case.
-Scott
^ permalink raw reply
* Re: [PATCH 11/13] sdhci: Add quirk for controllers that need IRQ re-init after reset
From: Laurent Pinchart @ 2009-02-13 15:47 UTC (permalink / raw)
To: linuxppc-dev
Cc: sdhci-devel, Arnd Bergmann, Liu Dave, linux-kernel, Ben Dooks,
Pierre Ossman
In-Reply-To: <20090213144738.GK23889@oksana.dev.rtsoft.ru>
[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]
Hi Anton,
On Friday 13 February 2009 15:47:38 Anton Vorontsov wrote:
> FSL eSDHC controllers losing signal/interrupt enable states after
> reset, so we should re-enable them.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/mmc/host/sdhci.c | 7 +++++++
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index eff615d..b308dbf 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -189,6 +189,7 @@ static void sdhci_disable_card_detection(struct
> sdhci_host *host) static void sdhci_reset(struct sdhci_host *host, u8 mask)
> {
> unsigned long timeout;
> + u32 ier = 0; /* shut up gcc */
You should use
u32 uninitialized_var(ier);
instead to avoid generating extra code.
>
> if (host->quirks & SDHCI_QUIRK_NO_CARD_NO_RESET) {
> if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> @@ -196,6 +197,9 @@ static void sdhci_reset(struct sdhci_host *host, u8
> mask) return;
> }
>
> + if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
> + ier = sdhci_readl(host, SDHCI_INT_ENABLE);
> +
> sdhci_writeb(host, mask, SDHCI_SOFTWARE_RESET);
>
> if (mask & SDHCI_RESET_ALL)
> @@ -215,6 +219,9 @@ static void sdhci_reset(struct sdhci_host *host, u8
> mask) timeout--;
> mdelay(1);
> }
> +
> + if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
> + sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
> }
>
> static void sdhci_init(struct sdhci_host *host)
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index 44c820a..5c5a950 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -229,6 +229,8 @@ struct sdhci_host {
> #define SDHCI_QUIRK_NONSTANDARD_CLOCK (1<<19)
> /* Controller does not like fast PIO transfers */
> #define SDHCI_QUIRK_PIO_NEEDS_DELAY (1<<20)
> +/* Controller losing signal/interrupt enable states after reset */
> +#define SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET (1<<21)
>
> int irq; /* Device IRQ */
> void __iomem * ioaddr; /* Mapped address */
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussee de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* LINUX BOOT UP PROBLEM-PPC405 ML403
From: Li Jun (Aaron) @ 2009-02-13 17:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1.1: Type: text/plain, Size: 1197 bytes --]
Hi,
When I try to boot the linux on the Xilinx virtex4 fx ml403 board.
The information below shows up:
----------------------------------------------------------------------------
-
Welcome to ML403 Linux 2.6
Starting system...
mounting /proc: done.
Mounting '/' read-write: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
System started.
starting pid 158, tty '': '/sbin/getty'
process '/sbin/getty -L ttyUL0 9600 vt100' (pid 158) exited. Scheduling it
for r
estart.
starting pid 163, tty '': '/sbin/getty'
process '/sbin/getty -L ttyUL0 9600 vt100' (pid 163) exited. Scheduling it
for r
estart.
starting pid 168, tty '': '/sbin/getty'
----------------------------------------------------------------------------
----------------------
I am using the uart lite 9600, and the inittab of my root file system is as
below:
::sysinit:/etc/init.d/rcS
#::askfirst:-/bin/sh
::ctrlaltdel:/sbin/reboot
::shutdown:/sbin/swapoff -a
::shutdown:/bin/umount -a -r
::restart:/sbin/init
::respawn:/sbin/getty -L ttyUL0 9600 vt100
Anybody can help?
Thanks!
Best regards,
Li Jun
[-- Attachment #1.2: Type: text/html, Size: 6676 bytes --]
[-- Attachment #2: mylinuxboot_2.txt --]
[-- Type: text/plain, Size: 4277 bytes --]
Welcome to the Xilinx Virtex-4 ML403 Evaluation Platform Bootloader Menu!
Please choose a demo by typing in the number of the demo you want to use
Or select a demo using the directional buttons and LCD or VGA display
(Then press the center button to start the selected demo)
1. Virtex-4 Slide Show
2. Web Server Demo
3. Linux Demo
4. QNX Demo
5. USB Demo
6. My own ACE file
7. Load/Restore Flash Images
loaded at: 00400000 004F819C
board data at: 004F6120 004F619C
relocated to: 00404060 004040DC
zimage at: 00404E49 004F5B98
avail ram: 004F9000 04000000
Linux/PPC load: console=ttyUL0,9600 ip=on root=/dev/xsa2 rw
Uncompressing Linux...done.
Now booting the kernel
[ 0.000000] Linux version 2.6.23-rc2 (liju0010@rplinx1) (gcc version 4.1.0) #
19 Thu Feb 12 17:02:45 SGT 2009
[ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 16384
[ 0.000000] Normal 16384 -> 16384
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 16384
[ 0.000000] Built 1 zonelists in Zone order. Total pages: 16256
[ 0.000000] Kernel command line: console=ttyUL0,9600 ip=on root=/dev/xsa2 rw
[ 0.000000] Xilinx INTC #0 at 0x81800000 mapped to 0xFDFFF000
[ 0.000000] PID hash table entries: 256 (order: 8, 1024 bytes)
[ 0.000341] Console: colour dummy device 80x25
[ 0.001046] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.002459] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.027896] Memory: 62780k available (1524k kernel code, 500k data, 96k init,
0k highmem)
[ 0.113286] Mount-cache hash table entries: 512
[ 0.121929] NET: Registered protocol family 16
[ 0.163221] NET: Registered protocol family 2
[ 0.196707] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.197982] TCP established hash table entries: 2048 (order: 2, 16384 bytes)
[ 0.198606] TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.198995] TCP: Hash tables configured (established 2048 bind 2048)
[ 0.199071] TCP reno registered
[ 0.220331] io scheduler noop registered
[ 0.220426] io scheduler anticipatory registered (default)
[ 0.220499] io scheduler deadline registered
[ 0.220823] io scheduler cfq registered
[ 0.309153] uartlite.0: ttyUL0 at MMIO 0x84000000 (irq = 1) is a uartlite
[ 0.310642] console [ttyUL0] enabled
[ 2.270738] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 bloc
ksize
[ 2.363600] xsysace xsysace.0: Xilinx SystemACE revision 1.0.12
[ 2.435897] xsysace xsysace.0: capacity: 1019088 sectors
[ 2.500435] xsa: xsa1 xsa2
[ 2.544344] tun: Universal TUN/TAP device driver, 1.6
[ 2.605239] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 2.682049] mice: PS/2 mouse device common for all mice
[ 2.745383] TCP cubic registered
[ 2.784516] NET: Registered protocol family 1
[ 2.837079] NET: Registered protocol family 17
[ 3.393776] IP-Config: No network devices available.
[ 3.922144] kjournald starting. Commit interval 5 seconds
[ 3.988474] EXT3-fs warning: mounting unchecked fs, running e2fsck is recomme
nded
[ 4.117526] EXT3 FS on xsa2, internal journal
[ 4.170014] EXT3-fs: recovery complete.
[ 4.254147] EXT3-fs: mounted filesystem with ordered data mode.
[ 4.325712] VFS: Mounted root (ext3 filesystem).
[ 4.382081] Freeing unused kernel memory: 96k init
init started: BusyBox v1.7.2 (2007-12-21 20:42:03 SGT)
starting pid 142, tty '': '/etc/init.d/rcS'
Welcome to ML403 Linux 2.6
Starting system...
mounting /proc: done.
Mounting '/' read-write: done.
brining up loopback interface: done.
Mounting /tmp: done.
Starting syslogd: done.
Starting klogd: done.
Starting inetd: done.
System started.
starting pid 158, tty '': '/sbin/getty'
process '/sbin/getty -L ttyUL0 9600 vt100' (pid 158) exited. Scheduling it for r
estart.
starting pid 163, tty '': '/sbin/getty'
process '/sbin/getty -L ttyUL0 9600 vt100' (pid 163) exited. Scheduling it for r
estart.
starting pid 168, tty '': '/sbin/getty'
^ permalink raw reply
* Re: [PATCH 11/13] sdhci: Add quirk for controllers that need IRQ re-init after reset
From: Anton Vorontsov @ 2009-02-13 17:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: sdhci-devel, Arnd Bergmann, Liu Dave, linux-kernel, linuxppc-dev,
Ben Dooks, Pierre Ossman
In-Reply-To: <200902131647.17728.laurentp@cse-semaphore.com>
On Fri, Feb 13, 2009 at 04:47:13PM +0100, Laurent Pinchart wrote:
> Hi Anton,
>
> On Friday 13 February 2009 15:47:38 Anton Vorontsov wrote:
[...]
> > sdhci_host *host) static void sdhci_reset(struct sdhci_host *host, u8 mask)
> > {
> > unsigned long timeout;
> > + u32 ier = 0; /* shut up gcc */
>
> You should use
>
> u32 uninitialized_var(ier);
>
> instead to avoid generating extra code.
Thanks Laurent, will fix.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* MPC8248 IDMA PCI burst
From: Arun Roy @ 2009-02-13 17:38 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
Hi,
I am having some problem with the PCI burst using the MPC8248 IDMA feature. I can get a continuous burst of 2k when transferring data from the system memory to the PCI direction but in the other direction (i.e. PCI to system memory) the PCI burst is fragmented with 32 bytes of fragment. I have verified that the Prefetch bit is set in the POCMR register.
Here are my settings :
DCM : DMA_WRAP=101, SINC=1, DINC=1, S/D=00
STS: 2016
SS_MAX: 2016
BUF_INV: 2048
DTS: 2016
Transfer buffer size is 2048 bytes
BD flags : V=1, W=1, I=1, L=1, BD Len = 1024
Any help will be appreciated.
Thanks
-Arun
[-- Attachment #2: Type: text/html, Size: 3386 bytes --]
^ permalink raw reply
* Re: LINUX BOOT UP PROBLEM-PPC405 ML403
From: Grant Likely @ 2009-02-13 18:08 UTC (permalink / raw)
To: Li Jun (Aaron); +Cc: linuxppc-dev
In-Reply-To: <001101c98dfd$ed7993e0$c86cbba0$@com>
Is there a /dev/ttyUL0 in your root filesystem?
On Fri, Feb 13, 2009 at 10:10 AM, Li Jun (Aaron) <aaronleefly@gmail.com> wrote:
> Hi,
>
> When I try to boot the linux on the Xilinx virtex4 fx ml403 board.
>
>
>
> The information below shows up:
>
> -----------------------------------------------------------------------------
>
> Welcome to ML403 Linux 2.6
>
>
>
> Starting system...
>
> mounting /proc: done.
>
> Mounting '/' read-write: done.
>
> brining up loopback interface: done.
>
> Mounting /tmp: done.
>
> Starting syslogd: done.
>
> Starting klogd: done.
>
> Starting inetd: done.
>
> System started.
>
> starting pid 158, tty '': '/sbin/getty'
>
> process '/sbin/getty -L ttyUL0 9600 vt100' (pid 158) exited. Scheduling it
> for r
>
> estart.
>
> starting pid 163, tty '': '/sbin/getty'
>
> process '/sbin/getty -L ttyUL0 9600 vt100' (pid 163) exited. Scheduling it
> for r
>
> estart.
>
> starting pid 168, tty '': '/sbin/getty'
>
> --------------------------------------------------------------------------------------------------
>
> I am using the uart lite 9600, and the inittab of my root file system is as
> below:
>
> ::sysinit:/etc/init.d/rcS
>
> #::askfirst:-/bin/sh
>
> ::ctrlaltdel:/sbin/reboot
>
> ::shutdown:/sbin/swapoff -a
>
> ::shutdown:/bin/umount -a -r
>
> ::restart:/sbin/init
>
> ::respawn:/sbin/getty -L ttyUL0 9600 vt100
>
>
>
> Anybody can help?
>
>
>
> Thanks!
>
>
>
> Best regards,
>
> Li Jun
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: LINUX BOOT UP PROBLEM-PPC405 ML403
From: Li Jun (Aaron) @ 2009-02-13 18:56 UTC (permalink / raw)
To: 'Grant Likely'; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40902131008s28d27756g8dd3d76ec3bc379f@mail.gmail.com>
Hi Grant,
I can not find the /dev/ttyUL0 in my root filesystem.
Is that the problem? What should I do? Just make a node, like : mknod
/dev/ttyUL0?
I am not familiar with the root filesystem.
Thanks!
Best regards,
Li Jun
-----Original Message-----
From: Grant Likely [mailto:grant.likely@secretlab.ca]=20
Sent: 2009=C4=EA2=D4=C214=C8=D5 2:08
To: Li Jun (Aaron)
Cc: linuxppc-dev@ozlabs.org
Subject: Re: LINUX BOOT UP PROBLEM-PPC405 ML403
Is there a /dev/ttyUL0 in your root filesystem?
On Fri, Feb 13, 2009 at 10:10 AM, Li Jun (Aaron) <aaronleefly@gmail.com>
wrote:
> Hi,
>
> When I try to boot the linux on the Xilinx virtex4 fx ml403 board.
>
>
>
> The information below shows up:
>
>
-------------------------------------------------------------------------=
---
-
>
> Welcome to ML403 Linux 2.6
>
>
>
> Starting system...
>
> mounting /proc: done.
>
> Mounting '/' read-write: done.
>
> brining up loopback interface: done.
>
> Mounting /tmp: done.
>
> Starting syslogd: done.
>
> Starting klogd: done.
>
> Starting inetd: done.
>
> System started.
>
> starting pid 158, tty '': '/sbin/getty'
>
> process '/sbin/getty -L ttyUL0 9600 vt100' (pid 158) exited. =
Scheduling it
> for r
>
> estart.
>
> starting pid 163, tty '': '/sbin/getty'
>
> process '/sbin/getty -L ttyUL0 9600 vt100' (pid 163) exited. =
Scheduling it
> for r
>
> estart.
>
> starting pid 168, tty '': '/sbin/getty'
>
>
-------------------------------------------------------------------------=
---
----------------------
>
> I am using the uart lite 9600, and the inittab of my root file system =
is
as
> below:
>
> ::sysinit:/etc/init.d/rcS
>
> #::askfirst:-/bin/sh
>
> ::ctrlaltdel:/sbin/reboot
>
> ::shutdown:/sbin/swapoff -a
>
> ::shutdown:/bin/umount -a -r
>
> ::restart:/sbin/init
>
> ::respawn:/sbin/getty -L ttyUL0 9600 vt100
>
>
>
> Anybody can help?
>
>
>
> Thanks!
>
>
>
> Best regards,
>
> Li Jun
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] powerpc: New cpu type shows up as "unknown" even when logical PVR is recognized
From: Dave Kleikamp @ 2009-02-13 20:45 UTC (permalink / raw)
To: ppc-dev; +Cc: Paul Mackerras
When identify_cpu() is called a second time with a logical PVR, it only
copies a subset of the cpu_spec structure to avoid overwriting the
performance monitor fields that were initialized based on the real PVR.
If the real PVR is not recognized, the structure is initialized with
default data in which the pvr_mask field is zero. Overriding the default
definition with the one based on the logical PVR does not update the
pvr_mask field. Since the pvr_mask field remains zero, show_cpuinfo()
reports the cpu as "unknown".
identify_cpu() should update the pvr_mask, so that show_cpuinfo() reports
the logical cpu name, as it would if the kernel recognized the real PVR.
For completeness, this patch also updates pvr_value, although its only
use appears to be in booke_wdt_init() setting ident.firmware_version. I'm
not sure which value (the real or logical) is the most useful here, if it
matters at all.
Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..a216fad 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1780,6 +1780,8 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
* performance monitor fields.
*/
if (t->num_pmcs && !s->num_pmcs) {
+ t->pvr_mask = s->pvr_mask;
+ t->pvr_value = s->pvr_value;
t->cpu_name = s->cpu_name;
t->cpu_features = s->cpu_features;
t->cpu_user_features = s->cpu_user_features;
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply related
* Re: [PATCH] pci/msi: Use #ifdefs instead of weak functions
From: Jesse Barnes @ 2009-02-13 21:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linux-kernel, linuxppc-dev, mingo, hpa, linux-pci, tglx
In-Reply-To: <d1c931db79adf22f3506aa0343aec5361600b37e.1232325038.git.michael@ellerman.id.au>
On Sunday, January 18, 2009 4:31 pm Michael Ellerman wrote:
> Weak functions aren't all they're cracked up to be. They lead to
> incorrect binaries with some toolchains, they require us to have empty
> functions we otherwise wouldn't, and the unused code is not elided
> (as of gcc 4.3.2 anyway).
>
> So replace the weak MSI arch hooks with the #define foo foo idiom. We no
> longer need empty versions of arch_setup/teardown_msi_irq().
>
> This is less source (by 1 line!), and results in smaller binaries too:
>
> text data bss dec hex filename
> 9354300 1693916 678424 11726640 b2ef30 build/powerpc/vmlinux-before
> 9354052 1693852 678424 11726328 b2edf8 build/powerpc/vmlinux-after
>
> Also smaller on x86_64 and arm (iop13xx).
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Applied to my linux-next branch, thanks Michael.
--
Jesse Barnes, Intel Open Source Technology Center
^ permalink raw reply
* [PATCH] Reduce hashtable size when using 64kB pages
From: Anton Blanchard @ 2009-02-13 21:57 UTC (permalink / raw)
To: linuxppc-dev
At the moment we size the hashtable based on 4kB pages / 2, even on a
64kB kernel. This results in a hashtable that is much larger than it
needs to be.
Grab the real page size and size the hashtable based on that. Note: this
only works on non hypervisor machines.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 8d5b475..f5bc1b2 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -516,7 +516,7 @@ static int __init htab_dt_scan_pftsize(unsigned long node,
static unsigned long __init htab_get_table_size(void)
{
- unsigned long mem_size, rnd_mem_size, pteg_count;
+ unsigned long mem_size, rnd_mem_size, pteg_count, psize;
/* If hash size isn't already provided by the platform, we try to
* retrieve it from the device-tree. If it's not there neither, we
@@ -534,7 +534,8 @@ static unsigned long __init htab_get_table_size(void)
rnd_mem_size <<= 1;
/* # pages / 2 */
- pteg_count = max(rnd_mem_size >> (12 + 1), 1UL << 11);
+ psize = mmu_psize_defs[mmu_virtual_psize].shift;
+ pteg_count = max(rnd_mem_size >> (psize + 1), 1UL << 11);
return pteg_count << 7;
}
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-02-13 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
Here's 4 small powerpc fixes, a couple are regression in .29, and the
others are nasty enough bugs with trivial enough fixes that I deemed
then ok to go into .29 (and back into stable).
The following changes since commit b578f3fcca1e78624dfb5f358776e63711d7fda2:
Linus Torvalds (1):
Merge git://git.infradead.org/users/cbou/battery-2.6.29
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Dave Hansen (1):
powerpc/mm: Fix numa reserve bootmem page selection
Geoff Levand (1):
powerpc/ps3: Move ps3_mm_add_memory to device_initcall
Michael Neuling (1):
powerpc/vsx: Fix VSX alignment handler for regs 32-63
Philippe Gerum (1):
powerpc/mm: Fix _PAGE_CHG_MASK to protect _PAGE_SPECIAL
arch/powerpc/include/asm/pgtable-4k.h | 2 +-
arch/powerpc/include/asm/pgtable-64k.h | 2 +-
arch/powerpc/include/asm/pgtable-ppc32.h | 3 ++-
arch/powerpc/kernel/align.c | 7 ++++++-
arch/powerpc/mm/numa.c | 5 +++--
arch/powerpc/platforms/ps3/mm.c | 2 +-
6 files changed, 14 insertions(+), 7 deletions(-)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, ftrace: use create_branch lib function
From: Michael Ellerman @ 2009-02-14 13:49 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Frederic Weisbecker, Ingo Molnar, Andrew Morton
In-Reply-To: <20090213150147.180922180@goodmis.org>
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
On Fri, 2009-02-13 at 10:00 -0500, Steven Rostedt wrote:
> plain text document attachment
> (0002-powerpc-ftrace-use-create_branch-lib-function.patch)
> From: Steven Rostedt <srostedt@redhat.com>
>
> Impact: clean up, remove duplicate code
>
> When ftrace was first ported to PowerPC, there existed a
> create_function_call that would create the instruction to make a call
> to a given address. Unfortunately, this call expected to write to
> the address it was given, and since it used the address to calculate
> the offset, it could not be faked.
>
> ftrace needed a way to create the instruction without actually writing
> that instruction to the text section. So ftrace had to implement its
> own code.
>
> Now we have create_branch in the code patching library, which does
> exactly what ftrace needs. This patch replaces ftrace's implementation
> with the library function.
Thanks for doing this, I was going to once the ftrace code had settled a
little but you beat me to it.
> @@ -46,17 +41,10 @@ ftrace_call_replace(unsigned long ip, unsigned long addr, int link)
> {
> unsigned int op;
>
> - /*
> - * It would be nice to just use create_function_call, but that will
> - * update the code itself. Here we need to just return the
> - * instruction that is going to be modified, without modifying the
> - * code.
> - */
> addr = GET_ADDR(addr);
>
> /* if (link) set op to 'bl' else 'b' */
> - op = 0x48000000 | (link ? 1 : 0);
> - op |= (ftrace_calc_offset(ip, addr) & 0x03fffffc);
> + op = create_branch((unsigned int *)ip, addr, link ? 1 : 0);
If I was feeling nit-picky I'd say you should use:
op = create_branch((unsigned int *)ip, addr, link ? BRANCH_SET_LINK : 0);
But admittedly we're unlikely to ever change the flag handling, so it's
probably not worth the effort of a respin (or this email :).
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: New cpu type shows up as "unknown" even when logical PVR is recognized
From: Michael Ellerman @ 2009-02-14 14:00 UTC (permalink / raw)
To: Dave Kleikamp; +Cc: ppc-dev, Paul Mackerras
In-Reply-To: <1234557928.10378.8.camel@norville.austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]
On Fri, 2009-02-13 at 14:45 -0600, Dave Kleikamp wrote:
> When identify_cpu() is called a second time with a logical PVR, it only
> copies a subset of the cpu_spec structure to avoid overwriting the
> performance monitor fields that were initialized based on the real PVR.
>
> If the real PVR is not recognized, the structure is initialized with
> default data in which the pvr_mask field is zero. Overriding the default
> definition with the one based on the logical PVR does not update the
> pvr_mask field. Since the pvr_mask field remains zero, show_cpuinfo()
> reports the cpu as "unknown".
>
> identify_cpu() should update the pvr_mask, so that show_cpuinfo() reports
> the logical cpu name, as it would if the kernel recognized the real PVR.
>
> For completeness, this patch also updates pvr_value, although its only
> use appears to be in booke_wdt_init() setting ident.firmware_version. I'm
> not sure which value (the real or logical) is the most useful here, if it
> matters at all.
>
> Signed-off-by: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
>
> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
> index 923f87a..a216fad 100644
> --- a/arch/powerpc/kernel/cputable.c
> +++ b/arch/powerpc/kernel/cputable.c
> @@ -1780,6 +1780,8 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
> * performance monitor fields.
> */
> if (t->num_pmcs && !s->num_pmcs) {
> + t->pvr_mask = s->pvr_mask;
> + t->pvr_value = s->pvr_value;
> t->cpu_name = s->cpu_name;
> t->cpu_features = s->cpu_features;
> t->cpu_user_features = s->cpu_user_features;
Seems like we'd be better off copying the whole structure, and then
putting back the performance monitor fields. So we don't end up with
another bug if something's added to struct cpu_spec.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] powerpc, ftrace: use create_branch lib function
From: Steven Rostedt @ 2009-02-14 15:20 UTC (permalink / raw)
To: Michael Ellerman
Cc: linux-kernel, linuxppc-dev, Steven Rostedt, Paul Mackerras,
Frederic Weisbecker, Ingo Molnar, Andrew Morton
In-Reply-To: <1234619366.10265.3.camel@localhost>
On Sun, 15 Feb 2009, Michael Ellerman wrote:
> >
> > /* if (link) set op to 'bl' else 'b' */
> > - op = 0x48000000 | (link ? 1 : 0);
> > - op |= (ftrace_calc_offset(ip, addr) & 0x03fffffc);
> > + op = create_branch((unsigned int *)ip, addr, link ? 1 : 0);
>
> If I was feeling nit-picky I'd say you should use:
>
> op = create_branch((unsigned int *)ip, addr, link ? BRANCH_SET_LINK : 0);
>
>
> But admittedly we're unlikely to ever change the flag handling, so it's
> probably not worth the effort of a respin (or this email :).
Not worth the effort of a respin, I agree.
But it would be worth the effort of a clean up patch ;-)
Not for "oh this flag might change", but for reviewers looking at the
code and knowing exactly what that '1' means.
-- Steve
^ permalink raw reply
* 4xx tree updates
From: Josh Boyer @ 2009-02-14 19:47 UTC (permalink / raw)
To: linuxppc-dev
Hi All,
I've been rather busy lately and have unfortunately gotten behind on
updating the 4xx tree. I spent some time this weekend looking over
the patches queued up, and fortunately there were not too many. I'm
doing some build testing of these 4 today:
commit 6c7120902305b3a21460cd2f0f917a39307df566
Author: Madhulika Madishetty <mmadishetty@amcc.com>
AMCC PPC 460SX redwood SoC platform initial framework
commit 41b6a085e48d0d9e1200946755f49f31dd930137
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/4xx: Enable PCI domains on 4xx
commit 018f76ec516c09a5381e517d0739d377a60ec0d5
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
powerpc/4xx: Add missing USB and i2c devices to Canyonlands
commit e12401222f749c37277a313d631dc024bbfd3b00
Author: Yuri Tikhonov <yur@emcraft.com>
powerpc/44x: Support for 256KB PAGE_SIZE
Barring any unforseen issues with these, I'll push them to my
next branch tomorrow and ask Ben to pull them shortly thereafter.
If I've missed any patches that should be headed for 2.6.30, please
let me know!
josh
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
From: Sam Ravnborg @ 2009-02-14 19:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-rt-users, linux-kernel, linuxppc-dev, Steven Rostedt,
Paul Mackerras
In-Reply-To: <20090204212612.GN22608@elte.hu>
On Wed, Feb 04, 2009 at 10:26:12PM +0100, Ingo Molnar wrote:
>
> * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
>
> > This patch gives arches more freedom on overwriting CFLAGS, specifically
> > on PowerPC we want to remove -fno-omit-frame-pointer flag.
> >
> > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > ---
> > Makefile | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 7715b2c..d1ba93f 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -525,8 +525,6 @@ else
> > KBUILD_CFLAGS += -O2
> > endif
> >
> > -include $(srctree)/arch/$(SRCARCH)/Makefile
> > -
> > ifneq (CONFIG_FRAME_WARN,0)
> > KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
> > endif
> > @@ -555,6 +553,8 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
> > KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
> > endif
> >
> > +include $(srctree)/arch/$(SRCARCH)/Makefile
> > +
> > # arch Makefile may override CC so keep this after arch Makefile is included
> > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> > CHECKFLAGS += $(NOSTDINC_FLAGS)
> > --
>
> this patch is really for Sam to judge - Cc:-ed him.
If we move the include further down then the following:
# Force gcc to behave correct even for buggy distributions
# Arch Makefiles may override this setting
KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
will most likely fail.
If popwerpc needs to get rid of "-fno-omit-frame-pointer" then
we need a way to express this at KConfig level and NOT by doing
some tricks with CFLAGS.
Sam
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
From: Sam Ravnborg @ 2009-02-14 19:58 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-rt-users, linux-kernel, linuxppc-dev, Steven Rostedt,
Paul Mackerras, Ingo Molnar
In-Reply-To: <1234324294.29851.0.camel@pasglop>
On Wed, Feb 11, 2009 at 02:51:34PM +1100, Benjamin Herrenschmidt wrote:
> On Wed, 2009-02-04 at 22:26 +0100, Ingo Molnar wrote:
> > > +include $(srctree)/arch/$(SRCARCH)/Makefile
> > > +
> > > # arch Makefile may override CC so keep this after arch Makefile is
> > included
> > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC)
> > -print-file-name=include)
> > > CHECKFLAGS += $(NOSTDINC_FLAGS)
> > > --
> >
> > this patch is really for Sam to judge - Cc:-ed him.
>
> Sam ? I have a few more powerpc patches depending on that one... so I'd
> like to know if it's totally doomed or not :-)
See my answer to the mail from Ingo.
We really need to do this on Kconfig level it at all possible.
Sam
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
From: Ingo Molnar @ 2009-02-14 22:03 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-rt-users, linux-kernel, linuxppc-dev, Steven Rostedt,
Paul Mackerras
In-Reply-To: <20090214195702.GB1241@uranus.ravnborg.org>
* Sam Ravnborg <sam@ravnborg.org> wrote:
> On Wed, Feb 04, 2009 at 10:26:12PM +0100, Ingo Molnar wrote:
> >
> > * Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> >
> > > This patch gives arches more freedom on overwriting CFLAGS, specifically
> > > on PowerPC we want to remove -fno-omit-frame-pointer flag.
> > >
> > > Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> > > ---
> > > Makefile | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 7715b2c..d1ba93f 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -525,8 +525,6 @@ else
> > > KBUILD_CFLAGS += -O2
> > > endif
> > >
> > > -include $(srctree)/arch/$(SRCARCH)/Makefile
> > > -
> > > ifneq (CONFIG_FRAME_WARN,0)
> > > KBUILD_CFLAGS += $(call cc-option,-Wframe-larger-than=${CONFIG_FRAME_WARN})
> > > endif
> > > @@ -555,6 +553,8 @@ ifdef CONFIG_DEBUG_SECTION_MISMATCH
> > > KBUILD_CFLAGS += $(call cc-option, -fno-inline-functions-called-once)
> > > endif
> > >
> > > +include $(srctree)/arch/$(SRCARCH)/Makefile
> > > +
> > > # arch Makefile may override CC so keep this after arch Makefile is included
> > > NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
> > > CHECKFLAGS += $(NOSTDINC_FLAGS)
> > > --
> >
> > this patch is really for Sam to judge - Cc:-ed him.
>
> If we move the include further down then the following:
>
> # Force gcc to behave correct even for buggy distributions
> # Arch Makefiles may override this setting
> KBUILD_CFLAGS += $(call cc-option, -fno-stack-protector)
>
> will most likely fail.
ah, ok. (I long ago made the mental note of "dont change the toplevel Makefile
if you can avoid it" - this reinforces that.)
> If popwerpc needs to get rid of "-fno-omit-frame-pointer" then
> we need a way to express this at KConfig level and NOT by doing
> some tricks with CFLAGS.
Here is what we have in the toplevel Makefile at the moment:
ifdef CONFIG_FRAME_POINTER
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
else
KBUILD_CFLAGS += -fomit-frame-pointer
endif
My original suggestion (more than a week ago) was to make PPC always
select FRAME_POINTERS.
It was pointed out that -fno-omit-frame-pointers (i.e.: generate frame
pointers) not only makes the code less optimal on PPC, but it can also be
miscompiled.
But instrumentation really needs to know whether __builtin_return_address(1)
[etc] is reliable, whether stack tracing is fast - and other details - and PPC
is the odd one out.
So the question is: even with FRAME_POINTERS disabled on PPC, is
__builtin_return_address(1)/(2) reliable, and is save_stack_trace() fast? (i.e.
can it walk down the stack frame efficiently, or does it have to scan the full
kernel stack) I.e. does PPC have all the material advantages of frame pointers?
Ingo
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
From: Benjamin Herrenschmidt @ 2009-02-15 0:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-rt-users, linux-kernel, linuxppc-dev, Steven Rostedt,
Paul Mackerras, Sam Ravnborg
In-Reply-To: <20090214220326.GA5200@elte.hu>
On Sat, 2009-02-14 at 23:03 +0100, Ingo Molnar wrote:
>
> So the question is: even with FRAME_POINTERS disabled on PPC, is
> __builtin_return_address(1)/(2) reliable, and is save_stack_trace() fast? (i.e.
> can it walk down the stack frame efficiently, or does it have to scan the full
> kernel stack) I.e. does PPC have all the material advantages of frame pointers?
Yes, we do. We effectively have frame pointers in fact, they may only be
omitted in leaf functions but then gcc __builtin_return_address() knows
how to handle that afaik.
Cheers,
Ben.
^ permalink raw reply
* OpenPIC / CPM2 PIC and cascading interrupt priorities
From: Guillaume Knispel @ 2009-02-15 4:50 UTC (permalink / raw)
To: Linuxppc-dev
Hi,
I'm programming a board with an MPC8555E on which an external chip can
raise low priority interrupts through the port C of the CPM2. Under
nominal conditions it generates few interrupts, but they take a
relatively long time to be processed.
I also use some CPM2 controllers in such a way that their interrupts
need to be served with a short latency. At first I thought that this
would not be a problem if IRQF_DISABLED is not set for the port C ISR,
because the CPM2 controller interrupt has a higher priority.
But the thing is: the primary interrupt controller of the MPC8555E is
an OpenPIC and the CPM2 PIC is cascaded behind.
=46rom the behavior I observe and if I understand both Linux code and the
MPC8555E manual correctly, if the CPM2 PIC is idle and then a port C
interrupt arrives on it, it will put its code in SIVEC and send a
signal to the OpenPIC, which will assert the interrupt signal of the
core, then some assembly language magic happens and eventually do_IRQ()
is called with external interrupts masked, which calls *handle_irq
which in this case is cpm2_cascade() which is consistently written in
every platform where it exists as :
static void cpm2_cascade(unsigned int irq, struct irq_desc *desc)
{
int cascade_irq;
while ((cascade_irq =3D cpm2_get_irq()) >=3D 0)
generic_handle_irq(cascade_irq);
desc->chip->eoi(irq);
}
cascade_irq will be retrieved thanks to SIVEC and this time the flow
handler will be handle_edge_irq (set in cpm2_set_irq_type() ) which
will ack it (to the CPM2 PIC) and call the ISR (IRQF_DISABLED not set).
Now if the CPM2 controller interrupt occurs while the port C ISR is
running (at a higher CPM2 PIC priority), the CPM2 PIC will tell the
OpenPIC. But the OpenPIC won't interrupt the core again because for the
OpenPIC this is just yet another CPM2 interrupt, the same that the one
being handled, which has not yet been cleared by the ->eio() call at the
end of cpm2_cascade.
So, IRQF_DISABLED or not IRQF_DISABLED, the port C ISR won't be
interrupted by the controller ISR.
Now the big question: does anybody think it could be interesting to
reorganize the Linux irq layers such as the priorities of cascaded
interrupts are respected (that would need some changes in the
architecture independent code), or is this a stupid idea and I should
just use a tasklet?
Cheers,
Guillaume KNISPEL
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: Include arch Makefiles as late as possible
From: Ingo Molnar @ 2009-02-15 8:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-rt-users, linux-kernel, linuxppc-dev, Steven Rostedt,
Paul Mackerras, Sam Ravnborg
In-Reply-To: <1234657196.26036.86.camel@pasglop>
* Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Sat, 2009-02-14 at 23:03 +0100, Ingo Molnar wrote:
> >
> > So the question is: even with FRAME_POINTERS disabled on PPC, is
> > __builtin_return_address(1)/(2) reliable, and is save_stack_trace() fast? (i.e.
> > can it walk down the stack frame efficiently, or does it have to scan the full
> > kernel stack) I.e. does PPC have all the material advantages of frame pointers?
>
> Yes, we do. We effectively have frame pointers in fact, they may only be
> omitted in leaf functions but then gcc __builtin_return_address() knows
> how to handle that afaik.
So basically we want to define FRAME_POINTERS on PPC, but do not want
the -fno-omit-frame-pointers flag.
Originally (many moons ago) FRAME_POINTER _was_ just the toplevel Makefile
detail, but these days we've got a handful of secondary uses as well,
expressing the reliability of backtraces in essence.
We could split the whole option (affecting lots of files), or we could zap
that compiler flag in the PPC case - it is only PPC that worries about this
anyway.
Ingo
^ permalink raw reply
* Re: 4xx tree updates
From: Felix Radensky @ 2009-02-15 13:31 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20090214194732.GA30783@zod.rchland.ibm.com>
Josh Boyer-4 wrote:
>
> Hi All,
>
> I've been rather busy lately and have unfortunately gotten behind on
> updating the 4xx tree. I spent some time this weekend looking over
> the patches queued up, and fortunately there were not too many. I'm
> doing some build testing of these 4 today:
>
> commit 6c7120902305b3a21460cd2f0f917a39307df566
> Author: Madhulika Madishetty <mmadishetty@amcc.com>
>
> AMCC PPC 460SX redwood SoC platform initial framework
>
> commit 41b6a085e48d0d9e1200946755f49f31dd930137
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> powerpc/4xx: Enable PCI domains on 4xx
>
> commit 018f76ec516c09a5381e517d0739d377a60ec0d5
> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> powerpc/4xx: Add missing USB and i2c devices to Canyonlands
>
> commit e12401222f749c37277a313d631dc024bbfd3b00
> Author: Yuri Tikhonov <yur@emcraft.com>
>
> powerpc/44x: Support for 256KB PAGE_SIZE
>
> Barring any unforseen issues with these, I'll push them to my
> next branch tomorrow and ask Ben to pull them shortly thereafter.
>
> If I've missed any patches that should be headed for 2.6.30, please
> let me know!
>
> josh
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
Hi, Josh
What about 4xx SPI driver ? Is it planned for inclusion in 2.6.30 ?
Thanks.
Felix.
--
View this message in context: http://www.nabble.com/4xx-tree-updates-tp22016711p22022614.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* The state of Serial Rapid IO on MPC8548
From: Felix Radensky @ 2009-02-15 13:41 UTC (permalink / raw)
To: linuxppc-dev
Hi
I've noticed that in 2.6.29-rc5 Serial Rapid IO is only available
for 86xx processors. There's also no Freescale BSP for 8548.
What is the best source of SRIO driver for this CPU ? Can I
simply enable SRIO support in mainline kernel for 85xx and hope
it will work ?
Thanks.
Felix.
--
View this message in context: http://www.nabble.com/The-state-of-Serial-Rapid-IO-on-MPC8548-tp22022709p22022709.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ 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;
as well as URLs for NNTP newsgroup(s).