From: "Rob Taylor" <robt@flyingpig.com>
To: "Dan Malek" <dan@mvista.com>
Cc: <linuxppc-embedded@lists.linuxppc.org>
Subject: RE: switching linux kernels
Date: Fri, 6 Oct 2000 17:50:52 +0100 [thread overview]
Message-ID: <000e01c02fb5$9637a8b0$b400a8c0@eventhorizon> (raw)
In-Reply-To: <39D21A61.445CC61F@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]
I was just having a second look at io.h, cos i'm using a hacked up version for
some ppcboot stuff, and I noticed that when CONFIG_APUS is on read doesn't
eieio, and when its on it does, surely readw/writew, etc shouldn't eieio and
in/out, etc should? infact the whole thing seems a bit of a mess.
attached are the functions I'm using for pci accesses in ppcboot. Doubt it'll be
of any use, but I thought you might be interested.
Thanks,
Rob Taylor
Flying Pig Systems
>
> > presumably this is due to int in/out macros adding _IO_BASE to the pointer?
>
> Yes.
>
> > ... So
> > am I right in thinking that it makes sense to use in/out for ISA
> accesses (if
> > _IO_BASE is set correctly for your platform) and readb/writeb/..
> for the rest of
> > your memory mapped registers?
>
>
> Well, yes, today. Some of us have been "fighting" about this lately.
> I'm not a fan of address arithmetic in the inb/outb, so probably on
> 8xx and 82xx you will always have some "opaque" handle to in/out that
> doesn't resemble any notion of x86 "ports". The reason is that on
> these 8xx and 82xx systems (and potentially others) we don't have very
> flexible host bridges, or the processors are used in complex multiple
> PCI bus configurations where the notion of "bus 0" may not exist. You
> can't assume using a hard coded (or legacy) port number will get you
> anywhere but a bus fault.
>
>
> -- Dan
>
>
[-- Attachment #2: pci_io.h --]
[-- Type: application/octet-stream, Size: 2473 bytes --]
/* originally from linux source (asm-ppc/io.h).
* Sanity added by Rob Taylor, Flying Pig Systems, 2000
*/
#ifndef _PCI_IO_H_
#define _PCI_IO_H_
#include <io.h>
#define pcimem_readb(addr) (*(volatile u8 *) (addr))
#define pcimem_writeb(b,addr) ((*(volatile u8 *) (addr)) = (b))
#define pciio_readb(addr) (*(volatile u8 *) (addr)); eieio()
#define pciio_writeb(b,addr) ((*(volatile u8 *) (addr)) = (b)); eieio()
#if !defined(__BIG_ENDIAN)
#define pcimem_readw(addr) (*(volatile u16 *) (addr))
#define pcimem_readl(addr) (*(volatile u32 *) (addr))
#define pcimem_writew(b,addr) ((*(volatile u16 *) (addr)) = (b))
#define pcimem_writel(b,addr) ((*(volatile u32 *) (addr)) = (b))
#else
#define pcimem_readw(addr) pcimem_read_le16((volatile u16 *)(addr))
#define pcimem_readl(addr) pcimem_read_le32((volatile u32 *)(addr))
#define pcimem_writew(b,addr) pcimem_write_le16((volatile u16 *)(addr),(b))
#define pcimem_writel(b,addr) pcimem_write_le32((volatile u32 *)(addr),(b))
#endif
#if !defined(__BIG_ENDIAN)
#define pciio_readw(addr) (*(volatile u16 *) (addr)); eieio()
#define pciio_readl(addr) (*(volatile u32 *) (addr)); eieio()
#define pciio_writew(b,addr) ((*(volatile u16 *) (addr)) = (b)); eieio()
#define pciio_writel(b,addr) ((*(volatile u32 *) (addr)) = (b)); eieio()
#else
#define pciio_readw(addr) pcimem_read_le16((volatile u16 *)(addr)); eieio()
#define pciio_readl(addr) pcimem_read_le32((volatile u32 *)(addr)); eieio()
#define pciio_writew(b,addr) pcimem_write_le16((volatile u16 *)(addr),(b)); eieio()
#define pciio_writel(b,addr) pcimem_write_le32((volatile u32 *)(addr),(b)); eieio()
#endif
extern inline int pcimem_read_le16(volatile unsigned short *addr)
{
int ret;
__asm__ __volatile__("lhbrx %0,0,%1" : "=r" (ret) :
"r" (addr), "m" (*addr));
return ret;
}
extern inline void pcimem_write_le16(volatile unsigned short *addr, int val)
{
__asm__ __volatile__("sthbrx %1,0,%2" : "=m" (*addr) :
"r" (val), "r" (addr));
}
extern inline unsigned pcimem_read_le32(volatile unsigned *addr)
{
unsigned ret;
__asm__ __volatile__("lwbrx %0,0,%1" : "=r" (ret) :
"r" (addr), "m" (*addr));
return ret;
}
extern inline void pcimem_write_le32(volatile unsigned *addr, int val)
{
__asm__ __volatile__("stwbrx %1,0,%2" : "=m" (*addr) :
"r" (val), "r" (addr));
}
#endif /* _PCI_IO_H_ */
next prev parent reply other threads:[~2000-10-06 16:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-09-26 22:34 switching linux kernels Julia Elbert
2000-09-27 0:40 ` Graham Stoney
2000-09-27 5:59 ` Dan Malek
2000-09-27 6:41 ` Graham Stoney
2000-09-27 9:31 ` Rob Taylor
2000-09-27 16:03 ` Dan Malek
2000-10-06 16:50 ` Rob Taylor [this message]
-- strict thread matches above, loose matches on Subject: below --
2000-09-26 18:24 Julia Elbert
2000-09-26 16:59 Julia Elbert
2000-09-26 0:02 Julia Elbert
2000-09-26 0:25 ` Graham Stoney
2000-09-26 15:54 ` Dan Malek
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='000e01c02fb5$9637a8b0$b400a8c0@eventhorizon' \
--to=robt@flyingpig.com \
--cc=dan@mvista.com \
--cc=linuxppc-embedded@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).