the main processing queue, clear the NAK counter for any associated
BULK or CONTROL transfers and poll the endpoint(s) for 1 millisecond
at 125us rate interval, before going into slow, 10ms, NAK polling mode
again. This has the effect that typical ping-ping protocols respond
quicker when initiated from the USB host.
MFC after: 2 weeks
GENERIC64 for PowerPC to use vt with it.
Much to my chagrin, PS3 support seems to have bitrotted somewhat since the
last time I tried it. ehci panics on attach and interrupt handling seems
to be faulty. This should be fixed soon...
On modern ARM SoCs the L2 cache controller sits between the CPU and the
AXI bus, and most on-chip memory-mapped devices are on the AXI bus. We
map the device registers using the 'Device' memory attribute, which means
the memory is not cached, but writes to it are buffered. Ensuring that a
write has made it all the way to a device may require that the L2
controller take some action.
There is currently only one implementation of the new function, for the
PL310 cache controller. It invokes a function that the controller
manual calls "cache sync" but it actually has nothing to do with cache at
all, it triggers a drain of all pending store buffer writes and it blocks
until they complete.
The sheeva and xscale L2 controllers (which predate the concept of Device
memory) don't seem to have a corresponding function. It appears that the
standard armv5 drain_writebuf function includes draining all the way
through the L2 controller.
The last obstacle to switching PowerPC entirely to vt is that the Playstation 3
framebuffer driver needs to be ported over. This only applies for powerpc64,
however.
on my G4 iBook by more than half. Still 10% slower than syscons, but that's
much better than a factor of 2.
The slowness had to do with pathological write performance on 8-bit
framebuffers, which are almost universally used on Open Firmware systems.
Writing 1 byte at a time, potentially nonconsecutively, resulted in many
extra PCI write cycles. This patch, in the common case where it's writing
one or several characters in an 8x8 font, gangs the writes together into
a set of 32-bit writes. This is a port of r143830 to vt(4).
The EFI framebuffer is also extremely slow, probably for the same reason,
and the same patch will likely help there.
On armv4 these are defined as synonyms right now, but it's a bit ambiguous
what NOCACHE means (is buffering/write-combining also enabled or not?); this
is a first step towards replacing PTE_NOCACHE with a less ambiguous name.
need COW and is writeable (i.e. becoming writeable due to the
mprotect(2) operation), do not create a new backing object for the
entry. The caller of the function is vm_map_protect(), the call is
made to ensure that wired entry has all pages resident and wired in
the top level object and to enable the write. We might need to copy
read-only page from some backing objects into the top object or remap
the page with the write allowed.
This fixes the issue with mishandling of the swap accounting when
read-only wired mapping is upgraded to write-enabled after fork. The
previous code path did not accounted the new object, but it creation
is redundand anyway and the change provides an optimization for the
non-common situation.
Reported by: markj
Suggested and reviewed by: alc (previous version)
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
o KMODDEPS warning is 15 years stale. Remove it.
o MK_CTF will always be defined now, so no need to test to see if it
is defined.
o no need to define MK_FORMAT_EXTENTIONS if undefined anymore.
page queues for the backing objects. The queues are huge and clutter
the display, when mostly the map entries and its backing storage is
interesting.
The page queues can be seen with ddb 'show object' command.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
the GPIO pin is connected to a push button (or other devices).
Instead keep the boot loader settings.
Calling ar71xx_gpio_pin_configure() with DEFAULT_CAPS was probably a
mistake and was causing all the pins to be set as outputs.
at that time, but AFAIK it is only used on routerboards.
Enabling GPIO_FUNC_SPI_CS[1|2]_EN will claim the use of gpio pins 0 and 1
respectivelly for use as SPI CS pins.
When really needed, this can still be enabled on kernel hints using the
function_set and function_clear knobs.
This driver supports the low and high precision models (9 and 11 bits) and
it will auto-detect the both variants.
The driver expose the temperature registers (actual temperature, shutdown
and hysteresys temperature) and also the configuration register.
It was tested on FDT systems: RPi, BBB and on non-FDT systems: AR71xx, with
both, hardware i2c controllers (when available) and gpioiic(4).
This provides a simple and cheap way for verifying the i2c bus on embedded
systems.
- For non-periodic traffic we only need to wait two SOFs before
disabling the channel.
- Make sure we release the TX FIFO tracking level after the host
channel is disabled.
- Make sure the host channel state gets reset/disabled initially.
- Two minor code style changes.
MFC after: 2 weeks
Under enough load, the swi's can actually be preempted and migrated
to other currently free cores. When doing RSS experiments, this lead
to the per-CPU TCP timers not lining up any more with the RX CPU said
flows were ending up on, leading to increased lock contention.
Since there was a little pushback on flipping them on by default,
I've left the default at "don't pin."
The other less obvious problem here is that the default swi
is also the same as the destination swi for CPU #0. So if one
pins the swi on CPU #0, there's no default floating swi.
A nice future project would be to create a separate swi for
the "default" floating swi, as well as per-CPU swis that are
(optionally) pinned.
Tested:
* parallel TCP tests (2 x 1g unfortunately for now);
CPU: Intel(R) Xeon(R) CPU E5-2650
Note:
This is based on some initial investigation into RSS/TCP stack lock
contention on FreeBSD-HEAD whilst at Netflix in January 2014.
- Rework how we allocate and free USB host channels, so that we only
allocate a channel if there is a real packet going out on the USB
cable.
- Use BULK type for control data and status, due to instabilities in
the HW it appears.
- Split FIFO TX levels into one for the periodic FIFO and one for the
non-periodic FIFO.
- Use correct HFNUM mask when scheduling host transactions. The HFNUM
register does not count the full 16-bit range.
- Correct START/COMPLETION slot for TT transactions. For INTERRUPT and
ISOCHRONOUS type transactions the hardware always respects the ODDFRM
bit, which means we need to allocate multiple host channels when
processing such endpoints, to not miss any so-called complete split
opportunities.
- When doing ISOCHRONOUS OUT transfers through a TT send all data
payload in a single ALL-burst. This deacreases the likelyhood for
isochronous data underruns.
- Fixed unbalanced unlock in case of "dwc_otg_init_fifo()" failure.
- Increase interrupt priority.
MFC after: 2 weeks
have implemented the PIM_NOSCAN rescan functionality will have it
enabled.
This is a no-op for head.
Reviewed by: slm
Sponsored by: Spectra Logic Corporation
MFC after: 3 days
TLR is necessary for reliable communication with SAS tape drives.
This was broken by change 246713 in the mps(4) driver. It changed the
cm_data field for SCSI I/O requests to point to the CCB instead of the data
buffer. So, instead, look at the CCB's data pointer to determine whether
or not we're talking to a tape drive.
Also, take the residual into account to make sure that we don't go off the
end of the request.
MFC after: 3 days
Sponsored by: Spectra Logic Corporation
Remove some other ifdefs that came in with a copy/paste that mean basically
"if this processor supports multicore stuff", because if you're starting up
an AP core... it does.
