int _bus_dmatag_subregion(bus_dma_tag_t tag,
bus_addr_t min_addr,
bus_addr_t max_addr,
bus_dma_tag_t *newtag,
int flags)
void _bus_dmatag_destroy(bus_dma_tag_t tag)
that allow a (normally broken/limited) device to restrict the bus address
range it can talk to. this is used by bce(4) to limit DMA addresses to
1GB range, the maximum the chip can address.
all this is from Yorick Hardy <yhardy@uj.ac.za> with input from several
people on tech-kern.
XXX: bus_dma(9) needs an update still.
P_*/L_* naming convention, and rename the in-kernel flags to avoid
conflict. (P_ -> PK_, L_ -> LW_ ). Add back the (now unused) LSDEAD
constant.
Restores source compatibility with pre-newlock2 tools like ps or top.
Reviewed by Andrew Doran.
by Slava Semushin <slava.semushin@gmail.com>.
To verify that no nasty side effects of duplicate includes (or their
removal) have an effect here, I've compiled an i386/ALL kernel with
and without the patch, and the only difference in the resulting .o
files was in shifted line numbers in some assert() calls.
The comparison of the .o files was based on the output of "objdump -D".
Thanks to martin@ for the input on testing.
- finish implementing splraiseipl (and makeiplcookie).
http://mail-index.NetBSD.org/tech-kern/2006/07/01/0000.html
- complete workqueue(9) and fix its ipl problem, which is reported
to cause audio skipping.
- fix netbt (at least compilation problems) for some ports.
- fix PR/33218.
to how other KSEG-style pmaps (alpha, sh3, sh5) do.
Add a DIAGNOSTIC panic for KSEG1 addresses (nothing should touch
uncached memory, right?)
Clean up the the pmapdebug printfs a little too (athough with
more ugly #ifdef DEBUG bits of code).
XXX: should use DPRINTF() type printfs here.
Fixes panic running regress/sys/kern/umount on MIPS platforms
reported by Martin Husemann.
which have virtual address indexed cache and whose pmaps don't always
allow normal shared mappings even for read only pages.
In future, these pmaps should be rewritten to handle such read only
shared mappings properly like ARM pmap, but currently we just disable
sosend_loan() to avoid unnecessary uncached mappings and cache flushes
on MIPS3 CPUs, or map/unmap thrashing on SH4.
Discussed with thorpej a while ago.
from cpu_configure(9) to cpu_initclocks(9) on mips ports which use
mips3_clockintr.c:mips3_clockintr() (i.e. CPU INT5 clock) to avoid
hardclock(9) before softclock interrupt is initialized in initclocks().
This should be harmless because initclocks() is a part of configure()
in these days and there is no MI function which expects hardware
interrupts between cpu_configure(9) and cpu_initclocks(9).
Disccussed on tech-kern and port-mips.
dumpdev. this occurs when we try to set the dumpdev to a device
with no driver loaded. this fixes PR#34872.
in sys_swapctl, if bdevsw_lookup() fails, set dumpdev = NODEV
before calling cpu_dumpconf(). (this also fixes PR#34872.)
XXX: cpu_dumpconf() should probably be changed to take a dumpdev
XXX: and return an error in such cases, but that is a much more
XXX: intrusive change.
XXX2: this is only run-tested on sparc64 and compile tested on a
XXX2: couple of platforms.
Specifically, the SPI flash now operates as a nearly fully functional block
device (other than lacking disklabel support). It does some basic translation
stuff, so that if you attempt to write a block, the underlying flash sectors
(usually 64k in size) will be read, erased and rewritten.
To minize thrashing, the spiflash strategy routine attempts to gather writes
to the same sector together, so that in the typical case you will not have to
repeatedly erase/rewrite the sector. It also attempts to check and verify
whether an erase cycle is truly needed. There are still access patterns that
will cause multiple erases to occur, and so I heartily discourage the use
of these flash devices for storing anything other than small configuration
data, or write-once images. If you want to do more than that, then someone
should try to write a real flash translation layer.
The drivers attempt to provide some level of asynchronous operation, so that
while you are erasing or writing to the flash, other things can reasonably
take place.
Note that spiflash does not do bad block remapping. It also doesn't detect
when a device is in read-only mode, or if some sectors are read-only. It
only supports uniform sectored NOR flash. It lacks any code to deal with
disklabels, and does not offer any disk related ioctls.
These limitations aside, it would not be terribly hard, I think, to break
out the code I've done to create a generic "norflash" driver, backed by
a "common" spiflash module. Then other flash drivers (e.g. athflash, etc.)
could benefit from the ability to use this as a block device. I've tried
to architect it to support that, if someone else wants to do the work.
(Hi Jared!)
The primary reason that I've not added code to deal with disklabels is that
I had a difficult time figuring out which framework (disklabels or wedges)
to use, and which bits of code were necessary to implement. In the case of
the flash devices I'm working with, a parser to deal with redboot FIS images
(partitions) would need to be added. I was prepared to do this, but gave
up owing to the complete and total lack of any API or design documentation
pertaining to the requirements for disk drivers and disklabel management or
wedges. I would strongly encourage someone who knows something about
wedges or disklabels to write a simple document (or even a dummy driver)
showing which interfaces should be provided in new mass storage drivers.
This work was funded by the Champaign-Urbana Community Wireless Network
Project.
artificial limitations which really only make it good for use with serial
flash devices. One of the more annoying limitations is a restriction that
it can only transfer 8 bytes at a time. (4 command/address, plus 4 data.)
The driver includes design to work around those limitations, but these
changes are only appropriate for serial flash devices.
This driver is designed to run in interrupt driven mode, but due to lack
of adequate documentation, we run it in polled mode.
A subsequent commit will introduce the MI M25P flash driver, which has been
tested and is known to function somewhat reasonably..
The main changes needed are:
1) pass address and IRQ information from aubus (auspi uses interrupts)
2) all Au1550 PSC protocols have the same status and register bits
for enable, so clean that up (clock registers could be different)
3) improve timeout logic on enable (a fixed delay isn't good enough)
4) make aupsc_print return QUIET, as it is annoying to see messages
for unconfigured protocols. This whole mechanism should be re-
engineered, to either use indirect configuration or provide more
detailed board-driven configuration. A comment to that effect is
placed in the source.
This is shown to work on DBAU1550.
assigned to request 0. With this change, ethernet interrupts are assigned
to req1, seperately from req0. This potentially gives better performance
by shortening the list of handlers walked somewhat.
the Meraki web site at http://www.meraki.net/ ) This includes changes
to the AR5312 to make it more conducive to sharing code with the AR5315,
and also includes improved early console support.
All devices including ethernet and wlan interfaces on the Meraki Mini are
functional with this port, _except_ SPI flash, which will be introduced
later.
This port was funded by the Champaign-Urbana Communit Wireless Network
Project (CUWiN).
echos this "non-error" message (not even tulip.c). Included is an
explanatory message stating that these counters should probably all be
converted to evcnt counters.
useful. The functions delay, cpu_initclocks, and setstatclcokrate have been
renamed to mips3_delay, mips3_initclocks, and mips3_setstatclockrate.
We provide weak aliases for the original names, so machdep code doesn't have
to provide wrapper routines. (Giving good performance.)
I've moved mips3_clockintr, mips3_initclocks, and mips3_setstatclockrate to
their own mips3_clockintr file, because some ports may not be able to use
these, and its senseless to carry that baggage.
tsutsui