TI OMAP controllers which will return the reset-in-progress bit as zero if
you read the status register too fast after setting the reset bit.
The zero is apparently from a stale snapshot of the internal state presented
in the interface register, and leads to a false indication that the reset
is complete when it either hasn't started yet or is in-progress. The
workaround is to first loop until the bit is seen as asserted, then do the
normal loop waiting to see it de-asserted.
Submitted by: Michal Meloun <meloun@miracle.cz>
can't do a timeout bigger than 15 seconds. The code wasn't checking for
this and because bitmasking was involved the requested timeout was
basically adjusted modulo-16. That led to things like a 128 second
timeout actually being a 9 second timeout, which accidentally worked fine
until watchdogd was changed to only pet the dog once every 10 seconds.
o Move similar block/networking methods to common file
o Follow r275640 and correct MMIO registers width
o Pass value to MMIO platform_note method.
Sponsored by: DARPA, AFRL
far away from a ldr psuedo instruction. With this clang will place the
literal value here where it's close enough to be loaded.
MFC after: 1 week
Sponsored by: ABT Systems Ltd
If this feels like deja vu... the last time this was fixed in this file
only ARM_MMU_V6 was fixed, this time it's ARM_ARCH_V6 (and this time I
searched for other occurrances of pj4b in here).
the first cacheline if the buffer start address is not on a cacheline
boundary. Normally a buffer which is not cacheline-aligned is bounced,
but a special rule applies for mbufs, which are always misaligned due to
the header. We know the cpu will not write to the header while dma is in
progress (so we've been told anyway), but it may have written to the
header shortly before starting a read, so we need to flush that write out
to memory before invalidating the whole buffer.
In collaboration with Mical Meloun and Svata Kraus.
It is automatically set when -fPIC is passed to the compiler.
Reviewed by: dim, kib
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D1179
For OMAP4, the old values for 1MHz gave a bus frequency of about 890KHz.
The new numbers hit 1MHz exactly.
For AM335x the prescaler values are adjusted to give a 24MHz clock for
all 3 standard speeds, as the manual recommends (as near as we can tell,
there are errors and typos apparent in the document). Also, 1MHz speed
is added, and has been tested successfully on a BeagleboneWhite board.
PR: 195009
The current support for controlling i2c bus speed is an inconsistant mess.
There are 4 symbolic speed values defined, UNKNOWN, SLOW, FAST, FASTEST.
It seems to be universally assumed that SLOW means the standard 100KHz
rate from the original spec. Nothing ever calls iicbus_reset() with a
speed of FAST, although some drivers would treat it as the 400KHz standard
speed. Mostly iicbus_reset() is called with the speed set to UNKNOWN or
FASTEST, and there's really no telling what any individual driver will do
with those.
The speed of an i2c bus is limited by the speed of the slowest device on
the bus. This means that generally the bus speed needs to be configured
based on the board/system and the components within it. Historically for
i2c we've configured with device hints. Newer systems use FDT data and it
documents a clock-frequency property for i2c busses. Hobbyists and
developers are likely to want on the fly changes. These changes provide
all 3 methods, but do not require any existing drivers to change to use
the new facilities.
This adds an iicbus method, iicbus_get_frequency(dev, speed) that gets the
frequency for the requested symbolic speed. If the symbolic speed is SLOW
or if there is no speed configured for the bus, the returned value is
100KHz, always. Otherwise, if bus speed is configured by hints, fdt,
tunable, or sysctl, that speed is returned. It also adds a helper
function, iicbus_init_frequency() that any bus driver subclassed from
iicbus can initialize the frequency from some other source of info.
Initial driver implementations are provided for Freescale and TI.
Differential Revision: https://reviews.freebsd.org/D1174
PR: 195009
We used to invalidate the cache for PREREAD alone, or writeback+invalidate
for PREREAD with PREWRITE, then treat POSTREAD as a no-op. Prefetching on
modern systems can lead to parts of a DMA buffer getting pulled into the
caches while DMA is in progress (due to access of "nearby" data), so it's
mandatory to invalidate during the POSTREAD sync even if a PREREAD
invalidate also happened.
In the PREREAD case the invalidate is done to ensure that there are no
dirty cache lines that might get automatically evicted during the DMA,
corrupting the buffer. In a PREREAD+PREWRITE case the writeback which is
required for PREWRITE handling is suffficient to avoid corruption caused
by eviction and no invalidate need be done until POSTREAD time.
Submitted by: Michal Meloun <meloun@miracle.cz>
The PREWRITE handling does a writeback of any dirty cachelines, so there's
no danger of an eviction during the DMA corrupting the buffer. There will
be an invalidate done during POSTREAD, so doing it before the read too is
wasted time.
