| To: | maillist@jg555.com |
|---|---|
| Subject: | Re: [PATCH Cobalt 1/1] 64-bit fix |
| From: | Atsushi Nemoto <anemo@mba.ocn.ne.jp> |
| Date: | Fri, 20 Jan 2006 01:35:19 +0900 (JST) |
| Cc: | ralf@linux-mips.org, tbm@cyrius.com, pdh@colonel-panic.org, linux-mips@linux-mips.org |
| In-reply-to: | <43CE821A.6060004@jg555.com> |
| Original-recipient: | rfc822;linux-mips@linux-mips.org |
| References: | <20060117135145.GE3336@linux-mips.org> <20060117.232350.93019515.anemo@mba.ocn.ne.jp> <43CE821A.6060004@jg555.com> |
| Sender: | linux-mips-bounce@linux-mips.org |
>>>>> On Wed, 18 Jan 2006 09:59:54 -0800, Jim Gifford <maillist@jg555.com> said: jim> We all need to understand the concerns with the current jim> method. The only issue I see from Ralf is the following: jim> Broken on multiple PCI busses. Yes, it is an only reason I have ever seen. jim> Now the way I understand the issue is the current iomap.c jim> only handles a single bus, Ralf's point is that if there are jim> multiple busses this patch may not work properly. Is that a jim> correct statement Ralf. I think the current iomap can handle multiple busses. The traditional way (ioremap + read[bwl] for memory space and in[bwl] for IO space) can be used on multiple PCI busses if pci resources were properly configured. (Though IO space address might be a bit strange value due to single global mips_io_port_base, it works anyway.) The current iomap basically do same jobs. --- Atsushi Nemoto |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available, Nigel Stephens |
|---|---|
| Next by Date: | Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available, Stephane Eranian |
| Previous by Thread: | Re: [PATCH Cobalt 1/1] 64-bit fix, Jim Gifford |
| Next by Thread: | Re: [PATCH Cobalt 1/1] 64-bit fix, Jim Gifford |
| Indexes: | [Date] [Thread] [Top] [All Lists] |