Re: [parisc-linux-cvs] grundler

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

[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

[parisc-linux] Card-mode Dino

[Grant Grundler]

Alex deVries wrote:

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

No. Dino implements the PA I/O architected registers but no IODC.
I suspect the problem is it's really a bus converter and that
needs PDC support - IODC entry points don't apply to this.
Can anyone confirm this?

grant

Re: [parisc-linux] Card-mode Dino

[LaMont Jones]

> > And does the dino-on-a-card have it's own IODC on the card?
> No. Dino implements the PA I/O architected registers but no IODC.
> I suspect the problem is it's really a bus converter and that
> needs PDC support - IODC entry points don't apply to this.
> Can anyone confirm this?

Can't confirm or deny, but it is possible (we've done it at least once)
to build a bus converter that does not require PDC help, just architecture
knowledge.

lamont

Re: [parisc-linux] Card-mode Dino

[Grant Grundler]

LaMont Jones wrote:
> > > And does the dino-on-a-card have it's own IODC on the card?
> > No. Dino implements the PA I/O architected registers but no IODC.
> > I suspect the problem is it's really a bus converter and that
> > needs PDC support - IODC entry points don't apply to this.
> > Can anyone confirm this?
> 
> Can't confirm or deny, but it is possible (we've done it at least once)
> to build a bus converter that does not require PDC help, just architecture
> knowledge.

Let me add some depth to my suspicion.
Platform IO space (which Dino "translates" 1:1 to PCI MMIO space) is
assigned exclusively by PDC on platforms with GSC busses.  The OS can't
assign I/O space addresses to devices unless (a) knows where I/O space
is (could make assumptions about this), (b) exactly which parts
have been used by other bus converters or devices, and (c) which
parts are reserved for "special" devices (eg graphics)?

I suspect IODC can't provide this sort of functionality. Let me
rephrase my question: does anyone know if architected PDC interfaces
provide enough information to satisfy a/b/c above?

thanks,
grant

Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

[parisc-linux] PCI-like busses

[Grant Grundler]

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

Ok.

> So:  Are there parisc boxen with more than one type of interface to PCI-like
> busses?

B/C/D class boxen haben PCI u. EISA (u. GSC) "slots".
Since learning EISA/ISA busses are "PCI-like", the answer is "yes".
And if this answer is right, then I'll put back the "multi-bus type"
support in pci.h. I don't get how EISA would use these services
(perhaps just the IRQ stuff?) but I'll trust you on that.

> 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 ?

Yes - but I'm only aware of K/T class "form factor" (shape/size).
These won't normally fit in the A/B/C/D class boxes which also have
GSC slots. Any other HP person know if any card-mode Dino's were
made for workstations?

(Next week I'll see if I can wedge the K-class one into a workstation
anyway)

grant


Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253

Re: PCI-like busses

[Philipp Rumpf]

> > So:  Are there parisc boxen with more than one type of interface to PCI-like
> > busses?
> 
> B/C/D class boxen haben PCI u. EISA (u. GSC) "slots".
> Since learning EISA/ISA busses are "PCI-like", the answer is "yes".

Of course, strictly speaking we could separate between pci busses (where we
have configuration space accesses) and isa-like busses (where we don't).  I
don't see any advantage.  For port accesses, we don't have to separate.

> And if this answer is right, then I'll put back the "multi-bus type"
> support in pci.h. I don't get how EISA would use these services
> (perhaps just the IRQ stuff?) but I'll trust you on that.

Remember I still want to remove the IRQ handling out of struct pci_bus_ops.

> Yes - but I'm only aware of K/T class "form factor" (shape/size).
> These won't normally fit in the A/B/C/D class boxes which also have

The Dino-on-a-card I have in the A180C is quite long, yes.

> (Next week I'll see if I can wedge the K-class one into a workstation
> anyway)

Don't destroy any hardware ;)


	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

[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

[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]

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