This adds the PCA9546 4-channel i2c bus switch.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Heiko Schocher <hs@denx.de>
Fix some errors pointed out by 'make refcheckdocs'.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Do not limit to 3 (100KHz, 400KHz, 1MHz) bus frequencies, but
instead allow for any frequency. Depending on the requested
frequency (via the clock-frequency DT entry), use the spec
data from either Standard, Fast or Fast Plus mode.
In order to do so, the driver do not use anymore spec identifier
by directly handle the requested frequency and from it retrieve
the corresponding spec data to be used for the computation
of the timing register.
Signed-off-by: Alain Volmat <alain.volmat@st.com>
Reviewed-by: Patrick DELAUNAY <patrick.delaunay@st.com>
Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Remove 'has_high_speed' config since we can check high speed support
from IC_COMP_PARAM_1 register.
Signed-off-by: Jun Chen <ptchentw@gmail.com>
Signed-off-by: Jun Chen <jun.chen@vatics.com>
To read IC_COMP_PARAM_1[3:2] to check is high speed possible,
and fall back to fast mode if not.
Signed-off-by: Jun Chen <ptchentw@gmail.com>
Signed-off-by: Jun Chen <jun.chen@vatics.com>
This adds support for clock stretching to the i2c-gpio driver. This is
accomplished by switching the GPIO used for the SCL line to an input
when it should be driven high, and polling on the SCL line value until
it goes high (indicating that the I2C slave is no longer pulling it
low).
This is enabled by default; for gpios which cannot be configured as
inputs, the i2c-gpio,scl-output-only property can be used to fall back
to the previous behavior.
Signed-off-by: Michael Auchter <michael.auchter@ni.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
This patch reworks i2c-gpio to make it easier to switch out the
implementation of the sda/scl get/set functions. This is in preparation
for a patch to conditionally implement clock stretching support.
Signed-off-by: Michael Auchter <michael.auchter@ni.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add deblock dequence for the I2C bus, needed on some devices. This sequence
is issued once, when probing the driver, and is controlled by DT property,
"i2c-gpio,deblock".
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Export the i2c_deblock_gpio_loop() so it can be used in other places in
U-Boot. In particular, this is useful in the GPIO I2C driver, which claims
the SDA/SCL GPIOs and thus prevents the i2c_deblock() implementation from
claiming the pins as GPIOs again.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Make the delay between SCL line changes and the number of SCL clock
changes configurable as a parameter of the deblock function. No
functional change.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Unfortunately a recent change adjusted the order of the checks here such
that 400MHz now shows up as fast-plus speed (1Mbps). Fix it.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: d96440d1e3 ("i2c: designware_i2c: Add support for fast-plus speed")
TPM TEE driver
Various minor sandbox video enhancements
New driver model core utility functions
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEslwAIq+Gp8wWVbYnfxc6PpAIreYFAl48iogACgkQfxc6PpAI
reaVzAf/an3/yKe6r3CVWlcRV6H/dVg1ApnnLpX7jS0p0b++oCVvOiy7z1WPXj3k
b1SSgENDeeZ/8EHio+Gf7ZidH/TGEj7L6YEFwd1t60GMkZiWEkNf4Z53tw482YG+
96hoPD+ySTW+ddIdVHWAFG2I4aEiKHANJAp/ItNdD+rLbrEwNQy+eiK5JTOk80B6
/X8AJCLZeAC1s7vs+2+WolgjT78QGzA9HHalMiublcqh0ivKKk0QeQiOKKPe8JYJ
om5YY1TxayQ60Xmo5f39/SBfzEEklxw83sU9o1tBeYzyVUpu7fQdkxiDbWdsij77
DgwLdeYQJGbN+hdSWE0gjTqyhW+lWA==
=KRoA
-----END PGP SIGNATURE-----
Merge tag 'dm-pull-6feb20' of https://gitlab.denx.de/u-boot/custodians/u-boot-dm
sandbox conversion to SDL2
TPM TEE driver
Various minor sandbox video enhancements
New driver model core utility functions
Now that we have uclass_first_device_drvdata(), use it from the I2C driver
to reduce code duplication.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
This adds DM_FLAG_PRE_RELOC flag to probe i2c driver
before relocation
Signed-off-by: Biwen Li <biwen.li@nxp.com>
Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com>
Move some of the code currently in the ofdata_to_platdata() method to
probe() so that it is not executed when generating ACPI tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
We want to be able to calculate the speed separately from actually setting
the speed, so we can generate the required ACPI tables. Split out the
calculation into its own function.
Drop the double underscore on __dw_i2c_set_bus_speed while we are here.
That is reserved for compiler internals.
Signed-off-by: Simon Glass <sjg@chromium.org>
This is used to store the speed information for a bus. We want to provide
this to ACPI so that it can tell the kernel. Move this struct to the
header file so it can be accessed by the ACPI i2c implementation being
added later.
Signed-off-by: Simon Glass <sjg@chromium.org>
Convert the obvious uses of i2c bus speeds to use the enum.
Use livetree access for code changes.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Patrick Delaunay <patrick.delaunay@st.com>
Tested-by: Patrick Delaunay <patrick.delaunay@st.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Update this driver to use the new standard enums for speed.
Note: This driver needs to move to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Update this driver to use the new standard enums for speed.
Note: This driver needs to move to driver model.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Some versions of this peripheral include a spike-suppression phase of the
bus. Add support for this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
At present the driver can end up with timing parameters which are slightly
faster than those expected. It is possible to optimise the parameters to
get the best possible result.
Create a new function to handle the timing calculation. This uses a table
of defaults for each speed mode rather than writing it in code.
The function works by calculating the 'period' of each bit on the bus in
terms of the input clock to the controller (IC_CLK). It makes sure that
the constraints are met and that the different components of that period
add up correctly.
This code was taken from coreboot which has ended up with this same
driver, but now in a much-different form.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Create a struct to hold the three timing parameters. This will make it
easier to move these calculations into a separate function in a later
patch.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Instead of passing this parameter into __dw_i2c_set_bus_speed(), pass in
the driver's private data, from which the function can obtain that
information. This allows the function to have access to the full state of
the driver.
Signed-off-by: Sicomp_param1mon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>
The i2c controller defines a few timing properties. Read these in and
store them for use by the driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
At present the driver uses an approximation for the bus clock, e.g. 166MHz
instead of 166 2/3 MHz.
This can result in small errors in the resulting I2C speed, perhaps 0.5%
or so.
Adjust the existing code to start from the accurate figure, even if later
rounding reduces this accuracy.
Update the bus speed code to work in KHz instead of MHz, which removes
most of the error.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Group these #defines into an enum to make it easier to understand the
relationship between them.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jun Chen <ptchentw@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Some SoCs support a higher speed than what is currently called 'max' in
this driver. Rename it to 'high' speed, which is the official name of the
3.4MHz speed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jun Chen <ptchentw@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
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>
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>
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>
- 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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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 2feec4eafd ("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>
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>
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>
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>
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: 622597dee4 ("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>
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>
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>
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>
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>
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(®s->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>
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>
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>
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>
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>
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>
Setting up the delay only needs to be done once; move it to
rcar_i2c_set_speed so it's done at initialization time.
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>
This patch adds support for handling arbitration lost
in case of multi master mode. When an arbitration lost
is detected, it retries for 10 times before failing.
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>
The arbitration lost interrupt was not getting cleared
while clearing interrupts. This patch fixes this by adding
arbitration lost interrupt as well during clear. This patch
also removes hardcoded value and defined a macro for it.
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>
Add support for R-Car Gen3 SoCs into the driver, which encompases
the Gen3 SoC extra timing register handling and 64bit build fixes.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
Read ICSR only once to avoid missing interrupts. This happens on R8A7791
Porter during reset, when reading the PMIC register 0x13, which may fail
sometimes because of the missed DTE interrupt.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Migrate SYS_I2C_TEGRA from headers to Kconfig
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Cc: Tom Warren <twarren@nvidia.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Cc: Peter.Chubb@data61.csiro.au
Cc: Lucas Stach <dev@lynxeye.de>
Cc: Stefan Agner <stefan.agner@toradex.com>
Cc: Alban Bedel <alban.bedel@avionic-design.de>
Cc: Allen Martin <amartin@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
At present this driver does not check whether it is able to actually
communicate with the I2C controller. It prints a timeout message but still
considers the probe to be successful.
To fix this, add some checking that the init succeeds.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
This driver is replaced by drivers/i2c/i2c-cdns.c DM based driver.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Heiko Schocher <hs@denx.de>
For !DM case busses are listed as
ZynqMP> i2c bus
Bus 0: zynq_0
Bus 1: zynq_0->PCA9544A@0x75:0
Bus 2: zynq_0->PCA9544A@0x75:1
Bus 3: zynq_0->PCA9544A@0x75:2
Bus 4: zynq_1
Bus 5: zynq_1->PCA9548@0x74:0
Bus 6: zynq_1->PCA9548@0x74:1
Bus 7: zynq_1->PCA9548@0x74:2
Bus 8: zynq_1->PCA9548@0x74:3
Bus 9: zynq_1->PCA9548@0x74:4
Bus 10: zynq_1->PCA9548@0x75:0
Bus 11: zynq_1->PCA9548@0x75:1
Bus 12: zynq_1->PCA9548@0x75:2
Bus 13: zynq_1->PCA9548@0x75:3
Bus 14: zynq_1->PCA9548@0x75:4
Bus 15: zynq_1->PCA9548@0x75:5
Bus 16: zynq_1->PCA9548@0x75:6
Bus 17: zynq_1->PCA9548@0x75:7
where is exactly describing i2c bus topology.
By moving to DM case i2c mux buses are using names from DT and because
i2c-muxes describing sub busses with the same names like i2c@0, etc it
is hard to identify which bus is where.
Linux is adding topology information to i2c-mux busses to identify them
better.
This patch is doing the same and composing bus name with topology
information.
When patch is applied with topology information on zcu102-revA.
ZynqMP> i2c bus
Bus 0: i2c@ff020000
20: gpio@20, offset len 1, flags 0
21: gpio@21, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 2: i2c@ff020000->i2c-mux@75->i2c@0
Bus 3: i2c@ff020000->i2c-mux@75->i2c@1
Bus 4: i2c@ff020000->i2c-mux@75->i2c@2
Bus 1: i2c@ff030000 (active 1)
74: i2c-mux@74, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 5: i2c@ff030000->i2c-mux@74->i2c@0 (active 5)
54: eeprom@54, offset len 1, flags 0
Bus 6: i2c@ff030000->i2c-mux@74->i2c@1
Bus 7: i2c@ff030000->i2c-mux@74->i2c@2
Bus 8: i2c@ff030000->i2c-mux@74->i2c@3
Bus 9: i2c@ff030000->i2c-mux@74->i2c@4
Bus 10: i2c@ff030000->i2c-mux@75->i2c@0
Bus 11: i2c@ff030000->i2c-mux@75->i2c@1
Bus 12: i2c@ff030000->i2c-mux@75->i2c@2
Bus 13: i2c@ff030000->i2c-mux@75->i2c@3
Bus 14: i2c@ff030000->i2c-mux@75->i2c@4
Bus 15: i2c@ff030000->i2c-mux@75->i2c@5
Bus 16: i2c@ff030000->i2c-mux@75->i2c@6
Bus 17: i2c@ff030000->i2c-mux@75->i2c@7
Behavior before the patch is applied.
ZynqMP> i2c bus
Bus 0: i2c@ff020000
20: gpio@20, offset len 1, flags 0
21: gpio@21, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 2: i2c@0
Bus 3: i2c@1
Bus 4: i2c@2
Bus 1: i2c@ff030000 (active 1)
74: i2c-mux@74, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 5: i2c@0 (active 5)
54: eeprom@54, offset len 1, flags 0
Bus 6: i2c@1
Bus 7: i2c@2
Bus 8: i2c@3
Bus 9: i2c@4
Bus 10: i2c@0
Bus 11: i2c@1
Bus 12: i2c@2
Bus 13: i2c@3
Bus 14: i2c@4
Bus 15: i2c@5
Bus 16: i2c@6
Bus 17: i2c@7
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
For i2c controllers which are missing alias in DT there is no req_seq
setup. This function is setting up proper ID based on highest found
alias ID.
On zcu102 this is the behavior when patch is applied.
ZynqMP> i2c bus
Bus 0: i2c@ff020000
20: gpio@20, offset len 1, flags 0
21: gpio@21, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 2: i2c@0
Bus 3: i2c@1
Bus 4: i2c@2
Bus 1: i2c@ff030000 (active 1)
74: i2c-mux@74, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus 5: i2c@0 (active 5)
54: eeprom@54, offset len 1, flags 0
Bus 6: i2c@1
Bus 7: i2c@2
Bus 8: i2c@3
Bus 9: i2c@4
Bus 10: i2c@0
Bus 11: i2c@1
Bus 12: i2c@2
Bus 13: i2c@3
Bus 14: i2c@4
Bus 15: i2c@5
Bus 16: i2c@6
Bus 17: i2c@7
Before this patch applied (controllers have -1 ID)
ZynqMP> i2c bus
Bus 0: i2c@ff020000
20: gpio@20, offset len 1, flags 0
21: gpio@21, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus 1: i2c@ff030000 (active 1)
74: i2c-mux@74, offset len 1, flags 0
75: i2c-mux@75, offset len 1, flags 0
Bus -1: i2c@0 (active 0)
54: eeprom@54, offset len 1, flags 0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@0
Bus -1: i2c@1
Bus -1: i2c@2
Bus -1: i2c@3
Bus -1: i2c@4
Bus -1: i2c@5
Bus -1: i2c@6
Bus -1: i2c@7
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
