2004-11-08 22:56:32

by Mark A. Greer

[permalink] [raw]
Subject: [PATCH][PPC32] Add setup_indirect_pci_nomap() routine

===== arch/ppc/syslib/indirect_pci.c 1.12 vs edited =====
--- 1.12/arch/ppc/syslib/indirect_pci.c 2004-03-17 05:02:23 -07:00
+++ edited/arch/ppc/syslib/indirect_pci.c 2004-10-12 14:24:23 -07:00
@@ -112,15 +112,24 @@
};

void __init
+setup_indirect_pci_nomap(struct pci_controller* hose, u32 cfg_addr,
+ u32 cfg_data)
+{
+ hose->cfg_addr = (unsigned int *)cfg_addr;
+ hose->cfg_data = (unsigned char *)cfg_data;
+ hose->ops = &indirect_pci_ops;
+}
+
+void __init
setup_indirect_pci(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data)
{
unsigned long base = cfg_addr & PAGE_MASK;
char *mbase;

mbase = ioremap(base, PAGE_SIZE);
- hose->cfg_addr = (unsigned int *)(mbase + (cfg_addr & ~PAGE_MASK));
+ cfg_addr = (u32)(mbase + (cfg_addr & ~PAGE_MASK));
if ((cfg_data & PAGE_MASK) != base)
mbase = ioremap(cfg_data & PAGE_MASK, PAGE_SIZE);
- hose->cfg_data = (unsigned char *)(mbase + (cfg_data & ~PAGE_MASK));
- hose->ops = &indirect_pci_ops;
+ cfg_data = (u32)(mbase + (cfg_data & ~PAGE_MASK));
+ setup_indirect_pci_nomap(hose, cfg_addr, cfg_data);
}
===== include/asm-ppc/pci-bridge.h 1.12 vs edited =====
--- 1.12/include/asm-ppc/pci-bridge.h 2003-09-12 09:26:56 -07:00
+++ edited/include/asm-ppc/pci-bridge.h 2004-10-12 14:23:36 -07:00
@@ -94,6 +94,8 @@
int early_write_config_dword(struct pci_controller *hose, int bus, int dev_fn,
int where, u32 val);

+extern void setup_indirect_pci_nomap(struct pci_controller* hose,
+ u32 cfg_addr, u32 cfg_data);
extern void setup_indirect_pci(struct pci_controller* hose,
u32 cfg_addr, u32 cfg_data);
extern void setup_grackle(struct pci_controller *hose);


Attachments:
indirect_pci.patch (1.62 kB)

2004-11-08 23:02:39

by Kumar Gala

[permalink] [raw]
Subject: Re: [PATCH][PPC32] Add setup_indirect_pci_nomap() routine

Mark,

Out of interest, why would we not want to ioremap the cfg addr/data
registers?

- kumar

On Nov 8, 2004, at 4:56 PM, Mark A. Greer wrote:

> This patch adds a routine that sets up indirect pci config space access
> but doesn't ioremap the config space addr/data registers.
>
> Signed-off-by: Mark Greer <[email protected]>
> <indirect_pci.patch>

2004-11-08 23:56:09

by Mark A. Greer

[permalink] [raw]
Subject: Re: [PATCH][PPC32] Add setup_indirect_pci_nomap() routine

Kumar Gala wrote:

> Mark,
>
> Out of interest, why would we not want to ioremap the cfg addr/data
> registers?
>
> - kumar
>
> On Nov 8, 2004, at 4:56 PM, Mark A. Greer wrote:
>
>> This patch adds a routine that sets up indirect pci config space access
>> but doesn't ioremap the config space addr/data registers.
>

You do need them mapped, of course, but:

a) It so happens that on the marvell host bridges those regs are in the
middle of a larger block that is already ioremapp'd.

b) [Warning: Long story...] To determine the type of bridge, the code
has to access a pci cfg register on the bridge so access to those regs
are necessary no matter what. However, some platforms that use the
marvell bridges don't use one or both of the hoses. We've seen cases
where if you try to access the pci bus that isn't wired properly, the
bridge hangs so I can't always use pcibios_alloc_controller() to alloc
the hose struct (or the pci infrastructure will try to scan the bus &
hang the bridge). Instead, in the one routine that gets the bridge
type, I temporarily use a hose struct alloc'd on the stack and call
setup_indirect_pci[_nomap]() with it. Once I've read the bridge type, I
no longer need that mapping but there is no "remove_indirect_pci()"
routine to undo the previous setup. So, worst case, when a platform
uses both hoses, those regs are mapped once when all the bridge's regs
are mapped, a second time when the temporary mapping is used, and a
third time when using a hose struct alloc'd by
pcibios_alloc_controller(). I end up with two unused mappings.

With some work & ugly code, I could get rid of one extra mapping but not
both, and making a "nomap" routine just seemed cleaner. There are
probably other ppc platforms that could use this as well.

Mark