MFC r345757:

Improve debugging options in bcm2835_sdhci.c

Similar to bcm2835_sdhost.c add a TUNABLE and SYSCTL to selectively
turn on debugging printfs if debugging is turned on at compile time.

MFC: r342634 (partial)

o Don't allocate resources for SDMA in sdhci(4) if the controller or the
front-end doesn't support SDMA or the latter implements a platform-
specific transfer method instead. While at it, factor out allocation
and freeing of SDMA resources to sdhci_dma_{alloc,free}() in order to
keep the code more readable when adding support for ADMA variants.

o Base the size of the SDMA bounce buffer on MAXPHYS up to the maximum
of 512 KiB instead of using a fixed 4-KiB-buffer. With the default
MAXPHYS of 128 KiB and depending on the controller and medium, this
reduces the number of SDHCI interrupts by a factor of ~16 to ~32 on
sequential reads while an increase of throughput of up to ~84 % was
seen.

Front-ends for broken controllers that only support an SDMA buffer
boundary of a specific size may set SDHCI_QUIRK_BROKEN_SDMA_BOUNDARY
and supply a size via struct sdhci_slot. According to Linux, only -
unsupported in stable/11 anyway - Qualcomm MSM-type SDHCI controllers
are affected by this, though.

Requested by: Shreyank Amartya (unconditional bump to 512 KiB)

o Introduce a SDHCI_DEPEND macro for specifying the dependency of the
front-end modules on the sdhci(4) one and bump the module version
of sdhci(4) to 2 via an also newly introduced SDHCI_VERSION in order
to ensure that all components are in sync WRT struct sdhci_slot.

o In sdhci(4):
- Make pointers const were applicable, and
- replace a few device_printf(9) calls with slot_printf() for
consistency.

Revert r330897:

This was intended to be a non-functional change. It wasn't. The commit
message was thus wrong. In addition it broke arm, and merged crypto
related code.

Revert with prejudice.

This revert skips files touched in r316370 since that commit was since
MFCed. This revert also skips files that require $FreeBSD$ property
changes.

Thank you to those who helped me get out of this mess including but not
limited to gonzo, kevans, rgrimes.

Requested by: gjb (re)

Partial merge of the SPDX changes

These changes are incomplete but are making it difficult
to determine what other changes can/should be merged.

No objections from: pfg

MFC: r312939, r313250, r314811 (partial), r314887 (partial), r315760,
r315845, 315430, r317981, r315466

o Fix some overly long lines, whitespace and other bugs according to
style(9) as well as spelling etc. in mmc(4), mmcsd(4) and sdhci(4).

o In the mmc(4) bridges and sdhci(4) (bus) front-ends:
- Remove redundant assignments of the default bus_generic_print_child
device method,
- use DEVMETHOD_END,
- use NULL instead of 0 for pointers.

o Trim/adjust includes.

o Add and use a MMC_DECLARE_BRIDGE macro for declaring mmc(4) bridges
as kernel drivers and their dependency onto mmc(4).

o Add support for eMMC "partitions". Besides the user data area, i. e.
the default partition, eMMC v4.41 and later devices can additionally
provide up to:
1 enhanced user data area partition
2 boot partitions
1 RPMB (Replay Protected Memory Block) partition
4 general purpose partitions (optionally with a enhanced or extended
attribute)

Besides simply subdividing eMMC devices, some Intel NUCs having UEFI
code in the boot partitions etc., another use case for the partition
support is the activation of pseudo-SLC mode, which manufacturers of
eMMC chips typically associate with the enhanced user data area and/
or the enhanced attribute of general purpose partitions.

CAVEAT EMPTOR: Partitioning eMMC devices is a one-time operation.

o Now that properly issuing CMD6 is crucial (so data isn't written to
the wrong partition for example), make a step into the direction of
correctly handling the timeout for these commands in the MMC layer.
Also, do a SEND_STATUS when CMD6 is invoked with an R1B response as
recommended by relevant specifications.

o Add an IOCTL interface to mmcsd(4); this is sufficiently compatible
with Linux so that the GNU mmc-utils can be ported to and used with
FreeBSD (note that due to the remaining deficiencies outlined above
SANITIZE operations issued by/with `mmc` currently most likely will
fail). These latter have been added to ports as sysutils/mmc-utils.
Among others, the `mmc` tool of mmc-utils allows for partitioning
eMMC devices (tested working).

o For devices following the eMMC specification v4.41 or later, year 0
is 2013 rather than 1997; so correct this for assembling the device
ID string properly.

o Let mmcsd.ko depend on mmc.ko. Additionally, bump MMC_VERSION as at
least for some of the above a matching pair is required.

o In the ACPI front-end of sdhci(4) describe the Intel eMMC and SDXC
controllers as such in order to match the PCI one.
Additionally, in the entry for the 80860F14 SDXC controller remove
the eMMC-only SDHCI_QUIRK_INTEL_POWER_UP_RESET.

MFC r307239:

Fix BCM283x(Raspberry Pi) SDHCI driver for ARM64 build

- Revert BUS_SPACE_PHYSADDR back to rman_get_start. BUS_SPACE_PHYSADDR was
introduced in 2013 as temporary wrapper until proper solution appears.
It's ARM only and since we need this file for ARM64 build and no proper
API has been introduced - just revert the change and make sure it's
going to appear when people grep for BUS_SPACE_PHYSADDR in sources.

- Fix printf format for size_t variables

MFC r307067, r307068, r307087, r307088, r307089,
r307091, r307092, r307093, r307095, r307098,
r307115:

r307067:
Make intc driver compatible with upstream DTS

- Fix compatibility strings
- Properly decode upstream's two-cell interrupt specs. Our home-made dts
does not have two-cell interrupts so no need to preserve backward
compatibility

r307068:
Make Rapsberry Pi watchdog driver compatible with upstream DTS

- Fix compatibility strings
- Compensate the difference in base address for our custom DTS and
upstream one (for backward compatibility)

r307087:
Make sure intc is attached before interrupt consumers

If pass order is not specified devices are attached in the order they are
defined in dts. Some interrupt consumers may be defined before intc. Also
make sure intc interrupt-parent local_intc is attached before intc itself.

r307088:
Add compatible strings used in upstream dts files

r307089:
Make framebuffer driver compatible with upstream DT

- Add compatibility string
- Add simplebus as possible parent bus

r307091:
Add compatibility string from upstream DT

r307092:
Make BCM2835 GPIO driver compatible with upstream DT

- Add compatibility string
- Make reserverd and read-only properties optional

r307093:
Make BCM283x USB driver compatible with upstream DT

- Make resource allocation logic depend on compatibility string
to check what format of DTS node should be used - FreeBSD's or upstream

r307095:
Make VCHI driver compatible with upstream DT

- Add compatibility string
- Compensate difference in base address between our custom DTB and upstream one

r307098:
Make BCM28x USB driver compatible with upstream device tree

This should have been committed in r307093: resource allocation depends
on source of the device tree. upstream dts has extra interrupt that we can
ignore

r307115:
Fix typo in comment

Spotted by: loos

Copy head@r302406 to stable/11 as part of the 11.0-RELEASE cycle.
Prune svn:mergeinfo from the new branch, as nothing has been merged
here.

Additional commits post-branch will follow.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Fix fallout from r292180 (Dec 2015)... ensure that every driver which has
a DRIVER_MODULE() referencing mmc_driver has a MODULE_DEPEND() on mmc. This
is because the kernel linker only searches for symbols in dependent modules,
so loading sdhci_pci (and other bus-flavors of sdhci) would fail when mmc
was not compiled into the kernel (even if you hand-loaded mmc first).

(Thanks to jilles@ for providing the vital clue about the kernel linker.)

Do not use DMA channels used by GPU.

(1) The channel mask is get from "brcm,dma-channel-mask" property of
dma node, and if not provided, from "broadcom,channels" property.
(2) Consequently, sdhci driver does not allocate any specific channel.
(3) Use CS_RESET bit for initial channel reset.

Differential Revision: https://reviews.freebsd.org/D4303

Move the DRIVER_MODULE() statements that declare mmc(4) to be a child of
the various bridge drivers out of dev/mmc.c and into the bridge drivers.

Requested by: jhb (almost two years ago; better late than never)

Refactor mailbox property API to make it usable for /dev/vcio driver:

- Add bcm2835_mbox_property for generic property request, it accepts
pointer to prepared property chan message and its size, forwards
it to MBOX and copies result back
- Make all bcm2835_mbox_XXX functions that use property channel go
through bcm2835_mbox_property path. Do not accept device_t as
an argument, it's not required: all DMA operatiosn should go
through mbox device, and all API consumers should report errors
on their side.

Remove unused mutex and softc variables.

Enable DMA for sdhci on RPi 2 (BCM2836).

Fetch the SDHCI frequency from videocore (our prefered source) and only if
it fails, fetch the clock-frequency from DTB.

If both methods fail, use the hardcoded default.

Remove a debug #error from the bcm2835 sdhci driver.

Add support for the Raspberry Pi 2. As the chip is based on the bcm2835 in
the Raspberry Pi B we support most of the devices are already supported,
however the base address has changed.

A few items are not working, or missing. The main ones are:
* DMA doesn't work in the sdhci driver.
* Enabling vchiq halts the boot, may be interrupt related.
* There is no U-Boot port yet so the DTB is embedded in the kernel.

The last point will make it difficult to boot FreeBSD, however there is
support for the Raspberry Pi 2 in the U-Boot git repo. As I have not tested
this it is left as an open task to create a port to build.

X-MFC: When the above issues are fixed
Sponsored by: ABT Systems Ltd

Add a helper function to read clock frequencies from videocore and use this
to get the default frequency of the sdhci device.

While here use a u_int to hold the frequency as it may be too large to fit
in a 32-bit signed integer. This is the case when we have a 250MHz clock.

Remove stale comments about the issues with HS mode.

Remove a previous workaround to limit the minimum sdhci frequency that
isn't needed anymore.

Remove some duplicate calls to bus_release_resource() and destroy the mutex
on error cases.

While here remove unnecessary includes.

Save the command-and-flags value into the shadow register when it is written.

This doesn't actually change any behavior, because it just allows a 16-bit
read of the command register to return the correct value, and nothing
actually does a 16-bit read of that register.

Add a new SDHCI quirk, SDHCI_QUIRK_DONT_SET_HISPD_BIT. Apparently some
sdhci controllers, such as the one on a Raspberry Pi, mishandle the signal
timing in high speed signaling mode, but run just fine in standard mode
with the bus running at frequencies between 25-50MHz (which shouldn't work).

This is the solution adopted by U-Boot and other OSes (linux and *BSD)
for the timeouts on Raspberry Pi boards with certain SD cards. Some
research shows that this quirk is also used on a few other boards, so the
fix is a generic quirk instead of being in the RPi-specific driver code.

This change is based on information discovered by Michal Meloun.

Handle dma mappings with more than one segment for rpi sdhci.

The driver inherently does dma in 512 byte chunks, but it's possible that
such a buffer can span two physically discontiguous pages (such as when
a userland program does IO on the raw /dev/mmcsdN devices). Now the driver
can handle a buffer that's split across two pages.

It could in theory handle any number of segments now, but as long as IO is
being done in 512 byte blocks it will never need more than two.

Check for and handle failures of bus_dmamap_load(). The driver currently
requires that each 512 byte IO be in a single contiguous buffer, but if a
buffer crosses a page boundary and the physical pages aren't contiguous
you can get an EFBIG failure (too many segments).

The driver really should handle multiple segment IO, but before adding that
I wanted to make sure that it's handling failure properly while the failure
is easily recreatable.

Store the shadow command/mode register in the softc, not a local static var.

Submitted by: Michal Meloun

Since r273264 the SD card detection on Raspberry Pi is reliably working and
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

Add a workaround needed to fix a bug of Arasan Host Controller where it may
lose the contents of consecutive writes (that happens within two SD card
clock cycles).

This fixes the causes of instability during the SD card detection and
identification on Raspberry Pi (which happens at 400 kHz and so was much
more vulnerable to this issue).

Remove the previous workaround which clearly can't provide the same effect.

MFC after: 1 week
Relnotes: yes

sdhci.h has grown a dependency on sysctl.h, include the latter where needed.

Follow r261352 by updating all drivers which are children of simplebus
to check the status property in their probe routines.

Simplebus used to only instantiate its children whose status="okay"
but that was improper behavior, fixed in r261352. Now that it doesn't
check anymore and probes all its children; the children all have to
do the check because really only the children know how to properly
interpret their status property strings.

Right now all existing drivers only understand "okay" versus something-
that's-not-okay, so they all use the new ofw_bus_status_okay() helper.

Remove #include <machine/frame.h> from all the arm code that doesn't
really need it. That would be almost everywhere it was included. Add
it in a couple files that really do need it and were previously getting
it by accident via another header.

Disable debugging.

Eliminate an intermediate buffer and some memcpy() operations, and do
DMA directly to/from the buffers passed in from higher layer drivers.

Reviewed by: gonzo

Add a macro that gets the physical address of a memory mapped device
register from a bus space resource.

Note that this macro is just for ARM, and is intended to have a short
lifespan. The DMA engines in some SoCs need the physical address of a
memory-mapped device register as one of the arguments for the transfer.
Several scattered ad-hoc solutions have been converted to use this macro,
which now also serves to mark the places where a more complete fix needs
to be applied (after that fix has been designed).

Add platform DMA support to SDHCI driver for BCM2835

Submitted by: Daisuke Aoyama <aoyama at peach.ne.jp>
Reviewed by: ian@

Spelling fixes

Spotted by: N. J. Mann

Roll back change of frequency for initialization sequence since it
seems to cause more problems then previous behavior: it either breaks
initilization sequence in other places or uncovers problems with
high-speed mode timing for SDHCI 3.0

- Add hw.bcm2835.sdhci.hs tunable to enable/disable highspeed mode in
SDHCI driver
Suggested by: Daisuke Aoyama

- Set initilization sequence frequency to 8MHz. It should fix Data CRC
errors. Standard requires initialization sequence to be executed
at 400KHz but on this hardware low frequncies seems to cause
Data CRC errors.

Value was derived from analyzing hardware signals after
Raspberry Pi is powered up. Before any data is read though DATA line
adapter's clock frequency is changed to 8MHz.

Modern cards should function fine at 8MHz but for older MMC cards it
can be overriden by setting hw.bcm2835.sdhci.min_freq tunable.

Get frequency from "clock-frequency" property of "/axi/sdhci" FDT node

Add BCM2835 SDHCI driver and enable it in Raspberry Pi config