* [POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit 6a30bd1e2160e921a8fb051b472dfaf068f4f386
Author: Olof Johansson <olof@lixom.net>
Date: Tue Sep 4 21:53:30 2007 -0500
[POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
Move pasemi_idle_init() to be a late_initcall instead of being called from
setup_arch(). This way the cpufreq driver has a chance to initialize and
save away the boot time astate before we go to idle for the first time.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/idle.c b/arch/powerpc/platforms/pasemi/idle.c
index 3c962d5..d8e1fcc 100644
--- a/arch/powerpc/platforms/pasemi/idle.c
+++ b/arch/powerpc/platforms/pasemi/idle.c
@@ -72,8 +72,11 @@ static int pasemi_system_reset_exception(struct pt_regs *regs)
return 1;
}
-void __init pasemi_idle_init(void)
+static int __init pasemi_idle_init(void)
{
+ if (!machine_is(pasemi))
+ return -ENODEV;
+
#ifndef CONFIG_PPC_PASEMI_CPUFREQ
printk(KERN_WARNING "No cpufreq driver, powersavings modes disabled\n");
current_mode = 0;
@@ -82,7 +85,10 @@ void __init pasemi_idle_init(void)
ppc_md.system_reset_exception = pasemi_system_reset_exception;
ppc_md.power_save = modes[current_mode].entry;
printk(KERN_INFO "Using PA6T idle loop (%s)\n", modes[current_mode].name);
+
+ return 0;
}
+late_initcall(pasemi_idle_init);
static int __init idle_param(char *p)
{
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index 6fd2fe7..516acab 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -10,8 +10,6 @@ extern void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset);
extern void __init alloc_iobmap_l2(void);
-extern void __init pasemi_idle_init(void);
-
/* Power savings modes, implemented in asm */
extern void idle_spin(void);
extern void idle_doze(void);
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index fe9a5d6..5ddf40a 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -115,8 +115,6 @@ void __init pas_setup_arch(void)
/* Remap SDC register for doing reset */
/* XXXOJN This should maybe come out of the device tree */
reset_reg = ioremap(0xfc101100, 4);
-
- pasemi_idle_init();
}
static int __init pas_setup_mce_regs(void)
^ permalink raw reply related
* [POWERPC] pasemi: Print more information at machine check
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit c456a6cdfe86cb0e2e2187f5e76768f9215e0693
Author: Olof Johansson <olof@lixom.net>
Date: Tue Sep 4 21:49:51 2007 -0500
[POWERPC] pasemi: Print more information at machine check
Add printout of some SoC error status registers, and dump the SLB contents
for those machine check events where it makes sense.
Since we can't go about and ioremap registers at machine check time,
and we generally want to do as little as possible to print out the
information, pre-build a table of the registers to dump and their address
in the common PCI config space range.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/setup.c b/arch/powerpc/platforms/pasemi/setup.c
index 05def62..fe9a5d6 100644
--- a/arch/powerpc/platforms/pasemi/setup.c
+++ b/arch/powerpc/platforms/pasemi/setup.c
@@ -39,8 +39,21 @@
#include "pasemi.h"
+/* SDC reset register, must be pre-mapped at reset time */
static void __iomem *reset_reg;
+/* Various error status registers, must be pre-mapped at MCE time */
+
+#define MAX_MCE_REGS 32
+struct mce_regs {
+ char *name;
+ void __iomem *addr;
+};
+
+static struct mce_regs mce_regs[MAX_MCE_REGS];
+static int num_mce_regs;
+
+
static void pas_restart(char *cmd)
{
printk("Restarting...\n");
@@ -106,6 +119,59 @@ void __init pas_setup_arch(void)
pasemi_idle_init();
}
+static int __init pas_setup_mce_regs(void)
+{
+ struct pci_dev *dev;
+ int reg;
+
+ if (!machine_is(pasemi))
+ return -ENODEV;
+
+ /* Remap various SoC status registers for use by the MCE handler */
+
+ reg = 0;
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa00a, NULL);
+ while (dev && reg < MAX_MCE_REGS) {
+ mce_regs[reg].name = kasprintf(GFP_KERNEL,
+ "mc%d_mcdebug_errsta", reg);
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x730);
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa00a, dev);
+ reg++;
+ }
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa001, NULL);
+ if (dev && reg+4 < MAX_MCE_REGS) {
+ mce_regs[reg].name = "iobdbg_IntStatus1";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x438);
+ reg++;
+ mce_regs[reg].name = "iobdbg_IOCTbusIntDbgReg";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x454);
+ reg++;
+ mce_regs[reg].name = "iobiom_IntStatus";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0xc10);
+ reg++;
+ mce_regs[reg].name = "iobiom_IntDbgReg";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0xc1c);
+ reg++;
+ }
+
+ dev = pci_get_device(PCI_VENDOR_ID_PASEMI, 0xa009, NULL);
+ if (dev && reg+2 < MAX_MCE_REGS) {
+ mce_regs[reg].name = "l2csts_IntStatus";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x200);
+ reg++;
+ mce_regs[reg].name = "l2csts_Cnt";
+ mce_regs[reg].addr = pasemi_pci_getcfgaddr(dev, 0x214);
+ reg++;
+ }
+
+ num_mce_regs = reg;
+
+ return 0;
+}
+device_initcall(pas_setup_mce_regs);
+
static __init void pas_init_IRQ(void)
{
struct device_node *np;
@@ -166,25 +232,34 @@ static int pas_machine_check_handler(struct pt_regs *regs)
{
int cpu = smp_processor_id();
unsigned long srr0, srr1, dsisr;
+ int dump_slb = 0;
+ int i;
srr0 = regs->nip;
srr1 = regs->msr;
dsisr = mfspr(SPRN_DSISR);
printk(KERN_ERR "Machine Check on CPU %d\n", cpu);
- printk(KERN_ERR "SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
- printk(KERN_ERR "DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
+ printk(KERN_ERR "SRR0 0x%016lx SRR1 0x%016lx\n", srr0, srr1);
+ printk(KERN_ERR "DSISR 0x%016lx DAR 0x%016lx\n", dsisr, regs->dar);
+ printk(KERN_ERR "BER 0x%016lx MER 0x%016lx\n", mfspr(SPRN_PA6T_BER),
+ mfspr(SPRN_PA6T_MER));
+ printk(KERN_ERR "IER 0x%016lx DER 0x%016lx\n", mfspr(SPRN_PA6T_IER),
+ mfspr(SPRN_PA6T_DER));
printk(KERN_ERR "Cause:\n");
if (srr1 & 0x200000)
printk(KERN_ERR "Signalled by SDC\n");
+
if (srr1 & 0x100000) {
printk(KERN_ERR "Load/Store detected error:\n");
if (dsisr & 0x8000)
printk(KERN_ERR "D-cache ECC double-bit error or bus error\n");
if (dsisr & 0x4000)
printk(KERN_ERR "LSU snoop response error\n");
- if (dsisr & 0x2000)
+ if (dsisr & 0x2000) {
printk(KERN_ERR "MMU SLB multi-hit or invalid B field\n");
+ dump_slb = 1;
+ }
if (dsisr & 0x1000)
printk(KERN_ERR "Recoverable Duptags\n");
if (dsisr & 0x800)
@@ -192,13 +267,40 @@ static int pas_machine_check_handler(struct pt_regs *regs)
if (dsisr & 0x400)
printk(KERN_ERR "TLB parity error count overflow\n");
}
+
if (srr1 & 0x80000)
printk(KERN_ERR "Bus Error\n");
- if (srr1 & 0x40000)
+
+ if (srr1 & 0x40000) {
printk(KERN_ERR "I-side SLB multiple hit\n");
+ dump_slb = 1;
+ }
+
if (srr1 & 0x20000)
printk(KERN_ERR "I-cache parity error hit\n");
+ if (num_mce_regs == 0)
+ printk(KERN_ERR "No MCE registers mapped yet, can't dump\n");
+ else
+ printk(KERN_ERR "SoC debug registers:\n");
+
+ for (i = 0; i < num_mce_regs; i++)
+ printk(KERN_ERR "%s: 0x%08x\n", mce_regs[i].name,
+ in_le32(mce_regs[i].addr));
+
+ if (dump_slb) {
+ unsigned long e, v;
+ int i;
+
+ printk(KERN_ERR "slb contents:\n");
+ for (i = 0; i < SLB_NUM_ENTRIES; i++) {
+ asm volatile("slbmfee %0,%1" : "=r" (e) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (v) : "r" (i));
+ printk(KERN_ERR "%02d %016lx %016lx\n", i, e, v);
+ }
+ }
+
+
/* SRR1[62] is from MSR[62] if recoverable, so pass that back */
return !!(srr1 & 0x2);
}
^ permalink raw reply related
* [POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
From: Olof Johansson @ 2007-09-05 2:09 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit e34d30c44975ed7db1542f6548f2716185c87baf
Author: Olof Johansson <olof@lixom.net>
Date: Sat Sep 1 14:45:07 2007 -0500
[POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
Export some of the implementation-specific registers via sysfs. Useful
when debugging, etc.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 55d29ed..d7835ba 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -197,6 +197,36 @@ SYSFS_PMCSETUP(pa6t_pmc3, SPRN_PA6T_PMC3);
SYSFS_PMCSETUP(pa6t_pmc4, SPRN_PA6T_PMC4);
SYSFS_PMCSETUP(pa6t_pmc5, SPRN_PA6T_PMC5);
+#ifdef CONFIG_DEBUG_KERNEL
+SYSFS_PMCSETUP(hid0, SPRN_HID0);
+SYSFS_PMCSETUP(hid1, SPRN_HID1);
+SYSFS_PMCSETUP(hid4, SPRN_HID4);
+SYSFS_PMCSETUP(hid5, SPRN_HID5);
+SYSFS_PMCSETUP(ima0, SPRN_PA6T_IMA0);
+SYSFS_PMCSETUP(ima1, SPRN_PA6T_IMA1);
+SYSFS_PMCSETUP(ima2, SPRN_PA6T_IMA2);
+SYSFS_PMCSETUP(ima3, SPRN_PA6T_IMA3);
+SYSFS_PMCSETUP(ima4, SPRN_PA6T_IMA4);
+SYSFS_PMCSETUP(ima5, SPRN_PA6T_IMA5);
+SYSFS_PMCSETUP(ima6, SPRN_PA6T_IMA6);
+SYSFS_PMCSETUP(ima7, SPRN_PA6T_IMA7);
+SYSFS_PMCSETUP(ima8, SPRN_PA6T_IMA8);
+SYSFS_PMCSETUP(ima9, SPRN_PA6T_IMA9);
+SYSFS_PMCSETUP(imaat, SPRN_PA6T_IMAAT);
+SYSFS_PMCSETUP(btcr, SPRN_PA6T_BTCR);
+SYSFS_PMCSETUP(pccr, SPRN_PA6T_PCCR);
+SYSFS_PMCSETUP(rpccr, SPRN_PA6T_RPCCR);
+SYSFS_PMCSETUP(der, SPRN_PA6T_DER);
+SYSFS_PMCSETUP(mer, SPRN_PA6T_MER);
+SYSFS_PMCSETUP(ber, SPRN_PA6T_BER);
+SYSFS_PMCSETUP(ier, SPRN_PA6T_IER);
+SYSFS_PMCSETUP(sier, SPRN_PA6T_SIER);
+SYSFS_PMCSETUP(siar, SPRN_PA6T_SIAR);
+SYSFS_PMCSETUP(tsr0, SPRN_PA6T_TSR0);
+SYSFS_PMCSETUP(tsr1, SPRN_PA6T_TSR1);
+SYSFS_PMCSETUP(tsr2, SPRN_PA6T_TSR2);
+SYSFS_PMCSETUP(tsr3, SPRN_PA6T_TSR3);
+#endif /* CONFIG_DEBUG_KERNEL */
static SYSDEV_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
static SYSDEV_ATTR(spurr, 0600, show_spurr, NULL);
@@ -228,6 +258,36 @@ static struct sysdev_attribute pa6t_attrs[] = {
_SYSDEV_ATTR(pmc3, 0600, show_pa6t_pmc3, store_pa6t_pmc3),
_SYSDEV_ATTR(pmc4, 0600, show_pa6t_pmc4, store_pa6t_pmc4),
_SYSDEV_ATTR(pmc5, 0600, show_pa6t_pmc5, store_pa6t_pmc5),
+#ifdef CONFIG_DEBUG_KERNEL
+ _SYSDEV_ATTR(hid0, 0600, show_hid0, store_hid0),
+ _SYSDEV_ATTR(hid1, 0600, show_hid1, store_hid1),
+ _SYSDEV_ATTR(hid4, 0600, show_hid4, store_hid4),
+ _SYSDEV_ATTR(hid5, 0600, show_hid5, store_hid5),
+ _SYSDEV_ATTR(ima0, 0600, show_ima0, store_ima0),
+ _SYSDEV_ATTR(ima1, 0600, show_ima1, store_ima1),
+ _SYSDEV_ATTR(ima2, 0600, show_ima2, store_ima2),
+ _SYSDEV_ATTR(ima3, 0600, show_ima3, store_ima3),
+ _SYSDEV_ATTR(ima4, 0600, show_ima4, store_ima4),
+ _SYSDEV_ATTR(ima5, 0600, show_ima5, store_ima5),
+ _SYSDEV_ATTR(ima6, 0600, show_ima6, store_ima6),
+ _SYSDEV_ATTR(ima7, 0600, show_ima7, store_ima7),
+ _SYSDEV_ATTR(ima8, 0600, show_ima8, store_ima8),
+ _SYSDEV_ATTR(ima9, 0600, show_ima9, store_ima9),
+ _SYSDEV_ATTR(imaat, 0600, show_imaat, store_imaat),
+ _SYSDEV_ATTR(btcr, 0600, show_btcr, store_btcr),
+ _SYSDEV_ATTR(pccr, 0600, show_pccr, store_pccr),
+ _SYSDEV_ATTR(rpccr, 0600, show_rpccr, store_rpccr),
+ _SYSDEV_ATTR(der, 0600, show_der, store_der),
+ _SYSDEV_ATTR(mer, 0600, show_mer, store_mer),
+ _SYSDEV_ATTR(ber, 0600, show_ber, store_ber),
+ _SYSDEV_ATTR(ier, 0600, show_ier, store_ier),
+ _SYSDEV_ATTR(sier, 0600, show_sier, store_sier),
+ _SYSDEV_ATTR(siar, 0600, show_siar, store_siar),
+ _SYSDEV_ATTR(tsr0, 0600, show_tsr0, store_tsr0),
+ _SYSDEV_ATTR(tsr1, 0600, show_tsr1, store_tsr1),
+ _SYSDEV_ATTR(tsr2, 0600, show_tsr2, store_tsr2),
+ _SYSDEV_ATTR(tsr3, 0600, show_tsr3, store_tsr3),
+#endif /* CONFIG_DEBUG_KERNEL */
};
diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
index 281011e..347de53 100644
--- a/include/asm-powerpc/reg.h
+++ b/include/asm-powerpc/reg.h
@@ -518,21 +518,47 @@
#define PA6T_MMCR1_ES4 0x0000000000ff0000UL
#define PA6T_MMCR1_ES5 0x00000000ff000000UL
-#define SPRN_PA6T_SIAR 780
-#define SPRN_PA6T_UPMC0 771
-#define SPRN_PA6T_UPMC1 772
+#define SPRN_PA6T_UPMC0 771 /* User PerfMon Counter 0 */
+#define SPRN_PA6T_UPMC1 772 /* ... */
#define SPRN_PA6T_UPMC2 773
#define SPRN_PA6T_UPMC3 774
#define SPRN_PA6T_UPMC4 775
#define SPRN_PA6T_UPMC5 776
-#define SPRN_PA6T_UMMCR0 779
-#define SPRN_PA6T_UMMCR1 782
-#define SPRN_PA6T_PMC0 787
-#define SPRN_PA6T_PMC1 788
-#define SPRN_PA6T_PMC2 789
-#define SPRN_PA6T_PMC3 790
-#define SPRN_PA6T_PMC4 791
-#define SPRN_PA6T_PMC5 792
+#define SPRN_PA6T_UMMCR0 779 /* User Monitor Mode Control Register 0 */
+#define SPRN_PA6T_SIAR 780 /* Sampled Instruction Address */
+#define SPRN_PA6T_UMMCR1 782 /* User Monitor Mode Control Register 1 */
+#define SPRN_PA6T_SIER 785 /* Sampled Instruction Event Register */
+#define SPRN_PA6T_PMC0 787
+#define SPRN_PA6T_PMC1 788
+#define SPRN_PA6T_PMC2 789
+#define SPRN_PA6T_PMC3 790
+#define SPRN_PA6T_PMC4 791
+#define SPRN_PA6T_PMC5 792
+#define SPRN_PA6T_TSR0 793 /* Timestamp Register 0 */
+#define SPRN_PA6T_TSR1 794 /* Timestamp Register 1 */
+#define SPRN_PA6T_TSR2 799 /* Timestamp Register 2 */
+#define SPRN_PA6T_TSR3 784 /* Timestamp Register 3 */
+
+#define SPRN_PA6T_IER 981 /* Icache Error Register */
+#define SPRN_PA6T_DER 982 /* Dcache Error Register */
+#define SPRN_PA6T_BER 862 /* BIU Error Address Register */
+#define SPRN_PA6T_MER 849 /* MMU Error Register */
+
+#define SPRN_PA6T_IMA0 880 /* Instruction Match Array 0 */
+#define SPRN_PA6T_IMA1 881 /* ... */
+#define SPRN_PA6T_IMA2 882
+#define SPRN_PA6T_IMA3 883
+#define SPRN_PA6T_IMA4 884
+#define SPRN_PA6T_IMA5 885
+#define SPRN_PA6T_IMA6 886
+#define SPRN_PA6T_IMA7 887
+#define SPRN_PA6T_IMA8 888
+#define SPRN_PA6T_IMA9 889
+#define SPRN_PA6T_BTCR 978 /* Breakpoint and Tagging Control Register */
+#define SPRN_PA6T_IMAAT 979 /* Instruction Match Array Action Table */
+#define SPRN_PA6T_PCCR 1019 /* Power Counter Control Register */
+#define SPRN_PA6T_RPCCR 1021 /* Retire PC Trace Control Register */
+
#else /* 32-bit */
#define SPRN_MMCR0 952 /* Monitor Mode Control Register 0 */
^ permalink raw reply related
* [POWERPC] pasemi: Add workaround for erratum 5945
From: Olof Johansson @ 2007-09-05 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit 3f7a4e905341e46e7b442a9326c3b31229e25209
Author: Olof Johansson <olof@lixom.net>
Date: Mon Sep 3 00:11:49 2007 -0500
[POWERPC] pasemi: Add workaround for erratum 5945
Erratum 5945 causes some of the registers on the PCIe root ports to
not read correctly. Do a small dance to avoid this: Write an unused
register, read the value and write it back. Thankfully this is not in
a hot code path.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index fcfb3df..b6a0ec4 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -51,6 +51,61 @@ static void volatile __iomem *pa_pxp_cfg_addr(struct pci_controller *hose,
return hose->cfg_data + PA_PXP_CFA(bus, devfn, offset);
}
+static inline int is_root_port(int busno, int devfn)
+{
+ return ((busno == 0) && (PCI_FUNC(devfn) < 4) &&
+ ((PCI_SLOT(devfn) == 16) || (PCI_SLOT(devfn) == 17)));
+}
+
+static inline int is_5945_reg(int reg)
+{
+ return (((reg >= 0x18) && (reg < 0x34)) ||
+ ((reg >= 0x158) && (reg < 0x178)));
+}
+
+static int workaround_5945(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct pci_controller *hose;
+ void volatile __iomem *addr, *dummy;
+ int byte;
+ u32 tmp;
+
+ if (!is_root_port(bus->number, devfn) || !is_5945_reg(offset))
+ return 0;
+
+ hose = pci_bus_to_host(bus);
+
+ addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset & ~0x3);
+ byte = offset & 0x3;
+
+ /* Workaround bug 5945: write 0 to a dummy register before reading,
+ * and write back what we read. We must read/write the full 32-bit
+ * contents so we need to shift and mask by hand.
+ */
+ dummy = pa_pxp_cfg_addr(hose, bus->number, devfn, 0x10);
+ out_le32(dummy, 0);
+ tmp = in_le32(addr);
+ out_le32(addr, tmp);
+
+ switch (len) {
+ case 1:
+ *val = (tmp >> (8*byte)) & 0xff;
+ break;
+ case 2:
+ if (byte == 0)
+ *val = tmp & 0xffff;
+ else
+ *val = (tmp >> 16) & 0xffff;
+ break;
+ default:
+ *val = tmp;
+ break;
+ }
+
+ return 1;
+}
+
static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
{
@@ -64,6 +119,9 @@ static int pa_pxp_read_config(struct pci_bus *bus, unsigned int devfn,
if (!pa_pxp_offset_valid(bus->number, devfn, offset))
return PCIBIOS_BAD_REGISTER_NUMBER;
+ if (workaround_5945(bus, devfn, offset, len, val))
+ return PCIBIOS_SUCCESSFUL;
+
addr = pa_pxp_cfg_addr(hose, bus->number, devfn, offset);
/*
@@ -180,7 +238,7 @@ void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset)
{
struct pci_controller *hose;
- hose = pci_bus_to_host(bus);
+ hose = pci_bus_to_host(dev->bus);
- return pa_pxp_cfg_addr(hose, hose->number, dev->devfn, int offset)
+ return (void __iomem *)pa_pxp_cfg_addr(hose, dev->bus->number, dev->devfn, offset);
}
^ permalink raw reply related
* [POWERPC] pasemi: add pasemi_pci_getcfgaddr()
From: Olof Johansson @ 2007-09-05 2:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905020733.GA25900@lixom.net>
commit aa37284d64c33d4755072d4bb4b5b1304d415d97
Author: Olof Johansson <olof@lixom.net>
Date: Sat Sep 1 15:43:52 2007 -0500
[POWERPC] pasemi: add pasemi_pci_getcfgaddr()
Add pasemi_pci_getcfgaddr(), to get the remapped address of a specific
config register for a PCI device.
Signed-off-by: Olof Johansson <olof@lixom.net>
diff --git a/arch/powerpc/platforms/pasemi/pasemi.h b/arch/powerpc/platforms/pasemi/pasemi.h
index be84954..6fd2fe7 100644
--- a/arch/powerpc/platforms/pasemi/pasemi.h
+++ b/arch/powerpc/platforms/pasemi/pasemi.h
@@ -6,6 +6,8 @@ extern void pas_pci_init(void);
extern void __devinit pas_pci_irq_fixup(struct pci_dev *dev);
extern void __devinit pas_pci_dma_dev_setup(struct pci_dev *dev);
+extern void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset);
+
extern void __init alloc_iobmap_l2(void);
extern void __init pasemi_idle_init(void);
diff --git a/arch/powerpc/platforms/pasemi/pci.c b/arch/powerpc/platforms/pasemi/pci.c
index 03d1d07..fcfb3df 100644
--- a/arch/powerpc/platforms/pasemi/pci.c
+++ b/arch/powerpc/platforms/pasemi/pci.c
@@ -175,3 +175,12 @@ void __init pas_pci_init(void)
/* Use the common resource allocation mechanism */
pci_probe_only = 1;
}
+
+void __iomem *pasemi_pci_getcfgaddr(struct pci_dev *dev, int offset)
+{
+ struct pci_controller *hose;
+
+ hose = pci_bus_to_host(bus);
+
+ return pa_pxp_cfg_addr(hose, hose->number, dev->devfn, int offset)
+}
^ permalink raw reply related
* Re: [patch 5/6] Walnut board support
From: David Gibson @ 2007-09-05 3:01 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070831200643.514442000@linux.vnet.ibm.com>
On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> Board support for the PPC405 Walnut evaluation board
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Olof Johansson @ 2007-09-05 2:07 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Paul,
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/olof/pasemi.git for-2.6.24
to receive the following updates:
arch/powerpc/kernel/sysfs.c | 60 +++++++++++++++++
arch/powerpc/platforms/pasemi/idle.c | 8 ++
arch/powerpc/platforms/pasemi/pasemi.h | 4 -
arch/powerpc/platforms/pasemi/pci.c | 71 ++++++++++++++++++++
arch/powerpc/platforms/pasemi/setup.c | 112 +++++++++++++++++++++++++++++++--
include/asm-powerpc/reg.h | 48 ++++++++++----
6 files changed, 281 insertions(+), 22 deletions(-)
Olof Johansson (5):
[POWERPC] pasemi: add pasemi_pci_getcfgaddr()
[POWERPC] pasemi: Add workaround for erratum 5945
[POWERPC] pasemi: Export more SPRs to sysfs when CONFIG_DEBUG_KERNEL=y
[POWERPC] pasemi: Print more information at machine check
[POWERPC] pasemi: Move pasemi_idle_init() to late_initcall()
Patches also posted as replies to this email for general info.
Thanks,
Olof
^ permalink raw reply
* Re: Document and implement an improved flash device binding
From: David Gibson @ 2007-09-05 2:59 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <143067874eed1b4ee9c75d5272bb5958@kernel.crashing.org>
On Mon, Sep 03, 2007 at 12:23:34PM +0200, Segher Boessenkool wrote:
> >+ j) CFI or JEDEC memory-mapped NOR flash
> >
> > Flash chips (Memory Technology Devices) are often used for solid
> >state
> > file systems on embedded devices.
>
> Well, almost everything has a NOR flash on it, not just
> embedded boards ;-)
Well, true.
> >+ - bank-width : Width (in bytes) of the flash bank. Equal to the
> >+ device width times the number of interleaved chips.
> >+ - device-width : (optional) Width of a single flash chip. If
> >+ omitted, assumed to be equal to 'bank-width'.
>
> Let's have bank-width optional instead, it's more natural
> that way for the common case of just one chip. Or, you can
> say that either is optional.
No, I'm disinclined to do that since bank-width is the primary bit of
information that the driver needs.
> >+ flash@ff000000 {
> >+ compatible = "amd,am29lv128ml", "cfi-flash";
> >+ reg = <ff000000 01000000>;
> >+ bank-width = <4>;
>
> This is an 8/16-bit part, you need a device-width ;-)
Oops - that comes from grabbing a random flash name, combining it with
other example fragments without checking the details. Added a
device-width.
> Need #address-cells here for the child nodes:
Oops. Added #a and #s.
> >+ fs@0 {
> >+ reg = <0 f80000>;
> >+ };
>
> [big snip]
>
> >+ OpenBIOS@0 {
>
> This show immediately why node name = partition name won't
> work out. You're not supposed to start a node name with a
> capital like this.
According to which?
Nonetheless, I've added a label property, and used it for the ebony
tree.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Keep On Debugging You
From: Timur Tabi @ 2007-09-05 2:53 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
I wrote this last year in frustration with an out-of-order execution bug
I was trying to fix.
Keep On Debugging You
Sung to the tune of REO Speedwagon's "Keep on Loving' You"
You should've seen by the opcodes in the queue, baby
There was something missin'
You should known by the registers, too, maybe
But you were too busy bitchin'
You stalled ahead
But you never fed
Instead my instructions
All ended up switchin'
And though I know all flushes
Still I don't remember
Cause it was stwu way before lwzu
And they're still together
And I meant every line I wrote
When I wrote them in order I meant
That I wanted them in order
And I'm gonna keep on debugging you
Cause it's the only thing I'm paid to do
I don't have time to sleep
I just want to keep on debugging you
(solo)
And I meant every line I wrote
When I wrote them in order I meant
That I wanted them in order
(chorus)
--
Timur Tabi
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3225 bytes --]
^ permalink raw reply
* Re: [RFC] AmigaOne device tree source v2
From: David Gibson @ 2007-09-05 2:48 UTC (permalink / raw)
To: Gerhard Pircher; +Cc: linuxppc-dev
In-Reply-To: <20070904114945.303440@gmx.net>
On Tue, Sep 04, 2007 at 01:49:45PM +0200, Gerhard Pircher wrote:
>
> -------- Original-Nachricht --------
> > Datum: Tue, 4 Sep 2007 00:32:57 +0200
> > Von: Segher Boessenkool <segher@kernel.crashing.org>
> > An: "Gerhard Pircher" <gerhard_pircher@gmx.net>
> > CC: linuxppc-dev@ozlabs.org, David Gibson <david@gibson.dropbear.id.au>
> > Betreff: Re: [RFC] AmigaOne device tree source v2
>
> > PCI memory space sits on the PCI bus, not on the PCI host bridge,
> > so is not part of "reg" but is part of "ranges" here, since it is
> > direct mapped into the host's address space.
> That's right, but what about this example here (from a Pegasos II):
>
> /proc/device-tree/pci@80000000:
> name "pci"
> linux,phandle 0fc59260 (264606304)
> bus-range 00000000 00000000
> pci-bridge-number 00000000
> reg 80000000 40000000
> 8259-interrupt-acknowledge f1000cb4
> ranges 01000000 00000000 00000000 fe000000 00000000 00010000
> 02000000 00000000 80000000 80000000 00000000 40000000
> clock-frequency 01fca055 (33333333)
> #size-cells 00000002
> #address-cells 00000003
> device_type "pci"
>
> AFAIU the reg property overlaps the ranges property for the PCI memory
> space from 0x80000000 to 0xC0000000 or the CPU address space at the
> same location!? Would be good to know, why it was defined like this.
That looks totally bogus. Unlike Segher, I think there are a few
cases where overlapping reg and ranges can make sense (PCI bridges
where config space is accessed indirectly via MMIO registers which lie
in the legacy ISA IO space is an example). But this doesn't look like
such a case - it just looks like whoever did the device tree
misunderstood the distinction between reg and ranges.
> > PCI legacy I/O is not direct mapped: there is no legacy I/O on a
> > PowerPC system bus. So, it can not be mentioned in the "ranges"
> > property, but the PHB registers used to access it should be shown
> > in the "reg" property. It could be a simple linear window (it
> > sounds like it is here?), but it could for example also be implemented
> > via an address/data register pair.
Err... huh? The legacy IO space is assigned a block of addresses in
3-word "OF-PCI-space by the PCI binding. When that is translated into
an MMIO range by the bridge, there's no reason that can't be encoded
into the ranges property.
> Yes, it is a simple linear address window. I'll remove its address range
> from the reg property.
>
> > The order of the "reg" entries depends on the exact model of PCI
> > bridge, so a device binding for it has to be written.
> Only the Pegasos I and the AmigaOne use this PCI bridge. I guess it should
> be enough to check for the board type, but a compatible property doesn't
> hurt.
The whole damn point of the device tree is to avoid using this kind of
non-local information "I know what the board type is over there, so it
must be this PCI bridge over here". The node should have a compatible
property which is sufficient to select the right bridge driver.
I think this is typically badly done at the moment, simply because PCI
has historically been set up by the platform code, rather than by a
"host bridge driver" in the mould of other drivers. I don't see that
changing real soon, but that doesn't mean we shouldn't at least put
enough information in the device tree to make it possible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 3/6] Walnut DTS
From: David Gibson @ 2007-09-05 2:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070904074203.748030c7@weaponx.rchland.ibm.com>
On Tue, Sep 04, 2007 at 07:42:03AM -0500, Josh Boyer wrote:
> On Sun, 02 Sep 2007 08:59:44 -0500
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
[snip]
> > > > + POB0: opb {
> > > > + compatible = "ibm,opb";
> > >
> > > Need an opb-405gp here, too.
> >
> > Yep.
>
> Fixed.
>
> > > > + #address-cells = <1>;
> > > > + #size-cells = <1>;
> > > > + ranges = <0 ef600000 a00000>;
> > >
> > > Hrm... something we ought to clarify is the interpretation of the
> > > POB0_BEAR register with respect to the bridge's ranges property. For
> > > 440 I think the BEAR will need to be interpreted as an OPB address,
> > > rather than a PLB address, but I'm not sure if that will work here
> > > with the limited ranges property you have.
> >
> > Ok, I'll look at this.
>
> The BEAR will still be interpreted as a PLB address here as far as I
> can see. The ranges spans the entire OPB space. Am I missing
> something?
Ah, sorry, my mistake. I thought the BEAR register would encode an
OPB address rather than a PLB address (and thus, be only 32-bits wide
on 440). In fact it appears it does encode a PLB address (and is
split into BEARH and BEARL registers on 440).
Hrm.. I'm still slightly uneasy though. In my Ebony device tree, the
POB's ranges exists to embed the 32-bit OPB space into the 64-bit PLB
space by tacking on a 0x1 in bits 32:35. In your 405gp ranges, you're
describing just the address range used by OPB peripherals
(0xef600000-0xf0000000) as residing at address 0 in OPB-space.
Since the ranges will still generate the right physical addresses, I
guess it doesn't matter. But I'm not sure it meets the principle of
least surprise - since I think the documentation generally talks as
though addresses on the 405 OPB bus are identical to addreses on the
PLB.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: disable interrput under ppc?
From: Wang, Baojun @ 2007-09-05 2:00 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <388931546.05165@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 3778 bytes --]
On Wednesday 05 September 2007, you wrote:
> On Tue, 4 Sep 2007 13:24:33 -0500
>
> Scott Wood <scottwood@freescale.com> wrote:
> > On Tue, Sep 04, 2007 at 10:44:14AM +0800, Wang, Baojun wrote:
> > > hi, list
> > >
> > > How can I disable interrput like `cli' in x86?
> >
> > local_irq_disable().
> >
> > > I want the following code freeze the box but it doesn't, $MSR is
> > > altered however the box is still alive, how can I freeze the box like
> > > `cli' in x86? Thanks very much!
> >
> > Disabling interrupts doesn't freeze the machine by itself -- it depends
> > on what you do afterwards, which you didn't show.
I need to check whether the interrupt have been disabled already, so I'm
expected after local_irq_disable() ( __asm__ __volatile__ ("wrteei
0": : :"memory) ), the machine is dead but it doesn't.
> If you're using a BOOKE variant, there is a way to use the DBCR0
> register to set debug wait enable or something to basically hang the
> CPU until something external clears that bit. But why you would want
> to do that, I have no idea.
Sorry, I just want to check whether disable_irq/enable_irq is functioning.
> josh
I'm not really getting confused about the following code:
// Executing all pending events
while ((event = get_next_set_bit_and_clear
(pending, xm_root_domain -> events -> masked_events)) != -1) {
// An event pending when there is not any handler installed
// catching it??? it must be an error
//assert (xm_root_domain -> event_handler [event]);
if (!xm_root_domain -> events -> event_handler [event]) continue;
// Before executing an event handler, events' flag is disabled
// and the event is masked
printk(KERN_EMERG"sync_root_events: looping!\n");
set_bit (xm_root_domain -> events -> masked_events, event);
printk(KERN_EMERG"sync_root_events: looping 2!\n");
disable_events_flag (xm_root_domain);
printk(KERN_EMERG"sync_root_events: looping 3!\n");
printk(KERN_EMERG"hw_irq_disabled?: %d\n", hw_irq_disabled());
hw_enable_irq ();
printk(KERN_EMERG"sync_root_events: looping 4!\n");
// Here, the event handler is executed always
// with the same conditions, that is, event flag disabled
// and the executed event masked as well
(*xm_root_domain -> events -> event_handler[event])
(event, regs);
printk(KERN_EMERG"sync_root_events: looping 5!\n");
hw_disable_irq();
printk(KERN_EMERG"sync_root_events: looping 6!\n");
// Events flag is automatically enabled (iret emulation)
enable_events_flag (xm_root_domain);
}
hw_enable_irq() and hw_disable_irq() is exactly the same as
local_irq_enable()/local_irq_disable(), but the output shows while running
hw_eable_irq() (at that point irq is disabled), the rest of the code is
blocked, and I don't know why:
output:
[ 172.049381] sync_root_events: looping!
[ 172.053159] sync_root_events: looping 2!
[ 172.057094] sync_root_events: looping 3!
[ 172.061027] hw_irq_disabled?: 1
[ 172.997338] sync_root_events: looping!
[ 173.001095] sync_root_events: looping 2!
[ 173.005028] sync_root_events: looping 3!
[ 173.008961] hw_irq_disabled?: 1
I'm sorry If I'm asking a bad question, I'm not familiar with ppc/kernel
programming at this moment. Great thanks to Scott and josh for your reply.
Regards,
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 2/6] cuimage for Bamboo board
From: David Gibson @ 2007-09-05 1:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1188826931.3772.11.camel@localhost.localdomain>
On Mon, Sep 03, 2007 at 08:42:11AM -0500, Josh Boyer wrote:
> On Mon, 2007-09-03 at 11:01 +1000, David Gibson wrote:
> > On Fri, Aug 31, 2007 at 03:04:51PM -0500, Josh Boyer wrote:
> > > Add a cuboot wrapper for the Bamboo board. This also removes some obsoleted
> > > linker declarations that have been moved into ops.h
> > >
> > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> >
> > [snip]
> > > --- linux-2.6.orig/arch/powerpc/boot/bamboo.c
> > > +++ linux-2.6/arch/powerpc/boot/bamboo.c
> > > @@ -24,8 +24,7 @@
> > > #include "4xx.h"
> > > #include "44x.h"
> > >
> > > -extern char _dtb_start[];
> > > -extern char _dtb_end[];
> > > +static u8 *bamboo_mac0, *bamboo_mac1;
> > >
> > > static void bamboo_fixups(void)
> > > {
> > > @@ -34,12 +33,16 @@ static void bamboo_fixups(void)
> > > ibm440ep_fixup_clocks(sysclk, 11059200);
> > > ibm4xx_fixup_memsize();
> > > ibm4xx_quiesce_eth((u32 *)0xef600e00, (u32 *)0xef600f00);
> > > + if (bamboo_mac0 && bamboo_mac1)
> > > + dt_fixup_mac_addresses(bamboo_mac0, bamboo_mac1);
> >
> > Bit ugly that you only set the MAC address for any ethernet if they're
> > supplied for every ethernet.
>
> Good point. Will fix.
>
> > > simple_alloc_init(_end, avail_ram, 32, 64);
> > > - bamboo_init();
> > > + bamboo_init(NULL, NULL);
> >
> > There must surely be a way to get the MAC addresses out of OpenBIOS...
>
> Probably. I just need to find out where they are stored.
It's not buried somewhere in the arch/ppc/boot code?
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [patch 5/6] Walnut board support
From: David Gibson @ 2007-09-05 1:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20070904073741.1adab0ba@weaponx.rchland.ibm.com>
On Tue, Sep 04, 2007 at 07:37:41AM -0500, Josh Boyer wrote:
> On Sun, 02 Sep 2007 08:59:06 -0500
> Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:
>
> > On Mon, 2007-09-03 at 11:11 +1000, David Gibson wrote:
> > > On Fri, Aug 31, 2007 at 03:04:54PM -0500, Josh Boyer wrote:
> > > > Board support for the PPC405 Walnut evaluation board
> > > >
> > > > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> > >
> > > [snip]
> > > > --- linux-2.6.orig/arch/powerpc/platforms/40x/Kconfig
> > > > +++ linux-2.6/arch/powerpc/platforms/40x/Kconfig
> > > > @@ -53,13 +53,13 @@
> > > > # help
> > > > # This option enables support for the IBM PPC405GPr evaluation board.
> > > >
> > > > -#config WALNUT
> > > > -# bool "Walnut"
> > > > -# depends on 40x
> > > > -# default y
> > > > -# select 405GP
> > > > -# help
> > > > -# This option enables support for the IBM PPC405GP evaluation board.
> > > > +config WALNUT
> > > > + bool "Walnut"
> > > > + depends on 40x
> > > > + default y
> > > > + select 405GP
> > > > + help
> > > > + This option enables support for the IBM PPC405GP evaluation board.
> > >
> > > Surely this needs WANT_DEVICE_TREE, too.
> >
> > Yes, will be fixed.
>
> Er, actually no it won't. It doesn't need to be selected here, as 40x
> in arch/powerpc/platforms/Kconfig.cputype already selects
> WANT_DEVICE_TREE. Same thing that ebony and bamboo do for 44x.
Oh, yes, so it does, sorry. Though we may need to change that if
anyone goes and puts a real OF implementation on some 44x board.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: "atomic" 64-bit math on 32-bit ppc's?
From: David Gibson @ 2007-09-05 1:04 UTC (permalink / raw)
To: Matt Sealey; +Cc: ppc-dev
In-Reply-To: <46DD500B.4020207@genesi-usa.com>
On Tue, Sep 04, 2007 at 01:31:07PM +0100, Matt Sealey wrote:
>
> Gabriel Paubert wrote:
> > On Tue, Sep 04, 2007 at 12:09:22PM +0100, Matt Sealey wrote:
> >> Hi guys,
> >>
> >> The Solaris PPC code drop included most of these functions for 32-bit ops on
> >> 32-bit PPC architectures but the 64-bit operations are not present. What I
> >> a not clear on is the operation of lwarx and stwcx. and if they will work if
> >> you are doing operations on two words at a time.
> >
> > No. There is a single reservation for a single word.
>
> This is what I gathered from the programming environments manual at least.
>
> > the 64 bit operations inside a spinlock on PPC32, and then select the
> > number /location of spinlock(s) based on your needs, from one global
> > per machine to one per 64 bit variable if you find excessive contention.
>
> Okay that makes sense, but it would have to be a super global big lock,
> I don't think the code is there in ZFS to give every 64-bit variable it's
> own dedicated spinlock (kind of an overhaul) and I'm trying to be fast..
These aren't the only two options. You could use a hashed array of
locks, based on the address where you're doing the atomic operation.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [POWERPC] flags as passed to spin_*_irqsave() should be unsigned long.
From: Olof Johansson @ 2007-09-04 23:39 UTC (permalink / raw)
To: Tony Breeds; +Cc: LinuxPPC-dev
In-Reply-To: <20070905002314.GT10345@bakeyournoodle.com>
On Wed, Sep 05, 2007 at 10:23:14AM +1000, Tony Breeds wrote:
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
> Found trying to build a -rt kernel, which has a BUILD_BUG_ON(), in this
> caswe.
Thanks, applied. I'll batch it up with the next set of updates to jgarzik.
-Olof
^ permalink raw reply
* [POWERPC] flags as passed to spin_*_irqsave() should be unsigned long.
From: Tony Breeds @ 2007-09-05 0:23 UTC (permalink / raw)
To: LinuxPPC-dev, Olof Johansson
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
Found trying to build a -rt kernel, which has a BUILD_BUG_ON(), in this
caswe.
drivers/net/pasemi_mac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: working/drivers/net/pasemi_mac.c
===================================================================
--- working.orig/drivers/net/pasemi_mac.c 2007-09-04 16:46:40.000000000 +1000
+++ working/drivers/net/pasemi_mac.c 2007-09-04 16:47:01.000000000 +1000
@@ -524,7 +524,7 @@ static int pasemi_mac_clean_tx(struct pa
struct pasemi_mac_buffer *info;
struct pas_dma_xct_descr *dp;
int start, count;
- int flags;
+ unsigned long flags;
spin_lock_irqsave(&mac->tx->lock, flags);
@@ -950,7 +950,7 @@ static int pasemi_mac_start_tx(struct sk
struct pas_dma_xct_descr *dp;
u64 dflags;
dma_addr_t map;
- int flags;
+ unsigned long flags;
dflags = XCT_MACTX_O | XCT_MACTX_ST | XCT_MACTX_SS | XCT_MACTX_CRC_PAD;
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: [patch 1/2] PS3: Clear SPU Class 0 interrupts in handler
From: Arnd Bergmann @ 2007-09-04 22:50 UTC (permalink / raw)
To: Geoff Levand
Cc: Noguchi, Masato, linuxppc-dev@ozlabs.org, Paul Mackerras,
Jeremy Kerr
In-Reply-To: <46DD4777.8050402@am.sony.com>
On Tuesday 04 September 2007, Geoff Levand wrote:
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>=20
> Fix a bug that causes the PS3 to hang on the SPU Class 0 interrupt.
>=20
> The Cell BE Architecture spec states that the SPU MFC Class 0 interrupt
> is delivered as a pulse. =C2=A0The current spu interrupt handler assumes =
this
> behavior and does not clear the interrupt status.
>=20
> The PS3 hypervisor visualizes all SPU interrupts as level, and on return
> from the interrupt handler the hypervisor will deliver a new virtual
> interrupt for any unmasked interrupts which for which the status has not
> been cleared. =C2=A0This fix clears the interrupt status in the interrupt
> handler.
Right, we have this one in the sdk3.0/2.6.22-arnd2 kernel since I pulled
in all of the ps3-linux tree, so it was already part of our testing,
and the explanation makes sense, so we should certainly have it
upstream.
Jeremy, please add this to your patch queue.
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-04 22:42 UTC (permalink / raw)
To: Geoff Levand; +Cc: Masato Noguchi, linuxppc-dev@ozlabs.org, Paul Mackerras
In-Reply-To: <46DD4783.9040103@am.sony.com>
On Tuesday 04 September 2007, Geoff Levand wrote:
>
> From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
>
> Add platform specific SPU run control routines.
>
> The current spufs_run_spu() implementation uses the SPU master
> run control bit (MFC_SR1[S]) to control SPE execution, but the
> PS3 hypervisor does not support the use of this feature. This
> change adds run control wrapper routines. The bare metal
> routines use the master run control bit, and the PS3 specific
> routines use the priv2 run control register.
>
> Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Hmm, ok. Since I don't think we'll get to do the right solution
(unmapping the ps registers on the ps3) that soon, doing this
patch is at least better than the current situation where we
end up with an oops every time we leave spu_run.
It would probably be good to mention the remaining problem
with the current approach in the changelog and as a comment
in the ps3 specific functions.
> @@ -178,6 +179,8 @@ struct spu_management_ops {
> int (*enumerate_spus)(int (*fn)(void *data));
> int (*create_spu)(struct spu *spu, void *data);
> int (*destroy_spu)(struct spu *spu);
> + int (*enable_spu)(struct spu_context *ctx);
> + int (*disable_spu)(struct spu_context *ctx);
> int (*init_affinity)(void);
> };
Also, I think you should make the return type of the callback
'void' since the result is not used anywhere.
Arnd <><
^ permalink raw reply
* Re: [patch 2/2] Cell: Wrap master run control bit
From: Arnd Bergmann @ 2007-09-04 22:44 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Masato Noguchi, Paul Mackerras, Jeremy Kerr
In-Reply-To: <200709050042.13926.arnd@arndb.de>
On Wednesday 05 September 2007, Arnd Bergmann wrote:
> On Tuesday 04 September 2007, Geoff Levand wrote:
> >=20
> > From: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> >=20
> > Add platform specific SPU run control routines.
> >=20
> > The current spufs_run_spu() implementation uses the SPU master
> > run control bit (MFC_SR1[S]) to control SPE execution, but the
> > PS3 hypervisor does not support the use of this feature. =A0This
> > change adds run control wrapper routines. =A0The =A0bare metal
> > routines use the master run control bit, and the PS3 specific
> > routines use the priv2 run control register.
> >=20
> > Signed-off-by: Masato Noguchi <Masato.Noguchi@jp.sony.com>
> > Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
One more thing, please send spufs related patches to Jeremy instead
of to me. I'm happy to give advice on the patch contents, but
since Jeremy has taken over maintainership of spufs, merging a
patch is his decision in the end.
Arnd <><
^ permalink raw reply
* Re: Newbie on embedded linux on PPC: error: cannot find boot.o
From: Wolfgang Reissnegger @ 2007-09-04 21:33 UTC (permalink / raw)
To: Thomas Gerlach; +Cc: linuxppc-embedded
In-Reply-To: <46DD65BF.5090304@kip.uni-heidelberg.de>
Hi Thomas,
Xilinx is building the tools in the EDK to work with VxWorks and for Standalone systems. In order to compile a Linux kernel you need to get a toolchain from one of the Third Party vendors, such as MontaVista. They have the correct linker scripts for building a kernel.
Cheers,
Wolfgang
Thomas Gerlach wrote:
> hi folks,
>
>
> my name is thomas trying to make embedded linux run on a powerpc, but
> we've got special boards here, although we use a xilinx virtex4
> fpga...
>
> as you said in the nabble-thread (see subject), i set up edk9.1
> software platform settings und ran libgen to get the xparameters*
> files. i copied those bsp files into the kernel tree (i use your
> kernel linux-2.6-virtex from git.secretlabs.ca/git). after
> configuring the kernel settigs, i try
>
> $ make ARCH=ppc CROSS_COMPILE=powerpc-eabi-
>
> what i get is the following output:
>
>> CHK include/linux/version.h
>> CHK include/linux/utsrelease.h
>> CALL scripts/checksyscalls.sh
>> CHK include/linux/compile.h
>> LD init/mounts.o
>> powerpc-eabi-ld: cannot find boot.o
>> make[1]: *** [init/mounts.o] Error 1
>> make: *** [init] Error 2
>
> so, i searched for boot.o (it exists) and even copied it into several
> dirs of the linux kernel tree (where i thought i would make sense),
> but the problem still remains.
>
> googling results in
>
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&getPagePath=17462&BV_SessionID=@@@@1197140711.1188909240@@@@&BV_EngineID=cccgaddllgmfkflcefeceihdffhdfkf.0
>
>
> and this, too, doesn't take me further in solving the problem.
>
> i hope you can help me.
>
> many thanks in advance,
>
> kind regards
> thomas gerlach
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH 4/9] cpm2: Add cpm2_set_pin().
From: Vitaly Bordug @ 2007-09-04 20:51 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070828201924.GD24329@ld0162-tx32.am.freescale.net>
On Tue, 28 Aug 2007 15:19:24 -0500
Scott Wood wrote:
> This provides a generic way for board code to set up CPM pins, rather
> than directly poking magic values into registers.
>
Please provide more info either here or somewhere in Documentation/, or inside the code at least.
We're adding new utility function here, and need to describe in a nutshell now the thing works.
This is completely self-explanatory for limited amount of people, I mean.
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/sysdev/cpm2_common.c | 33
> +++++++++++++++++++++++++++++++++ include/asm-powerpc/cpm2.h
> | 9 +++++++++ 2 files changed, 42 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/sysdev/cpm2_common.c
> b/arch/powerpc/sysdev/cpm2_common.c index 549da4b..b8460c0 100644
> --- a/arch/powerpc/sysdev/cpm2_common.c
> +++ b/arch/powerpc/sysdev/cpm2_common.c
> @@ -418,3 +418,36 @@ void *cpm_dpram_addr(unsigned long offset)
> return (void __force *)(im_dprambase + offset);
> }
> EXPORT_SYMBOL(cpm_dpram_addr);
> +
> +struct cpm2_ioports {
> + u32 dir, par, sor, odr, dat;
> + u32 res[3];
> +};
> +
> +void cpm2_set_pin(int port, int pin, int flags)
> +{
> + struct cpm2_ioports __iomem *iop =
> + (struct cpm2_ioports __iomem *)&cpm2_immr->im_ioport;
> +
> + pin = 1 << (31 - pin);
> +
> + if (flags & CPM_PIN_OUTPUT)
> + setbits32(&iop[port].dir, pin);
> + else
> + clrbits32(&iop[port].dir, pin);
> +
> + if (!(flags & CPM_PIN_GPIO))
> + setbits32(&iop[port].par, pin);
> + else
> + clrbits32(&iop[port].par, pin);
> +
> + if (flags & CPM_PIN_SECONDARY)
> + setbits32(&iop[port].sor, pin);
> + else
> + clrbits32(&iop[port].sor, pin);
> +
> + if (flags & CPM_PIN_OPENDRAIN)
> + setbits32(&iop[port].odr, pin);
> + else
> + clrbits32(&iop[port].odr, pin);
> +}
> diff --git a/include/asm-powerpc/cpm2.h b/include/asm-powerpc/cpm2.h
> index 41a45db..d7b57ac 100644
> --- a/include/asm-powerpc/cpm2.h
> +++ b/include/asm-powerpc/cpm2.h
> @@ -1247,5 +1247,14 @@ enum cpm_clk {
> extern int cpm2_clk_setup(enum cpm_clk_target target, int clock, int
> mode); extern int cpm2_smc_clk_setup(enum cpm_clk_target target, int
> clock);
> +#define CPM_PIN_INPUT 0
> +#define CPM_PIN_OUTPUT 1
> +#define CPM_PIN_PRIMARY 0
> +#define CPM_PIN_SECONDARY 2
> +#define CPM_PIN_GPIO 4
> +#define CPM_PIN_OPENDRAIN 8
> +
> +void cpm2_set_pin(int port, int pin, int flags);
> +
> #endif /* __CPM2__ */
> #endif /* __KERNEL__ */
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH 3/9] cpm2: Add SCCs to cpm2_clk_setup(), and cpm2_smc_clk_setup().
From: Vitaly Bordug @ 2007-09-04 20:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070830201500.GB5144@ld0162-tx32.am.freescale.net>
On Thu, 30 Aug 2007 15:15:00 -0500
Scott Wood wrote:
> On Thu, Aug 30, 2007 at 02:25:48AM +0400, Vitaly Bordug wrote:
> > I would have it in the same patch, that adds clocking stuff to 8xx.
>
> I was trying to keep the 8xx and 82xx patchsets reasonably separate.
>
> > And maybe in the same, segregate source rather then having it in the
> > foo_common.c, to ease fix/update/rework.
>
> I'm not sure I understand what you mean -- where do you want the code
> to go?
>
Thinking once again about this, It looks good the way it is, another way is prolly overkill so nm.
--
Sincerely, Vitaly
^ permalink raw reply
* Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
From: Vitaly Bordug @ 2007-09-04 20:15 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Timur Tabi
In-Reply-To: <20070904182028.GC18280@ld0162-tx32.am.freescale.net>
On Tue, 4 Sep 2007 13:20:28 -0500
Scott Wood wrote:
> > > _and system GPIOs_ :-)
> >
> > Yup, firmware should set up gpios, to make initial kernel boot.
>
> No, it should set all pins and similar setup-once type initialization
> that is board-specific rather than device-specific -- there's no
> reason for the kernel to need to care about that sort of thing.
>
> > After that, kernel can and should manage GPIOs. Few examples.
> >
> > Say units (like USB or SPI) can work in very different modes. And
> > it's okay if user want to change device mode in the runtime.
>
> This is a special case that warrants kernel involvement. It should
> not be used as justification for the bootloader leaving pins
> unconfigured in the majority of cases where it does not make sense to
> change them at runtime.
>
This argue is useless: both opinions have same weight. Firmware is able to provide meaningful default gpio setup, and nobody
will object. The point is, that blindly assume all the low-level stuff is fine, you are able only in case you've developed respective bits in the firmware.
More usual case is additional overhead of checking if the firmware not attempting to do something not really wanted, so we'll
always have a tradeoff.
--
Sincerely, Vitaly
^ permalink raw reply
* Problems with MPC8272ADS
From: Manil Gaouar @ 2007-09-04 19:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 396 bytes --]
Hi,
I am a bit newbie in this. I tried compiling Linux 2.4 using
ADS8272_deconfig from the kernel 2.6 and I have many compilation errors.
Are the deconfig files from 2.4 to 2.6 that different, or can I use the
2.6 file with little changes???
I don't understand why there is support for this board in 2.6 and not in
2.4, since Denx recommend 2.4.
Thx for your help!
[-- Attachment #2: Type: text/html, Size: 2241 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox