if the fdt data doesn't provide a gpio pin for reading the write protect
switch and also doesn't contain a "wp-disable" property.
In r311735 the long-bitrotted code in this driver for using the non-
standard fdt "mmchs-wp-gpio-pin" property was replaced with new common
support code for handling write-protect and card-detect gpio pins. The
old code never found a property with that name, and the logic was to
assume that no gpio pin meant that the card was not write protected.
The new common code behaves differently. If there is no fdt data saying
what to do about sensing write protect, the value in the standard SDHCI
PRESENT_STATE register is used. On this hardware, if there is no signal
for write protect muxed into the sd controller then that bit in the
register indicates write protect.
The real problem here is the fdt data, which should contain "wp-disable"
properties for eMMC and micro-sd slots where write protect is not even
an option in the hardware, but we are not in control of that data, it
comes from linux. So we have to make the same flawed assumption in our
driver that the corresponding linux driver has: no info means no protect.
Reported by: several users on the arm@ list
Pointy hat: me, for not testing enough before committing r311735
This enables the PHY circuitry for UTMI+ level 2 and 3, and sets the
flag to tell the ehci code that the root hub has a transaction translator
in it. For imx6 we can use the standard ehci_get_port_speed_portsc()
function to find out what speed device is connected to the port.
On arm64 use atomics. Then, both arm and arm64 do not need a critical
section around update. Replace all cpus loop by CPU_FOREACH().
This brings arm and arm64 counter(9) implementation closer to current
amd64, but being more RISC-y, arm* version cannot avoid atomics.
Reported by: Alexandre Martins <alexandre.martins@stormshield.eu>
Reviewed by: andrew
Tested by: Alexandre Martins, andrew
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
identify_arm_cpu() in sys/arm/arm/identcpu-v4.c incorrectly uses a
u_int8_t variable to store the result of cpu_get_control().
It should really use a u_int variable, the same way as done for cpu_ident()
in the same function, as both cpuid and control registers are 32-bit..
This issue causes users of identcpu-v4 to incorrectly report things such as
icache status (bit 12 in cpu control register) and basically anything
defined in bits above bit 7 :-)
Reviewed by: manu
Sponsored by: Smartcom - Bulgaria AD
Differential Revision: https://reviews.freebsd.org/D9460
The types are for the byte offset and page index in vm object. They
are similar to off_t, which is defined as 64bit MI integer. Using MI
definitions will allow to provide consistent MD values of vm
object-related maximum sizes.
Reviewed by: alc
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
- Use new option SMP_ON_UP instead of (mis)using specific CPU type.
By this, any SMP kernel can be compiled with SMP_ON_UP support.
- Enable runtime detection of CPU multiprocessor extensions only
if SMP_ON_UP option is used. In other cases (pure SMP or UP),
statically compile only required variant.
- Don't leak multiprocessor instructions to UP kernel.
- Correctly handle data cache write back to point of unification.
DCCMVAU is supported on all armv7 cpus.
- For SMP_ON_UP kernels, detect proper TTB flags on runtime.
Differential Revision: https://reviews.freebsd.org/D9133
Historically AM335x LCDC driver used non-standard "hdmi" property to
refer to HDMI framer. There is no such thing in upstream DTS, so to
handle both cases fallback to bindings described in
bindings/media/video-interfaces.txt in Linux documentation.
We still make some assumptions that are not universally true: we
assume that if remote endpoint is available it's going to be HDMI
framer. Which is true for AM335x-based devices currently supported
but may be not true for some custom hardware.
MFC after: 1 week
register, in addition to configuring it as input with the pinmux driver.
There was a control register bit commented as "no desc in datasheet". A
later revision of the manual reveals the bit to be an input/output control
for the timer pin. In addition to configuring capture or pulse mode, you
apparently have to separately configure the pin direction in the timer
control register.
Before this change, the timer block was apparently driving a signal onto a
pad configured by pinmux as input. Capture mode still accidentally worked
for me during testing because I was using a very strong signal source that
just out-muscled the weaker drive from the misconfigured pin.
Commit r312747 ("Setup decoding windows for ARMADA38X") resulted
in build failing for Marvell platforms, which don't have AHCI controller.
This patch provides a fix by adding dummy functions for such cases.
On the occasion rename register dump routine to decode_win_ahci_dump,
in order to avoid confusion.
Submitted by: Marcin Wojtas <mw@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
- Replace pcpu_find(curcpu) with get_pcpu(), which is much
more direct.
- Remove armv4 pcpu fields which I added in r286296 but never
needed to use.
- armv6 pc_qmap_addr was leftover from the old armv6 pmap
implementation. Rename it and put it to use in the new one.
Noted by: skra
Reviewed by: skra
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9312
This file provides support for AHCI mode on Armada38x
and adds new optional AHCI device to arm/mv/files.mv.
Submitted by: Konrad Adamczyk <ka@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Reviewed by: zbb
Differential revision: https://reviews.freebsd.org/D9222
It is necesarry to open memory windows on internal bus for
AHCI driver to work correctly.
Submitted by: Konrad Adamczyk <ka@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Reviewed by: zbb
Differential revision: https://reviews.freebsd.org/D9220
Configure decoding windows only for devices with
enabled nodes in FDT.
Submitted by: Konrad Adamczyk <ka@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Reviewed by: zbb
Differential revision: https://reviews.freebsd.org/D9219
* Currently supports only Armada38X family but other Marvell SoC's
can be added if needed.
* Provides temperature is C deg.
* To print the temperature one can use:
sysctl dev.armada_thermal.0.temperature
Submitted by: Zbigniew Bodek <zbb@semihalf.com>
Obtained from: Semihalf
Sponsored by: Stormshield
Differential revision: https://reviews.freebsd.org/D9217
mappings for armv6 pmap zero and copy operations to the MD PCPU region.
Change sysmap initialization to only allocate KVA pages for CPUs that
are actually present.
While here, collapse CMAP3 into CMAP2 (their use was mutually exclusive
anyway) and "recover" some space in PCPU padding that has always been
available due to 64-byte cacheline padding.
Reviewed by: skra
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D9172
descriptor state will not change anymore). This seems to eliminate the
race where we can miss a stalled queue under high load.
While here remove the unnecessary curly brackets.
Reported by: Konstantin Kormashev <konstantin@netgate.com>
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
- Pad small packets to 60 bytes and not 64 (exclude the CRC bytes);
- Pad the packet using m_append(9), if the packet has enough space for
padding, which is usually true, it will not be necessary append a newly
allocated mbuf to the chain.
Suggested by: yongari
MFC after: 3 days
Sponsored by: Rubicon Communications, LLC (Netgate)
disabled (Hi netmap!).
Only remove the CRC bytes from packets when the hardware tell us to do so.
Fixes the 'discard frame w/o leading ethernet header' issues.
Sponsored by: Rubicon Communications, LLC (Netgate)
The Zedboard has a hardware bug where initialization of the USB PHY
occasionally fails on boot-up. Fix regression in -CURRENT when
kernel panics on such occasion. 11-RELEASE branch works fine
PR: 215862
Submitted by: Thomas Skibo <thoma555-bsd@yahoo.com>
it into pmap-v4.h where they are used. Other than those few lines of
support for different MMU types, nothing in cpuconf.h has been used in our
code for quite a while.
The file existed to set up a variety of symbols to describe the
architecture. Over the past few years we have converted all of our source
to use the new architecture symbols standardized by ARM Inc, and predefined
by both clang and gcc.
PR: 216104
Replace archaic "busses" with modern form "buses."
Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "busses" in code as identifiers
No functional change.
http://grammarist.com/spelling/buses-busses/
PR: 216099
Reported by: bltsrc at mail.ru
Sponsored by: Dell EMC Isilon
Add basic support for A33/R16 that is enough to boot a kernel.
This adds the platform code, padconf data and the new clocks strings.
MFC after: 2 weeks
QEMU does not implement hardware debug registers so when
dbg_monitor_is_enabled is called kernel receives "invalid instruction"
exception. QEMU implements only DIDR register and on read returns all
zeroes to indicate that it doesn't support other registers. Real
hardware has Version bits set.
MFC after: 1 week
