Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Signed-off-by: NJingoo Han <jg1.han@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If a process receives signal while it is waiting for I2C transfer to
complete, an error is returned to the caller and the transfer is aborted.
This can cause the driver to fail subsequent transfers. Also according to
commit d295a86e (i2c: mv64xxx: work around signals causing I2C
transactions to be aborted) I2C drivers aren't supposed to abort
transactions on signals.

To prevent this switch to use wait_for_completion_timeout() instead of
wait_for_completion_interruptible_timeout() in the designware I2C driver.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: NChristian Ruppert <christian.ruppert@abilis.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.

So remove devm_pinctrl_get_select_default() from the driver.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since commit ab78029e (drivers/pinctrl: grab default handles from device core),
we can rely on device core for handling pinctrl.

So remove devm_pinctrl_get_select_default() from the driver.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Asking for a multi-part message to be handled by this driver is racy; it
has been observed that the following sequence is possible with this
driver:

	- send start
	- send address + write
	- send data
	- send (repeated) start
	- send address + write
	- send (repeated) start
	- send address + read
	- unrecoverable bus hang (except by system reset)

The problem is that the interrupt handling sees the next event after the
first repeated start is sent - the IFLG bit is set in the register even
though INTEN is disabled.

Let's fix this by moving all of the message processing into interrupt
context, rather than having it partly in IRQ and partly in process
context.  This allows us to move immediately to the next message in the
interrupt handler and get on with the transfer, rather than incuring a
couple of scheduling switches to get the next message.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Move mv64xxx_i2c_prepare_for_io() higher up in the driver to avoid a
future forward declaration for this function.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As this driver does not advertise protocol mangling support
(I2C_FUNC_PROTOCOL_MANGLING is not set), having code to act on
I2C_M_NOSTART is illogical, and in any case isn't supportable on
anything but the first message - which makes no sense.  Remove
the I2C_M_NOSTART code.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Propagate the error code from request_irq() rather than ignoring it
entirely.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

As we're changing to using devm_* APIs to fix various problems
in this driver, lets also do devm_kzalloc() while we're here too.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This driver forgets to use clk_put().  Rather than adding clk_put(),
lets instead use devm_clk_get() to obtain this clock so that it's
automatically handled on cleanup.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Eliminate reg_base_p and reg_size, mv64xxx_i2c_unmap_regs() and an
unchecked ioremap() return from this driver by using the devm_*
API for requesting and ioremapping resources.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

mv64xxx_i2c_map_regs() already returns an error code, so lets
propagate that to mv64xxx_i2c_probe()'s caller.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NMark A. Greer <mgreer@animalcreek.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Moorestown support is removed from kernel and Medfield is supported by
i2c-designware-pci. But i2c-intel-mid is still in upstream and community
resources are wasted to maintain it.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NBarry Song <Baohua.Song@csr.com>

Do not use interruptible waits in an I2C driver; if a process uses
signals (eg, Xorg uses SIGALRM and SIGPIPE) then these signals can
cause the I2C driver to abort a transaction in progress by another
driver, which can cause that driver to fail.  I2C drivers are not
expected to abort transactions on signals.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Duplicate the feature bits documentation in modinfo, as not every user
will read the driver's source code or documentation file.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This is the same controller as on Intel Lynxpoint but the ACPI ID is
different (8086F41). Add support for this.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If the I2C bus is put to a low power state by an ACPI method it might pull
the SDA line low (as its power is removed). Once the bus is put to full
power state again, the SDA line is pulled back to high. This transition
looks like a STOP condition from the controller point-of-view which sets
STOP detected bit in its status register causing the driver to fail
subsequent transfers.

Fix this by always clearing all interrupts before we start a transfer.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c_dw_xfer_msg() pushes a number of bytes to transmit/receive
to/from the bus into the TX FIFO.
For master-rx transactions, the maximum amount of data that can be
received is calculated depending solely on TX and RX FIFO load.

This is racy - TX FIFO may contain master-rx data yet to be
processed, which will eventually land into the RX FIFO. This
data is not taken into account and the function may request more
data than the controller is actually capable of storing.

This patch ensures the driver takes into account the outstanding
master-rx data in TX FIFO to prevent RX FIFO overrun.
Signed-off-by: NJosef Ahmad <josef.ahmad@linux.intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

The TX_FIFO register is 10 bits wide.  The lower 8 bits are the data to be
written, while the upper two bits are flags to indicate stop/start.

The driver apparently attempted to optimize write access, by only writing a
byte in those cases where the stop/start bits are zero.  However, we have
seen cases where the lower byte is duplicated onto the upper byte by the
hardware, which causes inadvertent stop/starts.

This patch changes the write access to the transmit FIFO to always be 16 bits
wide.

Signed off by: Steven A. Falco <sfalco@harris.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

HZ based value is better than a magic number.
Signed-off-by: NEunbong Song <eunb.song@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

I've been debugging the abnormal operation of i2c on octeon. If a process is
terminated by signal in the middle of i2c operation, next i2c read operation
which is done by another process was failed. So i changed to ignore signal in
the middle of i2c operation. After that the problem was not reproduced.
Signed-off-by: NEunbong Song <eunb.song@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Driver core already takes care of refcounting, no need to do this on
driver level again.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Driver core already takes care of refcounting, no need to do this on
driver level again.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Driver core already takes care of refcounting, no need to do this on
driver level again.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NSekhar Nori <nsekhar@ti.com>

GENERIC_GPIO is now equivalent to GPIOLIB and features that depended on
GENERIC_GPIO can now depend on GPIOLIB to allow removal of this option.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>

Use generic DMA DT helper. Platforms booting with or without DT populated are
both supported.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Acked-by: NJean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In PIO mode we can end up with the same errors as in DMA mode, but as IRQs
are disabled there we have to check for them manually after each command.

Also don't use the big controller reset hammer when receiving a NAK from a
slave. It's sufficient to tell the controller to continue at a clean state.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Tested-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This commit fixes the three following races in PIO code:

- The CTRL0 register is racy in itself, when programming transfer state and
  run bit in the same cycle the hardware sometimes ends up using the state
  from the last transfer. Fix this by programming state in one cycle, make
  sure the write is flushed down APBX bus by reading back the reg and only
  then trigger the run bit.

- Only clear the DMAREQ bit in DEBUG0 after the read/write to the data reg
  happened. Otherwise we are racing with the hardware about who touches
  the data reg first.

- When checking for completion of a transfer it's not sufficient to check
  if the data engine finished, but also a check for i2c bus idle is needed.
  In PIO mode we are really fast to program the next transfer after a finished
  one, so the controller possibly tries to start a new transfer while the
  clkgen engine is still busy writing the NAK/STOP from the last transfer to
  the bus.
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Using autosuspend helps to reduce the resume latency in situations where
another I2C message is going to be started soon. For example with HID over
I2C touch panels we get several messages in a short period of time while
the touch panel is in use.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This is not an atomic context so there is no need to use mdelay() but
instead use usleep_range().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The correct way to disable or enable the controller is to wait until the
DW_IC_ENABLE_STATUS register bit matches the bit we program into DW_IC_ENABLE
register. This procedure is described in the DesignWare I2C databook.

By doing this we can be sure that the controller is in correct state once
the function returns.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

It is not good idea to mix static and dynamic I2C adapter numbering. In
this particular case on Lynxpoint we had graphics I2C adapter which took
the first numbers preventing the designware I2C driver from using the
adapter numbers it preferred.

Since Lynxpoint support was just introduced and there is no hardware available
outside Intel we can fix this by switching to use dynamic adapter numbering
instead of static.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This makes the error handling much more simpler than open-coding everything
and in addition makes the probe function smaller an tidier.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

With dev_err() we can get the device instance printed as well and is pretty
much standard to use dev_* macros in the drivers anyway. In addition
correct the indentation of probe() arguments.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This makes the error handling much more simpler than open-coding everything
and in addition makes the probe function smaller and tidier.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

SMBus read and write are supported by the emulation layer of i2c
framework if the controller doesn't have SMBus features.

I2C_M_RECV_LEN flag is used to let i2c drivers know rx length is not
yet determined but will be read to the first byte in rx buffer.

s3c2410 doesn't handle this flag. So only one byte is read from slave.
There fore following two features are added to the driver code.

1. skip rx length check if I2C_M_RECV_LEN is set and the length is 1.
2. add actual bytes to the rx length after reading first bytes if
   I2C_M_RECV_LEN.

I2C_M_RECV_LEN is only set for SMBus command. So this code does not
affect legacy codes which only use i2c command for s3c2410.
Signed-off-by: NJaemin Yoo <jmin.yoo@samsung.com>
Tested-by: NPrasanna Kumar <prasanna.ps@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

With the generic DMA device tree helper supported by mxs-dma driver,
client devices only need to call dma_request_slave_channel() for
requesting a DMA channel from dmaengine.
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NWolfram Sang <wsa@the-dreams.de>

The ACPI handle of struct i2c_adapter's dev member should not be
set, because this causes that struct i2c_adapter to be associated
with the ACPI device node corresponding to its parent as the
second "physical_device", which is incorrect (this happens during
the registration of struct i2c_adapter).  Consequently,
acpi_i2c_register_devices() should use the ACPI handle of the
parent of the struct i2c_adapter it is called for rather than the
struct i2c_adapter's ACPI handle (which should be NULL).

Make that happen and modify the i2c-designware-platdrv driver,
which currently is the only driver for ACPI-enumerated I2C
controller chips, not to set the ACPI handle for the
struct i2c_adapter it creates.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: NAaron Lu <aaron.lu@intel.com>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>