Re: Hardware debuggers for PPC74xx G4 CPUs
Original-Nachricht Datum: Wed, 14 Nov 2007 12:17:09 +1100 Von: Benjamin Herrenschmidt [EMAIL PROTECTED] An: Gerhard Pircher [EMAIL PROTECTED] CC: Jon Smirl [EMAIL PROTECTED], [EMAIL PROTECTED], linuxppc-dev@ozlabs.org Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs On Tue, 2007-11-13 at 23:21 +0100, Gerhard Pircher wrote: Original-Nachricht Datum: Tue, 13 Nov 2007 17:10:29 -0500 Von: Jon Smirl [EMAIL PROTECTED] An: Grant Likely [EMAIL PROTECTED] CC: Gerhard Pircher [EMAIL PROTECTED], linuxppc-dev@ozlabs.org Betreff: Re: Hardware debuggers for PPC74xx G4 CPUs Here are the choices: http://www.macraigor.com/cpus.htm Looks like the Abatron BDI-2000 is the cheapest hardware debugger that supports 74xx G4 CPUs. :-( Do you have the appropriate connector for it on the motherboard as well ? If not, then you are out of luck... Ben. Yes, the connector is on the CPU module. Gerhard -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote: Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache prefetch engines (I don't care about the performance loss). I couldn't find any other code that sets the M bit, except for huge TLB page support, but isn't that only for PPC64? Right, it's only 64 bits. You've double checked nothing broke the M bit thing ? In which case, I don't know what else... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
Original-Nachricht Datum: Wed, 14 Nov 2007 10:37:52 +1100 Von: Benjamin Herrenschmidt [EMAIL PROTECTED] An: Gerhard Pircher [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org Betreff: Re: Kernel locks up after calling kernel_execve() Add printk's to things :-) It's a UP kernel so there should be no spinlocks anyway. Best is to try to get a 100% reprocase and printk your way toward the origin of the problem if you don't have a HW debugger. Unless you manage to sneak in an irq to xmon but if you are totally locked up, you probably can't. Also xmon seems to lockup the machine. I was able to active it through the magic sysrq key, but the machine died afterwards. Could also be something you do that your buggy northbridge doesn't like. For example, maybe it dislikes M bit in the hash table and you end up with it set due to other reasons (I know we had changes in this area). Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache prefetch engines (I don't care about the performance loss). I couldn't find any other code that sets the M bit, except for huge TLB page support, but isn't that only for PPC64? Gerhard -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Kernel locks up after calling kernel_execve()
Original-Nachricht Datum: Wed, 14 Nov 2007 21:04:57 +1100 Von: Benjamin Herrenschmidt [EMAIL PROTECTED] An: Gerhard Pircher [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org Betreff: Re: Kernel locks up after calling kernel_execve() On Wed, 2007-11-14 at 10:39 +0100, Gerhard Pircher wrote: Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache prefetch engines (I don't care about the performance loss). I couldn't find any other code that sets the M bit, except for huge TLB page support, but isn't that only for PPC64? Right, it's only 64 bits. You've double checked nothing broke the M bit thing ? In which case, I don't know what else... Yes, I did. Otherwise the machine dies much earlier in the boot process. Gerhard -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
This patch adds support for 'mpc5200-simple-platform' compatible
boards which do not need a platform specific setup. Such boards
are supported assuming the following:
- GPIO pins are configured by the firmware,
- CDM configuration (clocking) is setup correctly by firmware,
- if the 'fsl,has-wdt' property is present in one of the
gpt nodes, then it is safe to use such gpt to reset the board,
- PCI is supported if enabled in the kernel configuration
and if there is a PCI bus node defined in the device tree.
Signed-off-by: Marian Balakowicz [EMAIL PROTECTED]
---
This is a updated version of the patch 04/13 from the patchset that
adds arch/powerpc support for three MPC5200 based boards:
TQ-Components TQM5200, Schindler CM5200 and Promess Motion-PRO.
Supported boards table was made static __initdata and
sorted alphabetically.
Cheers,
Marian Balakowicz
arch/powerpc/boot/dts/lite5200.dts |2 -
arch/powerpc/boot/dts/lite5200b.dts |2 -
arch/powerpc/platforms/52xx/Kconfig | 22 ++-
arch/powerpc/platforms/52xx/Makefile |1
arch/powerpc/platforms/52xx/mpc5200_simple.c | 84 ++
5 files changed, 107 insertions(+), 4 deletions(-)
create mode 100644 arch/powerpc/platforms/52xx/mpc5200_simple.c
diff --git a/arch/powerpc/boot/dts/lite5200.dts
b/arch/powerpc/boot/dts/lite5200.dts
index 6731763..5902362 100644
--- a/arch/powerpc/boot/dts/lite5200.dts
+++ b/arch/powerpc/boot/dts/lite5200.dts
@@ -19,7 +19,7 @@
/ {
model = fsl,lite5200;
// revision = 1.0;
- compatible = fsl,lite5200,generic-mpc5200;
+ compatible = fsl,lite5200;
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/powerpc/boot/dts/lite5200b.dts
b/arch/powerpc/boot/dts/lite5200b.dts
index b540388..b509129 100644
--- a/arch/powerpc/boot/dts/lite5200b.dts
+++ b/arch/powerpc/boot/dts/lite5200b.dts
@@ -19,7 +19,7 @@
/ {
model = fsl,lite5200b;
// revision = 1.0;
- compatible = fsl,lite5200b,generic-mpc5200;
+ compatible = fsl,lite5200b;
#address-cells = 1;
#size-cells = 1;
diff --git a/arch/powerpc/platforms/52xx/Kconfig
b/arch/powerpc/platforms/52xx/Kconfig
index 2938d49..36e880b 100644
--- a/arch/powerpc/platforms/52xx/Kconfig
+++ b/arch/powerpc/platforms/52xx/Kconfig
@@ -19,6 +19,26 @@ config PPC_MPC5200_BUGFIX
It is safe to say 'Y' here
+config PPC_MPC5200_SIMPLE
+ bool Generic support for simple MPC5200 based boards
+ depends on PPC_MULTIPLATFORM PPC32
+ select PPC_MPC5200
+ default n
+ help
+ This option enables support for a simple MPC52xx based boards which
+ do not need a custom platform specific setup. Such boards are
+ supported assuming the following:
+
+ - GPIO pins are configured by the firmware,
+ - CDM configuration (clocking) is setup correctly by firmware,
+ - if the 'fsl,has-wdt' property is present in one of the
+ gpt nodes, then it is safe to use such gpt to reset the board,
+ - PCI is supported if enabled in the kernel configuration
+ and if there is a PCI bus node defined in the device tree.
+
+ Boards that are compatible with this generic platform support
+ are: 'tqc,tqm5200', 'promess,motionpro', 'schindler,cm5200'.
+
config PPC_EFIKA
bool bPlan Efika 5k2. MPC5200B based computer
depends on PPC_MULTIPLATFORM PPC32
@@ -34,5 +54,3 @@ config PPC_LITE5200
select WANT_DEVICE_TREE
select PPC_MPC5200
default n
-
-
diff --git a/arch/powerpc/platforms/52xx/Makefile
b/arch/powerpc/platforms/52xx/Makefile
index 307dbc1..fe1b81b 100644
--- a/arch/powerpc/platforms/52xx/Makefile
+++ b/arch/powerpc/platforms/52xx/Makefile
@@ -6,6 +6,7 @@ obj-y += mpc52xx_pic.o
mpc52xx_common.o
obj-$(CONFIG_PCI) += mpc52xx_pci.o
endif
+obj-$(CONFIG_PPC_MPC5200_SIMPLE) += mpc5200_simple.o
obj-$(CONFIG_PPC_EFIKA)+= efika.o
obj-$(CONFIG_PPC_LITE5200) += lite5200.o
diff --git a/arch/powerpc/platforms/52xx/mpc5200_simple.c
b/arch/powerpc/platforms/52xx/mpc5200_simple.c
new file mode 100644
index 000..049c03d
--- /dev/null
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
@@ -0,0 +1,84 @@
+/*
+ * Support for 'mpc5200-simple-platform' compatible boards.
+ *
+ * Written by Marian Balakowicz [EMAIL PROTECTED]
+ * Copyright (C) 2007 Semihalf
+ *
+ * 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.
+ *
+ * Description:
+ * This code implements support for a simple MPC52xx based boards which
+ * do not need a custom platform specific setup. Such boards are
+ * supported assuming the following:
+ *
+ * - GPIO pins are configured by the
[PATCH] 2.6.24-rc2-mm1 powerpc (iseries)- build failure - mm/stab.c
Hi Andrew,
The kernel builds fails with following error, with randconfig
CC arch/powerpc/mm/stab.o
arch/powerpc/mm/stab.c: In function ‘stab_initialize’:
arch/powerpc/mm/stab.c:282: error: implicit declaration of function ‘HvCall1’
arch/powerpc/mm/stab.c:282: error: ‘HvCallBaseSetASR’ undeclared (first use in
this function)
arch/powerpc/mm/stab.c:282: error: (Each undeclared identifier is reported only
once
arch/powerpc/mm/stab.c:282: error: for each function it appears in.)
make[1]: *** [arch/powerpc/mm/stab.o] Error 1
make: *** [arch/powerpc/mm] Error 2
Signed-off-by: Kamalesh Babulal [EMAIL PROTECTED]
--
--- linux-2.6.24-rc2/arch/powerpc/mm/stab.c 2007-11-14 05:22:55.0
-0500
+++ linux-2.6.24-rc2/arch/powerpc/mm/~stab.c2007-11-14 05:23:18.0
-0500
@@ -21,6 +21,10 @@
#include asm/abs_addr.h
#include asm/firmware.h
+#ifdef CONFIG_PPC_ISERIES
+#include asm/iseries/hv_call.h
+#endif /* CONFIG_PPC_ISERIES */
+
struct stab_entry {
unsigned long esid_data;
unsigned long vsid_data;
--
Thanks Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: printk/console_init - baud rate setting
I am getting garbage on the screen. So, I presume this must be some sort of baud rate issue. Can some one help me out understand how this baud is set for serial drivers? I want to run at 115200. console=ttyS0,115200 See Documentation/kernel-parameters.txt; depending on exactly what early console you are using, that one might have it hardcoded. Have a look around. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
This patch makes PowerPC 4xx UIC use generic edge and level irq handlers
instead of a custom handle_uic_irq() function. Acking a level irq on UIC
has no effect if the interrupt is still asserted by the device, even if
the interrupt is already masked. So, to really de-assert the interrupt
we need to de-assert the external source first *and* ack it on UIC then.
The handle_level_irq() function masks and ack's the interrupt with mask_ack
callback prior to calling the actual ISR and unmasks it at the end.
So, to use it with UIC level interrupts we need to ack in the unmask
callback instead, after the ISR has de-asserted the external interrupt source.
Even if we ack the interrupt that we didn't handle (unmask/ack it at
the end of the handler, while next irq is already pending) it will not
de-assert the irq, untill we de-assert its exteral source.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/sysdev/uic.c | 89 --
1 files changed, 24 insertions(+), 65 deletions(-)
--- linux-2.6/arch/powerpc/sysdev/uic.c 2007-11-13 22:28:01.0 +0300
+++ linux-2.6.o/arch/powerpc/sysdev/uic.c 2007-11-13 22:27:20.0
+0300
@@ -60,14 +60,19 @@ struct uic {
static void uic_unmask_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
- u32 er;
+ u32 er, sr;
+ sr = 1 (31-src);
spin_lock_irqsave(uic-lock, flags);
+ /* ack level interrupts here */
+ if (desc-status IRQ_LEVEL)
+ mtdcr(uic-dcrbase + UIC_SR, sr);
er = mfdcr(uic-dcrbase + UIC_ER);
- er |= 1 (31 - src);
+ er |= sr;
mtdcr(uic-dcrbase + UIC_ER, er);
spin_unlock_irqrestore(uic-lock, flags);
}
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
static void uic_mask_ack_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
er = mfdcr(uic-dcrbase + UIC_ER);
er = ~sr;
mtdcr(uic-dcrbase + UIC_ER, er);
- mtdcr(uic-dcrbase + UIC_SR, sr);
+ /* on the uic, acking (i.e. clearing the sr bit)
+* a level irq will have no effect if the interrupt
+* is still asserted by the device, even if
+* the interrupt is already masked. therefore
+* we only ack the egde interrupts here, while
+* level interrupts are ack'ed after the actual
+* isr call in the uic_unmask_irq()
+*/
+ if (!(desc-status IRQ_LEVEL))
+ mtdcr(uic-dcrbase + UIC_SR, sr);
spin_unlock_irqrestore(uic-lock, flags);
}
@@ -156,8 +171,11 @@ static int uic_set_irq_type(unsigned int
desc-status = ~(IRQ_TYPE_SENSE_MASK | IRQ_LEVEL);
desc-status |= flow_type IRQ_TYPE_SENSE_MASK;
- if (!trigger)
+ if (!trigger) {
desc-status |= IRQ_LEVEL;
+ set_irq_handler(virq, handle_level_irq);
+ } else
+ set_irq_handler(virq, handle_edge_irq);
spin_unlock_irqrestore(uic-lock, flags);
@@ -173,73 +191,14 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
-/**
- * handle_uic_irq - irq flow handler for UIC
- * @irq: the interrupt number
- * @desc: the interrupt description structure for this irq
- *
- * This is modified version of the generic handle_level_irq() suitable
- * for the UIC. On the UIC, acking (i.e. clearing the SR bit) a level
- * irq will have no effect if the interrupt is still asserted by the
- * device, even if the interrupt is already masked. Therefore, unlike
- * the standard handle_level_irq(), we must ack the interrupt *after*
- * invoking the ISR (which should have de-asserted the interrupt in
- * the external source). For edge interrupts we ack at the beginning
- * instead of the end, to keep the window in which we can miss an
- * interrupt as small as possible.
- */
-void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
-{
- unsigned int cpu = smp_processor_id();
- struct irqaction *action;
- irqreturn_t action_ret;
-
- spin_lock(desc-lock);
- if (desc-status IRQ_LEVEL)
- desc-chip-mask(irq);
- else
- desc-chip-mask_ack(irq);
-
- if (unlikely(desc-status IRQ_INPROGRESS))
- goto out_unlock;
- desc-status = ~(IRQ_REPLAY | IRQ_WAITING);
- kstat_cpu(cpu).irqs[irq]++;
-
- /*
-* If its disabled or no action available
-* keep it masked and get out of here
-*/
- action = desc-action;
- if (unlikely(!action || (desc-status IRQ_DISABLED))) {
-
Re: [PATCH 2/2] PowerPC: make 4xx uic use generic edge and level irq handlers
Benjamin Herrenschmidt wrote: On Wed, 2007-11-14 at 13:13 +1100, David Gibson wrote: Hrm. I *think* I'm convinced this is safe, although acking in a callback which doesn't say it acks is rather yucky. Essentially this code is trading flow readability (because just reading handle_level_irq will tell you something other than what it does in our case) for smaller code size. I'm not sure if this is a good trade or not. It's not just code size. Actually, I was having problems with Ingo's real-time patch, that works on all platforms that use generic hard irq handlers and doesn't work just on 4xx since we use a custom one here. And I thought that using generic handlers would be easier to maintain. I agree that ack'ing in a callback which doesn't say it ack's looks odd, but ack'ing level-triggered interrupts is quirky on UIC itself. So, I just thought that adding a couple of quirks to mask_ack and unmask callbacks was not that bad. There's also one definite problem: according to the discussions I had with Thomas Gleixner when I wrote uic.c, handle_edge_irq is not what we want for edge interrupts. Apparently handle_edge_irq is only for edge interrupts on broken PICs which won't latch new interrupts while the irq is masked. UIC is not in this category, so handle_level_irq is actually what we want, even for an edge irq. Yes, I thought the naming was more than a little confusing, too. Hrm... handle_edge_irq works for both and you have a small performance benefit in not masking, and thus using handle_edge_irq, so I don't totally agree here. Basically, what handle_edge_irq() does is lazy masking. Now there -is- an issue here is that if you do lazy masking, you need to be able to re-emit in some convenient way. With the ack quirks added we can use handle_level_irq for edge-triggered interrupts. I'll test and resubmit the patch. Ben. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] PMU: replace information ioctls and schedule for removal
This patch adds sysfs attributes to the PMU to allow getting
the information on the PMU type and whether adb is present from
there instead of via the ioctl. The ioctl is made optional and
scheduled for removal.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
v2 adds the firmware version to sysfs.
Documentation/feature-removal-schedule.txt |8
drivers/macintosh/Kconfig | 11 ++
drivers/macintosh/via-pmu.c| 48 +
3 files changed, 67 insertions(+)
--- everything.orig/drivers/macintosh/via-pmu.c 2007-11-13 19:32:37.618723850
+0100
+++ everything/drivers/macintosh/via-pmu.c 2007-11-13 19:35:43.718712837
+0100
@@ -2533,10 +2533,12 @@ pmu_ioctl(struct inode * inode, struct f
#endif /* CONFIG_INPUT_ADBHID */
#endif /* CONFIG_PMAC_BACKLIGHT_LEGACY */
+#ifdef CONFIG_DEPRECATED_PMU_INFO_IOCTLS
case PMU_IOC_GET_MODEL:
return put_user(pmu_kind, argp);
case PMU_IOC_HAS_ADB:
return put_user(pmu_has_adb, argp);
+#endif
}
return error;
}
@@ -2680,6 +2682,51 @@ static int pmu_sys_resume(struct sys_dev
#endif /* CONFIG_PM_SLEEP CONFIG_PPC32 */
+static ssize_t show_kind(struct sys_device *sysdev, char *buf)
+{
+ return sprintf(buf, %d\n, pmu_kind);
+}
+
+static ssize_t show_has_adb(struct sys_device *sysdev, char *buf)
+{
+ return sprintf(buf, %d\n, pmu_has_adb);
+}
+
+static ssize_t show_pmu_version(struct sys_device *sysdev, char *buf)
+{
+ return sprintf(buf, %d\n, pmu_version);
+}
+
+static SYSDEV_ATTR(kind, 0444, show_kind, NULL);
+static SYSDEV_ATTR(has_adb, 0444, show_has_adb, NULL);
+static SYSDEV_ATTR(firmware_version, 0444, show_pmu_version, NULL);
+
+int pmu_sys_add(struct sys_device *sysdev)
+{
+ int err;
+
+ err = sysdev_create_file(sysdev, attr_kind);
+ if (err)
+ goto out;
+
+ err = sysdev_create_file(sysdev, attr_has_adb);
+ if (err)
+ goto out_remove_kind;
+
+ err = sysdev_create_file(sysdev, attr_firmware_version);
+ if (err)
+ goto out_remove_adb;
+
+ return 0;
+
+ out_remove_adb:
+ sysdev_remove_file(sysdev, attr_has_adb);
+ out_remove_kind:
+ sysdev_remove_file(sysdev, attr_kind);
+ out:
+ return err;
+}
+
static struct sysdev_class pmu_sysclass = {
set_kset_name(pmu),
};
@@ -2693,6 +2740,7 @@ static struct sysdev_driver driver_pmu =
.suspend= pmu_sys_suspend,
.resume = pmu_sys_resume,
#endif /* CONFIG_PM_SLEEP CONFIG_PPC32 */
+ .add= pmu_sys_add,
};
static int __init init_pmu_sysfs(void)
--- everything.orig/Documentation/feature-removal-schedule.txt 2007-11-13
19:31:42.458723687 +0100
+++ everything/Documentation/feature-removal-schedule.txt 2007-11-13
19:32:40.728716851 +0100
@@ -342,3 +342,11 @@ Why: This driver has been marked obsolet
Who: Stephen Hemminger [EMAIL PROTECTED]
---
+
+What: /dev/pmu information ioctls
+When: January 2010
+Files: drivers/macintosh/via-pmu.c
+Why: The PMU information can be obtained from sysfs now.
+Who: Johannes Berg [EMAIL PROTECTED]
+
+---
--- everything.orig/drivers/macintosh/Kconfig 2007-11-13 19:31:42.388718641
+0100
+++ everything/drivers/macintosh/Kconfig2007-11-13 19:32:40.728716851
+0100
@@ -87,6 +87,17 @@ config ADB_PMU
this device; you should do so if your machine is one of those
mentioned above.
+config DEPRECATED_PMU_INFO_IOCTLS
+ bool Support deprecated PMU information ioctl
+ depends on ADB_PMU
+ default y
+ help
+ The PMU ioctl supports getting information on the type of PMU and
+ whether an ADB is present. This information is also available in
+ sysfs so this ioctl is no longer needed.
+
+ If in doubt, say Y even if you will not use the ioctl.
+
config ADB_PMU_LED
bool Support for the Power/iBook front LED
depends on ADB_PMU
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powermac: proper sleep management
This adds platform_suspend_ops for PMU based machines, directly in
the PMU driver. This finally allows suspending via /sys/power/state
on powerbooks.
The patch also replaces the PMU ioctl with a simple call to
pm_suspend(PM_SUSPEND_MEM) and puts the sleep-related PMU ioctls onto
the feature-removal schedule, to be removed in early 2010 (just
over two years from now).
Additionally, it cleans up some debug code.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Documentation/feature-removal-schedule.txt | 10
drivers/macintosh/Kconfig | 12
drivers/macintosh/via-pmu.c| 462 +
3 files changed, 241 insertions(+), 243 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2007-11-13 20:16:51.196263726
+0100
+++ everything/drivers/macintosh/via-pmu.c 2007-11-13 20:24:29.056252331
+0100
@@ -10,13 +10,13 @@
*
* Copyright (C) 1998 Paul Mackerras and Fabio Riccardi.
* Copyright (C) 2001-2002 Benjamin Herrenschmidt
+ * Copyright (C) 2006-2007 Johannes Berg
*
* THIS DRIVER IS BECOMING A TOTAL MESS !
* - Cleanup atomically disabling reply to PMU events after
*a sleep or a freq. switch
- * - Move sleep code out of here to pmac_pm, merge into new
- *common PM infrastructure
- * - Save/Restore PCI space properly
+ * - check if powerbook 3400 really needs the extra PCI
+ *save/restore code we have
*
*/
#include stdarg.h
@@ -64,7 +64,7 @@
#include via-pmu-event.h
/* Some compile options */
-#define DEBUG_SLEEP
+#undef DEBUG_SLEEP
/* Misc minor number allocated for /dev/pmu */
#define PMU_MINOR 154
@@ -149,12 +149,9 @@ static spinlock_t pmu_lock;
static u8 pmu_intr_mask;
static int pmu_version;
static int drop_interrupts;
-#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) defined(CONFIG_PPC32)
static int option_lid_wakeup = 1;
-#endif /* CONFIG_PM_SLEEP CONFIG_PPC32 */
-#if
(defined(CONFIG_PM_SLEEP)defined(CONFIG_PPC32))||defined(CONFIG_PMAC_BACKLIGHT_LEGACY)
-static int sleep_in_progress;
-#endif
+#endif /* CONFIG_SUSPEND CONFIG_PPC32 */
static unsigned long async_req_locks;
static unsigned int pmu_irq_stats[11];
@@ -220,7 +217,7 @@ extern void enable_kernel_fp(void);
#ifdef DEBUG_SLEEP
int pmu_polled_request(struct adb_request *req);
-int pmu_wink(struct adb_request *req);
+void pmu_blink(int n);
#endif
/*
@@ -871,7 +868,7 @@ proc_read_options(char *page, char **sta
{
char *p = page;
-#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) defined(CONFIG_PPC32)
if (pmu_kind == PMU_KEYLARGO_BASED
pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) = 0)
p += sprintf(p, lid_wakeup=%d\n, option_lid_wakeup);
@@ -912,7 +909,7 @@ proc_write_options(struct file *file, co
*(val++) = 0;
while(*val == ' ')
val++;
-#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) defined(CONFIG_PPC32)
if (pmu_kind == PMU_KEYLARGO_BASED
pmac_call_feature(PMAC_FTR_SLEEP_STATE,NULL,0,-1) = 0)
if (!strcmp(label, lid_wakeup))
@@ -1718,7 +1715,7 @@ pmu_present(void)
return via != 0;
}
-#if defined(CONFIG_PM_SLEEP) defined(CONFIG_PPC32)
+#if defined(CONFIG_SUSPEND) defined(CONFIG_PPC32)
/*
* This struct is used to store config register values for
* PCI devices which may get powered off when we sleep.
@@ -1821,42 +1818,6 @@ pbook_pci_restore(void)
}
}
-#ifdef DEBUG_SLEEP
-/* N.B. This doesn't work on the 3400 */
-void
-pmu_blink(int n)
-{
- struct adb_request req;
-
- memset(req, 0, sizeof(req));
-
- for (; n 0; --n) {
- req.nbytes = 4;
- req.done = NULL;
- req.data[0] = 0xee;
- req.data[1] = 4;
- req.data[2] = 0;
- req.data[3] = 1;
- req.reply[0] = ADB_RET_OK;
- req.reply_len = 1;
- req.reply_expected = 0;
- pmu_polled_request(req);
- mdelay(50);
- req.nbytes = 4;
- req.done = NULL;
- req.data[0] = 0xee;
- req.data[1] = 4;
- req.data[2] = 0;
- req.data[3] = 0;
- req.reply[0] = ADB_RET_OK;
- req.reply_len = 1;
- req.reply_expected = 0;
- pmu_polled_request(req);
- mdelay(50);
- }
- mdelay(50);
-}
-#endif
/*
* Put the powerbook to sleep.
@@ -1894,122 +1855,6 @@ restore_via_state(void)
extern void pmu_backlight_set_sleep(int sleep);
-static int
-pmac_suspend_devices(void)
-{
- int ret;
-
- pm_prepare_console();
-
- /* Sync the disks. */
- /* XXX It would be nice to have some way to ensure that
-* nobody is dirtying any new buffers while we wait.
[PATCH] PMU: remove dead code
Some code in via-pmu.c is never compiled because of compile options
within the file. Remove the code completely.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/macintosh/via-pmu.c | 42 +-
1 file changed, 1 insertion(+), 41 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2007-11-13 19:32:03.058713543
+0100
+++ everything/drivers/macintosh/via-pmu.c 2007-11-13 19:32:05.968717936
+0100
@@ -64,9 +64,7 @@
#include via-pmu-event.h
/* Some compile options */
-#undef SUSPEND_USES_PMU
#define DEBUG_SLEEP
-#undef HACKED_PCI_SAVE
/* Misc minor number allocated for /dev/pmu */
#define PMU_MINOR 154
@@ -1255,9 +1253,7 @@ void
pmu_suspend(void)
{
unsigned long flags;
-#ifdef SUSPEND_USES_PMU
- struct adb_request *req;
-#endif
+
if (!via)
return;
@@ -1275,17 +1271,10 @@ pmu_suspend(void)
via_pmu_interrupt(0, NULL);
spin_lock_irqsave(pmu_lock, flags);
if (!adb_int_pending pmu_state == idle
!req_awaiting_reply) {
-#ifdef SUSPEND_USES_PMU
- pmu_request(req, NULL, 2, PMU_SET_INTR_MASK, 0);
- spin_unlock_irqrestore(pmu_lock, flags);
- while(!req.complete)
- pmu_poll();
-#else /* SUSPEND_USES_PMU */
if (gpio_irq = 0)
disable_irq_nosync(gpio_irq);
out_8(via[IER], CB1_INT | IER_CLR);
spin_unlock_irqrestore(pmu_lock, flags);
-#endif /* SUSPEND_USES_PMU */
break;
}
} while (1);
@@ -1306,18 +1295,11 @@ pmu_resume(void)
return;
}
adb_int_pending = 1;
-#ifdef SUSPEND_USES_PMU
- pmu_request(req, NULL, 2, PMU_SET_INTR_MASK, pmu_intr_mask);
- spin_unlock_irqrestore(pmu_lock, flags);
- while(!req.complete)
- pmu_poll();
-#else /* SUSPEND_USES_PMU */
if (gpio_irq = 0)
enable_irq(gpio_irq);
out_8(via[IER], CB1_INT | IER_SET);
spin_unlock_irqrestore(pmu_lock, flags);
pmu_poll();
-#endif /* SUSPEND_USES_PMU */
}
/* Interrupt data could be the result data from an ADB cmd */
@@ -1803,14 +1785,10 @@ static void broadcast_wake(void)
* PCI devices which may get powered off when we sleep.
*/
static struct pci_save {
-#ifndef HACKED_PCI_SAVE
u16 command;
u16 cache_lat;
u16 intr;
u32 rom_address;
-#else
- u32 config[16];
-#endif
} *pbook_pci_saves;
static int pbook_npci_saves;
@@ -1856,16 +1834,10 @@ pbook_pci_save(void)
pci_dev_put(pd);
return;
}
-#ifndef HACKED_PCI_SAVE
pci_read_config_word(pd, PCI_COMMAND, ps-command);
pci_read_config_word(pd, PCI_CACHE_LINE_SIZE, ps-cache_lat);
pci_read_config_word(pd, PCI_INTERRUPT_LINE, ps-intr);
pci_read_config_dword(pd, PCI_ROM_ADDRESS, ps-rom_address);
-#else
- int i;
- for (i=1;i16;i++)
- pci_read_config_dword(pd, i4, ps-config[i]);
-#endif
++ps;
}
}
@@ -1884,17 +1856,6 @@ pbook_pci_restore(void)
int j;
while ((pd = pci_get_device(PCI_ANY_ID, PCI_ANY_ID, pd)) != NULL) {
-#ifdef HACKED_PCI_SAVE
- int i;
- if (npci-- == 0) {
- pci_dev_put(pd);
- return;
- }
- ps++;
- for (i=2;i16;i++)
- pci_write_config_dword(pd, i4, ps-config[i]);
- pci_write_config_dword(pd, 4, ps-config[1]);
-#else
if (npci-- == 0)
return;
ps++;
@@ -1918,7 +1879,6 @@ pbook_pci_restore(void)
pci_write_config_word(pd, PCI_COMMAND, ps-command);
break;
}
-#endif
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] PMU: don't lock_kernel()
I see nothing that this lock_kernel() actually protects against
so remove it.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Please queue to whatever branch you feel appropriate.
drivers/macintosh/via-pmu.c |3 ---
1 file changed, 3 deletions(-)
--- everything.orig/drivers/macintosh/via-pmu.c 2007-11-13 19:32:01.728726509
+0100
+++ everything/drivers/macintosh/via-pmu.c 2007-11-13 19:32:03.058713543
+0100
@@ -33,7 +33,6 @@
#include linux/adb.h
#include linux/pmu.h
#include linux/cuda.h
-#include linux/smp_lock.h
#include linux/module.h
#include linux/spinlock.h
#include linux/pm.h
@@ -2547,7 +2546,6 @@ pmu_release(struct inode *inode, struct
struct pmu_private *pp = file-private_data;
unsigned long flags;
- lock_kernel();
if (pp != 0) {
file-private_data = NULL;
spin_lock_irqsave(all_pvt_lock, flags);
@@ -2561,7 +2559,6 @@ pmu_release(struct inode *inode, struct
kfree(pp);
}
- unlock_kernel();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powermac: fix warning in time.c
arch/powerpc/platforms/powermac/time.c:88: warning: ‘to_rtc_time’ defined but
not used
Somehow this warning has always bothered me. This patch fixes it by
making the relevant code depend on the users.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/time.c |2 ++
1 file changed, 2 insertions(+)
--- linux-2.6-git.orig/arch/powerpc/platforms/powermac/time.c 2007-11-13
19:07:32.243563123 +0100
+++ linux-2.6-git/arch/powerpc/platforms/powermac/time.c2007-11-13
19:08:27.154561404 +0100
@@ -84,12 +84,14 @@ long __init pmac_time_init(void)
return delta;
}
+#if defined(CONFIG_ADB_CUDA) || defined(CONFIG_ADB_PMU)
static void to_rtc_time(unsigned long now, struct rtc_time *tm)
{
to_tm(now, tm);
tm-tm_year -= 1900;
tm-tm_mon -= 1;
}
+#endif
static unsigned long from_rtc_time(struct rtc_time *tm)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
The patch updates the booting-without-of.txt-file. There is a description for the case if mdio data and clock pins are on different processor ports. It extends the [PATCH v3] using mii-bitbang on different processor ports. Signed-off-by: Sergej Stepanov [EMAIL PROTECTED] Signed-off-by: Scott Wood [EMAIL PROTECTED] -- diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 497d8d8..084d31b 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1936,11 +1936,15 @@ platforms are moved over to use the flattened-device-tree model. Currently defined compatibles: fsl,pq1-fec-mdio (reg is same as first resource of FEC device) - fsl,cpm2-mdio-bitbang (reg is port C registers) + fsl,cpm2-mdio-bitbang Properties for fsl,cpm2-mdio-bitbang: - fsl,mdio-pin : pin of port C controlling mdio data - fsl,mdc-pin : pin of port C controlling mdio clock + The first reg resource is the I/O port register block on which MDIO + resides. The second reg resource is the I/O port register block on + which MDC resides. If there is only one reg resource, it is used for + both MDIO and MDC. + fsl,mdio-pin : pin of chosen port for controlling mdio data + fsl,mdc-pin : pin of chosen port for controlling mdio clock Example: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] PowerPC: make 4xx uic use generic level irq handler
This patch makes PowerPC 4xx UIC use generic level irq handler instead
of a custom handle_uic_irq() function. We ack only edge irqs in mask_ack
callback, since acking a level irq on UIC has no effect if the interrupt
is still asserted by the device, even if the interrupt is already masked.
So, to really de-assert the interrupt we need to de-assert the external
source first *and* ack it on UIC then. The handle_level_irq() function
masks and ack's the interrupt with mask_ack callback prior to calling
the actual ISR and unmasks it at the end. So, to use it with UIC interrupts
we need to ack level irqs in the unmask callback instead, after the ISR
has de-asserted the external interrupt source. Even if we ack the interrupt
that we didn't handle (unmask/ack it at the end of the handler, while
next irq is already pending) it will not de-assert the irq, untill we
de-assert its exteral source.
Signed-off-by: Valentine Barshak [EMAIL PROTECTED]
---
arch/powerpc/sysdev/uic.c | 81 ++
1 files changed, 19 insertions(+), 62 deletions(-)
--- linux-2.6.orig/arch/powerpc/sysdev/uic.c2007-11-14 15:57:37.0
+0300
+++ linux-2.6/arch/powerpc/sysdev/uic.c 2007-11-14 15:59:18.0 +0300
@@ -60,14 +60,19 @@ struct uic {
static void uic_unmask_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
- u32 er;
+ u32 er, sr;
+ sr = 1 (31-src);
spin_lock_irqsave(uic-lock, flags);
+ /* ack level-triggered interrupts here */
+ if (desc-status IRQ_LEVEL)
+ mtdcr(uic-dcrbase + UIC_SR, sr);
er = mfdcr(uic-dcrbase + UIC_ER);
- er |= 1 (31 - src);
+ er |= sr;
mtdcr(uic-dcrbase + UIC_ER, er);
spin_unlock_irqrestore(uic-lock, flags);
}
@@ -99,6 +104,7 @@ static void uic_ack_irq(unsigned int vir
static void uic_mask_ack_irq(unsigned int virq)
{
+ struct irq_desc *desc = get_irq_desc(virq);
struct uic *uic = get_irq_chip_data(virq);
unsigned int src = uic_irq_to_hw(virq);
unsigned long flags;
@@ -109,7 +115,16 @@ static void uic_mask_ack_irq(unsigned in
er = mfdcr(uic-dcrbase + UIC_ER);
er = ~sr;
mtdcr(uic-dcrbase + UIC_ER, er);
- mtdcr(uic-dcrbase + UIC_SR, sr);
+ /* On the UIC, acking (i.e. clearing the SR bit)
+* a level irq will have no effect if the interrupt
+* is still asserted by the device, even if
+* the interrupt is already masked. Therefore
+* we only ack the egde interrupts here, while
+* level interrupts are ack'ed after the actual
+* isr call in the uic_unmask_irq()
+*/
+ if (!(desc-status IRQ_LEVEL))
+ mtdcr(uic-dcrbase + UIC_SR, sr);
spin_unlock_irqrestore(uic-lock, flags);
}
@@ -173,64 +188,6 @@ static struct irq_chip uic_irq_chip = {
.set_type = uic_set_irq_type,
};
-/**
- * handle_uic_irq - irq flow handler for UIC
- * @irq: the interrupt number
- * @desc: the interrupt description structure for this irq
- *
- * This is modified version of the generic handle_level_irq() suitable
- * for the UIC. On the UIC, acking (i.e. clearing the SR bit) a level
- * irq will have no effect if the interrupt is still asserted by the
- * device, even if the interrupt is already masked. Therefore, unlike
- * the standard handle_level_irq(), we must ack the interrupt *after*
- * invoking the ISR (which should have de-asserted the interrupt in
- * the external source). For edge interrupts we ack at the beginning
- * instead of the end, to keep the window in which we can miss an
- * interrupt as small as possible.
- */
-void fastcall handle_uic_irq(unsigned int irq, struct irq_desc *desc)
-{
- unsigned int cpu = smp_processor_id();
- struct irqaction *action;
- irqreturn_t action_ret;
-
- spin_lock(desc-lock);
- if (desc-status IRQ_LEVEL)
- desc-chip-mask(irq);
- else
- desc-chip-mask_ack(irq);
-
- if (unlikely(desc-status IRQ_INPROGRESS))
- goto out_unlock;
- desc-status = ~(IRQ_REPLAY | IRQ_WAITING);
- kstat_cpu(cpu).irqs[irq]++;
-
- /*
-* If its disabled or no action available
-* keep it masked and get out of here
-*/
- action = desc-action;
- if (unlikely(!action || (desc-status IRQ_DISABLED))) {
- desc-status |= IRQ_PENDING;
- goto out_unlock;
- }
-
- desc-status |= IRQ_INPROGRESS;
- desc-status = ~IRQ_PENDING;
- spin_unlock(desc-lock);
-
- action_ret = handle_IRQ_event(irq, action);
-
- spin_lock(desc-lock);
- desc-status = ~IRQ_INPROGRESS;
- if (desc-status IRQ_LEVEL)
- desc-chip-ack(irq);
- if (!(desc-status
DMA interrupt is not generating in MPC8641D
Hai, We have designed a MPC8641D based AMC card. As part of our customer requirement for a PCIe messaging driver for communicating between the MPC8641D AMC card as the PCIe target and the MPC8548E AMC card as the Host. We are using the DMA for transferring data between the boards thru' PCIe. The DMA Interrupt on the target end is not getting registered and hence we face the issue (ie) No interrupt is generated after DMA transfer completion. As per datasheet(Rev. 1, 05/2007) page no:445 interrupt number for DMAchannel 1 is 4. We are using linux kernel version :2.6.23-rc3. According to file (include/asm-powerpc/irq.h) line no:636 the interrupt number for DMA in linux is 20(decimal). When using this interrupt number 20 we are not able to registerd the DMA interrupts. Note: 1. Linux is configured in SMP mode. 2. Value of Device status register(0xf80E000C) : 0x0aa28747 Thanks and Regards Sivaji -- View this message in context: http://www.nabble.com/DMA-interrupt-is-not-generating-in-MPC8641D-tf4805310.html#a13747460 Sent from the linuxppc-dev mailing list archive at Nabble.com. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C on mpc8248 / device tree
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the latest postings.
-Alan
On 11/13/07, Jon Smirl [EMAIL PROTECTED] wrote:
I am working on a patch for i2c and device tree. I attached the current
version.
DTC entry looks like this.
[EMAIL PROTECTED] {
compatible =
mpc5200b-i2c,mpc5200-i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
compatible = epson,rtc8564;
reg = 51;
};
};
--
Jon Smirl
[EMAIL PROTECTED]
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.24-rc1 freezes on powerbook at first boot stage
[FWIW, my powerbook worked with -rc1] 2.6.24-rc2 works so lala :) b43 doesn't authenticate via wpa (bluetooth isn't loaded): WEXT auth param 4 value 0x0 - ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 5 value 0x1 - Internet Systems Consortium DHCP Client V3.1.0 Those error messages are unrelated. My b43 works fine, even with a multi-MAC patch. TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered sysctl table check failed: /kernel .1 Writable sysctl directory Call Trace: [c1061e60] [c0008b28] show_stack+0x4c/0x1ac (unreliable) [c1061ea0] [c0047354] set_fail+0x50/0x68 [c1061ec0] [c0047784] sysctl_check_table+0x418/0x714 [c1061f30] [c00335b8] register_sysctl_table+0x64/0xb4 [c1061f50] [c033fd5c] register_powersave_nap_sysctl+0x18/0x2c [c1061f60] [c03391e4] kernel_init+0xc0/0x2a0 [c1061ff0] [c0011a58] kernel_thread+0x44/0x60 This has been fixed. There is a lot to do, but it seems to be a big, big code change in that version. This impressed me by looking at the git changes and the size of patches. And the rc's don't seem to be frozend versions. A lot of new code comes in Let me know whether a complete dmesg is needed. What is the problem? Why is this on wireless? It'd help if you'd make one message per problem and post it to the correct mailing lists. johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C on mpc8248 / device tree
The patch is orthogonal to your issue.
There is NOT a driver in the kernel tree for the i2c on CPM2 based
parts like the 8248 (from what I can tell).
- k
On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the latest postings.
-Alan
On 11/13/07, Jon Smirl [EMAIL PROTECTED] wrote:I am working on
a patch for i2c and device tree. I attached the current version.
DTC entry looks like this.
[EMAIL PROTECTED] {
compatible = mpc5200b-i2c,mpc5200-
i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
compatible = epson,rtc8564;
reg = 51;
};
};
--
Jon Smirl
[EMAIL PROTECTED]
___
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: I2C on mpc8248 / device tree
ERk.
So if I needed to read values from four i2c devices (raw access would be
fine) and I need to get this working in a few days, how would you suggest I
proceed? Kernel = 2.6.23+.
Do I need to start from scratch?
Start by using Jon's patch (or are the 5200 i2c and the cpm2 i2c
completely incompatible?)
What about other cpm2/i2c threads - Did they ever complete?
1) On Wednesday, November 23, 2005 8:01 AM Kumar Gala wrote: * Can we
rename the driver from mpc8260 - cpm2. The driver should work* * on any
device that has a CPM2 which includes a number of MPC82xx* * and MPC85xx
processors http://osdir.com/ml/ports.ppc.devel/2005-11/msg00153.html#. So
calling it and its config options, etc* * MPC8260 is going to be confusing
to users.* [PATCH] I2C: Add I2C Bus support for MPC with CPM2.
On 11/14/07, Kumar Gala [EMAIL PROTECTED] wrote:
The patch is orthogonal to your issue.
There is NOT a driver in the kernel tree for the i2c on CPM2 based
parts like the 8248 (from what I can tell).
- k
On Nov 14, 2007, at 9:31 AM, Alan Bennett wrote:
Does this patch support the cpm2 as well?
I get conflicting thoughts looking over the latest postings.
-Alan
On 11/13/07, Jon Smirl [EMAIL PROTECTED] wrote:I am working on
a patch for i2c and device tree. I attached the current version.
DTC entry looks like this.
[EMAIL PROTECTED] {
compatible = mpc5200b-i2c,mpc5200-
i2c,fsl-i2c;
reg = 3d40 40;
interrupts = 2 10 0;
interrupt-parent = mpc5200_pic;
fsl5200-clocking;
[EMAIL PROTECTED] {
compatible = epson,rtc8564;
reg = 51;
};
};
--
Jon Smirl
[EMAIL PROTECTED]
___
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: I2C on mpc8248 / device tree
On Wed, Nov 14, 2007 at 10:49:13AM -0700, Alan Bennett wrote: ERk. So if I needed to read values from four i2c devices (raw access would be fine) and I need to get this working in a few days, how would you suggest I proceed? Kernel = 2.6.23+. Do I need to start from scratch? Start by using Jon's patch (or are the 5200 i2c and the cpm2 i2c completely incompatible?) Start with the cpm i2c driver that Jochen Friedrich posted to linuxppc-embedded. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do not depend on MAX_ORDER when grouping pages by mobility
On (13/11/07 11:44), Stephen Rothwell didst pronounce:
On Mon, 12 Nov 2007 15:54:53 + [EMAIL PROTECTED] (Mel Gorman) wrote:
Ordinarily, the size of a pageblock is determined from the hugepage size.
On PPC64, the hugepage size is determined at runtime based on the ability
of the machine. If the machine does not support hugepages, HPAGE_SHIFT is
0. This results in pageblock_order being set to -PAGE_SHIFT and a crash
results shortly afterwards.
This patch checks that HPAGE_SHIFT is a sensible value before using the
hugepage size. If it is 0, MAX_ORDER-1 is used instead as this is a sensible
value of pageblock_order.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
Looks good. Legacy iSeries boots fine with this and David Gibson has run
his libhugetlbfs test suite on a Power5+ machine also running the same
kernel (ppc64_defconfig).
I would be good if we could get this in for 2.6.24 (since, as far as
legacy iSeries is concerned, this is a regression from 2.6.23). I am not
sure what other testing needs to be done.
libhugetlbfs test suite and boot test on iSeries is sufficient in this
case. However, the version I sent would break on IA-64 due to the lack of
a definition for HPAGE_SHIFT when CONFIG_HUGETLB_PAGE is not set. Can you
confirm this patch still fixes the problem please? If it does, I'll send
it to Andrew as a fix for 2.6.24. Whether iSeries is legacy or not, this is
breakage and should be fixed.
Thanks
Ordinarily the size of a pageblock is determined at compile-time based on the
hugepage size. On PPC64, the hugepage size is determined at runtime based on
what is supported by the machine. With legacy machines such as iSeries that
do not support hugepages, HPAGE_SHIFT is 0. This results in pageblock_order
being set to -PAGE_SHIFT and a crash results shortly afterwards.
This patch adds a function to select a sensible value for pageblock order by
default when HUGETLB_PAGE_SIZE_VARIABLE is set. It checks that HPAGE_SHIFT
is a sensible value before using the hugepage size; if it is not MAX_ORDER-1
is used.
This is a fix for 2.6.24.
Credit goes to Stephen Rothwell for identifying the bug and testing on
iSeries. Additional credit goes to Andy Whitcroft for spotting a problem
with respects to IA-64 before releasing. Additional credit goes to David
Gibson for testing with the libhugetlbfs test suite.
Signed-off-by: Mel Gorman [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |5 +
mm/page_alloc.c | 14 --
2 files changed, 17 insertions(+), 2 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig
linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig
--- linux-2.6.24-rc2-mm1-clean/arch/powerpc/Kconfig 2007-11-14
11:38:05.0 +
+++ linux-2.6.24-rc2-005_iSeries_fix/arch/powerpc/Kconfig 2007-11-14
11:39:12.0 +
@@ -187,6 +187,11 @@ config FORCE_MAX_ZONEORDER
default 9 if PPC_64K_PAGES
default 13
+config HUGETLB_PAGE_SIZE_VARIABLE
+ bool
+ depends on HUGETLB_PAGE
+ default y
+
config MATH_EMULATION
bool Math emulation
depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff
linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c
linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c
--- linux-2.6.24-rc2-mm1-clean/mm/page_alloc.c 2007-11-14 11:38:08.0
+
+++ linux-2.6.24-rc2-005_iSeries_fix/mm/page_alloc.c2007-11-14
13:45:19.0 +
@@ -3342,6 +3342,16 @@ static void inline setup_usemap(struct p
#endif /* CONFIG_SPARSEMEM */
#ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
+
+/* Return a sensible default order for the pageblock size. */
+static inline int __init pageblock_default_order(void)
+{
+ if (HPAGE_SHIFT PAGE_SHIFT)
+ return HUGETLB_PAGE_ORDER;
+
+ return MAX_ORDER-1;
+}
+
/* Initialise the number of pages represented by NR_PAGEBLOCK_BITS */
static inline void __init set_pageblock_order(unsigned int order)
{
@@ -3357,7 +3367,7 @@ static inline void __init set_pageblock_
}
#else /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
-/* Defined this way to avoid accidently referencing HUGETLB_PAGE_ORDER */
+#define pageblock_default_order(x) (0)
#define set_pageblock_order(x) do {} while (0)
#endif /* CONFIG_HUGETLB_PAGE_SIZE_VARIABLE */
@@ -3442,7 +3452,7 @@ static void __meminit free_area_init_cor
if (!size)
continue;
- set_pageblock_order(HUGETLB_PAGE_ORDER);
+ set_pageblock_order(pageblock_default_order());
setup_usemap(pgdat, zone, size);
ret = init_currently_empty_zone(zone, zone_start_pfn,
size, MEMMAP_EARLY);
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
[PATCH] powerpc: prpmc2800 - Enable L2 cache
From: Mark A. Greer [EMAIL PROTECTED] Turn on the L2 cache on the prpmc2800 platform. Signed-off-by: Mark A. Greer [EMAIL PROTECTED] --- arch/powerpc/platforms/embedded6xx/prpmc2800.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/embedded6xx/prpmc2800.c b/arch/powerpc/platforms/embedded6xx/prpmc2800.c index e484cac..653a5eb 100644 --- a/arch/powerpc/platforms/embedded6xx/prpmc2800.c +++ b/arch/powerpc/platforms/embedded6xx/prpmc2800.c @@ -144,6 +144,7 @@ static int __init prpmc2800_probe(void) strncpy(prpmc2800_platform_name, m, min((int)len, PLATFORM_NAME_MAX - 1)); + _set_L2CR(_get_L2CR() | L2CR_L2E); return 1; } ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: I2C on mpc8248 / device tree
On 11/14/07, Scott Wood [EMAIL PROTECTED] wrote: On Wed, Nov 14, 2007 at 10:49:13AM -0700, Alan Bennett wrote: ERk. So if I needed to read values from four i2c devices (raw access would be fine) and I need to get this working in a few days, how would you suggest I proceed? Kernel = 2.6.23+. Do I need to start from scratch? Start by using Jon's patch (or are the 5200 i2c and the cpm2 i2c completely incompatible?) Start with the cpm i2c driver that Jochen Friedrich posted to linuxppc-embedded. Sorry about the confusion I thought the mpc82xx chips had the same i2c core as the mpc52xx but I was not correct. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] vdso: Fixes for cache line sizes
[POWERPC] vdso: Fixes for cache line sizes Current VDSO implementation is hardcoded to 128 byte cachelines, which only works on IBM's 64-bit processors. Convert it to get the line sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- Paul, this is needed to make for example the IBM jvm run on pa6t. Please include as bugfix for 2.6.24. diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index 2c8e756..02cfe9a 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -284,6 +284,10 @@ int main(void) DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32)); DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec)); DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec)); + DEFINE(CFG_ICACHE_LINESZ, offsetof(struct vdso_data, icache_line_size)); + DEFINE(CFG_DCACHE_LINESZ, offsetof(struct vdso_data, dcache_line_size)); + DEFINE(CFG_ICACHE_LOGLINESZ, offsetof(struct vdso_data, icache_log_line_size)); + DEFINE(CFG_DCACHE_LOGLINESZ, offsetof(struct vdso_data, dcache_log_line_size)); #ifdef CONFIG_PPC64 DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64)); DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec)); diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index 2322ba5..5a8ab23 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -696,14 +696,21 @@ static int __init vdso_init(void) vdso_data-physicalMemorySize = lmb_phys_mem_size(); vdso_data-dcache_size = ppc64_caches.dsize; vdso_data-dcache_line_size = ppc64_caches.dline_size; + vdso_data-dcache_log_line_size = ppc64_caches.log_dline_size; vdso_data-icache_size = ppc64_caches.isize; vdso_data-icache_line_size = ppc64_caches.iline_size; + vdso_data-icache_log_line_size = ppc64_caches.log_iline_size; /* * Calculate the size of the 64 bits vDSO */ vdso64_pages = (vdso64_end - vdso64_start) PAGE_SHIFT; DBG(vdso64_kbase: %p, 0x%x pages\n, vdso64_kbase, vdso64_pages); +#else + vdso_data-dcache_line_size = L1_CACHE_BYTES; + vdso_data-dcache_log_line_size = L1_CACHE_SHIFT; + vdso_data-icache_line_size = L1_CACHE_BYTES; + vdso_data-icache_log_line_size = L1_CACHE_SHIFT; #endif /* CONFIG_PPC64 */ diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S index 9cb3199..fac0fa6 100644 --- a/arch/powerpc/kernel/vdso32/cacheflush.S +++ b/arch/powerpc/kernel/vdso32/cacheflush.S @@ -23,29 +23,44 @@ * * Flushes the data cache invalidate the instruction cache for the * provided range [start, end[ - * - * Note: all CPUs supported by this kernel have a 128 bytes cache - * line size so we don't have to peek that info from the datapage */ V_FUNCTION_BEGIN(__kernel_sync_dicache) .cfi_startproc - li r5,127 - andcr6,r3,r5/* round low to line bdy */ + mflrr12 + .cfi_register lr,r12 + mr r11,r3 + bl [EMAIL PROTECTED] + mtlrr12 + mr r10,r3 + + lwz r7,CFG_DCACHE_LINESZ(r10) + addir5,r7,-1 + andcr6,r11,r5 /* round low to line bdy */ subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ - srwi. r8,r8,7 /* compute line count */ - crclr cr0*4+so + lwz r9,CFG_DCACHE_LOGLINESZ(r10) + srw.r8,r8,r9/* compute line count */ beqlr /* nothing to do? */ mtctr r8 - mr r3,r6 -1: dcbst 0,r3 - addir3,r3,128 +1: dcbst 0,r6 + add r6,r6,r7 bdnz1b sync + +/* Now invalidate the instruction cache */ + + lwz r7,CFG_ICACHE_LINESZ(r10) + addir5,r7,-1 + andcr6,r11,r5 /* round low to line bdy */ + subfr8,r6,r4/* compute length */ + add r8,r8,r5 + lwz r9,CFG_ICACHE_LOGLINESZ(r10) + srw.r8,r8,r9/* compute line count */ + beqlr /* nothing to do? */ mtctr r8 -1: icbi0,r6 - addir6,r6,128 - bdnz1b +2: icbi0,r6 + add r6,r6,r7 + bdnz2b isync li r3,0 blr diff --git a/arch/powerpc/kernel/vdso64/cacheflush.S b/arch/powerpc/kernel/vdso64/cacheflush.S index 66a36d3..8b6bcce 100644 --- a/arch/powerpc/kernel/vdso64/cacheflush.S +++ b/arch/powerpc/kernel/vdso64/cacheflush.S @@ -23,29 +23,44 @@ * * Flushes the data cache invalidate the instruction cache for the * provided range [start, end[ - * - * Note: all CPUs
Re: [PATCH] [POWERPC] pSeries: make pseries_defconfig minus PCI build again
On Wed, Nov 14, 2007 at 03:07:39PM +1100, Stephen Rothwell wrote: Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] Acked-by: Linas Vepstas [EMAIL PROTECTED] --- arch/powerpc/platforms/pseries/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index 16e4e40..306a9d0 100644 --- a/arch/powerpc/platforms/pseries/Kconfig +++ b/arch/powerpc/platforms/pseries/Kconfig @@ -21,7 +21,7 @@ config PPC_SPLPAR config EEH bool PCI Extended Error Handling (EEH) if EMBEDDED - depends on PPC_PSERIES + depends on PPC_PSERIES PCI default y if !EMBEDDED config SCANLOG -- 1.5.3.5 ___ 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: [PATCH] [POWERPC] vdso: Fixes for cache line sizes
On Wed, 2007-11-14 at 13:24 -0600, Olof Johansson wrote: [POWERPC] vdso: Fixes for cache line sizes Current VDSO implementation is hardcoded to 128 byte cachelines, which only works on IBM's 64-bit processors. Convert it to get the line sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Please call the fields block size not line size. There are subtle differences and per architecture, it should really be block size. Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- Paul, this is needed to make for example the IBM jvm run on pa6t. Please include as bugfix for 2.6.24. Heh, they use the vdso for flushes ? I didn't know that ! Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] pci hotplug: fix rpaphp directory naming
Fix presentation of the slot number in the /sys/bus/pci/slots
directory to match that used in the majority of other drivers.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
--
On Tue, Nov 13, 2007 at 07:26:07PM -0800, Greg KH wrote:
We need a signed-off-by: to be able to apply this...
Whoops. See above. Same patch as list time, no changes.
On Tue, Nov 13, 2007 at 02:58:30PM -0700, Matthew Wilcox wrote:
On Tue, Nov 13, 2007 at 03:41:21PM -0600, Linas Vepstas wrote:
/sys/bus/pci/slots
/sys/bus/pci/slots/control
/sys/bus/pci/slots/control/remove_slot
/sys/bus/pci/slots/control/add_slot
/sys/bus/pci/slots/0001:00:02.0
/sys/bus/pci/slots/0001:00:02.0/phy_location
Ugh. Almost two years ago, paulus promised me he was going to fix the
slot name for rpaphp. Guess he didn't.
You have to ask the right person. :-) I've been defacto mainaining
the rpaphp code for unpteen years now. On the other hand, I am also
much, much better at promising than delivering.
This is one of the hateful things about the current design -- hotplug
drivers do too much. Instead of being just the interface between the
Linux PCI code and the hardware, they create sysfs directories, add
files,
and generally have far too much freedom.
I chopped out several hundred LOC from rpaphp a year ago,
and hopefuly that might make furthre simplification easier
someday.
We have four different schemes currently for naming in slots/,
1. slot number. Used by cpqphp, ibmphp, acpiphp, pciehp, shpc.
2. domain:bus:dev:fn. Used by fakephp.
3a. domain:bus:dev. Used by rpaphp and sgihp.
3b. Except that rpaphp uses phy_location to present the information
that
should be in the name and sgihp uses path.
... I've forgotten what cpci uses. And yenta doesn't use it.
How is anyone supposed to write sane managability tools in the
presence
of such anarchy?
~ # cat /sys/bus/pci/slots/:00:02.2/phy_location
U787A.001.DNZ00Z5-P1-C2
Right. This should look like:
# cat /sys/bus/pci/slots/U787A.001.DNZ00Z5-P1-C2/address
:00:02
This patch implements exactly what you describe. Boot tested.
I assume you really mean it -- if so, then please review and
ack the patch !?
I have absolutely no clue if this breaks any existing IBM tools.
I'm pretty sure it doesn't ... but attention Mike Strosaker! does it?
drivers/pci/hotplug/rpaphp.h |1
drivers/pci/hotplug/rpaphp_pci.c | 14 ---
drivers/pci/hotplug/rpaphp_slot.c | 47 +++---
3 files changed, 24 insertions(+), 38 deletions(-)
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_pci.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_pci.c 2007-11-13
17:52:10.0 -0600
@@ -64,19 +64,6 @@ int rpaphp_get_sensor_state(struct slot
return rc;
}
-static void set_slot_name(struct slot *slot)
-{
- struct pci_bus *bus = slot-bus;
- struct pci_dev *bridge;
-
- bridge = bus-self;
- if (bridge)
- strcpy(slot-name, pci_name(bridge));
- else
- sprintf(slot-name, %04x:%02x:00.0, pci_domain_nr(bus),
- bus-number);
-}
-
/**
* rpaphp_enable_slot - record slot state, config pci device
*
@@ -114,7 +101,6 @@ int rpaphp_enable_slot(struct slot *slot
info-adapter_status = EMPTY;
slot-bus = bus;
slot-pci_devs = bus-devices;
- set_slot_name(slot);
/* if there's an adapter in the slot, go add the pci devices */
if (state == PRESENT) {
Index: linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c
===
--- linux-2.6.23-rc8-mm1.orig/drivers/pci/hotplug/rpaphp_slot.c 2007-07-08
18:32:17.0 -0500
+++ linux-2.6.23-rc8-mm1/drivers/pci/hotplug/rpaphp_slot.c 2007-11-13
18:05:13.0 -0600
@@ -33,23 +33,31 @@
#include asm/rtas.h
#include rpaphp.h
-static ssize_t location_read_file (struct hotplug_slot *php_slot, char *buf)
+static ssize_t address_read_file (struct hotplug_slot *php_slot, char *buf)
{
- char *value;
- int retval = -ENOENT;
+ int retval;
struct slot *slot = (struct slot *)php_slot-private;
+ struct pci_bus *bus;
if (!slot)
- return retval;
+ return -ENOENT;
- value = slot-location;
- retval = sprintf (buf, %s\n, value);
+ bus = slot-bus;
+ if (!bus)
+ return -ENOENT;
+
+ if (bus-self)
+ retval = sprintf(buf, pci_name(bus-self));
+ else
+ retval = sprintf(buf, %04x:%02x:00.0,
+ pci_domain_nr(bus), bus-number);
+
return retval;
}
-static struct hotplug_slot_attribute php_attr_location = {
- .attr = {.name = phy_location, .mode =
[REPOST] script to build all defconfigs
I've been asked to post the script again, might as well update with the latest version. See below. I normally use this as: $ CROSS_COMPILE= ARCH=powerpc TARGET=vmlinux modules buildall modules won't build on some of the embedded platforms though, so you'll have to weed out those build errors by hand, or do: $ CROSS_COMPILE= ARCH=powerpc TARGET=vmlinux buildall --- #!/bin/bash #export CC=ccache gcc echo -n cleaning: make $O -ks mrproper echo done for config in arch/$ARCH/configs/* allnoconfig allmodconfig allyesconfig ; do CONFIG=`basename $config` echo -n $ARCH.$CONFIG: ; yes | make $O $CONFIG buildall.log 21 if time make $O $TARGET -ksj 5 buildall.log 21 ; then mv buildall.log $ARCH.$CONFIG.log.passed echo passed else mv buildall.log $ARCH.$CONFIG.log.failed echo failed fi done ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] [POWERPC] vdso: Fixes for cache block sizes
[POWERPC] vdso: Fixes for cache line sizes Current VDSO implementation is hardcoded to 128 byte cache blocks, which are only used on IBM's 64-bit processors. Convert it to get the blocks sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Signed-off-by: Olof Johansson [EMAIL PROTECTED] --- Paul, this is needed to make for example the IBM jvm run on pa6t. Please include as bugfix for 2.6.24. On Thu, Nov 15, 2007 at 07:28:22AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2007-11-14 at 13:24 -0600, Olof Johansson wrote: [POWERPC] vdso: Fixes for cache line sizes Current VDSO implementation is hardcoded to 128 byte cachelines, which only works on IBM's 64-bit processors. Convert it to get the line sizes out of vdso_data instead, similar to how the ppc64 in-kernel cache flush does it. Please call the fields block size not line size. There are subtle differences and per architecture, it should really be block size. Alright. I've added block sizes since I'm not sure whether the old systemcfg data is actually line or block sizes, and I guess it's something we need to stay compatible with. See separate new patch. Also, ppc64_caches only has line sizes, so fill it with that for now. I'll submit a separate patch to complete ppc64_caches with block sizes, but that's a cleanup not a bug fix (i.e. target for that would be 2.6.25). Paul, this is needed to make for example the IBM jvm run on pa6t. Please include as bugfix for 2.6.24. Heh, they use the vdso for flushes ? I didn't know that ! Me neither, and the fact that the vdso was hardcoded for 128 had completely passed me by. -Olof diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index 2c8e756..d67bcd8 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -284,6 +284,10 @@ int main(void) DEFINE(CFG_SYSCALL_MAP32, offsetof(struct vdso_data, syscall_map_32)); DEFINE(WTOM_CLOCK_SEC, offsetof(struct vdso_data, wtom_clock_sec)); DEFINE(WTOM_CLOCK_NSEC, offsetof(struct vdso_data, wtom_clock_nsec)); + DEFINE(CFG_ICACHE_BLOCKSZ, offsetof(struct vdso_data, icache_block_size)); + DEFINE(CFG_DCACHE_BLOCKSZ, offsetof(struct vdso_data, dcache_block_size)); + DEFINE(CFG_ICACHE_LOGBLOCKSZ, offsetof(struct vdso_data, icache_log_block_size)); + DEFINE(CFG_DCACHE_LOGBLOCKSZ, offsetof(struct vdso_data, dcache_log_block_size)); #ifdef CONFIG_PPC64 DEFINE(CFG_SYSCALL_MAP64, offsetof(struct vdso_data, syscall_map_64)); DEFINE(TVAL64_TV_SEC, offsetof(struct timeval, tv_sec)); diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c index 2322ba5..3702df7 100644 --- a/arch/powerpc/kernel/vdso.c +++ b/arch/powerpc/kernel/vdso.c @@ -699,11 +699,22 @@ static int __init vdso_init(void) vdso_data-icache_size = ppc64_caches.isize; vdso_data-icache_line_size = ppc64_caches.iline_size; + /* XXXOJN: Blocks should be added to ppc64_caches and used instead */ + vdso_data-dcache_block_size = ppc64_caches.dline_size; + vdso_data-icache_block_size = ppc64_caches.iline_size; + vdso_data-dcache_log_block_size = ppc64_caches.log_dline_size; + vdso_data-icache_log_block_size = ppc64_caches.log_iline_size; + /* * Calculate the size of the 64 bits vDSO */ vdso64_pages = (vdso64_end - vdso64_start) PAGE_SHIFT; DBG(vdso64_kbase: %p, 0x%x pages\n, vdso64_kbase, vdso64_pages); +#else + vdso_data-dcache_block_size = L1_CACHE_BYTES; + vdso_data-dcache_log_block_size = L1_CACHE_SHIFT; + vdso_data-icache_block_size = L1_CACHE_BYTES; + vdso_data-icache_log_block_size = L1_CACHE_SHIFT; #endif /* CONFIG_PPC64 */ diff --git a/arch/powerpc/kernel/vdso32/cacheflush.S b/arch/powerpc/kernel/vdso32/cacheflush.S index 9cb3199..99a76f7 100644 --- a/arch/powerpc/kernel/vdso32/cacheflush.S +++ b/arch/powerpc/kernel/vdso32/cacheflush.S @@ -23,29 +23,44 @@ * * Flushes the data cache invalidate the instruction cache for the * provided range [start, end[ - * - * Note: all CPUs supported by this kernel have a 128 bytes cache - * line size so we don't have to peek that info from the datapage */ V_FUNCTION_BEGIN(__kernel_sync_dicache) .cfi_startproc - li r5,127 - andcr6,r3,r5/* round low to line bdy */ + mflrr12 + .cfi_register lr,r12 + mr r11,r3 + bl [EMAIL PROTECTED] + mtlrr12 + mr r10,r3 + + lwz r7,CFG_DCACHE_BLOCKSZ(r10) + addir5,r7,-1 + andcr6,r11,r5 /* round low to line bdy */ subfr8,r6,r4/* compute length */ add r8,r8,r5/* ensure we get enough */ - srwi. r8,r8,7 /* compute line count */ - crclr cr0*4+so + lwz r9,CFG_DCACHE_LOGBLOCKSZ(r10) +
Re: Kernel locks up after calling kernel_execve()
Gerhard Pircher writes: Yeah, the northbridge hates the M bit! Thus the AmigaOne platform code Wow. masks out the CPU_FTR_NEED_COHERENT flag and disables the L2 cache prefetch engines (I don't care about the performance loss). I couldn't find any other code that sets the M bit, except for huge TLB page support, but isn't that only for PPC64? No it's not just for ppc64. We had a patch that went in some time ago to ensure that the M bit was set on various 32-bit platforms because otherwise we got data corruption (due to a small cache in the northbridge not being kept coherent with the processor cache). Look for CPU_FTR_NEED_COHERENT in include/asm-powerpc/cputable.h and arch/powerpc/mm/*. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v5 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
Hi Marian,
On Wed, 14 Nov 2007 11:21:37 +0100 Marian Balakowicz [EMAIL PROTECTED] wrote:
+++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
+#include asm/time.h
+#include asm/machdep.h
+#include asm/mpc52xx.h
You still need asm/prom.h because you use of_get_flat_dt_root() and
of_flat_dt_is_compatible().
+/* list of the supported boards */
+static const char *board[] __initdata = {
Unfortunately you can't use const and __initdata, so just remove the
const. (const changes the attributes on the section that __initdata is
stored in.)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgp6HXGXlaIBA.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
about uImage-DENX-v2.6.14 config
Hello, I have a problem when using linux-2.6.14(download from ftp.denx.de) for RTAI on ppc440EP. I use the ELDK4.1 and when boot the uImage I compiled , I always have the problem as following: ## Booting image at 0050 ... Image Name: Linux-2.6.14 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1155686 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK then it stopped . I am afraid that maybe the problem comes from the config. I have ever use the uImage-DENX-v2.6.14 you offered in ftp.denx.de/pub/linux/amcc/image/yosemite/ and it works. So can you send me a config file for 2.6.14 to me? Thank you. Best wishes kyla ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
Jon Smirl wrote: On 11/13/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: That's why Dominic wants to get OpenOCD running on the PowerPC. All we need is the programming documentation for controlling the CPU via the debug hardware. Note that this is basically different for every CPU around. I'd like to get it for the MPC5200 because of the project I am working on, an open source audio device. It would be nice if there was a cheap hardware debugger available for hackers to use on it. Maybe one of the Freescale developers will see this and send me the right docs. Is it radically different? Dominic has been able to support every ARM 7/9 chip he can get his hands on without too much trouble once the core support was written. I don't think he has ARM 11 working yet. Obviously this documentation exist, all of the commercial vendors had to have it to develop their debuggers. Maybe it is already out there and we just don't know where to look. Ben. DISCLAIMER: Extrapolating grossly from almost no knowledge! My understanding is that the Freescale PPC debugger interface is based on the JTAG interface using a proprietary command set. Basically, if you do their magic BDM (JTAG extension) command, you get into an internal scan chain that allows you to read/write the processor internals (registers). The problems are many... * The documentation is only available under NDA, a problem for open source debuggers. * The scan chain is different on every processor, and may be different on different revisions of the same processor. * If you mess up with JTAG, you will probably burn up the CPU. Very literally. I've seen it done. Twice. (Thankfully not my screwup, and it wasn't a PPC so it deserved to die. ;-) The internal scan chain is probably safer, but YMMV. gvb ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: printk/console_init - baud rate setting
Thanks Segher. It was because of the BASE_BAUD value. We are working at 600MHz, not 18.432. After that change, it worked fine. Thanks Siva -Original Message- From: Segher Boessenkool [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 14, 2007 3:00 PM To: Siva Prasad Subject: Re: printk/console_init - baud rate setting Thanks for your response Segher. I already have the command line console=ttyS0, 115200. Now, how to make sure that 115200 setting is calculated properly for the use by driver. In other words, can you kind enough to please let me know how 115200 is supported by the driver, based on the clock frequency. That is solely the driver's own responsibility, you'll have to look at the source code. 8250 typically just assumes 18.432MHz. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Hardware debuggers for PPC74xx G4 CPUs
On 11/14/07, Jerry Van Baren [EMAIL PROTECTED] wrote: Jon Smirl wrote: On 11/13/07, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: That's why Dominic wants to get OpenOCD running on the PowerPC. All we need is the programming documentation for controlling the CPU via the debug hardware. Note that this is basically different for every CPU around. I'd like to get it for the MPC5200 because of the project I am working on, an open source audio device. It would be nice if there was a cheap hardware debugger available for hackers to use on it. Maybe one of the Freescale developers will see this and send me the right docs. Is it radically different? Dominic has been able to support every ARM 7/9 chip he can get his hands on without too much trouble once the core support was written. I don't think he has ARM 11 working yet. Obviously this documentation exist, all of the commercial vendors had to have it to develop their debuggers. Maybe it is already out there and we just don't know where to look. Ben. DISCLAIMER: Extrapolating grossly from almost no knowledge! My understanding is that the Freescale PPC debugger interface is based on the JTAG interface using a proprietary command set. Basically, if you do their magic BDM (JTAG extension) command, you get into an internal scan chain that allows you to read/write the processor internals (registers). The problems are many... * The documentation is only available under NDA, a problem for open source debuggers. This is what we need. I would like it specifically for the mpc5200. But we want to use it in OpenOCD so NDA won't work. * The scan chain is different on every processor, and may be different on different revisions of the same processor. Hopefully the doc will cover this. * If you mess up with JTAG, you will probably burn up the CPU. Very literally. I've seen it done. Twice. (Thankfully not my screwup, and it wasn't a PPC so it deserved to die. ;-) The internal scan chain is probably safer, but YMMV. Dominic is way experienced implementing JTAG for ARM CPUs. He has done several dozen interfaces. ARM doesn't have any problems releasing their debugging info. I've also lined up a mpc5200 development board vendor who wants a cheap mpc5200 JTAG too and is willing to supply him with target hardware. JTAG hardware would be something similar to this: http://www.amontec.com/jtagkey-tiny.shtml So $30-40 for hardware with free OpenOCD software and you have JTAG for the mpc5200. This puts it in the range of classroom use. The few embedded classes I've been around lately are being taught on ARM hardware because it is so cheap. Development boards and the JTAG can be had for under $100. For example check out this store, it carries hundreds of ARM products and almost no PowerPC ones. http://microcontrollershop.com -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Do not depend on MAX_ORDER when grouping pages by mobility
Hi Mel, On Wed, 14 Nov 2007 18:10:45 + [EMAIL PROTECTED] (Mel Gorman) wrote: libhugetlbfs test suite and boot test on iSeries is sufficient in this case. However, the version I sent would break on IA-64 due to the lack of a definition for HPAGE_SHIFT when CONFIG_HUGETLB_PAGE is not set. Can you confirm this patch still fixes the problem please? If it does, I'll send it to Andrew as a fix for 2.6.24. Whether iSeries is legacy or not, this is breakage and should be fixed. The new patch works fine. I reran the libhugetlbfs tests on a Power5+ machine and the ppc64_defconfig boots on legacy iSeries. So Tested-by: Stephen Rothwell [EMAIL PROTECTED] iSeries boot test and hugetlb tests on PPC64 Thanks. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpNHX6xx8MlV.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: about uImage-DENX-v2.6.14 config
On Wednesday 14 November 2007, zhangwei zhang wrote: Hello, I have a problem when using linux-2.6.14(download from ftp.denx.de) for RTAI on ppc440EP. RTAI on PPC? I thought RTAI was dead for anything other than X86. And 2.6.14 is quite old. I suggest you use a newer binary version or compile a the image from the current kernel source. I use the ELDK4.1 and when boot the uImage I compiled , I always have the problem as following: ## Booting image at 0050 ... Image Name: Linux-2.6.14 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1155686 Bytes = 1.1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK then it stopped . I am afraid that maybe the problem comes from the config. I have ever use the uImage-DENX-v2.6.14 you offered in ftp.denx.de/pub/linux/amcc/image/yosemite/ and it works. So can you send me a config file for 2.6.14 to me? Thank you. Please don't stick with 2.6.14. Download the current kernel: http://www.denx.de/cgi-bin/gitweb.cgi?p=linux-2.6-denx.git;a=summary and there you will find the .config for the Yosemite (arch/ppc/configs/yosemite_defconfig). Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
