| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
provide again an optional storage for a copy of the descriptor in the `sync'
(fetch) function, and use the returned address afterwards.
On IP22 systems (in the broader sense of the term, thus IP20/IP22/IP24),
descriptors will remain in uncached memory and no local copies need to be made.
On IP28 systems, descriptors will remain in cached memory (so as to avoid
switching to `slow mode'), but a local copy will be performed with the necessary
cache eviction work, so that speculative code execution on R10000 will not
touch the real descriptor.
With this in place, all the explicit descriptor cache operations in if_sq,
some of them being redundant or operating on the wrong number of
descriptors, can be removed, with the HPC DMA wrappers taking care of doing
the right thing.
Tested on IP22 and IP28. IP26 still unhappy but no worse than before.
|
| |
|
|
|
|
|
|
|
|
| |
IP22 motherboard (IP26, IP28). Instead, do not ask for a BUS_DMA_COHERENT
mapping, but perform explicit cache operations.
This removes the need for the memory controller to switch between `fast' and
`slow' mode every time a DMA descriptor is updated.
Tested on IP22 and IP28.
|
| |
|
|
|
| |
false sq positives ("sq not configured" since rejected by the sq driver) in
dmesg, for SCSI HPC boards.
|
| |
|
|
|
| |
as some odd mips designs need moro than 32 bits in there. This causes a lot
of mechanical changes everywhere getsr() is used.
|
| |
|
|
| |
such statements with it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
controller. In this mode, access to physical memory are not allowed to
bypass the cache, and this allows the memory subsystem to run faster.
Of course, some device drivers will require uncached memory access (e.g.
for proper HPC DMA descriptor operation).
New ip22-specific functions to switch between `fast mode' and `slow mode'
are introduced.
hpc(4) now provides read and write routines to fetch a dma descriptor from
uncached memory into a local copy, and update it from said modified copy.
On systems without the ECC MC, these will do nothing and operation will
continue to access the uncached memory directly. On systems with the ECC MC,
they will perform a copy, and the writeback will be done in slow mode.
bus_dmamem_map() requests for DMA memory with BUS_DMA_COHERENT set in flags,
which would return uncached memory, will now always fail on systems with
the ECC memory controller. Drivers which really need uncached memory, and
are aware of this particular setup, will now pass
BUS_DMA_COHERENT | BUS_DMA_BUS1, which will let the request succeed.
sq(4) will use all of the above to work mostly unmodified on ECC MC systems
in fast mode.
Finally, fast mode is enabled after autoconf.
Tested on IP22 and IP28.
|
| |
|
|
|
| |
Previous change was a tad too optimistic. This repairs E++ and GIO SCSI board
operation.
|
| | |
|
| |
|
|
|
| |
figure out whether they attach to the onboard hpc or to an expansion slot
(or the Challenge S IO+ mezzanine). No functional change (yet)
|
| |
|
|
|
| |
temporarily disabled (and then reenabled later). Will be necessary for the
next driver commit.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- break each hpc1/hpc3 child lists into two lists, one for the onboard
devices, and one for the expansion devices.
- do not try to attach Indy-only devices (pckbc, haltwo) on Challenge S.
- do not duplicate entries for expansion devices, only with different interrupt
numbers depending on the system, but instead use a single entry with -1 as
the interrupt level, and have the attachment glue figure out which
interrupt vector applies, depending upon the system.
- on expansion hpc1 (or 1.5) boards, do a minimal bus check to decide whether
or not the hardware we are attaching is there, since we currently don't
know how to tell E++ (sq only) and GIO32 SCSI (wdsc only) boards apart.
This hopefully will get rid of misleading `device not configured' messages.
|
| |
|
|
|
| |
need to have knowledge of the underlying interrupt controller. No functional
change.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the current logic can be traced back to DaveM's intership at SGI in 1996,
and are adequate for the hardware he had access to.
However, ``recent'' Indigo2 and Indy systems are fit with a faster (33MHz
instead of 25MHz) GIO64 bus, which need different timing parameters, and
guess what? The PROM knows the right values to set.
Since programming these timing registers was apparently only necessary for
the Challenge S second interface:
1) only reprogram those registers on an IP24 (Indy, Challenge S) system.
2) pick proper values depending upon the actual GIO64 bus speed.
Item #1 fixes Ethernet operation on Indigo2 (at least my teal R4400SC).
Item #2 fixes Ethernet operation on my R5000SC Indy.
For the record, programming unoptimal value caused `TX DMA underrun' errors
(documented as `can't happen' in the HPC3 documentation, oh the irony),
which could be reproduced reliably with ypbind(8).
|
| |
|
|
| |
PIO write buffer.
|
| |
|
|
|
| |
layout is enough to enforce this. Don't request DMA page boundary alignment
when allocating them.
|
| |
|
|
|
|
|
|
|
| |
narrow these in the various ipXX_machdep.c. On IP22-like systems, narrow
them to 28 bit physical addresses, but unpessimize this by extending this
to 32 bit after autoconf, if no 28-bit limited hpc(4) device has been found.
Since physical memory on these systems start at 128MB, this means that Indigo
systems with more than 128MB memory will behave correctly (and so will Indy
systems with E++ boards and more than 128MB memory).
|
|
|
(IP20, IP22, IP24) in 64-bit mode, adapated from NetBSD. Currently limited
to headless operation, input and video drivers will get ported soon.
Should work on all R4000, R4440 and R5000 based systems. L2 cache on R5000SC
Indy not supported yet (coming soon), R4600 not supported yet either (coming
soon as well).
Tested to boot multiuser on: Indigo2 R4000SC, Indy R4000PC, Indy R4000SC,
Indy R5000SC, Indigo2 R4400SC. There are still glitches in the Ethernet driver
which are being looked at.
Expansion support is limited to the GIO E++ board; GIO boards with PCI-GIO
bridges not ported yet due to the lack of hardware, and this kind of driver
does not port blindly.
Most of this work comes from NetBSD, polishing and integration work, as well
as putting as many ``R4x00 in 64-bit mode'' erratas as necessary, by yours
truly.
More work is coming, as well as trying to get some easy way to boot install
kernels (as older PROM can only boot ECOFF binaries, which won't do for the
kernel).
|
miod