public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jes Sorensen <jes@sunsite.dk>
To: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, arjanv@redhat.com
Subject: Re: [RFC] I/O Access Abstractions
Date: 29 Jun 2001 23:02:24 +0200	[thread overview]
Message-ID: <d3bsn7gftr.fsf@lxplus015.cern.ch> (raw)
In-Reply-To: <3652.993803483@warthog.cambridge.redhat.com>
In-Reply-To: David Howells's message of "Fri, 29 Jun 2001 09:31:23 +0100"

>>>>> "David" == David Howells <dhowells@redhat.com> writes:

David> Jes Sorensen <jes@sunsite.dk> wrote:
>>  Have you considered the method used by the 8390 Ethernet driver?
>> For each device, add a pointer to the registers and a register
>> shift.

David> And also flags to specify which address space the I/O ports
David> reside in, and which how to adjust the host-PCI bridge to bring
David> the appropriate bit of the PCI address space into view through
David> the CPU address space window. Don't laugh - it happens.

Hmm, I am shocked ;-)

>> I really don't like hacing virtual access functions that makes
>> memory mapped I/O look the same as I/O operations.

David> Why not? It makes drivers a simpler and more flexible if they
David> can treat different types of resource in the same way. serial.c
David> is a really good example of this:

It will also degrade performance if you introduce all these weird
tests or function calls in the hot path.

David> The switch has to be performed at runtime - so you get at least
David> one conditional branch in your code, probably more. My proposal
David> would replace the conditional branch with a subroutine (which
David> lacks the pipline stall).

Actually on some architectures you'd prefer the conditional branch
over the subroutine call when you can do predication like on the ia64.

David> Also a number of drivers (eg: ne2k-pci) have to be bound to
David> compile time to either I/O space or memory space. This would
David> allow you to do it at runtime without incurring conditional
David> branching.

But it's going to cost for the ones who do not support this.

>> For memory mapped I/O you want to be able to smart optimizations to
>> reduce the access on the PCI bus (or similar).

David> I wouldn't have thought you'd want to reduce the number of
David> accesses to the PCI bus. If, for example, you did to writes to
David> a memory-mapped I/O register, you don't want the first to be
David> optimised away.

One good example I can think off is when you update a dma descriptor
in PCI shared memory space (__raw_writel()). In that case you want to
be able to use posted writes so all writes is done in one PCI write
transaction instead of individual ones.

Jes

  reply	other threads:[~2001-06-29 21:04 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-28 13:13 [RFC] I/O Access Abstractions David Howells
2001-06-28 13:32 ` Alan Cox
2001-06-28 13:55   ` David Woodhouse
2001-06-28 16:02     ` Jes Sorensen
2001-06-29  8:31       ` David Howells
2001-06-29 21:02         ` Jes Sorensen [this message]
2001-07-02 14:22         ` David Woodhouse
2001-07-02 15:57           ` David Howells
2001-07-02 16:17             ` David Woodhouse
2001-07-02 16:20               ` Alan Cox
2001-07-02 16:41                 ` David Woodhouse
2001-07-02 16:56                   ` Alan Cox
2001-07-02 18:22                     ` Russell King
2001-07-02 18:26                       ` Jeff Garzik
2001-07-02 20:10                         ` Alan Cox
2001-07-02 22:08                           ` Benjamin Herrenschmidt
2001-07-02 22:15                             ` Alan Cox
2001-07-02 23:54                               ` Benjamin Herrenschmidt
2001-07-03 12:02                                 ` Alan Cox
2001-07-03 14:38                                   ` Benjamin Herrenschmidt
2001-07-03  2:06                           ` Jeff Garzik
2001-07-03  8:38                             ` David Howells
2001-07-07 11:27                               ` Geert Uytterhoeven
2001-07-03  8:15                         ` David Howells
2001-07-03  8:22                           ` Jeff Garzik
2001-07-03  8:31                             ` Jeff Garzik
2001-07-03  9:00                               ` David Howells
2001-07-03  9:29                                 ` Jeff Garzik
2001-07-02 22:10                       ` Benjamin Herrenschmidt
2001-07-03  8:04                     ` David Howells
2001-07-03  7:55                 ` David Howells
2001-07-03  8:00                   ` Jeff Garzik
2001-07-03  8:07                     ` David Howells
2001-07-03 11:53                   ` Alan Cox
2001-07-07 11:26                   ` Geert Uytterhoeven
     [not found] <20010702191129.A29246@flint.arm.linux.org.uk>
2001-07-03  8:12 ` David Howells

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=d3bsn7gftr.fsf@lxplus015.cern.ch \
    --to=jes@sunsite.dk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=arjanv@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.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