History log of /netbsd-src/sys/arch/algor/include/isa_machdep.h (Results 1 – 7 of 7)
Revision Date Author Comments
# eee38be7 08-Jul-2011 matt <matt@NetBSD.org>

Major update of algor.
Now uses generic mips bus_space.h bus_dma.h isa_machdep.h pci_machdep.h
Now uses evbmips versions of cpu.c isadma_bounce.c mcclock_isa.c


# ab367b5f 19-Aug-2009 dyoung <dyoung@NetBSD.org>

(Re-)define isa_detach_hook(), and define isa_dmadestroy(). Update
some isa_chipset_tag_t->ic_detach_hook() definitions.


# ce099b40 28-Apr-2008 martin <martin@NetBSD.org>

Remove clause 3 and 4 from TNF licenses


# 95e1ffb1 11-Dec-2005 christos <christos@NetBSD.org>

merge ktrace-lwp.


# c5b66303 14-Sep-2004 simonb <simonb@NetBSD.org>

White space nit.


# d88cf589 09-May-2003 fvdl <fvdl@NetBSD.org>

A few ISA sound drivers like to share dma channels, and hence deferred
isa_dmamap_create() calls to their open/close entrypoints. This worked
with some luck, but broke on i386 when _bus_dmamap_create

A few ISA sound drivers like to share dma channels, and hence deferred
isa_dmamap_create() calls to their open/close entrypoints. This worked
with some luck, but broke on i386 when _bus_dmamap_create started
to allocate bounce buffers upfront, since memory below 16M may well
not be available when the sound devices is opened for the Nth time.

To fix this, create a new simple interface, isa_drq_alloc/isa_drq_free,
wrappers around already existing bitmask macros. These are expected
to be used before an isa_dmamap_create call, and after an
isa_dmamap_destroy call, respectively. For the sb and ad1848 drivers,
they're deferred until open/close.

All isa_dmamap_create calls can now use BUS_DMA_ALLOCNOW and be done
at attach time.

show more ...


# 16b9c606 28-May-2001 thorpej <thorpej@NetBSD.org>

A port to the Algorithmics MIPS evaluation boards. We currently
support the P-5064, which has a QED RM5xxx CPU soldered on.

There is some skeletal support for the P-4032 (an older board, which
had

A port to the Algorithmics MIPS evaluation boards. We currently
support the P-5064, which has a QED RM5xxx CPU soldered on.

There is some skeletal support for the P-4032 (an older board, which
had an R4xxx CPU). There are some placeholders for the P-6032, which
is their newest board, but no real code yet (the P-6032 has a different
PCI controller, the Algorithmics BONITO).

There are still some (apprently softintr-related) problems with the
algor kernel, but it works well-enough to self-host.

Kudos to Allegro Networks for loaning me a P-5064 board on which to do
the port.

show more ...