[parisc-linux-cvs] [PATCH] PCI MMIO mapping

[Grant Grundler]

Bjorn Helgaas wrote:
> Thanks for the detailed feedback!

welcome :^)

...
> I can parse it now, but I don't think it is quite correct yet.  On 64-bit 
> "legacy" (non-PAT) boxes, we set the 32 high-order bits of lmmio_base, 
> then later do "res->start |= ldev->lmmio_base".  This isn't sign-extension 
> because it doesn't depend on the value of a sign bit.  Right?

Well, IO space is always at 0xf0000000 for legacy boxes.
So while the algorithm isn't using the sign bit, it could.


> > This has me slightly nervous.
> > Does this work on both C3000 and A500? (ie Sprockets and PAT PDCs)
> > If so, does it work because the value is sign extended?
> > Or because the READ_REG32() is cast to a 64-bit read and both PDCs
> > write a 64-bit value into LMMIO_BASE?
> 
> I haven't tested on anything but Superdome yet, because I was ignorant of 
> what the important test cases were.  I'll test C3000 and A500 before 
> checking in.  I did not intend to be relying on any sign extension or 
> side-effects of casting.

Ok. It has to work on c3k in both 32- and 64-bit.

> As I understand it, the current behavior is:
> 
> 	32-bit boxes:
> 		host address == PCI bus address always

Except for card-mode dino. :^(
parisc-linux drivers for devices on card-mode Dino basically
ignore MMIO space since we can only add hooks to inb/outb.
To date, that's only the 100BT driver.


> 	64-bit legacy:
> 		PCI bus addresses are of the form 0x00000000XXXXXXXX
> 		host_addr = (0xffffffff << 32) | bus_addr
> 		bus_addr = (host_addr & 0xffffffff)
> 
> 	64-bit PAT boxes:
> 		PCI bus addresses are of the form 0x00000000XXXXXXXX
> 		lmmio_base is of the form 0xXXXXXXXX00000000
> 		host_addr = lmmio_base | bus_addr
> 		bus_addr = (host_addr & 0xffffffff)

64-bit PAT boxes also support GMMIO. ie 64-bit BAR's don't have to
have the upper 32-bit bits zero'd like on any legacy box.
We may need to differentiate between 32-bit PCI bus addresses 
and 64-bit PCI bus addresses.

> My reasoning was that since there's no overlap between bits set in 
> lmmio_base and bits set in PCI bus addresses, this should be equivalent to
> 
> 	host_addr = bus_addr + offset
> 	bus_addr = host_addr - offset
> 
> where
> 
> 	32-bit boxes:
> 		offset = 0
> 
> 	64-bit legacy:
> 		offset = (0xffffffff << 32)
> 
> 	64-bit PAT boxes:
> 		offset = lmmio_base_PA_VIEW - lmmio_base_IO_VIEW
> 		(for non-Superdome boxes, lmmio_base_IO_VIEW is 0)

For 32-bit PCI addresses (32-bit BAR or upper 32-bits are zero) I
think your reasoning is correct.

...
> The Mercury ERS describes ELMMIO and says Elroy has it too, but removed it 
> from the ERS.  I'll leave the comment as it was except for correcting 
> "distrubuted".  I had just thought ELMMIO itself was a typo.

Ok.


...
> Why is -1 preferable to 0?  I'm not interested in making card-mode dino 
> MMIO work either; the only reason I set mem_space_offset at all here was 
> so that if somebody *did* try to use PCI_{HOST,BUS}_ADDR with such a dino, 
> it wouldn't use an uninitialized offset.

I was hoping the system would fault in a recognizable way but
it will probably do that with 0 as well.


> > In fact, I'm wondering if pcibios_host_to_bus()even implements
> > pcivtobus() correctly.  IIRC, pcivtobus() is to convert *any* Host
> > virtual address into an address which can be DMA'd to by the PCI
> > device. This mess was replaced with Dynamic DMA mapping in 2.3 and
> > it's just taking the drivers a while to catch up.
> 
> I think the driver uses pcivtobus() only for CSRs and script memory, not 
> or arbitrary host addresses.  Since it doesn't appear in 2.4.4. at all, 
> we're in luck, because this was the only use for pcibios_host_to_bus(), so 
> we'll be able to just nuke the whole thing.

ok. I'm not going to worry about it then as long as c3k/a500 still work.

thanks!
grant

Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253

--4F3D1482A.990740571/dsl2.external.hp.com--