Re: [parisc-linux-cvs] grundler

Re: [parisc-linux-cvs] grundler

[Philipp Rumpf]

> 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

Re: [parisc-linux-cvs] grundler

[Philipp Rumpf]

On Wed, Sep 01, 1999 at 05:02:23PM -0600, grundler@puffin.external.hp.com wrote:
> Update of /home/cvs/parisc/linux/drivers/gecko
> In directory puffin.external.hp.com:/tmp/cvs-serv4014/linux/drivers/gecko
> 
> Modified Files:
> 	dino.c 

okay, let's go through the changes here too:

 - strange STATIC define with a comment about "performance" kernels.

I don't see the point.  Is there one ?

 - use of irq_t all over the place

I don't mind this, but it really doesn't matter and just using int has the
advantage of still being able to printk it.

 - Dino-specific IRQ management

As far as I am concerned, there is no way I want to have 5 different IRQ
managements in the kernel.  It is not needed, the performance loss is minimal,
I don't see any other advantages to it.  (I just skipped that code so you don't
get all my complaints)

 - #if 0-ing out dino_walk_bus

remove it.  we really don't need any #if 0 bodies swimming around our trees.

 - check for potentially defect Dino chips

Nothing negative I can say about that

 - +** TODO: Dino needs a method to look at and possibly "claim" GSC devices.

it's what you #if 0-ed out. (
        struct gsc_dev *dev = gsc_devices;

	while(dev = dev->next) {
		if(is_dino(dev)) {
			blah blah 
		}
	}
).

 - split dino init into two parts

I don't see the point.

 - changes to dino_config_write_byte aso (renaming them in the process)

Is this for supporting more than one PCI bus via pci-to-pci bridges ?
looks unnecessary to me, but I really don't know


 - +** Performance is going to stink if drivers use I/O port instead
   +** of MMIO.

This is not Dino-specific.

 - use of readb aso instead of gsc_readb aso

gsc_readb is there for a reason.

	Philipp Rumpf

Re: [parisc-linux-cvs] grundler

[Philipp Rumpf]

> Modified Files:
> 	pci.c 

- removed support for more than one bus

we don't want that, do we ?

- don't see anything else


That's it for today, I promise.

	Philipp Rumpf

Re: [parisc-linux-cvs] grundler

[Philipp Rumpf]

> I don't want to sound aggressive, but I really do not see the point in most
> of your changes.

I really didn't.  Honest.  Even if the rest of the mails seems to have suggested
so to about everyone who read them.

> the type of irqs is defined to be int (not unsigned int) in ABIs we cannot

APIs.  Sorry.  Second time today I mix them up.  (Actually, this one was the first
time).

Re: [parisc-linux-cvs] grundler

[Matthew Wilcox]

On Thu, Sep 02, 1999 at 11:08:31AM +0200, Philipp Rumpf wrote:
>  - use of readb aso instead of gsc_readb aso
> 
> gsc_readb is there for a reason.

Let me amplify on this a little.  As I understand it, Linus has decreed
that readb/writeb/(etc) shall work on busses which `look like PCI'.
All other busses (zorro, podule, sbus, ...) shall define their own
*_readb/writeb/...  functions.  People have proposed auto-detecting which
bus is being written to and doing the right thing, but Linus disagrees.
So that's why we have gsc_readb, because GSC looks insufficiently
like PCI.  Does this make sense?

-- 
Matthew Wilcox <willy@bofh.ai>
"Windows and MacOS are products, contrived by engineers in the service of
specific companies. Unix, by contrast, is not so much a product as it is a
painstakingly compiled oral history of the hacker subculture." - N Stephenson

Re: [parisc-linux-cvs] grundler

[Grant Grundler]

Philipp Rumpf wrote:
> > Modified Files:
> > 	pci.c 
> 
> - removed support for more than one bus

Not quite - removed support for more than one type of PCI bus adapter.
PA platforms only support one type of PCI bus adapter at a time.
We could link in more than on PCI bus driver but only one will
ever get used. (At least that's my goal).

> we don't want that, do we ?

Rather we don't need it.
If you want it you can have it. :^)

> That's it for today, I promise.

ditto.

thanks,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: [parisc-linux-cvs] grundler

[Philipp Rumpf]

> Not quite - removed support for more than one type of PCI bus adapter.
> PA platforms only support one type of PCI bus adapter at a time.

Sorry ? Alex told me the exact opposite when I asked him and I relied on that.

So:  Are there parisc boxen with more than one type of interface to PCI-like
busses ? For example, can I take a Dino-on-a-card card and put it into a box
which does not use Dino as native-to-PCI bridge ?

	Philipp Rumpf

Re: [parisc-linux-cvs] grundler

[Alex deVries]

Philipp Rumpf wrote:
> > Not quite - removed support for more than one type of PCI bus adapter.
> > PA platforms only support one type of PCI bus adapter at a time.
> 
> Sorry ? Alex told me the exact opposite when I asked him and I relied on that.

I don't *think* I ever said that, but if I did, I was wrong.

> So:  Are there parisc boxen with more than one type of interface to PCI-like
> busses ? For example, can I take a Dino-on-a-card card and put it into a box
> which does not use Dino as native-to-PCI bridge ?

And does the dino-on-a-card have it's own IODC on the card?

- Alex

-- 
Alex deVries
Vice President of Engineering
The Puffin Group