Add support for the SMBus alert mechanism to the i2c-parport-light
driver. The ADM1032 evaluation board at least is properly wired for
this.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Trent Piepho <tpiepho@freescale.com>

Add support for the SMBus alert mechanism to the i2c-parport driver.
The ADM1032 evaluation board at least is properly wired for this.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Trent Piepho <tpiepho@freescale.com>

When the i2c-parport adapter is reponsible for powering devices, it
would seem reasonable to give them some time to settle before trying
to access them.
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The description of the delay parameter is incomplete, it suggests that
there is a direct relation between the delay value and the bus
frequency. In fact, due to additional delays in the i2c bitbanging
code, the i2c clock is always much slower.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Cc: Till Harbaum <Till@Harbaum.org>

Add the Intel Cougar Point (PCH) SMBus controller device IDs.
Signed-off-by: NSeth Heasley <seth.heasley@intel.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

The id_table field of the struct pci_driver is constant in <linux/pci.h>
so it is worth to make initialization data also constant.

The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)

// <smpl>
@r@
disable decl_init,const_decl_init;
identifier I1, I2, x;
@@
	struct I1 {
	  ...
	  const struct I2 *x;
	  ...
	};
@s@
identifier r.I1, y;
identifier r.x, E;
@@
	struct I1 y = {
	  .x = E,
	};
@c@
identifier r.I2;
identifier s.E;
@@
	const struct I2 E[] = ... ;
@depends on !c@
identifier r.I2;
identifier s.E;
@@
+	const
	struct I2 E[] = ...;
// </smpl>
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Cc: Julia Lawall <julia@diku.dk>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Signed-off-by: NRade Bozic <rade.bozic.ext@nsn.com>
Signed-off-by: NDavid Daney <ddaney@caviumnetworks.com>
Cc: Michael Lawnick <michael.lawnick.ext@nsn.com>
To: linux-mips@linux-mips.org
To: linux-i2c@vger.kernel.org
To: ben-linux@fluff.org
To: khali@linux-fr.org
Cc: rade.bozic.ext@nsn.com
Cc: Michael Lawnick <michael.lawnick.ext@nsn.com>
Patchwork: http://patchwork.linux-mips.org/patch/890/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove unnecessary includes
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

It makes them harder to grep for.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Since the drivers data now contains the i2c adapter structure, we can
pass around the drivers data between internal functions (which is what
they want) rather than using the i2c adapter structure and having an
additional pointer dereference each time.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This avoids unnecessary casting.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Acked-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

clk_set_rate() is not supposed to be used to turn clocks on and off.
That's what clk_enable/clk_disable is for.
Acked-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Acked-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Acked-by: NVitaly Wool <vitalywool@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The functionality bit vector is always returned as a little-endian
32-bit number by the device, so it must be byte-swapped to the host
endianness.

On the other hand, the delay value is handled by the USB stack, so no
byte swapping is needed on our side.

This fixes bug #15105:
http://bugzilla.kernel.org/show_bug.cgi?id=15105Reported-by: NJens Richter <jens@richter-stutensee.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Tested-by: NJens Richter <jens@richter-stutensee.de>
Cc: Till Harbaum <till@harbaum.org>
Cc: stable@kernel.org

accordingly adapt order of release_mem_region and release_mem_region on
remove.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: Wolfram Sang <w.sang@pengutronix.de>
Cc: Richard Zhao <linuxzsc@gmail.com>
Cc: Darius Augulis <augulis.darius@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: linux-i2c@vger.kernel.org
Acked-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

After generating the stop bit by changing MSTA from 1 to 0,
the i2c_imx->stopped was immediatly set to 1. The second test
on i2c_imx->stopped then is correct and the controller never
waits if the bus is busy. This patch corrects this.

On mx31moboard, stop bit was not generated on single write transfers.
This was kept unnoticed as other transfers are made afterwards that
help the write recipient to resynchronize.

Thanks to Philippe and Michael for the debugging.
Signed-off-by: NValentin Longchamp <valentin.longchamp@epfl.ch>
Signed-off by: Philippe Rétornaz <philippe.retornaz@epfl.ch>
Reported-by: NMichael Bonani <michael.bonani@epfl.ch>
Acked-by; Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Unexpected signals can disturb the bus-handling and lock it up. Don't use
interruptible in 'wait_event_*' and 'wake_*' as in commits
dc1972d0 (for cpm),
1ab082d7 (for mpc),
b7af349b (for omap).
Signed-off-by: NWolfram Sang <w.sang@pengutronix.de>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Remove the following sparse warnings (see "make C=1"):
 * drivers/i2c/busses/i2c-ali1563.c:91:3: warning: do-while statement
   is not a compound statement
 * drivers/i2c/busses/i2c-ali1563.c:161:3: warning: do-while statement
   is not a compound statement
Signed-off-by: NMárton Németh <nm127@freemail.hu>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

With `while (timeout++ < MAX_TIMEOUT)' timeout reaches MAX_TIMEOUT + 1
after the loop. This is probably unlikely to produce a problem.
Signed-off-by: NRoel Kluin <roel.kluin@gmail.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

Current OMAP3 I2C driver code does not follow the correct sequence for soft
reset. Due to this, lock up issues are reported during timeout/error cases.

This patch fixes above issue by disabling I2C controller as per OMAP3430 TRM
for soft reset. As per TRM, I2C controller needs to be disabled as a first
step during soft reset.

Here is correct soft reset sequence:
a. Ensure that the module is disabled
(clear the I2Ci.I2C_CON[15] I2C_EN bit to 0).
b. Set the I2Ci.I2C_SYSC[1] SRST bit to 1.
c. Enable the module by setting I2Ci.I2C_CON[15] I2C_EN bit to 1.
d. Check the I2Ci.I2C_SYSS[0] RDONE bit until it is set to 1 to
indicate the software reset is complete.

Tested on Zoom2, Zoom3, 3430SDP and 3630SDP
Signed-off-by: NManjunatha GK <manjugk@ti.com>
Signed-off-by: George, Harith<harith@ti.com>
Acked-by: Varadarajan, Charu Latha<charu@ti.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Commit ef871432... (i2c-omap: OMAP3: PM: (re)init for every transfer
to support off-mode) introduced a change which make the dev->iestate
contents be written to the OMAP_I2C_IE_REG every time omap_i2c_unidle
is called.  Previously, the state was only written if it wasn't equal
to zero.

In omap_i2c_probe, omap_i2c_unidle() is called prior to omap_i2c_init(),
in which case dev->iestate has not yet been initialized and will be set
to zero.  Having this value written to the registers causes deadlock
while booting.

As such, this change restores the original functionality.
Signed-off-by: NCory Maccarrone <darkstar6262@gmail.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Calculation of the CLKDIV speed setting should be done using base 10 math
rather than base 2.  We also avoid exceeding the spec due to integer
truncation and a 50% duty cycle.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NMike Frysinger <vapier@gentoo.org>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Map I2C adapter number to platform ID number
Signed-off-by: NKevin Wells <kevin.wells@nxp.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Because of OMAP off-mode, powerdomain can go off when I2C is idle.
Save enough state, and do a re-init for each transfer.

Additional save/restore state added by Jagadeesh Bhaskar Pakaravoor
(SYSC_REG) and Aaro Koskinen (wakeup sources.)

Also, The OMAP3430 TRM states:

"During active mode (I2Ci.I2C_CON[15] I2C_EN bit is set to 1), make no
changes to the I2Ci.I2C_SCLL and I2Ci.I2C_SCLH registers.  Changes may
result in unpredictable behavior."

Hence, the I2C_EN bit should be clearer when modifying these
registers. Please note that clearing the entire I2C_CON register to
disable the I2C module is safe, because the I2C_CON register is
re-configured for each transfer.
Signed-off-by: NJouni Hogander <jouni.hogander@nokia.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Cc: Jagadeesh Bhaskar Pakaravoor <j-pakaravoor@ti.com>
Cc: Aaro Koskinen <aaro.koskinen@nokia.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Hu Tao <taohu@motorola.com>
Cc: Xiaolong Chen <A21785@motorola.com>
Signed-off-by: NKevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

In the case of no-ACKs, we don't want to see dev_err() messages in the
console, because some utilities like i2c-tools are capable of printing
decorated console output.  This patch will ease such situations.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

* ABRT_MASTER_DIS: Fix a typo.

* i2c_dw_handle_tx_abort: Return an appropriate error number
  depending on abort_source.

* i2c_dw_xfer: Add a missing abort_source initialization.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Suppose TX_ABRT occurs in the middle of processing i2c_msg msgs[], and
a STOP condition has already been generated on the bus.  In this case,
subsequent i2c_dw_xfer_msg() might initiate a new and unnecessary I2C
transaction, which we'd have to avoid.

Furthermore, anytime TX_ABRT is set, the contents of tx/rx buffers are
flushed, so we don't have to process RX_FULL and TX_EMPTY.

Disable interrupts, and skip them.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Current error handling procedures are not good in two respects:

* Forgot to mark dev->cmd_complete as "completed" on errors

  Once an I2C transaction is initiated, wait_for_completion_
  interruptible_timeout() waits for dev->cmd_complete to be completed.
  We have to take care of it whenever an error is detected, otherwise
  we will have a needless HZ timeout.

* Forgot to disable interrupts

  In the previous patch, interrupt mask operations have been changed.
  We don't disable interrupts at the end of the interrupt handler any
  more, and try to keep RX_FULL (and TX_EMPTY if required) enabled
  during the transaction so that we can send longer data than the size
  of Tx/Rx FIFO.

  If an error is detected, we need to disable interrupts before
  quitting current transaction.

We can work around above points using dev->msg_err effectively.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Currently we disable TX_EMPTY interrupt when buf_len is zero, but this
is wrong.  (buf_len == 0) means that all transmit data in the current
i2c_msg message has been sent out, but that doesn't necessarily mean
all i2c_msg messages have been processed.

TX_EMPTY interrupt is used as the driving force of DW I2C transactions,
so we need to keep it enabled as long as i2c_msg messages are available.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Currently we process the first i2c_dw_xfer_msg() in i2c_dw_xfer(),
but in this case there is a possibility to be interrupted by certain
interrupts.  As described before in this patchset, we need to keep
providing new transmit data within a given time period, otherwise Tx
FIFO underrun takes place and STOP condition will be generated on the
bus, even if we have more bytes to be written.

In order to exclude all such possibilities, change TX_EMPTY interrupt
usage as below:

* DW_IC_INTR_DEFAULT_MASK: Define a default interrupt mask set, and
  put TX_EMPTY there.

* i2c_dw_xfer_init: Enable DW_IC_INTR_DEFAULT_MASK prior to initiating
  a new I2C transaction.  The first TX_EMPTY will be triggered shortly.
  With the help of it, we can make the first call to i2c_dw_xfer_msg()
  in the interrupt handler.

* i2c_dw_xfer_msg: Fixup intr_mask operation accordingly.  Make sure
  that TX_EMPTY operations need to be reversed.

* request_irq: Set IRQF_DISABLED so that we could load transmit data
  into Tx FIFO without being distracted by other interrupts.

* Remove i2c_dw_xfer_msg() in i2c_dw_xfer().
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

I2c_dw_xfer_msg() also has the same target address inconsistency check,
and furthermore it checks across all i2c_msg messages, while
i2c_dw_read() walks through i2c_msg messages only with_ I2C_M_RD flag.
That is, target address check in i2c_dw_read() is redundant and useless.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

Set proper I2C_FUNC_SMBUS_* bits so that the driver could be used with
some utilities requiring SMBus functionalities, such as i2c-tools.

Note that DW I2C core doesn't support I2C_FUNC_SMBUS_QUICK, as it's not
capable of zero-length data transactions.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>

As the driver and hardware always process the given data in parallel,
then it would be better to initialize tx_limit, rx_limit and rx_valid
variables just prior to being used.

This will help us to send / receive as much data as possible.
Signed-off-by: NShinya Kuribayashi <shinya.kuribayashi@necel.com>
Acked-by: NBaruch Siach <baruch@tkos.co.il>
Signed-off-by: NBen Dooks <ben-linux@fluff.org>