In this mode DATA_CMD register reads and writes are performed in
TX/RX FIFO-sized bursts to increase I2C bus utilization.
That reduces read time from 60us to 30us per byte when read data is fit
in to RX FIFO buffer in FAST speed mode in my setup.
IC clock rates are varied between different controller models so we have
to adjust timing registers in each case individually. Borrow intresting
constants and formulas from Intel specs, i2c-designware and lpss_intel
drivers and apply them to FreeBSD supported controller models.
Implement fetching of timing data via ACPI methods execution if available.
as the driver is fully functional on a cold boot through utilization of
polled mode.
As a side effect, ig4 children probe and attach methods can be called
earlier in the boot sequence, so now it is up to the child drivers
to wait for a kernel initialization completion if it is required.
If controller is allocated with IIC_NOWAIT option ig4 enables polled mode
for a period of allocation that makes possible to start I2C transfers
from the contexts where sleeping is not allowed e.g. from ithreads or
callouts.
Now io_lock is used as condition variable to synchronize active process with
the interrupt handler. It is not used for tasks other than waiting for
interrupt and passing parameters to and from it's handler.
There is no need to read all controller's RX FIFO data to clear RX_FULL
bit in interrupt handler as interrupts are masked permanently since
previous commit.
This avoids possible interrupt storms, depending on the state of the I2C
controller before the driver attached.
During attaching this clears the interrupt mask.
Revert r338215 as this change makes it no-op.
Obtained from: DragonflyBSD (d7c8555)
They share common device driver code with different bus attachments
This commit starts a bunch of changes which have following properties:
Reviewed by: imp (previous version)
MFC after: 1 month
Differential Revision: https://reviews.freebsd.org/D22016
Due to hardware limitation AMD I2C controller can't trigger pending
interrupt if interrupt status has been changed after clearing
interrupt status bits. So, I2C will lose the interrupt and IO will be
timed out. Implements a workaround to disable I2C controller interrupt
and re-enable I2C interrupt before existing interrupt handler.
Submitted by: rajfbsd@gmail.com
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D16720
Add PCI ids for I2C controllers on Apollo Lake platform. Also convert
switch/case probe logic into a table.
Reviewed by: avg
Differential Revision: https://reviews.freebsd.org/D16120
This was tested by Ben on HP Chromebook 13 G1 with a
Skylake CPU and Sunrise Point-LP I2C controller and by me on
Minnowboard Turbot with Atom E3826 (formerly Bay Trail)
Submitted by: Ben Pye <ben@curlybracket.co.uk>
Reviewed by: gonzo
Obtained from: DragonflyBSD (a4549657 by Imre Vadász)
MFC after: 2 weeks
Differential Revision: https://reviews.freebsd.org/D13654
Add ACPI part for ig4 driver to make it work on Intel BayTrail SoC where
ig4 device is available only through ACPI
Reviewed by: avg
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D8742
Summary:
The hardware does not expose a classic SMBus interface.
Instead it has a lower level interface that can express a far richer
I2C protocol than what smbus offers. However, the interface does not
provide a way to explicitly generate the I2C stop and start conditions.
It's only possible to request that the stop condition is generated
after transferring the next byte in either direction. So, at least
one data byte must always be transferred.
Thus, some I2C sequences are impossible to generate, e.g., an equivalent
of smbus quick command (<start>-<slave addr>-<r/w bit>-<stop>).
At the same time isl(4) and cyapa(4) are moved to iicbus and now they use
iicbus_transfer for communication. Previously they used smbus_trans()
interface that is not defined by the SMBus protocol and was implemented
only by ig4(4). In fact, that interface was impossible to implement
for the typical SMBus controllers like intpm(4) or ichsmb(4) where
a type of the SMBus command must be programmed.
The plan is to remove smbus_trans() and all its uses.
As an aside, the smbus_trans() method deviates from the standard,
but perhaps backwards, FreeBSD convention of using 8-bit slave
addresses (shifted by 1 bit to the left). The method expects
7-bit addresses.
There is a user facing consequence of this change.
A user must now provide device hints for isl and cyapa that specify an iicbus to use
and a slave address on it.
On Chromebook hardware where isl and cyapa devices are commonly found
it is also possible to use a new chromebook_platform(4) driver that
automatically configures isl and cyapa devices. There is no need to
provide the device hints in that case,
Right now smbus(4) driver tries to discover all slaves on the bus.
That is very dangerous. Fortunately, the probing code uses smbus_trans()
to do its job, so it is really enabled for ig4 only.
The plan is to remove that auto-probing code and smbus_trans().
Tested by: grembo, Matthias Apitz <guru@unixarea.de> (w/o
chromebook_platform)
Discussed with: grembo, imp
Reviewed by: wblock (docs)
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D8172
