DMA is opt-in for this driver. So, we can't use deferred probing for
requesting DMA channels in probe, because our driver would get endlessly
deferred if DMA support is compiled in AND the DMA driver is missing.
Because we can't know when the DMA driver might show up, we always try
again when a DMA transfer would be possible. The downside is that there
is more overhead for setting up PIO transfers under the above scenario.
But well, having DMA enabled and the proper DMA driver missing looks
like a broken or test config anyhow.
Reported-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Refactor DMA setup to keep the errno so we can implement better
deferred probe support in the next step.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Originally, the I2C controller supported by the i2c-mv64xxx driver
requires a lot of software support: an interrupt is generated at each
step of an I2C transaction (after the start bit, after sending the
address, etc.) and the driver is in charge of re-programming the I2C
controller to do the next step of the I2C transaction. This explains
the fairly complex state machine that the driver has.

On Marvell Armada XP and later processors (Armada 375, 38x, etc.), the
I2C controller was extended with a part called the "I2C Bridge", which
allows to offload the I2C transaction completely to the
hardware. Initial support for this mechanism was added in commit
930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support").

However, the implementation done in this commit has two related
issues, which this commit fixes by completely changing how the offload
implementation is done:

 * SMBus read transfers, where there is one write to select the
   register immediately followed in the same transaction by one read,
   were making the processor hang. This was easier visible on the
   Marvell Armada XP WRT1900AC platform using a driver for an I2C LED
   controller, or on other Armada XP platforms by using a simple
   'i2cget' command to read an I2C EEPROM.

 * The implementation was based on the fact that the offload engine
   was re-programmed to transfer each message of an I2C xfer: this
   meant that each message sent with the offload engine was starting
   with a normal I2C start sequence. However, the I2C subsystem
   assumes that all messages belonging to the same xfer will use the
   so-called "repeated start" so that the entire I2C xfer is seen as
   one transfer by the I2C devices and cannot be interrupt by other
   I2C masters on the same bus.

In fact, the "I2C Bridge" allows to offload three types of xfer:

 - xfer of one write message
 - xfer of one read message
 - xfer of one write message followed by one read message

For all other situations, we have to fallback to not using the "I2C
Bridge" in order to get proper I2C semantics.

Therefore, this commit reworks the offload implementation to put it
not at the message level, but at the xfer level: in the
mv64xxx_i2c_xfer() function, we decide if the transaction can be
offloaded (in which case it is handled by the
mv64xxx_i2c_offload_xfer() function), or otherwise it is handled by
the slow path (implemented in the existing mv64xxx_i2c_execute_msg()).

This allows to simplify the state machine, which no longer needs to
have any state related to the offload implementation: the offload
implementation is now completely separated from the slow path (with
the exception of the interrupt handler, of course).

In summary:

 - mv64xxx_i2c_can_offload() will analyze an I2C xfer and decided of
   the "I2C Bridge" can be used to offload it or not.

 - mv64xxx_i2c_offload_xfer() will actually program the "I2C Bridge"
   to offload one xfer (of either one or two messages), and block
   using mv64xxx_i2c_wait_for_completion() until the xfer completes.

 - The interrupt handler mv64xxx_i2c_intr() is modified to push the
   offload related code to a separate function,
   mv64xxx_i2c_intr_offload(). It will take care of reading the
   received data if needed.

This commit was tested on:

 - Armada XP OpenBlocks AX3-4 (EEPROM on I2C and RTC on I2C)
 - Armada XP WRT1900AC (LED controller on I2C)
 - Armada XP GP (EEPROM on I2C)

Fixes: 930ab3d4 ("i2c: mv64xxx: Add I2C Transaction Generator support")
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[wsa: fixed checkpatch warnings]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We don't need the mask since we obtain the channels via DT.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The first I2C slave provider using the new generic interface.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The first user of the i2c-slave interface is an eeprom simulator. It is
a shared memory which can be accessed by the remote master via I2C and
locally via sysfs.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Finally(!), make Linux support being an I2C slave. Most of the existing
infrastructure is reused. We mainly add i2c_slave_register/unregister()
calls which tells i2c bus drivers to activate the slave mode. Then, they
also get a callback to report slave events to.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

After commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so some #ifdef blocks
depending on CONFIG_PM_RUNTIME may be dropped now.

Do that in drivers/i2c/busses/i2c-omap.c.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>

Cadence I2C controller has bug wherein it generates invalid read transactions
after timeout in master receiver mode. This driver does not use the HW
timeout and this interrupt is disabled but the feature itself cannot be
disabled. Hence, this patch writes the maximum value (0xFF) to this register.
This is one of the workarounds to this bug and it will not avoid the issue
completely but reduces the chances of error.
Signed-off-by: NVishnu Motghare <vishnum@xilinx.com>
Signed-off-by: NHarini Katakam <harinik@xilinx.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

According to I2C specification the NACK should be handled as follows:
"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not
Acknowledge signal. The master can then generate either a STOP condition to
abort the transfer, or a repeated START condition to start a new transfer."
[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf]

Currently the Davinci i2c driver interrupts the transfer on receipt of a
NACK but fails to send a STOP in some situations and so makes the bus
stuck until next I2C IP reset (idle/enable).

For example, the issue will happen during SMBus read transfer which
consists from two i2c messages write command/address and read data:

S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P
<--- write -----------------------> <--- read --------------------->

The I2C client device will send NACK if it can't recognize "Command Code"
and it's expected from I2C master to generate STP in this case.
But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will
not be generated.

Hence, fix it by generating Stop condition (STP) always when NACK is received.

This patch fixes Davinci I2C in the same way it was done for OMAP I2C
commit cda2109a ("i2c: omap: query STP always when NACK is received").
Reviewed-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reported-by: NHein Tibosch <hein_tibosch@yahoo.es>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

Switch Davinci I2C driver to use platform_get_irq(), because
it is not recommened to use platform_get_resource(pdev, IORESOURCE_IRQ, ..)
for requesting IRQ resources any more, as they can be not ready yet
in case of DT-boot.
Acked-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NGrygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

We can simply pass the pointer to the private structure to the irq
routine instead of passing the platform device and looking up its
driver_data.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The SET_PM_RUNTIME_PM_OPS() and SET_RUNTIME_PM_OPS() macros are
identical except that one of them is not empty for CONFIG_PM set,
while the other one is not empty for CONFIG_PM_RUNTIME set,
respectively.

However, after commit b2b49ccb (PM: Kconfig: Set PM_RUNTIME if
PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so one
of these macros is now redundant.

For this reason, replace SET_PM_RUNTIME_PM_OPS() with
SET_RUNTIME_PM_OPS() everywhere and redefine the SET_PM_RUNTIME_PM_OPS
symbol as SET_RUNTIME_PM_OPS in case new code is starting to use the
macro being removed here.
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add support for SCCB by implementing I2C_M_IGNORE_NAK and I2C_M_STOP
flags and advertising functionality flag I2C_FUNC_PROTOCOL_MANGLING.

Also fixed missing functionality flag I2C_FUNC_NOSTART.
Signed-off-by: NPetr Cvek <petr.cvek@tul.cz>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Commit 0f5768bf ("i2c: omap: implement workaround for handling
invalid BB-bit values") introduce the error result in boot test fault on
OMAP3530 boards.

The patch fix the error (disable i2c bus test for OMAP3530).
Reported-by: NKevin Hilman <khilman@kernel.org>
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Fixes: 0f5768bf ("i2c: omap: implement workaround for handling invalid BB-bit values")
Tested-by: NTony Lindgren <tony@atomide.com>
Tested-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

CONFIG_OF_DYNAMIC enables runtime changes to the device tree which in
turn may trigger addition or removal of devices from Linux. Add an
OF_RECONFIG notifier handler to receive tree change events and to
creating or destroy i2c devices as required.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
[grant.likely: clean up #ifdefs and drop unneeded error handling]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-i2c@vger.kernel.org

Dynamically inserting i2c client device nodes requires the use
of a single device registration method. Factor out the loop body of
of_i2c_register_devices() so that it can be called for individual
device_nodes instead of for all the children of a node.

Note: The diff of this commit looks far more complicated than it
actually is due the indentation being changed for a large block of code.
When viewed using the diff -w flag to ignore whitespace changes it can
be seen that the change is actually quite simple.
Signed-off-by: NPantelis Antoniou <pantelis.antoniou@konsulko.com>
[grant.likely: Made new function static and removed changes to header]
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Reviewed-by: NWolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: linux-i2c@vger.kernel.org

Let's handle i2c interrupt re-configuration in i2c driver. This will
help us in removing some soc specific checks from machine files and
will help in removing static iomapping of SYS register in exynos.c

Also handle saving and restoring of SYS_I2C_CFG register during
suspend and resume of i2c driver.
Signed-off-by: NPankaj Dubey <pankaj.dubey@samsung.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Now that we are using the clk notifier framework we get compile errors
without COMMON_CLK. But the driver fails to probe without COMMON_CLK
anyways, so just add that as a Kconfig dependency.
Signed-off-by: NMax Schwarz <max.schwarz@online.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

ACPI 5.0 introduces _DEP (Operation Region Dependencies) to designate
device objects that OSPM should assign a higher priority in start
ordering due to future operation region accesses.

On Asus T100TA, ACPI battery info are read from a I2C slave device via
I2C operation region. Before I2C operation region handler is installed,
battery _STA always returns 0. There is a _DEP method of designating
start order under battery device node.

This patch is to implement _DEP feature to fix battery issue on the
Asus T100TA.  Introducing acpi_dep_list and adding dep_unmet count
in struct acpi_device. During ACPI namespace scan, create struct
acpi_dep_data for a valid pair of master (device pointed to by _DEP)/
slave(device with _DEP), record master's and slave's ACPI handle in
it and put it into acpi_dep_list. The dep_unmet count will increase
by one if there is a device under its _DEP. Driver's probe() should
return EPROBE_DEFER when find dep_unmet is larger than 0. When I2C
operation region handler is installed, remove all struct acpi_dep_data
on the acpi_dep_list whose master is pointed to I2C host controller
and decrease slave's dep_unmet. When dep_unmet decreases to 0, all
_DEP conditions are met and then do acpi_bus_attach() for the device
in order to resolve battery _STA issue on the Asus T100TA.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=69011Tested-by: NJan-Michael Brummer <jan.brummer@tabos.org>
Tested-by: NAdam Williamson <adamw@happyassassin.net>
Tested-by: NMichael Shigorin <shigorin@gmail.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLan Tianyu <tianyu.lan@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

No functional changes.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Arbitration Lost is an expected situation in a multimaster
environment. I2C controller (IP) correctly detect and report AL.

The only one visible reason for resetting IP in the AL case is
to avoid advisory 1.94 (omap3) and errata i595 (omap4): "I2C:
After an Arbitration is Lost the Module Incorrectly Starts
the Next Transfer".

Errata workaround states: "The MST and STT bits inside I2C_CON
should be set to 1 at the same moment (avoid setting the MST bit
to 1 while STT = 0)." The driver never set MST and STT bits
separately and doesn't create condition for errata. So the reset
is not necessary.

Also corrected return value for AL to -EAGAIN.

Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Tested-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

In a multimaster environment, after IP software reset, BB-bit value doesn't
correspond to the current bus state. It may happen what BB-bit will be 0,
while the bus is busy due to another I2C master activity.

Any transfer started when BB=0 and bus is busy wouldn't be completed by IP
and results in controller timeout. More over, in some cases IP could
interrupt another master's transfer and corrupt data on wire.

The commit implement method allowing to prevent IP from entering into
"controller timeout" state and from "data corruption" state.

The one drawback is the need to wait for 10ms before the first transfer.

Tested on Beagleboard XM C.
Tested on BBB and AM437x Starter Kit by Felipe Balbi.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Tested-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Delete STAT_AD0 mask as unrelated to current IP (omap1?).
Delete DEBUG conditional around SYSTEST masks group.
Add SYSTEST functional mode masks for SCL and SDA.
Add STAT_BF mask.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Tested-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

The i2c input clock can change dynamically, e.g. on the RK3066 where
pclk_i2c0 and pclk_i2c1 are connected to the armclk, which changes
rate on cpu frequency scaling.

Until now, we incorrectly called clk_get_rate() while holding the
i2c->lock in rk3x_i2c_xfer() to adapt to clock rate changes.
Thanks to Huang Tao for reporting this issue.

Do it properly now using the clk notifier framework. The callback
logic was taken from i2c-cadence.c.

Also rename all misleading "i2c_rate" variables to "clk_rate", as they
describe the *input* clk rate.
Signed-off-by: NMax Schwarz <max.schwarz@online.de>
Tested-by: Doug Anderson <dianders@chromium.org> on RK3288
Reviewed-by: NDoug Anderson <dianders@chromium.org>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If dma controller is not probed, defer i2c probe.
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

commit 6d9939f6 (i2c: omap: split out [XR]DR
and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly
Set) get handled. 6d9939f6 code doesn't correspond to workaround provided by
errata.

According to errata ISR must filter out spurious RDR before data read not after.
ISR must read RXSTAT to get number of bytes available to read. Because RDR
could be set while there could no data in the receive FIFO.

Restored pre 6d9939f6 way of handling errata.

Found by code review. Real impact haven't seen.
Tested on Beagleboard XM C.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Fixes: 6d9939f6 i2c: omap: split out [XR]DR and [XR]RDY
Tested-by: NFelipe Balbi <balbi@ti.com>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Since at91sam9g45 is now DT-only, all DMA capable users of this driver
are using the DT case, and the legacy support can be removed.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

If the Designware core is configured with IC_EMPTYFIFO_HOLD_MASTER_EN
set to zero, allowing the TX FIFO to become empty causes a STOP
condition to be generated on the I2C bus. If the transmit FIFO
threshold is set too high, an erroneous STOP condition can be
generated on long transfers - particularly where the interrupt
latency is extended.
Signed-off-by: NAndrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

commit 1d7afc95 (i2c: omap: ack IRQ in parts)
changed the interrupt handler to complete transfers without clearing
XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be
fired again. As a result, ISR keep processing transfer after it was already
complete (from the driver code point of view).

A didn't see real impacts of the 1d7afc95, but it is really bad idea to
have ISR running on user data after transfer was complete.

It looks, what 1d7afc95 violate TI specs in what how AL and NACK should be
handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32).

According to specs (if I understood correctly), in case of NACK and AL driver
must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and
NACK, AL, ARDY, and XDR (Master Transmitter Mode).

All that is done down the code under the if condition:
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ...

The patch restore pre 1d7afc95 logic of handling NACK and AL interrupts, so
no interrupts is fired after ISR informs the rest of driver what transfer
complete.

Note: instead of removing break under NACK case, we could just replace 'break'
with 'continue' and allow NACK transfer to finish using ARDY event. I found
that NACK and ARDY bits usually set together. That case confirm TI wiki:
http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK

In order if someone interested in the event traces for NACK and AL cases,
I sent them to mailing list.

Tested on Beagleboard XM C.
Signed-off-by: NAlexander Kochetkov <al.kochet@gmail.com>
Fixes: 1d7afc95 i2c: omap: ack IRQ in parts
Cc: <stable@vger.kernel.org> # v3.7+
Acked-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NAaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This fixes the following kbuild test robot warning:

>> drivers/i2c/busses/i2c-dln2.c:70:1-4: WARNING: end returns can be simplified if negative or 0 value
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reported-by: NJulia Lawall <julia.lawall@lip6.fr>
Signed-off-by: NOctavian Purdila <octavian.purdila@intel.com>
Acked-by: NWolfram Sang <wsa@the-dreams.de>
Signed-off-by: NLee Jones <lee.jones@linaro.org>

It should be the DMA device, not the platform device.
Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NYao Yuan <yao.yuan@freescale.com>

The SCB is present on IMG SoCs other than the META-based TZ1090,
such as the MIPS-based Pistachio SoC.  Relax the Kconfig dependency
so that it can be built on any MIPS or META machine.
Signed-off-by: NAndrew Bresticker <abrestic@chromium.org>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This is a driver for the I2C controller found in Amlogic Meson SoCs.
Signed-off-by: NBeniamino Galvani <b.galvani@gmail.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

This makes the topology clearer. For instance, by adding a pca9547
device with address 0x70 to bus i2c-0, you get:

/sys/class/i2c-dev/i2c-0/device/0-0070/channel-0 -> i2c-1
...
/sys/class/i2c-dev/i2c-0/device/0-0070/channel-7 -> i2c-8
Signed-off-by: NGerlando Falauto <gerlando.falauto@keymile.com>
[wsa: simplified sysfs-usage and fixed format string usage]
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMartin Belanger <martin.belanger@cyaninc.com>
Acked-by: NDanielle Costantino <danielle.costantino@gmail.com>

The current implementation creates muxed i2c-<n> busses as immediate
children of their i2c-<n> parent bus. In case of multiple muxes on one
bus, it is impossible to determine which muxed bus comes from which mux.

It could be argued that the parent device should be changed from the
parent adapter to the mux device. This has pros and cons. To improve the
topology, simply add a "mux_device" symlink pointing to the actual
muxing device, so we can distinguish muxed busses. Doing it this way, we
don't break the ABI.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Tested-by: NGuenter Roeck <linux@roeck-us.net>

No need to initialize 'ret' if it gets assigned directly after that.
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>

Add dma support for i2c. This function depend on DMA driver.
You can turn on it by write both the dmas and dma-name properties in dts node.
DMA is optional, even DMA request unsuccessfully, i2c can also work well.
Signed-off-by: NYuan Yao <yao.yuan@freescale.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>