* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 20:35 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154028871.29826.261.camel@goblue>
>> These two lines don't need the msi.o and msi-altix.o AFAICS.
>
> Yup, you are right...updated patch included below.
Looks fine now, thanks.
>>> +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
>>
>> I think this file should live in arch/powerpc, and so should this
>> Makefile fragment.
>
> I'm following the current MSI methodologies where arch specific MSI
> code
> lives in drivers/pci. This is just like msi-altix.c.
True, but our core support lives in arch/. The same is true for PHB
code etc.; if Altix messed this up, that doesn't mean we need to :-)
>> Other than that, can we please have the part that doesn't build the
>> "generic" MSI stuff included ASAP?
This would naturally fall out as a separate patch then, as well.
>>> Index: 2.6-msi/drivers/pci/msi-rtas.c
>>
>> Maybe msi-papr.c is a better name btw? Not that I care :-)
>
> IMHO I don't like PAPR names because they like changing them on a
> whim.
> RTAS is a bit more persistent.
Maybe msi-pseries then? Oh wait, they changed that name too ;-)
> I don't really care...If anyone feels real strongly about it, I'll
> change it.
If you move this code to arch/powerpc/platforms/pseries/, you could
just call it "msi.c". I don't like the msi-rtas name -- but, I don't
feel that strongly about it, just a suggestion.
Segher
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 19:34 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <67FD272C-C378-4549-8B35-70912AFAB7EF@kernel.crashing.org>
On Thu, 2006-07-27 at 20:46 +0200, Segher Boessenkool wrote:
> > Index: 2.6-msi/drivers/pci/Makefile
> > ===================================================================
> > --- 2.6-msi.orig/drivers/pci/Makefile
> > +++ 2.6-msi/drivers/pci/Makefile
> > @@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
> > obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
> > obj-$(CONFIG_X86_VISWS) += setup-irq.o
> >
> > -msiobj-y := msi.o msi-apic.o
> > -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> > -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> > +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> > +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
>
> > +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> > +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
>
> These two lines don't need the msi.o and msi-altix.o AFAICS.
Yup, you are right...updated patch included below.
> > +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
>
> I think this file should live in arch/powerpc, and so should this
> Makefile fragment.
I'm following the current MSI methodologies where arch specific MSI code
lives in drivers/pci. This is just like msi-altix.c.
> > +
> > obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
> >
> > #
>
> Other than that, can we please have the part that doesn't build the
> "generic" MSI stuff included ASAP?
>
> > Index: 2.6-msi/drivers/pci/msi-rtas.c
>
> Maybe msi-papr.c is a better name btw? Not that I care :-)
IMHO I don't like PAPR names because they like changing them on a whim.
RTAS is a bit more persistent.
I don't really care...If anyone feels real strongly about it, I'll
change it.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/prom_init.c | 8 ++
arch/powerpc/platforms/pseries/setup.c | 4 +
arch/powerpc/platforms/pseries/xics.c | 5 -
drivers/pci/Kconfig | 2
drivers/pci/Makefile | 5 +
drivers/pci/msi-rtas.c | 111
+++++++++++++++++++++++++++++++++
include/asm-powerpc/rtas.h | 4 +
7 files changed, 134 insertions(+), 5 deletions(-)
Index: 2.6-msi/drivers/pci/Makefile
===================================================================
--- 2.6-msi.orig/drivers/pci/Makefile
+++ 2.6-msi/drivers/pci/Makefile
@@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
-msiobj-y := msi.o msi-apic.o
+msiobj-$(CONFIG_X86) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
+msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
+
obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
#
Index: 2.6-msi/drivers/pci/msi-rtas.c
===================================================================
--- /dev/null
+++ 2.6-msi/drivers/pci/msi-rtas.c
@@ -0,0 +1,111 @@
+/*
+ * Jake Moilanen <moilanen@austin.ibm.com>
+ * Copyright (C) 2006 IBM
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/irq.h>
+#include <asm/rtas.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+
+int rtas_enable_msi(struct pci_dev* pdev)
+{
+ static int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ int n_intr;
+ int last_virq = NO_IRQ;
+ int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ struct device_node * dn;
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return -ENOENT;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return -ENXIO;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 0, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_WARNING "error[%d]: getting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return -EIO;
+ }
+
+ /* Return if there's no MSI interrupts */
+ if (!ret[0])
+ return -ENOENT;
+
+ n_intr = ret[0];
+
+ for (i = 0; i < n_intr; i++) {
+ do {
+ rc = rtas_call(query_token, 4, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff, i);
+ } while (rtas_busy_delay(rc));
+
+ if (!rc) {
+ virq = irq_create_mapping(irq_find_host(dn), ret[0],
+ ret[1] ? IRQ_TYPE_EDGE_RISING :
+ IRQ_TYPE_LEVEL_LOW);
+
+ /* for now, take the last valid vector given out */
+ if (virq != NO_IRQ)
+ last_virq = virq;
+
+ } else {
+ printk(KERN_WARNING "error[%d]: "
+ "query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+ /*
+ * If we can't get any MSI vectors, fail and try falling
+ * back to LSI
+ */
+ if (last_virq == NO_IRQ)
+ return -EIO;
+
+ pdev->irq = last_virq;
+
+ return 0;
+}
+
+void rtas_disable_msi(struct pci_dev* pdev)
+{
+ /*
+ * for now, we don't give firmware back vectors to their pool
+ */
+}
Index: 2.6-msi/drivers/pci/Kconfig
===================================================================
--- 2.6-msi.orig/drivers/pci/Kconfig
+++ 2.6-msi/drivers/pci/Kconfig
@@ -4,7 +4,7 @@
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
+ depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || PPC_PSERIES
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
Index: 2.6-msi/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/setup.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/setup.c
@@ -267,6 +267,10 @@ static void __init pseries_discover_pic(
return;
} else if (strstr(typep, "ppc-xicp")) {
ppc_md.init_IRQ = xics_init_IRQ;
+#ifdef CONFIG_PCI_MSI
+ ppc_md.enable_msi = rtas_enable_msi;
+ ppc_md.disable_msi = rtas_disable_msi;
+#endif
#ifdef CONFIG_KEXEC
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
#endif
Index: 2.6-msi/include/asm-powerpc/rtas.h
===================================================================
--- 2.6-msi.orig/include/asm-powerpc/rtas.h
+++ 2.6-msi/include/asm-powerpc/rtas.h
@@ -4,6 +4,7 @@
#include <linux/spinlock.h>
#include <asm/page.h>
+#include <linux/pci.h>
/*
* Definitions for talking to the RTAS on CHRP machines.
@@ -186,6 +187,9 @@ extern int early_init_dt_scan_rtas(unsig
extern void pSeries_log_error(char *buf, unsigned int err_type, int
fatal);
+extern int rtas_enable_msi(struct pci_dev* pdev);
+extern void rtas_disable_msi(struct pci_dev * pdev);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
Index: 2.6-msi/arch/powerpc/kernel/prom_init.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/prom_init.c
+++ 2.6-msi/arch/powerpc/kernel/prom_init.c
@@ -632,6 +632,12 @@ static void __init early_cmdline_parse(v
/* ibm,dynamic-reconfiguration-memory property supported */
#define OV5_DRCONF_MEMORY 0x20
#define OV5_LARGE_PAGES 0x10 /* large pages supported */
+/* PCIe/MSI support. Without MSI full PCIe is not supported */
+#ifdef CONFIG_PCI_MSI
+#define OV5_MSI 0x01 /* PCIe/MSI support */
+#else
+#define OV5_MSI 0x00
+#endif /* CONFIG_PCI_MSI */
/*
* The architecture vector has an array of PVR mask/value pairs,
@@ -675,7 +681,7 @@ static unsigned char ibm_architecture_ve
/* option vector 5: PAPR/OF options */
3 - 1, /* length */
0, /* don't ignore, don't halt */
- OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES,
+ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_MSI,
};
/* Old method - ELF header with PT_NOTE sections */
Index: 2.6-msi/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/xics.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/xics.c
@@ -526,11 +526,12 @@ static int xics_host_map_lpar(struct irq
pr_debug("xics: map_lpar virq %d, hwirq 0x%lx, flags: 0x%x\n",
virq, hw, flags);
- if (sense && sense != IRQ_TYPE_LEVEL_LOW)
+ if (sense && !(sense & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_RISING)))
printk(KERN_WARNING "xics: using unsupported sense 0x%x"
" for irq %d (h: 0x%lx)\n", flags, virq, hw);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ if (sense && sense & IRQ_TYPE_LEVEL_LOW)
+ get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &xics_pic_lpar, handle_fasteoi_irq);
return 0;
}
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: Sylvain Munaut @ 2006-07-27 19:15 UTC (permalink / raw)
To: John Rigby; +Cc: linuxppc-embedded
In-Reply-To: <4b73d43f0607271030o7170e8dcn28bd3f62ec243426@mail.gmail.com>
Hi John,
Frankly ... I don't know, I don't get how this new thing works ...
if you figure it out, be my guest do it and explain it to me ;)
It would be great because I get this cleaned API sitting on my
tree along with the IDE DMA and the FEC code that I'd really
like to send ...
Sylvain
John Rigby wrote:
> Sylvain,
>
> How can I help getting the mpc5200 migrated to the powerpc tree?
> I should have some time to help with this.
>
> After we get it migrated we can get the bestcomm code in and
> the various drivers that use it.
>
> Also, did you ever get a liteb board? If not send me your address
> and I will try again to get you one.
>
> Thanks
> John
>
> On 7/17/06, Sylvain Munaut <tnt@246tnt.com> wrote:
>> Benjamin Herrenschmidt wrote:
>> >> But anyway, it's mainly internal cleanup and adapting drivers
>> >> from the public version on my git tree to this newest/cleaner
>> >> version is a 15 min work ;)
>> >>
>> >
>> > Any reason why you aren't regulary submitting those patches for
>> upstream
>> > inclusion ?
>> >
>> Yes. What's in there and not in main streams adds quite a lot to
>> arch/ppc ... So
>> MPC5200 should be adapted to arch/powerpc first and then those changes.
>> And since
>> no-one did that yet and I haven't done it yet either ... (I must admit I
>> had a quick look
>> and I didn't understand much on how to do the change ...)
>>
>>
>> Sylvain
>>
>>
>> PS: Sorry for the lag (like 15 days...) you know email
>> problem/appartement change/vacation/... the usual ;)
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 18:50 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <67FD272C-C378-4549-8B35-70912AFAB7EF@kernel.crashing.org>
>> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
>> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
>
> These two lines don't need the msi.o and msi-altix.o AFAICS.
s/altix/apic/. Duh.
Segher
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Segher Boessenkool @ 2006-07-27 18:46 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024834.29826.240.camel@goblue>
> Index: 2.6-msi/drivers/pci/Makefile
> ===================================================================
> --- 2.6-msi.orig/drivers/pci/Makefile
> +++ 2.6-msi/drivers/pci/Makefile
> @@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
> obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
> obj-$(CONFIG_X86_VISWS) += setup-irq.o
>
> -msiobj-y := msi.o msi-apic.o
> -msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
> -msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
> +msiobj-$(CONFIG_X86) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
> +msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
> +msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
These two lines don't need the msi.o and msi-altix.o AFAICS.
> +msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
I think this file should live in arch/powerpc, and so should this
Makefile fragment.
> +
> obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
>
> #
Other than that, can we please have the part that doesn't build the
"generic" MSI stuff included ASAP?
> Index: 2.6-msi/drivers/pci/msi-rtas.c
Maybe msi-papr.c is a better name btw? Not that I care :-)
No comments on your actual code, sorry.
Segher
^ permalink raw reply
* Re: [PATCH][1/2] export msi symbols
From: Segher Boessenkool @ 2006-07-27 18:41 UTC (permalink / raw)
To: Jake Moilanen; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1154024245.29826.231.camel@goblue>
> Forgot to export symbols for MSI.
>
> Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
Acked-by: Segher Boessenkool <segher@kernel.crashing.org>
^ permalink raw reply
* [PATCH][2/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 18:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1154024154.29826.229.camel@goblue>
Rebased with the IRQ layer rewrite. The code is not deallocating the
vectors on a pci_disable_msi(). This is to work around a firmware
vector release bug. Plus it is really not needed, as
irq_create_mapping() just returns mappings to irqs that it knows of.
Additionally, the patch includes the client architecture bit for MSI,
and correctly identifying that MSI is edge triggered.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/prom_init.c | 8 ++
arch/powerpc/platforms/pseries/setup.c | 4 +
arch/powerpc/platforms/pseries/xics.c | 5 -
drivers/pci/Kconfig | 2
drivers/pci/Makefile | 9 +-
drivers/pci/msi-rtas.c | 111
+++++++++++++++++++++++++++++++++
include/asm-powerpc/rtas.h | 4 +
7 files changed, 136 insertions(+), 7 deletions(-)
Index: 2.6-msi/drivers/pci/Makefile
===================================================================
--- 2.6-msi.orig/drivers/pci/Makefile
+++ 2.6-msi/drivers/pci/Makefile
@@ -27,9 +27,12 @@ obj-$(CONFIG_PPC64) += setup-bus.o
obj-$(CONFIG_MIPS) += setup-bus.o setup-irq.o
obj-$(CONFIG_X86_VISWS) += setup-irq.o
-msiobj-y := msi.o msi-apic.o
-msiobj-$(CONFIG_IA64_GENERIC) += msi-altix.o
-msiobj-$(CONFIG_IA64_SGI_SN2) += msi-altix.o
+msiobj-$(CONFIG_X86) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64) += msi.o msi-apic.o
+msiobj-$(CONFIG_IA64_GENERIC) += msi.o msi-apic.o msi-altix.o
+msiobj-$(CONFIG_IA64_SGI_SN2) += msi.o msi-apic.o msi-altix.o
+msiobj-$(CONFIG_PPC_PSERIES) += msi-rtas.o
+
obj-$(CONFIG_PCI_MSI) += $(msiobj-y)
#
Index: 2.6-msi/drivers/pci/msi-rtas.c
===================================================================
--- /dev/null
+++ 2.6-msi/drivers/pci/msi-rtas.c
@@ -0,0 +1,111 @@
+/*
+ * Jake Moilanen <moilanen@austin.ibm.com>
+ * Copyright (C) 2006 IBM
+ *
+ * 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; version 2 of the
+ * License.
+ *
+ */
+
+#include <linux/pci.h>
+#include <linux/irq.h>
+#include <asm/rtas.h>
+#include <asm/hw_irq.h>
+#include <asm/ppc-pci.h>
+
+int rtas_enable_msi(struct pci_dev* pdev)
+{
+ static int seq_num = 1;
+ int i;
+ int rc;
+ int query_token = rtas_token("ibm,query-interrupt-source-number");
+ int devfn;
+ int busno;
+ u32 *reg;
+ int reglen;
+ int ret[3];
+ int dummy;
+ int n_intr;
+ int last_virq = NO_IRQ;
+ int virq;
+ unsigned int addr;
+ unsigned long buid = -1;
+ struct device_node * dn;
+
+ dn = pci_device_to_OF_node(pdev);
+
+ if (!of_find_property(dn, "ibm,req#msi", &dummy))
+ return -ENOENT;
+
+ reg = (u32 *) get_property(dn, "reg", ®len);
+ if (reg == NULL || reglen < 20)
+ return -ENXIO;
+
+ devfn = (reg[0] >> 8) & 0xff;
+ busno = (reg[0] >> 16) & 0xff;
+
+ buid = get_phb_buid(dn->parent);
+ addr = (busno << 16) | (devfn << 8);
+
+ do {
+ rc = rtas_call(rtas_token("ibm,change-msi"), 6, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff,
+ 0, 0, seq_num);
+
+ seq_num = ret[1];
+ } while (rtas_busy_delay(rc));
+
+ if (rc) {
+ printk(KERN_WARNING "error[%d]: getting the number of "
+ "MSI interrupts for %s\n", rc, dn->name);
+ return -EIO;
+ }
+
+ /* Return if there's no MSI interrupts */
+ if (!ret[0])
+ return -ENOENT;
+
+ n_intr = ret[0];
+
+ for (i = 0; i < n_intr; i++) {
+ do {
+ rc = rtas_call(query_token, 4, 3, ret, addr,
+ buid >> 32, buid & 0xffffffff, i);
+ } while (rtas_busy_delay(rc));
+
+ if (!rc) {
+ virq = irq_create_mapping(irq_find_host(dn), ret[0],
+ ret[1] ? IRQ_TYPE_EDGE_RISING :
+ IRQ_TYPE_LEVEL_LOW);
+
+ /* for now, take the last valid vector given out */
+ if (virq != NO_IRQ)
+ last_virq = virq;
+
+ } else {
+ printk(KERN_WARNING "error[%d]: "
+ "query-interrupt-source-number for %s\n",
+ rc, dn->name);
+ }
+ }
+
+ /*
+ * If we can't get any MSI vectors, fail and try falling
+ * back to LSI
+ */
+ if (last_virq == NO_IRQ)
+ return -EIO;
+
+ pdev->irq = last_virq;
+
+ return 0;
+}
+
+void rtas_disable_msi(struct pci_dev* pdev)
+{
+ /*
+ * for now, we don't give firmware back vectors to their pool
+ */
+}
Index: 2.6-msi/drivers/pci/Kconfig
===================================================================
--- 2.6-msi.orig/drivers/pci/Kconfig
+++ 2.6-msi/drivers/pci/Kconfig
@@ -4,7 +4,7 @@
config PCI_MSI
bool "Message Signaled Interrupts (MSI and MSI-X)"
depends on PCI
- depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64
+ depends on (X86_LOCAL_APIC && X86_IO_APIC) || IA64 || PPC_PSERIES
help
This allows device drivers to enable MSI (Message Signaled
Interrupts). Message Signaled Interrupts enable a device to
Index: 2.6-msi/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/setup.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/setup.c
@@ -267,6 +267,10 @@ static void __init pseries_discover_pic(
return;
} else if (strstr(typep, "ppc-xicp")) {
ppc_md.init_IRQ = xics_init_IRQ;
+#ifdef CONFIG_PCI_MSI
+ ppc_md.enable_msi = rtas_enable_msi;
+ ppc_md.disable_msi = rtas_disable_msi;
+#endif
#ifdef CONFIG_KEXEC
ppc_md.kexec_cpu_down = pseries_kexec_cpu_down_xics;
#endif
Index: 2.6-msi/include/asm-powerpc/rtas.h
===================================================================
--- 2.6-msi.orig/include/asm-powerpc/rtas.h
+++ 2.6-msi/include/asm-powerpc/rtas.h
@@ -4,6 +4,7 @@
#include <linux/spinlock.h>
#include <asm/page.h>
+#include <linux/pci.h>
/*
* Definitions for talking to the RTAS on CHRP machines.
@@ -186,6 +187,9 @@ extern int early_init_dt_scan_rtas(unsig
extern void pSeries_log_error(char *buf, unsigned int err_type, int
fatal);
+extern int rtas_enable_msi(struct pci_dev* pdev);
+extern void rtas_disable_msi(struct pci_dev * pdev);
+
/* Error types logged. */
#define ERR_FLAG_ALREADY_LOGGED 0x0
#define ERR_FLAG_BOOT 0x1 /* log was pulled from NVRAM on boot */
Index: 2.6-msi/arch/powerpc/kernel/prom_init.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/prom_init.c
+++ 2.6-msi/arch/powerpc/kernel/prom_init.c
@@ -632,6 +632,12 @@ static void __init early_cmdline_parse(v
/* ibm,dynamic-reconfiguration-memory property supported */
#define OV5_DRCONF_MEMORY 0x20
#define OV5_LARGE_PAGES 0x10 /* large pages supported */
+/* PCIe/MSI support. Without MSI full PCIe is not supported */
+#ifdef CONFIG_PCI_MSI
+#define OV5_MSI 0x01 /* PCIe/MSI support */
+#else
+#define OV5_MSI 0x00
+#endif /* CONFIG_PCI_MSI */
/*
* The architecture vector has an array of PVR mask/value pairs,
@@ -675,7 +681,7 @@ static unsigned char ibm_architecture_ve
/* option vector 5: PAPR/OF options */
3 - 1, /* length */
0, /* don't ignore, don't halt */
- OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES,
+ OV5_LPAR | OV5_SPLPAR | OV5_LARGE_PAGES | OV5_MSI,
};
/* Old method - ELF header with PT_NOTE sections */
Index: 2.6-msi/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/platforms/pseries/xics.c
+++ 2.6-msi/arch/powerpc/platforms/pseries/xics.c
@@ -526,11 +526,12 @@ static int xics_host_map_lpar(struct irq
pr_debug("xics: map_lpar virq %d, hwirq 0x%lx, flags: 0x%x\n",
virq, hw, flags);
- if (sense && sense != IRQ_TYPE_LEVEL_LOW)
+ if (sense && !(sense & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_RISING)))
printk(KERN_WARNING "xics: using unsupported sense 0x%x"
" for irq %d (h: 0x%lx)\n", flags, virq, hw);
- get_irq_desc(virq)->status |= IRQ_LEVEL;
+ if (sense && sense & IRQ_TYPE_LEVEL_LOW)
+ get_irq_desc(virq)->status |= IRQ_LEVEL;
set_irq_chip_and_handler(virq, &xics_pic_lpar, handle_fasteoi_irq);
return 0;
}
^ permalink raw reply
* [PATCH][1/2] export msi symbols
From: Jake Moilanen @ 2006-07-27 18:17 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1154024154.29826.229.camel@goblue>
Forgot to export symbols for MSI.
Signed-off-by: Jake Moilanen <moilanen@austin.ibm.com>
arch/powerpc/kernel/irq.c | 5 +++++
1 files changed, 5 insertions(+)
Index: 2.6-msi/arch/powerpc/kernel/irq.c
===================================================================
--- 2.6-msi.orig/arch/powerpc/kernel/irq.c
+++ 2.6-msi/arch/powerpc/kernel/irq.c
@@ -52,6 +52,7 @@
#include <linux/radix-tree.h>
#include <linux/mutex.h>
#include <linux/bootmem.h>
+#include <linux/pci.h>
#include <asm/uaccess.h>
#include <asm/system.h>
@@ -818,12 +819,14 @@ int pci_enable_msi(struct pci_dev * pdev
else
return -1;
}
+EXPORT_SYMBOL(pci_enable_msi);
void pci_disable_msi(struct pci_dev * pdev)
{
if (ppc_md.disable_msi)
ppc_md.disable_msi(pdev);
}
+EXPORT_SYMBOL(pci_disable_msi);
void pci_scan_msi_device(struct pci_dev *dev) {}
int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries,
int nvec) {return -1;}
@@ -831,6 +834,8 @@ void pci_disable_msix(struct pci_dev *de
void msi_remove_pci_irq_vectors(struct pci_dev *dev) {}
void disable_msi_mode(struct pci_dev *dev, int pos, int type) {}
void pci_no_msi(void) {}
+EXPORT_SYMBOL(pci_enable_msix);
+EXPORT_SYMBOL(pci_disable_msix);
#endif
^ permalink raw reply
* [PATCH][0/2] RTAS MSI
From: Jake Moilanen @ 2006-07-27 18:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is a rebased RTAS MSI which uses the IRQ layer rewrite. Please try
getting it into 2.6.18.
I mistakenly forgot to export the MSI symbols. So modules weren't too
happy...
The RTAS patch skips the intel-centric MSI layer and uses
pci_enable/disable_msi() calls directly. It does not correctly handle
multi-vector MSI either.
^ permalink raw reply
* Fw: AvNet FX12 Mini Modules
From: Ing.Gianfranco Morandi @ 2006-07-27 17:49 UTC (permalink / raw)
To: Linux PPC Embedded
Hello everyone,
I would like to start using the AvNet FX12 Mini module in our embedded
project and unfotunately I do not have a great knowledge on how to use linux
on FPGA.
Can anyone give me any suggestions or reference project where I can start?
any suggestions would be apreciated.
regards
Gianfranco
^ permalink raw reply
* Re: Using bestcomm in an external module (MPC5200B to be exact)
From: John Rigby @ 2006-07-27 17:30 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <44BC0B9A.5010103@246tNt.com>
Sylvain,
How can I help getting the mpc5200 migrated to the powerpc tree?
I should have some time to help with this.
After we get it migrated we can get the bestcomm code in and
the various drivers that use it.
Also, did you ever get a liteb board? If not send me your address
and I will try again to get you one.
Thanks
John
On 7/17/06, Sylvain Munaut <tnt@246tnt.com> wrote:
> Benjamin Herrenschmidt wrote:
> >> But anyway, it's mainly internal cleanup and adapting drivers
> >> from the public version on my git tree to this newest/cleaner
> >> version is a 15 min work ;)
> >>
> >
> > Any reason why you aren't regulary submitting those patches for upstream
> > inclusion ?
> >
> Yes. What's in there and not in main streams adds quite a lot to
> arch/ppc ... So
> MPC5200 should be adapted to arch/powerpc first and then those changes.
> And since
> no-one did that yet and I haven't done it yet either ... (I must admit I
> had a quick look
> and I didn't understand much on how to do the change ...)
>
>
> Sylvain
>
>
> PS: Sorry for the lag (like 15 days...) you know email
> problem/appartement change/vacation/... the usual ;)
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Where to store the Linux kernel.
From: Tony Lee @ 2006-07-27 16:52 UTC (permalink / raw)
To: Frank D Lombardo; +Cc: linuxppc-embedded
In-Reply-To: <44C8DC19.9030600@mdivac.com>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
I used the VP20 before. You can use the Xilinx's tool to generate the .ace
file from the .elf, bit stream, etc and put it in the CF.
It is very simple ponce you do it once and Xilinx has very good app note to
tell you exactly what need to do.
-Tony
On 7/27/06, Frank D Lombardo <lombardo@mdivac.com> wrote:
>
> Ming,
>
> I am using an ML403 in a similar way. I have the download.bit file
> stored in platform flash. U-Boot, the Linux Kernel and initrd are stored
> in the linear flash.
>
> Frank
>
>
> Ming Liu wrote:
> > Hello everyone,
> > Now I am doing a embedded linux project on the board of ML403(virtex4,
> > ppc405). In my product, I cannot use CF card. So I have to use flash
> memory
> > to store the Linux kernel. Except for the Linux kernel, also I have to
> > store the hardware information of the system.bit file. I know in ml403
> > board, there are two types of flash. One is Platform Flash and the other
> is
> > Linear Flash. Can anyone tell me how can I arrange my hardware .bit file
> > and Linux kernel zImage.elf file and store them in the flash provided in
> > the board? Can I put both of them in the Platform Flash chip? Thanks for
> > the telling.
> >
> > Regards
> > Ming
> >
> > _________________________________________________________________
> > 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
> >
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
-Tony
Having fun with FPGA, gige, mpeg, snmp, ppc, Linux
[-- Attachment #2: Type: text/html, Size: 2488 bytes --]
^ permalink raw reply
* Re: Where to store the Linux kernel.
From: Frank D Lombardo @ 2006-07-27 15:30 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY110-F64D7B98642F2626AA4E90B2580@phx.gbl>
Ming,
I am using an ML403 in a similar way. I have the download.bit file
stored in platform flash. U-Boot, the Linux Kernel and initrd are stored
in the linear flash.
Frank
Ming Liu wrote:
> Hello everyone,
> Now I am doing a embedded linux project on the board of ML403(virtex4,
> ppc405). In my product, I cannot use CF card. So I have to use flash memory
> to store the Linux kernel. Except for the Linux kernel, also I have to
> store the hardware information of the system.bit file. I know in ml403
> board, there are two types of flash. One is Platform Flash and the other is
> Linear Flash. Can anyone tell me how can I arrange my hardware .bit file
> and Linux kernel zImage.elf file and store them in the flash provided in
> the board? Can I put both of them in the Platform Flash chip? Thanks for
> the telling.
>
> Regards
> Ming
>
> _________________________________________________________________
> 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Kumar Gala @ 2006-07-27 15:37 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Patrick J. Kelsey
In-Reply-To: <5744F4FC-32DC-4F24-9FD4-E6CAC4AFA6A4@freescale.com>
On Jul 27, 2006, at 10:30 AM, Andy Fleming wrote:
> Branch delay slots are evil, and PowerPC did not use them.
>
> 'nuff said.
>
> Pretty much any powerpc binary should work on any PowerPC system.
> Actually, we use a 603-compiled root file system for our e500
> processors (in our lab), and don't run into any problems. This is
Let's be clear, that is done by emulating the floating point
instructions in the kernel. (And there are a few user space integer/
control instructions that e500 doesn't implement, but your rarely run
into them).
- k
> On Jul 27, 2006, at 07:36, Jerry Van Baren wrote:
>
>> Patrick J. Kelsey wrote:
>>> (sorry about that last one. had a bit of trouble with a certain
>>> web based mail client...)
>>>
>>> Thanks for the reply, Kumar.
>>>
>>> That sounds encouraging. One of the things I was worried about with
>>> scheduling differences would be a differing number of branch delay
>>> slots between the two core versions. I'm still a bit new to the
>>> details of the PowerPC architecture, and at this point I'm not even
>>> sure if there are branch delay slots, although it does seem from my
>>> reading that the 603e and 750 pipelines are the same, in which case
>>> there would ceratinly be no worries here.
>>
>> FWIIW, the PowerPC architecture has hardware instruction interlocking
>> and scheduling and doesn't require the compiler to implement the
>> branch
>> delay slots like, for instance, the MIPS architecture. This is much
>> more compiler and portability friendly, but at the expense of more
>> logic
>> in the processor (the PowerPC is not nearly as minimalistic as the
>> MIPS).
>>
>>> At this point, I'm not concerned so much about an inefficient
>>> schedule resulting from running -mcpu=750 code on a 603e as long as
>>> the execution is correct.
>>>
>>> Pat
>>
>> gvb
>> _______________________________________________
>> 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
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Andy Fleming @ 2006-07-27 15:30 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev, Patrick J. Kelsey
In-Reply-To: <44C8B330.7030600@smiths-aerospace.com>
Branch delay slots are evil, and PowerPC did not use them.
'nuff said.
Pretty much any powerpc binary should work on any PowerPC system.
Actually, we use a 603-compiled root file system for our e500
processors (in our lab), and don't run into any problems. This is
On Jul 27, 2006, at 07:36, Jerry Van Baren wrote:
> Patrick J. Kelsey wrote:
>> (sorry about that last one. had a bit of trouble with a certain
>> web based mail client...)
>>
>> Thanks for the reply, Kumar.
>>
>> That sounds encouraging. One of the things I was worried about with
>> scheduling differences would be a differing number of branch delay
>> slots between the two core versions. I'm still a bit new to the
>> details of the PowerPC architecture, and at this point I'm not even
>> sure if there are branch delay slots, although it does seem from my
>> reading that the 603e and 750 pipelines are the same, in which case
>> there would ceratinly be no worries here.
>
> FWIIW, the PowerPC architecture has hardware instruction interlocking
> and scheduling and doesn't require the compiler to implement the
> branch
> delay slots like, for instance, the MIPS architecture. This is much
> more compiler and portability friendly, but at the expense of more
> logic
> in the processor (the PowerPC is not nearly as minimalistic as the
> MIPS).
>
>> At this point, I'm not concerned so much about an inefficient
>> schedule resulting from running -mcpu=750 code on a 603e as long as
>> the execution is correct.
>>
>> Pat
>
> gvb
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Where to store the Linux kernel.
From: Ming Liu @ 2006-07-27 12:49 UTC (permalink / raw)
To: linuxppc-embedded
Hello everyone,
Now I am doing a embedded linux project on the board of ML403(virtex4,
ppc405). In my product, I cannot use CF card. So I have to use flash memory
to store the Linux kernel. Except for the Linux kernel, also I have to
store the hardware information of the system.bit file. I know in ml403
board, there are two types of flash. One is Platform Flash and the other is
Linear Flash. Can anyone tell me how can I arrange my hardware .bit file
and Linux kernel zImage.elf file and store them in the flash provided in
the board? Can I put both of them in the Platform Flash chip? Thanks for
the telling.
Regards
Ming
_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Jerry Van Baren @ 2006-07-27 12:36 UTC (permalink / raw)
To: Patrick J. Kelsey; +Cc: linuxppc-dev
In-Reply-To: <A958F7B12F59EC408E904A912CDE3DAE3D6A0A@cvn68.fairmountautomation.com>
Patrick J. Kelsey wrote:
> (sorry about that last one. had a bit of trouble with a certain web based mail client...)
>
> Thanks for the reply, Kumar.
>
> That sounds encouraging. One of the things I was worried about with
> scheduling differences would be a differing number of branch delay
> slots between the two core versions. I'm still a bit new to the
> details of the PowerPC architecture, and at this point I'm not even
> sure if there are branch delay slots, although it does seem from my
> reading that the 603e and 750 pipelines are the same, in which case
> there would ceratinly be no worries here.
FWIIW, the PowerPC architecture has hardware instruction interlocking
and scheduling and doesn't require the compiler to implement the branch
delay slots like, for instance, the MIPS architecture. This is much
more compiler and portability friendly, but at the expense of more logic
in the processor (the PowerPC is not nearly as minimalistic as the MIPS).
> At this point, I'm not concerned so much about an inefficient
> schedule resulting from running -mcpu=750 code on a 603e as long as
> the execution is correct.
>
> Pat
gvb
^ permalink raw reply
* RE: Can 750 user-mode binaries run on a 603e core?
From: Patrick J. Kelsey @ 2006-07-27 12:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <002701c6b16f$af134640$99dfdfdf@bakuhatsu.net>
VGhhbmtzLCBNYXR0Lg0KIA0KRXZlcnl0aGluZyBJIHdhcyByZWFkaW5nIGFib3V0IGJpbmFyeSBj
b21wYXRpYmlsaXR5IHdhcyBvcmllbnRlZCBpbiB0aGUgJ3JlZ3VsYXInIGRpcmVjdGlvbiwgYXNz
dXJpbmcgbWUgdGhhdCA2MDNlIGJpbmFyaWVzIHdvdWxkIHJ1biBvbiB0aGUgNzUwIGp1c3QgZmlu
ZS4gIEknbSBnbGFkIHRvIGhlYXIgdGhhdCBpdCBydW5zIGluIHRoZSBvdGhlciBkaXJlY3Rpb24g
YWxzbyAoYXQgbGVhc3QgZm9yIGludGVnZXIgYW5kIEZQVSBjb2RlLCB3aGljaCBpcyBnb29kIGVu
b3VnaCBmb3IgbWUpLg0KIA0KUGF0DQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglG
cm9tOiBNYXR0IFNlYWxleSBbbWFpbHRvOm1hdHRAZ2VuZXNpLXVzYS5jb21dIA0KCVNlbnQ6IFRo
dSA3LzI3LzIwMDYgNzoyNyBBTSANCglUbzogUGF0cmljayBKLiBLZWxzZXk7IGxpbnV4cHBjLWRl
dkBvemxhYnMub3JnIA0KCUNjOiANCglTdWJqZWN0OiBSRTogQ2FuIDc1MCB1c2VyLW1vZGUgYmlu
YXJpZXMgcnVuIG9uIGEgNjAzZSBjb3JlPw0KCQ0KCQ0KDQoNCglUaGUgNjAzLzYwM2UgaGFzIDEg
aW50ZWdlciB1bml0LiBUaGUgNjA0LzYwNGUgYW5kIDd4eCBsaW5lcyBoYWQNCgkyLg0KCQ0KCUJh
c2ljYWxseSBpZiB5b3Ugb3B0aW1pemUgZm9yIHRoZSA3NTAgaXQgbWF5IHF1ZXVlIHVwIGludGVn
ZXINCglvcHMgYXNzdW1pbmcgdGhlcmUgaXMgcm9vbSB0byBleGVjdXRlIHRoZW0gc2ltdWx0YW5l
b3VzbHksIHdoZW4NCglpbiBmYWN0IHRoZXJlIGlzbid0Lg0KCQ0KCUJ1dCBhcyBrdW1hciBzYWlk
LCB1c2Vyc3BhY2UgaXMgYWJzb2x1dGVseSBwb3NpdGl2ZWx5IGlkZW50aWNhbCwNCgl0aGUgY2hp
cHMgZnJvbSA2MDNlIHRvIHRoZSBsYXRlc3QgRzQgYXJlIGVudGlyZWx5IGJpbmFyeQ0KCWNvbXBh
dGlibGUgZm9yIGludGVnZXIgYW5kIEZQVSBjb2RlLiBNb3N0IHBlb3BsZSBqdXN0IG9wdGltaXpl
DQoJZm9yIHRoZSA2MDNlIGFuZCBsZXQgdGhlIENQVSBoYW5kbGUgdGhlIHJlc3QuDQoJDQoJLS0N
CglNYXR0IFNlYWxleSA8bWF0dEBnZW5lc2ktdXNhLmNvbT4NCglNYW5hZ2VyLCBHZW5lc2ksIERl
dmVsb3BlciBSZWxhdGlvbnMNCgkNCgkNCgk+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoJ
PiBGcm9tOiBsaW51eHBwYy1kZXYtYm91bmNlcyttYXR0PWdlbmVzaS11c2EuY29tQG96bGFicy5v
cmcNCgk+IFttYWlsdG86bGludXhwcGMtZGV2LWJvdW5jZXMrbWF0dD1nZW5lc2ktdXNhLmNvbUBv
emxhYnMub3JnXQ0KCT4gT24gQmVoYWxmIE9mIFBhdHJpY2sgSi4gS2Vsc2V5DQoJPiBTZW50OiBU
aHVyc2RheSwgSnVseSAyNywgMjAwNiA1OjU0IEFNDQoJPiBUbzogbGludXhwcGMtZGV2QG96bGFi
cy5vcmcNCgk+IFN1YmplY3Q6IFJFOiBDYW4gNzUwIHVzZXItbW9kZSBiaW5hcmllcyBydW4gb24g
YSA2MDNlIGNvcmU/DQoJPg0KCT4gKHNvcnJ5IGFib3V0IHRoYXQgbGFzdCBvbmUuIGhhZCBhIGJp
dCBvZiB0cm91YmxlIHdpdGggYQ0KCT4gY2VydGFpbiB3ZWIgYmFzZWQgbWFpbCBjbGllbnQuLi4p
DQoJPiANCgk+IFRoYW5rcyBmb3IgdGhlIHJlcGx5LCBLdW1hci4NCgk+IA0KCT4gVGhhdCBzb3Vu
ZHMgZW5jb3VyYWdpbmcuICBPbmUgb2YgdGhlIHRoaW5ncyBJIHdhcyB3b3JyaWVkDQoJPiBhYm91
dCB3aXRoIHNjaGVkdWxpbmcgZGlmZmVyZW5jZXMgd291bGQgYmUgYSBkaWZmZXJpbmcgbnVtYmVy
DQoJPiBvZiBicmFuY2ggZGVsYXkgc2xvdHMgYmV0d2VlbiB0aGUgdHdvIGNvcmUgdmVyc2lvbnMu
ICBJJ20NCgk+IHN0aWxsIGEgYml0IG5ldyB0byB0aGUgZGV0YWlscyBvZiB0aGUgUG93ZXJQQyBh
cmNoaXRlY3R1cmUsDQoJPiBhbmQgYXQgdGhpcyBwb2ludCBJJ20gbm90IGV2ZW4gc3VyZSBpZiB0
aGVyZSBhcmUgYnJhbmNoIGRlbGF5DQoJPiBzbG90cywgYWx0aG91Z2ggaXQgZG9lcyBzZWVtIGZy
b20gbXkgcmVhZGluZyB0aGF0IHRoZSA2MDNlDQoJPiBhbmQgNzUwIHBpcGVsaW5lcyBhcmUgdGhl
IHNhbWUsIGluIHdoaWNoIGNhc2UgdGhlcmUgd291bGQNCgk+IGNlcmF0aW5seSBiZSBubyB3b3Jy
aWVzIGhlcmUuDQoJPiANCgk+IEF0IHRoaXMgcG9pbnQsIEknbSBub3QgY29uY2VybmVkIHNvIG11
Y2ggYWJvdXQgYW4gaW5lZmZpY2llbnQNCgk+IHNjaGVkdWxlIHJlc3VsdGluZyBmcm9tIHJ1bm5p
bmcgLW1jcHU9NzUwIGNvZGUgb24gYSA2MDNlIGFzDQoJPiBsb25nIGFzIHRoZSBleGVjdXRpb24g
aXMgY29ycmVjdC4NCgk+IA0KCT4gUGF0DQoJPiANCgk+DQoJPiAgICAgICAtLS0tLU9yaWdpbmFs
IE1lc3NhZ2UtLS0tLQ0KCT4gICAgICAgRnJvbToNCgk+IGxpbnV4cHBjLWRldi1ib3VuY2VzK2tl
bHNleXBqPWZhaXJtb3VudGF1dG9tYXRpb24uY29tQG96bGFicy5vDQoJPiByZyBvbiBiZWhhbGYg
b2YgS3VtYXIgR2FsYQ0KCT4gICAgICAgU2VudDogV2VkIDcvMjYvMjAwNiA4OjA0IFBNDQoJPiAg
ICAgICBUbzogUGF0cmljayBKLiBLZWxzZXkNCgk+ICAgICAgIENjOiBsaW51eHBwYy1kZXZAb3ps
YWJzLm9yZw0KCT4gICAgICAgU3ViamVjdDogUmU6IENhbiA3NTAgdXNlci1tb2RlIGJpbmFyaWVz
IHJ1biBvbiBhIDYwM2UgY29yZT8NCgk+ICAgICAgDQoJPiAgICAgIA0KCT4NCgk+DQoJPiAgICAg
ICBPbiBKdWwgMjYsIDIwMDYsIGF0IDU6MjcgUE0sIFBhdHJpY2sgSi4gS2Vsc2V5IHdyb3RlOg0K
CT4gICAgICANCgk+ICAgICAgID4gSGksDQoJPiAgICAgICA+DQoJPiAgICAgICA+IElmIGhhdmUg
dXNlci1tb2RlIGJpbmFyaWVzIGJ1aWx0IGZvciBhIDc1MCBjb3JlLCBzYXkNCgk+IHdpdGggZ2Nj
IC0NCgk+ICAgICAgID4gbWNwdT03NTAsIHNob3VsZCBJIGV4cGVjdCB0aGVtIHRvIHJ1biBvbiBh
IDYwM2UgY29yZT8NCgk+ICBXb3VsZCBJIGhhdmUNCgk+ICAgICAgID4gdG8gd29ycnkgYWJvdXQg
dW5zdXBwb3J0ZWQgaW5zdHJ1Y3Rpb25zIG9yDQoJPiBpbnN0cnVjdGlvbiBzY2hlZHVsaW5nDQoJ
PiAgICAgICA+IGlzc3Vlcz8NCgk+ICAgICAgID4NCgk+ICAgICAgID4gSWYgdGhlcmUncyBhIGJl
dHRlciBsaXN0IGZvciB0aGlzIHF1ZXN0aW9uLCBwbGVhc2UgYWR2aXNlLg0KCT4gICAgICANCgk+
ICAgICAgIFN1cmUsIHRoZXJlIGlzbid0IGRpZmZlcmVudCBpbiB0aGUgdXNlciBzcGFjZSBpbnN0
cnVjdGlvbiBzZXRzDQoJPiAgICAgICBiZXR3ZWVuIHRoZSA3NTAgYW5kIDYwM2UgY29yZS4gIFRo
ZSAtbWNwdSBpcyBvbmx5IHR3ZWFraW5nDQoJPiAgICAgICBpbnN0cnVjdGlvbiBzY2hlZHVsaW5n
IGFuZCBtYWtpbmcgaXQgc3BlY2lmaWMgZm9yIHRoZSA3NTAuICBUaGUNCgk+ICAgICAgIGluc3Ry
dWN0aW9uIHNjaGVkdWxpbmcgZGlmZmVyZW5jZXMgYXJlbid0IHRoYXQgaHVnZSBpZg0KCT4gbWVt
b3J5IHNlcnZlcw0KCT4gICAgICAgbWUgY29ycmVjdGx5LiAgVGhlIDc1MCBwcm9iYWJseSB0YWtl
cyBmZXdlciBjeWNsZXMgb24NCgk+IG11bHRpcGxlIGFuZA0KCT4gICAgICAgZGl2aWRlcy4gIEkg
Zm9yZ2V0IGlmIHRoZSA3NTAgaGFzIGFueSBhZGRpdGlvbmFsDQoJPiBleGVjdXRpb24gdW5pdHMg
dGhhdA0KCT4gICAgICAgdGhlIDYwM2UgZGlkbid0IGhhdmUgKGFkZGl0aW9uYWwgaW50ZWdlciB1
bml0cywgZXRjLikuDQoJPiAgICAgIA0KCT4gICAgICAgLSBrdW1hcg0KCT4gICAgICAgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCgk+ICAgICAgIExpbnV4
cHBjLWRldiBtYWlsaW5nIGxpc3QNCgk+ICAgICAgIExpbnV4cHBjLWRldkBvemxhYnMub3JnDQoJ
PiAgICAgICBodHRwczovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBwYy1kZXYN
Cgk+ICAgICAgDQoJPg0KCT4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCgk+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCgk+IExpbnV4cHBjLWRldkBv
emxhYnMub3JnDQoJPiBodHRwczovL296bGFicy5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eHBw
Yy1kZXYNCgk+DQoJDQoJDQoNCg==
^ permalink raw reply
* RE: Can 750 user-mode binaries run on a 603e core?
From: Matt Sealey @ 2006-07-27 11:27 UTC (permalink / raw)
To: 'Patrick J. Kelsey', linuxppc-dev
In-Reply-To: <A958F7B12F59EC408E904A912CDE3DAE3D6A0A@cvn68.fairmountautomation.com>
The 603/603e has 1 integer unit. The 604/604e and 7xx lines had
2.
Basically if you optimize for the 750 it may queue up integer
ops assuming there is room to execute them simultaneously, when
in fact there isn't.
But as kumar said, userspace is absolutely positively identical,
the chips from 603e to the latest G4 are entirely binary
compatible for integer and FPU code. Most people just optimize
for the 603e and let the CPU handle the rest.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
> -----Original Message-----
> From: linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matt=genesi-usa.com@ozlabs.org]
> On Behalf Of Patrick J. Kelsey
> Sent: Thursday, July 27, 2006 5:54 AM
> To: linuxppc-dev@ozlabs.org
> Subject: RE: Can 750 user-mode binaries run on a 603e core?
>
> (sorry about that last one. had a bit of trouble with a
> certain web based mail client...)
>
> Thanks for the reply, Kumar.
>
> That sounds encouraging. One of the things I was worried
> about with scheduling differences would be a differing number
> of branch delay slots between the two core versions. I'm
> still a bit new to the details of the PowerPC architecture,
> and at this point I'm not even sure if there are branch delay
> slots, although it does seem from my reading that the 603e
> and 750 pipelines are the same, in which case there would
> ceratinly be no worries here.
>
> At this point, I'm not concerned so much about an inefficient
> schedule resulting from running -mcpu=750 code on a 603e as
> long as the execution is correct.
>
> Pat
>
>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+kelseypj=fairmountautomation.com@ozlabs.o
> rg on behalf of Kumar Gala
> Sent: Wed 7/26/2006 8:04 PM
> To: Patrick J. Kelsey
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: Can 750 user-mode binaries run on a 603e core?
>
>
>
>
> On Jul 26, 2006, at 5:27 PM, Patrick J. Kelsey wrote:
>
> > Hi,
> >
> > If have user-mode binaries built for a 750 core, say
> with gcc -
> > mcpu=750, should I expect them to run on a 603e core?
> Would I have
> > to worry about unsupported instructions or
> instruction scheduling
> > issues?
> >
> > If there's a better list for this question, please advise.
>
> Sure, there isn't different in the user space instruction sets
> between the 750 and 603e core. The -mcpu is only tweaking
> instruction scheduling and making it specific for the 750. The
> instruction scheduling differences aren't that huge if
> memory serves
> me correctly. The 750 probably takes fewer cycles on
> multiple and
> divides. I forget if the 750 has any additional
> execution units that
> the 603e didn't have (additional integer units, etc.).
>
> - kumar
> _______________________________________________
> 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
>
^ permalink raw reply
* RE: Can 750 user-mode binaries run on a 603e core?
From: Patrick J. Kelsey @ 2006-07-27 3:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E7ECF775-1E54-4EE8-98DA-89FAD5C7C03A@kernel.crashing.org>
KHNvcnJ5IGFib3V0IHRoYXQgbGFzdCBvbmUuIGhhZCBhIGJpdCBvZiB0cm91YmxlIHdpdGggYSBj
ZXJ0YWluIHdlYiBiYXNlZCBtYWlsIGNsaWVudC4uLikgDQogDQpUaGFua3MgZm9yIHRoZSByZXBs
eSwgS3VtYXIuDQogDQpUaGF0IHNvdW5kcyBlbmNvdXJhZ2luZy4gIE9uZSBvZiB0aGUgdGhpbmdz
IEkgd2FzIHdvcnJpZWQgYWJvdXQgd2l0aCBzY2hlZHVsaW5nIGRpZmZlcmVuY2VzIHdvdWxkIGJl
IGEgZGlmZmVyaW5nIG51bWJlciBvZiBicmFuY2ggZGVsYXkgc2xvdHMgYmV0d2VlbiB0aGUgdHdv
IGNvcmUgdmVyc2lvbnMuICBJJ20gc3RpbGwgYSBiaXQgbmV3IHRvIHRoZSBkZXRhaWxzIG9mIHRo
ZSBQb3dlclBDIGFyY2hpdGVjdHVyZSwgYW5kIGF0IHRoaXMgcG9pbnQgSSdtIG5vdCBldmVuIHN1
cmUgaWYgdGhlcmUgYXJlIGJyYW5jaCBkZWxheSBzbG90cywgYWx0aG91Z2ggaXQgZG9lcyBzZWVt
IGZyb20gbXkgcmVhZGluZyB0aGF0IHRoZSA2MDNlIGFuZCA3NTAgcGlwZWxpbmVzIGFyZSB0aGUg
c2FtZSwgaW4gd2hpY2ggY2FzZSB0aGVyZSB3b3VsZCBjZXJhdGlubHkgYmUgbm8gd29ycmllcyBo
ZXJlLg0KIA0KQXQgdGhpcyBwb2ludCwgSSdtIG5vdCBjb25jZXJuZWQgc28gbXVjaCBhYm91dCBh
biBpbmVmZmljaWVudCBzY2hlZHVsZSByZXN1bHRpbmcgZnJvbSBydW5uaW5nIC1tY3B1PTc1MCBj
b2RlIG9uIGEgNjAzZSBhcyBsb25nIGFzIHRoZSBleGVjdXRpb24gaXMgY29ycmVjdC4NCiANClBh
dA0KIA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogbGludXhwcGMtZGV2
LWJvdW5jZXMra2Vsc2V5cGo9ZmFpcm1vdW50YXV0b21hdGlvbi5jb21Ab3psYWJzLm9yZyBvbiBi
ZWhhbGYgb2YgS3VtYXIgR2FsYSANCglTZW50OiBXZWQgNy8yNi8yMDA2IDg6MDQgUE0gDQoJVG86
IFBhdHJpY2sgSi4gS2Vsc2V5IA0KCUNjOiBsaW51eHBwYy1kZXZAb3psYWJzLm9yZyANCglTdWJq
ZWN0OiBSZTogQ2FuIDc1MCB1c2VyLW1vZGUgYmluYXJpZXMgcnVuIG9uIGEgNjAzZSBjb3JlPw0K
CQ0KCQ0KDQoNCglPbiBKdWwgMjYsIDIwMDYsIGF0IDU6MjcgUE0sIFBhdHJpY2sgSi4gS2Vsc2V5
IHdyb3RlOg0KCQ0KCT4gSGksDQoJPg0KCT4gSWYgaGF2ZSB1c2VyLW1vZGUgYmluYXJpZXMgYnVp
bHQgZm9yIGEgNzUwIGNvcmUsIHNheSB3aXRoIGdjYyAtDQoJPiBtY3B1PTc1MCwgc2hvdWxkIEkg
ZXhwZWN0IHRoZW0gdG8gcnVuIG9uIGEgNjAzZSBjb3JlPyAgV291bGQgSSBoYXZlIA0KCT4gdG8g
d29ycnkgYWJvdXQgdW5zdXBwb3J0ZWQgaW5zdHJ1Y3Rpb25zIG9yIGluc3RydWN0aW9uIHNjaGVk
dWxpbmcgDQoJPiBpc3N1ZXM/DQoJPg0KCT4gSWYgdGhlcmUncyBhIGJldHRlciBsaXN0IGZvciB0
aGlzIHF1ZXN0aW9uLCBwbGVhc2UgYWR2aXNlLg0KCQ0KCVN1cmUsIHRoZXJlIGlzbid0IGRpZmZl
cmVudCBpbiB0aGUgdXNlciBzcGFjZSBpbnN0cnVjdGlvbiBzZXRzIA0KCWJldHdlZW4gdGhlIDc1
MCBhbmQgNjAzZSBjb3JlLiAgVGhlIC1tY3B1IGlzIG9ubHkgdHdlYWtpbmcgDQoJaW5zdHJ1Y3Rp
b24gc2NoZWR1bGluZyBhbmQgbWFraW5nIGl0IHNwZWNpZmljIGZvciB0aGUgNzUwLiAgVGhlIA0K
CWluc3RydWN0aW9uIHNjaGVkdWxpbmcgZGlmZmVyZW5jZXMgYXJlbid0IHRoYXQgaHVnZSBpZiBt
ZW1vcnkgc2VydmVzIA0KCW1lIGNvcnJlY3RseS4gIFRoZSA3NTAgcHJvYmFibHkgdGFrZXMgZmV3
ZXIgY3ljbGVzIG9uIG11bHRpcGxlIGFuZCANCglkaXZpZGVzLiAgSSBmb3JnZXQgaWYgdGhlIDc1
MCBoYXMgYW55IGFkZGl0aW9uYWwgZXhlY3V0aW9uIHVuaXRzIHRoYXQgDQoJdGhlIDYwM2UgZGlk
bid0IGhhdmUgKGFkZGl0aW9uYWwgaW50ZWdlciB1bml0cywgZXRjLikuDQoJDQoJLSBrdW1hcg0K
CV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJTGludXhw
cGMtZGV2IG1haWxpbmcgbGlzdA0KCUxpbnV4cHBjLWRldkBvemxhYnMub3JnDQoJaHR0cHM6Ly9v
emxhYnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZGV2DQoJDQoNCg==
^ permalink raw reply
* RE: Can 750 user-mode binaries run on a 603e core?
From: Patrick J. Kelsey @ 2006-07-27 2:53 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <E7ECF775-1E54-4EE8-98DA-89FAD5C7C03A@kernel.crashing.org>
IA0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogbGludXhwcGMtZGV2LWJv
dW5jZXMra2Vsc2V5cGo9ZmFpcm1vdW50YXV0b21hdGlvbi5jb21Ab3psYWJzLm9yZyBvbiBiZWhh
bGYgb2YgS3VtYXIgR2FsYSANCglTZW50OiBXZWQgNy8yNi8yMDA2IDg6MDQgUE0gDQoJVG86IFBh
dHJpY2sgSi4gS2Vsc2V5IA0KCUNjOiBsaW51eHBwYy1kZXZAb3psYWJzLm9yZyANCglTdWJqZWN0
OiBSZTogQ2FuIDc1MCB1c2VyLW1vZGUgYmluYXJpZXMgcnVuIG9uIGEgNjAzZSBjb3JlPw0KCQ0K
CQ0KDQoNCglPbiBKdWwgMjYsIDIwMDYsIGF0IDU6MjcgUE0sIFBhdHJpY2sgSi4gS2Vsc2V5IHdy
b3RlOg0KCQ0KCT4gSGksDQoJPg0KCT4gSWYgaGF2ZSB1c2VyLW1vZGUgYmluYXJpZXMgYnVpbHQg
Zm9yIGEgNzUwIGNvcmUsIHNheSB3aXRoIGdjYyAtDQoJPiBtY3B1PTc1MCwgc2hvdWxkIEkgZXhw
ZWN0IHRoZW0gdG8gcnVuIG9uIGEgNjAzZSBjb3JlPyAgV291bGQgSSBoYXZlIA0KCT4gdG8gd29y
cnkgYWJvdXQgdW5zdXBwb3J0ZWQgaW5zdHJ1Y3Rpb25zIG9yIGluc3RydWN0aW9uIHNjaGVkdWxp
bmcgDQoJPiBpc3N1ZXM/DQoJPg0KCT4gSWYgdGhlcmUncyBhIGJldHRlciBsaXN0IGZvciB0aGlz
IHF1ZXN0aW9uLCBwbGVhc2UgYWR2aXNlLg0KCQ0KCVN1cmUsIHRoZXJlIGlzbid0IGRpZmZlcmVu
dCBpbiB0aGUgdXNlciBzcGFjZSBpbnN0cnVjdGlvbiBzZXRzIA0KCWJldHdlZW4gdGhlIDc1MCBh
bmQgNjAzZSBjb3JlLiAgVGhlIC1tY3B1IGlzIG9ubHkgdHdlYWtpbmcgDQoJaW5zdHJ1Y3Rpb24g
c2NoZWR1bGluZyBhbmQgbWFraW5nIGl0IHNwZWNpZmljIGZvciB0aGUgNzUwLiAgVGhlIA0KCWlu
c3RydWN0aW9uIHNjaGVkdWxpbmcgZGlmZmVyZW5jZXMgYXJlbid0IHRoYXQgaHVnZSBpZiBtZW1v
cnkgc2VydmVzIA0KCW1lIGNvcnJlY3RseS4gIFRoZSA3NTAgcHJvYmFibHkgdGFrZXMgZmV3ZXIg
Y3ljbGVzIG9uIG11bHRpcGxlIGFuZCANCglkaXZpZGVzLiAgSSBmb3JnZXQgaWYgdGhlIDc1MCBo
YXMgYW55IGFkZGl0aW9uYWwgZXhlY3V0aW9uIHVuaXRzIHRoYXQgDQoJdGhlIDYwM2UgZGlkbid0
IGhhdmUgKGFkZGl0aW9uYWwgaW50ZWdlciB1bml0cywgZXRjLikuDQoJDQoJLSBrdW1hcg0KCV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJTGludXhwcGMt
ZGV2IG1haWxpbmcgbGlzdA0KCUxpbnV4cHBjLWRldkBvemxhYnMub3JnDQoJaHR0cHM6Ly9vemxh
YnMub3JnL21haWxtYW4vbGlzdGluZm8vbGludXhwcGMtZGV2DQoJDQoNCg==
^ permalink raw reply
* Re: Can 750 user-mode binaries run on a 603e core?
From: Kumar Gala @ 2006-07-27 0:04 UTC (permalink / raw)
To: Patrick J. Kelsey; +Cc: linuxppc-dev
In-Reply-To: <A958F7B12F59EC408E904A912CDE3DAE3D6A07@cvn68.fairmountautomation.com>
On Jul 26, 2006, at 5:27 PM, Patrick J. Kelsey wrote:
> Hi,
>
> If have user-mode binaries built for a 750 core, say with gcc -
> mcpu=750, should I expect them to run on a 603e core? Would I have
> to worry about unsupported instructions or instruction scheduling
> issues?
>
> If there's a better list for this question, please advise.
Sure, there isn't different in the user space instruction sets
between the 750 and 603e core. The -mcpu is only tweaking
instruction scheduling and making it specific for the 750. The
instruction scheduling differences aren't that huge if memory serves
me correctly. The 750 probably takes fewer cycles on multiple and
divides. I forget if the 750 has any additional execution units that
the 603e didn't have (additional integer units, etc.).
- kumar
^ permalink raw reply
* Can 750 user-mode binaries run on a 603e core?
From: Patrick J. Kelsey @ 2006-07-26 22:27 UTC (permalink / raw)
To: linuxppc-dev
SGksDQogDQpJZiBoYXZlIHVzZXItbW9kZSBiaW5hcmllcyBidWlsdCBmb3IgYSA3NTAgY29yZSwg
c2F5IHdpdGggZ2NjIC1tY3B1PTc1MCwgc2hvdWxkIEkgZXhwZWN0IHRoZW0gdG8gcnVuIG9uIGEg
NjAzZSBjb3JlPyAgV291bGQgSSBoYXZlIHRvIHdvcnJ5IGFib3V0IHVuc3VwcG9ydGVkIGluc3Ry
dWN0aW9ucyBvciBpbnN0cnVjdGlvbiBzY2hlZHVsaW5nIGlzc3Vlcz8NCiANCklmIHRoZXJlJ3Mg
YSBiZXR0ZXIgbGlzdCBmb3IgdGhpcyBxdWVzdGlvbiwgcGxlYXNlIGFkdmlzZS4NCiANClRoYW5r
cywNClBhdA0K
^ permalink raw reply
* Re: [PATCH] Add rtas_set_indicator_fast() for RTAS call without extended delay
From: Nathan Lynch @ 2006-07-26 22:04 UTC (permalink / raw)
To: Haren Myneni; +Cc: Milton Miller II, Paul Mackerras, External List
In-Reply-To: <44C6F521.8040609@us.ibm.com>
Haren Myneni wrote:
> diff -Naurp 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2618-rc2/arch/powerpc/kernel/rtas.c
> --- 2618-rc2.orig/arch/powerpc/kernel/rtas.c 2006-07-25 19:34:11.000000000 -0700
> +++ 2618-rc2/arch/powerpc/kernel/rtas.c 2006-07-25 19:33:16.000000000 -0700
> @@ -569,6 +569,27 @@ int rtas_set_indicator(int indicator, in
> }
> EXPORT_SYMBOL(rtas_set_indicator);
>
> +/*
> + * Ignoring RTAS extended delay
> + */
> +int rtas_set_indicator_fast(int indicator, int index, int new_value)
> +{
> + int rc;
> + int token = rtas_token("set-indicator");
> +
> + if (token == RTAS_UNKNOWN_SERVICE)
> + return -ENOENT;
> +
> + rc = rtas_call(token, 3, 1, NULL, indicator, index, new_value);
> +
> + WARN_ON(rc == -2 || (rc >= 9900 && rc <= 9905));
> +
> + if (rc < 0)
> + return rtas_error_rc(rc);
> +
> + return rc;
> +}
> +
> void rtas_restart(char *cmd)
> {
> if (rtas_flash_term_hook)
> diff -Naurp 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2618-rc2/arch/powerpc/platforms/pseries/xics.c
> --- 2618-rc2.orig/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:34:41.000000000 -0700
> +++ 2618-rc2/arch/powerpc/platforms/pseries/xics.c 2006-07-25 19:33:36.000000000 -0700
> @@ -796,7 +796,7 @@ void xics_teardown_cpu(int secondary)
> * so leave the master cpu in the group.
> */
> if (secondary)
> - rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
> + rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
> (1UL << interrupt_server_size) - 1 -
> default_distrib_server, 0);
> }
> @@ -813,7 +813,7 @@ void xics_migrate_irqs_away(void)
> xics_set_cpu_priority(cpu, 0);
>
> /* remove ourselves from the global interrupt queue */
> - status = rtas_set_indicator(GLOBAL_INTERRUPT_QUEUE,
> + status = rtas_set_indicator_fast(GLOBAL_INTERRUPT_QUEUE,
> (1UL << interrupt_server_size) - 1 - default_distrib_server, 0);
> WARN_ON(status < 0);
>
Looks fine to me from a quick look, but we need to use
rtas_set_indicator_fast in xics_setup_cpu as well (I think I neglected
to mention I saw the warning in the cpu up path, sorry).
^ permalink raw reply
* Re: Serial issue
From: Lee Revell @ 2006-07-26 22:00 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1153950324.2927.6.camel@mindpipe>
On Wed, 2006-07-26 at 17:45 -0400, Lee Revell wrote:
> I'm trying to connect to a Yosemite 440 PPC board using the serial
> console. I've tried everything in every Linux Serial FAQ and HOWTO but
> no matter what, I can receive but I cannot transmit.
I've resolved the problem - unlike my reference system, with this host,
hardware flow control must be disabled for it to work.
Sorry for the noise.
Lee
^ 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