[parisc-linux] Dino PCI and I/O spaces

[parisc-linux] Dino PCI and I/O spaces

[Alan Cox]

I've put together draft code to handle the Dino PCI configuration space
accesses. There seems to be no way to do byte sized config accesses, do
I just read 32bits mask and write 32bits ?

The I/O space documentation also doesn't cover how to force sizes for
inb/inw/inl.

Im guessing you simply do that sized memory access to the 0x6C offset.

I'm mapping the notional I/O space 0x0000->0xFFFF as PCI space I/O. Since
HP boxes have I/O space high no MMIO can be confused for PCI this way.
If we have multiple Dino's in any box I need to put my thinking hat back on.

Also as a btw: PCI I/O port access will suck rocks on HP because we have
to grab a lock since it is a two stage operation. That may mean we want
to write smart copy/csum/io and ins* functions for PCI block I/O.

Alan

Re: [parisc-linux] Dino PCI and I/O spaces

[Matthew Wilcox]

On Mon, Jun 14, 1999 at 04:15:08PM +0100, Alan Cox wrote:
> Also as a btw: PCI I/O port access will suck rocks on HP because we have
> to grab a lock since it is a two stage operation. That may mean we want
> to write smart copy/csum/io and ins* functions for PCI block I/O.

Do we only have to grab a lock on SMP machines, or can we sleep between
the two accesses?

-- 
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] Dino PCI and I/O spaces

[Alan Cox]

> On Mon, Jun 14, 1999 at 04:15:08PM +0100, Alan Cox wrote:
> > Also as a btw: PCI I/O port access will suck rocks on HP because we have
> > to grab a lock since it is a two stage operation. That may mean we want
> > to write smart copy/csum/io and ins* functions for PCI block I/O.
> 
> Do we only have to grab a lock on SMP machines, or can we sleep between
> the two accesses?

On a uniprocessor we might take an interrupt between the two cycles. So we
have to suffer anyway

Re: [parisc-linux] Dino PCI and I/O spaces

[Matthew Wilcox]

On Mon, Jun 14, 1999 at 04:21:29PM +0100, Alan Cox wrote:
> > On Mon, Jun 14, 1999 at 04:15:08PM +0100, Alan Cox wrote:
> > > Also as a btw: PCI I/O port access will suck rocks on HP because we have
> > > to grab a lock since it is a two stage operation. That may mean we want
> > > to write smart copy/csum/io and ins* functions for PCI block I/O.
> > 
> > Do we only have to grab a lock on SMP machines, or can we sleep between
> > the two accesses?
> 
> On a uniprocessor we might take an interrupt between the two cycles. So we
> have to suffer anyway

Then we ought to disable interrupts, surely?  Otherwise we can have:

Grab lock
interrupt taken
driver attempts to perform IO, tries to take lock, machine hangs solid.

Or what sort of locking scheme did you have in mind?

-- 
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] Dino PCI and I/O spaces

[Alan Cox]

> > On a uniprocessor we might take an interrupt between the two cycles. So we
> > have to suffer anyway
> 
> Then we ought to disable interrupts, surely?  Otherwise we can have:
> 
> Grab lock
> interrupt taken
> driver attempts to perform IO, tries to take lock, machine hangs solid.
> 
> Or what sort of locking scheme did you have in mind?

Im already using spinlock_irqsave, for the obvious reason you enumerate above

Re: [parisc-linux] Dino PCI and I/O spaces

[Grant Grundler]

Alan Cox wrote:
> 
> I've put together draft code to handle the Dino PCI configuration space
> accesses. There seems to be no way to do byte sized config accesses, do
> I just read 32bits mask and write 32bits ?

I don't recall HP-UX performing read/modify/write.
I thought Dino will forward the byte enables to the PCI bus.
PCI-PCI bridge numbering I think depends on this.

> The I/O space documentation also doesn't cover how to force sizes for
> inb/inw/inl.

It doesn't clearly for configuration space.
It does for I/O space. I suspect all spaces are handled the
same in this regard.
See section 7.7.3 "Configuration Access Endianness".
Other sections may talk more about the "byte enable" signals.

> Im guessing you simply do that sized memory access to the 0x6C offset.

That's been my experience.

> 
> I'm mapping the notional I/O space 0x0000->0xFFFF as PCI space I/O. Since
> HP boxes have I/O space high no MMIO can be confused for PCI this way.
> If we have multiple Dino's in any box I need to put my thinking hat back on.

Not a problem. Each Dino has it's own configuration and I/O space.
If the parent/child relationship between Dino and PCI devices is
maintained then bus numbering and address assignment is not a problem.

Enabling memory mapped I/O requires programming Dino to respond
to a unique host address range. On the A/B/C/J class boxes, firmware
takes care of this and programming PCI devices BAR registers to match.
The OS can pick this up and pass it too device drivers.

On these boxes it's "uncomplicated" since the host physical address
is the same as the PCI bus address. I mention this since it's not
the case for all HP platforms.

> Also as a btw: PCI I/O port access will suck rocks on HP because we have
> to grab a lock since it is a two stage operation. That may mean we want
> to write smart copy/csum/io and ins* functions for PCI block I/O.

Yup.  HP has generally used memory mapped I/O on all it's platforms.
Since I/O port space is (was?) not performance path, it was OK for the
PCI device driver has to use what we call an "accessor" function.
Ditto for PCI configuration space access.

grant

> Alan
> 
> ---------------------------------------------------------------------------
> To unsubscribe: send e-mail to parisc-linux-request@thepuffingroup.com with
> `unsubscribe' as the subject.
> 

Grant Grundler
Enterprise Systems Technology Lab
+1.408.447.7253

Re: [parisc-linux] Dino PCI and I/O spaces

[Alan Cox]

> > accesses. There seems to be no way to do byte sized config accesses, do
> > I just read 32bits mask and write 32bits ?
> 
> I thought Dino will forward the byte enables to the PCI bus.
> PCI-PCI bridge numbering I think depends on this.

So how do I set those. The documentaiton also says the low two bits of
the register read back as 0. I guess that doesnt actually imply that the
write of it has no affect. 

> It does for I/O space. I suspect all spaces are handled the
> same in this regard.
> See section 7.7.3 "Configuration Access Endianness".
> Other sections may talk more about the "byte enable" signals.

Ok

> > Im guessing you simply do that sized memory access to the 0x6C offset.
> That's been my experience.

Cool

> Enabling memory mapped I/O requires programming Dino to respond
> to a unique host address range. On the A/B/C/J class boxes, firmware
> takes care of this and programming PCI devices BAR registers to match.
> The OS can pick this up and pass it too device drivers.

Excellent. So I can relatively easily stuff an S3 card in the box and
use it as a debugging buffer once we get booting

> On these boxes it's "uncomplicated" since the host physical address
> is the same as the PCI bus address. I mention this since it's not
> the case for all HP platforms.

Ok. We have a clear notion of bus/physical/virtual seperation, and translation
macros. Linux stuff all uses

virt_to_bus() - to convert to bus space
virt_to_phys() - to convert to physical space

Alan

Re: [parisc-linux] Dino PCI and I/O spaces

[Grant Grundler]

Alan Cox wrote:
> > > accesses. There seems to be no way to do byte sized config accesses, do
> > > I just read 32bits mask and write 32bits ?
> > 
> > I thought Dino will forward the byte enables to the PCI bus.
> > PCI-PCI bridge numbering I think depends on this.
> 
> So how do I set those. The documentaiton also says the low two bits of
> the register read back as 0. I guess that doesnt actually imply that the
> write of it has no affect. 

The PCI_CONFIG_ADDR register (offset 0x64) is used to source the
word address. So it's not surprising the lower order bits are RO.

"Byte enables" are GSC and PCI bus signals - not register contents.
The PA processor generates byte enable signals on the GSC bus and
Dino forwards those for the appropriate bytes (swapped to match
the swapping/endian conversion done for the PCI_CONFIG_DATA register.)
The byte enable signals are taken when a processor read/write targets
the PCI_CONFIG_DATA register (offset 0x68). The contents of PCI_CONFIG_ADDR
and bytes enable signals from GSC bus are combined to generate a read/write
transaction on the PCI bus.

(Disclaimer: I'm not as certain of the above as it sounds though I
believe it's correct - remember, I'm a SW engineer :^)


> > On these boxes it's "uncomplicated" since the host physical address
> > is the same as the PCI bus address. I mention this since it's not
> > the case for all HP platforms.
> 
> Ok. We have a clear notion of bus/physical/virtual seperation, and
> translation macros. Linux stuff all uses
> 
> virt_to_bus() - to convert to bus space
> virt_to_phys() - to convert to physical space

Excellent.

later,
grant

> 
> Alan
> 

Grant Grundler
Enterprise Systems Technology Lab
+1.408.447.7253