On Fri, 23 Jul 2004 17:19:23 +0200
Manuel Bouyer <bouyer@antioche.lip6.fr> wrote:

> bus_dmamem_alloc(9) says:
>         The mapping of this memory is machine-dependent (or "opaque");
>         machine-independent code is not to assume that the addresses
>         returned are valid in kernel virtual address space, or that
>         the addresses returned are system physical addresses.  The
>         address
>=20
> To me, this means that we can't make any assumptions about the values
> returned by bus_dmamem_alloc(), and especially it's wrong to assume we
> can do memory-related operations on ds_addr/ds_len.
That is the reason why I think fpa(4) does invalid things. E.g.
bus_dma(9) code may need that ds_addr/ds_len is page aligend / an
integer multiple of a page.

> If this is really needed, we may need a bus_dmamem_submap(), or
> something like this.
> But I have the feeling that this could be handled in some other ways,
> maybe with device-dependant macros or functions, like siop/esiop does.
I agree.=20

> My guess is that fpa(4) needs fixing. I suspect it may have problems
> on platforms like sparc64 for the same reason.
My thoughts. fpa(4) is broken on sparc / sparc64. I saw fpa(4) working
on alpha and powerpc, I asume it is working on i386 too. This
architectures have (at least partially) similar bus_dma(9)
implementations. Sparc / sparc64 bus_dma(9) is different to alpha /
powerpc / i386 and hp700 has some similarities to sparc / sparc64...

BTW: I did a hack to pdq_ifsubr.c:pdq_os_memalloc_contig(). I commented
out the double bus_dmamem_map() and only created a new bus_dmamap_t with
appropriate offsets that describes the same region as the other mapping.
Now fpa(4) starts to work but fails to communicate with the hardware. As
the debugging options in fpa(4) are broken too I stoped diging into
this. Below is a output that shows how far I got:

dino0 at phantomas0 hpa 0xfff80000 path 8/0 irq 28 ipl 1: Dino V3.1
pci0 at dino0
pci0: i/o space, memory space enabled
fpa0 at pci0 dev 1 function 0

PDQ Descriptor Block =3D 0x5cd4000 (PA =3D 0x635000)
    Receive Queue          =3D 0x5cd4000
    Transmit Queue         =3D 0x5cd4800
    Host SMT Queue         =3D 0x5cd5000
    Command Response Queue =3D 0x5cd5280
    Command Request Queue  =3D 0x5cd5300
PDQ Consumer Block =3D 0x5cd53c0
PDQ CSRs: BASE =3D 0xf0fec000
    Port Reset                =3D 0x0 [0x00000000]
    Host Data                 =3D 0x4 [0x00000000]
    Port Control              =3D 0x8 [0x00000000]
    Port Data A               =3D 0xc [0x00000000]
    Port Data B               =3D 0x10 [0x00000000]
    Port Status               =3D 0x14 [0x00000200]
    Host Int Type 0           =3D 0x18 [0x000000d2]
    Host Int Enable           =3D 0x1c [0x00000000]
    Type 2 Producer           =3D 0x20 [0x00000000]
    Command Response Producer =3D 0x28 [0x00000000]
    Command Request Producer  =3D 0x2c [0x00000000]
    Host SMT Producer         =3D 0x30 [0x00000000]
    Unsolicited Producer      =3D 0x34 [0x00000000]
PDQ Command Request Buffer =3D 0x5cd5500 (PA=3D0x636500)
PDQ Command Response Buffer =3D 0x5cd5900 (PA=3D0x636900)
PDQ Unsolicit Event Buffer =3D 0x5cd6000 (PA=3D0x637000)
PDQ Adapter State =3D DMA Unavailable
CSR cmd spun 193 times
CSR cmd spun 193 times
CSR cmd spun 197 times
CSR cmd spun 167 times
CSR cmd spun 228 times
CSR cmd spun 224 times
CSR cmd spun 884 times
Transition to DMA Available took 0 spins
PDQ Queue Command Request: Status Chars Get queued
PDQ Adapter State =3D Halted
Halt code =3D 6 (DMA Error)
PFI status =3D 0x2, Host 0 Fatal Interrupt =3D 0x0
fpa0: initialization failed
esiop0 at pci0 dev 19 function 0: Symbios Logic 53c875 (ultra-wide scsi)
--=20


tsch=FC=DF,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/