All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.