linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
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_ */

  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).