Handle error bits of INTR_STAT and TX_ABORT registers.
Move interrupt clearing from interrupt handler to polling loop to get
common execution path with polled mode.
Do not clear interrupts with reading of IG4_REG_CLR_INTR register as
interrupts, triggered during the period from reg_read(IG4_REG_INTR_STAT)
to reg_read(IG4_REG_CLR_INTR) will be missed.
Instead, read each IG4_REG_CLR_* register separately.
INTR_STAT register exposes more useful informaton then STA register does
e.g. it exposes error and I2C bus STOP conditions. Make it a main source
of I2C transfer state.
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.
Currently ig4 internally depends on it's own interrupts and uses mtx_sleep()
to wait for them. That means it can not be used from any context where
sleeping is disallowed e.g. on cold boot, from DDB/KDB, from other device
driver's interrupt handlers and so on.
This change replaces sleeps with busy loops in cold boot and DDB cases.
Setting the IG4_REG_RX_TL register to 1 was actually generating an
interrupt after 2 bytes were available in the Rx fifo. We need to set the
register to 0 to get an interrupt for 1 byte already.
Obtained from: DragonflyBSD (02f0bf2)
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.
Specs shows no dedicated interrupt firing on disable of the controller.
Remove io lock acquisitions around set_controller() calls as they are
not needed anymore.
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)
Fail the attach on controller startup errors. For some reason the
dell xps 13 says there's I2C controller, but the controller appears
to be permanente disabled and will refuse to enable.
Obtained from: DragonflyBSD (509820b)
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
Execution of "Soft reset" command (IG4_REG_RESETS_SKL) at controller init
stage sets SDA_HOLD register value to 0x0001 which is often too low for
normal operation.
Set SDA_HOLD back to 28 after reset to restore controller functionality.
PR: 240339
Reported by: imp, GregV, et al.
MFC after: 3 days
This includes removing stray whitespace, adding a line after the
variable declaration block and removing a redundant check.
MFC after: 1 week
X-MFC with: r339754
In testing on a Dell Latitude 7480, having ig4.ko loaded during a
suspend caused the system to hang. It turns out that ig4iic_intr() was
being called after the device entered D3, and entered an infinite loop
because a read of the I2C status register returned all ones, causing us
to attempt to read a byte from the data buffer until one of the status
bits clears. This occured because ig4iic_pci0 shares an interrupt with
the VGA device on this laptop, so ig4iic_intr() gets called even when
there is no work to do. This is exactly the problem fixed by r342170,
which resolves the hang for me and allows suspend/resume to work with
ig4.ko loaded. So, re-enable autoloading of ig4.ko in the hope that
r342170 resolves the problem universally.
Reviewed by: gonzo
MFC after: 1 month (pending an MFC of r342170)
Differential Revision: https://reviews.freebsd.org/D18587
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
Newer chips may require assert/deassert after power down for proper
startup. Check respective flag in DEVIDLE_CTRL and perform operation
if neccesssary.
PR: 221777
Submitted by: marc.priggemeyer@gmail.com
Obtained from: DragonFly BSD
Tested on: Thinkpad T470
ig4(4) does not support suspend/resume but present on the hardware where
such functionality is critical, like laptops. Remove PNP info to avoid
breaking suspend/resume on the systems where ig4(4) load is not explicitly
requested by the user.
PR: 229791
Reported by: Ali Abdallah
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
Some machine BIOSes use the I2C bus and leave it in a state that causes
interrupts to not work properly due to a pending interrupt having been
latched.
Refactor the code a bit to clear pending interrupts when I2C is enabled.
This fixes the primary problem.
Also fix a possible race condition in the interrupt handler where the
interrupt was being cleared after reading the status instead of before.
Reported by: pfg
Reviewed by: jhb
Approved by: jhb
Obtained from: DragonFly BSD
Differential Revision: https://reviews.freebsd.org/D6586
