The BAM mode requires buffer for start tag data and tx, rx SG
list. Currently, this is being taken for maximum transfer length
(65K). But an I2C transfer can have multiple messages and each
message can be of this maximum length so the buffer overflow will
happen in this case. Since increasing buffer length won’t be
feasible since an I2C transfer can contain any number of messages
so this patch does following changes to make i2c transfers working
for multiple messages case.

1. Calculate the required buffers for 2 maximum length messages
   (65K * 2).
2. Split the descriptor formation and descriptor scheduling.
   The idea is to fit as many messages in one DMA transfers for 65K
   threshold value (max_xfer_sg_len). Whenever the sg_cnt is
   crossing this, then schedule the BAM transfer and subsequent
   transfer will again start from zero.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Currently the completion timeout is being taken according to
maximum transfer length which is too high if SCL is operating in
high frequency. This patch calculates timeout on the basis of
one-byte transfer time and uses the same for completion timeout.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Currently each message length in complete transfer is being
checked for determining DMA mode and if any of the message length
is less than FIFO length then non DMA mode is being used which
will increase overhead. DMA can be used for any length and it
should be determined with complete transfer length. Now, this
patch selects DMA mode if the total length is greater than FIFO
length.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Currently the i2c error handling in BAM mode is not working
properly in stress condition.

1. After an error, the FIFO are being written with FLUSH and
   EOT tags which should not be required since already these tags
   have been written in BAM descriptor itself.

2. QUP state is being moved to RESET in IRQ handler in case
   of error. When QUP HW encounters an error in BAM mode then it
   moves the QUP STATE to PAUSE state. In this case, I2C_FLUSH
   command needs to be executed while moving to RUN_STATE by writing
   to the QUP_STATE register with the I2C_FLUSH bit set to 1.

3. In Error case, sometimes, QUP generates more than one
   interrupt which will trigger the complete again. After an error,
   the flush operation will be scheduled after doing
   reinit_completion which should be triggered by BAM IRQ callback.
   If the second QUP IRQ comes during this time then it will call
   the complete and the transfer function will assume the all the
   BAM HW descriptors have been completed.

4. The release DMA is being called after each error which
   will free the DMA tx and rx channels. The error like NACK is very
   common in I2C transfer and every time this will be overhead. Now,
   since the error handling is proper so this release channel can be
   completely avoided.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Austin Christ <austinwc@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

In case of FLUSH operation, BAM copies INPUT EOT FLUSH (0x94)
instead of normal EOT (0x93) tag in input data stream when an
input EOT tag is received during flush operation. So only one tag
will be written instead of 2 separate tags.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The role of FLUSH and EOT tag is to flush already scheduled
descriptors in BAM HW in case of error. EOT is required only
when descriptors are scheduled in RX FIFO. If all the messages
are WRITE, then only FLUSH tag will be used.

A single BAM transfer can have multiple read and write messages.
The EOT and FLUSH tags should be scheduled at the end of BAM HW
descriptors. Since the READ and WRITE can be present in any order
so for some of the cases, these tags are not being written
correctly.

Following is one of the example

   READ, READ, READ, READ

Currently EOT and FLUSH tags are being written after each READ.
If QUP gets NACK for first READ itself, then flush will be
triggered. It will look for first FLUSH tag in TX FIFO and will
stop there so only descriptors for first READ descriptors be
flushed. All the scheduled descriptors should be cleared to
generate BAM DMA completion.

Now this patch is scheduling FLUSH and EOT only once after all the
descriptors. So, flush will clear all the scheduled descriptors and
BAM will generate the completion interrupt.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Sricharan R <sricharan@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The rx_nents and tx_nents are redundant. rx_buf and tx_buf can
be used for total number of SG entries. Since rx_buf and tx_buf
give the impression that it is buffer instead of count so rename
it to tx_cnt and rx_cnt for giving it more meaningful variable
name.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

1. Assigns use_dma in qup_dev structure itself which will
   help in subsequent patches to determine the mode in IRQ handler.
2. Does minor code reorganization for loops to reduce the
   unnecessary comparison and assignment.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Reviewed-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The QUP BSLP BAM generates the following error sometimes if the
current I2C DMA transfer fails and the flush operation has been
scheduled

    “bam-dma-engine 7884000.dma: Cannot free busy channel”

If any I2C error comes during BAM DMA transfer, then the QUP I2C
interrupt will be generated and the flush operation will be
carried out to make I2C consume all scheduled DMA transfer.
Currently, the same completion structure is being used for BAM
transfer which has already completed without reinit. It will make
flush operation wait_for_completion_timeout completed immediately
and will proceed for freeing the DMA resources where the
descriptors are still in process.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Acked-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Austin Christ <austinwc@codeaurora.org>
Reviewed-by: Andy Gross <andy.gross@linaro.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The file has been updated from 2016 to 2018 so fixed the
copyright years.
Signed-off-by: Abhishek Sahu <absahu@codeaurora.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

In case we receive NACK on DATA we shouldn't be resetting the controller,
rather we should issue STOP command. This will terminate the current
transaction and -EIO is returned.

While at that handle the SMBus Quick Command properly.
We shouldn't be setting the XLP9XX_I2C_CMD_READ/WRITE for such
transactions.
Signed-off-by: George Cherian <george.cherian@cavium.com>
Reviewed-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

I2C bus enters the STOP condition after the DATA_DONE interrupt is raised.
Essentially the driver should be checking the bus state before sending
any transaction. In case a transaction is initiated while the
bus is busy, the prior transaction's stop condition is not achieved.
Add the check to make sure the bus is not busy before every transaction.
Signed-off-by: George Cherian <george.cherian@cavium.com>
Reviewed-by: Jan Glauber <jglauber@cavium.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The hardware may not support SDA hold time configuration, but if it is
not set in the Device Tree either, there is no need to print a warning.
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Alexander Monakov <amonakov@ispras.ru>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Free Electrons is now Bootlin, change my email address accordingly
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The errata FE-8471889 description has been updated. There is still a
timing violation for repeated start. But the errata now states that it
was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz)
there is no issue.

This patch limit the errata fix to the Standard mode.

It has been tesed successfully on the clearfog (Aramda 388 based board).
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Suspend functions seem to have been copied from i2c-cadence driver.
Rename the functions to match the rest of the driver.
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

"These patches verify the device id of the PCA984x mux chips using
standardized (but rarely implemented) i2c device identification."

Make sure to not disallow the chips on adapters that are not capable
of reading the device id, but also make sure to check the device id
before writing to the chip.
Tested-by: Adrian Fiergolski <adrian.fiergolski@cern.ch>
Signed-off-by: Peter Rosin <peda@axentia.se>

Can be used during probe to double check that the probed device is
what is expected.

Loosely based on code from Adrian Fiergolski <adrian.fiergolski@cern.ch>.
Tested-by: Adrian Fiergolski <adrian.fiergolski@cern.ch>
Reviewed-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Peter Rosin <peda@axentia.se>

The buses should honor the firmware interface used to register the device,
but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
devices registered via OF.

This means that user-space will never get an OF stype uevent MODALIAS even
when the drivers modules contain aliases exported from both the I2C and OF
device ID tables. For example, an Atmel maXTouch Touchscreen registered by
a DT node with compatible "atmel,maxtouch" has the following module alias:

$ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
i2c:maxtouch

So udev won't be able to auto-load a module for an OF-only device driver.
Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
table only has a workaround for how the I2C core reports the module alias.

This patch changes the I2C core to report an OF related MODALIAS uevent if
the device was registered via OF. So for the previous example, after this
patch, the reported MODALIAS for the Atmel maXTouch will be the following:

$ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
of:NtrackpadT<NULL>Catmel,maxtouch

NOTE: This patch may break out-of-tree drivers that were relying on this
      behavior, and only had an I2C device ID table even when the device
      was registered via OF. There are no remaining drivers in mainline
      that do this, but out-of-tree drivers have to be fixed and define
      a proper OF device ID table to have module auto-loading working.
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Tested-by: Dmitry Mastykin <mastichi@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

ACPI_ERROR and ACPI_DEBUG_PRINT are not intended to be used by device
drivers. Use acpi_handle message logging functions instead.

As a nice side effect, it removes the following compiler warnings
which were printed when ACPI debug is disabled:

drivers/i2c/busses/i2c-scmi.c: In function "acpi_smbus_cmi_add_cap":
drivers/i2c/busses/i2c-scmi.c:328:39: warning: suggest braces around empty body in an "else" statement [-Wempty-body]
drivers/i2c/busses/i2c-scmi.c:338:12: warning: suggest braces around empty body in an "else" statement [-Wempty-body]
Suggested-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Accesses to SB800_PIIX4_SMB_IDX can occur from multiple drivers.
One example for another driver is the sp5100_tco driver.

Use request_muxed_region() to ensure synchronization.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The piix4 i2c driver is extremely slow. Replacing msleep()
with usleep_range() increases its speed substantially.
Use sleep ranges similar to those used in the i2c-801 driver
to keep things simple.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Use Kernel coding style for better readability.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Peter Rosin <peda@axentia.se>

Document support for the IIC Bus Interface for DVFS (IIC for DVFS) in
the Renesas M3-N (r8a77965) SoC.

No driver update is needed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The pointer reg is assigned a value that is never read, it is later
overwritten with a new value, hence the redundant initialization can
be removed.

Cleans up clang warning:
drivers/i2c/busses/i2c-stm32f4.c:352:16: warning: Value stored to 'reg'
during its initialization is never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

HSI2C_MASTER_ST_LOSE state is not documented properly, extensive tests
show that hardware is usually able to recover from this state without
interrupting the transfer. Moreover documentation says that
such state can be caused by slave clock stretching, and should not be
treated as an error during transaction. The only place it indicates
an error is just before starting transaction. In such case bus recovery
procedure should be performed - master should pulse SCL line nine times
and then send STOP condition, it can be repeated until SDA goes high.
The procedure can be performed using manual commands HSI2C_CMD_READ_DATA
and HSI2C_CMD_SEND_STOP.
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

In case of transaction with I2C_M_RECV_LEN set, make sure the driver reads
the first byte and then updates the RX fifo with the expected length. Set
threshold to 1 byte so that driver gets an interrupt on receiving the first byte.
After which the transfer length is updated depending on the received length.
Also report SMBus block read functionality.
Signed-off-by: George Cherian <george.cherian@cavium.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Fix the driver violation of the common practice to return
ENXIO error on a slave address NACK.
Signed-off-by: Dmitry Bazhenov <dmitry.bazhenov@auriga.com>
Signed-off-by: George Cherian <george.cherian@cavium.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

R-Car D3 (R8A77995) SoC has a R-Car Gen3-compatible I2C controller.
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

of_get_property() is a bit cumbersome to use. Replace it with the newer
of_property_read_u32() for more readable code.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

The very same check is done when calling i2c_new_device(). Remove it
here to avoid code duplication.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

'result' is mostly used in the kernel as int for functions returning
errno on failure. Here it is a pointer to the client struct, so let's
call it this way (as the parent function does, too).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

When debugging a ref counting problem, I overlooked this snipplet a few
times. Might be taste, but I think the new location is visually easier
recognizable.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

If we cannot create a device, this is an error, not a warning. Fix the
log level.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

Pull Xtensa fixes from Max Filippov:
 "Two fixes for reserved memory/DMA buffers allocation in high memory on
  xtensa architecture

   - fix memory accounting when reserved memory is in high memory region

   - fix DMA allocation from high memory"

* tag 'xtensa-20180225' of git://github.com/jcmvbkbc/linux-xtensa:
  xtensa: support DMA buffers in high memory
  xtensa: fix high memory/reserved memory collision

Pull x86 fixes from Thomas Gleixner:
 "A small set of fixes:

   - UAPI data type correction for hyperv

   - correct the cpu cores field in /proc/cpuinfo on CPU hotplug

   - return proper error code in the resctrl file system failure path to
     avoid silent subsequent failures

   - correct a subtle accounting issue in the new vector allocation code
     which went unnoticed for a while and caused suspend/resume
     failures"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/topology: Update the 'cpu cores' field in /proc/cpuinfo correctly across CPU hotplug operations
  x86/topology: Fix function name in documentation
  x86/intel_rdt: Fix incorrect returned value when creating rdgroup sub-directory in resctrl file system
  x86/apic/vector: Handle vector release on CPU unplug correctly
  genirq/matrix: Handle CPU offlining proper
  x86/headers/UAPI: Use __u64 instead of u64 in <uapi/asm/hyperv.h>

Pull perf fix from Thomas Gleixner:
 "A single commit which shuts up a bogus GCC-8 warning"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/oprofile: Fix bogus GCC-8 warning in nmi_setup()

Pull locking fixes from Thomas Gleixner:
 "Three patches to fix memory ordering issues on ALPHA and a comment to
  clarify the usage scope of a mutex internal function"

* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  locking/xchg/alpha: Fix xchg() and cmpxchg() memory ordering bugs
  locking/xchg/alpha: Clean up barrier usage by using smp_mb() in place of __ASM__MB
  locking/xchg/alpha: Add unconditional memory barrier to cmpxchg()
  locking/mutex: Add comment to __mutex_owner() to deter usage