Before this commit the i2c-designware-platdrv assumes that if the pdev
has an apci-companion it should use a dynamic adapter-nr and it sets
adapter->nr to -1, otherwise it will use pdev->id as adapter->nr.

There are 3 ways how platform_device-s to which i2c-designware-platdrv
will bind can be instantiated:

1) Through of / devicetree
2) Through ACPI enumeration
3) Explicitly instantiated through platform_device_create + add

1) In case of devicetree-instantiation the drivers/of code always sets
pdev->id to PLATFORM_DEVID_NONE, which is -1 so in this case both paths
to set adapter->nr end up doing the same thing.

2) In case of ACPI instantiation the device will always have an
ACPI-companion, so we are already using dynamic adapter-nrs.

3) There are 2 places manually instantiating a designware_i2c platform_dev:
drivers/mfd/intel_quark_i2c_gpio.c
drivers/mfd/intel-lpss.c

In the intel_quark_i2c_gpio.c case pdev->id is always 0, so switching to
dynamic adapter-nrs here could lead to the bus-number no longer being
stable, but the quark X1000 only has 1 i2c-controller, which will also
be assigned bus-number 0 when using dynamic adapter-nrs.

In the intel-lpss.c case intel_lpss_probe() is called from either
intel-lpss-acpi.c in which case there always is an ACPI-companion, or
from intel-lpss-pci.c. In most cases devices handled by intel-lpss-pci.c
also have an ACPI-companion, so we use a dynamic adapter-nr. But in some
cases the ACPI-companion is missing and we would use pdev->id (allocated
from intel_lpss_devid_ida). Devices which use the intel-lpss-pci.c code
typically have many i2c busses, so using pdev->id in this case may lead
to a bus-number conflict, triggering a WARN(id < 0, "couldn't get idr")
in i2c-core-base.c causing an oops an the adapter registration to fail.
So in this case using non dynamic adapter-nrs is actually undesirable.

One machine on which this oops was triggering is the Apollo Lake based
Acer TravelMate Spin B118.

TL;DR: Switching to always using dynamic adapter-numbers does not make
any difference in most cases and in the one case where it does make a
difference the behavior change is desirable because the old behavior
caused an oops.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1687065Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

i2c-designware-platdrv assumes that if the pdev has an apci-companion
it should use a dynamic adapter-nr and otherwise it will use pdev->id
as adapter-nr.

Before this commit the setting of the adapter.nr was somewhat convoluted,
in the acpi_companion case it was set from dw_i2c_acpi_configure, in the
non acpi_companion case it was set from dw_i2c_set_fifo_size based on
tx_fifo_depth not being set yet indicating that dw_i2c_acpi_configure was
not executed.

This cleans this up, directly setting the adapter-nr from
dw_i2c_plat_probe for both cases.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Make sure we report 'no buffer' for 0-length messages. This can only
happen if threshold is set to 0 which is kind of bogus but we should
still handle this situation. Update the docs and add a debug message
to educate callers of this function.
Reported-by: NHsin-Yi Wang <hsinyi@chromium.org>
Fixes: e94bc5d1 ("i2c: add helpers to ease DMA handling")
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NHsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It conforms with Reference Manual I2C timing section.

Fixes: aeb068c5 ("i2c: i2c-stm32f7: add driver")
Signed-off-by: NNicolas Le Bayon <nicolas.le.bayon@st.com>
Signed-off-by: NBich Hemon <bich.hemon@st.com>
Reviewed-by: NPierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

To make sure people can understand the lockless design of this driver
without the need to dive into git history, add a comment giving an
overview of the situation.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch fixes the problem that an interrupt may set up a new I2C
message and the DMA callback overwrites this setup.

By disabling the DMA Enable Register(ICDMAER), rcar_i2c_dma_unmap()
enables interrupts for register settings (such as Master Control
Register(ICMCR)) and advances the I2C transfer sequence.

If an interrupt occurs immediately after ICDMAER is disabled, the
callback handler later continues and overwrites the previous settings
from the interrupt. So, disable ICDMAER at the end of the callback to
ensure other interrupts are masked until then.

Note that this driver needs to work lock-free because there are IP cores
with a HW race condition which prevent us from using a spinlock in the
interrupt handler.

Reproduction test:
1. Add a delay after disabling ICDMAER. (It is expected to generate an
   interrupt of rcar_i2c_irq())

    void rcar_i2c_dma_unmap(struct rcar_i2c_priv *priv)
    {
        ...
        rcar_i2c_write(priv, ICDMAER, 0);
        usleep_range(500, 800)
        ...
        priv->dma_direction = DMA_NONE;
    }

2. Execute DMA transfers

 $ i2ctransfer -y 4 w9@0x6a 1 1+ r16

3. A log message of BUG_ON() will be displayed.

Fixes: 73e8b052 ("i2c: rcar: add DMA support")
Signed-off-by: NHiromitsu Yamasaki <hiromitsu.yamasaki.ym@renesas.com>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
[wsa: updated test case to be more reliable, added note to comment]
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

When compiling with -Wformat, clang warns:

drivers/i2c/busses/i2c-sis630.c:482:4: warning: format specifies type
      'unsigned short' but the argument has type 'int' [-Wformat]
                        smbus_base + SMB_STS,
                        ^~~~~~~~~~~~~~~~~~~~

drivers/i2c/busses/i2c-sis630.c:483:4: warning: format specifies type
      'unsigned short' but the argument has type 'int' [-Wformat]
                        smbus_base + SMB_STS + SIS630_SMB_IOREGION - 1);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

drivers/i2c/busses/i2c-sis630.c:531:37: warning: format specifies type
      'unsigned short' but the argument has type 'int' [-Wformat]
                 "SMBus SIS630 adapter at %04hx", smbus_base + SMB_STS);
                                          ~~~~~   ^~~~~~~~~~~~~~~~~~~~

This patch fixes the format strings to use the format type for int.

Link: https://github.com/ClangBuiltLinux/linux/issues/378Signed-off-by: NLouis Taylor <louis@kragniz.eu>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

DMA with zero-length transfers doesn't make sense and this HW doesn't
support them at all, so increase the threshold.

Fixes: fc66b39f ("i2c: mediatek: Use DMA safe buffers for i2c transactions")
Signed-off-by: NHsin-Yi Wang <hsinyi@chromium.org>
[wsa: reworded commit message]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

A previous change allowed I2C client devices to discover new IRQs upon
reprobe by clearing the IRQ in i2c_device_remove. However, if an IRQ was
assigned in i2c_new_device, that information is lost.

For example, the touchscreen and trackpad devices on a Dell Inspiron laptop
are I2C devices whose IRQs are defined by ACPI extended IRQ types. The
client device structures are initialized during an ACPI walk. After
removing the i2c_hid device, modprobe fails.

This change caches the initial IRQ value in i2c_new_device and then resets
the client device IRQ to the initial value in i2c_device_remove.

Fixes: 6f108dd7 ("i2c: Clear client->irq in i2c_device_remove")
Signed-off-by: NJim Broadus <jbroadus@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
[wsa: this is an easy to backport fix for the regression. We will
refactor the code to handle irq assignments better in general.]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

gcc complains, rightfully so, I think:

drivers/i2c/busses/i2c-ocores.c:32: warning: Cannot understand  * @process_lock: protect I2C transfer process.
 on line 32 - I thought it was a doc line

Make it a simple comment.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

On most Intel Bay- and Cherry-Trail systems the PMIC is connected over I2C
and the PMIC is accessed through various means by the _PS0 and _PS3 ACPI
methods (power on / off methods) of various devices.

This leads to suspend/resume ordering problems where a device may be
resumed and get its _PS0 method executed before the I2C controller is
resumed. On Cherry Trail this leads to errors like these:

     i2c_designware 808622C1:06: controller timed out
     ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
     ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR
     video LNXVIDEO:00: Failed to change power state to D0

But on Bay Trail this caused I2C reads to seem to succeed, but they end
up returning wrong data, which ends up getting written back by the typical
read-modify-write cycle done to turn on various power-resources.

Debugging the problems caused by this silent data corruption is quite
nasty. This commit adds a check which disallows i2c_dw_xfer() calls to
happen until the controller's resume method has completed.

Which turns the silent data corruption into getting these errors in
dmesg instead:

    i2c_designware 80860F41:04: Error i2c_dw_xfer call while suspended
    ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
    ACPI Error: Method parse/execution failed \_SB.PCI0.GFX0._PS0, AE_ERROR

Which is much better.

Note the above errors are an example of issues which this patch will
help to debug, the actual fix requires fixing the suspend order and
this has been fixed by a different commit.

Note the setting / clearing of the suspended flag in the suspend / resume
methods is NOT protected by i2c_lock_bus(). This is intentional as these
methods get called from i2c_dw_xfer() (through pm_runtime_get/put) a nd
i2c_dw_xfer() is called with the i2c_bus_lock held, so otherwise we would
deadlock. This means that there is a theoretical race between a non runtime
suspend and the suspended check in i2c_dw_xfer(), this is not a problem
since normally we should not hit the race and this check is primarily a
debugging tool so hitting the check if there are suspend/resume ordering
problems does not need to be 100% reliable.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 86c92b99 ("i2c: tegra: Add DMA support") added DMA support
to the Tegra I2C driver for Tegra devices that support the APB DMA
controller. One side-effect of this change is that even for Tegra
devices that do not have an APB DMA controller and hence, cannot
support DMA tranfers for I2C transactions, the following error messages
are still displayed ...

 ERR KERN tegra-i2c 31c0000.i2c: cannot use DMA: -19
 ERR KERN tegra-i2c 31c0000.i2c: falling back to PIO

There is no point displaying the above messages for devices that do not
have an APB DMA controller and so fix this by returning from the
tegra_i2c_init_dma() function if 'has_apb_dma' is not true.

Furthermore, if CONFIG_TEGRA20_APB_DMA is not set, then rather than
printing an error message, print an debug message as for whatever reason
this could be intentional.

Fixes: 86c92b99 ("i2c: tegra: Add DMA support")
Signed-off-by: NJonathan Hunter <jonathanh@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add a fault injector simulating a Kernel panic happening after starting
a transfer. Read the docs for its usage.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add a fault injector simulating 'arbitration lost' from multi-master
setups. Read the docs for its usage.

A helper function for future fault injectors using SCL interrupts is
created to achieve this.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Multi-master support is defeatured on Tegra210 and Tegra186 due to
known bugs.

This patch removes multi-master support for Tegra210 and Tegra186
I2C HW feature.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Tegra186 does not have master FIFO  control register and instead
uses FIFO control register like prior Tegra chipset.

This patch fixes this and prevents crashing during boot when
accessing FIFO control registers.
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The phrasing in two dev_err messages is using fallbacking which
os less understandable than "falling back", so fix this up.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Actually, total amount of available minor number for a single major is
MINORMASK + 1. So expand minor range when registering chrdev region.
Signed-off-by: NChengguang Xu <cgxu519@gmx.com>
[wsa: fixed typo in commit message]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In multi-master environment, this driver's master cannot know
exactly when a peer master sends data to this driver's slave so
cases can be happened that this master tries sending data through
the master_xfer function but slave data from a peer master is still
being processed or slave xfer is started by a peer immediately
after it queues a master command. To support multi-master use cases
properly, this H/W provides arbitration in physical level and it
provides priority based command handling too to avoid conflicts in
multi-master environment, means that if a master and a slave events
happen at the same time, H/W will handle a higher priority event
first and a pending event will be handled when bus comes back to
the idle state.

To support this H/W feature properly, this patch adds the 'pending'
state of master and its handling code so that the pending master
xfer can be continued after slave operation properly.
Signed-off-by: NJae Hyun Yoo <jae.hyun.yoo@linux.intel.com>
Reviewed-by: NBrendan Higgins <brendanhiggins@google.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The driver's interrupt handler checks whether a message is currently
being handled with the curr_msg pointer. When it is NULL, the interrupt
is considered to be unexpected. Similarly, the i2c_start_transfer
routine checks for the remaining number of messages to handle in
num_msgs.

However, these values are never cleared and always keep the message and
number relevant to the latest transfer (which might be done already and
the underlying message memory might have been freed).

When an unexpected interrupt hits with the DONE bit set, the isr will
then try to access the flags field of the curr_msg structure, leading
to a fatal page fault.

The msg_buf and msg_buf_remaining fields are also never cleared at the
end of the transfer, which can lead to similar pitfalls.

Fix these issues by introducing a cleanup function and always calling
it after a transfer is finished.

Fixes: e2474541 ("i2c: bcm2835: Fix hang for writing messages larger than 16 bytes")
Signed-off-by: NPaul Kocialkowski <paul.kocialkowski@bootlin.com>
Acked-by: NStefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In case the hold bit is not needed we are carrying the old values.
Fix the same by resetting the bit when not needed.

Fixes the sporadic i2c bus lockups on National Instruments
Zynq-based devices.

Fixes: df8eb569 ("i2c: Add driver for Cadence I2C controller")
Reported-by: NKyle Roeschley <kyle.roeschley@ni.com>
Acked-by: NMichal Simek <michal.simek@xilinx.com>
Signed-off-by: NShubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
Tested-by: NKyle Roeschley <kyle.roeschley@ni.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If an smbus transfer fails, there's no guarantee that the output
buffer was written.  So, avoid trying to show the output buffer when
tracing after an error.  This was 'mostly harmless', but would trip
up kasan checking if left-over cruft in byte 0 is a large length,
causing us to read from unwritten memory.
Signed-off-by: NJohn Sperbeck <jsperbeck@google.com>
Reviewed-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Add the I2C bus clock speed to the platform data structure.
If not set, default to 100KHz as before.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Some implementations of the OCORES i2c bus master use IO mapped
registers. Add support for getting the IO registers from the platform
data, and register accessor functions.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Miscellaneous style fixes from checkpatch
Signed-off-by: NFederico Vaga <federico.vaga@cern.ch>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It adds the SPDX tag and it removes the old text about the GPLv2.
Signed-off-by: NFederico Vaga <federico.vaga@cern.ch>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This driver assumes that an interrupt line is always available for
the I2C master. This is not always the case and this patch adds support
for a polling version.

Report from Andrew Lunn:

  I did some timing tests for this. On my box, we request a udelay of
  80uS. The kernel actually delays for about 79uS. We then spin in
  ocores_wait() for an additional 10-11uS, which is 3 to 4 iterations.

  There are actually 9 bits on the wire, not 8, since there is an
  ACK/NACK bit after the actual data transfer. So i changed the delay to
  (9 * 1000) / i2c->bus_clock_khz. That resulted in ocores_wait() mostly
  not looping at all. But for reading an 4K AT24 EEPROM, it increased
  the read time by 10ms, from 424ms to 434ms. So we should probably keep
  with 8.
Signed-off-by: NFederico Vaga <federico.vaga@cern.ch>
Tested-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If the Interrupt Flag (IF) is not set, we should not handle the IRQ:
- the line can be shared with other devices
- it can be a spurious interrupt

To avoid reading twice the status register, the ocores_process() function
expects it to be read by the caller.
Signed-off-by: NFederico Vaga <federico.vaga@cern.ch>
Acked-by: NPeter Korsgaard <peter@korsgaard.com>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Detecting a timeout is ok, but we also need to assert a STOP command on
the bus in order to prevent it from generating interrupts when there are
no on going transfers.

Example: very long transmission.

1. ocores_xfer: START a transfer
2. ocores_isr : handle byte by byte the transfer
3. ocores_xfer: goes in timeout [[bugfix here]]
4. ocores_xfer: return to I2C subsystem and to the I2C driver
5. I2C driver : it may clean up the i2c_msg memory
6. ocores_isr : receives another interrupt (pending bytes to be
                transferred) but the i2c_msg memory is invalid now

So, since the transfer was too long, we have to detect the timeout and
STOP the transfer.

Another point is that we have a critical region here. When handling the
timeout condition we may have a running IRQ handler. For this reason I
introduce a spinlock.

In order to make easier to understan locking I have:
- added a new function to handle timeout
- modified the current ocores_process() function in order to be protected
  by the new spinlock
Like this it is obvious at first sight that this locking serializes
the execution of ocores_process() and ocores_process_timeout()
Signed-off-by: NFederico Vaga <federico.vaga@cern.ch>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch adds I2C interface timing registers support for
proper bus rate configuration along with meeting the I2C spec
setup and hold times based on the tuning performed on Tegra210,
Tegra186 and Tegra194 platforms.

I2C_INTERFACE_TIMING_0 register contains TLOW and THIGH field
and Tegra I2C controller design uses them as a part of internal
clock divisor.

I2C_INTERFACE_TIMING_1 register contains the setup and hold times
for start and stop conditions.
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Tegra194 allows max of 64K bytes and Tegra186 and prior allows
max of 4K bytes of transfer per packet.

one sec timeout is not enough for transfers more than 10K bytes
at STD bus rate.

This patch updates I2C transfer timeout based on the transfer size
and I2C bus rate to allow enough time during max transfer size at
lower bus speed.
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch adds DMA support for Tegra I2C.

Tegra I2C TX and RX FIFO depth is 8 words. PIO mode is used for
transfer size of the max FIFO depth and DMA mode is used for
transfer size higher than max FIFO depth to save CPU overhead.

PIO mode needs full intervention of CPU to fill or empty FIFO's
and also need to service multiple data requests interrupt for the
same transaction. This adds delay between data bytes of the same
transfer when CPU is fully loaded and some slave devices has
internal timeout for no bus activity and stops transaction to
avoid bus hang. DMA mode is helpful in such cases.

DMA mode is also helpful for Large transfers during downloading or
uploading FW over I2C to some external devices.

Tegra210 and prior Tegra chips use APBDMA driver which is replaced
with GPCDMA on Tegra186 and Tegra194.
This patch uses has_apb_dma flag in hw_feature to differentiate
DMA driver change between Tegra chipset.

APBDMA driver is registered from module-init level and this patch
also has a change to register I2C driver at module-init level
rather than subsys-init to avoid deferring I2C probe till APBDMA
driver is registered.
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Tested-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Tegra194 supports maximum 64K bytes per packet including 12 bytes of
packet header irrespective of PIO or DMA mode transfer.

This patch updates Tegra194 max write length to account for packet
header size for transfers.

Cc: stable@vger.kernel.org # 4.20+
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Tegra186 and prior supports maximum 4K bytes per packet transfer
including 12 bytes of packet header.

This patch fixes max write length limit to account packet header
size for transfers.

Cc: stable@vger.kernel.org # 4.4+
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Bus clear feature of Tegra I2C controller helps to recover from
bus hang when I2C master loses the bus arbitration due to the
slave device holding SDA LOW continuously for some unknown reasons.

Per I2C specification, the device that held the bus LOW should
release it within 9 clock pulses.

During bus clear operation, Tegra I2C controller sends 9 clock
pulses and terminates the transaction with STOP condition.
Upon successful bus clear operation, bus goes to idle state and
driver retries the transaction.
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This patch sorts all the include headers alphabetically for the
I2C Tegra driver.
Acked-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NDmitry Osipenko <digetx@gmail.com>
Signed-off-by: NSowjanya Komatineni <skomatineni@nvidia.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The latest documentation made it clear that we need to initialize the
TCYC value independently of DMA. The old code used TCYC06 (wrongly) for
non-DMA transfers. The new code sets TCYC up independently from DMA.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I think it is clear enough if we have the explanation once and make it
clear it is applicable for both SCL and SDA. Reword it a little with
the help of Simon's native language skills :)
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We measured the clock on a Lager and an Ebisu board. The new formula
gives better results for both. So after Gen3, switch to this formula for
all Gen2 SoCs.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We could finally measure the clock on an Ebisu board. The new formula
gives way better results, i.e. 100kHz instead of 106kHz and 400kHz
instead of 387kHz. Switch to these formulas for all Gen3 SoCs.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>