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 r314064, r314060:

Fix typos in bootverbose printfs... display the write-protect pin info,
not the card-detect pin info.

Remove a variable that has been unused since r311735 (it should have been
removed as part of those changes).

MFC r311734, r311735, r311951, r314071:

Add new helper routines for sdhci bridge drivers that use gpio pins for
card presence and write protect switch detection.

Use the new sdhci_fdt_gpio helper functions to add full support for FDT
gpio pins for detecting card insert/remove and write protect for ti_sdhci.

Include sys/systm.h for use of bootverbose.

Revert to ti_sdhci driver's historic behavior: assume an sd card is
writable 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.

MFC r308640:

Use the correct OF_getencprop over OF_getprop + fdt32_to_cpu to read
integer data from the device tree.

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.)

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)

Switch TI platform support code from using FreeBSD's custom-baked DTS
files to vendor-provided ones. It should make easier to adopt platform
code to new revisions of hardware and to use DTS overlays for various
Beaglebone extensions (shields/capes).

Original dts filenames were not changed, they're now wrappers over dts
files provided by TI. So make sure you update .dtb files on your
devices as part of kernel update

GPIO addressing was changed: instead of one global /dev/gpioc0 there
are per-bank instances of /dev/gpiocX. Each bank has 32 pins so for
instance pin 121 on /dev/gpioc0 in old addressing scheme is now pin 25
on /dev/gpioc3

On Pandaboard serial console devices was changed from /dev/ttyu0 to
/dev/ttyu2 so you'll have to update /etc/ttys to get login prompt
on serial port in multiuser mode. Single user mode serial console
should work as-is

Differential Revision: https://reviews.freebsd.org/D2146
Reviewed by: rpaulo, ian, Michal Meloun, Svatopluk Kraus

Add a new sdhci quirk, SDHCI_QUIRK_WAITFOR_RESET_ASSERTED, to work around
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>

Rewrap long lines; no functional changes.

Submitted by: Michal Meloun <meloun@miracle.cz>

Add code to set and reset open-drain mode on the bus when requested.

Submitted by: Michal Meloun <meloun@miracle.cz>

Use a switch on ti_chip() to find which SoC we are on. This allow us t
only enable support for the SoCs we are built for.

Start removing the omap3 support. In base it was only ever a header and a
few changes to drivers, no kernel config was added. As the SoCs are quite
old and the code is unmaintained start the process of removing support by
deleting the header file and code that depends on it along with the macro
SOC_OMAP3. Other Ti SoCs shouldn't be affected, other than for us to have
less code to maintain.

Differential Revision: https://reviews.freebsd.org/D936
Reviewed by: rpaulo, loos

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

Adjust the comments about translating clock divisor bits to match recent
code changes.

Fix the logic for translating between MMCHS and SDHCI clock divisors.

Submitted by: Svatopluk Kraus <onwahe@gmail.com>

Various fixes to the ti_sdhci driver, mostly to make it work on Pandaboard.

- Don't allow high-speed mode on OMAP4 due to hardware erratum.
- Check the proper bit in the status register when waiting for the
controller to come out of reset.
- Add handling for the "non-removable" fdt property by always returning
"card is present" status.
- Add the non-removable property for the MMC card on a Beaglebone Black.
- Add the non-removable property for Pandaboard as a workaround.

For Pandaboard the card detect pin is handled by the twl6030 fpga device
which gets an interrupt on pin change and then has to query the fpga
for the actual status. We don't have code to do that yet.

Submitted by: Svatopluk Kraus <onwahe@gmail.com>

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.

Bugfixes... the host capabilties from FDT data are stored in host.caps, not
host.host_ocr, examine the correct field when setting up the hardware. Also,
the offset for the capabilties register should be 0x140, not 0x240.

Submitted by: Ilya Bakulin <ilya@bakulin.de>
Pointy hat to: me

The ability to do 8-bit implies 4-bit capability too. Rearrange the cases
and add a fallthrough comment to make that happen.

TI sdhci driver improvements, mostly related to fdt data...

Use the published compatible strings (our own invention, "ti,mmchs" is
still accepted as well, for now).

Don't blindly turn on 8-bit bus mode, because even though the conroller
supports it, the board has to be wired appropriately as well. Use the
published property (bus-width=<n>) and honor all the valid values (1,4,8).

The eMMC device on a Beaglebone Black is wired for 8-bit, update the dts.

The mmchs controller can inherently do both 1.8v and 3.0v on the first
device and 1.8v only on other devices, unless an external transceiver is
used. Set the voltage automatically for the first device and honor
the published fdt property (ti,dualvolt) for other devices.

Thanks go to Ilya Bakulin for figuring out the voltage compatibility stuff.

Make the standard sdhci(4) driver work for the TI OMAP family SoCs.
The MMCHS hardware is pretty much a standard SDHCI v2.0 controller with a
couple quirks, which are now supported by sdhci(4) as of r254507.

This should work for all TI SoCs that use the MMCHS hardware, but it has
only been tested on AM335x right now, so this enables it on those platforms
but leaves the existing ti_mmchs driver in place for other OMAP variants
until they can be tested.

This initial incarnation lacks DMA support (coming soon). Even without it
this improves performance pretty noticibly over the ti_mmchs driver,
primarily because it now does multiblock IO.