Add missing set frame data pointer call. The
function call was missed when zero copy was
introduced in UMASS.
Reported by: WATANABE Kazuhiro.
Submitted by: Hans Petter Selasky
Remove dependancy towards the USB config thread in
the USB serial core. Use USB process msignalling
instead. Saves a little memory and hopefully makes
the code more understandable.
Submitted by: Hans Petter Selasky
Remove "vbus_interrupt" method from bus methods and use
a global function instead for the various drivers using it.
The reason for the removal is to simplify the code.
Submitted by: Hans Petter Selasky
Reduce the number of callback processes to 4 per
USB controller. There are two rough categories:
1) Giant locked USB transfers.
2) Non-Giant locked USB transfers.
On a real system with many USB devices plugged in the
number of processes reported by "ps auxw | grep USBPROC"
was reduced from 40 to 18.
Submitted by: Hans Petter Selasky
This change is about removing three fields from "struct usb2_xfer"
which can be reached from "struct usb2_xfer_root" instead and cleaning
up the code after this change. The fields are "xfer->udev",
"xfer->xfer_mtx" and "xfer->usb2_sc". In this process the following
changes were also made:
Rename "usb2_root" to "xroot" which is short for "xfer root".
Rename "priv_mtx" to "xfer_mtx" in USB core.
The USB_XFER_LOCK and USB_XFER_UNLOCK macros should only be used in
the USB core due to dependency towards "xroot". Substitute macros
for the real lock in two USB device drivers.
Submitted by: Hans Petter Selasky
Factor out roothub process into the USB bus structure for
all USB controller drivers. Essentially I am trying to
save some processes on the root HUB and get away
from the config thread pradigm. There will be a follow up
commit where the root HUB control and interrupt callback
will be moved over to run from the roothub process.
Total win: 3 processes become 1 for every USB controller.
Submitted by: Hans Petter Selasky
Usability improvement. Make sure that setting
power mode ON resurrects the device if powered OFF.
Reported by: Alexander Best.
Submitted by: Hans Petter Selasky
Initial version of ATMEGA USB device controller
driver. Has not been tested on real hardware yet.
The driver is based upon the AT91DCI driver.
Submitted by: Hans Petter Selasky
- Callwheels traced via KTR_CALLOUT. Each CPU is assigned a callwheel
source. The events on this source are the execution of individual callout
routines. Each routine shows up as a green rectangle while it is executed
and the event details include the function pointer and argument.
- Locks traced via KTR_LOCK. Currently, each lock name is assigned an event
source (since the existing KTR_LOCK traces only include lock names and
not pointers). This does mean that if multiple locks of the same name are
manipulated, the source line for that name may be confusing. However, for
many cases this can be useful. Locks are blue when they are held and
purple when contested. The contention support is a bit weak due to
limitations in the rw_rlock() and mtx_lock_spin() logging messages
currently. I also have not added support for contention on lockmgr,
sx, or rmlocks yet. What is there now can be profitably used to examine
activity on Giant however.
- Expand the width of the event source names column a bit to allow for some
of the longer names of these new source types.
(threads, CPU load counters, etc.). Each source is tagged with a group
and an order similar to the SYSINIT SI_SUB_* and SI_ORDER_*. After
the file is parsed, all the sources are then sorted. Currently, the only
affects of this are that the CPU loads are now sorted by CPU ID (so
CPU 0 is always first). However, this makes it easier to add new types
of event sources in the future and have them all clustered together
instead of intertwined with threads.
- Python lists perform insertions at the tail much faster than insertions
at the head. For a trace that had a lot of events for a single event
source, the constant insertions of new events to the head of the
per-source event list caused a noticable slow down. To compensate,
append new events to the end of the list during parsing and then
reverse the list prior to drawing.
- Somewhere in the tkinter internals the coordinates of a canvas are
stored in a signed 32-bit integer. As a result, if an the box for
an event spans 2^31, it would actually end up having a negative
X offset at one end. The result was a single box that covered the
entire event source. Kris worked around this for some traces by
bumping up the initial ticks/pixel ratio from 1 to 10. However, a
divisor of 10 can still be too small for large tracefiles (e.g.
with 4 million entries). Instead of hardcoding the initial scaling
ratio, calculate it from the time span of the trace file.
- Add support for using the mouse wheel to scroll the graph window
up and down.
o Eliminate tlb0[] (a s/w copy of TLB0)
- The table contents cannot be maintained reliably in multiple MMU
environments, where asynchronous events (invalidations from other cores)
can change our local TLB0 contents underneath.
- Simplify and optimize TLB flushing: system wide invalidations are
performed using tlbivax instruction (propagates to other cores), for
local MMU invalidations a new optimized routine (assembly) is introduced.
o Improve and simplify TID allocation and management.
- Let each core keep track of its TID allocations.
- Simplify TID recycling, eliminate dead code.
- Drop the now unused powerpc/booke/support.S file.
o Improve page tables management logic.
o Simplify TLB1 manipulation routines.
o Other improvements and polishing.
Obtained from: Freescale, Semihalf
- add a reference to the config(5) manpage;
- hopefully clarify the format of the 'env FILENAME' directive.
I am putting these notes in sys/${arch}/conf/GENERIC and not
in sys/conf/NOTES because:
1. i386/GENERIC already had reference to a similar option (hints..)
and to documentation (handbook)
2. GENERIC is what most users look at when they have to modify or
create a new kernel config, so having the suggestion there is
more effective.
I am only touching i386 and amd64 because the other GENERIC files
are already out of sync, and I am not sure what is the overall plan.
MFC after: 3 days
down will cause a fault. Check the phy power state before possibly
reading from the bb, this can happen as ar5212Reset intentionally
calls ar5212GetRfgain before bringing the bb out of reset (but we
do it here and not in the caller to guard against other possible uses).
