[parisc-linux] Astro and 100BT still not working

[Grant Grundler]

Grant Grundler wrote:
> Some possible theories:
> 1) it's not coherent (perhaps LCI didn't work right),

First off, I noticed (again) that the I/O MMU (aka IIOC)
isn't documented. Since it wasn't part of "Astro" documentation
it didn't get put through "the process".  Astro uses I/O MMU logic
original designed for Ike and thus didn't repeat stuff written
in the Ike Documentation. I think the public files even say
that someplace.

Anyway, Here's something interesting out of the "Ike" documentation:

    7.6 Virtual Index support

    In PCX-W based systems, DMA is coherent only if a virtual index is
    supplied with the physical address. So, most DMA addresses will have
    to be translated by the TLB. When the translation is done, the virtual
    index stored in the VINDEX field of the I/O PDIR entry is supplied by
    the TLB. In some cases, however, this may lead to performance problems.
    So, a Direct Virtual Index (DVI) mode is also supported. The PSC in
    Elroy is responsible for recognizing a DVI address and separating the
    virtual index from the address. See the PSC chapter. In either mode,
    8 bits of virtual index are supported.

    For I/O PDIR fetches themselves, IKE assumes that the I/O PDIR is
    equivalently mapped. I.e., it assumes that the physical address =
    virtual address and so it supplies bits 19:12 of the physical address
    as the virtual index. To ensure coherency of I/O PDIR fetches, the
    I/O PDIR must be equivalently mapped.


The second paragraph worries me. It suggests parisc-linux has to flush
the cachelines which contain I/O Pdir data every time such data is
changed since it's not equivalently mapped.  Since only bits 31:28
are different for kernel space (0xc....), does this still apply?

How can I test this?
(ie What's the linux function/macro to flush a cacheline?)

FWIW, this is a safe assumption for HP-UX.

grant

Grant Grundler
Unix Development Lab
+1.408.447.7253