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>
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>
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>
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>
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>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
Add code to look for a reset manager property. Specifically, look for the
reset-names of 'i2c'. A reset property is an optional feature, so only print
out a warning and do not fail if a reset property is not present.
If a reset property is discovered, then use it to deassert, thus bringing the
IP out of reset.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Allow sending restart conditions upon direction change as this is
required by some chips.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denxx.de>
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Make sure the driver writes the cmd_data register only once per
read transfer instead of doing so potentially repeatedly.
In case the read transfer didn't finish quickly enough, the loop
in the driver code would spin fast enough to write the same value
into the cmd_data register again before re-checking whether the
transfer completed, which would cause another spurious read transfer
on the bus.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
Cc: Chin Liang See <clsee@altera.com>
Some platforms don't implement the enable status register at offset 0x9c.
The SPEAr600 platform is one of them. The recently added check to this
status register can't be performend on these platforms.
This patch introduces a new config option that can be enabled on such
platforms not supporting this register.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
This patch adds support for the PCI(e) based I2C cores. Which can be
found for example on the Intel Bay Trail SoC. It has 7 I2C controllers
implemented as PCI devices.
This patch also adds the fixed values for the timing registers for
BayTrail which are taken from the Linux designware I2C driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This patch adds DM support to the designware I2C driver. It currently
supports DM and the legacy I2C support. The legacy support should be
removed, once all platforms using it have DM enabled.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
This patch prepares the designware I2C driver for the DM conversion.
This is mainly done by removing struct i2c_adapter from the functions
that shall be used by the DM driver version as well.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Integrating set_speed() into dw_i2c_set_bus_speed() will make the
conversion to DM easier for this driver.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
dw_i2c_enable() is used to dis-/en-able the I2C controller. It makes
sense to add such a function, as the controller is dis-/en-abled
multiple times in the code. Additionally, this function now checks,
if the controller is really dis-/en-abled. This code is copied
from the Linux I2C driver version.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
In preparation for the SoCFPGA support of the designware I2C driver,
convert this driver to the common CONFIG_SYS_I2C framework.
This patch converts all users of this driver, this is:
- ST spearxxx boards
- AXS101 (ARC700 platform)
I couldn't test this patch on those boards. Only compile tested for all
spear boards. And tested on SoCFPGA.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Alexey Brodkin <abrodkin@synopsys.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin Kumar <vk.vipin@gmail.com>
Cc: Jeroen Hofstee <jeroen@myspectrum.nl>
Include the i2c header and change the non confirming
functions to do so.
Cc: Heiko Schocher <hs@denx.de>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Acked-by: Heiko Schocher <hs@denx.de>
[trini: Fix i2c_get_bus_num prototype]
Signed-off-by: Tom Rini <trini@ti.com>
As soon as all boards have their CONFIG_SYS_I2C_BASE defined in
configuration files instead of "asm/arch/hardware.h" it's safe to remove
the inclusion in question and make driver platform-independent.
Cc: Tom Rini <trini@ti.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Stefan Roese <sr@denx.de>
Cc: Vipin Kumar <vipin.kumar@st.com>
Cc: Armando Visconti <armando.visconti@st.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Enhance the DesignWare I2C driver to support address length more
than 1 byte. This enhancement is required as some I2C slave
device such as EEPROM chip might have 16 bit address byte.
Signed-off-by: Chin Liang See <clsee@altera.com>
Acked-by: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Since we agreed on legacy implementation of "eeprom_{read|write}"
(http://patchwork.ozlabs.org/patch/295825/) I had to fix/make it work
again DesignWare I2C driver for cases when 1 EEPROM IC fake I2C with
anumber of "built-in" ICs with different chip addresses.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin KUMAR <vipin.kumar@st.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
Cc: Kuo-Jung Su <dantesu@faraday-tech.com>
This delay applies to any data transfer on I2C bus.
For example 1kB data read with per-byte access (which happens if
environment is stored in I2C EEPROM) takes more than 10 seconds.
Moreover data bus driver has to care about bus state and data transfer,
but not about internal states of attached devices.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin KUMAR <vipin.kumar@st.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
As it is stated in DesignWare I2C databook: writes to IC_TAR (0x4)
register succeed only when IC_ENABLE[0] is set to 0.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Tom Rini <trini@ti.com>
cc: Armando Visconti <armando.visconti@st.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Cc: Heiko Schocher <hs@denx.de>
Cc: Vipin KUMAR <vipin.kumar@st.com>
Cc: Tom Rix <Tom.Rix@windriver.com>
Cc: Mischa Jonker <mjonker@synopsys.com>
There are three couple (hcnt/lcnt) of registers for each
speed (SS/FS/HS). The driver needs to set the proper couple
of regs according to what speed we are setting.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
In the newer versions of designware i2c IP there is the possibility
of configuring it with IC_EMPTYFIFO_HOLD_MASTER_EN=1, which basically
requires the s/w to generate the stop bit condition directly, as
the h/w will not automatically generate it when TX_FIFO is empty.
To avoid generation of an extra 0x0 byte sent as data, the
IC_STOP command must be sent along with the last IC_CMD.
This patch always writes bit[9] of ic_data_cmd even in the
older versions, assuming that it is a noop there.
Signed-off-by: Armando Visconti <armando.visconti@st.com>
i2c_probe() is changed to reinit the i2c bus upon read failure.
This is naturally the case upon i2c bus probing.
Also, some printf messages upon read failure are removed. As they
would interfere with the "i2c probe" command.
Additionally, i2c_set_bus_speed() now returns 0, so that the
"i2c speed" command can be used.
Signed-off-by: Stefan Roese <sr@denx.de>
Cc: Amit Virdi <amit.virdi@st.com>
Cc: Vipin Kumar <vipin.kumar@st.com>
The designware i2c controller must be turned off before
setting the speed in IC_CON register, as stated in the
section 6.3.1 of the dw_apb_i2c_db.pdf.
Signed-off-by: Michel Sanches <michel.sanches@st.com>
Signed-off-by: Armando Visconti <armando.visconti@st.com>
Signed-off-by: Amit Virdi <amit.virdi@st.com>
Earlier, a driver exists in the u-boot source for designware i2c interface. That
driver was specific to spear platforms. This patch implements the i2c controller
as a generic driver which can be used by multiple platforms
The driver files are now renamed to designware_i2c.c and designware_i2c.h and
these are moved into drivers/i2c folder for reusability by other
platforms
Signed-off-by: Vipin Kumar <vipin.kumar@st.com>
Signed-off-by: Amit Virdi <amit.virdi@st.com>
