Port-powerpc archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Located problem in pcn driver...
Hello,
I think I have the answer to my own question... Here's a patch to the powerpc
port's bus_dma.c file that fixes the problem for me, and looks correct given
(a) the other places in this source file that set the ds_addr value, and (b)
how some of the other bus_dma.c implementations handle this:
Index: sys/arch/powerpc/powerpc/bus_dma.c
===================================================================
RCS file: /usr/NetBSD/src/sys/arch/powerpc/powerpc/bus_dma.c,v
retrieving revision 1.10
diff -c -r1.10 bus_dma.c
*** sys/arch/powerpc/powerpc/bus_dma.c 2003/04/09 22:28:56 1.10
--- sys/arch/powerpc/powerpc/bus_dma.c 2003/04/18 08:20:38
***************
*** 325,331 ****
error = EFBIG;
continue;
}
! map->dm_segs[seg].ds_addr = lastaddr;
map->dm_segs[seg].ds_len = m->m_len;
lastaddr += m->m_len;
continue;
--- 325,332 ----
error = EFBIG;
continue;
}
! map->dm_segs[seg].ds_addr = PHYS_TO_BUS_MEM(t,
lastaddr);
!
map->dm_segs[seg].ds_len = m->m_len;
lastaddr += m->m_len;
continue;
Comments?
John...
--- John Gordon <john_94501%yahoo.com@localhost> wrote:
> Hello,
>
> Well, after much hunting and a lot of debug code I have tracked down why my
> NS
> 1000 was unable to send anything over the network, despite being able to
> receive packets correctly. Problem is I am not certain of how to solve it
> correctly...
>
> The problem is simple: the address of the data that is being inserted into
> the
> transmit descriptor is not a PCI address, but a CPU address. On the NS 1000,
> as
> with many PPC systems, the main memory is in the 0 -> 2GB portion of the
> CPU's
> address space, but from the PCI side of the host bridge it is in in the 2GB
> ->
> 4GB range.
>
> Now, the code in the pcn_start() routine is as follows:
>
> if (sc->sc_swstyle == LE_B20_SSTYLE_PCNETPCI3) {
> for (nexttx = sc->sc_txnext, seg = 0;
> seg < dmamap->dm_nsegs;
> seg++, nexttx = PCN_NEXTTX(nexttx)) {
> /*
> * If this is the first descriptor we're
> * enqueueing, don't set the OWN bit just
> * yet. That could cause a race condition.
> * We'll do it below.
> */
> sc->sc_txdescs[nexttx].tmd0 = 0;
> sc->sc_txdescs[nexttx].tmd2 =
> htole32(dmamap->dm_segs[seg].ds_addr);
> sc->sc_txdescs[nexttx].tmd1 =
> htole32(LE_T1_ONES |
> (nexttx == sc->sc_txnext ? 0 : LE_T1_OWN) |
> (LE_BCNT(dmamap->dm_segs[seg].ds_len) &
> LE_T1_BCNT_MASK));
> lasttx = nexttx;
> }
> }
>
> The line in the middle of that loop that sets tmd2 is correctly handling the
> translation to PCI's little endian, but it is not dealing with the difference
> between the CPU's view of the address space, and the PCI bus' view of the
> address space.
>
> So, how do I fix this? Is the problem in this piece of code, or should the
> ds_addr value already have been translated to a PCI-view address? Obviously,
> for my testing it is simple to just set the top bit on the address, but how
> do
> I do this correctly, and where (in the driver here, or in the DMA code that
> sets up the ds_addr value in the first place)?
>
> Suggestions welcomed...
>
> Thanks,
> John...
>
> =====
> Rate Corporate America at http://exec-ratings.bluedonkey.org
>
> __________________________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo
> http://search.yahoo.com
=====
Rate Corporate America at http://exec-ratings.bluedonkey.org
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Home |
Main Index |
Thread Index |
Old Index