Re: [PATCH] pseries: phyp dump: Variable size reserve space.
Manish Ahuja writes: > B. It computers 5% of total ram and rounds it down to multiples of 256MB. > C. Compares the rounded down value and returns larger of 256MB or the new >computed value. So if we have 10GB of memory or more we'll use reserve more than 256MB. What is the advantage of reserving more than 256MB of memory? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Buildroot] zImage.embedded
> [cross posting from one mailing list to another] > >>> is the file zImage.elf my proper network image ? >> >> What bootloader is on your board? zImage.elf *might* be the proper >> image. If you're using u-boot, then you want to build a uImage >> instead. > > I'm trying to compile u-boot with buildroot, but it fails with: > >/usr/bin/make -j1 -C > /home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2 > > \ >""_config > make[1]: Entering directory > `/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2' > make[1]: *** No rule to make target `_config'. Stop. > make[1]: Leaving directory > `/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2' > make: *** > [/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2/.configured] > > Error 2 > > Apparently it expects a BOARD_NAME variable, but I don't know what to put in > it (I looked at the makefile and can't find the ml405 referenced in there). > -- > Guillaume Dargaud > http://www.gdargaud.net/ > I think you need to figure out how to build u-boot for your board outside buildroot, before you try to build it inside buildroot. Best Regards Ulf Samuelsson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Make Book-E debug handling SMP safe
Kumar Gala writes: > global_dbcr0 needs to be a per cpu set of save areas instead of a single > global on all processors. Looks reasonable. At some point you might want to use a per-cpu variable instead of an array in order to reduce cacheline bouncing. > Also, we switch to using DBCR0_IDM to determine if the user space app is > being debugged as its a more consistent way. In the future we should > support features like hardware breakpoint and watchpoints which will > have DBCR0_IDM set but not necessarily DBCR0_IC (single step). That should be OK. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] IB/ehca: extend query_device() and query_port() to support all values for ibv_devinfo
thanks, applied ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] scc_pata.c: do setup itself instead of ide_setup_pci_device ()
scc_pata has the different BAR configuration and using ide_setup_pci_device()
is inappropriate.
(ide_setup_pci_device() expects a normal PCI IDE controller with
BAR0..BAR3 either non-existant or being primary/secondary port bases
in I/O space.)
This patch do all needed setup itself instead of calling ide_setup_pci_device().
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
--- linux-2.6.25-rc1/drivers/ide/pci/scc_pata.c 2008-02-11 07:18:14.0
+0900
+++ linux-2.6.25-rc1_mod/drivers/ide/pci/scc_pata.c 2008-04-15
11:45:25.0 +0900
@@ -523,6 +523,42 @@ static int setup_mmio_scc (struct pci_de
return -ENOMEM;
}
+static int scc_ide_setup_pci_device(struct pci_dev *dev, const struct
ide_port_info *d)
+{
+ struct scc_ports *ports = pci_get_drvdata(dev);
+ ide_hwif_t *hwif = NULL;
+ hw_regs_t hw;
+ u8 idx[4] = { 0xff, 0xff, 0xff, 0xff };
+ int i;
+
+ for (i = 0; i < MAX_HWIFS; i++) {
+ hwif = &ide_hwifs[i];
+ if (hwif->chipset == ide_unknown)
+ break; /* pick an unused entry */
+ }
+ if (i == MAX_HWIFS) {
+ printk(KERN_ERR "%s: too many IDE interfaces, no room in
table\n",
+ SCC_PATA_NAME);
+ return -ENOMEM;
+ }
+
+ memset(&hw, 0, sizeof(hw));
+ for (i = IDE_DATA_OFFSET; i <= IDE_CONTROL_OFFSET; i++)
+ hw.io_ports[i] = ports->dma + 0x20 + i * 4;
+ hw.irq = dev->irq;
+ hw.dev = &dev->dev;
+ hw.chipset = ide_pci;
+ ide_init_port_hw(hwif, &hw);
+ hwif->dev = &dev->dev;
+ hwif->cds = d;
+
+ idx[0] = hwif->index;
+
+ ide_device_add(idx, d);
+
+ return 0;
+}
+
/**
* init_setup_scc - set up an SCC PATA Controller
* @dev: PCI device
@@ -545,10 +581,13 @@ static int __devinit init_setup_scc(stru
struct scc_ports *ports;
int rc;
+ rc = pci_enable_device(dev);
+ if (rc)
+ goto end;
+
rc = setup_mmio_scc(dev, d->name);
- if (rc < 0) {
- return rc;
- }
+ if (rc < 0)
+ goto end;
ports = pci_get_drvdata(dev);
ctl_base = ports->ctl;
@@ -583,7 +622,10 @@ static int __devinit init_setup_scc(stru
out_be32((void*)mode_port, MODE_JCUSFEN);
out_be32((void*)intmask_port, INTMASK_MSK);
- return ide_setup_pci_device(dev, d);
+ rc = scc_ide_setup_pci_device(dev, d);
+
+ end:
+ return rc;
}
/**
@@ -610,17 +652,6 @@ static void __devinit init_mmio_iops_scc
hwif->OUTSW = scc_ide_outsw;
hwif->OUTSL = scc_ide_outsl;
- hwif->io_ports[IDE_DATA_OFFSET] = dma_base + 0x20;
- hwif->io_ports[IDE_ERROR_OFFSET] = dma_base + 0x24;
- hwif->io_ports[IDE_NSECTOR_OFFSET] = dma_base + 0x28;
- hwif->io_ports[IDE_SECTOR_OFFSET] = dma_base + 0x2c;
- hwif->io_ports[IDE_LCYL_OFFSET] = dma_base + 0x30;
- hwif->io_ports[IDE_HCYL_OFFSET] = dma_base + 0x34;
- hwif->io_ports[IDE_SELECT_OFFSET] = dma_base + 0x38;
- hwif->io_ports[IDE_STATUS_OFFSET] = dma_base + 0x3c;
- hwif->io_ports[IDE_CONTROL_OFFSET] = dma_base + 0x40;
-
- hwif->irq = dev->irq;
hwif->dma_base = dma_base;
hwif->config_data = ports->ctl;
hwif->mmio = 1;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 86xx: mark functions static, other minor cleanups
On Fri, Apr 11, 2008 at 3:11 PM, Segher Boessenkool <[EMAIL PROTECTED]> wrote: > > > Updated as per above, and with tickerized prefixes for sbc8641. > > > > Care to try once more? It's only "tickerized" if it's in all > uppercase. I'm looking at what exists in arch/powerpc/boot/dts/* and I'm not seeing too much uppercase - here is a sample: ebony.dts:compatible = "ibm,ebony"; ep405.dts:compatible = "ibm,uic"; ep8248e.dts:compatible = "fsl,ep8248e"; bamboo.dts: compatible = "amcc,bamboo"; cm5200.dts: compatible = "schindler,cm5200"; ep88xc.dts: compatible = "fsl,ep88xc"; haleakala.dts: compatible = "amcc,kilauea"; holly.dts: compatible = "ibm,holly"; katmai.dts: compatible = "amcc,katmai"; kilauea.dts:compatible = "amcc,kilauea"; lite5200b.dts: compatible = "fsl,lite5200b"; motionpro.dts: compatible = "promess,motionpro"; mpc8272ads.dts: compatible = "fsl,mpc8272ads"; mpc866ads.dts: compatible = "fsl,mpc866ads"; > > + compatible = "wind,sbc8641"; To me this looks in keeping with the rest. And I prefer with the lower case, actually. (Apparently so do a lot of other people...) Paul. > > > > > Segher > > > > ___ > 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: Get new_emac driver running on 405EP
On Mon, 2008-04-14 at 19:38 +0200, M B wrote: > Hi, > I'm trying to get the new_emac driver (linux 2.6.25-rc8) running on my > 405EP board with a KSZ8721BT Micrel/Kendin PHY. > I've already found 2 problems/missing features: > 1) 100 retries in __emac_mdio_read for the read to complete are > slightly too less. 101 seem to be enough. But we could add a bit more, > because there is no negative effect for faster chips. > 2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both > phys have to be accessed through this one. This affectes the mdio > read/write functions. The later can easily be described in the device-tree as it's a fairly common setup. > I've already hacked around this problems, but ethernet is still not working. > After bringing up the device dmesg is flooded with this section. > emac/plb/opb/[EMAIL PROTECTED]: link timer > emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,01) > emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 786d > emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,01) > emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 786d > > > Any ideas where I should start looking? The above is the timer polling the link, you may want to remove that debug once it looks sane. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Manual kernel parameters are being ignored
On Mon, 14 Apr 2008 18:17:16 +0200 "Guillaume Dargaud" <[EMAIL PROTECTED]> wrote: > Anyone care to tell me why the parameters I type manually for the kernel are > being ignored ? Care to tell us which kernel you are using and what your .config for it looks like? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 7/8] [POWERPC] qe_lib: add support for QE USB
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote:
I believe QE USB clocks routing is qe_lib authority, so usb.c
created. Also, now cmxgcr needs its own lock.
why? (I'm asking to be more descriptive in the commit message)
This patch also fixes QE_USB_RESTART_TX command definition.
Patch look ok, but can you be a bit more descriptive about why we are
adding this.
- k
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/qe_lib/Kconfig |6
arch/powerpc/sysdev/qe_lib/Makefile |1 +
arch/powerpc/sysdev/qe_lib/ucc.c|7 ++--
arch/powerpc/sysdev/qe_lib/usb.c| 57 ++
+
include/asm-powerpc/qe.h| 18 ++-
5 files changed, 85 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/sysdev/qe_lib/usb.c
diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/
sysdev/qe_lib/Kconfig
index c1f2849..f09dae4 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -25,3 +25,9 @@ config QE_GTM
default y if FSL_GTM
help
QE General-purpose Timers Module support
+
+config QE_USB
+ bool
+ default y if USB_FHCI_HCD
+ help
+ QE USB Host Controller support
diff --git a/arch/powerpc/sysdev/qe_lib/Makefile b/arch/powerpc/
sysdev/qe_lib/Makefile
index 3297a52..c666a59 100644
--- a/arch/powerpc/sysdev/qe_lib/Makefile
+++ b/arch/powerpc/sysdev/qe_lib/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_UCC) += ucc.o
obj-$(CONFIG_UCC_SLOW) += ucc_slow.o
obj-$(CONFIG_UCC_FAST) += ucc_fast.o
obj-$(CONFIG_QE_GTM)+= gtm.o
+obj-$(CONFIG_QE_USB) += usb.o
diff --git a/arch/powerpc/sysdev/qe_lib/ucc.c b/arch/powerpc/sysdev/
qe_lib/ucc.c
index 0e348d9..d3c7f5a 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc.c
@@ -26,7 +26,8 @@
#include
#include
-static DEFINE_SPINLOCK(ucc_lock);
+DEFINE_SPINLOCK(cmxgcr_lock);
+EXPORT_SYMBOL(cmxgcr_lock);
int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
{
@@ -35,10 +36,10 @@ int ucc_set_qe_mux_mii_mng(unsigned int ucc_num)
if (ucc_num > UCC_MAX_NUM - 1)
return -EINVAL;
- spin_lock_irqsave(&ucc_lock, flags);
+ spin_lock_irqsave(&cmxgcr_lock, flags);
clrsetbits_be32(&qe_immr->qmx.cmxgcr, QE_CMXGCR_MII_ENET_MNG,
ucc_num << QE_CMXGCR_MII_ENET_MNG_SHIFT);
- spin_unlock_irqrestore(&ucc_lock, flags);
+ spin_unlock_irqrestore(&cmxgcr_lock, flags);
return 0;
}
diff --git a/arch/powerpc/sysdev/qe_lib/usb.c b/arch/powerpc/sysdev/
qe_lib/usb.c
new file mode 100644
index 000..60ce676
--- /dev/null
+++ b/arch/powerpc/sysdev/qe_lib/usb.c
@@ -0,0 +1,57 @@
+/*
+ * QE USB routines
+ *
+ * Copyright (c) Freescale Semicondutor, Inc. 2006.
+ * Shlomi Gridish <[EMAIL PROTECTED]>
+ * Jerry Huang <[EMAIL PROTECTED]>
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ * Anton Vorontsov <[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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+int qe_usb_clock_set(enum qe_clock clk, int rate)
+{
+ struct qe_mux __iomem *mux = &qe_immr->qmx;
+ unsigned long flags;
+ const bool is_brg = clk < QE_CLK1;
+ u32 val;
+
+ switch (clk) {
+ case QE_CLK3: val = QE_CMXGCR_USBCS_CLK3; break;
+ case QE_CLK5: val = QE_CMXGCR_USBCS_CLK5; break;
+ case QE_CLK7: val = QE_CMXGCR_USBCS_CLK7; break;
+ case QE_CLK9: val = QE_CMXGCR_USBCS_CLK9; break;
+ case QE_CLK13: val = QE_CMXGCR_USBCS_CLK13; break;
+ case QE_CLK17: val = QE_CMXGCR_USBCS_CLK17; break;
+ case QE_CLK19: val = QE_CMXGCR_USBCS_CLK19; break;
+ case QE_CLK21: val = QE_CMXGCR_USBCS_CLK21; break;
+ case QE_BRG9: val = QE_CMXGCR_USBCS_BRG9; break;
+ case QE_BRG10: val = QE_CMXGCR_USBCS_BRG10; break;
+ default:
+ pr_err("%s: requested unknown clock %d\n", __func__, clk);
+ return -EINVAL;
+ }
+
+ if (is_brg)
+ qe_setbrg(clk, rate, 1);
+
+ spin_lock_irqsave(&cmxgcr_lock, flags);
+
+ clrsetbits_be32(&mux->cmxgcr, QE_CMXGCR_USBCS, val);
+
+ spin_unlock_irqrestore(&cmxgcr_lock, flags);
+
+ return 0;
+}
+EXPORT_SYMBOL(qe_usb_clock_set);
diff --git a/include/asm-powerpc/qe.h b/include/asm-powerpc/qe.h
index c3be6e2..3276b06 100644
--- a/include/asm-powerpc/qe.h
+++ b/include/asm-powerpc/qe.h
@@ -16,6 +16,7 @@
#define _ASM_POWERPC_QE_H
#ifdef __KERNEL__
+#include
#include
#define QE_NUM_OF_SNUM 28
@@ -74,6 +75,8 @@ enum qe_clock {
QE_CLK_DUMMY
};
+extern spinlock_t cmxgcr_lock;
+
/* Export QE common operations */
extern void
Re: [PATCH] Make rheap safe for spinlocks
Kumar Gala wrote: > Is this need to fix a bug with an existing driver of for a new driver? Both. The ucc_geth driver calls qe_muram_alloc() with spinlocks held. The 8610 DIU driver does something similar, but it's targeted for 2.6.26. I'm hesitant to recommend inclusion in 2.6.25 because I haven't tested the fix throughly enough to know that it doesn't break something else. Technically, it could result in qe_muram_alloc() failing. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Make rheap safe for spinlocks
On Apr 14, 2008, at 10:43 AM, Timur Tabi wrote: The rheap allocation function, rh_alloc, could call kmalloc with GFP_KERNEL. This can sleep, which means you couldn't hold a spinlock while called rh_alloc. Change all kmalloc calls to use GFP_ATOMIC so that it won't sleep. This is safe because only small blocks are allocated. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- This patch is for 2.6.26. Is this need to fix a bug with an existing driver of for a new driver? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On Mon, 14 Apr 2008 10:46:29 -0500 Timur Tabi <[EMAIL PROTECTED]> wrote: > Jiri Slaby wrote: > > > Mainly because you can sleep inside locked mutex and because spinlock > > shouldn't > > be used for too many lines of code (busy waiting etc.). I think ldd3 will be > > more descriptive than me here :). > > Ok, I'll look into it. > > Andrew, do you want us to respin the patch, or would you be willing to let us > make the change in a follow-up patch? A fix against rc8-mm3 would be ideal for me. But a replacement patch is OK too - I'd convert that into an incremental so I can see what changed anyway. Others might find the replacement patch harder to review though... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH rebased][POWERPC] qe_lib and ucc_geth: switch to the cpm_muram implementation
This is very trivial patch. We're transitioning to the cpm_muram_*
calls. That's it.
Less trivial changes:
- BD_SC_* defines were defined in the cpm.h and qe.h, so to avoid redefines
we remove BD_SC from the qe.h and use cpm.h along with cpm_muram_*
prototypes;
- qe_muram_dump was unused and thus removed;
- added some code to the cpm_common.c to support legacy QE bindings
(data-only node name).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Rebased on top of today's galak/powerpc.git.
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/cpm_common.c | 16 +-
arch/powerpc/sysdev/qe_lib/qe.c | 96 +
arch/powerpc/sysdev/qe_lib/ucc_fast.c |8 ++--
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 18 +++---
drivers/net/ucc_geth.c| 96
include/asm-powerpc/cpm.h |1 +
include/asm-powerpc/qe.h | 29 +--
8 files changed, 79 insertions(+), 186 deletions(-)
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 6d386d0..42b44a1 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -40,6 +40,7 @@ endif
ifeq ($(ARCH),powerpc)
obj-$(CONFIG_CPM) += cpm_common.o
obj-$(CONFIG_CPM2) += cpm2.o cpm2_pic.o
+obj-$(CONFIG_QUICC_ENGINE) += cpm_common.o
obj-$(CONFIG_PPC_DCR) += dcr.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o cpm1.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
diff --git a/arch/powerpc/sysdev/cpm_common.c b/arch/powerpc/sysdev/cpm_common.c
index cb7df2d..57d78fa 100644
--- a/arch/powerpc/sysdev/cpm_common.c
+++ b/arch/powerpc/sysdev/cpm_common.c
@@ -85,9 +85,13 @@ int __init cpm_muram_init(void)
np = of_find_compatible_node(NULL, NULL, "fsl,cpm-muram-data");
if (!np) {
- printk(KERN_ERR "Cannot find CPM muram data node");
- ret = -ENODEV;
- goto out;
+ /* try legacy bindings */
+ np = of_find_node_by_name(NULL, "data-only");
+ if (!np) {
+ printk(KERN_ERR "Cannot find CPM muram data node");
+ ret = -ENODEV;
+ goto out;
+ }
}
muram_pbase = of_translate_address(np, zero);
@@ -189,6 +193,12 @@ void __iomem *cpm_muram_addr(unsigned long offset)
}
EXPORT_SYMBOL(cpm_muram_addr);
+unsigned long cpm_muram_offset(void __iomem *addr)
+{
+ return addr - muram_vbase;
+}
+EXPORT_SYMBOL(cpm_muram_offset);
+
/**
* cpm_muram_dma - turn a muram virtual address into a DMA address
* @offset: virtual address from cpm_muram_addr() to convert
diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c
index cff550e..4b48094 100644
--- a/arch/powerpc/sysdev/qe_lib/qe.c
+++ b/arch/powerpc/sysdev/qe_lib/qe.c
@@ -35,7 +35,6 @@
#include
static void qe_snums_init(void);
-static void qe_muram_init(void);
static int qe_sdma_init(void);
static DEFINE_SPINLOCK(qe_lock);
@@ -99,7 +98,7 @@ void qe_reset(void)
QE_CR_PROTOCOL_UNSPECIFIED, 0);
/* Reclaim the MURAM memory for our use. */
- qe_muram_init();
+ cpm_muram_init();
if (qe_sdma_init())
panic("sdma init failed!");
@@ -314,7 +313,7 @@ static int qe_sdma_init(void)
/* allocate 2 internal temporary buffers (512 bytes size each) for
* the SDMA */
- sdma_buf_offset = qe_muram_alloc(512 * 2, 4096);
+ sdma_buf_offset = cpm_muram_alloc(512 * 2, 4096);
if (IS_ERR_VALUE(sdma_buf_offset))
return -ENOMEM;
@@ -325,97 +324,6 @@ static int qe_sdma_init(void)
return 0;
}
-/*
- * muram_alloc / muram_free bits.
- */
-static DEFINE_SPINLOCK(qe_muram_lock);
-
-/* 16 blocks should be enough to satisfy all requests
- * until the memory subsystem goes up... */
-static rh_block_t qe_boot_muram_rh_block[16];
-static rh_info_t qe_muram_info;
-
-static void qe_muram_init(void)
-{
- struct device_node *np;
- const u32 *address;
- u64 size;
- unsigned int flags;
-
- /* initialize the info header */
- rh_init(&qe_muram_info, 1,
- sizeof(qe_boot_muram_rh_block) /
- sizeof(qe_boot_muram_rh_block[0]), qe_boot_muram_rh_block);
-
- /* Attach the usable muram area */
- /* XXX: This is a subset of the available muram. It
-* varies with the processor and the microcode patches activated.
-*/
- np = of_find_compatible_node(NULL, NULL, "fsl,qe-muram-data");
- if (!np) {
- np = of_find_node_by_name(NULL, "data-only");
- if (!np) {
- WARN_ON(1);
- return;
- }
- }
-
- address = of_get_address(np, 0, &size, &flags);
- WARN_ON(!address);
-
- of_node_put(np);
- if (address)
-
Re: [PATCH 0/8] A bit of new code and sparse cleanups along the way
On Mon, Apr 14, 2008 at 10:14:05AM -0500, Kumar Gala wrote: > > On Mar 11, 2008, at 12:21 PM, Anton Vorontsov wrote: >> Hi all, >> >> Please consider these patches for the 2.6.26. > > I've applied most of these patches to my powerpc-next branch. Thanks! > The > following two patches have NOT been applied: > > [POWERPC] sysdev,qe_lib: implement FSL GTM support > [POWERPC] qe_lib: add support for QE USB > > It seemed there was rework required to the sysdev,qe_lib patch. I can't recall any issues with "[POWERPC] qe_lib: add support for QE USB". As for FSL GTM.. yes, I'll send updated version soon. -- 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
Get new_emac driver running on 405EP
Hi, I'm trying to get the new_emac driver (linux 2.6.25-rc8) running on my 405EP board with a KSZ8721BT Micrel/Kendin PHY. I've already found 2 problems/missing features: 1) 100 retries in __emac_mdio_read for the read to complete are slightly too less. 101 seem to be enough. But we could add a bit more, because there is no negative effect for faster chips. 2) On the 405EP only the MDIO pin of the emac0 is pinned out, so both phys have to be accessed through this one. This affectes the mdio read/write functions. I've already hacked around this problems, but ethernet is still not working. After bringing up the device dmesg is flooded with this section. emac/plb/opb/[EMAIL PROTECTED]: link timer emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,01) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 786d emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,01) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 786d Any ideas where I should start looking? Best Regards Markus A ping doesn't work == # ifconfig eth0 1.1.1.1 eth0: link is up, 100 FDX, pause enabled # ping 1.1.1.1 -c1 PING 1.1.1.1 (1.1.1.1): 56 data bytes --- 1.1.1.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss No data gets transmitted == # ifconfig eth0 Link encap:Ethernet HWaddr 00:50:C2:1E:AF:FE inet addr:1.1.1.1 Bcast:1.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:23 And no interrupts triggered === # cat /proc/interrupts CPU0 16:737 UIC Level serial 18: 0 UIC Level MAL TX EOB 19: 0 UIC Level MAL RX EOB 20: 0 UIC Level MAL SERR 21: 0 UIC Level MAL TX DE 22: 0 UIC Level MAL RX DE BAD: 0 dmesg section after boot, debug level of emac driver is 3 = ef600400.serial: ttyS1 at MMIO 0xef600400 (irq = 17) is a 16550A PPC 4xx OCP EMAC driver, version 3.54 mal/plb/mcmal: probe mal/plb/mcmal: reset mal/plb/mcmal: enable_irq MAL v1 /plb/mcmal, 4 TX channels, 4 RX channels emac/plb/opb/[EMAIL PROTECTED]: features : 0x / 0x emac/plb/opb/[EMAIL PROTECTED]: tx_fifo_size : 2048 (2048 gige) emac/plb/opb/[EMAIL PROTECTED]: rx_fifo_size : 4096 (4096 gige) emac/plb/opb/[EMAIL PROTECTED]: max_mtu : 1500 emac/plb/opb/[EMAIL PROTECTED]: OPB freq : 6600 mal/plb/mcmal: reg(8000, 8000) emac/plb/opb/[EMAIL PROTECTED]: tx_desc ff10 emac/plb/opb/[EMAIL PROTECTED]: rx_desc ff100800 emac/plb/opb/[EMAIL PROTECTED]: PHY maps emac/plb/opb/[EMAIL PROTECTED]: configure emac/plb/opb/[EMAIL PROTECTED]: reset emac/plb/opb/[EMAIL PROTECTED]: rx_disable emac/plb/opb/[EMAIL PROTECTED]: tx_disable emac/plb/opb/[EMAIL PROTECTED]: link = 1 duplex = 1, pause = 0, asym_pause = 0 emac/plb/opb/[EMAIL PROTECTED]: __emac_calc_base_mr1 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,00) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 3100 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,00) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 3100 emac/plb/opb/[EMAIL PROTECTED]: mdio_write(00,00,a100) emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,00) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 3100 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,02) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 0022 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,03) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 1619 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,01) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 7849 emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,00) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 3100 emac/plb/opb/[EMAIL PROTECTED]: mdio_write(00,00,) emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,04) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> 01e1 emac/plb/opb/[EMAIL PROTECTED]: mdio_write(00,04,0de1) emac/plb/opb/[EMAIL PROTECTED]: mdio_read(00,00) emac/plb/opb/[EMAIL PROTECTED]: mdio_read -> emac/plb/opb/[EMAIL PROTECTED]: mdio_write(00,00,1200) emac/plb/opb/[EMAIL PROTECTED]: stats eth0: EMAC-0 /plb/opb/[EMAIL PROTECTED], MAC 00:50:c2:1e:af:fe eth0: found Generic MII PHY (0x00) emac/plb/opb/[EMAIL PROTECTED]: features : 0x / 0x emac/plb/opb/[EMAIL PROTECTED]: tx_fifo_size : 2048 (2048 gige) emac/plb/opb/[EMAIL PROTECTED]: rx_fifo_size : 4096 (4096 gige) emac/plb/opb/[EMAIL PROTECTED]: max_mtu : 1500 emac/plb/opb/[EMAIL PROTECTED]: OPB freq : 6600 mal/plb/mcmal: reg(2000, 4000) emac/plb/opb/[EMAIL PROTECTED]: tx_desc ff100400 emac/plb/opb/[EMAIL PROTECTED]: rx_desc ff100c00 emac/plb/opb/[EMAIL PROTECTED]: PHY maps 0020 0001 emac/plb/opb/[EMAIL PROTECTED]: configure emac/plb/opb/[EMAIL PROT
Re: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically
On Apr 11, 2008, at 10:49, Paul Gortmaker wrote: In message: [PATCH v2.6.26] gianfar: Determine TBIPA value dynamically on 10/04/2008 Andy Fleming wrote: TBIPA needs to be set to a value (on connected MDIO buses) that doesn't conflict with PHYs on the bus. By hardcoding it to 0x1f, we were preventing boards with PHYs at 0x1f from working properly. Instead, scan the bus when it comes up, and find an address that doesn't have a PHY on it. The TBI PHY configuration code then trusts that the value in TBIPA is either safe, or doesn't matter (ie - it's not an active bus with other PHYs). Signed-off-by: Andy Fleming <[EMAIL PROTECTED]> --- I think this should go in, but I'd like to see some testing first. I don't have hardware which is affected by this. I've only confirmed that it doesn't break current hardware. I've tested on a board with the primary PHY at 0x1f, and it seems OK. I'f I'm understanding this correctly, you are explicitly setting TBIPA to zero, doing a bus walk but excluding zero, and then assigning the found free address, which re-opens zero to be used by a real PHY. Right. It's a somewhat lazy scan of the bus. I'm assuming, here, that there will be at least one non-zero address that has no PHY on it. I've made some changes to what you'd sent out, those being: -changed the "if (i < 0) return -EBUSY to "i == 0" -remove the now unused TBIPA_VALUE define -remove the prototypes from gianfar.c now that you've added them into gianfar.h -factor out the code to read the PHY ID so we don't have it duplicated in two places. Excellent. Print it! :) Could you send out the two patches as two separate emails, and add my Acked-by: Andy Fleming <[EMAIL PROTECTED]> to the first one? You should also change the subject for the first patch so that it has [PATCH v2.6.26]. Andy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Flash on LocalBus @ MPC8343
On Sat, Apr 12, 2008 at 10:58:50AM +0200, André Schwarz wrote: > thanks , but ... can't find "of_bus_ids[]" entry. That means your platform likely isn't calling of_platform_bus_probe() at all. Look at other platforms, such as mpc831x_rdb, for an example. > I'm obviously out of sync. My last git-pull from denx is 3 days old, now > - need to update on monday. For Denx-specific support, please contact Denx. This certainly isn't something that was added in the past 3 days. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc8315: fix USB UTMI Host setup
On Mon, Apr 14, 2008 at 10:22:46AM -0500, Kumar Gala wrote: > > On Apr 9, 2008, at 8:59 AM, Anton Vorontsov wrote: >> Currently USB Host isn't functional on the MPC8315E boards, for two >> reasons as described below. >> >> MPC8315 Reference Manual says: >> "The USB DR unit must have the same clock ratio as the encryption core >> unit, unless one of them has its clock disabled." >> >> The encryption core also drives I2C clock, so it is enabled and is >> equal >> to 01. That means USBDRCM should be 01 here. >> >> Plus, according to MPC8315E-RDB schematics, USB unit consumes CLK_IN >> clock from the 24.00MHz oscillator, which means we must adjust REFSEL >> bits as well. > > Can you add a comment in the code about the fact that part of this fix > is board specific. Heh, the whole 83xx/usb.c file is board(s) specific, not this particular fix. :-/ So it doesn't need an explicit comment for this addition. It's just lucky coincedence that all previous boards were using same (or similar) setup. That is, it's perfectly possible that some custom MPC831XE board will use USB setup different from MPC8313E-RDB or MPC8315E-RDB, and the whole thing will break again. The same applies for MPC837X part of usb.c. There are board-specific settings all over the place. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Signal backtrace function
On Mon, 2008-04-14 at 18:09 +0200, Detlev Zundel wrote: > Hi Jocke, > > > I made my own backtrace function for printing > > a trace from within a signal handler. Maybe it > > can be useful for the kernel too? General > > comments welcome. > > Probably a dumb question, but doesn't backtrace(3) from glibc work > architecture independent already? Why do you need to reimplement it? Nope, it doesn't give you a good backtrace from within a signal handler. On x86 you can use the normal backtrace function with a minor workaround, but as ppc doesn't save a FP in leaf functions, that workaround does not work well. You can read more about it at http://www.linuxjournal.com/article/6391 Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Manual kernel parameters are being ignored
Anyone care to tell me why the parameters I type manually for the kernel are being ignored ? Linux/PPC load: console=ttyUL0,9600 root=/dev/xsa2 rw ip=off Uncompressing Linux...done. Now booting the kernel [...] [0.00] Kernel command line: console=ttyUL0,9600 root=/dev/nfs rw ip=on nfsroot=192.168.1.185:/ht -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Signal backtrace function
Hi Jocke, > I made my own backtrace function for printing > a trace from within a signal handler. Maybe it > can be useful for the kernel too? General > comments welcome. Probably a dumb question, but doesn't backtrace(3) from glibc work architecture independent already? Why do you need to reimplement it? Thanks Detlev -- The management question ... is not _whether_ to build a pilot system and throw it away. You _will_ do that. The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. - Fred Brooks, "The Mythical Man Month" -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: zImage.embedded
[cross posting from one mailing list to another] is the file zImage.elf my proper network image ? What bootloader is on your board? zImage.elf *might* be the proper image. If you're using u-boot, then you want to build a uImage instead. I'm trying to compile u-boot with buildroot, but it fails with: /usr/bin/make -j1 -C /home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2 \ ""_config make[1]: Entering directory `/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2' make[1]: *** No rule to make target `_config'. Stop. make[1]: Leaving directory `/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2' make: *** [/home/guinevere/Min_UartLite_NetLite_Ace/buildroot/project_build_powerpc/genepy/u-boot-1.3.2/.configured] Error 2 Apparently it expects a BOARD_NAME variable, but I don't know what to put in it (I looked at the makefile and can't find the ml405 referenced in there). -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PATCH 2/5] Platform code
On Sat, 2008-04-12 at 14:03 -0400, Sean MacLennan wrote: > > - * Sean MacLennan <[EMAIL PROTECTED]> > + * Sean MacLennan Please don't do this. Anywhere. Ever. The spambots are quite capable of undoing it, and have been for years. The only people you inconvenience are real people trying to contact you. -- dwmw2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Jiri Slaby wrote: > Mainly because you can sleep inside locked mutex and because spinlock > shouldn't > be used for too many lines of code (busy waiting etc.). I think ldd3 will be > more descriptive than me here :). Ok, I'll look into it. Andrew, do you want us to respin the patch, or would you be willing to let us make the change in a follow-up patch? -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Make rheap safe for spinlocks
The rheap allocation function, rh_alloc, could call kmalloc with GFP_KERNEL. This can sleep, which means you couldn't hold a spinlock while called rh_alloc. Change all kmalloc calls to use GFP_ATOMIC so that it won't sleep. This is safe because only small blocks are allocated. Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> --- This patch is for 2.6.26. arch/powerpc/lib/rheap.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/lib/rheap.c b/arch/powerpc/lib/rheap.c index 22c3b4f..29b2941 100644 --- a/arch/powerpc/lib/rheap.c +++ b/arch/powerpc/lib/rheap.c @@ -54,7 +54,7 @@ static int grow(rh_info_t * info, int max_blocks) new_blocks = max_blocks - info->max_blocks; - block = kmalloc(sizeof(rh_block_t) * max_blocks, GFP_KERNEL); + block = kmalloc(sizeof(rh_block_t) * max_blocks, GFP_ATOMIC); if (block == NULL) return -ENOMEM; @@ -258,7 +258,7 @@ rh_info_t *rh_create(unsigned int alignment) if ((alignment & (alignment - 1)) != 0) return ERR_PTR(-EINVAL); - info = kmalloc(sizeof(*info), GFP_KERNEL); + info = kmalloc(sizeof(*info), GFP_ATOMIC); if (info == NULL) return ERR_PTR(-ENOMEM); -- 1.5.3 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On 04/14/2008 04:49 PM, Timur Tabi wrote: Jiri Slaby wrote: On 04/14/2008 04:12 PM, Timur Tabi wrote: Unfortunately, the author of the patch, York, is out this week, so I'll have to take care of this. It'd be easier to modify rh_alloc() so that it doesn't sleep, so that's what I'm going to do. Anyway, why do you need the spin lock there (and not mutex)? I don't know. A spinlock just seemed obvious. Why would I prefer a mutex? Mainly because you can sleep inside locked mutex and because spinlock shouldn't be used for too many lines of code (busy waiting etc.). I think ldd3 will be more descriptive than me here :). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/5] WDT driver
On Mon, 14 Apr 2008 10:33:27 +0200 Laurent Pinchart <[EMAIL PROTECTED]> wrote: > What about > > setbits32((u32 __iomem *)(pikawdt_fpga + 0x14), 0xf80); Nice! I didn't know about that call. Thanks. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] CPM: Always use new binding.
On Apr 10, 2008, at 3:45 PM, Scott Wood wrote: The kconfig entry can go away once arch/ppc and references to the config in drivers are removed. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> --- arch/powerpc/platforms/82xx/Kconfig |3 - arch/powerpc/platforms/85xx/Kconfig |8 - arch/powerpc/platforms/8xx/Kconfig |4 - arch/powerpc/platforms/Kconfig |8 +- arch/powerpc/sysdev/cpm1.c | 112 --- arch/powerpc/sysdev/cpm2.c | 97 --- arch/powerpc/sysdev/cpm_common.c|3 - arch/powerpc/sysdev/fsl_soc.c | 541 --- 8 files changed, 1 insertions(+), 775 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc8315: fix USB UTMI Host setup
On Apr 9, 2008, at 8:59 AM, Anton Vorontsov wrote:
Currently USB Host isn't functional on the MPC8315E boards, for two
reasons as described below.
MPC8315 Reference Manual says:
"The USB DR unit must have the same clock ratio as the encryption core
unit, unless one of them has its clock disabled."
The encryption core also drives I2C clock, so it is enabled and is
equal
to 01. That means USBDRCM should be 01 here.
Plus, according to MPC8315E-RDB schematics, USB unit consumes CLK_IN
clock from the 24.00MHz oscillator, which means we must adjust REFSEL
bits as well.
Can you add a comment in the code about the fact that part of this fix
is board specific.
- k
p.s.
Idially we should rework whole 83xx/usb.c code, in two steps:
1. Move SCCR code to the U-Boot;
2. Implement fsl,usb-clock property in the device tree, so usb.c could
decide what clock exactly to use on per-board basis.
Though, today we're not in a hurry since there is just one 8315e board
out there.
Cc: Kumar Gala <[EMAIL PROTECTED]>
Cc: Kim Phillips <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/83xx/mpc83xx.h |2 ++
arch/powerpc/platforms/83xx/usb.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/mpc83xx.h b/arch/powerpc/
platforms/83xx/mpc83xx.h
index 68065e6..88a3b5c 100644
--- a/arch/powerpc/platforms/83xx/mpc83xx.h
+++ b/arch/powerpc/platforms/83xx/mpc83xx.h
@@ -16,6 +16,7 @@
#define MPC83XX_SCCR_USB_DRCM_10 0x0020
#define MPC8315_SCCR_USB_MASK 0x00c0
#define MPC8315_SCCR_USB_DRCM_11 0x00c0
+#define MPC8315_SCCR_USB_DRCM_01 0x0040
#define MPC837X_SCCR_USB_DRCM_11 0x00c0
/* system i/o configuration register low */
@@ -37,6 +38,7 @@
/* USB Control Register */
#define FSL_USB2_CONTROL_OFFS 0x500
#define CONTROL_UTMI_PHY_EN0x0200
+#define CONTROL_REFSEL_24MHZ 0x0040
#define CONTROL_REFSEL_48MHZ 0x0080
#define CONTROL_PHY_CLK_SEL_ULPI 0x0400
#define CONTROL_OTG_PORT 0x0020
diff --git a/arch/powerpc/platforms/83xx/usb.c b/arch/powerpc/
platforms/83xx/usb.c
index 471fdd8..64bcf0a 100644
--- a/arch/powerpc/platforms/83xx/usb.c
+++ b/arch/powerpc/platforms/83xx/usb.c
@@ -129,7 +129,7 @@ int mpc831x_usb_cfg(void)
if (immr_node && of_device_is_compatible(immr_node, "fsl,mpc8315-
immr"))
clrsetbits_be32(immap + MPC83XX_SCCR_OFFS,
MPC8315_SCCR_USB_MASK,
- MPC8315_SCCR_USB_DRCM_11);
+ MPC8315_SCCR_USB_DRCM_01);
else
clrsetbits_be32(immap + MPC83XX_SCCR_OFFS,
MPC83XX_SCCR_USB_MASK,
@@ -164,9 +164,15 @@ int mpc831x_usb_cfg(void)
/* Using on-chip PHY */
if (prop && (!strcmp(prop, "utmi_wide") ||
!strcmp(prop, "utmi"))) {
- /* Set UTMI_PHY_EN, REFSEL to 48MHZ */
+ u32 refsel;
+
+ if (of_device_is_compatible(immr_node, "fsl,mpc8315-immr"))
+ refsel = CONTROL_REFSEL_24MHZ;
+ else
+ refsel = CONTROL_REFSEL_48MHZ;
+ /* Set UTMI_PHY_EN and REFSEL */
out_be32(usb_regs + FSL_USB2_CONTROL_OFFS,
- CONTROL_UTMI_PHY_EN | CONTROL_REFSEL_48MHZ);
+ CONTROL_UTMI_PHY_EN | refsel);
/* Using external UPLI PHY */
} else if (prop && !strcmp(prop, "ulpi")) {
/* Set PHY_CLK_SEL to ULPI */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mpc8540 : Fix restart
What do you propose then ? The ability to reboot without power-off is really needed for embedded targets. And abort() from head_fsl.S seems really close to reboot. Boards should provide system logic mechanism that should be used. The problem is abort() only resets the core. The rest of the SoC wlll not be properly reset. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/8] A bit of new code and sparse cleanups along the way
On Mar 11, 2008, at 12:21 PM, Anton Vorontsov wrote: Hi all, Please consider these patches for the 2.6.26. I've applied most of these patches to my powerpc-next branch. The following two patches have NOT been applied: [POWERPC] sysdev,qe_lib: implement FSL GTM support [POWERPC] qe_lib: add support for QE USB It seemed there was rework required to the sysdev,qe_lib patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 8/8] [POWERPC] qe_io: fix sparse warnings
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote: Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/qe_lib/qe_io.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/8] [POWERPC] qe_lib: export qe_get_brg_clk()
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote: qe_get_brg_clk() will be used by the fsl_gtm routines. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/qe_lib/qe.c |5 +++-- include/asm-powerpc/qe.h|1 + 2 files changed, 4 insertions(+), 2 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/8] [POWERPC] immap_qe.h should include asm/io.h
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote: Headers should include prototypes they use, otherwise build will break if we use it without explicitly including io.h: CC arch/powerpc/sysdev/qe_lib/gtm.o In file included from include/asm/qe.h:20, from arch/powerpc/sysdev/qe_lib/gtm.c:18: include/asm/immap_qe.h: In function ‘immrbar_virt_to_phys’: include/asm/immap_qe.h:480: error: implicit declaration of function â €˜virt_to_phys’ make[2]: *** [arch/powerpc/sysdev/qe_lib/gtm.o] Error 1 make[1]: *** [arch/powerpc/sysdev/qe_lib] Error 2 gtm.c needs qe.h (which includes immap_qe.h) to use qe_get_brg_clk(). Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- include/asm-powerpc/immap_qe.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/8] [POWERPC] qe_lib: implement qe_muram_offset
On Mar 11, 2008, at 12:24 PM, Anton Vorontsov wrote: qe_muram_offset is the reverse of the qe_muram_addr, will be used for the Freescale QE USB Host Controller driver. This patch also moves qe_muram_addr into the qe.h header, plus adds __iomem hints to use with sparse. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/qe_lib/qe.c |8 +--- include/asm-powerpc/immap_qe.h |2 +- include/asm-powerpc/qe.h| 11 ++- 3 files changed, 12 insertions(+), 9 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/8] [POWERPC] fsl_lbc: implement few routines to manage FSL UPMs
Subject: [POWERPC] fsl_lbc: implement few UPM routines Freescale UPM can be used to adjust localbus timings or to generate orbitrary, pre-programmed "patterns" on the external Localbus signals. This patch implements few routines so drivers could work with UPMs in safe and generic manner. So far there is just one user of these routines: Freescale UPM NAND driver. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- arch/powerpc/Kconfig |5 ++ arch/powerpc/sysdev/Makefile |1 + arch/powerpc/sysdev/fsl_lbc.c | 129 + include/asm-powerpc/fsl_lbc.h | 88 4 files changed, 223 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/sysdev/fsl_lbc.c applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/8] [POWERPC] fsl_elbc_nand: factor out localbus defines
On Mar 11, 2008, at 12:23 PM, Anton Vorontsov wrote: This is needed to support other localbus peripherals, such as NAND on FSL UPM. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Would be great if someone from the MTD community will ack this patch to go through powerpc trees. Thanks, drivers/mtd/nand/fsl_elbc_nand.c | 219 + +--- include/asm-powerpc/fsl_lbc.h| 223 + + 2 files changed, 235 insertions(+), 207 deletions(-) create mode 100644 include/asm-powerpc/fsl_lbc.h applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
On Fri, Apr 11, 2008 at 11:06 AM, Anton Vorontsov <[EMAIL PROTECTED]> wrote: > On Fri, Apr 11, 2008 at 11:48:37AM -0500, Timur Tabi wrote: > > Anton Vorontsov wrote: > > > On Fri, Apr 11, 2008 at 09:13:36AM -0500, Kumar Gala wrote: > > >> On Mar 11, 2008, at 12:10 PM, Anton Vorontsov wrote: > > >>> - get rid of `model = "UCC"' in the ucc nodes > > >>> It isn't used anywhere, so remove it. If we'll ever need something > > >>> like this, we'll use compatible property instead. > > >>> - replace cell-index and device-id properties by fsl,ucc. > > >>> > > >>> Drivers are modified for backward compatibility's sake. > > >> I'd prefer we use cell-index and not introduce "fsl,ucc". I'm ok with > > >> dropping device-id and model (its implied in the compatiable). > > > > > > Ok. Here it is. netdev and linux-serial Cc'ed. > > > > Do we want the first UCC to have a cell-index of 1? Maybe we should fix > this > > off-by-one error once and for all, and number all UCCs from 0? > > Isn't documentation numbers UCC from 1? Then I believe we should stick > with it for device tree, since off by one is Linux implementation details. Plus making such a change will break deployed device trees. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
From: Anton Vorontsov <[EMAIL PROTECTED]> Subject: [POWERPC] UCC nodes cleanup - get rid of `model = "UCC"' in the ucc nodes It isn't used anywhere, so remove it. If we'll ever need something like this, we'll use compatible property instead. - replace last occurrences of device-id with cell-index. Drivers are modified for backward compatibility's sake. Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]> --- Documentation/powerpc/booting-without-of.txt |6 ++ arch/powerpc/boot/dts/mpc832x_mds.dts|7 +-- arch/powerpc/boot/dts/mpc832x_rdb.dts|4 arch/powerpc/boot/dts/mpc836x_mds.dts|4 arch/powerpc/boot/dts/mpc8568mds.dts |4 drivers/net/ucc_geth.c |8 +++- drivers/net/ucc_geth_mii.c | 11 --- drivers/serial/ucc_uart.c| 16 8 files changed, 30 insertions(+), 30 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
On Apr 14, 2008, at 9:56 AM, Timur Tabi wrote: Kumar Gala wrote: I say leave as you have it (UCC1 == cell-index = <1>). Changing it so cell-index = <0> is just more confusing w/regards to the docs. I don't see anything in booting-without-of.txt that requires cell- index to start at 0, however, the only other device that starts at 1 is SATA. Even the SSI starts at 0: - cell-index: the SSI, <0> = SSI1, <1> = SSI2, and so on Although I don't want to make more work for Anton, my vote is to have cell-index start at 0. That is the convention. It's too late to fix SATA, but at least we can avoid making it worse. I use cell-index starting at 1 for PCI to match our docs. I'll take Anton's last patch. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
Kumar Gala wrote: > I say leave as you have it (UCC1 == cell-index = <1>). > > Changing it so cell-index = <0> is just more confusing w/regards to > the docs. I don't see anything in booting-without-of.txt that requires cell-index to start at 0, however, the only other device that starts at 1 is SATA. Even the SSI starts at 0: - cell-index : the SSI, <0> = SSI1, <1> = SSI2, and so on Although I don't want to make more work for Anton, my vote is to have cell-index start at 0. That is the convention. It's too late to fix SATA, but at least we can avoid making it worse. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] UCC nodes cleanup
On Apr 11, 2008, at 12:31 PM, Anton Vorontsov wrote: On Fri, Apr 11, 2008 at 09:21:06PM +0400, Anton Vorontsov wrote: On Fri, Apr 11, 2008 at 12:12:30PM -0500, Timur Tabi wrote: Anton Vorontsov wrote: Or maybe I'm thinking here in terms of "fsl,ucc"... and cell- index is indeed should be -1... don't know. Please decide. ;-) Well, that's what I was thinking. cell-index is zero-based, so UCC1 should have cell-index = <0>. Of course, this means all the code needs to change, since I think device-id is one-based. Yup. You raised a really good question, because we're _introducing_ cell-index for UCC nodes, and if we'll choice wrong numbering scheme now, then there will be no way back w/o breaking backward compatibility. Hm... thinking about it more, we're introducing implementation for the cell-index, but device tree was "infected" already. So, too late. :-D I say leave as you have it (UCC1 == cell-index = <1>). Changing it so cell-index = <0> is just more confusing w/regards to the docs. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Jiri Slaby wrote: > On 04/14/2008 04:12 PM, Timur Tabi wrote: >> Unfortunately, the author of the patch, York, is out this week, so I'll have >> to >> take care of this. It'd be easier to modify rh_alloc() so that it doesn't >> sleep, so that's what I'm going to do. > > Anyway, why do you need the spin lock there (and not mutex)? I don't know. A spinlock just seemed obvious. Why would I prefer a mutex? We need a mutual exclusion device in order to prevent multiple threads from opening the DIU driver simultaneously. When the driver is opened the first time, it needs to initialize the hardware. The hardware can't be initialized unless we allocate a buffer first. Now, we could pre-allocate the buffer, but then this would be a permanent 5MB (8MB if we eliminate rh_alloc) allocation of physically contiguous memory. I'm assuming that this would be a bad thing. It wouldn't eliminate the spinlock, but at least we wouldn't be calling kmalloc(). I open to suggestion for improvements. I'm still going to post the rh_alloc atomic patch, because I think it makes sense anyway. This should fix the sleep-within-spinlock problem, but it does not fix the kmalloc-5MB-in-spinlock problem. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] FCC: fix confused base / offset
On Thu, Apr 10, 2008 at 11:38:00AM -0500, Scott Wood wrote: Hi Scott, Thank you for your help so far > Sascha Hauer wrote: >> See bottom of this mail. The board really is a 8260 based board. Our >> bootloader does not fill in the clock values, so they are hardcoded. I'm >> not very sure about the muram entries because the dpram is organized >> slightly different on the 8260. It has some dedicated FCC space and I >> don't know how to properly encode this in the device tree. > > I think the FCC space should just be left out. The old binding used the dpram offset 0xb080 for fcc2 while the new binding uses cpm_dpalloc which returns 0x80. When I use the old binding and change the hardcoded value from 0xb080 to 0x80 the fcc stopped working. I then hardcoded the value for the new binding to the same value as the old binding used, 0xb080, but no success. > >>> Does the PHY negotiate OK? >> >> Well I put some printks into the phy_read/write functions so I can say >> that it at least properly talks to the phy. > > Do you get a console message indicating that the link came up? No, but I didn't get a message for the old binding, too. I changed the device tree as you suggested, but still no success. BTW there is one thing I forgot to mention which could throw some light into this. This commit broke the FCC driver for me although it does the right thing: commit c6565331b7162a8348c70c37b4c33bedb6d4f02d Author: Scott Wood <[EMAIL PROTECTED]> Date: Mon Oct 1 14:20:50 2007 -0500 fs_enet: mac-fcc: Eliminate __fcc-* macros. These macros accomplish nothing other than defeating type checking. This patch also fixes one instance of the wrong register size being used that was revealed by enabling type checking. Signed-off-by: Scott Wood <[EMAIL PROTECTED]> Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> It fixes an access to the ftodr register in tx_kickstart(). After ftodr access the next console message is truncated and my bdi2000 shows me that the processor doesn't get out of cpm_uart_console_write(). Something strange is going on here... Sascha -- Pengutronix e.K. - Linux Solutions for Science and Industry --- Kontakt-Informationen finden Sie im Header dieser Mail oder auf der Webseite -> http://www.pengutronix.de/impressum/ <- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On 04/14/2008 04:12 PM, Timur Tabi wrote: Unfortunately, the author of the patch, York, is out this week, so I'll have to take care of this. It'd be easier to modify rh_alloc() so that it doesn't sleep, so that's what I'm going to do. Anyway, why do you need the spin lock there (and not mutex)? As I think you are still trying to avoid the problem instead of fixing it. Removing GFP_WAIT (fsl_diu_alloc) doesn't seem to me as mm friendly solution, especially if you allocate that much memory and you can sleep. But I might be wrong, you may need the spinlock... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[2.6 patch] powerpc/sysdev/rtc_cmos_setup.c: add MODULE_LICENSE
This patch adds the missing MODULE_LICENSE("GPL").
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
6f9e3869ba8122adefb706c7d5c18cf4b2dc65c9 diff --git
a/arch/powerpc/sysdev/rtc_cmos_setup.c b/arch/powerpc/sysdev/rtc_cmos_setup.c
index 0c9ac7e..c09ddc0 100644
--- a/arch/powerpc/sysdev/rtc_cmos_setup.c
+++ b/arch/powerpc/sysdev/rtc_cmos_setup.c
@@ -56,3 +56,5 @@ static int __init add_rtc(void)
return 0;
}
fs_initcall(add_rtc);
+
+MODULE_LICENSE("GPL");
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] Add DIU platform code for MPC8610HPCD
On Wednesday 12 March 2008, York Sun wrote:
> +#include
> +#include
> +
> +#undef DEBUG
> +#ifdef DEBUG
> +#define DPRINTK(fmt, args...) printk(KERN_DEBUG "%s: " fmt, __func__, ##
> args)
> +#else
> +#define DPRINTK(fmt, args...)
> +#endif
Please don't define your own debug macros, but rather use pr_debug and related
helpers from linux/kernel.h.
> +static unsigned char *pixis_bdcfg0, *pixis_arch;
> +
These need to be __iomem, as far as I can see. Please run 'make C=1'
to have this kind of problem checked by 'sparse' and clean up its
findings.
> @@ -161,12 +173,251 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_AL, 0x5229,
> quirk_uli5229);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AL, 0x5288, final_uli5288);
> #endif /* CONFIG_PCI */
>
> +static u32 get_busfreq(void)
> +{
> + struct device_node *node;
> +
> + u32 fs_busfreq = 0;
> + node = of_find_node_by_type(NULL, "cpu");
> + if (node) {
> + unsigned int size;
> + const unsigned int *prop =
> + of_get_property(node, "bus-frequency", &size);
> + if (prop)
> + fs_busfreq = *prop;
> + of_node_put(node);
> + };
> + return fs_busfreq;
> +}
I guess this breaks for frequencies larger than 2^32 Ghz, right?
IIRC, there is a method for encoding higher frequencies in the device
tree, and you should probably support that, or even better, refer
to some other function that is already interpreting it.
> +#ifdef CONFIG_FB_FSL_DIU
> +
> +static rh_block_t diu_rh_block[16];
> +static rh_info_t diu_rh_info;
> +static unsigned long diu_size = 1280 * 1024 * 4; /* One 1280x1024 buffer */
> +static void *diu_mem;
diu_mem is probably __iomem as well, right?
Also, it would be cleaner to have the variables in a data structure
pointed to by your device->driver_data. It would only be strictly
necessary if you expect to see a system with multiple DIU instances,
which I think is unlikely, but still it is the way that people
expect to see the code when they read it.
> +unsigned int platform_get_pixel_format
> + (unsigned int bits_per_pixel, int monitor_port)
> +{
> + static const unsigned long pixelformat[][3] = {
> + {0x2317, 0x88083218, 0x65052119},
> + {0x3316, 0x88082219, 0x65053118},
> + };
> + unsigned int pix_fmt, arch_monitor;
> +
> + arch_monitor = ((*pixis_arch == 0x01) && (monitor_port == 0))? 0 : 1;
> + /* DVI port for board version 0x01 */
> +
> + if (bits_per_pixel == 32)
> + pix_fmt = pixelformat[arch_monitor][0];
> + else if (bits_per_pixel == 24)
> + pix_fmt = pixelformat[arch_monitor][1];
> + else if (bits_per_pixel == 16)
> + pix_fmt = pixelformat[arch_monitor][2];
> + else
> + pix_fmt = pixelformat[1][0];
> +
> + return pix_fmt;
> +}
> +EXPORT_SYMBOL(platform_get_pixel_format);
Generally, when you create new functions that are going to be used
just by your own code, they should be EXPORT_SYMBOL_GPL. It's your
choice though, as you are the author.
> +void platform_set_pixel_clock(unsigned int pixclock)
> +{
> + u32 __iomem *clkdvdr;
> + u32 temp;
> + /* variables for pixel clock calcs */
> + ulong bestval, bestfreq, speed_ccb, minpixclock, maxpixclock;
> + ulong pixval;
> + long err;
> + int i;
> +
> + clkdvdr = ioremap(get_immrbase() + 0xe0800, sizeof(u32));
Please don't use get_immrbase in new code. Instead, register an
of_platform_driver for the device in the device tree, then
use of_iomap to map its register from the driver probe() callback.
> +void *fsl_diu_alloc(unsigned long size, unsigned long *phys)
> +{
> + void *virt;
> +
> + DPRINTK("size=%lu\n", size);
> +
> + virt = dma_alloc_coherent(0, size, phys, GFP_DMA | GFP_KERNEL);
> +
> + if (virt) {
> + DPRINTK("dma virt=%p phys=%lx\n", virt, *phys);
> + return virt;
> + }
> +
> + if (!diu_mem) {
> + printk(KERN_INFO "%s: no diu_mem\n", __func__);
> + return NULL;
> + }
> +
> + virt = rh_alloc(&diu_rh_info, size, "DIU");
> + if (virt)
> + *phys = virt_to_bus(virt);
> +
> + DPRINTK("rh virt=%p phys=%x\n", virt, *phys);
> +
> + return virt;
> +}
> +EXPORT_SYMBOL(fsl_diu_alloc);
Don't use virt_to_bus in new code, it does not work with the DMA
mapping API. Instead, use dma_map_single() to convert the kernel address
into something that can be addressed by hardware.
You probably don't need the dma_alloc_coherent path in that case,
but always use dma_map_single on a newly allocated piece of kernel
memory.
Arnd <><
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Jiri Slaby wrote: > On 04/14/2008 03:45 PM, Timur Tabi wrote: >> Jiri Slaby wrote: >> >>> See >>> http://lkml.org/lkml/2008/3/12/375 >> That email is dated 3/12 and those comments are about v1 of the patch. The >> most >> recent posted version is v5 and it addresses all these issues. See >> http://lkml.org/lkml/2008/4/1/346 > > Ok, how is the sleep-inside-spinlock in fsl_diu_open resolved? rh_alloc might > sleep if I still see correctly, do I? Hmmm... I thought I had an answer to this question, but I checked the patch again, and it looks like this particular issue hasn't been fixed. rh_alloc can still sleep. I know we worked on fixing this bug, so I'm not sure why it's still there. However, we don't need to call rh_alloc(). The arch/powerpc code has been updated to remove the need for us to a use an rheap. Unfortunately, the author of the patch, York, is out this week, so I'll have to take care of this. It'd be easier to modify rh_alloc() so that it doesn't sleep, so that's what I'm going to do. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On 04/14/2008 03:45 PM, Timur Tabi wrote: Jiri Slaby wrote: See http://lkml.org/lkml/2008/3/12/375 That email is dated 3/12 and those comments are about v1 of the patch. The most recent posted version is v5 and it addresses all these issues. See http://lkml.org/lkml/2008/4/1/346 Ok, how is the sleep-inside-spinlock in fsl_diu_open resolved? rh_alloc might sleep if I still see correctly, do I? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Jiri Slaby wrote: > See > http://lkml.org/lkml/2008/3/12/375 That email is dated 3/12 and those comments are about v1 of the patch. The most recent posted version is v5 and it addresses all these issues. See http://lkml.org/lkml/2008/4/1/346 -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
On 04/14/2008 03:39 PM, Timur Tabi wrote: Andrew Morton wrote: Thanks. I've made a note that this patch has outstanding issues. Usually this means that I'll defer merging it until they have been addressed: either by fixing them or by successfully arguing against the objections. Sorry, I must have gotten out of sync. What are the outstanding issues? I was under the impression that the latest patch (v5) resolved everything. In fact, the last email from you (dated 4/1) said that you picked it up, minus the defconfig. See http://lkml.org/lkml/2008/3/12/375 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] Driver for Freescale 8610 and 5121 DIU
Andrew Morton wrote: > Thanks. I've made a note that this patch has outstanding issues. Usually > this means that I'll defer merging it until they have been addressed: > either by fixing them or by successfully arguing against the objections. Sorry, I must have gotten out of sync. What are the outstanding issues? I was under the impression that the latest patch (v5) resolved everything. In fact, the last email from you (dated 4/1) said that you picked it up, minus the defconfig. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Paul Mackerras wrote:
> Kamalesh Babulal writes:
>
>> The SHA1 ID of the kernel is 0e81a8ae37687845f7cdfa2adce14ea6a5f1dd34
>> (2.6.25-rc8)
>> and the source seems to have the patch
>> 44387e9ff25267c78a99229aca55ed750e9174c7.
>>
>> The kernel was patched only the patch you gave me
>> (http://lkml.org/lkml/2008/4/8/42).
>
> Please try again with both that patch and the one below. Once again
> it won't fix the bug but will give us more information. When the oops
> occurs, the kernel will print a lot of debug information that should
> help locate the problem.
>
> Paul.
>
> diff --git a/arch/powerpc/kernel/asm-offsets.c
> b/arch/powerpc/kernel/asm-offsets.c
> index e932b43..f16db50 100644
> --- a/arch/powerpc/kernel/asm-offsets.c
> +++ b/arch/powerpc/kernel/asm-offsets.c
> @@ -144,6 +144,9 @@ int main(void)
> DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
> DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
> DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
> + DEFINE(PACASLBLOG, offsetof(struct paca_struct, slblog));
> + DEFINE(PACASLBLOGIX, offsetof(struct paca_struct, slblog_ix));
> + DEFINE(PACALASTSLB, offsetof(struct paca_struct, last_slb));
>
> DEFINE(SLBSHADOW_STACKVSID,
> offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid));
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 148a354..663df17 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -419,6 +419,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_1T_SEGMENT)
> slbmte r7,r0
> isync
>
> + ld r4,PACASLBLOGIX(r13)
> + addir4,r4,1
> + clrldi r4,r4,64-6
> + std r4,PACASLBLOGIX(r13)
> + add r4,r4,r13
> + addir4,r4,PACASLBLOG
> + li r5,4
> + std r5,0(r4)
> + mftbr5
> + std r5,8(r4)
> + std r6,16(r4)
> + std r0,24(r4)
> 2:
> clrrdi r7,r8,THREAD_SHIFT /* base of new stack */
> /* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
> @@ -533,6 +545,17 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
>
> stdcx. r0,0,r1 /* to clear the reservation */
>
> + li r4,0
> + slbmfee r2,r4
> + std r2,PACALASTSLB(r13)
> + slbmfev r2,r4
> + std r2,PACALASTSLB+8(r13)
> + li r4,1
> + slbmfee r2,r4
> + std r2,PACALASTSLB+16(r13)
> + slbmfev r2,r4
> + std r2,PACALASTSLB+24(r13)
> +
> /*
>* Clear RI before restoring r13. If we are returning to
>* userspace and we take an exception after restoring r13,
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 4b5b7ff..c918f33 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -1141,6 +1141,40 @@ void SPEFloatingPointException(struct pt_regs *regs)
> }
> #endif
>
> +static void dump_unrecov_slb(void)
> +{
> +#ifdef CONFIG_PPC64
> + long entry, rstart;
> + unsigned long esid, vsid;
> +
> + printk(KERN_EMERG "SLB contents now:\n");
> + for (entry = 0; entry < 64; ++entry) {
> + asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (entry));
> + if (esid == 0)
> + /* valid bit is clear along with everything else */
> + continue;
> + asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (entry));
> + printk(KERN_EMERG "%d: %.16lx %.16lx\n", entry, esid, vsid);
> + }
> +
> + printk(KERN_EMERG "SLB 0-1 at last exception exit:\n");
> + printk(KERN_EMERG "0: %.16lx %.16lx\n", get_paca()->last_slb[0][0],
> +get_paca()->last_slb[0][1]);
> + printk(KERN_EMERG "1: %.16lx %.16lx\n", get_paca()->last_slb[1][0],
> +get_paca()->last_slb[1][1]);
> + printk(KERN_EMERG "SLB update log:\n");
> + rstart = entry = get_paca()->slblog_ix;
> + do {
> + printk(KERN_EMERG "%d: %lx %lx %.16lx %.16lx\n", entry,
> +get_paca()->slblog[entry][0],
> +get_paca()->slblog[entry][1],
> +get_paca()->slblog[entry][2],
> +get_paca()->slblog[entry][3]);
> + entry = (entry + 1) % 63;
> + } while (entry != rstart);
> +#endif
> +}
> +
> /*
> * We enter here if we get an unrecoverable exception, that is, one
> * that happened at a point where the RI (recoverable interrupt) bit
> @@ -1151,6 +1185,8 @@ void unrecoverable_exception(struct pt_regs *regs)
> {
> printk(KERN_EMERG "Unrecoverable exception %lx at %lx\n",
> regs->trap, regs->nip);
> + if (regs->trap == 0x4100)
> + dump_unrecov_slb();
> die("Unrecoverable exception", regs, SIGABRT);
> }
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 906daed..235edf7 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/pow
Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Kamalesh Babulal writes:
> The SHA1 ID of the kernel is 0e81a8ae37687845f7cdfa2adce14ea6a5f1dd34
> (2.6.25-rc8)
> and the source seems to have the patch
> 44387e9ff25267c78a99229aca55ed750e9174c7.
>
> The kernel was patched only the patch you gave me
> (http://lkml.org/lkml/2008/4/8/42).
Please try again with both that patch and the one below. Once again
it won't fix the bug but will give us more information. When the oops
occurs, the kernel will print a lot of debug information that should
help locate the problem.
Paul.
diff --git a/arch/powerpc/kernel/asm-offsets.c
b/arch/powerpc/kernel/asm-offsets.c
index e932b43..f16db50 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -144,6 +144,9 @@ int main(void)
DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
DEFINE(PACA_TRAP_SAVE, offsetof(struct paca_struct, trap_save));
+ DEFINE(PACASLBLOG, offsetof(struct paca_struct, slblog));
+ DEFINE(PACASLBLOGIX, offsetof(struct paca_struct, slblog_ix));
+ DEFINE(PACALASTSLB, offsetof(struct paca_struct, last_slb));
DEFINE(SLBSHADOW_STACKVSID,
offsetof(struct slb_shadow, save_area[SLB_NUM_BOLTED - 1].vsid));
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 148a354..663df17 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -419,6 +419,18 @@ END_FTR_SECTION_IFSET(CPU_FTR_1T_SEGMENT)
slbmte r7,r0
isync
+ ld r4,PACASLBLOGIX(r13)
+ addir4,r4,1
+ clrldi r4,r4,64-6
+ std r4,PACASLBLOGIX(r13)
+ add r4,r4,r13
+ addir4,r4,PACASLBLOG
+ li r5,4
+ std r5,0(r4)
+ mftbr5
+ std r5,8(r4)
+ std r6,16(r4)
+ std r0,24(r4)
2:
clrrdi r7,r8,THREAD_SHIFT /* base of new stack */
/* Note: this uses SWITCH_FRAME_SIZE rather than INT_FRAME_SIZE
@@ -533,6 +545,17 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES)
stdcx. r0,0,r1 /* to clear the reservation */
+ li r4,0
+ slbmfee r2,r4
+ std r2,PACALASTSLB(r13)
+ slbmfev r2,r4
+ std r2,PACALASTSLB+8(r13)
+ li r4,1
+ slbmfee r2,r4
+ std r2,PACALASTSLB+16(r13)
+ slbmfev r2,r4
+ std r2,PACALASTSLB+24(r13)
+
/*
* Clear RI before restoring r13. If we are returning to
* userspace and we take an exception after restoring r13,
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4b5b7ff..c918f33 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -1141,6 +1141,40 @@ void SPEFloatingPointException(struct pt_regs *regs)
}
#endif
+static void dump_unrecov_slb(void)
+{
+#ifdef CONFIG_PPC64
+ long entry, rstart;
+ unsigned long esid, vsid;
+
+ printk(KERN_EMERG "SLB contents now:\n");
+ for (entry = 0; entry < 64; ++entry) {
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (entry));
+ if (esid == 0)
+ /* valid bit is clear along with everything else */
+ continue;
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (entry));
+ printk(KERN_EMERG "%d: %.16lx %.16lx\n", entry, esid, vsid);
+ }
+
+ printk(KERN_EMERG "SLB 0-1 at last exception exit:\n");
+ printk(KERN_EMERG "0: %.16lx %.16lx\n", get_paca()->last_slb[0][0],
+ get_paca()->last_slb[0][1]);
+ printk(KERN_EMERG "1: %.16lx %.16lx\n", get_paca()->last_slb[1][0],
+ get_paca()->last_slb[1][1]);
+ printk(KERN_EMERG "SLB update log:\n");
+ rstart = entry = get_paca()->slblog_ix;
+ do {
+ printk(KERN_EMERG "%d: %lx %lx %.16lx %.16lx\n", entry,
+ get_paca()->slblog[entry][0],
+ get_paca()->slblog[entry][1],
+ get_paca()->slblog[entry][2],
+ get_paca()->slblog[entry][3]);
+ entry = (entry + 1) % 63;
+ } while (entry != rstart);
+#endif
+}
+
/*
* We enter here if we get an unrecoverable exception, that is, one
* that happened at a point where the RI (recoverable interrupt) bit
@@ -1151,6 +1185,8 @@ void unrecoverable_exception(struct pt_regs *regs)
{
printk(KERN_EMERG "Unrecoverable exception %lx at %lx\n",
regs->trap, regs->nip);
+ if (regs->trap == 0x4100)
+ dump_unrecov_slb();
die("Unrecoverable exception", regs, SIGABRT);
}
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 906daed..235edf7 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -105,6 +105,7 @@ void slb_flush_and_rebolt(void)
* appropriately too. */
unsigned long linear_llp,
Re: [PATCH 5/5] WDT driver
On Saturday 12 April 2008 20:11, Sean MacLennan wrote:
> Signed-off-by: Sean MacLennan <[EMAIL PROTECTED]>
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 254d115..e73a3ea 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -697,6 +697,14 @@ config BOOKE_WDT
> Please see Documentation/watchdog/watchdog-api.txt for
> more information.
>
> +config PIKA_WDT
> + tristate "PIKA FPGA Watchdog"
> + depends on WARP
> + default y
> + help
> + This enables the watchdog in the PIKA FPGA. Currently used on
> + the Warp platform.
> +
> # PPC64 Architecture
>
> config WATCHDOG_RTAS
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f3fb170..09758c5 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -105,6 +105,7 @@ obj-$(CONFIG_MPC5200_WDT) += mpc5200_wdt.o
> obj-$(CONFIG_83xx_WDT) += mpc83xx_wdt.o
> obj-$(CONFIG_MV64X60_WDT) += mv64x60_wdt.o
> obj-$(CONFIG_BOOKE_WDT) += booke_wdt.o
> +obj-$(CONFIG_PIKA_WDT) += pika_wdt.o
>
> # PPC64 Architecture
> obj-$(CONFIG_WATCHDOG_RTAS) += wdrtas.o
> diff --git a/drivers/watchdog/pika_wdt.c b/drivers/watchdog/pika_wdt.c
> new file mode 100644
> index 000..b84ac07
> --- /dev/null
> +++ b/drivers/watchdog/pika_wdt.c
> @@ -0,0 +1,113 @@
> +/*
> + * PIKA FPGA based Watchdog Timer
> + *
> + * Copyright (c) 2008 PIKA Technologies
> + * Sean MacLennan
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +static void __iomem *pikawdt_fpga;
> +
> +
> +static inline void pikawdt_ping(void)
> +{
> + unsigned reset = in_be32(pikawdt_fpga + 0x14);
> + reset |= 0xf80; /* enable with max timeout - 15 seconds */
> + out_be32(pikawdt_fpga + 0x14, reset);
What about
setbits32((u32 __iomem *)(pikawdt_fpga + 0x14), 0xf80);
> +}
> +
> +static int pikawdt_open(struct inode *inode, struct file *file)
> +{
> + printk(KERN_INFO "PIKA WDT started...\n");
> +
> + pikawdt_ping();
> +
> + return 0;
> +}
> +
> +static int pikawdt_release(struct inode *inode, struct file *file)
> +{
> + pikawdt_ping(); /* one last time */
> + return 0;
> +}
> +
> +static ssize_t pikawdt_write(struct file *file, const char __user *buf,
> + size_t count, loff_t *ppos)
> +{
> + pikawdt_ping();
> + return count;
> +}
> +
> +/* We support the bare minimum to be conformant. */
> +static int pikawdt_ioctl(struct inode *inode, struct file *file,
> + unsigned int cmd, unsigned long arg)
> +{
> + if (cmd == WDIOC_KEEPALIVE) {
> + pikawdt_ping();
> + return 0;
> + } else
> + return -EINVAL;
> +}
> +
> +static const struct file_operations pikawdt_fops = {
> + .owner = THIS_MODULE,
> + .open = pikawdt_open,
> + .release= pikawdt_release,
> + .write = pikawdt_write,
> + .ioctl = pikawdt_ioctl,
> +};
> +
> +static struct miscdevice pikawdt_miscdev = {
> + .minor = WATCHDOG_MINOR,
> + .name = "watchdog",
> + .fops = &pikawdt_fops,
> +};
> +
> +static int __init pikawdt_init(void)
> +{
> + struct device_node *np;
> + int ret;
> +
> + np = of_find_compatible_node(NULL, NULL, "pika,fpga");
> + if (np == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to find fpga.\n");
> + return -ENOENT;
> + }
> +
> + pikawdt_fpga = of_iomap(np, 0);
> +
> + of_node_put(np);
> +
> + if (pikawdt_fpga == NULL) {
> + printk(KERN_ERR "pikawdt: Unable to map fpga.\n");
> + return -ENOENT;
> + }
> +
> + ret = misc_register(&pikawdt_miscdev);
> + if (ret) {
> + iounmap(pikawdt_fpga);
> + printk(KERN_ERR "pikawdt: Unable to register miscdev.\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +module_init(pikawdt_init);
> +
> +
> +static void __exit pikawdt_exit(void)
> +{
> + misc_deregister(&pikawdt_miscdev);
> +
> + iounmap(pikawdt_fpga);
> +}
> +module_exit(pikawdt_exit);
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
>
--
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
pgpUfGl9Oq6Pl.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
