* Pegasos 2 support patch ...
@ 2004-06-29 16:50 Sven Luther
2004-06-29 20:42 ` Sven Luther
2004-06-30 9:18 ` Adrian Cox
0 siblings, 2 replies; 21+ messages in thread
From: Sven Luther @ 2004-06-29 16:50 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]
Hello,
Please find here attached a patch which adds support for the Pegasos 2
motherboard, and partial support for the Pegasos 1. I would like to have
some review of it, and if it is ok, see how it would be possible to have
it included in the main kernel. The patch is against 2.6.7.
The remaining problem for the pegasos 2 is with the via82cxxx ide
driver, which needs to support a different irq for both channels, thus
breakign when a device is present on the second ide channel. The
pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
naturally not fit for mainstream inclusion. I would welcome any hint on
how to solve this issue.
The pegasos1 support is not complete, but i believe this is due to some
brokeness in the OF. The main problem being that the translate function
is broken, and altough phys has the right value (0x00010000) before
calling it, it is 0 afterwards. I suppose the initial value is taken
from &_stext, so it should be feasible to detect that this is the
correct value before calling the translate OF method, or fixing it if we
detect a Pegasos 1 with the model OF property. Comments on this would
also be welcome. There may be some interrupt level thing left on pegasos
1 also, but i would need to check that.
Thanks for your comments,
Friendly,
Sven Luther
[-- Attachment #2: pegasos2.diff --]
[-- Type: text/plain, Size: 7094 bytes --]
diff -urN kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_pci.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_pci.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_pci.c 2004-06-16 07:20:26.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_pci.c 2004-06-29 18:10:43.951806408 +0200
@@ -97,8 +97,9 @@
rtas_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
+ struct pci_controller *hose = bus->sysdata;
unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
- | ((bus->number & 0xff) << 16);
+ | (((bus->number - hose->first_busno) & 0xff) << 16) | (pci_domain_nr(bus) << 24);
unsigned long ret = ~0UL;
int rval;
@@ -111,8 +112,9 @@
rtas_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 val)
{
+ struct pci_controller *hose = bus->sysdata;
unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
- | ((bus->number & 0xff) << 16);
+ | (((bus->number - hose->first_busno) & 0xff) << 16) | (pci_domain_nr(bus) << 24);
int rval;
rval = call_rtas("write-pci-config", 3, 1, NULL, addr, len, val);
@@ -186,6 +188,26 @@
iounmap(reg);
}
+/* Marvell Discovery II based Pegasos 2 */
+//#define PEGASOS_USE_PCI_DOMAINS
+
+static void __init
+setup_peg2(struct pci_controller *hose, struct device_node *dev)
+{
+ struct device_node *root = find_path_device("/");
+ struct device_node *rtas;
+
+ rtas = of_find_node_by_name (root, "rtas");
+ if (rtas) {
+ hose->ops = &rtas_pci_ops;
+ } else {
+ printk ("RTAS supporting Pegasos OF not found, please upgrade your firmware\n");
+ }
+#ifndef PEGASOS_USE_PCI_DOMAINS
+ pci_assign_all_busses = 1;
+#endif
+}
+
void __init
chrp_find_bridges(void)
{
@@ -195,7 +217,7 @@
struct pci_controller *hose;
unsigned int *dma;
char *model, *machine;
- int is_longtrail = 0, is_mot = 0;
+ int is_longtrail = 0, is_mot = 0, is_pegasos = 0;
struct device_node *root = find_path_device("/");
/*
@@ -207,6 +229,8 @@
if (machine != NULL) {
is_longtrail = strncmp(machine, "IBM,LongTrail", 13) == 0;
is_mot = strncmp(machine, "MOT", 3) == 0;
+ if (strncmp(machine, "Pegasos2", 8) == 0) is_pegasos = 2;
+ else if (strncmp(machine, "Pegasos", 7) == 0) is_pegasos = 1;
}
for (dev = root->child; dev != NULL; dev = dev->sibling) {
if (dev->type == NULL || strcmp(dev->type, "pci") != 0)
@@ -257,6 +281,10 @@
hose->cfg_data = (unsigned char *)
ioremap(GG2_PCI_CONFIG_BASE, 0x80000);
gg2_pci_config_base = (unsigned long) hose->cfg_data;
+ } else if (is_pegasos == 1) {
+ setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc);
+ } else if (is_pegasos == 2) {
+ setup_peg2(hose, dev);
} else {
printk("No methods for %s (model %s), using RTAS\n",
dev->full_name, model);
@@ -274,6 +302,9 @@
printk("pci_dram_offset = %lx\n", pci_dram_offset);
}
}
-
- ppc_md.pcibios_fixup = chrp_pcibios_fixup;
+
+ if (is_pegasos)
+ ppc_md.pcibios_fixup = NULL;
+ else
+ ppc_md.pcibios_fixup = chrp_pcibios_fixup;
}
diff -urN kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_setup.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_setup.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_setup.c 2004-06-16 07:19:52.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_setup.c 2004-06-29 18:10:44.191769928 +0200
@@ -214,6 +214,37 @@
}
}
+void pegasos_set_l2cr(void)
+{
+ struct device_node *root = find_path_device("/");
+ char *machine;
+ struct device_node *np;
+ int l2cr_value;
+
+ /* On Pegasos, enable the l2 cache if needed, as the OF forgets it */
+ if (root == NULL)
+ return;
+ machine = get_property(root, "model", NULL);
+ if (machine == NULL)
+ return;
+ if (strncmp(machine, "Pegasos", 7) == 0) {
+ /* Enable L2 cache if needed */
+ np = find_type_devices("cpu");
+ if (np != NULL) {
+ unsigned int *l2cr = (unsigned int *)
+ get_property (np, "l2cr", NULL);
+ if (l2cr == NULL) {
+ printk ("Pegasos l2cr : no cpu l2cr property found\n");
+ return;
+ }
+ if (!((*l2cr) & 0x80000000)) {
+ printk ("Pegasos l2cr : L2 cache was not active, activating\n");
+ _set_L2CR(0);
+ _set_L2CR((*l2cr) | 0x80000000);
+ }
+ }
+ }
+}
void __init
chrp_setup_arch(void)
@@ -236,6 +267,9 @@
/* Lookup PCI host bridges */
chrp_find_bridges();
+ /* On pegasos, enable the L2 cache if not already done by OF */
+ pegasos_set_l2cr();
+
#ifndef CONFIG_PPC64BRIDGE
/*
* Temporary fixes for PCI devices.
@@ -387,6 +421,8 @@
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
struct device_node *kbd;
#endif
+ struct device_node *root = find_path_device ("/");
+ char *machine;
for (np = find_devices("pci"); np != NULL; np = np->next) {
unsigned int *addrp = (unsigned int *)
@@ -400,16 +436,20 @@
if (np == NULL)
printk(KERN_ERR "Cannot find PCI interrupt acknowledge address\n");
- chrp_find_openpic();
-
- prom_get_irq_senses(init_senses, NUM_8259_INTERRUPTS, NR_IRQS);
- OpenPIC_InitSenses = init_senses;
- OpenPIC_NumInitSenses = NR_IRQS - NUM_8259_INTERRUPTS;
-
- openpic_init(NUM_8259_INTERRUPTS);
- /* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */
- openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
+ /* Pegasos doesn't have openpic */
+ machine = get_property(root, "model", NULL);
+ if (strncmp(machine, "Pegasos", 7) != 0) {
+ chrp_find_openpic();
+
+ prom_get_irq_senses(init_senses, NUM_8259_INTERRUPTS, NR_IRQS);
+ OpenPIC_InitSenses = init_senses;
+ OpenPIC_NumInitSenses = NR_IRQS - NUM_8259_INTERRUPTS;
+
+ openpic_init(NUM_8259_INTERRUPTS);
+ /* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */
+ openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
i8259_irq);
+ }
for (i = 0; i < NUM_8259_INTERRUPTS; i++)
irq_desc[i].handler = &i8259_pic;
@@ -450,6 +490,8 @@
chrp_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
+ struct device_node *root = find_path_device ("/");
+ char *machine;
#ifdef CONFIG_BLK_DEV_INITRD
/* take care of initrd if we have one */
if ( r6 )
@@ -469,7 +511,11 @@
ppc_md.show_cpuinfo = chrp_show_cpuinfo;
ppc_md.irq_canonicalize = chrp_irq_canonicalize;
ppc_md.init_IRQ = chrp_init_IRQ;
- ppc_md.get_irq = openpic_get_irq;
+ machine = get_property(root, "model", NULL);
+ if (strncmp(machine, "Pegasos", 7) == 0)
+ ppc_md.get_irq = i8259_irq;
+ else
+ ppc_md.get_irq = openpic_get_irq;
ppc_md.init = chrp_init2;
diff -urN kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_time.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_time.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_time.c 2004-06-16 07:18:57.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_time.c 2004-06-29 18:10:44.032794096 +0200
@@ -41,6 +41,8 @@
int base;
rtcs = find_compatible_devices("rtc", "pnpPNP,b00");
+ if (rtcs == NULL)
+ rtcs = find_compatible_devices("rtc", "ds1385-rtc");
if (rtcs == NULL || rtcs->addrs == NULL)
return 0;
base = rtcs->addrs[0].address;
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-29 16:50 Pegasos 2 support patch Sven Luther
@ 2004-06-29 20:42 ` Sven Luther
2004-06-30 2:57 ` Benjamin Herrenschmidt
2004-06-30 9:18 ` Adrian Cox
1 sibling, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-29 20:42 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Tue, Jun 29, 2004 at 06:50:29PM +0200, Sven Luther wrote:
> The pegasos1 support is not complete, but i believe this is due to some
> brokeness in the OF. The main problem being that the translate function
> is broken, and altough phys has the right value (0x00010000) before
> calling it, it is 0 afterwards. I suppose the initial value is taken
> from &_stext, so it should be feasible to detect that this is the
> correct value before calling the translate OF method, or fixing it if we
> detect a Pegasos 1 with the model OF property. Comments on this would
> also be welcome. There may be some interrupt level thing left on pegasos
> 1 also, but i would need to check that.
Well, the pegasos 1 seems to start with mmu enabled, but with BATs
mapped 1:1. There is not much we can do unless we fix the translate
method, i think. The attached patch tests if the machine is a pegasos 1
(but not 2) and sets the phys to 0x00010000 if this is the case.
Another solution would be to test before doing the translate call, maybe
this would be more elegant ?
Friendly,
Sven Luther
[-- Attachment #2: pegasos1.diff --]
[-- Type: text/plain, Size: 976 bytes --]
diff -urN kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c
--- kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c 2004-06-16 07:20:24.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c 2004-06-29 21:07:04.491319912 +0200
@@ -794,6 +794,9 @@
char *p, *d;
unsigned long phys;
void *result[3];
+ char model[32];
+ phandle node;
+ int rc;
/* Default */
phys = (unsigned long) &_stext;
@@ -880,6 +883,11 @@
for (i = 0; i < prom_num_displays; ++i)
prom_display_paths[i] = PTRUNRELOC(prom_display_paths[i]);
+ /* Pegasos 1 has a broken translate method in the OF, fix it */
+ node = call_prom("finddevice", 1, 1, "/");
+ rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
+ if (rc > 0 && !strncmp (model, "Pegasos", 7) && strncmp (model, "Pegasos2", 8)) phys = 0x00010000;
+
prom_print("returning 0x");
prom_print_hex(phys);
prom_print("from prom_init\n");
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-29 20:42 ` Sven Luther
@ 2004-06-30 2:57 ` Benjamin Herrenschmidt
2004-06-30 6:00 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Benjamin Herrenschmidt @ 2004-06-30 2:57 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev list
> Another solution would be to test before doing the translate call, maybe
> this would be more elegant ?
Yup, if you know it will be broken, don't bother calling it,
and please, avoid the over-long line :)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 2:57 ` Benjamin Herrenschmidt
@ 2004-06-30 6:00 ` Sven Luther
2004-06-30 8:10 ` Geert Uytterhoeven
0 siblings, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 6:00 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Sven Luther, linuxppc-dev list
[-- Attachment #1: Type: text/plain, Size: 545 bytes --]
On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:
>
> > Another solution would be to test before doing the translate call, maybe
> > this would be more elegant ?
>
> Yup, if you know it will be broken, don't bother calling it,
> and please, avoid the over-long line :)
Ok, this is then the final patch, i hope it is now correct.
The only part missing is the via82cxxx patch, where may i best find help
on how to best solve this ? I wrote the maintainer listed in the patch,
but never got a reply.
Friendly,
Sven Luther
[-- Attachment #2: pegasos.diff --]
[-- Type: text/plain, Size: 8584 bytes --]
diff -ur kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_pci.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_pci.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_pci.c 2004-06-16 07:20:26.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_pci.c 2004-06-29 18:10:43.000000000 +0200
@@ -97,8 +97,9 @@
rtas_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 *val)
{
+ struct pci_controller *hose = bus->sysdata;
unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
- | ((bus->number & 0xff) << 16);
+ | (((bus->number - hose->first_busno) & 0xff) << 16) | (pci_domain_nr(bus) << 24);
unsigned long ret = ~0UL;
int rval;
@@ -111,8 +112,9 @@
rtas_write_config(struct pci_bus *bus, unsigned int devfn, int offset,
int len, u32 val)
{
+ struct pci_controller *hose = bus->sysdata;
unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
- | ((bus->number & 0xff) << 16);
+ | (((bus->number - hose->first_busno) & 0xff) << 16) | (pci_domain_nr(bus) << 24);
int rval;
rval = call_rtas("write-pci-config", 3, 1, NULL, addr, len, val);
@@ -186,6 +188,26 @@
iounmap(reg);
}
+/* Marvell Discovery II based Pegasos 2 */
+//#define PEGASOS_USE_PCI_DOMAINS
+
+static void __init
+setup_peg2(struct pci_controller *hose, struct device_node *dev)
+{
+ struct device_node *root = find_path_device("/");
+ struct device_node *rtas;
+
+ rtas = of_find_node_by_name (root, "rtas");
+ if (rtas) {
+ hose->ops = &rtas_pci_ops;
+ } else {
+ printk ("RTAS supporting Pegasos OF not found, please upgrade your firmware\n");
+ }
+#ifndef PEGASOS_USE_PCI_DOMAINS
+ pci_assign_all_busses = 1;
+#endif
+}
+
void __init
chrp_find_bridges(void)
{
@@ -195,7 +217,7 @@
struct pci_controller *hose;
unsigned int *dma;
char *model, *machine;
- int is_longtrail = 0, is_mot = 0;
+ int is_longtrail = 0, is_mot = 0, is_pegasos = 0;
struct device_node *root = find_path_device("/");
/*
@@ -207,6 +229,8 @@
if (machine != NULL) {
is_longtrail = strncmp(machine, "IBM,LongTrail", 13) == 0;
is_mot = strncmp(machine, "MOT", 3) == 0;
+ if (strncmp(machine, "Pegasos2", 8) == 0) is_pegasos = 2;
+ else if (strncmp(machine, "Pegasos", 7) == 0) is_pegasos = 1;
}
for (dev = root->child; dev != NULL; dev = dev->sibling) {
if (dev->type == NULL || strcmp(dev->type, "pci") != 0)
@@ -257,6 +281,10 @@
hose->cfg_data = (unsigned char *)
ioremap(GG2_PCI_CONFIG_BASE, 0x80000);
gg2_pci_config_base = (unsigned long) hose->cfg_data;
+ } else if (is_pegasos == 1) {
+ setup_indirect_pci(hose, 0xfec00cf8, 0xfee00cfc);
+ } else if (is_pegasos == 2) {
+ setup_peg2(hose, dev);
} else {
printk("No methods for %s (model %s), using RTAS\n",
dev->full_name, model);
@@ -274,6 +302,9 @@
printk("pci_dram_offset = %lx\n", pci_dram_offset);
}
}
-
- ppc_md.pcibios_fixup = chrp_pcibios_fixup;
+
+ if (is_pegasos)
+ ppc_md.pcibios_fixup = NULL;
+ else
+ ppc_md.pcibios_fixup = chrp_pcibios_fixup;
}
diff -ur kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_setup.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_setup.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_setup.c 2004-06-16 07:19:52.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_setup.c 2004-06-29 18:10:44.000000000 +0200
@@ -214,6 +214,37 @@
}
}
+void pegasos_set_l2cr(void)
+{
+ struct device_node *root = find_path_device("/");
+ char *machine;
+ struct device_node *np;
+ int l2cr_value;
+
+ /* On Pegasos, enable the l2 cache if needed, as the OF forgets it */
+ if (root == NULL)
+ return;
+ machine = get_property(root, "model", NULL);
+ if (machine == NULL)
+ return;
+ if (strncmp(machine, "Pegasos", 7) == 0) {
+ /* Enable L2 cache if needed */
+ np = find_type_devices("cpu");
+ if (np != NULL) {
+ unsigned int *l2cr = (unsigned int *)
+ get_property (np, "l2cr", NULL);
+ if (l2cr == NULL) {
+ printk ("Pegasos l2cr : no cpu l2cr property found\n");
+ return;
+ }
+ if (!((*l2cr) & 0x80000000)) {
+ printk ("Pegasos l2cr : L2 cache was not active, activating\n");
+ _set_L2CR(0);
+ _set_L2CR((*l2cr) | 0x80000000);
+ }
+ }
+ }
+}
void __init
chrp_setup_arch(void)
@@ -236,6 +267,9 @@
/* Lookup PCI host bridges */
chrp_find_bridges();
+ /* On pegasos, enable the L2 cache if not already done by OF */
+ pegasos_set_l2cr();
+
#ifndef CONFIG_PPC64BRIDGE
/*
* Temporary fixes for PCI devices.
@@ -387,6 +421,8 @@
#if defined(CONFIG_VT) && defined(CONFIG_INPUT_ADBHID) && defined(XMON)
struct device_node *kbd;
#endif
+ struct device_node *root = find_path_device ("/");
+ char *machine;
for (np = find_devices("pci"); np != NULL; np = np->next) {
unsigned int *addrp = (unsigned int *)
@@ -400,16 +436,20 @@
if (np == NULL)
printk(KERN_ERR "Cannot find PCI interrupt acknowledge address\n");
- chrp_find_openpic();
-
- prom_get_irq_senses(init_senses, NUM_8259_INTERRUPTS, NR_IRQS);
- OpenPIC_InitSenses = init_senses;
- OpenPIC_NumInitSenses = NR_IRQS - NUM_8259_INTERRUPTS;
-
- openpic_init(NUM_8259_INTERRUPTS);
- /* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */
- openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
+ /* Pegasos doesn't have openpic */
+ machine = get_property(root, "model", NULL);
+ if (strncmp(machine, "Pegasos", 7) != 0) {
+ chrp_find_openpic();
+
+ prom_get_irq_senses(init_senses, NUM_8259_INTERRUPTS, NR_IRQS);
+ OpenPIC_InitSenses = init_senses;
+ OpenPIC_NumInitSenses = NR_IRQS - NUM_8259_INTERRUPTS;
+
+ openpic_init(NUM_8259_INTERRUPTS);
+ /* We have a cascade on OpenPIC IRQ 0, Linux IRQ 16 */
+ openpic_hookup_cascade(NUM_8259_INTERRUPTS, "82c59 cascade",
i8259_irq);
+ }
for (i = 0; i < NUM_8259_INTERRUPTS; i++)
irq_desc[i].handler = &i8259_pic;
@@ -450,6 +490,8 @@
chrp_init(unsigned long r3, unsigned long r4, unsigned long r5,
unsigned long r6, unsigned long r7)
{
+ struct device_node *root = find_path_device ("/");
+ char *machine;
#ifdef CONFIG_BLK_DEV_INITRD
/* take care of initrd if we have one */
if ( r6 )
@@ -469,7 +511,11 @@
ppc_md.show_cpuinfo = chrp_show_cpuinfo;
ppc_md.irq_canonicalize = chrp_irq_canonicalize;
ppc_md.init_IRQ = chrp_init_IRQ;
- ppc_md.get_irq = openpic_get_irq;
+ machine = get_property(root, "model", NULL);
+ if (strncmp(machine, "Pegasos", 7) == 0)
+ ppc_md.get_irq = i8259_irq;
+ else
+ ppc_md.get_irq = openpic_get_irq;
ppc_md.init = chrp_init2;
diff -ur kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_time.c kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_time.c
--- kernel-source-2.6.7.orig/arch/ppc/platforms/chrp_time.c 2004-06-16 07:18:57.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/platforms/chrp_time.c 2004-06-29 18:10:44.000000000 +0200
@@ -41,6 +41,8 @@
int base;
rtcs = find_compatible_devices("rtc", "pnpPNP,b00");
+ if (rtcs == NULL)
+ rtcs = find_compatible_devices("rtc", "ds1385-rtc");
if (rtcs == NULL || rtcs->addrs == NULL)
return 0;
base = rtcs->addrs[0].address;
diff -ur kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c
--- kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c 2004-06-16 07:20:24.000000000 +0200
+++ kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c 2004-06-30 07:51:49.975232432 +0200
@@ -794,6 +794,9 @@
char *p, *d;
unsigned long phys;
void *result[3];
+ char model[32];
+ phandle node;
+ int rc;
/* Default */
phys = (unsigned long) &_stext;
@@ -850,11 +853,20 @@
klimit = (char *) (mem - offset);
- /* If we are already running at 0xc0000000, we assume we were
- * loaded by an OF bootloader which did set a BAT for us.
- * This breaks OF translate so we force phys to be 0.
- */
- if (offset == 0) {
+ node = call_prom("finddevice", 1, 1, "/");
+ rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
+ if (rc > 0 && !strncmp (model, "Pegasos", 7)
+ && strncmp (model, "Pegasos2", 8)) {
+ /* Pegasos 1 has a broken translate method in the OF,
+ * and furthermore the BATs are mapped 1:1 so the phys
+ * address calculated above is * correct, so let's use
+ * it directly.
+ */
+ } else if (offset == 0) {
+ /* If we are already running at 0xc0000000, we assume we were
+ * loaded by an OF bootloader which did set a BAT for us.
+ * This breaks OF translate so we force phys to be 0.
+ */
prom_print("(already at 0xc0000000) phys=0\n");
phys = 0;
} else if ((int) call_prom("getprop", 4, 1, prom_chosen, "mmu",
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 6:00 ` Sven Luther
@ 2004-06-30 8:10 ` Geert Uytterhoeven
2004-06-30 8:21 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Geert Uytterhoeven @ 2004-06-30 8:10 UTC (permalink / raw)
To: Sven Luther; +Cc: Benjamin Herrenschmidt, linuxppc-dev list
On Wed, 30 Jun 2004, Sven Luther wrote:
> On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:
> > > Another solution would be to test before doing the translate call, maybe
> > > this would be more elegant ?
> >
> > Yup, if you know it will be broken, don't bother calling it,
> > and please, avoid the over-long line :)
>
> Ok, this is then the final patch, i hope it is now correct.
> --- kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c 2004-06-16 07:20:24.000000000 +0200
> +++ kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c 2004-06-30 07:51:49.975232432 +0200
> @@ -850,11 +853,20 @@
>
> klimit = (char *) (mem - offset);
>
> - /* If we are already running at 0xc0000000, we assume we were
> - * loaded by an OF bootloader which did set a BAT for us.
> - * This breaks OF translate so we force phys to be 0.
> - */
> - if (offset == 0) {
> + node = call_prom("finddevice", 1, 1, "/");
> + rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
> + if (rc > 0 && !strncmp (model, "Pegasos", 7)
> + && strncmp (model, "Pegasos2", 8)) {
> + /* Pegasos 1 has a broken translate method in the OF,
> + * and furthermore the BATs are mapped 1:1 so the phys
> + * address calculated above is * correct, so let's use
^
Bogus asterisk
> + * it directly.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 8:10 ` Geert Uytterhoeven
@ 2004-06-30 8:21 ` Sven Luther
0 siblings, 0 replies; 21+ messages in thread
From: Sven Luther @ 2004-06-30 8:21 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Sven Luther, Benjamin Herrenschmidt, linuxppc-dev list
On Wed, Jun 30, 2004 at 10:10:07AM +0200, Geert Uytterhoeven wrote:
> On Wed, 30 Jun 2004, Sven Luther wrote:
> > On Tue, Jun 29, 2004 at 09:57:29PM -0500, Benjamin Herrenschmidt wrote:
> > > > Another solution would be to test before doing the translate call, maybe
> > > > this would be more elegant ?
> > >
> > > Yup, if you know it will be broken, don't bother calling it,
> > > and please, avoid the over-long line :)
> >
> > Ok, this is then the final patch, i hope it is now correct.
>
> > --- kernel-source-2.6.7.orig/arch/ppc/syslib/prom_init.c 2004-06-16 07:20:24.000000000 +0200
> > +++ kernel-source-2.6.7.peg2/arch/ppc/syslib/prom_init.c 2004-06-30 07:51:49.975232432 +0200
> > @@ -850,11 +853,20 @@
> >
> > klimit = (char *) (mem - offset);
> >
> > - /* If we are already running at 0xc0000000, we assume we were
> > - * loaded by an OF bootloader which did set a BAT for us.
> > - * This breaks OF translate so we force phys to be 0.
> > - */
> > - if (offset == 0) {
> > + node = call_prom("finddevice", 1, 1, "/");
> > + rc = call_prom("getprop", 4, 1, node, "model", model, sizeof(model));
> > + if (rc > 0 && !strncmp (model, "Pegasos", 7)
> > + && strncmp (model, "Pegasos2", 8)) {
> > + /* Pegasos 1 has a broken translate method in the OF,
> > + * and furthermore the BATs are mapped 1:1 so the phys
> > + * address calculated above is * correct, so let's use
> ^
> Bogus asterisk
Ok, i will remove it thanks.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-29 16:50 Pegasos 2 support patch Sven Luther
2004-06-29 20:42 ` Sven Luther
@ 2004-06-30 9:18 ` Adrian Cox
2004-06-30 9:30 ` Sven Luther
2004-06-30 15:50 ` Sven Luther
1 sibling, 2 replies; 21+ messages in thread
From: Adrian Cox @ 2004-06-30 9:18 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
On Tue, 2004-06-29 at 17:50, Sven Luther wrote:
> The remaining problem for the pegasos 2 is with the via82cxxx ide
> driver, which needs to support a different irq for both channels, thus
> breakign when a device is present on the second ide channel. The
> pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
> naturally not fit for mainstream inclusion. I would welcome any hint on
> how to solve this issue.
I have a board which has the same problem.
My current idea is to add an extra flag to the ide_pci_device_t to
indicate that the device defaults to ports 14 and 15, then modify
ide_hwif_configure() to use this flag.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 9:18 ` Adrian Cox
@ 2004-06-30 9:30 ` Sven Luther
2004-06-30 9:40 ` Adrian Cox
2004-06-30 15:50 ` Sven Luther
1 sibling, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 9:30 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:
> On Tue, 2004-06-29 at 17:50, Sven Luther wrote:
> > The remaining problem for the pegasos 2 is with the via82cxxx ide
> > driver, which needs to support a different irq for both channels, thus
> > breakign when a device is present on the second ide channel. The
> > pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
> > naturally not fit for mainstream inclusion. I would welcome any hint on
> > how to solve this issue.
>
> I have a board which has the same problem.
>
> My current idea is to add an extra flag to the ide_pci_device_t to
> indicate that the device defaults to ports 14 and 15, then modify
> ide_hwif_configure() to use this flag.
Ok, sounds nice, do you plan to write this patch anytime soon, or should
i go forward and implement this idea ?
Thanks for the reply.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 9:30 ` Sven Luther
@ 2004-06-30 9:40 ` Adrian Cox
2004-06-30 9:45 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Adrian Cox @ 2004-06-30 9:40 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
On Wed, 2004-06-30 at 10:30, Sven Luther wrote:
> On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:
> > On Tue, 2004-06-29 at 17:50, Sven Luther wrote:
> > > The remaining problem for the pegasos 2 is with the via82cxxx ide
> > > driver, which needs to support a different irq for both channels, thus
> > > breakign when a device is present on the second ide channel. [snip]
> > My current idea is to add an extra flag to the ide_pci_device_t to
> > indicate that the device defaults to ports 14 and 15, then modify
> > ide_hwif_configure() to use this flag.
>
> Ok, sounds nice, do you plan to write this patch anytime soon, or should
> i go forward and implement this idea ?
I've got a few other things to get into the kernel before this, so
please don't wait for me. If you make a patch I'll test it.
In my case, the initial setup is that the device has been assigned I/O
space address in the 0xfe00 range, and no PCI IRQ. This confuses the
PCI IDE code, because it assumes that the device must be an add-in card
if it is not on the legacy ports.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 9:40 ` Adrian Cox
@ 2004-06-30 9:45 ` Sven Luther
0 siblings, 0 replies; 21+ messages in thread
From: Sven Luther @ 2004-06-30 9:45 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 10:40:47AM +0100, Adrian Cox wrote:
> On Wed, 2004-06-30 at 10:30, Sven Luther wrote:
> > On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:
> > > On Tue, 2004-06-29 at 17:50, Sven Luther wrote:
> > > > The remaining problem for the pegasos 2 is with the via82cxxx ide
> > > > driver, which needs to support a different irq for both channels, thus
> > > > breakign when a device is present on the second ide channel. [snip]
>
> > > My current idea is to add an extra flag to the ide_pci_device_t to
> > > indicate that the device defaults to ports 14 and 15, then modify
> > > ide_hwif_configure() to use this flag.
> >
> > Ok, sounds nice, do you plan to write this patch anytime soon, or should
> > i go forward and implement this idea ?
>
> I've got a few other things to get into the kernel before this, so
> please don't wait for me. If you make a patch I'll test it.
Ok, altough i have not much experience with ide stuff.
> In my case, the initial setup is that the device has been assigned I/O
> space address in the 0xfe00 range, and no PCI IRQ. This confuses the
> PCI IDE code, because it assumes that the device must be an add-in card
> if it is not on the legacy ports.
Ok.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 9:18 ` Adrian Cox
2004-06-30 9:30 ` Sven Luther
@ 2004-06-30 15:50 ` Sven Luther
2004-06-30 16:12 ` Adrian Cox
1 sibling, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 15:50 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 10:18:10AM +0100, Adrian Cox wrote:
>
> On Tue, 2004-06-29 at 17:50, Sven Luther wrote:
> > The remaining problem for the pegasos 2 is with the via82cxxx ide
> > driver, which needs to support a different irq for both channels, thus
> > breakign when a device is present on the second ide channel. The
> > pegasos-via82cxxx.diff patches is a hcky soltuion for this, but is
> > naturally not fit for mainstream inclusion. I would welcome any hint on
> > how to solve this issue.
>
> I have a board which has the same problem.
>
> My current idea is to add an extra flag to the ide_pci_device_t to
> indicate that the device defaults to ports 14 and 15, then modify
> ide_hwif_configure() to use this flag.
Mmm, ...
static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)
Would it not be better in my case to call ide_hwif_configure with the
right irq ? Or do i misunderstand what you had in mind ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 15:50 ` Sven Luther
@ 2004-06-30 16:12 ` Adrian Cox
2004-06-30 16:23 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Adrian Cox @ 2004-06-30 16:12 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
On Wed, 2004-06-30 at 16:50, Sven Luther wrote:
> static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
> ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)
>
> Would it not be better in my case to call ide_hwif_configure with the
> right irq ? Or do i misunderstand what you had in mind ?
It shouldn't make much difference - I only suggested ide_hwif_configure
because it already contains flag checking code.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 16:12 ` Adrian Cox
@ 2004-06-30 16:23 ` Sven Luther
2004-06-30 16:39 ` Adrian Cox
0 siblings, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 16:23 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 05:12:46PM +0100, Adrian Cox wrote:
> On Wed, 2004-06-30 at 16:50, Sven Luther wrote:
> > static ide_hwif_t *ide_hwif_configure(struct pci_dev *dev,
> > ide_pci_device_t *d, ide_hwif_t *mate, int port, int irq)
> >
> > Would it not be better in my case to call ide_hwif_configure with the
> > right irq ? Or do i misunderstand what you had in mind ?
>
> It shouldn't make much difference - I only suggested ide_hwif_configure
> because it already contains flag checking code.
I am not sure if it works for me, but in your case, would the right
solution not be to have d->init_chipset return the irq ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 16:23 ` Sven Luther
@ 2004-06-30 16:39 ` Adrian Cox
2004-06-30 18:52 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Adrian Cox @ 2004-06-30 16:39 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
On Wed, 2004-06-30 at 17:23, Sven Luther wrote:
> I am not sure if it works for me, but in your case, would the right
> solution not be to have d->init_chipset return the irq ?
No, because d->init_chipset is only called once per pci device, and that
one pci device provides two channels with different irqs.
The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
i8259 interrupt controller internally, but the kernel believes that only
IDE controllers at the legacy address can have separate irqs for each
channel.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 16:39 ` Adrian Cox
@ 2004-06-30 18:52 ` Sven Luther
2004-06-30 19:05 ` Adrian Cox
0 siblings, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 18:52 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:
> On Wed, 2004-06-30 at 17:23, Sven Luther wrote:
> > I am not sure if it works for me, but in your case, would the right
> > solution not be to have d->init_chipset return the irq ?
>
> No, because d->init_chipset is only called once per pci device, and that
> one pci device provides two channels with different irqs.
Ah, too bad. that said, this could be perhaps changed ? After all the
calling code in the idesetup stuff is per channel, so there is no reason
we could not call this one (or a similar function) for each channel.
> The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
> i8259 interrupt controller internally, but the kernel believes that only
> IDE controllers at the legacy address can have separate irqs for each
> channel.
Is this the case for each via ide controller ? If so why does it work on
x86 ?
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 18:52 ` Sven Luther
@ 2004-06-30 19:05 ` Adrian Cox
2004-06-30 19:38 ` Sven Luther
0 siblings, 1 reply; 21+ messages in thread
From: Adrian Cox @ 2004-06-30 19:05 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev
On Wed, 2004-06-30 at 19:52, Sven Luther wrote:
> On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:
> > The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
> > i8259 interrupt controller internally, but the kernel believes that only
> > IDE controllers at the legacy address can have separate irqs for each
> > channel.
>
> Is this the case for each via ide controller ? If so why does it work on
> x86 ?
Because on x86 the BIOS places the IDE controller at the legacy
addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
controller is also the legacy IDE controller, and thus uses the legacy
irq numbers 14 and 15.
What I'm looking for is a tidy way of achieving the same result on a
platform where the boot firmware did not put the via ide controller at
the legacy addresses.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 19:05 ` Adrian Cox
@ 2004-06-30 19:38 ` Sven Luther
2004-07-01 7:59 ` Geert Uytterhoeven
0 siblings, 1 reply; 21+ messages in thread
From: Sven Luther @ 2004-06-30 19:38 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, linuxppc-dev
On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:
> On Wed, 2004-06-30 at 19:52, Sven Luther wrote:
> > On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:
> > > The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
> > > i8259 interrupt controller internally, but the kernel believes that only
> > > IDE controllers at the legacy address can have separate irqs for each
> > > channel.
> >
> > Is this the case for each via ide controller ? If so why does it work on
> > x86 ?
>
> Because on x86 the BIOS places the IDE controller at the legacy
> addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
> controller is also the legacy IDE controller, and thus uses the legacy
> irq numbers 14 and 15.
Ah, ok, so this is just another x86-bug, and there should really be no
major problem in rectifying it, and all the code should already be in
setup-pci.c. We just need to find some way to detect that we are also in
this case. Could this not be probed somehow ? In which case are the irq
numbers the same ? Only when the via driver is on a stansalone pci card ?
> What I'm looking for is a tidy way of achieving the same result on a
> platform where the boot firmware did not put the via ide controller at
> the legacy addresses.
Ok, the main point would be to fins the tidy way for doing this.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-06-30 19:38 ` Sven Luther
@ 2004-07-01 7:59 ` Geert Uytterhoeven
2004-07-01 8:42 ` Adrian Cox
0 siblings, 1 reply; 21+ messages in thread
From: Geert Uytterhoeven @ 2004-07-01 7:59 UTC (permalink / raw)
To: Sven Luther; +Cc: Adrian Cox, Linux/PPC Development
On Wed, 30 Jun 2004, Sven Luther wrote:
> On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:
> > On Wed, 2004-06-30 at 19:52, Sven Luther wrote:
> > > On Wed, Jun 30, 2004 at 05:39:35PM +0100, Adrian Cox wrote:
> > > > The problem is that the via686 ide is hardwired to irqs 14 and 15 of the
> > > > i8259 interrupt controller internally, but the kernel believes that only
> > > > IDE controllers at the legacy address can have separate irqs for each
> > > > channel.
> > >
> > > Is this the case for each via ide controller ? If so why does it work on
> > > x86 ?
> >
> > Because on x86 the BIOS places the IDE controller at the legacy
> > addresses (0x1f0, 0x170), and then setup-pci.c spots that the via ide
> > controller is also the legacy IDE controller, and thus uses the legacy
> > irq numbers 14 and 15.
>
> Ah, ok, so this is just another x86-bug, and there should really be no
> major problem in rectifying it, and all the code should already be in
> setup-pci.c. We just need to find some way to detect that we are also in
> this case. Could this not be probed somehow ? In which case are the irq
> numbers the same ? Only when the via driver is on a stansalone pci card ?
>
> > What I'm looking for is a tidy way of achieving the same result on a
> > platform where the boot firmware did not put the via ide controller at
> > the legacy addresses.
>
> Ok, the main point would be to fins the tidy way for doing this.
Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
SL82C105 IDE interface, which is left in legacy mode by Open Firmware?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-07-01 7:59 ` Geert Uytterhoeven
@ 2004-07-01 8:42 ` Adrian Cox
2004-07-01 8:48 ` Geert Uytterhoeven
2004-07-01 8:57 ` Sven Luther
0 siblings, 2 replies; 21+ messages in thread
From: Adrian Cox @ 2004-07-01 8:42 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Sven Luther, Linux/PPC Development
On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:
> On Wed, 30 Jun 2004, Sven Luther wrote:
> > On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:
> > Ah, ok, so this is just another x86-bug, and there should really be no
> > major problem in rectifying it, and all the code should already be in
> > setup-pci.c. We just need to find some way to detect that we are also in
> > this case. Could this not be probed somehow ? In which case are the irq
> > numbers the same ? Only when the via driver is on a stansalone pci card ?
The via 686 can't go on a standalone pci card, as it's a complete
southbridge.
> > > What I'm looking for is a tidy way of achieving the same result on a
> > > platform where the boot firmware did not put the via ide controller at
> > > the legacy addresses.
> >
> > Ok, the main point would be to fins the tidy way for doing this.
>
> Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
> SL82C105 IDE interface, which is left in legacy mode by Open Firmware?
Which tree are those boards in?
There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
are being used to fool the core ide code into behaving in a specific
way. The core ide code makes no guarantees that these tricks will
continue to work, and in my case the necessary tricks changed between
2.4 and 2.6. The only platform specific knowledge required for the Via
686 is the mapping between the internal i8259 interrupt number and the
linux interrupt number.
- Adrian Cox
Humboldt Solutions Ltd.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-07-01 8:42 ` Adrian Cox
@ 2004-07-01 8:48 ` Geert Uytterhoeven
2004-07-01 8:57 ` Sven Luther
1 sibling, 0 replies; 21+ messages in thread
From: Geert Uytterhoeven @ 2004-07-01 8:48 UTC (permalink / raw)
To: Adrian Cox; +Cc: Sven Luther, Linux/PPC Development
On Thu, 1 Jul 2004, Adrian Cox wrote:
> On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:
> > On Wed, 30 Jun 2004, Sven Luther wrote:
> > > On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:
> > > > What I'm looking for is a tidy way of achieving the same result on a
> > > > platform where the boot firmware did not put the via ide controller at
> > > > the legacy addresses.
> > >
> > > Ok, the main point would be to fins the tidy way for doing this.
> >
> > Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
> > SL82C105 IDE interface, which is left in legacy mode by Open Firmware?
>
> Which tree are those boards in?
LongTrail support has been in the main tree since several years. But
longtrail_pcibios_fixup() may still be missing even in the PPC tree (it doesn't
seem to be in plain 2.6.7 yet). Patches floated on the list.
> There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
> IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
> are being used to fool the core ide code into behaving in a specific
> way. The core ide code makes no guarantees that these tricks will
> continue to work, and in my case the necessary tricks changed between
> 2.4 and 2.6. The only platform specific knowledge required for the Via
> 686 is the mapping between the internal i8259 interrupt number and the
> linux interrupt number.
And the internal i8259 interrupt number is always the same as the Linux
interrupt number to support legacy code, right?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Pegasos 2 support patch ...
2004-07-01 8:42 ` Adrian Cox
2004-07-01 8:48 ` Geert Uytterhoeven
@ 2004-07-01 8:57 ` Sven Luther
1 sibling, 0 replies; 21+ messages in thread
From: Sven Luther @ 2004-07-01 8:57 UTC (permalink / raw)
To: Adrian Cox; +Cc: Geert Uytterhoeven, Sven Luther, Linux/PPC Development
On Thu, Jul 01, 2004 at 09:42:52AM +0100, Adrian Cox wrote:
> On Thu, 2004-07-01 at 08:59, Geert Uytterhoeven wrote:
> > On Wed, 30 Jun 2004, Sven Luther wrote:
> > > On Wed, Jun 30, 2004 at 08:05:01PM +0100, Adrian Cox wrote:
>
> > > Ah, ok, so this is just another x86-bug, and there should really be no
> > > major problem in rectifying it, and all the code should already be in
> > > setup-pci.c. We just need to find some way to detect that we are also in
> > > this case. Could this not be probed somehow ? In which case are the irq
> > > numbers the same ? Only when the via driver is on a stansalone pci card ?
>
> The via 686 can't go on a standalone pci card, as it's a complete
> southbridge.
So, do i understand this correctly, and all instances of the via82cxxx
driver have the 14/15 interrupt arrangement ? Or are there other
standalone pci cards basd on the via ide chipset ?
> > > > What I'm looking for is a tidy way of achieving the same result on a
> > > > platform where the boot firmware did not put the via ide controller at
> > > > the legacy addresses.
> > >
> > > Ok, the main point would be to fins the tidy way for doing this.
> >
> > Cfr. the code in longtrail_pcibios_fixup() and briq_pcibios_fixup() for the
> > SL82C105 IDE interface, which is left in legacy mode by Open Firmware?
>
> Which tree are those boards in?
>
> There's a similar fixup in pplus.c in 2.6.7, but I don't like the way
> IDE works on PowerPC currently. The ppc_ide_md structure and the fixups
> are being used to fool the core ide code into behaving in a specific
> way. The core ide code makes no guarantees that these tricks will
> continue to work, and in my case the necessary tricks changed between
> 2.4 and 2.6. The only platform specific knowledge required for the Via
> 686 is the mapping between the internal i8259 interrupt number and the
> linux interrupt number.
Mmm.
Friendly,
Sven Luther
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2004-07-01 8:57 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-06-29 16:50 Pegasos 2 support patch Sven Luther
2004-06-29 20:42 ` Sven Luther
2004-06-30 2:57 ` Benjamin Herrenschmidt
2004-06-30 6:00 ` Sven Luther
2004-06-30 8:10 ` Geert Uytterhoeven
2004-06-30 8:21 ` Sven Luther
2004-06-30 9:18 ` Adrian Cox
2004-06-30 9:30 ` Sven Luther
2004-06-30 9:40 ` Adrian Cox
2004-06-30 9:45 ` Sven Luther
2004-06-30 15:50 ` Sven Luther
2004-06-30 16:12 ` Adrian Cox
2004-06-30 16:23 ` Sven Luther
2004-06-30 16:39 ` Adrian Cox
2004-06-30 18:52 ` Sven Luther
2004-06-30 19:05 ` Adrian Cox
2004-06-30 19:38 ` Sven Luther
2004-07-01 7:59 ` Geert Uytterhoeven
2004-07-01 8:42 ` Adrian Cox
2004-07-01 8:48 ` Geert Uytterhoeven
2004-07-01 8:57 ` Sven Luther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).