From: Philipp Rumpf <prumpf@suse.de>
To: parisc-linux@thepuffingroup.com
Subject: Re: [parisc-linux-cvs] grundler
Date: Thu, 2 Sep 1999 10:40:07 +0200 [thread overview]
Message-ID: <19990902104007.H629@suse.de> (raw)
In-Reply-To: <199909012302.RAA04035@puffin.external.hp.com>; from grundler@puffin.external.hp.com on Wed, Sep 01, 1999 at 05:02:23PM -0600
> Update of /home/cvs/parisc/linux/include/asm-parisc
> In directory puffin.external.hp.com:/tmp/cvs-serv4014/linux/include/asm-parisc
>
> Modified Files:
> pci.h
> Log Message:
> Update GSCtoPCI (Dino) bus adapter support. Have most of the design
> in place and what's my "first cut" implementation.
I don't want to sound aggressive, but I really do not see the point in most
of your changes.
Let's go through them:
- renamed pci_{port,config,bus}_ops to {port,config,bus}_ops.
waste of struct namespace should asm/pci.h be included accidentally
(furthermore it strikes me as strange to have pci_bios_ops, but simply bus_ops.
- typedef unsigned int irq_t;
the type of irqs is defined to be int (not unsigned int) in ABIs we cannot
change if we ever want to see a merged parisc kernel.
- renamed PCI_NUM_BUS to MAX_BUSSES.
I think we really should restrict ourselves to exporting symbols, macros and
other names starting with PCI_ and pci_. (I am aware this may be because it
took me way too long to synch the trees and that this just reflects the rest
of your code).
> Marked lots of stuff with "TODO" - I'll keep whacking at these.
- "** TODO: I don't think we need the "bus" parameter. "dev""
ignoring your comment style ;), it really strikes me as a good idea to keep
the interface in place to support native-to-PCI bridges with more than one
bus on them. It might be a good idea for those not to pass the "relative"
bus number to those instead of the absolute one, but that is just a change
in one spot as opposed to changing an interface and digging through several
drivers.
> Main issues to still be resolved are:
> o GSC device claim - how does dino driver learn about GSC devices
For that we need Alex's code, but it looks very much like we will have a list
of GSC devices like we currently have for PCI on systems where that is the
native bus. Then, you will use gsc_find_device(u16 hversion); and be happy.
> o Registration and handling of interrupts (request_irq() support)
None. The current idea is dino.c registers a region of 32 "virtual" IRQs (i.e.
Linux IRQ cookies, not EIRR bits) and uses do_irq_mask to handle them. Also,
pcibios_fixup will put the right irq cookie numbers in the pci_devices list.
> o How drivers will use I/O port space accessor functions.
> (assumes we won't change them to use MMIO space)
basically,
u8 inb(u32 address) {
return pci_ops[(address>>16)].port.inb(
pci_devs[(address>>16],
(u8) (address>>16) / pci_rel_bus[(address>>16)],
(u16) adress);
}
that looks slow but I hope for the "port accesses are slow anyway" argument
to win.
Philipp Rumpf
next parent reply other threads:[~1999-09-02 8:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <199909012302.RAA04035@puffin.external.hp.com>
1999-09-02 8:40 ` Philipp Rumpf [this message]
1999-09-02 14:26 ` [parisc-linux-cvs] grundler Philipp Rumpf
[not found] <199909012302.RAA04044@puffin.external.hp.com>
1999-09-02 9:08 ` Philipp Rumpf
1999-09-02 14:43 ` Matthew Wilcox
[not found] <199909012302.RAA04026@puffin.external.hp.com>
1999-09-02 9:12 ` Philipp Rumpf
1999-09-02 17:20 ` Grant Grundler
1999-09-03 11:15 ` Philipp Rumpf
1999-09-03 16:22 ` Alex deVries
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=19990902104007.H629@suse.de \
--to=prumpf@suse.de \
--cc=parisc-linux@thepuffingroup.com \
/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.