[PATCH] Change PCI host bridge setup/resources

[PATCH] Change PCI host bridge setup/resources

[Thomas Bogendoerfer]

PCI host bridge setup for SNI RM machines with PCI is quite broken, now that
Linux does it's resource setup own its own. It will use IO addresses,
which are needed by the EISA config detection and assigns PCI memory
addresses, which overlap with ISA legacy addresses (video ram). Below
is a patch, which changes the way how the PCI memory addresses are
used and sets the minimum IO address to give enough IO space for
8 EISA slots). This patch needs the other PCI resource change, I've
posted.

Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---


diff --git a/arch/mips/sni/pcit.c b/arch/mips/sni/pcit.c
index 1dfc3f0..00d151f 100644
--- a/arch/mips/sni/pcit.c
+++ b/arch/mips/sni/pcit.c
@@ -43,7 +43,7 @@ static struct platform_device pcit_serial8250_device = {
 };
 
 static struct plat_serial8250_port pcit_cplus_data[] = {
-	PORT(0x3f8, 4),
+	PORT(0x3f8, 0),
 	PORT(0x2f8, 3),
 	PORT(0x3e8, 4),
 	PORT(0x2e8, 3),
@@ -59,9 +59,9 @@ static struct platform_device pcit_cplus_serial8250_device = {
 };
 
 static struct resource sni_io_resource = {
-	.start	= 0x00001000UL,
+	.start	= 0x00000000UL,
 	.end	= 0x03bfffffUL,
-	.name	= "PCIT IO MEM",
+	.name	= "PCIT IO",
 	.flags	= IORESOURCE_IO,
 };
 
@@ -92,6 +92,11 @@ static struct resource pcit_io_resources[] = {
 		.name	= "dma2",
 		.flags	= IORESOURCE_BUSY
 	}, {
+		.start	=  0xcf8,
+		.end	= 0xcfb,
+		.name	= "PCI config addr",
+		.flags	= IORESOURCE_BUSY
+	}, {
 		.start	=  0xcfc,
 		.end	= 0xcff,
 		.name	= "PCI config data",
@@ -100,107 +105,19 @@ static struct resource pcit_io_resources[] = {
 };
 
 static struct resource sni_mem_resource = {
-	.start	= 0x10000000UL,
-	.end	= 0xffffffffUL,
+	.start	= 0x18000000UL,
+	.end	= 0x1fbfffffUL,
 	.name	= "PCIT PCI MEM",
 	.flags	= IORESOURCE_MEM
 };
 
-/*
- * The RM200/RM300 has a few holes in it's PCI/EISA memory address space used
- * for other purposes.  Be paranoid and allocate all of the before the PCI
- * code gets a chance to to map anything else there ...
- *
- * This leaves the following areas available:
- *
- * 0x10000000 - 0x1009ffff (640kB) PCI/EISA/ISA Bus Memory
- * 0x10100000 - 0x13ffffff ( 15MB) PCI/EISA/ISA Bus Memory
- * 0x18000000 - 0x1fbfffff (124MB) PCI/EISA Bus Memory
- * 0x1ff08000 - 0x1ffeffff (816kB) PCI/EISA Bus Memory
- * 0xa0000000 - 0xffffffff (1.5GB) PCI/EISA Bus Memory
- */
-static struct resource pcit_mem_resources[] = {
-	{
-		.start	= 0x14000000,
-		.end	= 0x17bfffff,
-		.name	= "PCI IO",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x17c00000,
-		.end	= 0x17ffffff,
-		.name	= "Cache Replacement Area",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x180a0000,
-		.end	= 0x180bffff,
-		.name	= "Video RAM area",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x180c0000,
-		.end	= 0x180fffff,
-		.name	= "ISA Reserved",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x19000000,
-		.end	= 0x1fbfffff,
-		.name	= "PCI MEM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fc00000,
-		.end	= 0x1fc7ffff,
-		.name	= "Boot PROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fc80000,
-		.end	= 0x1fcfffff,
-		.name	= "Diag PROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fd00000,
-		.end	= 0x1fdfffff,
-		.name	= "X-Bus",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fe00000,
-		.end	= 0x1fefffff,
-		.name	= "BIOS map",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1ff00000,
-		.end	= 0x1ff7ffff,
-		.name	= "NVRAM / EEPROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fff0000,
-		.end	= 0x1fffefff,
-		.name	= "MAUI ASIC",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1ffff000,
-		.end	= 0x1fffffff,
-		.name	= "MP Agent",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x20000000,
-		.end	= 0x9fffffff,
-		.name	= "Main Memory",
-		.flags	= IORESOURCE_BUSY
-	}
-};
-
 static void __init sni_pcit_resource_init(void)
 {
 	int i;
 
 	/* request I/O space for devices used on all i[345]86 PCs */
 	for (i = 0; i < ARRAY_SIZE(pcit_io_resources); i++)
-		request_resource(&ioport_resource, pcit_io_resources + i);
-
-	/* request mem space for pcimt-specific devices */
-	for (i = 0; i < ARRAY_SIZE(pcit_mem_resources); i++)
-		request_resource(&sni_mem_resource, pcit_mem_resources + i);
-
-	ioport_resource.end = sni_io_resource.end;
+		request_resource(&sni_io_resource, pcit_io_resources + i);
 }
 
 
@@ -209,9 +126,10 @@ extern struct pci_ops sni_pcit_ops;
 static struct pci_controller sni_pcit_controller = {
 	.pci_ops	= &sni_pcit_ops,
 	.mem_resource	= &sni_mem_resource,
-	.mem_offset	= 0x10000000UL,
+	.mem_offset	= 0x00000000UL,
 	.io_resource	= &sni_io_resource,
-	.io_offset	= 0x00000000UL
+	.io_offset	= 0x00000000UL,
+	.io_map_base    = SNI_PORT_BASE
 };
 
 static void enable_pcit_irq(unsigned int irq)
@@ -262,7 +180,7 @@ static void pcit_hwint0(void)
 	int irq;
 
 	clear_c0_status(IE_IRQ0);
-	irq = ffs((pending >> 16) & 0x7f);
+	irq = ffs((pending >> 16) & 0x3f);
 
 	if (likely(irq > 0))
 		do_IRQ (irq + SNI_PCIT_INT_START - 1);
@@ -289,6 +207,8 @@ static void sni_pcit_hwint_cplus(void)
 
 	if (pending & C_IRQ0)
 		pcit_hwint0();
+	else if (pending & C_IRQ1)
+		do_IRQ (MIPS_CPU_IRQ_BASE + 3);
 	else if (pending & C_IRQ2)
 		do_IRQ (MIPS_CPU_IRQ_BASE + 4);
 	else if (pending & C_IRQ3)
@@ -317,21 +237,23 @@ void __init sni_pcit_cplus_irq_init(void)
 	mips_cpu_irq_init();
 	for (i = SNI_PCIT_INT_START; i <= SNI_PCIT_INT_END; i++)
 		set_irq_chip(i, &pcit_irq_type);
-	*(volatile u32 *)SNI_PCIT_INT_REG = 0;
+	*(volatile u32 *)SNI_PCIT_INT_REG = 0x40000000;
 	sni_hwint = sni_pcit_hwint_cplus;
 	change_c0_status(ST0_IM, IE_IRQ0);
-	setup_irq (SNI_PCIT_INT_START + 6, &sni_isa_irq);
+	setup_irq (MIPS_CPU_IRQ_BASE + 3, &sni_isa_irq);
 }
 
 void sni_pcit_init(void)
 {
-	sni_pcit_resource_init();
 	rtc_mips_get_time = mc146818_get_cmos_time;
 	rtc_mips_set_time = mc146818_set_rtc_mmss;
 	board_time_init = sni_cpu_time_init;
+	ioport_resource.end = sni_io_resource.end;
 #ifdef CONFIG_PCI
+	PCIBIOS_MIN_IO = 0x9000;
 	register_pci_controller(&sni_pcit_controller);
 #endif
+	sni_pcit_resource_init();
 }
 
 static int __init snirm_pcit_setup_devinit(void)
diff --git a/arch/mips/sni/pcimt.c b/arch/mips/sni/pcimt.c
index 8e8593b..9ee208d 100644
--- a/arch/mips/sni/pcimt.c
+++ b/arch/mips/sni/pcimt.c
@@ -91,7 +91,7 @@ static struct platform_device pcimt_serial8250_device = {
 };
 
 static struct resource sni_io_resource = {
-	.start	= 0x00001000UL,
+	.start	= 0x00000000UL,
 	.end	= 0x03bfffffUL,
 	.name	= "PCIMT IO MEM",
 	.flags	= IORESOURCE_IO,
@@ -132,107 +132,19 @@ static struct resource pcimt_io_resources[] = {
 };
 
 static struct resource sni_mem_resource = {
-	.start	= 0x10000000UL,
-	.end	= 0xffffffffUL,
+	.start	= 0x18000000UL,
+	.end	= 0x1fbfffffUL,
 	.name	= "PCIMT PCI MEM",
 	.flags	= IORESOURCE_MEM
 };
 
-/*
- * The RM200/RM300 has a few holes in it's PCI/EISA memory address space used
- * for other purposes.  Be paranoid and allocate all of the before the PCI
- * code gets a chance to to map anything else there ...
- *
- * This leaves the following areas available:
- *
- * 0x10000000 - 0x1009ffff (640kB) PCI/EISA/ISA Bus Memory
- * 0x10100000 - 0x13ffffff ( 15MB) PCI/EISA/ISA Bus Memory
- * 0x18000000 - 0x1fbfffff (124MB) PCI/EISA Bus Memory
- * 0x1ff08000 - 0x1ffeffff (816kB) PCI/EISA Bus Memory
- * 0xa0000000 - 0xffffffff (1.5GB) PCI/EISA Bus Memory
- */
-static struct resource pcimt_mem_resources[] = {
-	{
-		.start	= 0x100a0000,
-		.end	= 0x100bffff,
-		.name	= "Video RAM area",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x100c0000,
-		.end	= 0x100fffff,
-		.name	= "ISA Reserved",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x14000000,
-		.end	= 0x17bfffff,
-		.name	= "PCI IO",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x17c00000,
-		.end	= 0x17ffffff,
-		.name	= "Cache Replacement Area",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1a000000,
-		.end	= 0x1a000003,
-		.name	= "PCI INT Acknowledge",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fc00000,
-		.end	= 0x1fc7ffff,
-		.name	= "Boot PROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fc80000,
-		.end	= 0x1fcfffff,
-		.name	= "Diag PROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fd00000,
-		.end	= 0x1fdfffff,
-		.name	= "X-Bus",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fe00000,
-		.end	= 0x1fefffff,
-		.name	= "BIOS map",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1ff00000,
-		.end	= 0x1ff7ffff,
-		.name	= "NVRAM / EEPROM",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1fff0000,
-		.end	= 0x1fffefff,
-		.name	= "ASIC PCI",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x1ffff000,
-		.end	= 0x1fffffff,
-		.name	= "MP Agent",
-		.flags	= IORESOURCE_BUSY
-	}, {
-		.start	= 0x20000000,
-		.end	= 0x9fffffff,
-		.name	= "Main Memory",
-		.flags	= IORESOURCE_BUSY
-	}
-};
-
 static void __init sni_pcimt_resource_init(void)
 {
 	int i;
 
 	/* request I/O space for devices used on all i[345]86 PCs */
 	for (i = 0; i < ARRAY_SIZE(pcimt_io_resources); i++)
-		request_resource(&ioport_resource, pcimt_io_resources + i);
-
-	/* request mem space for pcimt-specific devices */
-	for (i = 0; i < ARRAY_SIZE(pcimt_mem_resources); i++)
-		request_resource(&sni_mem_resource, pcimt_mem_resources + i);
-
-	ioport_resource.end = sni_io_resource.end;
+		request_resource(&sni_io_resource, pcimt_io_resources + i);
 }
 
 extern struct pci_ops sni_pcimt_ops;
@@ -240,9 +152,10 @@ extern struct pci_ops sni_pcimt_ops;
 static struct pci_controller sni_controller = {
 	.pci_ops	= &sni_pcimt_ops,
 	.mem_resource	= &sni_mem_resource,
-	.mem_offset	= 0x10000000UL,
+	.mem_offset	= 0x00000000UL,
 	.io_resource	= &sni_io_resource,
-	.io_offset	= 0x00000000UL
+	.io_offset	= 0x00000000UL,
+	.io_map_base    = SNI_PORT_BASE
 };
 
 static void enable_pcimt_irq(unsigned int irq)
@@ -363,15 +276,17 @@ void __init sni_pcimt_irq_init(void)
 
 void sni_pcimt_init(void)
 {
-	sni_pcimt_resource_init();
 	sni_pcimt_detect();
 	sni_pcimt_sc_init();
 	rtc_mips_get_time = mc146818_get_cmos_time;
 	rtc_mips_set_time = mc146818_set_rtc_mmss;
 	board_time_init = sni_cpu_time_init;
+	ioport_resource.end = sni_io_resource.end;
 #ifdef CONFIG_PCI
+	PCIBIOS_MIN_IO = 0x9000;
 	register_pci_controller(&sni_controller);
 #endif
+	sni_pcimt_resource_init();
 }
 
 static int __init snirm_pcimt_setup_devinit(void)


-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] Change PCI host bridge setup/resources

[Sergei Shtylyov]

Thomas Bogendoerfer wrote:
> PCI host bridge setup for SNI RM machines with PCI is quite broken, now that
> Linux does it's resource setup own its own. It will use IO addresses,
> which are needed by the EISA config detection and assigns PCI memory
> addresses, which overlap with ISA legacy addresses (video ram). Below
> is a patch, which changes the way how the PCI memory addresses are
> used and sets the minimum IO address to give enough IO space for
> 8 EISA slots). This patch needs the other PCI resource change, I've
> posted.

> diff --git a/arch/mips/sni/pcit.c b/arch/mips/sni/pcit.c
> index 1dfc3f0..00d151f 100644
> --- a/arch/mips/sni/pcit.c
> +++ b/arch/mips/sni/pcit.c
> @@ -43,7 +43,7 @@ static struct platform_device pcit_serial8250_device = {
>  };
>  
>  static struct plat_serial8250_port pcit_cplus_data[] = {
> -	PORT(0x3f8, 4),
> +	PORT(0x3f8, 0),
>  	PORT(0x2f8, 3),
>  	PORT(0x3e8, 4),
>  	PORT(0x2e8, 3),

    Hm, what is that -- UART #1 without IRQ?

> @@ -59,9 +59,9 @@ static struct platform_device pcit_cplus_serial8250_device = {
>  };
> 
>  static struct resource sni_io_resource = {
> -	.start	= 0x00001000UL,
> +	.start	= 0x00000000UL,
>  	.end	= 0x03bfffffUL,
> -	.name	= "PCIT IO MEM",
> +	.name	= "PCIT IO",
>  	.flags	= IORESOURCE_IO,
>  };

    Why us this necessary, only beacuse compatible peripherals are behind PCI?
EISA is behind PCI as well, yet you're setting PCIBIOS_MIN_IO to 0x9000. Does 
this all really make sense? :-/

> @@ -92,6 +92,11 @@ static struct resource pcit_io_resources[] = {
>  		.name	= "dma2",
>  		.flags	= IORESOURCE_BUSY
>  	}, {
> +		.start	=  0xcf8,
> +		.end	= 0xcfb,
> +		.name	= "PCI config addr",
> +		.flags	= IORESOURCE_BUSY
> +	}, {

    This is certainly *not* a PCI or [E]ISA resource. It's decoded by the 
*host* bridge.

>  		.start	=  0xcfc,
>  		.end	= 0xcff,
>  		.name	= "PCI config data",

    Well, why not just join them into one?

>  void sni_pcit_init(void)
>  {
> -	sni_pcit_resource_init();
>  	rtc_mips_get_time = mc146818_get_cmos_time;
>  	rtc_mips_set_time = mc146818_set_rtc_mmss;
>  	board_time_init = sni_cpu_time_init;
> +	ioport_resource.end = sni_io_resource.end;
>  #ifdef CONFIG_PCI
> +	PCIBIOS_MIN_IO = 0x9000;
>  	register_pci_controller(&sni_pcit_controller);
>  #endif
> +	sni_pcit_resource_init();
>  }

WBR, Sergei

Re: [PATCH] Change PCI host bridge setup/resources

[Thomas Bogendoerfer]

On Sun, Apr 08, 2007 at 09:20:31PM +0400, Sergei Shtylyov wrote:
> > static struct plat_serial8250_port pcit_cplus_data[] = {
> >-	PORT(0x3f8, 4),
> >+	PORT(0x3f8, 0),
> > 	PORT(0x2f8, 3),
> > 	PORT(0x3e8, 4),
> > 	PORT(0x2e8, 3),
> 
>    Hm, what is that -- UART #1 without IRQ?

workaround for not fully working interrupts on UART1. IRQ 0 means
polling. Read the source.

> > static struct resource sni_io_resource = {
> >-	.start	= 0x00001000UL,
> >+	.start	= 0x00000000UL,
> > 	.end	= 0x03bfffffUL,
> >-	.name	= "PCIT IO MEM",
> >+	.name	= "PCIT IO",
> > 	.flags	= IORESOURCE_IO,
> > };
> 
>    Why us this necessary, only beacuse compatible peripherals are behind 
>    PCI?
> EISA is behind PCI as well, yet you're setting PCIBIOS_MIN_IO to 0x9000. 
> Does this all really make sense? :-/

it does, how about reading the PCI code ?

EISA IO address space is 0x0000 - 0xffff, so this IO addresses need to
be forwarded by the PCI host bridge. PCIBIOS_MIN_IO is for the PCI
address assignment code, and tells this code to start allocating IO
space starting at 0x9000. This is needed because the pci eisa code
will use n + 0x1000 as EISA slot base addresses, which gives 0x8000
for the 8th (last) slot. So it's IMHO a good idea to avoid collisions
between EISA and PCI for IO space.

>    This is certainly *not* a PCI or [E]ISA resource. It's decoded by the 
> *host* bridge.

so ? It's an IO address no device should use, because it won't work.
Therefore mark it busy. That's all the code does.

> > 		.start	=  0xcfc,
> > 		.end	= 0xcff,
> > 		.name	= "PCI config data",
> 
>    Well, why not just join them into one?

what's your point ? This stuff is all about giving some hints and
avoiding address assignment collisions. I could just drop the whole
table and nothing will change, because the PCI code doesn't assign
IO addresses below 0x9000. Fine with me, but I think it doesn't hurt
to know, what IO addresses are used for some stuff.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] Change PCI host bridge setup/resources

[Geert Uytterhoeven]

On Mon, 9 Apr 2007, Thomas Bogendoerfer wrote:
> On Sun, Apr 08, 2007 at 09:20:31PM +0400, Sergei Shtylyov wrote:
> >    This is certainly *not* a PCI or [E]ISA resource. It's decoded by the 
> > *host* bridge.
> 
> so ? It's an IO address no device should use, because it won't work.
> Therefore mark it busy. That's all the code does.

Yep, it's transparently decoded ISA (which is behind PCI) to control the PCI
bus. Just traditional PC legacy hacks :-)

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

Re: [PATCH] Change PCI host bridge setup/resources

[Sergei Shtylyov]

Hello.

Thomas Bogendoerfer wrote:

>>>static struct plat_serial8250_port pcit_cplus_data[] = {
>>>-	PORT(0x3f8, 4),
>>>+	PORT(0x3f8, 0),
>>>	PORT(0x2f8, 3),
>>>	PORT(0x3e8, 4),
>>>	PORT(0x2e8, 3),

>>   Hm, what is that -- UART #1 without IRQ?

> workaround for not fully working interrupts on UART1. IRQ 0 means
> polling. Read the source.

    Thanks, I've read it quite a lot already. But is UART3 IRQ working (being 
the same as UART1's)?

>>>static struct resource sni_io_resource = {
>>>-	.start	= 0x00001000UL,
>>>+	.start	= 0x00000000UL,
>>>	.end	= 0x03bfffffUL,
>>>-	.name	= "PCIT IO MEM",
>>>+	.name	= "PCIT IO",
>>>	.flags	= IORESOURCE_IO,
>>>};

>>   Why us this necessary, only beacuse compatible peripherals are behind 
>>   PCI?
>>EISA is behind PCI as well, yet you're setting PCIBIOS_MIN_IO to 0x9000. 
>>Does this all really make sense? :-/

> it does, how about reading the PCI code ?

    To me, it doesn't make much sense with or without reading the code.
And note that no other boards claim ports 0x0000 thru 0x0fff to PCI.

> EISA IO address space is 0x0000 - 0xffff, so this IO addresses need to
> be forwarded by the PCI host bridge.

    No need to educate me about EISA.

> PCIBIOS_MIN_IO is for the PCI
> address assignment code, and tells this code to start allocating IO
> space starting at 0x9000.

    I know that too.

> This is needed because the pci eisa code
> will use n + 0x1000 as EISA slot base addresses, which gives 0x8000
> for the 8th (last) slot. So it's IMHO a good idea to avoid collisions
> between EISA and PCI for IO space.

    Yeah, and I'd given 0x00009000 as PCI I/O start address for that same 
purpose. [E]ISA resources, while being accessed (via PCI bus as a proxy) are 
generally not a part of PCI bus.

>>   This is certainly *not* a PCI or [E]ISA resource. It's decoded by the 
>>*host* bridge.

> so ? It's an IO address no device should use, because it won't work.
> Therefore mark it busy. That's all the code does.

    It just shouldn't appear under PCI bus in the resource hierarchy.

>>>		.start	=  0xcfc,
>>>		.end	= 0xcff,
>>>		.name	= "PCI config data",

>>   Well, why not just join them into one?

> what's your point ? This stuff is all about giving some hints and
> avoiding address assignment collisions. I could just drop the whole
> table and nothing will change, because the PCI code doesn't assign
> IO addresses below 0x9000. Fine with me, but I think it doesn't hurt
> to know, what IO addresses are used for some stuff.

    You're changing PCI I/O space start address for no apparent reason which 
seems to break general 8259 code.

> Thomas.

WBR, Sergei

Re: [PATCH] Change PCI host bridge setup/resources

[Sergei Shtylyov]

Hello.

Geert Uytterhoeven wrote:

>>>   This is certainly *not* a PCI or [E]ISA resource. It's decoded by the 
>>>*host* bridge.

>>so ? It's an IO address no device should use, because it won't work.
>>Therefore mark it busy. That's all the code does.

> Yep, it's transparently decoded ISA (which is behind PCI) to control the PCI
> bus. Just traditional PC legacy hacks :-)

    Rubbish. I was complaining about the PCI config/data ports at 0xCF8/0xCFC 
which are by no means part of either [E]ISA or PCI. They're decoded by the 
host to PCI bridge.

WBR, Sergei

Re: [PATCH] Change PCI host bridge setup/resources

[Thomas Bogendoerfer]

On Mon, Apr 09, 2007 at 06:42:40PM +0400, Sergei Shtylyov wrote:
> >workaround for not fully working interrupts on UART1. IRQ 0 means
> >polling. Read the source.
> 
>    Thanks, I've read it quite a lot already. But is UART3 IRQ working 
>    (being the same as UART1's)?

right now, none of the ISA interrupts are working on that machine,
probably because I'm missing some IRQ routing setup. The workaround is
there to get serial console working in userspace.

>    To me, it doesn't make much sense with or without reading the code.
> And note that no other boards claim ports 0x0000 thru 0x0fff to PCI.

no other board MIPS board has EISA behind PCI afaik. So this is a new
situation.

>    Yeah, and I'd given 0x00009000 as PCI I/O start address for that same 
> purpose. [E]ISA resources, while being accessed (via PCI bus as a proxy) 
> are generally not a part of PCI bus.

it would help, if you would try to understand the stuff first. Just read
the EISA code...

>    You're changing PCI I/O space start address for no apparent reason which 
> seems to break general 8259 code.

could you try to understand the issue please ? I could leave the i8259
code alone and everything will work as before. Only the entries for
the PIC would be missing in /proc/iomem (which I could kludge around
by adding them to the pcit/pcimt resource list). Every other platform 
won't see a difference, because no other platform needs to request the
PCI IO space starting at 0x0000. 

I've checked the platform device code, and it uses insert_region() like
my proposed change for i8259. So I'm pretty sure, that's the way to
go.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: [PATCH] Change PCI host bridge setup/resources

[Maciej W. Rozycki]

On Mon, 9 Apr 2007, Thomas Bogendoerfer wrote:

> >    To me, it doesn't make much sense with or without reading the code.
> > And note that no other boards claim ports 0x0000 thru 0x0fff to PCI.
> 
> no other board MIPS board has EISA behind PCI afaik. So this is a new
> situation.

 To everybody involved: quite a few Alpha boxes use the PCEB bridge, which 
may or may not be the same as in here, so they may be used as a reference 
of how things may be set up.  Though, being quite an old port, this code 
may not necessarily represent the best approach possible.

 Personally I think ISA and EISA resources that are behind a PCI bus (or 
any other, for that matter) should be registered as descendants to that 
bus.  It's only the PC architecture that makes (E)ISA resources special -- 
almost any other platform will relocate them arbitrarily (they will not 
start from zero in the host address space, which may even have no notion 
of the I/O address space at all) and may have multiple copies if multiple 
PCI buses are used in a non-tree configuration.  It may be useful to 
register PCI I/O windows in the MMIO space as appropriate too.

 Also mapping PCI I/O addresses from 0 does make sense in some actual 
hardware configurations which do not have any legacy bridges involved, so 
making sure code is prepared to do this is not an unreasonable thing to 
do.  There is currently (or used to be, not so long ago) a problem with 
some code somewhere as I tried such a setup with a SWARM board and I 
recall getting a failure somewhere, which I mean to get back to at one 
point.

  Maciej