description was eaten by the dog (or an editor crash or something).
Add variable-frequency support to the arm mpcore eventtimer driver.
This allows a platform's early init code to tell the mpcore driver that the
clock frequency can vary. That causes the mpcore driver to register an
eventtimer, but not a timecounter. The platform has to provide a time
counter using some other fixed-frequency clock, but can still use the
per-cpu goodness of the mpcore hardware for event timers.
When the platform support code does something to change the frequency of
the CPU clocks (power saving, thermal management) it must tell the mpcore
driver code about it using arm_tmr_change_frequency().
register values, then restart the timer. This prevents a situation where
an old event fires just as we're about to load a new value into the timer,
when the start routine is called to change the time of the current event.
Also re-nest the parens properly for casting the result of converting
time and frequency to a count. This doesn't actually change the result of
the calcs, but will some day prevent a loss-of-precision warning on the
assignment, if that warning gets enabled.
few of them also build kern_clocksource.c. That strikes me as insane, but
maybe there's a good reason for it. Until I figure that out, un-break
the build by not referencing functions in kern_clocksource if NO_EVENTTIMERS
is defined.
4248 dtrace(1M) should never create DOF with empty probes section
4249 Only probes from the first DTrace object file will be included
Illumos Revision: 4a20ab41aadcb81c53e72fc65886e964e9add59
Reference:
https://www.illumos.org/issues/4248https://www.illumos.org/issues/4249
Obtained from: Illumos
MFC after: 1 month
default wMaxPacketSize (64 or 512 bytes). This actually helps older FTDI
devices (which were USB 1/full speed) more than the new H-series high
speed, but even for the new chips it helps cut the number of interrupts
when doing very high speed (3-12mbaud).
This avoids extra locking in icl_pdu_queue(); the upper layer needs to call
it while holding its own lock anyway, to avoid sending PDUs out of order.
Sponsored by: The FreeBSD Foundation
PCIe Alternate RID Interpretation (ARI) is an optional feature that
allows devices to have up to 256 different functions. It is
implemented by always setting the PCI slot number to 0 and
re-purposing the 5 bits used to encode the slot number to instead
contain the function number. Combined with the original 3 bits
allocated for the function number, this allows for 256 functions.
This is enabled by default, but it's expected to be a no-op on currently
supported hardware. It's a prerequisite for supporting PCI SR-IOV, and
I want the ARI support to go in early to help shake out any bugs in it.
ARI can be disabled by setting the tunable hw.pci.enable_ari=0.
Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.
Recent FDTI chips have the ability to operate at up to 12mbps. The newer
chips with faster clocks have the same usb vendor/product IDs as the older
chips; the bcdDevice field must be used to detect the newer versions. This
change includes a new function to do that instead of using just the IDs from
the vendor/product table.
The code to choose the baud clock divisor is completely rewritten. In
addition to supporting the new higher clock rates, the rewrite fixes a
longstanding bug in the old code which put the high bits of the fractional
part of the divisor into the wrong place in the wIndex field. That bug
was mostly harmless -- it accidentally didn't affect standard baud rates
and would only show up when using relatively fast non-standard rates.
Under the hood the VT-d spec is really implemented in terms of
PCI RIDs instead of bus/slot/function, even though the spec makes
pains to convert back to bus/slot/function in examples. However
working with bus/slot/function is not correct when PCI ARI is
in use, so convert to using RIDs in most cases. bus/slot/function
will only be used when reporting errors to a user.
Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.
My PCI RID changes somehow got intermixed with my PCI ARI patch when I
committed it. I may have accidentally applied a patch to a non-clean
working tree. Revert everything while I figure out what went wrong.
Pointy hat to: rstone
Under the hood the VT-d spec is really implemented in terms of
PCI RIDs instead of bus/slot/function, even though the spec makes
pains to convert back to bus/slot/function in examples. However
working with bus/slot/function is not correct when PCI ARI is
in use, so convert to using RIDs in most cases. bus/slot/function
will only be used when reporting errors to a user.
Reviewed by: kib
Sponsored by: Sandvine Inc.
generate dwarf4 by default as well, so always force dwarf2 when
generating debugging data. It is harmless on older versions of both
clang and gcc, but required on newer ones.
them for actual target errors. They can be enabled back by setting
kern.cam.ctl.verbose=1, or booting with bootverbose.
Sponsored by: The FreeBSD Foundation
out 32 is not enough to support a full sized TSO packet.
While I'm here fix a long standing bug introduced in r169632 in
bce(4) where it didn't include L2 header length of TSO packet in
the maximum DMA segment size calculation.
In collaboration with: rmacklem
MFC after: 2 weeks
Support covers device drivers for:
- Interrupt Combiner
- gpio/pad, External Interrupts Controller (pad)
- I2C Interface
- Chrome Embedded Controller
- Chrome Keyboard
Also:
- Use new gpio dev class in EHCI driver
- Expand device tree information
