summaryrefslogtreecommitdiff
path: root/drivers/i2c
AgeCommit message (Collapse)Author
2020-01-27i2c: designware_i2c: Include clk.h in the header fileSimon Glass
We use struct clk here so really should include this header file to avoid build errors. Also switch the order of clk.h in the C file to match the required code style. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Don't allow changing IC_CLKSimon Glass
If a different input clock is required then the correct way to do this is with a clock driver. Don't allow boards to override IC_CLK. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de>
2020-01-27i2c: designware_i2c: Add more registersSimon Glass
Some versions of this peripherals provide more control of the bus behaviour. Add definitions for these registers. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ley Foon Tan <ley.foon.tan@intel.com> Reviewed-by: Jun Chen <ptchentw@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-12-18Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-x86 ↵Tom Rini
into next - Various x86 common codes updated for TPL/SPL - I2C designware driver updated for PCI - ICH SPI driver updated to support Apollo Lake - Add Intel FSP2 base support - Intel Apollo Lake platform specific drivers support - Add a new board Google Chromebook Coral
2019-12-17i2c: add support for offset overflow in to addressRobert Beckett
Some devices (2 wire eeproms for example) use some bits from the chip address to represent the high bits of the offset instead of or as well as using multiple bytes for the offset, effectively stealing chip addresses on the bus. Add a chip offset mask that can be set for any i2c chip which gets filled with the offset overflow during offset setup. Signed-off-by: Robert Beckett <bob.beckett@collabora.com> Signed-off-by: Ian Ray <ian.ray@ge.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-12-15i2c: designware: Add Apollo Lake supportSimon Glass
For Apollo Lake we need to take the I2C bus controller out of reset before using this. Add this functionality to the driver. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Support use in SPLSimon Glass
Allow this driver to set up an IO address in SPL using an 'early-regs' property. This allows SPL to use the I2C driver without having to enable the full PCI stack. Also split out ofdata_to_platdata in designware driver since this is more correct, and more convenient for the new logic. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Avoid using static dataSimon Glass
Drivers are not allowed to use static data since they may be used in SPL where BSS is not available. It is possible that driver model may provide support for numbering devices in the future. But for now, move this to global_data. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15i2c: designware: Tidy up PCI supportSimon Glass
This is hacked into the driver at present. It seems better to have it as a separate driver that uses the base driver. Create a new file and put the X86 code into it. Actually the Baytrail settings should really come from the device tree. Note that 'has_max_speed' is added as well. This is currently always false but since only Baytrail provides the config, it does not affect operation for other devices. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-15dm: gpio: Allow control of GPIO uclass in SPLSimon Glass
At present if CONFIG_SPL_GPIO_SUPPORT is enabled then the GPIO uclass is included in SPL/TPL without any control for boards. Some boards may want to disable this to reduce code size where GPIOs are not needed in SPL or TPL. Add a new Kconfig option to permit this. Default it to 'y' so that existing boards work correctly. Change existing uses of CONFIG_DM_GPIO to CONFIG_IS_ENABLED(DM_GPIO) to preserve the current behaviour. Also update the 74x164 GPIO driver since it cannot build with SPL. This allows us to remove the hacks in config_uncmd_spl.h and Makefile.uncmd_spl (eventually those files should be removed). Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
2019-12-11i2c: i2c_cdns: fix write timeout on fifo boundaryMichael Auchter
This fixes an issue that would cause I2C writes to timeout when the number of bytes is a multiple of the FIFO depth (i.e. 16 bytes). Within the transfer loop, after writing the data register with a new byte to transfer, if the transfer size equals the FIFO depth, the loop pauses until the INTERRUPT_COMP bit asserts to indicate data has been sent. This same check is performed after the loop as well to ensure data has been transferred prior to returning. In the case where the amount of data to be written is a multiple of the FIFO depth, the transfer loop would wait for the INTERRUPT_COMP bit to assert after writing the final byte, and then wait for this bit to assert once more. However, since the transfer has finished at this point, no new data has been written to the data register, and hence INTERRUPT_COMP will never assert. Fix this by only waiting for INTERRUPT_COMP in the transfer loop if there's still data to be written. Signed-off-by: Michael Auchter <michael.auchter@ni.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2019-12-02common: Move some time functions out of common.hSimon Glass
These functions belong in time.h so move them over and add comments. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2019-11-23rockchip: i2c: don't sent stop bit after each messageVasily Khoruzhick
That's not correct and it breaks SMBUS-style reads and and writes for some chips (e.g. SYR82X/SYR83X). Stop bit should be sent only after the last message. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
2019-10-14i2c: imx_lpi2c: add ipg clkPeng Fan
The controller needs two clk, per clk and ipg clk, so let's add ipg clk. Signed-off-by: Peng Fan <peng.fan@nxp.com>
2019-09-02i2c: mxc: add CONFIG_CLK supportPeng Fan
When CONFIG_CLK enabled, use CLK UCLASS for clk related settings. Signed-off-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> hs: removed hunk in mxc_i2c_probe() as not longer in code
2019-08-27i2c: mxc_i2c: Remove i2c_idle_bus from probeYe Li
i2c_idle_bus is already used in i2c_init_transfer. So before each transfer if the bus is not ready, the i2c_idle_bus will be used to force idle. It is unnecessary to call it again in probe. We found a issue when enabling i2c mux with the mxc_i2c. The mxc_i2c is probed after mux probing. However, at this moment the mux is still in idle state not select any port. So if we call i2c_idle_bus in probe, it will fail and cause mxc_i2c probe failed. Signed-off-by: Ye Li <ye.li@nxp.com>
2019-08-27i2c-mux-gpio: Fix GPIO request flag issueYe Li
When requesting GPIO, the GPIOD_IS_OUT is missed in flag, so the GPIO is set the input mode not output and cause mux not work. Signed-off-by: Ye Li <ye.li@nxp.com>
2019-08-22drivers: i2c: mxc: Fix compiler error when using i2c dm modeChuanhua Han
I2C dm mode enablemenet causes below compilation errors: In file included from include/config.h:8:0, from include/common.h:20: include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used" # error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used" ^~~~~ In file included from include/config.h:8:0, from include/common.h:20: include/config_fallbacks.h:51:4: error: #error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used" # error "Cannot define CONFIG_SYS_I2C when CONFIG_DM_I2C is used" ^~~~~ board/freescale/lx2160a/lx2160a.c: In function 'board_early_init_f': board/freescale/lx2160a/lx2160a.c:108:2: warning: implicit declaration of function 'i2c_early_init_f'; did you mean 'arch_early_init_r'? [-Wimplicit-function-declaration] i2c_early_init_f(); ^~~~~~~~~~~~~~~~ arch_early_init_r drivers/i2c/mxc_i2c.c: In function 'mxc_i2c_probe': drivers/i2c/mxc_i2c.c:824:8: warning: implicit declaration of function 'enable_i2c_clk'; did you mean 'enable_irq_wake'? [-Wimplicit-function-declaration] ret = enable_i2c_clk(1, bus->seq); ^~~~~~~~~~~~~~ enable_irq_wake So fix these compilation errors. Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
2019-07-29i2c: remove i2c driver-model compatibility layerBartosz Golaszewski
There are no more users of the compatibility layer for i2c. Remove the driver and all references to it. Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Acked-by: Heiko Schocher <hs@denx.de>
2019-07-17i2c: omap24xx_i2c: Adapt driver to support K3 devicesVignesh R
K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be compiled for ARCH_K3. Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
2019-07-12i2c: stm32f7_i2c: Fix warnings when compiling with W=1Patrick Delaunay
This patch solves the following warnings: drivers/i2c/stm32f7_i2c.c: In function 'stm32_i2c_compute_solutions': warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (scldel < scldel_min) ^ warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (((sdadel >= sdadel_min) && ^~ warning: comparison between signed and unsigned integer expressions [-Wsign-compare] (sdadel <= sdadel_max)) && ^~ drivers/i2c/stm32f7_i2c.c: In function 'stm32_i2c_choose_solution': warning: comparison between signed and unsigned integer expressions [-Wsign-compare] if (clk_error < clk_error_prev) { ^ Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-07-09xilinx_xiic: Fix transfer initialisationMelin Tomas
Prior to starting a new transfer, conditionally wait for bus to not be busy. Reinitialise controller as otherwise operation is not stable. For reference, see linux kernel commit 9656eeebf3f1 ("i2c: Revert i2c: xiic: Do not reset controller before every transfer") hs: Fixed DOS line endings added missing '\n' Fixed git commit description style Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
2019-07-09xilinx_xiic: Fix fill tx fifo loopMelin Tomas
Comparison should be against the actual message length, not loop index. len is used for stopping while loop, pos is position in message. stop should be sent when entire message is sent, not when len and pos meet. hs: fixed DOS line endings Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
2019-07-09i2c: designware: Get clock rate from clock DMLey Foon Tan
Get clock rate from clock DM if CONFIG_CLK is enabled. Otherwise, uses IC_CLK define. Signed-off-by: Ley Foon Tan <ley.foon.tan@intel.com> Acked-by: Marek Vasut <marex@denx.de>
2019-07-09i2c: designware_i2c: Restore enable state after set speedJun Chen
Before calling __dw_i2c_set_bus_speed(), the I2C could already be set as ether enable or disable, we should restore the original setting instead of enable i2c anyway. This patch fix a bug happened in init function: __dw_i2c_init(){ /* Disable i2c */ ... __dw_i2c_set_bus_speed(i2c_base, NULL, speed); writel(slaveaddr, &i2c_base->ic_sar); /* Enable i2c */ } In this case, enable i2c inside __dw_i2c_set_bus_speed() function will cause ic_sar write fail. Signed-off-by: Jun Chen <ptchentw@gmail.com>
2019-05-23i2c: stm32f7: improve loopback in timing algorithmNicolas Le Bayon
This avoids useless loops inside the I2C timing algorithm. Actually, we support only one possible solution per prescaler value. So after finding a solution with a prescaler, the algorithm can switch directly to the next prescaler value. Signed-off-by: Nicolas Le Bayon <nicolas.le.bayon@st.com> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-23i2c: stm32f7: Fix SDADEL minimum formulaNicolas Le Bayon
It conforms with Reference Manual I2C timing section. Signed-off-by: Nicolas Le Bayon <nicolas.le.bayon@st.com> Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com> Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
2019-05-21Merge git://git.denx.de/u-boot-mpc83xxTom Rini
- Update MPC83xx platform support to current best practices, etc.
2019-05-21i2c: ihs: Improve error handlingMario Six
Improve the error handling and reporting of the IHS I2C driver. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-05-21i2c: ihs: Get rid of fpgamapMario Six
Since the IHS I2C driver want upstream, the surrounding infrastructure has changed quite a bit (notably, the fpgamap driver was replaced with a regmap driver). Update the driver to work with these changes. Signed-off-by: Mario Six <mario.six@gdsys.cc> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-05-17i2c: mxc: Hide kconfig based control in DM_I2C modeTrent Piepho
These options only apply when not using DM_I2C. When using device trees, the dt will enable and control the speeds of the I2C controller(s) and these configuration options have no effect. So disable them in DM_I2C mode. Otherwise they show up as decoys, and make it look like one is enabling I2C controllers and setting the speed when really it's doing nothing. However, a system using a SPL build will not use DM_I2C in the SPL, even if DM_I2C is enabled for the main u-boot. And so the SPL might use the kconfig based I2C speed controls while the main u-boot does not. Cc: Sriram Dash <sriram.dash@nxp.com> Cc: Priyanka Jain <priyanka.jain@nxp.com> Cc: Heiko Schocher <hs@denx.de> Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-17i2c: mxc_i2c: Fix read and read->write xfers in DM modeTrent Piepho
This is an old driver that supports both device mapped and non-mapped mode, and covers a wide range of hardware. It's hard to change without risking breaking something. I have to tried to be exceedingly detailed in this patch, so please excuse the length of the commit essay that follows. In device mapped mode the I2C xfer function does not handle plain read, and some other, transfers correctly. What it can't handle are transactions that: Start with a read, or, Have a write followed by a read, or, Have more than one read in a row. The common I2C/SMBUS read register and write register transactions always start with a write, followed by a write or a read, and then end. These work, so the bug is not apparent for most I2C slaves that only use these common xfer forms. The existing xfer loop initializes by sending the chip address in write mode after it deals with bus arbitration and master setup. When processing each message, if the next message will be a read, it sends a repeated start followed by the chip address in read mode after the current message. Obviously, this does not work if the first message is a read, as the chip is always addressed in write mode initially by i2c_init_transfer(). A write following a read does not work because the repeated start is only sent when the next message is a read. There is no logic to send it when the current message is a read and next is write. It should be sent every time the bus changes direction. The ability to use a plain read was added to this driver in commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"), but this applied only the non-DM code path. This patch fixes the DM code path. The xfer function will call i2c_init_transfer() with an alen of -1 to avoid sending the chip address. The same way the non-DM code achieves this. The xfer function's message loop will send the address and mode before each message if the bus changes direction, and on the first message. When reading data, the master hardware is one byte ahead of what we receive. I.e., reading a byte from the data register returns a byte *already received* by the master, and causes the master to start the RX of the *next* byte. Therefor, before we read the final byte of a message, we must tell the master what to do next. I add a "last" flag to i2c_read_data() to tell it if the message is to be followed by a stop or a repeated start. When last == true it acts exactly as before. The non-DM code can only create an xfer where the read, if any, is the final message of the xfer. And so the only callsite of i2c_read_data() in the non-DM code has the "last" parameter as true. Therefore, this change has no effect on the non-DM code. As all other changes are in the DM xfer function, which is not even compiled in non-DM code, I am confident that this patch has no effect on boards not using I2C_DM. This greatly reduces the range of hardware that could be affected. For DM boards, I have verified every transaction the "i2c" command can create on a scope and they are all exactly as they are supposed to be. I also tested write->read->write, which isn't possible with the i2c command, and it works as well. I didn't fix multiple reads in a row, as it's a lot more invasive and obviously no one has every wanted them since they've never worked. It didn't seem like the extra complexity was justified to support something no one uses. Cc: Nandor Han <nandor.han@ge.com> Cc: Heiko Schocher <hs@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Breno Matheus Lima <brenomatheus@gmail.com> Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-17i2c: mxc_i2c: Document how non-DM functions workTrent Piepho
It is not very clear how these work in relation to the exact I2C xfers they produce. In paticular, the address length is somewhat overloaded in the read method. Clearly document the existing behavior. Maybe this will help the next person who needs to work on this driver and not break non-DM boards. Cc: Nandor Han <nandor.han@ge.com> Cc: Heiko Schocher <hs@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <festevam@gmail.com> Cc: Breno Matheus Lima <brenomatheus@gmail.com> Signed-off-by: Trent Piepho <tpiepho@impinj.com>
2019-05-03Merge git://git.denx.de/u-boot-marvellTom Rini
- Fix in kwbimage (return code checking) (Young Xiao) - Misc updates to Turris Omnia (Marek)
2019-05-03i2c: mvtwsi: fix reading status register after interruptMarek Behún
The twsi_wait function reads the control register for interrupt flag, and if interrupt flag is present, it immediately reads status register. On our device this sometimes causes bad value being read from status register, as if the value was not yet updated. My theory is that the controller does approximately this: 1. sets interrupt flag in control register, 2. sets the value of status register, 3. causes an interrupt In U-Boot we do not use interrupts, so I think that it is possible that sometimes the status register in the twsi_wait function is read between points 1 and 2. The bug does not appear if I add a small delay before reading status register. Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i) function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status register. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Heiko Schocher <hs@denx.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: Mario Six <mario.six@gdsys.cc> Cc: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Stefan Roese <sr@denx.de>
2019-05-01rockchip: use 'arch-rockchip' as header file pathKever Yang
Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common header file path, so that we can get the correct path directly. Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2019-04-26Merge branch 'master' of git://git.denx.de/u-boot-socfpgaTom Rini
2019-04-25i2c: designware: fix reset handling on socfpga gen5Simon Goldschmidt
Using this driver on socfpga gen5 with DM_I2C enabled leads to a data abort as the 'i2c' reset property cannot be found (the gen5 dtsi does not provide reset-names). The actual bug was to check 'if (&priv->reset_ctl)', which is never false. While at it, convert the driver to use 'reset_get_bulk' instead of looking at a specific named reset and also make it release the reset on driver remove before starting the OS. Fixes: 622597dee4f6 ("i2c: designware: add reset ctrl to driver") Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-04-24Merge tag 'u-boot-amlogic-20190423' of git://git.denx.de/u-boot-amlogicTom Rini
- Add support for Amlogic p200 & p201 Reference Designs - Add Amlogic SoC information display - Add support for the Libretech-AC AML-S805X-AC board - Add Amlogic AXG reset compatible - Add I2C support for Amlogic AXG - Fix AXG PIN and BANK pinctrl definitions - Fix regmap_read_poll_timeout warning about sandbox_timer_add_offset - Add initial support for Amlogic G12A SoC and U200 board - Enable PHY_REALTEK for selected boards - Fix Khadas VIM2 README
2019-04-11i2c: muxes: pca954x: support PCA9543 I2C switchLuca Ceresoli
The PCA9543 is a 2-channel I2C switch. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-11i2c: muxes: pca954x: clarify enable fieldLuca Ceresoli
The chip_desc.enable field is used only for muxes, not for switches. Document it and remove the unused values. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Heiko Schocher <hs@denx.de> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-11i2c: muxes: pca954x: update list of supported devicesLuca Ceresoli
The Kconfig help has not been updated while adding PCA9547 and PCA9646. Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net> Acked-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher<hs@denx.de>
2019-04-11DM: I2C: Introduce 'u-boot, i2c-transaction-bytes' propertyLukasz Majewski
The 'u-boot,i2c-transaction-bytes' device tree property provides information regarding number of bytes transferred by a device in a single transaction. This change is necessary to avoid hanging devices after soft reset. One notable example is communication with MC34708 device: 1. Reset when communicating with MC34708 via I2C. 2. The u-boot (after reboot -f) tries to setup the I2C and then calls force_idle_bus. In the same time MC34708 still has some data to be sent (as it transfers data in 24 bits chunks). 3. The force_idle_bus() is not able to make the bus idle as 8 SCL clocks may be not enough to have the full transmission. 4. We end up with I2C inconsistency with MC34708. This PMIC device requires 24+ SCL cycles to make finish any pending I2C transmission. Signed-off-by: Lukasz Majewski <lukma@denx.de>
2019-04-10i2c: meson: add configurable divider factorsGuillaume La Roque
This patch add support for I2C controller in Meson-AXG SoC, Due to the IP changes between I2C controller, we need to introduce a compatible data to make the divider factor configurable. backport from linux: 931b18e92cd0 ("2c: meson: add configurable divider factors") Signed-off-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
2019-03-21i2c: i2c_cdns: Fix below warnings with checker toolSiva Durga Prasad Paladugu
This patch fixes below warnings found with checker tool. The variable len in i2c_msg struct is of unsigned type and it is received as recv_count which is unsigned type but it is checked with < 0 which is always false, hence removed it. The local variable curr_recv_count is declared as signed type and compared aginst unsigned recv_count which is incorrect. This is fixed by declaring it as unsigned type. drivers/i2c/i2c-cdns.c: In function ‘cdns_i2c_read_data’: drivers/i2c/i2c-cdns.c:317:18: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] if ((recv_count < 0)) ^ drivers/i2c/i2c-cdns.c:340:24: warning: comparison of integer expressions of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare] updatetx = recv_count > curr_recv_count; ^ drivers/i2c/i2c-cdns.c:361:39: warning: comparison of integer expressions of different signedness: ‘u32’ {aka ‘unsigned int’} and ‘int’ [-Wsign-compare] while (readl(&regs->transfer_size) != Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-03-08i2c: rcar_i2c: Move FSDA check to rcar_i2c_recoverIsmael Luceno Cortes
Cosmetic change. Any call to the recover function would need to do the same check afterwards, so it's sensible to make it part of the function. Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com>
2019-03-08i2c: rcar_i2c: Set the slave address from rcar_i2c_xferIsmael Luceno Cortes
It needs to be done for both reads and writes, so do it at rcar_i2c_xfer to avoid duplication. Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-03-08i2c: rcar_i2c: Don't mask errors with EREMOTEIO at rcar_i2c_xferIsmael Luceno Cortes
Fix rcar_i2c_xfer return value, previously it was always returning -EREMOTEIO when dealing with errors from calls to the read/write functions. Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-03-08i2c: rcar_i2c: Fix sending of slave addressesIsmael Luceno Cortes
Do the reset before clearing the MSR, otherwise it may result in a read or write operation instead if the start condition is repeated. Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>
2019-03-08i2c: rcar_i2c: Add comments about registers & valuesIsmael Luceno Cortes
Document the meaning of macros related to registers and values to be written to them. Signed-off-by: Ismael Luceno <ismael.luceno@silicon-gears.com> Reviewed-by: Marek Vasut <marek.vasut+renesas@gmail.com> Reviewed-by: Heiko Schocher <hs@denx.de>