MFhead@r320180

Merge ^/head r319973 through 321382.

Merge ^/head r320398 through r320572.

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

Merge ^/head r312207 through r312308.

MFhead@r312305

"Buses" is the preferred plural of "bus"

Replace archaic "busses" with modern form "buses."

Intentionally excluded:
* Old/random drivers I didn't recognize
* Old hardware in general
* Use of "bus

"Buses" is the preferred plural of "bus"

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

show more ...

Merge ^/head r308491 through r308841.

Stop including fdt_common.h from the arm code when it's unneeded.

Sponsored by: ABT Systems Ltd

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.

Merge from head

Sponsored by: Gandi.net

Merge from head

Sync up with head up to r289211.

Merge from head

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 dif

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.

show more ...

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 sign

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

show more ...

Reintegrate head: r274132-r277384

Sponsored by: The FreeBSD Foundation

Reintegrate head revisions r273096-r277147

Sponsored by: The FreeBSD Foundation

Sync to HEAD@r274766

Merge from head@274682

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, S

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

show more ...

IFC @r269962

Submitted by: Anish Gupta (akgupt3@gmail.com)

Merge head from 7/28

Sync to HEAD@r269943.

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