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.
for cache maintenance operations, but ensure that all prior writes have
reached memory when doing a PREWRITE sync.
Submitted by: Michal Meloun <meloun@miracle.cz>
I originally overlooked a couple flag bits defined in the fdt binding docs.
One flag suppresses the pad configuration (pullup/pulldown/etc). The other
one requires that the SION (set input on) flag be set in the mux register.
Also, it appears from the data involved that if the input register
address in the config tuple is zero, there is no input configuration. The
old code was writing to register zero, which contains a collection of misc
control bits (having nothing to do with input configuration) that probably
shouldn't get overwritten arbitrarily. The bindings doc doesn't explictly
mention this.
that expose new bugs with HS mode.
When the old code could not do the proper card detection it would boot with
lower defaults (and no HS mode) and this makes some HS cards boots.
Now, with the card always identified as HS capable, the sdhci controller
tries to run the card at HS speeds and makes the boot always fail.
Disable the HS mode for now (which still can be enabled with the tunable)
until it is properly fixed.
MFC with: r273264
Requested by: many
have chosen different (and more traditional) stateless/statuful
NAT64 as translation mechanism. Last non-trivial commits to both
faith(4) and faithd(8) happened more than 12 years ago, so I assume
it is time to drop RFC3142 in FreeBSD.
No objections from: net@
It turns out an alignment of zero can lead to an endless loop in the
vm reservations code, so specifically disallow that. The manpage says
hardware which can do dma at any address should use a value of one, which
hints at the forbiddeness of zero without exactly saying it. Several
other conditions which could lead to insanity in working with the tag are
also checked now.
Every existing call to bus_dma_tag_create() (about 680 of them) was
eyeballed for violations of these things, and two alignment=0 glitches
were fixed. It's possible something was missed, but overall this
shouldn't lead to any arm users suddenly experiencing failures.
unit 0.
It seems that this 'simplification' was copied to all GPIO drivers in tree.
This fix a bug where a GPIO controller could fail to attach its children
(gpioc and gpiobus) if another GPIO driver attach first.
and casuword(9), but do not mix value read and indication of fault.
I know (or remember) enough assembly to handle x86 and powerpc. For
arm, mips and sparc64, implement fueword() and casueword() as wrappers
around fuword() and casuword(), which means that the functions cannot
distinguish between -1 and fault.
On architectures where fueword() and casueword() are native, implement
fuword() and casuword() using fueword() and casuword(), to reduce
assembly code duplication.
Sponsored by: The FreeBSD Foundation
Tested by: pho
MFC after: 2 weeks (ia64 needs treating)
Multipass device attachment was tested on many arm platforms by users and
only success was reported on the arm@ mailing list. This is just the
long-delayed followup of making it the default.
Multipass attachment is necessary when using vendor-supplied FDT data,
because our devices may need to be attached in a different order than they
are described in the FDT data.
used for kernel devices it is used by i2c(8).
This fix the 'error: Device not configured' when i2c(8) tries to reset the
controller, as an example:
# i2c -r
Resetting I2C controller on /dev/iic0: error: Device not configured
For now use conservative settings for default i2c speeds.
MFC after: 1 week
For an unkown reason (at moment), sometimes if_cpsw cannot read from PHY
and fails to attach calling cpsw_detach() which end up in a panic.
Fix it by doing the proper check before detach the miibus and also fix the
leak of few variables.
And to actually make it work, ether_ifattach() has to be moved to the end
of cpsw_attach() to avoid a race where calling ether_ifdetach() before
domain_init() (which will only run later on) would make it crash at
INP_INFO_RLOCK() on in_pcbpurgeif0().
Tested on: BBB (am335x)
MFC after: 1 week
