[PATCH] Added support for PRTLVT based boards (MPC5121)
Made MPC5121_ADS board support generic:
Renamed arch/powerpc/platforms/512x/mpc5121_ads.c and added list of supported
boards.
For both MPC5121 ADS or PRTLVT support, just select MPC5121_GENERIC and use
the corresponding device-tree.
Signed-off-by: David Jander [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/prtlvt.dts | 255
arch/powerpc/platforms/512x/Kconfig| 14 +-
arch/powerpc/platforms/512x/Makefile |2 +-
.../512x/{mpc5121_ads.c = mpc5121_generic.c} | 38 ++-
4 files changed, 290 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/boot/dts/prtlvt.dts
rename arch/powerpc/platforms/512x/{mpc5121_ads.c = mpc5121_generic.c} (73%)
diff --git a/arch/powerpc/boot/dts/prtlvt.dts b/arch/powerpc/boot/dts/prtlvt.dts
new file mode 100644
index 000..aeb663b
--- /dev/null
+++ b/arch/powerpc/boot/dts/prtlvt.dts
@@ -0,0 +1,255 @@
+/*
+ * Device tree source for PRTLVT based boards, based on:
+ * MPC5121E MDS Device Tree Source
+ *
+ * Copyright 2007 Freescale Semiconductor Inc.
+ * Copyright 2008 Protonic Holland
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+ /* compile with: ./dtc -p 10240 -R 20 -I dts -o prtlvt.dtb -O dtb -b 0
dts/prtlvt.dts */
+
+/dts-v1/;
+
+/ {
+ model = prtlvt;
+ compatible = prt,prtlvt;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 0x20; // 32 bytes
+ i-cache-line-size = 0x20; // 32 bytes
+ d-cache-size = 0x8000;// L1, 32K
+ i-cache-size = 0x8000;// L1, 32K
+ timebase-frequency = 5000;// 50 MHz (csb/4)
+ bus-frequency = 2;// 200 MHz csb bus
+ clock-frequency = 4; // 400 MHz ppc core
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x1000; // 256MB at 0
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = prt,prtlvt-localbus, simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0x8020 0x40;
+ ranges = 0x0 0x0 0xfe00 0x0200;
+ [EMAIL PROTECTED],0 {
+ compatible = amd,s29gl256n, cfi-flash;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0 0x0 0x0200;
+ bank-width = 2;
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc5121-immr, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ #interrupt-cells = 2;
+ ranges = 0x0 0x8000 0x40;
+ reg = 0x8000 0x40;
+ bus-frequency = 6600; // 66 MHz ips bus
+
+
+ // IPIC
+ // interrupts cell = intr #, sense
+ // sense values match linux IORESOURCE_IRQ_* defines:
+ // sense == 8: Level, low assertion
+ // sense == 2: Edge, high-to-low change
+ //
+ ipic: [EMAIL PROTECTED] {
+ compatible = fsl,mpc5121-ipic, fsl,ipic;
+ interrupt-controller;
+ #address-cells = 0;
+ #interrupt-cells = 2;
+ reg = 0xc00 0x100;
+ };
+
+ // 512x PSCs are not 52xx PSCs compatible
+ // PSC0 serial port aka ttyPSC0
+ [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = fsl,mpc5121-psc-uart;
+ port-number = 0;
+ cell-index = 0;
+ reg = 0x11000 0x100;
+ interrupts = 0x28 0x8; // actually the fifo irq
+ interrupt-parent = ipic ;
+ };
+
+ // PSC1 serial port aka ttyPSC1
+ [EMAIL PROTECTED] {
+ device_type = serial;
+ compatible = fsl,mpc5121-psc-uart;
+ port-number = 1;
+ cell-index = 1;
+ reg = 0x11100 0x100;
+ interrupts = 0x28 0x8; // actually the fifo irq
+ interrupt-parent = ipic ;
+ };
+
+ // PSC2 serial port aka ttyPSC2
+
Re: [PATCH 2/2] Re-added support for FEC on MPC5121 from Freescale LTIB to current head
On Thursday 12 June 2008 14:12:15 you wrote:
On Jun 12, 2008, at 6:45 AM, David Jander wrote:
Your commit message isn't exactly helpful as most people dont know
what LTIB is and its not terribly relevant. It just seems like you
are adding support for the FEC on MPC5121 and this point.
[...]
--- a/drivers/net/fec.h
+++ b/drivers/net/fec.h
@@ -59,6 +59,7 @@ typedef struct fec {
} fec_t;
#else
+#if !defined(CONFIG_FS_ENET_MPC5121_FEC)
/*
* Define device register set address map.
@@ -97,6 +98,48 @@ typedef struct fec {
unsigned long fec_fifo_ram[112]; /* FIFO RAM buffer */
} fec_t;
+#else /* CONFIG_FS_ENET_MPC5121_FEC */
+
+typedef struct fec {
[...]
+} fec_t;
+
+#endif /* CONFIG_FS_ENET_MPC5121_FEC */
#endif /* CONFIG_M5272 */
I'm not exactly clear as to why this was done this way but this not
acceptable as it means we can't build a multiplatform kernel that
needs this driver.
Well, it wouldn't be possible either, since CONFIG_M5272 is a Cold-fire
processor, and CONFIG_FS_ENET_MPC5121_FEC is for a PowerPC processor.
In this case.
Otherwise you are right, the driver breaks MPC83xx/MPC5121 multiplatform
builds.
I'm also not clear to me if the MPC5121 FEC is really the same device
or close to it that it should be sharing this driver or have its own.
I am coming to the conclusion that it should have its own driver.
Altough a lot of code could be shared, there are still enough differences, so
that writing just ONE driver without some #ifdef's that would break
multiplatform builds, would instead end up with a much bigger amount of if's,
that would make it unreadable, unmaintainable and inefficient.
Here's why: The above struct fet_t for instance is mapped to a set of
registers in the FEC. For processors with a CPM1, a CPM2 or without CPM (i.e.
MPC5121) the register mapping seems to be significantly different,
nevertheless the structs are all called struct fec_t. How can one fix this
at runtime without changing the name of the structs and then just use a lot
of if's or a combination of macro's and if's everywhere a register of the
FEC is accessed? I fear it will be a mess.
So I think it's either a separate driver, or break multiplatform builds.
Since I am learning from you that breaking multiplatform builds is a no-go,
I'll settle for splitting up the driver.
Any suggestion on where to put that split-off? How to name it?
I would suggest drivers/net/fec_mpc512x/*
I just resubmitted PATCH 1/2 again without part 2 (which hasn't much to do
with it anyway), so Grant may have a final look at it (hopefully I did it
right this time). Part 2 (MPC5121_FEC) will have to wait until monday or so,
since it will take me a while, and I have to do other things in between.
Any suggestions on how to solve the puzzle are of course welcome...
Thanks a lot for reviewing.
Best regards,
--
David Jander
Protonic Holland.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][PATCH] powerpc: add usable-memory property to drconf memory
kexec-tools in user space collects rtas, crash , tce region ranges
from /proc/device-tree/ and passes them as linux,usable-memory properties to
second/kdump kernel in the device tree buffer. With drconf memory in power6
machines, we need a similar method to preserve those regions in the kdump
kernel. This patch adopts a method to append the number 'n' from n'th lmb
entry in ibm,dynamic-memory as a string to linux,usable-memory string , so
as to distinguish each usable-memory region and it's size. Another place
that needs similar change but not included in this patch is in
arch/powerpc/mm/numa.c.
Signed-off-by: Chandru S [EMAIL PROTECTED]
---
--- arch/powerpc/kernel/prom.c.orig 2008-06-13 11:42:45.0 +0530
+++ arch/powerpc/kernel/prom.c 2008-06-13 12:09:04.0 +0530
@@ -884,9 +884,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *udm, *reg, *endp;
+ unsigned long l, n, un, flags;
u64 base, size, lmb_size;
+ char buf[64], t[8];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
@@ -919,6 +920,41 @@ static int __init early_init_dt_scan_drc
}
lmb_add(base, size);
}
+
+ /* Scan usable-memory properties */
+ for (; un != 0; --un) {
+ base = dt_mem_next_cell(dt_root_addr_cells, udm);
+ flags = dm[3];
+ udm += 4;
+ if ((flags 0x80) || !(flags 0x8))
+ continue;
+ strcpy(buf, linux,usable-memory);
+ sprintf(t, %d, (int)un);
+ strcat(buf, t);
+ reg = (cell_t *)of_get_flat_dt_prop(node,
+ (const char *)buf, l);
+ if (reg == NULL)
+ continue;
+ /* remove the previously added lmb */
+ lmb_remove(base, (base+lmb_size));
+ endp = reg + (l / sizeof(cell_t));
+ while ((endp - reg) = (dt_root_addr_cells +
+ dt_root_size_cells)) {
+
+ base = dt_mem_next_cell(dt_root_addr_cells, reg);
+ size = dt_mem_next_cell(dt_root_size_cells, reg);
+
+ if (size == 0)
+ continue;
+ if (iommu_is_off) {
+ if (base = 0x8000ul)
+ continue;
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+ }
+ lmb_add(base, size);
+ }
+ }
lmb_dump_all();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] powerpc: add usable-memory property to drconf memory
On Friday 13 June 2008 14:51:39 Chandru wrote:
kexec-tools in user space collects rtas, crash , tce region ranges
from /proc/device-tree/ and passes them as linux,usable-memory properties
to second/kdump kernel in the device tree buffer. With drconf memory in
power6 machines, we need a similar method to preserve those regions in the
kdump kernel. This patch adopts a method to append the number 'n' from
n'th lmb entry in ibm,dynamic-memory as a string to linux,usable-memory
string , so as to distinguish each usable-memory region and it's size.
Another place that needs similar change but not included in this patch is
in
arch/powerpc/mm/numa.c.
The previous patch had two missing lines. Hence sending it again. Sorry about
this :(.
Signed-off-by: Chandru S [EMAIL PROTECTED]
---
--- arch/powerpc/kernel/prom.c.orig 2008-06-13 11:42:45.0 +0530
+++ arch/powerpc/kernel/prom.c 2008-06-13 16:21:04.0 +0530
@@ -884,20 +884,22 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *udm, *reg, *endp;
+ unsigned long l, n, un, flags;
u64 base, size, lmb_size;
+ char buf[64], t[8];
ls = (cell_t *)of_get_flat_dt_prop(node, ibm,lmb-size, l);
if (ls == NULL || l dt_root_size_cells * sizeof(cell_t))
return 0;
lmb_size = dt_mem_next_cell(dt_root_size_cells, ls);
- dm = (cell_t *)of_get_flat_dt_prop(node, ibm,dynamic-memory, l);
+ udm = dm = (cell_t *)of_get_flat_dt_prop(node,
+ ibm,dynamic-memory, l);
if (dm == NULL || l sizeof(cell_t))
return 0;
- n = *dm++; /* number of entries */
+ un = n = *dm++; /* number of entries */
if (l (n * (dt_root_addr_cells + 4) + 1) * sizeof(cell_t))
return 0;
@@ -919,6 +921,41 @@ static int __init early_init_dt_scan_drc
}
lmb_add(base, size);
}
+
+ /* Scan usable-memory properties */
+ for (; un != 0; --un) {
+ base = dt_mem_next_cell(dt_root_addr_cells, udm);
+ flags = dm[3];
+ udm += 4;
+ if ((flags 0x80) || !(flags 0x8))
+ continue;
+ strcpy(buf, linux,usable-memory);
+ sprintf(t, %d, (int)un);
+ strcat(buf, t);
+ reg = (cell_t *)of_get_flat_dt_prop(node,
+ (const char *)buf, l);
+ if (reg == NULL)
+ continue;
+ /* remove the previously added lmb */
+ lmb_remove(base, (base+lmb_size));
+ endp = reg + (l / sizeof(cell_t));
+ while ((endp - reg) = (dt_root_addr_cells +
+ dt_root_size_cells)) {
+
+ base = dt_mem_next_cell(dt_root_addr_cells, reg);
+ size = dt_mem_next_cell(dt_root_size_cells, reg);
+
+ if (size == 0)
+ continue;
+ if (iommu_is_off) {
+ if (base = 0x8000ul)
+ continue;
+ if ((base + size) 0x8000ul)
+ size = 0x8000ul - base;
+ }
+ lmb_add(base, size);
+ }
+ }
lmb_dump_all();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/6] ibm_newemac: PowerPC 440GX EMAC PHY clock workaround
Did this show up on 2.6.26 recently? Or we're expecting it to show up a
bit later?
Thanks,
Luis
On Tue, 2008-04-22 at 10:46 +1000, Benjamin Herrenschmidt wrote:
From: Valentine Barshak [EMAIL PROTECTED]
The PowerPC 440GX Taishan board fails to reset EMAC3 (reset timeout error)
if there's no link. Because of that it fails to find PHY chip. The older
ibm_emac
driver had a workaround for that: the EMAC_CLK_INTERNAL/EMAC_CLK_EXTERNAL
macros,
which toggle the Ethernet Clock Select bit in the SDR0_MFR register. This
patch
does the same for ibm,emac-440gx compatible chips. The workaround forces
clock on -all- EMACs, so we select clock under global emac_phy_map_lock.
BenH: Made that #ifdef CONFIG_PPC_DCR_NATIVE for now as dcri_* stuff doesn't
exist for MMIO type DCRs like Cell. Some future rework improvements of the
DCR infrastructure will make that cleaner but for now, this makes it work.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/net/ibm_newemac/core.c | 18 +-
drivers/net/ibm_newemac/core.h |8 ++--
2 files changed, 23 insertions(+), 3 deletions(-)
--- linux-work.orig/drivers/net/ibm_newemac/core.c2008-04-22
10:11:59.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.c 2008-04-22 10:31:18.0
+1000
@@ -43,6 +43,8 @@
#include asm/io.h
#include asm/dma.h
#include asm/uaccess.h
+#include asm/dcr.h
+#include asm/dcr-regs.h
#include core.h
@@ -2333,6 +2335,11 @@ static int __devinit emac_init_phy(struc
dev-phy.mdio_read = emac_mdio_read;
dev-phy.mdio_write = emac_mdio_write;
+ /* Enable internal clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, 0, SDR0_MFR_ECS);
+#endif
/* Configure EMAC with defaults so we can at least use MDIO
* This is needed mostly for 440GX
*/
@@ -2365,6 +2372,12 @@ static int __devinit emac_init_phy(struc
if (!emac_mii_phy_probe(dev-phy, i))
break;
}
+
+ /* Enable external clock source */
+#ifdef CONFIG_PPC_DCR_NATIVE
+ if (emac_has_feature(dev, EMAC_FTR_440GX_PHY_CLK_FIX))
+ dcri_clrset(SDR0, SDR0_MFR, SDR0_MFR_ECS, 0);
+#endif
mutex_unlock(emac_phy_map_lock);
if (i == 0x20) {
printk(KERN_WARNING %s: can't find PHY!\n, np-full_name);
@@ -2490,8 +2503,11 @@ static int __devinit emac_init_config(st
}
/* Check EMAC version */
- if (of_device_is_compatible(np, ibm,emac4))
+ if (of_device_is_compatible(np, ibm,emac4)) {
dev-features |= EMAC_FTR_EMAC4;
+ if (of_device_is_compatible(np, ibm,emac-440gx))
+ dev-features |= EMAC_FTR_440GX_PHY_CLK_FIX;
+ }
/* Fixup some feature bits based on the device tree */
if (of_get_property(np, has-inverted-stacr-oc, NULL))
Index: linux-work/drivers/net/ibm_newemac/core.h
===
--- linux-work.orig/drivers/net/ibm_newemac/core.h2008-04-22
10:06:31.0 +1000
+++ linux-work/drivers/net/ibm_newemac/core.h 2008-04-22 10:30:03.0
+1000
@@ -301,6 +301,10 @@ struct emac_instance {
* Set if we have new type STACR with STAOPC
*/
#define EMAC_FTR_HAS_NEW_STACR 0x0040
+/*
+ * Set if we need phy clock workaround for 440gx
+ */
+#define EMAC_FTR_440GX_PHY_CLK_FIX 0x0080
/* Right now, we don't quite handle the always/possible masks on the
@@ -312,8 +316,8 @@ enum {
EMAC_FTRS_POSSIBLE =
#ifdef CONFIG_IBM_NEW_EMAC_EMAC4
- EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR|
- EMAC_FTR_STACR_OC_INVERT|
+ EMAC_FTR_EMAC4 | EMAC_FTR_HAS_NEW_STACR |
+ EMAC_FTR_STACR_OC_INVERT | EMAC_FTR_440GX_PHY_CLK_FIX |
#endif
#ifdef CONFIG_IBM_NEW_EMAC_TAH
EMAC_FTR_HAS_TAH|
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
Luis Machado
Software Engineer
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
On Friday 18 April 2008 19:16, Jochen Friedrich wrote:
Based on earlier work by Laurent Pinchart.
This patch implement GPIO LIB support for the CPM2 GPIOs.
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
Cc: Laurent Pinchart [EMAIL PROTECTED]
Signed-off-by: Laurent Pinchart [EMAIL PROTECTED]
Is there any showstopper or can this one be applied to powerpc-next ?
---
arch/powerpc/platforms/Kconfig |2 +
arch/powerpc/sysdev/cpm2.c | 11
arch/powerpc/sysdev/cpm_common.c | 123
++
include/asm-powerpc/cpm.h|3 +
4 files changed, 139 insertions(+), 0 deletions(-)
Changes from version 1:
- conditionally include #include linux/of_gpio.h in cpm_common.c, so it
compiles
when GPIO on 8xx is not selected.
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index f6eecd1..78911f6 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -283,6 +283,8 @@ config CPM2
depends on MPC85xx || 8260
select CPM
select PPC_LIB_RHEAP
+ select GENERIC_GPIO
+ select HAVE_GPIO_LIB
help
The CPM2 (Communications Processor Module) is a coprocessor on
embedded CPUs made by Freescale. Selecting this option means that
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index 5a6c5df..9311778 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
@@ -377,3 +377,14 @@ void cpm2_set_pin(int port, int pin, int flags)
else
clrbits32(iop[port].odr, pin);
}
+
+static int cpm_init_par_io(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, fsl,cpm2-pario-bank)
+ cpm2_gpiochip_add32(np);
+ return 0;
+}
+arch_initcall(cpm_init_par_io);
+
diff --git a/arch/powerpc/sysdev/cpm_common.c
b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..43bac6e 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -19,6 +19,8 @@
#include linux/init.h
#include linux/of_device.h
+#include linux/spinlock.h
+#include linux/of.h
#include asm/udbg.h
#include asm/io.h
@@ -28,6 +30,10 @@
#include mm/mmu_decl.h
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+#include linux/of_gpio.h
+#endif
+
#ifdef CONFIG_PPC_EARLY_DEBUG_CPM
static u32 __iomem *cpm_udbg_txdesc =
(u32 __iomem __force *)CONFIG_PPC_EARLY_DEBUG_CPM_ADDR;
@@ -198,3 +204,120 @@ dma_addr_t cpm_muram_dma(void __iomem *addr)
return muram_pbase + ((u8 __iomem *)addr - muram_vbase);
}
EXPORT_SYMBOL(cpm_muram_dma);
+
+#if defined(CONFIG_CPM2) || defined(CONFIG_8xx_GPIO)
+
+struct cpm2_ioports {
+ u32 dir, par, sor, odr, dat;
+ u32 res[3];
+};
+
+struct cpm2_gpio32_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u32 cpdata;
+};
+
+static inline struct cpm2_gpio32_chip *
+to_cpm2_gpio32_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct cpm2_gpio32_chip, mm_gc);
+}
+
+static void cpm2_gpio32_save_regs(struct of_mm_gpio_chip *mm_gc)
+{
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc-regs;
+
+ cpm2_gc-cpdata = in_be32(iop-dat);
+}
+
+static int cpm2_gpio32_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc-regs;
+ u32 pin_mask;
+
+ pin_mask = 1 (31 - gpio);
+
+ return !!(in_be32(iop-dat) pin_mask);
+}
+
+static void cpm2_gpio32_set(struct gpio_chip *gc, unsigned int gpio, int
value)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_gpio32_chip *cpm2_gc = to_cpm2_gpio32_chip(mm_gc);
+ struct cpm2_ioports __iomem *iop = mm_gc-regs;
+ unsigned long flags;
+ u32 pin_mask = 1 (31 - gpio);
+
+ spin_lock_irqsave(cpm2_gc-lock, flags);
+
+ if (value)
+ cpm2_gc-cpdata |= pin_mask;
+ else
+ cpm2_gc-cpdata = ~pin_mask;
+
+ out_be32(iop-dat, cpm2_gc-cpdata);
+
+ spin_unlock_irqrestore(cpm2_gc-lock, flags);
+}
+
+static int cpm2_gpio32_dir_out(struct gpio_chip *gc, unsigned int gpio, int
val)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc-regs;
+ u32 pin_mask;
+
+ pin_mask = 1 (31 - gpio);
+
+ setbits32(iop-dir, pin_mask);
+
+ cpm2_gpio32_set(gc, gpio, val);
+
+ return 0;
+}
+
+static int cpm2_gpio32_dir_in(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm_gpio_chip *mm_gc = to_of_mm_gpio_chip(gc);
+ struct cpm2_ioports __iomem *iop = mm_gc-regs;
+ u32 pin_mask;
+
+ pin_mask = 1 (31 - gpio);
+
+ clrbits32(iop-dir,
Re: [RFC PATCH 0/2] Merge HUGETLB_PAGE and HUGETLBFS Kconfig options
On Fri, 2008-06-13 at 14:46 +0100, Ralf Baechle wrote: MIPS doesn't do HUGETLB (at least not in-tree atm) so I'm not sure why [EMAIL PROTECTED] was cc'ed at all. So feel free to add my Couldnt-care-less: ack line ;-) Sorry :) My patches touched your defconfigs so I felt it prudent to include the mips list as an FYI. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC PATCH 0/2] Merge HUGETLB_PAGE and HUGETLBFS Kconfig options
On Thu, Jun 12, 2008 at 02:49:00PM -0400, Adam Litke wrote: There are currently two global Kconfig options that enable/disable the hugetlb code: CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS. This may have made sense before hugetlbfs became ubiquitous but now the pair of options are redundant. Merging these two options into one will simplify the code slightly and will, more importantly, avoid confusion and questions like: Which hugetlbfs CONFIG option should my code depend on? CONFIG_HUGETLB_PAGE is aliased to the value of CONFIG_HUGETLBFS, so one option can be removed without any effect. The first patch merges the two options into one option: CONFIG_HUGETLB. The second patch updates the defconfigs to set the one new option appropriately. I have cross-compiled this on i386, x86_64, ia64, powerpc, sparc64 and sh with the option enabled and disabled. This is completely mechanical but, due to the large number of files affected (especially defconfigs), could do well with a review from several sets of eyeballs. Thanks. MIPS doesn't do HUGETLB (at least not in-tree atm) so I'm not sure why [EMAIL PROTECTED] was cc'ed at all. So feel free to add my Couldnt-care-less: ack line ;-) Ralf ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH REPOST] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts
Hi Roland,
On Tuesday 10 June 2008 18:18:50 Roland Dreier wrote:
So just to be clear: this is a workaround for a hardware/firmware bug?
Yes it is.
OK, so paulus et al... does it seem like a good approach to call H_EOI
from driver code (given that this driver makes tons of other hcalls)?
How critical is this? Since you said corner case testing I suspect we
can defer this to 2.6.27 and maybe get it into -stable later?
No, it's ok with me if you pick this for 2.6.27.
Also, out of curiousity:
+u64 hipz_h_eoi(int irq)
+{
+ int value;
+ unsigned long xirr;
+
+ iosync();
what is the iosync() required for here?
It's the same sequence as the interrupt handler for powerpc is implemented.
+ value = (0xff 24) | irq;
+ xirr = value 0x;
given that irq and value are ints, is there any possible way value could
have bits outside of the low 32 set? If you're worried about sign
extension isn't it simpler to just make value unsigned?
+ return plpar_hcall_norets(H_EOI, xirr);
+}
ie why not:
u64 hipz_h_eoi(int irq)
{
unsigned xirr;
iosync();
xirr = (0xff 24) | irq;
return plpar_hcall_norets(H_EOI, xirr);
}
Yeah, you are rigth I will change that with the final patch.
I will send the final patch soon.
regards Stefan
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
XLLTemac with SGDMA working on virtex4FX ?
Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[140] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 61704k/65536k available (2892k kernel code, 3768k reserved, 112k data, 141k bss, 144k init) Mount-cache hash table entries: 512 net_namespace: 536 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e3 (irq = 16) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded Device Tree Probing 'ethernet' xilinx_lltemac 81c0.ethernet: MAC address is now 0: a:35: 0:22: 1 xilinx_lltemac 81c0.ethernet: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc5010100 XLlTemac: buffer descriptor size: 32768 (0x8000) XLlTemac: Allocating DMA descriptors with kmalloc6XLlTemac: (buffer_descriptor_init) phy: 0x3868000, virt: 0xc3868000, size: 0x8000 XTemac: PHY detected at address 4. xilinx_lltemac 81c0.ethernet: eth0: Xilinx TEMAC at 0x81C0 mapped to 0xC500E000, irq=17 mice: PS/2 mouse device common for all mice TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: XLlTemac: Options: 0x3fa eth0: XLlTemac: allocating interrupt 19 for dma mode tx. eth0: XLlTemac: allocating interrupt 18 for dma mode rx. eth0: XLlTemac: speed set to 10Mb/s eth0: XLlTemac: Send Threshold = 240, Receive Threshold = 40 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 Sending DHCP requests .. timed out! IP-Config: Reopening network devices... eth0: XLlTemac: Options: 0x3fa I can see the led blinking on my switch but don't see nothing using wireshak !!! Finaly, i know the the temac works because i can use it with uboot !!! even at speed 1000. In:serial Out: serial Err: serial U-Boot relocated to 03fcf000 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd=loooaadd %addr Press Enter within 3 seconds to stop autoboot Unknown command 'loooaadd' - try 'help' = setenv bootfile zImage.virtex = tftp 4 eth0: Xilinx XPS LocalLink Tri-Mode Ether MAC #0 at 0x81C0. 1000BASE-T/FD TFTP from server 192.168.1.100; our IP address is 192.168.1.200 Filename 'zImage.virtex'. Load address: 0x4 Loading: # done Bytes transferred = 1772215 (1b0ab7 hex) = so if someone already had that problem... Thanks in advance Simon _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH REPOST #2] IB/ehca: In case of lost interrupts, trigger EOI to reenable interrupts
During corner case testing, we noticed that some versions of ehca
do not properly transition to interrupt done in special load situations.
This can be resolved by periodically triggering EOI through H_EOI,
if eqes are pending.
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
As firmware team suggested I moved the call of the EOI h_call into
the handler function, this ensures that we will call EOI only when we
find a valid eqe on the event queue.
Additionally I changed the calculation of the xirr value as Roland suggested.
drivers/infiniband/hw/ehca/ehca_irq.c |9 +++--
drivers/infiniband/hw/ehca/hcp_if.c | 10 ++
drivers/infiniband/hw/ehca/hcp_if.h |1 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_irq.c
b/drivers/infiniband/hw/ehca/ehca_irq.c
index ce1ab05..0792d93 100644
--- a/drivers/infiniband/hw/ehca/ehca_irq.c
+++ b/drivers/infiniband/hw/ehca/ehca_irq.c
@@ -531,7 +531,7 @@ void ehca_process_eq(struct ehca_shca *shca, int is_irq)
{
struct ehca_eq *eq = shca-eq;
struct ehca_eqe_cache_entry *eqe_cache = eq-eqe_cache;
- u64 eqe_value;
+ u64 eqe_value, ret;
unsigned long flags;
int eqe_cnt, i;
int eq_empty = 0;
@@ -583,8 +583,13 @@ void ehca_process_eq(struct ehca_shca *shca, int is_irq)
ehca_dbg(shca-ib_device,
No eqe found for irq event);
goto unlock_irq_spinlock;
- } else if (!is_irq)
+ } else if (!is_irq) {
+ ret = hipz_h_eoi(eq-ist);
+ if (ret != H_SUCCESS)
+ ehca_err(shca-ib_device,
+bad return code EOI -rc = %ld\n, ret);
ehca_dbg(shca-ib_device, deadman found %x eqe, eqe_cnt);
+ }
if (unlikely(eqe_cnt == EHCA_EQE_CACHE_SIZE))
ehca_dbg(shca-ib_device, too many eqes for one irq event);
/* enable irq for new packets */
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c
b/drivers/infiniband/hw/ehca/hcp_if.c
index 5245e13..415d3a4 100644
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -933,3 +933,13 @@ u64 hipz_h_error_data(const struct ipz_adapter_handle
adapter_handle,
r_cb,
0, 0, 0, 0);
}
+
+u64 hipz_h_eoi(int irq)
+{
+ unsigned long xirr;
+
+ iosync();
+ xirr = (0xffULL 24) | irq;
+
+ return plpar_hcall_norets(H_EOI, xirr);
+}
diff --git a/drivers/infiniband/hw/ehca/hcp_if.h
b/drivers/infiniband/hw/ehca/hcp_if.h
index 60ce02b..2c3c6e0 100644
--- a/drivers/infiniband/hw/ehca/hcp_if.h
+++ b/drivers/infiniband/hw/ehca/hcp_if.h
@@ -260,5 +260,6 @@ u64 hipz_h_error_data(const struct ipz_adapter_handle
adapter_handle,
const u64 ressource_handle,
void *rblock,
unsigned long *byte_count);
+u64 hipz_h_eoi(int irq);
#endif /* __HCP_IF_H__ */
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
On Fri, Jun 13, 2008 at 02:46:20PM +0200, Laurent Pinchart wrote: On Friday 18 April 2008 19:16, Jochen Friedrich wrote: Based on earlier work by Laurent Pinchart. This patch implement GPIO LIB support for the CPM2 GPIOs. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] Cc: Laurent Pinchart [EMAIL PROTECTED] Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] Is there any showstopper or can this one be applied to powerpc-next ? One comment below. [...] + mm_gc-save_regs = cpm2_gpio32_save_regs; + of_gc-gpio_cells = 1; I would strongly suggest to use gpio_cells = 2, otherwise you will not able to pass GPIO flags (such as active-low etc) without breaking the compatibility with older trees. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCHv2 1/2] [POWERPC] CPM2: Implement GPIO LIB API on CPM2 Freescale SoC.
On Friday 13 June 2008 16:57, Anton Vorontsov wrote: On Fri, Jun 13, 2008 at 02:46:20PM +0200, Laurent Pinchart wrote: On Friday 18 April 2008 19:16, Jochen Friedrich wrote: Based on earlier work by Laurent Pinchart. This patch implement GPIO LIB support for the CPM2 GPIOs. Signed-off-by: Jochen Friedrich [EMAIL PROTECTED] Cc: Laurent Pinchart [EMAIL PROTECTED] Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] Is there any showstopper or can this one be applied to powerpc-next ? One comment below. [...] + mm_gc-save_regs = cpm2_gpio32_save_regs; + of_gc-gpio_cells = 1; I would strongly suggest to use gpio_cells = 2, otherwise you will not able to pass GPIO flags (such as active-low etc) without breaking the compatibility with older trees. Agreed. Jochen, will you resubmit or should I do it ? -- 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 pgpd8xa3QyK7q.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] poweroff via pm_power_off if set
This patch is needed to make ipmi_poweroff working on powerpc.
It straightens the poweroff procedure to match with other architectures.
At the moment powerpc plattforms can define their poweroff method using
ppc_md.power_off. The only way for plattform independent driver (ipmi_poweroff)
to register it's poweroff function is to use pm_power_off. So machine_power_off
should check whether pm_power_off has been set and if so it should be used.
If not, plattform dependent ppc_md.power_off should be called.
Signed-off-by: Christian Krafft [EMAIL PROTECTED]
Index: linux.git/arch/powerpc/kernel/setup-common.c
===
--- linux.git.orig/arch/powerpc/kernel/setup-common.c
+++ linux.git/arch/powerpc/kernel/setup-common.c
@@ -121,6 +121,8 @@ void machine_restart(char *cmd)
void machine_power_off(void)
{
machine_shutdown();
+ if (pm_power_off)
+ pm_power_off();
if (ppc_md.power_off)
ppc_md.power_off();
#ifdef CONFIG_SMP
@@ -133,7 +135,7 @@ void machine_power_off(void)
/* Used by the G5 thermal driver */
EXPORT_SYMBOL_GPL(machine_power_off);
-void (*pm_power_off)(void) = machine_power_off;
+void (*pm_power_off)(void) = NULL;
EXPORT_SYMBOL_GPL(pm_power_off);
void machine_halt(void)
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
signature.asc
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [8xx] powerpc: Add support for the MPC852 based mgsuvd board from keymile.
Hello Scott,
here comes the updated version for the mgsuvd port with your
suggested changes:
[powerpc] add support for the MPC852 based mgsuvd board from
keymile to arch/powerpc. Supported SMC1 (serial console),
SCC3 Ethernet (10Mbps hdx).
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgsuvd.dts | 163 ++
arch/powerpc/configs/mgsuvd_defconfig | 872 +
arch/powerpc/platforms/8xx/Kconfig|6 +
arch/powerpc/platforms/8xx/Makefile |1 +
arch/powerpc/platforms/8xx/mgsuvd.c | 93
5 files changed, 1135 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgsuvd.dts
create mode 100644 arch/powerpc/configs/mgsuvd_defconfig
create mode 100644 arch/powerpc/platforms/8xx/mgsuvd.c
diff --git a/arch/powerpc/boot/dts/mgsuvd.dts b/arch/powerpc/boot/dts/mgsuvd.dts
new file mode 100644
index 000..4b05346
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgsuvd.dts
@@ -0,0 +1,163 @@
+/*
+ * MGSUVD Device Tree Source
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = MGSUVD;
+ compatible = keymile,mgsuvd;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 16;
+ i-cache-line-size = 16;
+ d-cache-size = 8192;
+ i-cache-size = 8192;
+ timebase-frequency = 0; /* Filled in by u-boot
*/
+ bus-frequency = 0;/* Filled in by u-boot
*/
+ clock-frequency = 0; /* Filled in by u-boot
*/
+ interrupts = 15 2;/* decrementer
interrupt */
+ interrupt-parent = PIC;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x400; /* Filled in by u-boot */
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,pq1-localbus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xfff00100 0x40;
+
+ ranges = 0 0 0xf000 0x0100; /* Filled in by u-boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 0x8;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 0x8 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0xa 0x1e;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 0x28 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 0x2a 0x50;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x7a 0x86;
+ };
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc852, simple-bus, fsl,pq1-soc;
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 0xfff0 0x4000;
+
+ PIC: [EMAIL PROTECTED] {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0 24;
+ compatible = fsl,pq1-pic;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc852-cpm, simple-bus, fsl,cpm1;
+ interrupts = 0; /* cpm error interrupt */
+ interrupt-parent = CPM_PIC;
+ reg = 0x9c0 10;
+ ranges;
+
+
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
Hello Scott,
here comes the updated version for the mgcoge port, with your
suggestions:
[powerpc] Added support for the MPC8247 based board MGCOGE
from Keymile.
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgcoge.dts | 174 +++
arch/powerpc/configs/mgcoge_defconfig | 900 +
arch/powerpc/platforms/82xx/Kconfig |8 +
arch/powerpc/platforms/82xx/Makefile |1 +
arch/powerpc/platforms/82xx/mgcoge.c | 130 +
5 files changed, 1213 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgcoge.dts
create mode 100644 arch/powerpc/configs/mgcoge_defconfig
create mode 100644 arch/powerpc/platforms/82xx/mgcoge.c
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
new file mode 100644
index 000..54d49c5
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -0,0 +1,174 @@
+/*
+ * Device Tree for the MGCOGE plattform from keymile
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = MGCOGE;
+ compatible = keymile,mgcoge;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = eth0;
+ serial0 = smc2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 32;
+ i-cache-line-size = 32;
+ d-cache-size = 16384;
+ i-cache-size = 16384;
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ clock-frequency = 0; /* Filled in by U-Boot */
+ bus-frequency = 0; /* Filled in by U-Boot */
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc8247-localbus,
+fsl,pq2-localbus,
+simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xf0010100 0x40;
+
+ ranges = 0 0 0xfe00 0x0040
+ 1 0 0x5000 0x2000
+ ; /* Filled in by U-Boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0x0 0x40;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 0x4;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 0x4 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0x6 0x22;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 0x28 0x2;
+ };
+ };
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 1 0x0 0x200;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 2;
+ device-width = 2;
+ [EMAIL PROTECTED] {
+ label = ramdisk;
+ reg = 0 0x7a;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x7a 0x186;
+ };
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0 0; /* Filled in by U-Boot */
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8247-immr, fsl,pq2-soc, simple-bus;
+ ranges = 0x 0xf000 0x00053000;
+
+ // Temporary until code stops depending on it.
+ device_type = soc;
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ #interrupt-cells = 2;
+ compatible =
Re: [PATCH] [8xx] powerpc: Add support for the MPC852 based mgsuvd board from keymile.
Heiko Schocher wrote:
+ [EMAIL PROTECTED] {
+ compatible = fsl,pq1-localbus;
fsl,mpc852-localbus, fsl,pq1-localbus, simple-bus;
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc852, simple-bus, fsl,pq1-soc;
simple-bus should come last, since it's the most generic.
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 0xfff0 0x4000;
+
+ PIC: [EMAIL PROTECTED] {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0 24;
+ compatible = fsl,pq1-pic;
fsl,mpc852-pic, fsl,pq1-pic;
In general, a chip-specific name should be listed first, so the driver
can easily apply workarounds if needed. See the existing 8xx device
trees for examples.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: XLLTemac with SGDMA working on virtex4FX ?
Hi Simon, I have not done testing of this driver with checksum offload. I do test the driver in an automated test, but not in checksum offload mode, I need to add that test. I did receive the following patch and applied it to the Git server so I think Johann did some testing with checksum offload. That may have been with arch/ppc rather than arch/powerpc, not sure. I noticed that you have uboot working with LL TEMAC and it must be using DMA SG as it's running on the same h/w. I just got thru hacking together a rough polled mode LL TEMAC driver to support uboot and it's working, but not cleaned up. Just curious on your experience in that area. Thanks, John Linn Linux Development Strategy Xilinx is looking for embedded Linux developers *** the patch text I applied ** From: John Linn [EMAIL PROTECTED] Sent: Friday, April 04, 2008 10:25 AM To: git Cc: John Linn; Johann Baudy Subject: [PATCH] Xilinx: LL TEMAC: Fix checksum offload The LL TEMAC is generating the wrong checksum when TX hardware checksum is enabled. This is mainly due to two issues: - CHECKSUM_COMPLETE can only be used on RX PATH, CHECKSUM_PARTIAL must be used instead. - Checksum index offsets are being calculated wrong. Signed-off-by: Johann Baudy [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Frey Sent: Friday, June 13, 2008 8:46 AM To: linuxppc-dev@ozlabs.org Subject: XLLTemac with SGDMA working on virtex4FX ? Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[140] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 61704k/65536k available (2892k kernel code, 3768k reserved, 112k data, 141k bss, 144k init) Mount-cache hash table entries: 512 net_namespace: 536 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e3 (irq = 16) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded Device Tree Probing 'ethernet' xilinx_lltemac 81c0.ethernet: MAC address is now 0: a:35: 0:22: 1 xilinx_lltemac 81c0.ethernet: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc5010100 XLlTemac: buffer descriptor size: 32768 (0x8000) XLlTemac: Allocating DMA descriptors with kmalloc6XLlTemac: (buffer_descriptor_init) phy: 0x3868000, virt: 0xc3868000, size: 0x8000 XTemac: PHY detected at address 4. xilinx_lltemac 81c0.ethernet: eth0: Xilinx TEMAC at 0x81C0 mapped to 0xC500E000, irq=17 mice: PS/2 mouse device common for all mice TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: XLlTemac: Options: 0x3fa eth0: XLlTemac: allocating interrupt 19 for dma mode tx. eth0: XLlTemac: allocating interrupt 18 for dma mode rx. eth0: XLlTemac: speed set to 10Mb/s eth0: XLlTemac: Send Threshold = 240, Receive Threshold = 40 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 Sending DHCP requests .. timed out! IP-Config: Reopening network devices... eth0: XLlTemac: Options: 0x3fa I can see the led blinking on my switch but don't see nothing using wireshak !!! Finaly, i know the the temac works because i can use it with uboot !!! even at speed 1000. In:serial Out: serial Err:
Re: [PATCH] [82xx] powerpc: Add support for mpc8247 based board MGCOGE from keymile.
On Fri, Jun 13, 2008 at 06:33:08PM +0200, Heiko Schocher wrote: Hello Scott, here comes the updated version for the mgcoge port, with your suggestions: [powerpc] Added support for the MPC8247 based board MGCOGE from Keymile. Signed-off-by: Heiko Schocher [EMAIL PROTECTED] Acked-by: Scott Wood [EMAIL PROTECTED] -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] poweroff via pm_power_off if set
On Jun 13, 2008, at 10:36 AM, Christian Krafft wrote: This patch is needed to make ipmi_poweroff working on powerpc. It straightens the poweroff procedure to match with other architectures. At the moment powerpc plattforms can define their poweroff method using ppc_md.power_off. The only way for plattform independent driver (ipmi_poweroff) to register it's poweroff function is to use pm_power_off. So machine_power_off should check whether pm_power_off has been set and if so it should be used. If not, plattform dependent ppc_md.power_off should be called. It seems like this should be the other way around. Meaning ppc_md.power_off should be called first than pm_power_off. If a platform provides a power off mechanism that should presuming take precedence over the ipmi_poweroff. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
gen-mhs-devtree - C_ALL_PIMS_SHARE_ADDRESSES=0
Hi Stephen,
I wasn't able to get the FDT generator working with
C_ALL_PIMS_SHARE_ADDRESSES = 0 (parameter of MPMC) and EDK10.1 SP1 (you
will find error output below).
It seems that it's not fully supported in FDT TCL script yet!
Indeed, this script is looking for C_MPMC_BASEADDR instead of
C_PIMX_BASEADDR even if C_ALL_PIMS_SHARE_ADDRESSES = 0.
#--
# FDT BSP DRC...!
#--
Running generate for OS'es, Drivers and Libraries ...
#--
# FDT BSP generate...
#--
Clock Frequency: 3
+++ 151545648
Bus handle DPLB0 connected through a bus...
-master 151545648 DPLB0 plb ppc405_0
-master 151545648 IPLB0 plb ppc405_0
-slave 153793872 SPLB0 plb DDR_SDRAM_32Mx16
-slave 153793872 SDMA_CTRL1 plb DDR_SDRAM_32Mx16
-slave 153793872 SDMA_CTRL2 plb DDR_SDRAM_32Mx16
-slave 164169800 SPLB plb TriMode_MAC_GMII
-slave 166899408 SPLB plb xps_intc_0
-slave 167195280 SPLB plb common_gpio
-slave 167632152 SPLB plb xps_bram_if_cntlr_0
-slave 168015912 SPLB plb flash_ctrl_0
-slave 168339256 SPLB plb xps_uartlite_0
+++ 151545648
Bus handle DPLB1 connected directly...
VERSION
ERROR:MDT - fdt () - Bad highaddr for DDR_SDRAM_32Mx16
while executing
error Bad highaddr for $nodename
(procedure gen_reg_property line 10)
invoked from within
gen_reg_property $name $baseaddr $highaddr
(procedure memory line 12)
invoked from within
memory $slave MPMC_
(mpmc arm line 2)
invoked from within
switch $type {
plb_bram_if_cntlr -
opb_bram_if_cntlr {
# Ignore these, since they aren't big enough to be main
# memory, and we can'...
(procedure gen_memories line 9)
invoked from within
gen_memories $toplevel $hwproc_handle
(procedure ::sw_fdt::generate line 78)
invoked from within
::sw_fdt::generate 174540912
ERROR:MDT - Error while running generate for processor ppc405_0...
ERROR:MDT - : ld.so: object '/home/johann/Tools/usb_driver/libusb-driver.so'
from LD_PRELOAD cannot be preloaded: ignored.
make: *** [ppc405_0/lib/libxil.a] Error 2
Done!
I suggest this first draft below to fix it:
(assuming main bus is connected to PIM0)
--- fdt_v2_1_0.tcl.orig2008-05-08 19:46:22.0 +0200
+++ fdt_v2_1_0.tcl2008-06-18 15:47:49.0 +0200
@@ -475,7 +475,12 @@
set mpmc_node [lindex $tree 2]
}]} {
# No control port
+set share_addresses [scan_int_parameter_value $slave
C_ALL_PIMS_SHARE_ADDRESSES]
+if {$share_addresses == 0} {
+set baseaddr [scan_int_parameter_value $slave
C_PIM0_BASEADDR]
+} else {
set baseaddr [scan_int_parameter_value $slave C_MPMC_BASEADDR]
+}
set tree [slaveip_basic $slave $intc [format_ip_name mpmc
$baseaddr] ]
set ip_name [lindex $tree 0]
set mpmc_node [lindex $tree 2]
@@ -495,12 +500,12 @@
# Found an SDMA port
if {$share_addresses == 0} {
set baseaddr [scan_int_parameter_value $slave [format
C_SDMA_CTRL%d_BASEADDR $x]]
+set highaddr [scan_int_parameter_value $slave [format
C_SDMA_CTRL%d_HIGHADDR $x]]
} else {
set baseaddr [scan_int_parameter_value $slave
C_SDMA_CTRL_BASEADDR]
-}
set baseaddr [expr $baseaddr + $x * 0x80]
set highaddr [expr $baseaddr + 0x7f]
-
+}
set sdma_name [format_ip_name sdma $baseaddr PIM$x]
set sdma_tree [list $sdma_name tree {}]
set sdma_tree [tree_append $sdma_tree [gen_reg_property
$sdma_name $baseaddr $highaddr]]
@@ -783,7 +788,6 @@
set baseaddr [scan_int_parameter_value $slave [format
C_%sBASEADDR $baseaddr_prefix]]
set highaddr [scan_int_parameter_value $slave [format
C_%sHIGHADDR $baseaddr_prefix]]
-
lappend ip_node [gen_reg_property $name $baseaddr $highaddr]
lappend ip_node [list device_type string memory]
set ip_node [gen_params $ip_node $slave $params]
@@ -998,7 +1002,12 @@
}
}
mpmc {
+set share_addresses [scan_int_parameter_value $slave
C_ALL_PIMS_SHARE_ADDRESSES]
+if {$share_addresses != 0} {
lappend tree [memory $slave MPMC_ ]
+} else {
+lappend tree [memory $slave PIM0_ ]
+}
set memory_count [expr $memory_count + 1]
}
}
Best regards,
Johann Baudy
--
RT System Engineer - IXWAVES
Johann Baudy
Tel: +33(0)952335121
mail: [EMAIL PROTECTED]
IXWAVES
220 rue Albert Caquot
Sophia Antipolis
06560
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: XLLTemac with SGDMA working on virtex4FX ?
Hi John, I found a driver in the uboot ml from Yoshio Kashiwagi (Thanks :) link: http://www.nabble.com/Xilinx-PowerPC-XPS_LL_TEMAC-driver-td16893860.html#a1690 i didn't know how it works but it uses memcpy on tx and NetReceive() from uboot net.c ... I have to achieve an average speed of 20 MB/s. I hope it works ! Have you got some facts ? So, i don't know what i should do. I thought that xilinx drivers suppots there hw ! Should i try to integrate xilinx EDK generated drivers into xlnx kernel tree ? and how ? My computer and the temac are connected to a 1Gb switch and the led is blinking when the temac send something but not the led of my computer! as if the switch does not his job ! invalid frames ? is possible ? (i should have a break...) best regards, Simon --- En date de : Ven 13.6.08, John Linn [EMAIL PROTECTED] a écrit : De: John Linn [EMAIL PROTECTED] Objet: RE: XLLTemac with SGDMA working on virtex4FX ? À: Simon Frey [EMAIL PROTECTED], linuxppc-dev@ozlabs.org Date: Vendredi 13 Juin 2008, 17h52 Hi Simon, I have not done testing of this driver with checksum offload. I do test the driver in an automated test, but not in checksum offload mode, I need to add that test. I did receive the following patch and applied it to the Git server so I think Johann did some testing with checksum offload. That may have been with arch/ppc rather than arch/powerpc, not sure. I noticed that you have uboot working with LL TEMAC and it must be using DMA SG as it's running on the same h/w. I just got thru hacking together a rough polled mode LL TEMAC driver to support uboot and it's working, but not cleaned up. Just curious on your experience in that area. Thanks, John Linn Linux Development Strategy Xilinx is looking for embedded Linux developers *** the patch text I applied ** From: John Linn [EMAIL PROTECTED] Sent: Friday, April 04, 2008 10:25 AM To: git Cc: John Linn; Johann Baudy Subject: [PATCH] Xilinx: LL TEMAC: Fix checksum offload The LL TEMAC is generating the wrong checksum when TX hardware checksum is enabled. This is mainly due to two issues: - CHECKSUM_COMPLETE can only be used on RX PATH, CHECKSUM_PARTIAL must be used instead. - Checksum index offsets are being calculated wrong. Signed-off-by: Johann Baudy [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Frey Sent: Friday, June 13, 2008 8:46 AM To: linuxppc-dev@ozlabs.org Subject: XLLTemac with SGDMA working on virtex4FX ? Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[140] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 61704k/65536k available (2892k kernel code, 3768k reserved, 112k data, 141k bss, 144k init) Mount-cache hash table entries: 512 net_namespace: 536 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e3 (irq = 16) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded Device Tree Probing 'ethernet' xilinx_lltemac 81c0.ethernet: MAC address is now 0: a:35: 0:22: 1 xilinx_lltemac 81c0.ethernet: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy:
RE: XLLTemac with SGDMA working on virtex4FX ?
What board are you working on? Which phy option are you using? I'm guessing that there's something wrong in that area. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev- [EMAIL PROTECTED] On Behalf Of Simon Frey Sent: Friday, June 13, 2008 7:46 AM To: linuxppc-dev@ozlabs.org Subject: XLLTemac with SGDMA working on virtex4FX ? Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[140] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 61704k/65536k available (2892k kernel code, 3768k reserved, 112k data, 141k bss, 144k init) Mount-cache hash table entries: 512 net_namespace: 536 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled 83e0.serial: ttyS0 at MMIO 0x83e3 (irq = 16) is a 16550A console [ttyS0] enabled brd: module loaded loop: module loaded Device Tree Probing 'ethernet' xilinx_lltemac 81c0.ethernet: MAC address is now 0: a:35: 0:22: 1 xilinx_lltemac 81c0.ethernet: XLlTemac: using DMA mode. XLlTemac: Dma base address: phy: 0x84600100, virt: 0xc5010100 XLlTemac: buffer descriptor size: 32768 (0x8000) XLlTemac: Allocating DMA descriptors with kmalloc6XLlTemac: (buffer_descriptor_init) phy: 0x3868000, virt: 0xc3868000, size: 0x8000 XTemac: PHY detected at address 4. xilinx_lltemac 81c0.ethernet: eth0: Xilinx TEMAC at 0x81C0 mapped to 0xC500E000, irq=17 mice: PS/2 mouse device common for all mice TCP cubic registered NET: Registered protocol family 1 NET: Registered protocol family 17 RPC: Registered udp transport module. RPC: Registered tcp transport module. eth0: XLlTemac: Options: 0x3fa eth0: XLlTemac: allocating interrupt 19 for dma mode tx. eth0: XLlTemac: allocating interrupt 18 for dma mode rx. eth0: XLlTemac: speed set to 10Mb/s eth0: XLlTemac: Send Threshold = 240, Receive Threshold = 40 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 Sending DHCP requests .. timed out! IP-Config: Reopening network devices... eth0: XLlTemac: Options: 0x3fa I can see the led blinking on my switch but don't see nothing using wireshak !!! Finaly, i know the the temac works because i can use it with uboot !!! even at speed 1000. In:serial Out: serial Err: serial U-Boot relocated to 03fcf000 ### main_loop entered: bootdelay=3 ### main_loop: bootcmd=loooaadd %addr Press Enter within 3 seconds to stop autoboot Unknown command 'loooaadd' - try 'help' = setenv bootfile zImage.virtex = tftp 4 eth0: Xilinx XPS LocalLink Tri-Mode Ether MAC #0 at 0x81C0. 1000BASE-T/FD TFTP from server 192.168.1.100; our IP address is 192.168.1.200 Filename 'zImage.virtex'. Load address: 0x4 Loading: # done Bytes transferred = 1772215 (1b0ab7 hex) = so if someone already had that problem... Thanks in advance Simon _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev This email and any attachments are intended for the sole use of the named
Re: XLLTemac with SGDMA working on virtex4FX ?
Hi Simon, With EDK10.1, xps_ll_temac, ARCH=powerpc, I've reached ~17Mo/s with netperf (UDP) and ~30 Mo/s in raw packet mode. Are you using Xilinx evaluation board? If not pay attention to the PHY controller. (you may not use MARVELL_88E_PHY define) To check if you have some issues with checksum offload, you can use Wireshark (network analyzer). With this tool you will see your frames and if they are sent properly. Best regards, -- RT System Engineer - IXWAVES Johann Baudy On Fri, Jun 13, 2008 at 6:43 PM, Simon Frey [EMAIL PROTECTED] wrote: Hi John, I found a driver in the uboot ml from Yoshio Kashiwagi (Thanks :) link: http://www.nabble.com/Xilinx-PowerPC-XPS_LL_TEMAC-driver-td16893860.html#a1690 i didn't know how it works but it uses memcpy on tx and NetReceive() from uboot net.c ... I have to achieve an average speed of 20 MB/s. I hope it works ! Have you got some facts ? So, i don't know what i should do. I thought that xilinx drivers suppots there hw ! Should i try to integrate xilinx EDK generated drivers into xlnx kernel tree ? and how ? My computer and the temac are connected to a 1Gb switch and the led is blinking when the temac send something but not the led of my computer! as if the switch does not his job ! invalid frames ? is possible ? (i should have a break...) best regards, Simon --- En date de : Ven 13.6.08, John Linn [EMAIL PROTECTED] a écrit : De: John Linn [EMAIL PROTECTED] Objet: RE: XLLTemac with SGDMA working on virtex4FX ? À: Simon Frey [EMAIL PROTECTED], linuxppc-dev@ozlabs.org Date: Vendredi 13 Juin 2008, 17h52 Hi Simon, I have not done testing of this driver with checksum offload. I do test the driver in an automated test, but not in checksum offload mode, I need to add that test. I did receive the following patch and applied it to the Git server so I think Johann did some testing with checksum offload. That may have been with arch/ppc rather than arch/powerpc, not sure. I noticed that you have uboot working with LL TEMAC and it must be using DMA SG as it's running on the same h/w. I just got thru hacking together a rough polled mode LL TEMAC driver to support uboot and it's working, but not cleaned up. Just curious on your experience in that area. Thanks, John Linn Linux Development Strategy Xilinx is looking for embedded Linux developers *** the patch text I applied ** From: John Linn [EMAIL PROTECTED] Sent: Friday, April 04, 2008 10:25 AM To: git Cc: John Linn; Johann Baudy Subject: [PATCH] Xilinx: LL TEMAC: Fix checksum offload The LL TEMAC is generating the wrong checksum when TX hardware checksum is enabled. This is mainly due to two issues: - CHECKSUM_COMPLETE can only be used on RX PATH, CHECKSUM_PARTIAL must be used instead. - Checksum index offsets are being calculated wrong. Signed-off-by: Johann Baudy [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-dev-bounces+john.linnlinuxppc-dev-bounces%2Bjohn.linn [EMAIL PROTECTED] On Behalf Of Simon Frey Sent: Friday, June 13, 2008 8:46 AM To: linuxppc-dev@ozlabs.org Subject: XLLTemac with SGDMA working on virtex4FX ? Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash table entries: 256 (order: 8, 1024 bytes) clocksource: timebase mult[140] shift[22] registered Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 61704k/65536k available (2892k kernel code, 3768k reserved, 112k data, 141k bss, 144k init) Mount-cache hash table entries: 512 net_namespace: 536 bytes NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash
RE: gen-mhs-devtree - C_ALL_PIMS_SHARE_ADDRESSES=0
Good point. I'll see about integrating your patch.
Steve
-Original Message-
From: Johann Baudy [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 18, 2008 7:18 AM
To: Stephen Neuendorffer
Cc: linuxppc-dev@ozlabs.org
Subject: gen-mhs-devtree - C_ALL_PIMS_SHARE_ADDRESSES=0
Hi Stephen,
I wasn't able to get the FDT generator working with
C_ALL_PIMS_SHARE_ADDRESSES = 0 (parameter of MPMC) and EDK10.1 SP1
(you
will find error output below).
It seems that it's not fully supported in FDT TCL script yet!
Indeed, this script is looking for C_MPMC_BASEADDR instead of
C_PIMX_BASEADDR even if C_ALL_PIMS_SHARE_ADDRESSES = 0.
#--
# FDT BSP DRC...!
#--
Running generate for OS'es, Drivers and Libraries ...
#--
# FDT BSP generate...
#--
Clock Frequency: 3
+++ 151545648
Bus handle DPLB0 connected through a bus...
-master 151545648 DPLB0 plb ppc405_0
-master 151545648 IPLB0 plb ppc405_0
-slave 153793872 SPLB0 plb DDR_SDRAM_32Mx16
-slave 153793872 SDMA_CTRL1 plb DDR_SDRAM_32Mx16
-slave 153793872 SDMA_CTRL2 plb DDR_SDRAM_32Mx16
-slave 164169800 SPLB plb TriMode_MAC_GMII
-slave 166899408 SPLB plb xps_intc_0
-slave 167195280 SPLB plb common_gpio
-slave 167632152 SPLB plb xps_bram_if_cntlr_0
-slave 168015912 SPLB plb flash_ctrl_0
-slave 168339256 SPLB plb xps_uartlite_0
+++ 151545648
Bus handle DPLB1 connected directly...
VERSION
ERROR:MDT - fdt () - Bad highaddr for DDR_SDRAM_32Mx16
while executing
error Bad highaddr for $nodename
(procedure gen_reg_property line 10)
invoked from within
gen_reg_property $name $baseaddr $highaddr
(procedure memory line 12)
invoked from within
memory $slave MPMC_
(mpmc arm line 2)
invoked from within
switch $type {
plb_bram_if_cntlr -
opb_bram_if_cntlr {
# Ignore these, since they aren't big enough to be
main
# memory, and we can'...
(procedure gen_memories line 9)
invoked from within
gen_memories $toplevel $hwproc_handle
(procedure ::sw_fdt::generate line 78)
invoked from within
::sw_fdt::generate 174540912
ERROR:MDT - Error while running generate for processor ppc405_0...
ERROR:MDT - : ld.so: object
'/home/johann/Tools/usb_driver/libusb-driver.so'
from LD_PRELOAD cannot be preloaded: ignored.
make: *** [ppc405_0/lib/libxil.a] Error 2
Done!
I suggest this first draft below to fix it:
(assuming main bus is connected to PIM0)
--- fdt_v2_1_0.tcl.orig2008-05-08 19:46:22.0 +0200
+++ fdt_v2_1_0.tcl2008-06-18 15:47:49.0 +0200
@@ -475,7 +475,12 @@
set mpmc_node [lindex $tree 2]
}]} {
# No control port
+set share_addresses [scan_int_parameter_value $slave
C_ALL_PIMS_SHARE_ADDRESSES]
+if {$share_addresses == 0} {
+set baseaddr [scan_int_parameter_value $slave
C_PIM0_BASEADDR]
+} else {
set baseaddr [scan_int_parameter_value $slave
C_MPMC_BASEADDR]
+}
set tree [slaveip_basic $slave $intc [format_ip_name
mpmc
$baseaddr] ]
set ip_name [lindex $tree 0]
set mpmc_node [lindex $tree 2]
@@ -495,12 +500,12 @@
# Found an SDMA port
if {$share_addresses == 0} {
set baseaddr [scan_int_parameter_value $slave [format
C_SDMA_CTRL%d_BASEADDR $x]]
+set highaddr [scan_int_parameter_value $slave [format
C_SDMA_CTRL%d_HIGHADDR $x]]
} else {
set baseaddr [scan_int_parameter_value $slave
C_SDMA_CTRL_BASEADDR]
-}
set baseaddr [expr $baseaddr + $x * 0x80]
set highaddr [expr $baseaddr + 0x7f]
-
+}
set sdma_name [format_ip_name sdma $baseaddr PIM$x]
set sdma_tree [list $sdma_name tree {}]
set sdma_tree [tree_append $sdma_tree [gen_reg_property
$sdma_name $baseaddr $highaddr]]
@@ -783,7 +788,6 @@
set baseaddr [scan_int_parameter_value $slave [format
C_%sBASEADDR $baseaddr_prefix]]
set highaddr [scan_int_parameter_value $slave [format
C_%sHIGHADDR $baseaddr_prefix]]
-
lappend ip_node [gen_reg_property $name $baseaddr $highaddr]
lappend ip_node [list device_type string memory]
set ip_node [gen_params $ip_node $slave $params]
@@ -998,7 +1002,12 @@
}
}
mpmc {
+set share_addresses [scan_int_parameter_value $slave
C_ALL_PIMS_SHARE_ADDRESSES]
+if {$share_addresses != 0} {
lappend tree [memory $slave MPMC_ ]
+} else {
+lappend tree [memory $slave PIM0_ ]
+}
set memory_count [expr
Re: [RFC PATCH 2/2] Update defconfigs for CONFIG_HUGETLB
On Thu, 2008-06-12 at 22:36 +0300, Adrian Bunk wrote: On Thu, Jun 12, 2008 at 02:55:45PM -0400, Adam Litke wrote: Update all defconfigs that specify a default configuration for hugetlbfs. There is now only one option: CONFIG_HUGETLB. Replace the old CONFIG_HUGETLB_PAGE and CONFIG_HUGETLBFS options with the new one. I found no cases where CONFIG_HUGETLBFS and CONFIG_HUGETLB_PAGE had different values so this patch is large but completely mechanical: ... 335 files changed, 335 insertions(+), 385 deletions(-) ... Please don't do this kind of patches - it doesn't bring any advantage but can create tons of patch conflicts. The next time a defconfig gets updated it will anyway automatically be fixed, and for defconfigs that aren't updated it doesn't create any problems to keep them as they are today until they might one day get updated. Thanks for taking a look. I am not sure if I have ever seen a defconfig patch hit the mailing list before and I was wondering how those changes happen. In any case I am perfectly happy to drop this huge patch and stick with just the first one. -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Xilinx EDK 10.1 and XUPV2P: A little report
Hello list I have tried to port Linux 2.6 (xilinx git) to a XUPV2P board running a system implemented with EDK10.1 (Linux Version). I have fail, and I think I now why, this is a little report written for saving you some time (and maybe solving my problem if I am doing something wrong) The board is not supported by EDK 10.1, but I have found a Board Support File form https://wiki.ittc.ku.edu that seems to work. To start I have created a design that consists on a ppc, the mpmc, an uartlite, an interrupt manager and some bram. The basic programs worked ok on it. I have downloaded the kernel form xilinx git and adapted the xparameters file to fit my design. I have created a toolchain using OpenEmbedded and compiled the kernel with it, then I have downloaded the binary to the board and everything works fine until Now booting the kernel Debugging the kernel I have found that the system crashes (Exception 0x700) setting the mmu inside start_here (head_4xx.S)... Because it was a crash in the very beginning of my kernel live I developed some simple apps to tests all my peripherals and they worked ok in real mode: All of them worked OK BUT I have created a small piece of code that tests the peripherals in virtual mode and when the program is linked to the ram the system crashes!! Strangely, it works ok when it runs from bram. The same code works perfectly on a design created with EDK 8.1 and the kernel also works fine. I attach the source code of my test app and the OpenEmbedded parameters I have used. Best Regards - main: .globl main my_code: bl uart tlbia isync lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 iccci r0,r3 /*PID*/ li r0,0 mtpid r0 sync mem_map: /*RAM*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,768 rlwinm r3,r3,0,0,21 ori r3,r3,960 /*16M*/ li r0,0 tlbwelo r4,r0 tlbwehi r3,r0 /*BRAM*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,768 rlwinm r3,r3,0,0,21 ori r3,r3,448 /* 64K */ li r0,1 tlbwelo r4,r0 tlbwehi r3,r0 /*UARTLITE*/ lis r3,[EMAIL PROTECTED] ori r3,r3,[EMAIL PROTECTED] mr r4,r3 rlwinm r4,r4,0,0,21 ori r4,r4,263 rlwinm r3,r3,0,0,21 ori r3,r3,448 /*64K*/ li r0,2 tlbwelo r4,r0 tlbwehi r3,r0 sync on_mmu: lis r0,0 ori r0,r0,4146 mtsrr1 r0 lis r0,[EMAIL PROTECTED] ori r0,r0,[EMAIL PROTECTED] mtsrr0 r0 rfi b . uart: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r14,0x0 stb r14,0x0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] busy: lwz r10,0(r11) andi. r12,r10,8 bne+ busy lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r14,0x32 stb r14,0x0(r11) br rw_ram: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] lwz r10,0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r10,0xcc stb r10,0x0(r11) br rw_rom: lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] lwz r10,0(r11) lis r11,[EMAIL PROTECTED] ori r11,r11,[EMAIL PROTECTED] li r10,0xcc stb r10,0x0(r11) br bucle: bl rw_ram bl uart bl rw_rom bl bucle --- OpenEmbedded Parameters: PREFERRED_VERSION_gcc = 4.2.1 PREFERRED_VERSION_gcc-cross = 4.2.1 PREFERRED_VERSION_gcc-cross-initial = 4.2.1 PREFERRED_VERSION_binutils = 2.18 PREFERRED_VERSION_binutils-cross = 2.18 PREFERRED_VERSION_glibc = 2.5 PREFERRED_VERSION_glibc-intermediate = 2.5 PREFERRED_VERSION_linux-libc-headers = 2.6.25 -- Ricardo Ribalda http://www.eps.uam.es/~rribalda/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 10/19] [repost] powerpc: move get_longbusy_msecs out of ehca/ehea
Jeff,
Regarding the patches Rob just posted here, we'd like to just take them
through the powerpc tree with your sign off since they are part of a
Power platform feature we are enabling.
Thanks,
Brian
Robert Jennings wrote:
From: Robert Jennings [EMAIL PROTECTED]
In support of Cooperative Memory Overcommitment (CMO) this moves
get_longbusy_msecs() out of the ehca and ehea drivers and into the
architecture's hvcall header as plpar_get_longbusy_msecs. Some firmware
calls made in pSeries platform iommu code will need to share this
functionality.
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
I missed copying netdev on this patch the first time.
drivers/infiniband/hw/ehca/hcp_if.c | 24 ++--
drivers/net/ehea/ehea_phyp.c|4 ++--
drivers/net/ehea/ehea_phyp.h| 20
include/asm-powerpc/hvcall.h| 27 +++
4 files changed, 31 insertions(+), 44 deletions(-)
Index: b/drivers/infiniband/hw/ehca/hcp_if.c
===
--- a/drivers/infiniband/hw/ehca/hcp_if.c
+++ b/drivers/infiniband/hw/ehca/hcp_if.c
@@ -90,26 +90,6 @@
static DEFINE_SPINLOCK(hcall_lock);
-static u32 get_longbusy_msecs(int longbusy_rc)
-{
- switch (longbusy_rc) {
- case H_LONG_BUSY_ORDER_1_MSEC:
- return 1;
- case H_LONG_BUSY_ORDER_10_MSEC:
- return 10;
- case H_LONG_BUSY_ORDER_100_MSEC:
- return 100;
- case H_LONG_BUSY_ORDER_1_SEC:
- return 1000;
- case H_LONG_BUSY_ORDER_10_SEC:
- return 1;
- case H_LONG_BUSY_ORDER_100_SEC:
- return 10;
- default:
- return 1;
- }
-}
-
static long ehca_plpar_hcall_norets(unsigned long opcode,
unsigned long arg1,
unsigned long arg2,
@@ -139,7 +119,7 @@ static long ehca_plpar_hcall_norets(unsi
spin_unlock_irqrestore(hcall_lock, flags);
if (H_IS_LONG_BUSY(ret)) {
- sleep_msecs = get_longbusy_msecs(ret);
+ sleep_msecs = plpar_get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
@@ -192,7 +172,7 @@ static long ehca_plpar_hcall9(unsigned l
spin_unlock_irqrestore(hcall_lock, flags);
if (H_IS_LONG_BUSY(ret)) {
- sleep_msecs = get_longbusy_msecs(ret);
+ sleep_msecs = plpar_get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
Index: b/drivers/net/ehea/ehea_phyp.c
===
--- a/drivers/net/ehea/ehea_phyp.c
+++ b/drivers/net/ehea/ehea_phyp.c
@@ -61,7 +61,7 @@ static long ehea_plpar_hcall_norets(unsi
arg5, arg6, arg7);
if (H_IS_LONG_BUSY(ret)) {
- sleep_msecs = get_longbusy_msecs(ret);
+ sleep_msecs = plpar_get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
@@ -102,7 +102,7 @@ static long ehea_plpar_hcall9(unsigned l
arg6, arg7, arg8, arg9);
if (H_IS_LONG_BUSY(ret)) {
- sleep_msecs = get_longbusy_msecs(ret);
+ sleep_msecs = plpar_get_longbusy_msecs(ret);
msleep_interruptible(sleep_msecs);
continue;
}
Index: b/drivers/net/ehea/ehea_phyp.h
===
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -40,26 +40,6 @@
* hcp_* - structures, variables and functions releated to Hypervisor Calls
*/
-static inline u32 get_longbusy_msecs(int long_busy_ret_code)
-{
- switch (long_busy_ret_code) {
- case H_LONG_BUSY_ORDER_1_MSEC:
- return 1;
- case H_LONG_BUSY_ORDER_10_MSEC:
- return 10;
- case H_LONG_BUSY_ORDER_100_MSEC:
- return 100;
- case H_LONG_BUSY_ORDER_1_SEC:
- return 1000;
- case H_LONG_BUSY_ORDER_10_SEC:
- return 1;
- case H_LONG_BUSY_ORDER_100_SEC:
- return 10;
- default:
- return 1;
- }
-}
-
/* Number of pages which can be registered at once by H_REGISTER_HEA_RPAGES
*/
#define EHEA_MAX_RPAGE 512
Index: b/include/asm-powerpc/hvcall.h
===
--- a/include/asm-powerpc/hvcall.h
+++ b/include/asm-powerpc/hvcall.h
@@ -222,6 +222,33 @@
#ifndef __ASSEMBLY__
/**
+ * plpar_get_longbusy_msecs:
Re: [PATCH 18/19] ibmvscsi: driver enablement for CMO
CC'ing linux-scsi, although we'd like to take this through the powerpc tree
since it
is part of a patch set to enable a Power platform feature.
-Brian
Robert Jennings wrote:
From: Robert Jennings [EMAIL PROTECTED]
Enable the driver to function in a Cooperative Memory Overcommitment (CMO)
environment.
The following changes are made to enable the driver for CMO:
* DMA mapping errors will not result in error messages if entitlement has
been exceeded and resources were not available.
* The driver has a get_io_entitlement function defined to function
in a CMO environment. It will indicate how much IO memory it would like
to function.
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
drivers/scsi/ibmvscsi/ibmvscsi.c | 46
+--
drivers/scsi/ibmvscsi/ibmvscsi.h |2 ++
2 files changed, 41 insertions(+), 7 deletions(-)
Index: b/drivers/scsi/ibmvscsi/ibmvscsi.c
===
--- a/drivers/scsi/ibmvscsi/ibmvscsi.c
+++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
@@ -72,6 +72,8 @@
#include linux/delay.h
#include asm/firmware.h
#include asm/vio.h
+#include asm/firmware.h
+#include asm/iommu.h
#include scsi/scsi.h
#include scsi/scsi_cmnd.h
#include scsi/scsi_host.h
@@ -426,8 +428,10 @@ static int map_sg_data(struct scsi_cmnd
SG_ALL * sizeof(struct
srp_direct_buf),
evt_struct-ext_list_token, 0);
if (!evt_struct-ext_list) {
- sdev_printk(KERN_ERR, cmd-device,
- Can't allocate memory for indirect
table\n);
+ if (!firmware_has_feature(FW_FEATURE_CMO))
+ sdev_printk(KERN_ERR, cmd-device,
+ Can't allocate memory
+ for indirect table\n);
return 0;
}
}
@@ -743,7 +747,9 @@ static int ibmvscsi_queuecommand(struct
srp_cmd-lun = ((u64) lun) 48;
if (!map_data_for_srp_cmd(cmnd, evt_struct, srp_cmd, hostdata-dev)) {
- sdev_printk(KERN_ERR, cmnd-device, couldn't convert cmd to
srp_cmd\n);
+ if (!firmware_has_feature(FW_FEATURE_CMO))
+ sdev_printk(KERN_ERR, cmnd-device,
+ couldn't convert cmd to srp_cmd\n);
free_event_struct(hostdata-pool, evt_struct);
return SCSI_MLQUEUE_HOST_BUSY;
}
@@ -855,7 +861,10 @@ static void send_mad_adapter_info(struct
DMA_BIDIRECTIONAL);
if (dma_mapping_error(req-buffer)) {
- dev_err(hostdata-dev, Unable to map request_buffer for
adapter_info!\n);
+ if (!firmware_has_feature(FW_FEATURE_CMO))
+ dev_err(hostdata-dev,
+ Unable to map request_buffer for
+ adapter_info!\n);
free_event_struct(hostdata-pool, evt_struct);
return;
}
@@ -1400,7 +1409,9 @@ static int ibmvscsi_do_host_config(struc
DMA_BIDIRECTIONAL);
if (dma_mapping_error(host_config-buffer)) {
- dev_err(hostdata-dev, dma_mapping error getting host
config\n);
+ if (!firmware_has_feature(FW_FEATURE_CMO))
+ dev_err(hostdata-dev,
+ dma_mapping error getting host config\n);
free_event_struct(hostdata-pool, evt_struct);
return -1;
}
@@ -1604,7 +1615,7 @@ static struct scsi_host_template driver_
.eh_host_reset_handler = ibmvscsi_eh_host_reset_handler,
.slave_configure = ibmvscsi_slave_configure,
.change_queue_depth = ibmvscsi_change_queue_depth,
- .cmd_per_lun = 16,
+ .cmd_per_lun = IBMVSCSI_CMDS_PER_LUN_DEFAULT,
.can_queue = IBMVSCSI_MAX_REQUESTS_DEFAULT,
.this_id = -1,
.sg_tablesize = SG_ALL,
@@ -1613,6 +1624,26 @@ static struct scsi_host_template driver_
};
/**
+ * ibmvscsi_get_io_entitlement - Calculate IO entitlement needed by the
driver
+ *
+ * @vdev: struct vio_dev for the device whose entitlement is to be returned
+ *
+ * Return value:
+ * Number of bytes of IO data the driver will need to perform well.
+ */
+static unsigned long ibmvscsi_get_io_entitlement(struct vio_dev *vdev)
+{
+ /* iu_storage data allocated in initialize_event_pool */
+ unsigned long io_entitlement = max_requests * sizeof(union viosrp_iu);
+
+ /* add io space for sg data */
+ io_entitlement += (IBMVSCSI_MAX_SECTORS_DEFAULT *
+ IBMVSCSI_CMDS_PER_LUN_DEFAULT);
+
+ return IOMMU_PAGE_ALIGN(io_entitlement);
+}
+
+/**
* Called by bus code for each adapter
*/
static int
Re: Using DMA interrupt on MPC8313
So after I've built the kernel to include the dmaengine and fsldma drivers, my driver is allowed to register its ISR via request_irq. However, if these drivers are not installed then request_irq fails in my driver. So it seems that there is some other initialization happening before request_irq is being called in fsldma and subsequently my driver. Does anyone know what this is? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: The dmaengine provides a generic set of APIs w/a FSL dma backend. It might be the case that your need of dma doesnt fit into the current set of APIs. - k On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote: Well in that case wouldn't I need to use the fsldma driver? Or is dmaengine a generic dma driver? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote: I'm trying to write a driver that would make use of the DMA on the MPC8313. I'm attempting to register the interrupt with request_irq but it is not passing. Is there something that I need to do before I call request_irq, maybe in the dts or somewhere else? any reason you aren't using the dmaengine driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [8xx] powerpc: Add support for the MPC852 based mgsuvd board from keymile.
Hello Scott,
here the next try for the mgsuvd board:
[powerpc] add support for the MPC852 based mgsuvd board from
keymile to arch/powerpc. Supported SMC1 (serial console),
SCC3 Ethernet (10Mbps hdx).
Signed-off-by: Heiko Schocher [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mgsuvd.dts | 163 ++
arch/powerpc/configs/mgsuvd_defconfig | 872 +
arch/powerpc/platforms/8xx/Kconfig|6 +
arch/powerpc/platforms/8xx/Makefile |1 +
arch/powerpc/platforms/8xx/mgsuvd.c | 93
5 files changed, 1135 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/mgsuvd.dts
create mode 100644 arch/powerpc/configs/mgsuvd_defconfig
create mode 100644 arch/powerpc/platforms/8xx/mgsuvd.c
diff --git a/arch/powerpc/boot/dts/mgsuvd.dts b/arch/powerpc/boot/dts/mgsuvd.dts
new file mode 100644
index 000..f78d5de
--- /dev/null
+++ b/arch/powerpc/boot/dts/mgsuvd.dts
@@ -0,0 +1,163 @@
+/*
+ * MGSUVD Device Tree Source
+ *
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Heiko Schocher [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+/dts-v1/;
+/ {
+ model = MGSUVD;
+ compatible = keymile,mgsuvd;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,[EMAIL PROTECTED] {
+ device_type = cpu;
+ reg = 0;
+ d-cache-line-size = 16;
+ i-cache-line-size = 16;
+ d-cache-size = 8192;
+ i-cache-size = 8192;
+ timebase-frequency = 0; /* Filled in by u-boot
*/
+ bus-frequency = 0;/* Filled in by u-boot
*/
+ clock-frequency = 0; /* Filled in by u-boot
*/
+ interrupts = 15 2;/* decrementer
interrupt */
+ interrupt-parent = PIC;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x400; /* Filled in by u-boot */
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc852-localbus, fsl,pq1-localbus,
simple-bus;
+ #address-cells = 2;
+ #size-cells = 1;
+ reg = 0xfff00100 0x40;
+
+ ranges = 0 0 0xf000 0x0100; /* Filled in by u-boot */
+
+ [EMAIL PROTECTED],0 {
+ compatible = cfi-flash;
+ reg = 0 0 0x100;
+ #address-cells = 1;
+ #size-cells = 1;
+ bank-width = 1;
+ device-width = 1;
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 0 0x8;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 0x8 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0xa 0x1e;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 0x28 0x2;
+ };
+ [EMAIL PROTECTED] {
+ label = root;
+ reg = 0x2a 0x50;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 0x7a 0x86;
+ };
+ };
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = fsl,mpc852, fsl,pq1-soc, simple-bus;
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ ranges = 0 0xfff0 0x4000;
+
+ PIC: [EMAIL PROTECTED] {
+ interrupt-controller;
+ #interrupt-cells = 2;
+ reg = 0 24;
+ compatible = fsl,mpc852-pic, fsl,pq1-pic;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc852-cpm, fsl,cpm1, simple-bus;
+ interrupts = 0; /* cpm error interrupt */
+ interrupt-parent = CPM_PIC;
+ reg = 0x9c0 10;
+
Re: [PATCH 02/19] powerpc: Split processor entitlement retrieval and gathering to helper routines
Stephen Rothwell wrote: Hi Robert, On Thu, 12 Jun 2008 17:08:58 -0500 Robert Jennings [EMAIL PROTECTED] wrote: - seq_printf(m, R4=0x%lx\n, h_entitled); - seq_printf(m, R5=0x%lx\n, h_unallocated); - seq_printf(m, R6=0x%lx\n, h_aggregation); - seq_printf(m, R7=0x%lx\n, h_resource); This changes a user visible interface by removing the above. I don't know if this matters (probably not), but it should be mentioned in the changelog. You're right this should have been mentioned. The values it is printing out are the raw values returned from the H_GET_PPP hcall. The values were then parsed and pretty printed afterwards. I don't see a need to print these values out twice. + if (new_entitled) + *new_weight = current_weight; + + if (new_weight) + *new_entitled = current_entitled; These look fishy - checking one pointer for NULL and then updating via the other pointer. I thought something about this looked strange... Unfortunately this code gets slightly updated again in patch 3/19 of this patch series. The point you make is valid though, should not be de-referencing the pointers without validating them. I'll update this patch with a new changelog and pull the change from patch 3/19 into this pach where it belongs. -Nathan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: XLLTemac with SGDMA working on virtex4FX ?
Hi Simon, See my comments in-line below. Thanks, John -Original Message- From: Simon Frey [mailto:[EMAIL PROTECTED] Sent: Friday, June 13, 2008 10:43 AM To: John Linn; linuxppc-dev@ozlabs.org Subject: RE: XLLTemac with SGDMA working on virtex4FX ? Hi John, I found a driver in the uboot ml from Yoshio Kashiwagi (Thanks :) link: http://www.nabble.com/Xilinx-PowerPC-XPS_LL_TEMAC-driver-td16893860.html#a1690 i didn't know how it works but it uses memcpy on tx and NetReceive() from uboot net.c ... I have to achieve an average speed of 20 MB/s. I hope it works ! Have you got some facts ? John's response follows * My hacked on driver uses DMA SG in a polled mode and does not do any copies. But I have not idea what the performance is as it is not finished. It is functioning, but needs more work. It's still too early to tell performance and I'm diverted right now on other work. * So, i don't know what i should do. I thought that xilinx drivers suppots there hw ! Should i try to integrate xilinx EDK generated drivers into xlnx kernel tree ? and how ? My computer and the temac are connected to a 1Gb switch and the led is blinking when the temac send something but not the led of my computer! as if the switch does not his job ! invalid frames ? is possible ? (i should have a break...) John's response follows * The Xilinx drivers in the Embedded Development Kit for standalone operation and commercial Linux have full test coverage with the Xilinx hardware. The Xilinx Git server is a less mature initiative and we don't yet have full test coverage. We plan to continue increasing our test coverage thru our automated testing so that the open source drivers have better test coverage also. Have you tested this system configuration without checksum offload to make sure the system configuration is ok? The default configuration of the kernel in the Git tree, ml405_defconfig and ml507-defconfig, is setup to give users a baseline using a reference bitstream on the http://git.xilinx.com site. * best regards, Simon --- En date de : Ven 13.6.08, John Linn [EMAIL PROTECTED] a écrit : De: John Linn [EMAIL PROTECTED] Objet: RE: XLLTemac with SGDMA working on virtex4FX ? À: Simon Frey [EMAIL PROTECTED], linuxppc-dev@ozlabs.org Date: Vendredi 13 Juin 2008, 17h52 Hi Simon, I have not done testing of this driver with checksum offload. I do test the driver in an automated test, but not in checksum offload mode, I need to add that test. I did receive the following patch and applied it to the Git server so I think Johann did some testing with checksum offload. That may have been with arch/ppc rather than arch/powerpc, not sure. I noticed that you have uboot working with LL TEMAC and it must be using DMA SG as it's running on the same h/w. I just got thru hacking together a rough polled mode LL TEMAC driver to support uboot and it's working, but not cleaned up. Just curious on your experience in that area. Thanks, John Linn Linux Development Strategy Xilinx is looking for embedded Linux developers *** the patch text I applied ** From: John Linn [EMAIL PROTECTED] Sent: Friday, April 04, 2008 10:25 AM To: git Cc: John Linn; Johann Baudy Subject: [PATCH] Xilinx: LL TEMAC: Fix checksum offload The LL TEMAC is generating the wrong checksum when TX hardware checksum is enabled. This is mainly due to two issues: - CHECKSUM_COMPLETE can only be used on RX PATH, CHECKSUM_PARTIAL must be used instead. - Checksum index offsets are being calculated wrong. Signed-off-by: Johann Baudy [EMAIL PROTECTED] Signed-off-by: John Linn [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Frey Sent: Friday, June 13, 2008 8:46 AM To: linuxppc-dev@ozlabs.org Subject: XLLTemac with SGDMA working on virtex4FX ? Hi all, does anyone have working driver for xps_ll_temac unsing sg dma and checksum offload on rx and tx ?? I use the xlnx kernel with ARCH=powerpc and a device tree generated with the gen_mhs_devtree under EDK 10.1 I don't know what's wrong but i can't get or send anything even the speed is only 10 Mb/s ! that's what i get when the kernel starts... ## Starting application at 0x004007d0 ... Using Xilinx Virtex machine description Linux version 2.6.25-xlnx ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 PREEMPT Fri Jun 13 15:51:29 CEST 2008 Zone PFN ranges: DMA 0 -16384 Normal 16384 -16384 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -16384 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: console=ttyS0,115200 ip=dhcp Xilinx intc at 0x8180 mapped to 0xfdfff000 PID hash
Re: [PATCH 10/19] [repost] powerpc: move get_longbusy_msecs out of ehca/ehea
Brian King wrote: Jeff, Regarding the patches Rob just posted here, we'd like to just take them through the powerpc tree with your sign off since they are part of a Power platform feature we are enabling. Thanks, Brian Robert Jennings wrote: From: Robert Jennings [EMAIL PROTECTED] In support of Cooperative Memory Overcommitment (CMO) this moves get_longbusy_msecs() out of the ehca and ehea drivers and into the architecture's hvcall header as plpar_get_longbusy_msecs. Some firmware calls made in pSeries platform iommu code will need to share this functionality. Signed-off-by: Robert Jennings [EMAIL PROTECTED] --- I missed copying netdev on this patch the first time. drivers/infiniband/hw/ehca/hcp_if.c | 24 ++-- drivers/net/ehea/ehea_phyp.c|4 ++-- drivers/net/ehea/ehea_phyp.h| 20 include/asm-powerpc/hvcall.h| 27 +++ 4 files changed, 31 insertions(+), 44 deletions(-) ACK the quoted patch ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Silly spelling fix in pgtable-ppc32
Signed-off-by: Becky Bruce [EMAIL PROTECTED] --- include/asm-powerpc/pgtable-ppc32.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-powerpc/pgtable-ppc32.h b/include/asm-powerpc/pgtable-ppc32.h index c08e714..dde466b 100644 --- a/include/asm-powerpc/pgtable-ppc32.h +++ b/include/asm-powerpc/pgtable-ppc32.h @@ -620,8 +620,8 @@ static inline void set_pte_at(struct mm_struct *mm, unsigned long addr, } /* - * 2.6 calles this without flushing the TLB entry, this is wrong - * for our hash-based implementation, we fix that up here + * 2.6 calls this without flushing the TLB entry; this is wrong + * for our hash-based implementation, we fix that up here. */ #define __HAVE_ARCH_PTEP_TEST_AND_CLEAR_YOUNG static inline int __ptep_test_and_clear_young(unsigned int context, unsigned long addr, pte_t *ptep) -- 1.5.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
That's a bit odd. How is your driver getting the IRQ its requesting? Are you using the same .dts in both cases? - k On Jun 13, 2008, at 2:02 PM, Ron Madrid wrote: So after I've built the kernel to include the dmaengine and fsldma drivers, my driver is allowed to register its ISR via request_irq. However, if these drivers are not installed then request_irq fails in my driver. So it seems that there is some other initialization happening before request_irq is being called in fsldma and subsequently my driver. Does anyone know what this is? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: The dmaengine provides a generic set of APIs w/a FSL dma backend. It might be the case that your need of dma doesnt fit into the current set of APIs. - k On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote: Well in that case wouldn't I need to use the fsldma driver? Or is dmaengine a generic dma driver? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote: I'm trying to write a driver that would make use of the DMA on the MPC8313. I'm attempting to register the interrupt with request_irq but it is not passing. Is there something that I need to do before I call request_irq, maybe in the dts or somewhere else? any reason you aren't using the dmaengine driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc: Change BAT code to use phys_addr_t
Currently, the physical address is an unsigned long, but it should
be phys_addr_t in set_bat, [v/p]_mapped_by_bat. Also, create a
macro that can convert a large physical address into the correct
format for programming the BAT registers.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/mm/mmu_decl.h |2 +-
arch/powerpc/mm/pgtable_32.c |6 +++---
arch/powerpc/mm/ppc_mmu_32.c | 10 +-
include/asm-powerpc/mmu-hash32.h |9 +
4 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
index 0480225..46585b7 100644
--- a/arch/powerpc/mm/mmu_decl.h
+++ b/arch/powerpc/mm/mmu_decl.h
@@ -29,7 +29,7 @@ extern void hash_preload(struct mm_struct *mm, unsigned long
ea,
#ifdef CONFIG_PPC32
extern void mapin_ram(void);
extern int map_page(unsigned long va, phys_addr_t pa, int flags);
-extern void setbat(int index, unsigned long virt, unsigned long phys,
+extern void setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags);
extern void settlbcam(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags, unsigned int pid);
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index e0ff59f..c758407 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -53,9 +53,9 @@ extern void hash_page_sync(void);
#endif
#ifdef HAVE_BATS
-extern unsigned long v_mapped_by_bats(unsigned long va);
-extern unsigned long p_mapped_by_bats(unsigned long pa);
-void setbat(int index, unsigned long virt, unsigned long phys,
+extern phys_addr_t v_mapped_by_bats(unsigned long va);
+extern unsigned long p_mapped_by_bats(phys_addr_t pa);
+void setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags);
#else /* !HAVE_BATS */
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index cef9f15..55ec17e 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -46,13 +46,13 @@ union ubat {/* BAT register values
to be loaded */
struct batrange { /* stores address ranges mapped by BATs */
unsigned long start;
unsigned long limit;
- unsigned long phys;
+ phys_addr_t phys;
} bat_addrs[8];
/*
* Return PA for this VA if it is mapped by a BAT, or 0
*/
-unsigned long v_mapped_by_bats(unsigned long va)
+phys_addr_t v_mapped_by_bats(unsigned long va)
{
int b;
for (b = 0; b 4; ++b)
@@ -64,7 +64,7 @@ unsigned long v_mapped_by_bats(unsigned long va)
/*
* Return VA for a given PA or 0 if not mapped
*/
-unsigned long p_mapped_by_bats(unsigned long pa)
+unsigned long p_mapped_by_bats(phys_addr_t pa)
{
int b;
for (b = 0; b 4; ++b)
@@ -119,7 +119,7 @@ unsigned long __init mmu_mapin_ram(void)
* The parameters are not checked; in particular size must be a power
* of 2 between 128k and 256M.
*/
-void __init setbat(int index, unsigned long virt, unsigned long phys,
+void __init setbat(int index, unsigned long virt, phys_addr_t phys,
unsigned int size, int flags)
{
unsigned int bl;
@@ -138,7 +138,7 @@ void __init setbat(int index, unsigned long virt, unsigned
long phys,
| _PAGE_COHERENT | _PAGE_GUARDED);
wimgxpp |= (flags _PAGE_RW)? BPP_RW: BPP_RX;
bat[1].word[0] = virt | (bl 2) | 2; /* Vs=1, Vp=0 */
- bat[1].word[1] = phys | wimgxpp;
+ bat[1].word[1] = BAT_PHYS_ADDR(phys) | wimgxpp;
#ifndef CONFIG_KGDB /* want user access for breakpoints */
if (flags _PAGE_USER)
#endif
diff --git a/include/asm-powerpc/mmu-hash32.h b/include/asm-powerpc/mmu-hash32.h
index 6e21ca6..f39ff98 100644
--- a/include/asm-powerpc/mmu-hash32.h
+++ b/include/asm-powerpc/mmu-hash32.h
@@ -28,6 +28,15 @@
#define BPP_RW 0x02/* Read/write */
#ifndef __ASSEMBLY__
+/* Contort a phys_addr_t into the right format/bits for a BAT */
+#ifdef CONFIG_PHYS_64BIT
+#define BAT_PHYS_ADDR(x) ((u32)((x 0xfffeULL) | \
+ ((x 0x000eULL) 24) | \
+ ((x 0x0001ULL) 30)))
+#else
+#define BAT_PHYS_ADDR(x) (x)
+#endif
+
struct ppc_bat {
struct {
unsigned long bepi:15; /* Effective page index (virtual
address) */
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc: Get rid of bitfields in ppc_bat struct
While working on the 36-bit physical support, I noticed that there
was exactly one line of code that actually referenced the bitfields.
So I got rid of them and redefined ppc_bat as a struct of 2 u32's:
batu and batl. I also got rid of the previous union that held the
bitfield structs and a word representation of the batu/l values.
This seems like a nicer solution than adding in a bunch of
new bitfields to support extended bat addressing that would never
get used, and just leaving the struct as-is would have been
incomplete in the face of large physical addressing.
Signed-off-by: Becky Bruce [EMAIL PROTECTED]
---
arch/powerpc/mm/ppc_mmu_32.c | 19 ---
include/asm-powerpc/mmu-hash32.h | 19 ++-
2 files changed, 10 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 55ec17e..c53145f 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -38,10 +38,7 @@ struct hash_pte *Hash, *Hash_end;
unsigned long Hash_size, Hash_mask;
unsigned long _SDR1;
-union ubat { /* BAT register values to be loaded */
- struct ppc_bat bat;
- u32 word[2];
-} BATS[8][2]; /* 8 pairs of IBAT, DBAT */
+struct ppc_bat BATS[8][2]; /* 8 pairs of IBAT, DBAT */
struct batrange { /* stores address ranges mapped by BATs */
unsigned long start;
@@ -124,7 +121,7 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
{
unsigned int bl;
int wimgxpp;
- union ubat *bat = BATS[index];
+ struct ppc_bat *bat = BATS[index];
if (((flags _PAGE_NO_CACHE) == 0)
cpu_has_feature(CPU_FTR_NEED_COHERENT))
@@ -137,15 +134,15 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
wimgxpp = flags (_PAGE_WRITETHRU | _PAGE_NO_CACHE
| _PAGE_COHERENT | _PAGE_GUARDED);
wimgxpp |= (flags _PAGE_RW)? BPP_RW: BPP_RX;
- bat[1].word[0] = virt | (bl 2) | 2; /* Vs=1, Vp=0 */
- bat[1].word[1] = BAT_PHYS_ADDR(phys) | wimgxpp;
+ bat[1].batu = virt | (bl 2) | 2; /* Vs=1, Vp=0 */
+ bat[1].batl = BAT_PHYS_ADDR(phys) | wimgxpp;
#ifndef CONFIG_KGDB /* want user access for breakpoints */
if (flags _PAGE_USER)
#endif
- bat[1].bat.batu.vp = 1;
+ bat[1].batu |= 1; /* Vp = 1 */
if (flags _PAGE_GUARDED) {
/* G bit must be zero in IBATs */
- bat[0].word[0] = bat[0].word[1] = 0;
+ bat[0].batu = bat[0].batl = 0;
} else {
/* make IBAT same as DBAT */
bat[0] = bat[1];
@@ -158,8 +155,8 @@ void __init setbat(int index, unsigned long virt,
phys_addr_t phys,
| _PAGE_COHERENT);
wimgxpp |= (flags _PAGE_RW)?
((flags _PAGE_USER)? PP_RWRW: PP_RWXX): PP_RXRX;
- bat-word[0] = virt | wimgxpp | 4; /* Ks=0, Ku=1 */
- bat-word[1] = phys | bl | 0x40;/* V=1 */
+ bat-batu = virt | wimgxpp | 4; /* Ks=0, Ku=1 */
+ bat-batl = phys | bl | 0x40; /* V=1 */
}
bat_addrs[index].start = virt;
diff --git a/include/asm-powerpc/mmu-hash32.h b/include/asm-powerpc/mmu-hash32.h
index f39ff98..16b1a1e 100644
--- a/include/asm-powerpc/mmu-hash32.h
+++ b/include/asm-powerpc/mmu-hash32.h
@@ -38,23 +38,8 @@
#endif
struct ppc_bat {
- struct {
- unsigned long bepi:15; /* Effective page index (virtual
address) */
- unsigned long :4; /* Unused */
- unsigned long bl:11;/* Block size mask */
- unsigned long vs:1; /* Supervisor valid */
- unsigned long vp:1; /* User valid */
- } batu; /* Upper register */
- struct {
- unsigned long brpn:15; /* Real page index (physical address) */
- unsigned long :10; /* Unused */
- unsigned long w:1; /* Write-thru cache */
- unsigned long i:1; /* Cache inhibit */
- unsigned long m:1; /* Memory coherence */
- unsigned long g:1; /* Guarded (MBZ in IBAT) */
- unsigned long :1; /* Unused */
- unsigned long pp:2; /* Page access protections */
- } batl; /* Lower register */
+ u32 batu;
+ u32 batl;
};
#endif /* !__ASSEMBLY__ */
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
I don't know why request_irq is succeeding when the fsldma and dmaengine drivers are installed. I'm using the same dts in both cases. Ron --- Kumar Gala [EMAIL PROTECTED] wrote: That's a bit odd. How is your driver getting the IRQ its requesting? Are you using the same .dts in both cases? - k On Jun 13, 2008, at 2:02 PM, Ron Madrid wrote: So after I've built the kernel to include the dmaengine and fsldma drivers, my driver is allowed to register its ISR via request_irq. However, if these drivers are not installed then request_irq fails in my driver. So it seems that there is some other initialization happening before request_irq is being called in fsldma and subsequently my driver. Does anyone know what this is? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: The dmaengine provides a generic set of APIs w/a FSL dma backend. It might be the case that your need of dma doesnt fit into the current set of APIs. - k On Jun 12, 2008, at 3:04 PM, Ron Madrid wrote: Well in that case wouldn't I need to use the fsldma driver? Or is dmaengine a generic dma driver? Ron --- Kumar Gala [EMAIL PROTECTED] wrote: On Jun 12, 2008, at 2:35 PM, Ron Madrid wrote: I'm trying to write a driver that would make use of the DMA on the MPC8313. I'm attempting to register the interrupt with request_irq but it is not passing. Is there something that I need to do before I call request_irq, maybe in the dts or somewhere else? any reason you aren't using the dmaengine driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
Ron Madrid wrote: I don't know why request_irq is succeeding when the fsldma and dmaengine drivers are installed. I'm using the same dts in both cases. At this point, my only suggestion is to debug the request_irq() call and see what exactly fails. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Using DMA interrupt on MPC8313
So are you implying that the request_irq function should work without any other initialization function before it? Ron --- Timur Tabi [EMAIL PROTECTED] wrote: Ron Madrid wrote: I don't know why request_irq is succeeding when the fsldma and dmaengine drivers are installed. I'm using the same dts in both cases. At this point, my only suggestion is to debug the request_irq() call and see what exactly fails. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Question regarding mpic_assign_isu() in storcenter.c
Can anyone explain why the comment preceding mpic_assign_isu() on line 145 says
that the I2C registers are at 0x11020 yet the code on line 146 shows 0x11000?
The MPC8245 user manual shows the external interrupt 0 registers at 0x10200
(paddr=4) and the I2C registers at 0x11020.
from storcenter.c 2.6.25.6
/*
112 * Interrupt setup and service. Interrrupts on the turbostation come
113 * from the four PCI slots plus onboard 8241 devices: I2C, DUART.
114 */
115static void __init storcenter_init_IRQ(void)
116{
117struct mpic *mpic;
118struct device_node *dnp;
119const void *prop;
120int size;
121phys_addr_t paddr;
122
123dnp = of_find_node_by_type(NULL, open-pic);
124if (dnp == NULL)
125return;
126
127prop = of_get_property(dnp, reg, size);
128if (prop == NULL) {
129of_node_put(dnp);
130return;
131}
132
133paddr = (phys_addr_t)of_translate_address(dnp, prop);
134mpic = mpic_alloc(dnp, paddr, MPIC_PRIMARY | MPIC_WANTS_RESET,
13516, 32, OpenPIC );
136
137of_node_put(dnp);
138
139BUG_ON(mpic == NULL);
140
141/*
142 * 16 Serial Interrupts followed by 16 Internal Interrupts.
143 * I2C is the second internal, so it is at 17, 0x11020.
144 */
145mpic_assign_isu(mpic, 0, paddr + 0x10200);
146mpic_assign_isu(mpic, 1, paddr + 0x11000);
147
148mpic_init(mpic);
149}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
