MFC r329479-r329480, r329483, r329506-r329507, r329526, r329529, r329536,
r329541, r329730, r329841, r329988, r330397

r329479:
Do not try to deallocate memory that wasn't allocated (you'd think that
would be safe, but the function also tries to destroy mutexes that never
got created).

I guess this can only happen when imx_ehci_detach() is called on the
error-exit path from imx_ehci_attach(), and that path never got exercised
before today.

r329480:
Don't call sdhci_cleanup_slot() if sdhci_init_slot() never got called.
Also, do callout_init() very early in attach, so that callout_drain()
can be called in detach without worrying about whether it ever got init'd.

r329483:
Fix fallout from the import of fresh dts source files from linux 4.15. It
appears that node names no longer include leading zeroes in the @address
qualifiers, so we have to search for the nodes involved in interrupt fixup
using both flavors of name to be compatible with old and new .dtb files.

(You know you're in a bad place when you're applying a workaround to code
that exists only as a workaround for another problem.)

r329506:
Add a detach method so that this can be a kldunload-friendly module.

r329507:
Build modules specific to imx5/imx6 only when building those kernels.

This adds sys/modules/imx with a SUBDIR makefile to make the whole
collection of modules that are specific to these SoCs. Initially, that
"whole collection" consists of the if_ffec and imx_i2c drivers.

The if_ffec driver is referenced in its existing home in ../ffec rather
than moving it into the imx directory, because it's used by powerpc too,
but it is no longer built for all armv6/7 systems.

The imx_i2c driver is newly added as a module.

r329526:
Allow i2c hardware drivers to declare their own relationships to ofw_iicbus
rather than relying on a set of canned EARLY_DRIVER_MODULE() statements in
the ofw_iicbus source. This means hw drivers will no longer be required to
use one of a few predefined driver names. They will also now be able to
decide themselves if they want to use DRIVER_MODULE or EARLY_DRIVER_MODULE
and to set which pass to attach on for early modules.

Mainly, this adds extern declarations for the driver and devclass variables.
It also renames ofwiicbus_devclass to ofw_iicbus_devclass to be consistant
with the way we use ofw_ prefixes on this stuff.

r329529:
Give the imx_i2c driver its own name, set up its relationship to ofw_iicbus.
Previously it called itself 'iichb' to link up with the EARLY_DRIVER_MODULE
declaration in ofw_iicbus.c.

r329536:
Add the MODULE_DEPEND()s needed so that the kernel linker can resolve all
the symbols at load time when iicbus is not compiled into the kernel.

r329541:
Build ofw_iicbus as a module if OPT_FDT is defined.

r329730:
Add required header files.

Reported by: andreast@

r329841:
Add a missing line continuation.

How many commits does it take to get a simple module makefile working?
Apparently at least three.

Pointy hat to: ian

r329988:
Instead of building ofw_iicbus as a separate module, just compile it in to
the iicbus module for FDT-based systems.

The primary motivation for this is that host controller drivers which
declare DRIVER_MODULE(ofw_iicbus, thisdriver, etc, etc) now only need a
single MODULE_DEPEND(thisdriver, ofw_iicbus) for runtime linking to resolve
all the symbols. With ofw_iicbus and iicbus in separate modules, drivers
would need to declare a MODULE_DEPEND() on both, because symbol lookup is
non-recursive through the dependency chain. Requiring a driver to have
MODULE_DEPENDS() on both amounts to requiring the drivers to understand the
kobj inheritence details of how ofw_iicbus is implemented, which seems like
something they shouldn't have to know (and could even change some day).

Also, this is somewhat analogous to how the drivers get built when compiled
into the kernel. You don't have to ask for ofw_iicbus separately, it just
gets built in along with iicbus when option FDT is in effect.

r330397:
Fix a paste-o: use the IICBUS version constants, not IICBB bitbang driver's.

MFC r323474, r323553, r323691

r323474:
Add a default implementation that returns ENODEV for start, repeat_start,
stop, read, and write methods. Some controllers don't implement these
individual operations and have only a transfer method. In that case, we
should return an indication that the device is present but doesn't support
the method, as opposed to the kobj default error ENXIO which makes it
look like the whole device is missing. Userland tools such as i2c(8) can
use the differing return values to switch between the two different i2c
IO mechanisms.

r323553:
Defer attaching and probing iicbus and its children until interrupts are
available, in i2c controller drivers that require interrupts for transfers.

This is the result of auditing all 22 existing drivers that attach iicbus.
These drivers were the only ones remaining that require interrupts and were
not using config_intrhook to defer attachment. That has led, over the
years, to various i2c slave device drivers needing to use config_intrhook
themselves rather than performing bus transactions in their probe() and
attach() methods, just in case they were attached too early.

r323691:
Give icee(4) a detach() method so it can be used as a module. Add a
module makefile for it.

MFC r321586:

Add a debug sysctl that lets you see i2c bus traffic through this device.

MFC r320460, r320461, r320462, r320463:

If an i2c transfer ends due to error, issue a stop on the bus even if the
nostop option is set, if a start was issued.

Add iic_recover_bus(), a helper function that can be used by any i2c driver
which is able to manipulate the clock and data lines directly.
When an i2c bus is hung by a slave device stuck in the middle of a
transaction that didn't complete properly, this function manipulates the
clock and data lines in a sequence known to reliably reset slave devices.
The most common cause of a hung i2c bus is a system reboot in the middle of
an i2c transfer (so it doesnt' happen often, but now there is a way other
than power cycling to recover from it).

Add bus recovery handling to the imx5/imx6 i2c driver.

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

sys/arm: make use of the howmany() macro when available.

We have a howmany() macro in the <sys/param.h> header that is
convenient to re-use as it makes things easier to read.

Use IIC_EBUSBSY and IIC_BUSERR status values consistantly across all drivers.
Make it clearer what each one means in the comments that define them.

IIC_BUSBSY was used in many places to mean two different things, either
"someone else has reserved the bus so you have to wait until they're done"
or "the signal level on the bus was not in the state I expected before/after
issuing some command".

Now IIC_BUSERR is used consistantly to refer to protocol/signaling errors,
and IIC_BUSBSY refers to ownership/reservation of the bus.

Mostly rewrite the imx i2c driver. This started out as an attempt to fix
one specific problem: the driver didn't check for ACK/NAK after writing a
slave address byte to the bus, and some slaves signal that they are busy
(such as when completing an internal write to flash memory) by sending a
NAK in response to being addressed.

While working on that problem I discovered that the driver's handling of
error conditions in general didn't match the state transition diagram in
the reference manual, and making that right resulted in a lot of code
reorganization.

Along the way various other changes also happened...

- Remove a mutex that wasn't protecting anything.
- Remove some mystery DELAY()s, document the few that remain.
- Use pause_sbt(9) to yield the processor for the bulk of the time it
takes to transfer each byte rather than busy-polling the whole time.
- Disable the controller when no transfers are in progress; since we
don't operate in slave mode, there's no reason to run the hardware.
- Remove a bunch of unecessary code from probe().

Allow i2c bus speed to be configured via hints, FDT data, and sysctl.

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

Enable Freescale i.MX I2C driver for i.MX6.

Rename i.MX I2C driver file.

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.

Update copyright date.

Integrate Efika MX project back to home.

Sponsored by: The FreeBSD Foundation