lkml.org 
[lkml]   [2000]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectThe IO problem, ISA vs. PCI
    Date
    Note to linux-kenrel readers: This discussion is the Nth attempt to find
    a solution to handle both legacy IOs and PCI IOs on machines with several
    IO busses memory mapped at different locations in the CPU space.

    >No please, is there anybody bloat-conscious on this damned list ? Burying
    >more and more code inside each {in,out}[bwl] is not the solution.

    Well, that is pretty small overhead, and probably ridiculous compared to
    the overhead of the IO itself. Most fast devices use MMIO anyway.

    The problem is that whatever solution someone propose, there is _always_
    somebody to reject it.

    >Just define a macro ISA_PORT or something like this and update the kernel
    >to replace all the in/out to fixed ports to do in/out(ISA_PORT(n)). If you
    >don't do it you'll get a nice panic so you'll find all the places quite
    >fast.

    That basically mean making different macros for ISA in/out and PCI in/
    out. I've proposed this several time, but it requires changes to the
    common code, and all I got when talking about this was flames from x86 people.

    >Drawbacks ?

    Take the time to make this fit into some x86 people head. Also, I need
    something that can be ported quickly to 2.4. I'm afraid even if we make
    everybody agree to it, it will be delayed to 2.5.

    Linus: Would you accept this change now ?

    #define ISA_PORT(n) (n)

    And change to _all_ drivers doing legacy IOs to use that in their in/out
    macros ?

    I still prefer making separate macros for legacy IOs (isa_in/isa_out) and
    for PCI IOs (in/out), or the opposite if you prefer (in/out for isa and
    pci_in/pci_out for PCI).
    On x86, they would resolve to the same thing, while on our platforms,
    they could be handled differently.

    >PCI I/O resources will have to be kernel virtual, physical is impossible
    >with PreP if we want to lift the 2Gbuser space restriction (PreP I/O is
    >from 2 to 3 Gb physical and the first thing to do is to reallocate devices
    >which use it since most firmware use it too liberally, like one device
    >every ... 256Mb). There are other and better ways to increase user
    >available virtual space, however. And anyway I don't want any stinking add
    >in each in/out macro.

    Well, in 2.4 we can easily reassign PCI IOs if we configure the bridge
    with proper resources. If all goes well, my new PCI code should handle
    that fine (should be ready this week-end).

    >Indeed, this is too awkward (is tere no way to redirect only the VGA
    >part of the legacy I/O space ? That's what the PCI-PCI bridges do, but
    >I've not yet used a single machine with AGP so I'm ignorant).

    No, most bridges used on macs can't do that. In fact, AFAIK, it's not
    possible to access the ISA memory space neither on those machines (on
    UniN, I can't generate memory cycles at lower address than 0x80000000).

    My "pet" solution would be to have all legacy drivers request an IO base
    this way

    base = isa_get_IO_base(legacy_addr);

    The isa_get_IO_base function could then be "tweaked" to recognize known
    legacy addresses and return different bases. (There might still be
    problems with VGA vs. parallell, I don't know x86 world well enough to be
    sure).

    Ben.

    ------------------ RFC822 Header Follows ------------------
    From: Benjamin Herrenschmidt <bh40@calva.net>
    To: Gabriel Paubert <paubert@iram.es>, Linux/PowerPC Devel List
    <linuxppc-dev@lists.linuxppc.org>, Linus Torvalds <torvalds@transmeta.com>
    Cc: <linux-kernel@vger.kernel.org>
    Subject: Re: dual head r128
    Date: Thu, 12 Oct 2000 18:58:15 +0200
    Message-Id: <19340906102959.14429@192.168.1.2>
    In-Reply-To: <Pine.HPX.4.10.10010121719150.16113-100000@gra-ux1.iram.es>
    References: <Pine.HPX.4.10.10010121719150.16113-100000@gra-ux1.iram.es>
    X-Mailer: CTM PowerMail 3.0.5 <http://www.ctmdev.com>
    MIME-Version: 1.0
    Content-Type: text/plain; charset=US-ASCII
    Content-Transfer-Encoding: 7bit
    -----------------------------------------------------------


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:45    [W:2.870 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site