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
next prev parent 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