From owner-freebsd-hackers  Sat Dec 13 21:51:27 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id VAA12169
          for hackers-outgoing; Sat, 13 Dec 1997 21:51:27 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA12163
          for <hackers@freebsd.org>; Sat, 13 Dec 1997 21:51:20 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
          by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id VAA09724;
          Sat, 13 Dec 1997 21:51:11 -0800 (PST)
          (envelope-from hasty@rah.star-gate.com)
Message-Id: <199712140551.VAA09724@rah.star-gate.com>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Jun-ichiro itojun Itoh <itojun@itojun.org>
cc: gjp@erols.net (Gary Palmer), hackers@freebsd.org
Subject: Re: Beginning SPARC port 
In-reply-to: Your message of "Sun, 14 Dec 1997 14:18:39 +0900."
             <16608.882076719@coconut.itojun.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 13 Dec 1997 21:51:10 -0800
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

The functions is already there:

        old_irq = pci_conf_read(tag, PCI_INTERRUPT_REG);
        pci_conf_write(tag, PCI_INTERRUPT_REG, BROOKTREE_IRQ);

And usually PCI devices have i/o mapped registers.

	Amancio


> 
> >> 	hardware I/O model is CPU specific.  There are architectures
> >> 	that do not have inb/outb instruction, and maps I/O device control
> >> 	registers onto memory.  I dunno how Sparc-with-PCI motherboard
> >> 	access pci registers, but I'm sure there has to be bunch of changes.
> >Right, but in that case you #define the inb/outb macros to be the
> >appropriate load/store instructions for the processor.
> >What I am trying to say is that while it may not be the Politically
> >Correct(TM) solution, it is not totally i386 bound either. Being
> >#defines, its a bit more flexible than you were making out.
> 
> 	Yes, I agree with your idea, as the first step.
> 	In the future we should introduce some function like,
> 	pci_reg_write_byte(), for more platform-independency.
> 	Not all the implementers know about i386:-)
> 
> itojun
>