From: David Woodhouse <dwmw2@infradead.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: dhowells@redhat.com (David Howells),
linux-kernel@vger.kernel.org, arjanv@redhat.com
Subject: Re: [RFC] I/O Access Abstractions
Date: Thu, 28 Jun 2001 14:55:38 +0100 [thread overview]
Message-ID: <7040.993736538@redhat.com> (raw)
In-Reply-To: <E15FbuU-0006wH-00@the-village.bc.nu>
In-Reply-To: <E15FbuU-0006wH-00@the-village.bc.nu>
alan@lxorguk.ukuu.org.uk said:
> PCI memory (and sometimes I/O) writes are posted, Since x86 memory
> writes are also parallelisable instructions and since the CPU merely
> has to retire the writes in order your stall basically doesnt exist.
True. I can envisage a situation where the overhead of the function call is
noticeable. It would be interesting to see if it actually happens in real
life. If so, and if we set up the abstraction properly, we can keep
the accesses inline for those architectures where it's a win.
#ifdef CONFIG_VIRTUAL_BUS
#define resource_readb(res, x) res->readb(res, x)
#else
#define resource_readb(res, x) readb(x)
#endif
Having per-resource I/O methods would help us to remove some of the
cruft which is accumulating in various non-x86 code. Note that the below is
the _core_ routines for _one_ board - I'm not even including the extra
indirection through the machine vector here....
static inline volatile __u16 *
port2adr(unsigned int port)
{
if (port > 0x2000)
return (volatile __u16 *) (PA_MRSHPC + (port - 0x2000));
else if (port >= 0x1000)
return (volatile __u16 *) (PA_83902 + (port << 1));
else if (sh_pcic_io_start <= port && port <= sh_pcic_io_stop)
return (volatile __u16 *) (sh_pcic_io_wbase + (port &~ 1));
else
return (volatile __u16 *) (PA_SUPERIO + (port << 1));
}
static inline int
shifted_port(unsigned long port)
{
/* For IDE registers, value is not shifted */
if ((0x1f0 <= port && port < 0x1f8) || port == 0x3f6)
return 0;
else
return 1;
}
unsigned char se_inb(unsigned long port)
{
unsigned long pciiobrSet;
volatile unsigned long pciIoArea;
unsigned char pciIoData;
if (PXSEG(port))
return *(volatile unsigned char *)port;
#if defined(CONFIG_CPU_SUBTYPE_SH7751) && defined(CONFIG_PCI)
else if((port >= PCIBIOS_MIN_IO) && (port <= PCIBIOS_MIN_IO + SH7751_PCI_IO_SIZE)) {
pciiobrSet = (port & 0xFFFC0000);
*PCIIOBR = pciiobrSet;
pciIoArea = port & 0x0003FFFF;
pciIoArea += PCI_IO_AREA;
pciIoData = *((unsigned char*)pciIoArea);
return (unsigned char)pciIoData;
}
#endif /* defined(CONFIG_CPU_SUBTYPE_SH7751) && defined(CONFIG_PCI) */
else if (sh_pcic_io_start <= port && port <= sh_pcic_io_stop)
return *(__u8 *) (sh_pcic_io_wbase + 0x40000 + port);
else if (shifted_port(port))
return (*port2adr(port) >> 8);
else
return (*port2adr(port))&0xff;
}
--
dwmw2
next prev parent reply other threads:[~2001-06-28 13:56 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 [this message]
2001-06-28 16:02 ` Jes Sorensen
2001-06-29 8:31 ` David Howells
2001-06-29 21:02 ` Jes Sorensen
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=7040.993736538@redhat.com \
--to=dwmw2@infradead.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjanv@redhat.com \
--cc=dhowells@redhat.com \
--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