linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <linuxppc-dev@lists.linuxppc.org>, <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@redhat.com>
Subject: Re: IO issues vs. multiple busses
Date: Sun, 4 Mar 2001 20:55:33 +0100	[thread overview]
Message-ID: <19350127132717.21015@smtp.wanadoo.fr> (raw)
In-Reply-To: <Pine.LNX.4.10.10103031601260.455-100000@cassiopeia.home>
In-Reply-To: <Pine.LNX.4.10.10103031601260.455-100000@cassiopeia.home>

>So once again I vote for the introduction of
>isa_{request,release}_mem_region(), just like we already have isa_readb() and
>friends.

Well, it's the same problem as the IO, there may be more than one ISA mem
region,
especially when you put 2 video cards on 2 different PCI hosts (even without a
PCI-ISA bridge).

In fact, with a PCI-ISA bridge, I can imagine a config where you need 2 ISA IO
regions and 2 ISA mem regions on the same PCI bus if that bridge does address 
translation.

My concern for now is mostly to get video cards fixed, I don't care much about
legacy ISA hardware as in those case, I guess we can limit ourselves to a
single
ISA bus and inb/oub beeing happy to cope with it.

The problem is that we use the same macros (inb/outb) to access that ISA bus,
and to access any PCI IO bus. Well, I would suggest the following:

 - inb/outb without offset -> the ISA bus if any, or the IO space of the
   first PCI host
 - inb/outb with offset (or encoded HBA number) -> IO space of an other bus
 - pci_get_bus_io_base() returns the IO offset for accessing the Nth PCI
   bus IO space so that the fb devs can do VGA IOs on the bus that holds
   their card.
 - pci_get_bus_isa_mem_base() returns the base address at which isa mem
   is available for a given PCI bus (that is the address that generates
   mem cycles in the range 0->64k). This is a physical address, the driver
   still have to ioremap it. Some PCI cards can have a BAR mapping the
   VGA memory elsewhere, drivers for those cards should prefer the BAR
   mapping of course.

All IO ranges can be mapped via kernel VM tricks into a single contiguous
space
with the offset beeing something like a 64k increment, or we can have the
inb/outb
do a lookup of the host bus like on parisc. That's an arch implementation
detail.

Is that ok ? I know it's not perfect, but it would allow to solve the most
important problem for now. The PCI cards in need of IOs (like PCI IDE cards)
can have their resources fixed up by the arch code in order to tap the correct
bus. Only the real legacy ISA drivers will be limited to the fixed (default)
ISA bus.

Ben.


  reply	other threads:[~2001-03-04 19:56 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <19350125063652.28310@mailhost.mipsys.com>
2001-03-02 18:43 ` IO issues vs. multiple busses Grant Grundler
2001-03-03  2:45   ` Benjamin Herrenschmidt
2001-03-03 15:07     ` Geert Uytterhoeven
2001-03-04 19:55       ` Benjamin Herrenschmidt [this message]
2001-03-03 18:05     ` Grant Grundler
2001-03-04 20:04       ` Geert Uytterhoeven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19350127132717.21015@smtp.wanadoo.fr \
    --to=benh@kernel.crashing.org \
    --cc=davem@redhat.com \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).