| Age | Commit message (Collapse) | Author |
|---|
|
Convert the obvious uses of i2c bus speeds to use the enum.
Use livetree access for code changes.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Patrick Delaunay <[email protected]>
Tested-by: Patrick Delaunay <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Update this driver to use the new standard enums for speed.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Some versions of this peripheral include a spike-suppression phase of the
bus. Add support for this.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Signed-off-by: Simon Glass <[email protected]>
|
|
The i2c controller defines a few timing properties. Read these in and
store them for use by the driver.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Group these #defines into an enum to make it easier to understand the
relationship between them.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Jun Chen <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Jun Chen <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Ley Foon Tan <[email protected]>
Reviewed-by: Jun Chen <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Some versions of this peripherals provide more control of the bus
behaviour. Add definitions for these registers.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Ley Foon Tan <[email protected]>
Reviewed-by: Jun Chen <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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
|
|
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 <[email protected]>
Signed-off-by: Ian Ray <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Bin Meng <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
These functions belong in time.h so move them over and add comments.
Signed-off-by: Simon Glass <[email protected]>
Reviewed-by: Tom Rini <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
The controller needs two clk, per clk and ipg clk,
so let's add ipg clk.
Signed-off-by: Peng Fan <[email protected]>
|
|
When CONFIG_CLK enabled, use CLK UCLASS for clk related settings.
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Frieder Schrempf <[email protected]>
Tested-by: Frieder Schrempf <[email protected]>
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 <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Prabhakar Kushwaha <[email protected]>
|
|
There are no more users of the compatibility layer for i2c. Remove the
driver and all references to it.
Signed-off-by: Bartosz Golaszewski <[email protected]>
Acked-by: Heiko Schocher <[email protected]>
|
|
K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be
compiled for ARCH_K3.
Signed-off-by: Vignesh R <[email protected]>
Signed-off-by: Andreas Dannenberg <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Lokesh Vutla <[email protected]>
|
|
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 <[email protected]>
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
|
|
Get clock rate from clock DM if CONFIG_CLK is enabled.
Otherwise, uses IC_CLK define.
Signed-off-by: Ley Foon Tan <[email protected]>
Acked-by: Marek Vasut <[email protected]>
|
|
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 <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Patrick DELAUNAY <[email protected]>
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
It conforms with Reference Manual I2C timing section.
Signed-off-by: Nicolas Le Bayon <[email protected]>
Reviewed-by: Patrick DELAUNAY <[email protected]>
Signed-off-by: Patrick Delaunay <[email protected]>
|
|
- Update MPC83xx platform support to current best practices, etc.
|
|
Improve the error handling and reporting of the IHS I2C driver.
Signed-off-by: Mario Six <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
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 <[email protected]>
Cc: Priyanka Jain <[email protected]>
Cc: Heiko Schocher <[email protected]>
Signed-off-by: Trent Piepho <[email protected]>
|
|
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 <[email protected]>
Cc: Heiko Schocher <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Breno Matheus Lima <[email protected]>
Signed-off-by: Trent Piepho <[email protected]>
|
|
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 <[email protected]>
Cc: Heiko Schocher <[email protected]>
Cc: Stefano Babic <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: Breno Matheus Lima <[email protected]>
Signed-off-by: Trent Piepho <[email protected]>
|
|
- Fix in kwbimage (return code checking) (Young Xiao)
- Misc updates to Turris Omnia (Marek)
|
|
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 <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
Cc: Mario Six <[email protected]>
Cc: Baruch Siach <[email protected]>
Signed-off-by: Stefan Roese <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
