Re: [PATCH 5/5] powerpc: Increase NR_IRQS Kconfig maximum to 32768
On Sun, Jan 31, 2010 at 10:14:03PM +1100, Anton Blanchard wrote: With dynamic irq descriptors the overhead of a large NR_IRQS is much lower than it used to be. With more MSI-X capable adapters and drivers exploiting multiple vectors we may as well allow the user to increase it beyond the current maximum of 512. 32768 seems large enough that we'd never have to bump it again (although I bet my prediction is horribly wrong). It boot tests OK and the vmlinux footprint increase is only around 500kB due to: Only 1/2 MB? I'm running Linux on 12 year old PPC machines which have 16MB or RAM (ok, they are still running an old kernel, but a few patches like this and they wont't even boot). The kernels I have are well below 1MB, code+data+bss. Yes it is configurable, thanks, and 64 is enough for these machines (8259 plus an MPIC), so it's not that crucial. What I object to is calling 1/2MB negligible. Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 5/5] powerpc: Increase NR_IRQS Kconfig maximum to 32768
On Mon, 2010-02-01 at 10:09 +0100, Gabriel Paubert wrote: On Sun, Jan 31, 2010 at 10:14:03PM +1100, Anton Blanchard wrote: With dynamic irq descriptors the overhead of a large NR_IRQS is much lower than it used to be. With more MSI-X capable adapters and drivers exploiting multiple vectors we may as well allow the user to increase it beyond the current maximum of 512. 32768 seems large enough that we'd never have to bump it again (although I bet my prediction is horribly wrong). It boot tests OK and the vmlinux footprint increase is only around 500kB due to: Only 1/2 MB? I'm running Linux on 12 year old PPC machines which have 16MB or RAM (ok, they are still running an old kernel, but a few patches like this and they wont't even boot). The kernels I have are well below 1MB, code+data+bss. Yes it is configurable, thanks, and 64 is enough for these machines (8259 plus an MPIC), so it's not that crucial. What I object to is calling 1/2MB negligible. Yeah well, all Anton did was to push up the -max- value you can set in the config, not the default :-) But yeah, it's not negligible per-se. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/pci: Add calls to set_pcie_port_type() and set_pcie_hotplug_bridge()
Hi Ben, Benjamin Herrenschmidt wrote: Breno, can you test ? Also if you could give a quick spin to the other ones too make sure they don't break anything else, it would be great ! I tested and also asked my team to test and the changes work fine, fixing the problem. Also, we did a regression test and nothing seem to be broken. Thanks, Breno ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add DMA mask to MPSC serial and network and UART device to serial
Benjamin Herrenschmidt wrote:
On Fri, 2010-01-29 at 18:04 -0600, Corey Minyard wrote:
From: Corey Minyard cminy...@mvista.com
The MPSC drivers that use DMA need to set coherent_dma_mask to allow
dma_alloc_xxx routines to work properly. Also, the mpsc serial driver
needed to set pi-port.dev to register properly. With these fixes,
the MPSC drivers seem to work again.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
Is that enough ? Since 2.6.31 we also need the dma ops to be filled
properly and obviously that isn't going to happen for random platform
devices... Or are those initialized elsewhere by your platform code ? In
which case it might be a good place to also set the coherent mask...
That's done in ppc_dflt_bus_notify(), but that didn't seem an appropriate
place to do this. If it is, it's easy enough to add it there, but that
would
mean it would get set for all devices on any type of ppc system.
-corey
Maybe we should have a more generic way to set the default dma
information (including ops, masks etc...) for use by platform,
of_platform etc... devices.
Cheers,
Ben.
I'm not really sure about where to set the coherent_dma_mask, it seems
like a more general place would be better but I couldn't find it.
Without these, the console stops working after the switchover andantipode
the network driver fails to allocate buffers. With these, my board
boots up and works fine.
Index: linux-2.6.31/drivers/serial/mpsc.c
===
--- linux-2.6.31.orig/drivers/serial/mpsc.c
+++ linux-2.6.31/drivers/serial/mpsc.c
@@ -2071,6 +2071,9 @@ static int mpsc_drv_probe(struct platfor
if (!(rc = mpsc_drv_map_regs(pi, dev))) {
mpsc_drv_get_platform_data(pi, dev, dev-id);
+ dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
+ pi-port.dev = dev-dev;
+
if (!(rc = mpsc_make_ready(pi))) {
spin_lock_init(pi-tx_lock);
if (!(rc = uart_add_one_port(mpsc_reg,
Index: linux-2.6.31/drivers/net/mv643xx_eth.c
===
--- linux-2.6.31.orig/drivers/net/mv643xx_eth.c
+++ linux-2.6.31/drivers/net/mv643xx_eth.c
@@ -2916,7 +2916,7 @@ static int mv643xx_eth_probe(struct plat
mp-shared = platform_get_drvdata(pd-shared);
mp-base = mp-shared-base + 0x0400 + (pd-port_number 10);
mp-port_num = pd-port_number;
-
+ pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
mp-dev = dev;
set_params(mp, pd);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BSE-IP
I'm hoping someone can offer some advice on this:
I'm working with an embedded platform that does not pass anything from
firmware. I'm just trying to get some activity out the serial console at
this stage. simpleImage.bseip compiled with the following bseip.dts seems
to freeze before anything is written to the console. I'm assuming the
standard 8xx code will pickup this device tree, and work from there. Is
this correct? Shouldn't I see some output?
/dts-v1/;
/ {
model = BSEIP;
compatible = fsl,bseip;
#address-cells = 1;
#size-cells = 1;
cpus {
#address-cells = 1;
#size-cells = 0;
PowerPC,8...@0 {
compatible = PowerPC,8xx;
device_type = cpu;
reg = 0x0;
d-cache-line-size = 8;// 8
bytes
per line
i-cache-line-size = 8;// 8
bytes
per line
d-cache-size = 0x0400;// L1,
1K
i-cache-size = 0x0800;// L1,
2K
timebase-frequency = 4800;
bus-frequency = 4800;
clock-frequency = 4800;
interrupts = 15 2;
// decrementer interrupt
interrupt-parent = PIC;
};
};
memory {
device_type = memory;
reg = 0 0x100;
};
s...@ff00 {
compatible = fsl,mpc823, fsl,pq1-soc;
#address-cells = 1;
#size-cells = 1;
device_type = soc;
ranges = 0 0xff00 0x4000;
reg = 0xff00 0x4000;
bus-frequency = 4800;
PIC: interrupt-control...@0 {
interrupt-controller;
#interrupt-cells = 2;
reg = 0 0x24;
compatible = fsl,mpc823-pic,
fsl,pq1-pic;
};
pcm...@80 {
#address-cells = 3;
#interrupt-cells = 1;
#size-cells = 2;
compatible = fsl,pq-pcmcia;
device_type = pcmcia;
reg = 0x80 0x80;
interrupt-parent = PIC;
interrupts = 13 1;
};
c...@9c0 {
#address-cells = 1;
#size-cells = 1;
compatible = fsl,mpc823-cpm,
fsl,cpm1;
command-proc = 0x9c0;
interrupts = 0; // cpm error
interrupt
interrupt-parent = CPM_PIC;
reg = 0x9c0 0x40;
ranges;
mu...@2000 {
#address-cells = 1;
#size-cells = 1;
ranges = 0 0x2000
0x2000;
d...@0 {
compatible =
fsl,cpm-muram-data;
reg = 0
0x1c00;
};
};
b...@9f0 {
compatible =
fsl,mpc823-brg,
fsl,cpm1-brg,
fsl,cpm-brg;
reg = 0x9f0 0x10;
clock-frequency =
4800;
};
CPM_PIC: interrupt-control...@930 {
interrupt-controller;
#interrupt-cells = 1;
interrupts = 5 2 0 2;
interrupt-parent = PIC;
reg = 0x930 0x20;
compatible =
fsl,mpc823-cpm-pic,
Re: BSE-IP
dan.g...@faa.gov wrote:
I'm hoping someone can offer some advice on this:
I'm working with an embedded platform that does not pass anything from
firmware. I'm just trying to get some activity out the serial console at
this stage. simpleImage.bseip compiled with the following bseip.dts seems
to freeze before anything is written to the console. I'm assuming the
standard 8xx code will pickup this device tree, and work from there. Is
this correct? Shouldn't I see some output?
Has your firmware already set up the serial port? cpm-serial doesn't make
assumptions about specific addresses, but it does assume that the BRG, pins,
etc. have been set up for the serial port to work.
If this isn't the case, you'll need to do it from a custom bootwrapper platform
file.
d-cache-line-size = 8; // 8
bytes
per line
i-cache-line-size = 8; // 8
bytes
per line
Shouldn't this be 16 bytes?
s...@ff00 {
Is this the correct IMMR address for your firmware?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/10] arch/powerpc: Fix continuation line formats
On Mon, 2010-02-01 at 13:16 +1100, Benjamin Herrenschmidt wrote:
On Sun, 2010-01-31 at 12:02 -0800, Joe Perches wrote:
String constants that are continued on subsequent lines with \
are not good.
Signed-off-by: Joe Perches j...@perches.com
You want me to take that in the powerpc tree ?
Yes please.
A minor glitch below tho...
@@ -349,7 +349,7 @@ static int __init nvram_create_os_partition(void)
rc = ppc_md.nvram_write((char *)seq_init, sizeof(seq_init),
tmp_index);
if (rc = 0) {
printk(KERN_ERR nvram_create_os_partition: nvram_write
- failed (%d)\n, rc);
+ failed (%d)\n, rc);
return rc;
}
The above is objectionable :-)
Can you drop that section or do you need another patch?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: BSE-IP
dan.g...@faa.gov wrote: Has your firmware already set up the serial port? cpm-serial doesn't make assumptions about specific addresses, but it does assume that the BRG, pins, etc. have been set up for the serial port to work. Yes. Or, so I thought. First, I interrupt the bootstrap with Esc. Then, I load the image into RAM with 'load simpleImage.bseip 20' then 'go 20'. All of which is echo'd out the serial console by the firmware. I assumed that the low-level setups were complete. However, in the old ppc/boot/m8xx_tty.c there is some initialization for SMC1 and the BRG (serial_init()). Where should I do this in the new model? Is platform_specific_init() the right place? That'd be the place -- though it's also possible that it is already set up and the old code simply didn't assume it, and the problem is somewhere else. If you don't have an external debugger, you may want to dump some registers from the firmware prompt and determine where it set up the tx ring, and use that for early debugging. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc/ps3 Update ps3_defconfig
Subject: powerpc/ps3 Update ps3_defconfig Refresh ps3_defconfig to latest kernel sources and change these kernel config options: o CONFIG_USB_ANNOUNCE_NEW_DEVICES: n - y o CONFIG_USB_EHCI_TT_NEWSCHED: n - y o CONFIG_CMDLINE_BOOL: n - y o CONFIG_CMDLINE: n - Signed-off-by: Geoff Levand geoffrey.lev...@am.sony.com --- Hi Ben, Please apply for 2.6.33. -Geoff arch/powerpc/configs/ps3_defconfig | 155 ++--- 1 file changed, 109 insertions(+), 46 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.31-rc7 -# Mon Aug 24 17:38:50 2009 +# Linux kernel version: 2.6.33-rc6 +# Mon Feb 1 10:18:13 2010 # CONFIG_PPC64=y @@ -9,6 +9,7 @@ CONFIG_PPC64=y # Processor support # CONFIG_PPC_BOOK3S_64=y +# CONFIG_PPC_BOOK3E_64 is not set CONFIG_PPC_BOOK3S=y # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y @@ -22,6 +23,7 @@ CONFIG_PPC_STD_MMU_64=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_PPC_HAVE_PMU_SUPPORT=y +CONFIG_PPC_PERF_CTRS=y CONFIG_SMP=y CONFIG_NR_CPUS=2 CONFIG_64BIT=y @@ -35,7 +37,9 @@ CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y +CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_IRQ_PER_CPU=y +CONFIG_NR_IRQS=512 CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y @@ -60,6 +64,7 @@ CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set +CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y @@ -86,11 +91,13 @@ CONFIG_POSIX_MQUEUE_SYSCTL=y # # RCU Subsystem # -CONFIG_CLASSIC_RCU=y -# CONFIG_TREE_RCU is not set -# CONFIG_PREEMPT_RCU is not set +CONFIG_TREE_RCU=y +# CONFIG_TREE_PREEMPT_RCU is not set +# CONFIG_TINY_RCU is not set +# CONFIG_RCU_TRACE is not set +CONFIG_RCU_FANOUT=64 +# CONFIG_RCU_FANOUT_EXACT is not set # CONFIG_TREE_RCU_TRACE is not set -# CONFIG_PREEMPT_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 # CONFIG_GROUP_SCHED is not set @@ -108,6 +115,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set +# CONFIG_RD_LZO is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_ANON_INODES=y @@ -128,21 +136,22 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y -CONFIG_HAVE_PERF_COUNTERS=y +CONFIG_HAVE_PERF_EVENTS=y # -# Performance Counters +# Kernel Performance Events And Counters # +CONFIG_PERF_EVENTS=y +CONFIG_EVENT_PROFILE=y # CONFIG_PERF_COUNTERS is not set +# CONFIG_DEBUG_PERF_USE_VMALLOC is not set CONFIG_VM_EVENT_COUNTERS=y -# CONFIG_STRIP_ASM_SYMS is not set # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y -CONFIG_MARKERS=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set @@ -154,12 +163,14 @@ CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y +CONFIG_HAVE_DMA_API_DEBUG=y # # GCOV-based kernel profiling # # CONFIG_GCOV_KERNEL is not set -# CONFIG_SLOW_WORK is not set +CONFIG_SLOW_WORK=y +# CONFIG_SLOW_WORK_DEBUG is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y @@ -180,14 +191,41 @@ CONFIG_BLOCK_COMPAT=y # IO Schedulers # CONFIG_IOSCHED_NOOP=y -CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y -CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set -# CONFIG_DEFAULT_CFQ is not set +CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set -CONFIG_DEFAULT_IOSCHED=anticipatory +CONFIG_DEFAULT_IOSCHED=cfq +# CONFIG_INLINE_SPIN_TRYLOCK is not set +# CONFIG_INLINE_SPIN_TRYLOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK is not set +# CONFIG_INLINE_SPIN_LOCK_BH is not set +# CONFIG_INLINE_SPIN_LOCK_IRQ is not set +# CONFIG_INLINE_SPIN_LOCK_IRQSAVE is not set +# CONFIG_INLINE_SPIN_UNLOCK is not set +# CONFIG_INLINE_SPIN_UNLOCK_BH is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQ is not set +# CONFIG_INLINE_SPIN_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_READ_TRYLOCK is not set +# CONFIG_INLINE_READ_LOCK is not set +# CONFIG_INLINE_READ_LOCK_BH is not set +# CONFIG_INLINE_READ_LOCK_IRQ is not set +# CONFIG_INLINE_READ_LOCK_IRQSAVE is not set +# CONFIG_INLINE_READ_UNLOCK is not set +# CONFIG_INLINE_READ_UNLOCK_BH is not set +# CONFIG_INLINE_READ_UNLOCK_IRQ is not set +# CONFIG_INLINE_READ_UNLOCK_IRQRESTORE is not set +# CONFIG_INLINE_WRITE_TRYLOCK is not set +# CONFIG_INLINE_WRITE_LOCK is not set +# CONFIG_INLINE_WRITE_LOCK_BH is not set +# CONFIG_INLINE_WRITE_LOCK_IRQ is not set +# CONFIG_INLINE_WRITE_LOCK_IRQSAVE is not set +# CONFIG_INLINE_WRITE_UNLOCK is not set +#
[PATCH] powerpc: Set the port device in the mpsc serial driver
From: Corey Minyard cminy...@mvista.com
The mpsc serial driver needx to set the port's device tree element
to register properly.
Signed-off-by: Corey Minyard cminy...@mvista.com
---
Index: linux-2.6/drivers/serial/mpsc.c
===
--- linux-2.6.orig/drivers/serial/mpsc.c
+++ linux-2.6/drivers/serial/mpsc.c
@@ -2070,6 +2070,7 @@ static int mpsc_drv_probe(struct platfor
if (!(rc = mpsc_drv_map_regs(pi, dev))) {
mpsc_drv_get_platform_data(pi, dev, dev-id);
+ pi-port.dev = dev-dev;
if (!(rc = mpsc_make_ready(pi))) {
spin_lock_init(pi-tx_lock);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Add coherent_dma_mask setting to platform devices
From: Corey Minyard cminy...@mvista.com DMA ops requires that coherent_dma_mask be set properly for a device, but this was not being done for platform devices on powerpc. The MPSC drivers, in particular, need this for both serial and ethernet or they won't be able to allocate memory. Signed-off-by: Corey Minyard cminy...@mvista.com --- How about this patch? It seems to work ok and I suppose this makes sense. I'll send the uart setting in another patch. Index: linux-2.6/arch/powerpc/kernel/setup-common.c === --- linux-2.6.orig/arch/powerpc/kernel/setup-common.c +++ linux-2.6/arch/powerpc/kernel/setup-common.c @@ -681,6 +681,7 @@ static int ppc_dflt_bus_notify(struct no return 0; set_dma_ops(dev, dma_direct_ops); + pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); return NOTIFY_DONE; } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/4] ucc_geth: update the tbi-phy setting
On Thu, Jan 14, 2010 at 1:13 AM, Liu Yu yu@freescale.com wrote:
Old method only set tbi-phy for eth0.
Signed-off-by: Liu Yu yu@freescale.com
---
drivers/net/ucc_geth.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 750d86d..0e72013 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -37,6 +37,7 @@
#include asm/qe.h
#include asm/ucc.h
#include asm/ucc_fast.h
+#include asm/machdep.h
#include ucc_geth.h
#include fsl_pq_mdio.h
@@ -1334,7 +1335,7 @@ static int adjust_enet_interface(struct
ucc_geth_private *ugeth)
struct ucc_geth __iomem *ug_regs;
struct ucc_fast __iomem *uf_regs;
int ret_val;
- u32 upsmr, maccfg2, tbiBaseAddress;
+ u32 upsmr, maccfg2;
u16 value;
ugeth_vdbg(%s: IN, __func__);
@@ -1389,14 +1390,20 @@ static int adjust_enet_interface(struct
ucc_geth_private *ugeth)
/* Note that this depends on proper setting in utbipar register. */
if ((ugeth-phy_interface == PHY_INTERFACE_MODE_TBI) ||
(ugeth-phy_interface == PHY_INTERFACE_MODE_RTBI)) {
- tbiBaseAddress = in_be32(ug_regs-utbipar);
- tbiBaseAddress = UTBIPAR_PHY_ADDRESS_MASK;
- tbiBaseAddress = UTBIPAR_PHY_ADDRESS_SHIFT;
- value = ugeth-phydev-bus-read(ugeth-phydev-bus,
- (u8) tbiBaseAddress, ENET_TBI_MII_CR);
+ struct ucc_geth_info *ug_info = ugeth-ug_info;
+ struct phy_device *tbiphy;
+
+ if (!ug_info-tbi_node)
+ ugeth_warn(TBI mode requires that the device
+ tree specify a tbi-handle\n);
Shouldn't the driver avoid calling of_phy_find_device() if this error
path is taken?
+
+ tbiphy = of_phy_find_device(ug_info-tbi_node);
+ if (!tbiphy)
+ ugeth_warn(Could not get TBI device\n);
+
+ value = phy_read(tbiphy, ENET_TBI_MII_CR);
Ditto here; the code unconditionally tries to read the tbiphy, even if
it isn't there.
Looks wrong.
g.
value = ~0x1000; /* Turn off autonegotiation */
- ugeth-phydev-bus-write(ugeth-phydev-bus,
- (u8) tbiBaseAddress, ENET_TBI_MII_CR, value);
+ phy_write(tbiphy, ENET_TBI_MII_CR, value);
}
init_check_frame_length_mode(ug_info-lengthCheckRx,
ug_regs-maccfg2);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] powerpc: Reduce footprint of irq_stat
On Mon, Feb 01, 2010 at 05:30:23PM +1100, Anton Blanchard wrote:
PowerPC is currently using asm-generic/hardirq.h which statically allocates an
NR_CPUS irq_stat array. Switch to an arch specific implementation which uses
per cpu data:
On a kernel with NR_CPUS=1024, this saves quite a lot of memory:
textdata bss dec hexfilename
8767938 2944132 1636796 13348866 cbb002 vmlinux.baseline
8767779 2944260 1505724 13217763 c9afe3 vmlinux.irq_cpustat
A saving of around 128kB.
Signed-off-by: Anton Blanchard an...@samba.org
---
Index: linux-cpumask/arch/powerpc/include/asm/hardirq.h
===
--- linux-cpumask.orig/arch/powerpc/include/asm/hardirq.h 2010-01-31
22:07:21.037211728 +1100
+++ linux-cpumask/arch/powerpc/include/asm/hardirq.h 2010-02-01
17:28:56.990963256 +1100
@@ -1 +1,22 @@
-#include asm-generic/hardirq.h
+#ifndef _ASM_POWERPC_HARDIRQ_H
+#define _ASM_POWERPC_HARDIRQ_H
+
+#include linux/threads.h
+#include linux/irq.h
+
+typedef struct {
+ unsigned int __softirq_pending;
+} cacheline_aligned irq_cpustat_t;
No need to bother with an irq_cpustat_t type at all in this case, just
declare a softirq_pending per-cpu variable.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCHv2 0/2] Add max CPU nodes field to ibm,client-architecture call
Large NUMA machines require Linux to indicate support for more than 64 cpu cores. This is done through the ibm,client-architecture call, and is documented in the PAPR. There is also another new field added to indicate that the OS is Linux as a hint for possible future performance settings. The first patch attempts to statically initialize the number of supported cores with NR_CPUS, the maximum Linux could boot if the cpus did not have multi-threading (SMT). It can overestimate by the factor of SMT. For instance on Power6 with 2 way SMT it would overestimate by a factor of 2. The result of this overestimation is that Linux might not be able boot all the cpus assigned to it, but would still boot NR_CPUS worth of SMT threads. The second patch adjusts for SMT by reading the device tree before unflattening. I've updated patch 1 from previous comments. Patch 1 can be taken on its own if Patch 2 seems like overkill. v2 - Updated patch 2 style and messages. Basic functionality is the same as v1. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/7] powerpc: Reduce footprint of irq_stat
On Mon, 2010-02-01 at 22:55 +0100, Christoph Hellwig wrote:
+typedef struct {
+ unsigned int __softirq_pending;
+} cacheline_aligned irq_cpustat_t;
No need to bother with an irq_cpustat_t type at all in this case, just
declare a softirq_pending per-cpu variable.
I think his subsequent patches add members to that struct for
CE, MCE etc... stats.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
PATCH: Add non-Virtex 5 support for LL TEMAC driver
This patch adds support for using the LL TEMAC Ethernet driver on
non-Virtex 5 platforms by adding support for accessing the Soft DMA
registers as if they were memory mapped instead of solely through the
DCR's (available on the Virtex 5).
Signed-off-by: John Tyner jty...@cs.ucr.edu
--- /tmp/tmp.5198.41 2010-02-01 15:04:45.0 -0800
+++ ./linux-2.6.32.3/drivers/net/ll_temac.h 2010-01-28 15:06:17.0 -0800
@@ -338,6 +338,7 @@
/* IO registers and IRQs */
void __iomem *regs;
dcr_host_t sdma_dcrs;
+ u32 __iomem *sdma_regs;
int tx_irq;
int rx_irq;
int emac_num;
--- /tmp/tmp.5198.53 2010-02-01 15:04:45.0 -0800
+++ ./linux-2.6.32.3/drivers/net/ll_temac_main.c 2010-02-01 15:04:01.0 -0800
@@ -20,9 +20,6 @@
* or rx, so this should be okay.
*
* TODO:
- * - Fix driver to work on more than just Virtex5. Right now the driver
- * assumes that the locallink DMA registers are accessed via DCR
- * instructions.
* - Factor out locallink DMA code into separate driver
* - Fix multicast assignment.
* - Fix support for hardware checksumming.
@@ -117,12 +114,20 @@
static u32 temac_dma_in32(struct temac_local *lp, int reg)
{
- return dcr_read(lp-sdma_dcrs, reg);
+ if (lp-sdma_regs) {
+ return __raw_readl(lp-sdma_regs + reg);
+ } else {
+ return dcr_read(lp-sdma_dcrs, reg);
+ }
}
static void temac_dma_out32(struct temac_local *lp, int reg, u32 value)
{
- dcr_write(lp-sdma_dcrs, reg, value);
+ if (lp-sdma_regs) {
+ __raw_writel(value, lp-sdma_regs + reg);
+ } else {
+ dcr_write(lp-sdma_dcrs, reg, value);
+ }
}
/**
@@ -862,13 +867,17 @@
goto nodev;
}
- dcrs = dcr_resource_start(np, 0);
- if (dcrs == 0) {
- dev_err(op-dev, could not get DMA register address\n);
+ lp-sdma_regs = NULL;
+
+ if ((dcrs = dcr_resource_start(np, 0)) != 0) {
+ lp-sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
+ dev_dbg(op-dev, DCR base: %x\n, dcrs);
+ } else if ((lp-sdma_regs = of_iomap(np, 0))) {
+ dev_dbg(op-dev, MEM base: %p\n, lp-sdma_regs);
+ } else {
+ dev_err(op-dev, unable to map DMA registers\n);
goto nodev;
}
- lp-sdma_dcrs = dcr_map(np, dcrs, dcr_resource_len(np, 0));
- dev_dbg(op-dev, DCR base: %x\n, dcrs);
lp-rx_irq = irq_of_parse_and_map(np, 0);
lp-tx_irq = irq_of_parse_and_map(np, 1);
@@ -895,7 +904,7 @@
lp-phy_node = of_parse_phandle(op-node, phy-handle, 0);
if (lp-phy_node)
- dev_dbg(lp-dev, using PHY node %s (%p)\n, np-full_name, np);
+ dev_dbg(lp-dev, using PHY node %s (%p)\n, lp-phy_node-full_name, lp-phy_node);
/* Add the device attributes */
rc = sysfs_create_group(lp-dev-kobj, temac_attr_group);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
