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

[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