linux-mips
[Top] [All Lists]

Re: [PATCH Cobalt 1/1] 64-bit fix

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>