This new function enhances the i2c_get_chip*() toolbox by implementing a
variant that does not require a chip_addr. Instead, the desired device
is pointed to by a phandle.
Signed-off-by: Philip Richard Oberfichtner <pro@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
In SPL probing of the designware_i2c device on the StarFive VisionFive 2
board fails with
dw_i2c: mode 0, ic_clk 1000000, speed 100000,
period 10 rise 1 fall 1 tlow 5 thigh 4 spk 0
dw_i2c: bad counts. hcnt = -4 lcnt = 4
device_probe: i2c@12050000 failed to probe -22
When changing the offset for the high phase from 7 to 3 the device is
probed correctly. This now matches the value from the Linux driver.
Without this fix the memory size of the StarFive VisionFive 2 board cannot
be read from EEPROM.
Fixes: e71b6f6622 ("i2c: designware_i2c: Rewrite timing calculation")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
first version is only support standard mode.
remove this judgment to support standard/fast/fast plus mode.
Signed-off-by: Jim Liu <JJLIU0@nuvoton.com>
Changes for v2:
- add commit message
Reviewed-by: Heiko Schocher <hs@denx.de>
Allwinner seems to typically stick to a common MMIO memory map for
several SoCs, but from time to time does some breaking changes, which
also introduce new generations of some peripherals. The last time this
happened with the H6, which apart from re-organising the base addresses
also changed the clock controller significantly. We added a
CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits.
Now the Allwinner D1 changes the memory map again, and also extends the
pincontroller, among other peripherals.
To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol,
this name is reportedly used in the Allwinner BSP code, and prevents us
from inventing our own name.
Add this new symbol to some guards that were already checking for the H6
generation, since many features are shared between the two (like the
renovated clock controller).
This paves the way to introduce a first user of this generation.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code
to more easily include platform specific GPIO headers. This should not
be needed in a DM world anymore, since the generic GPIO framework
handles that nicely.
For Allwinner boards we still need to deal with non-DM GPIO in the SPL,
but this should become the exception, not the rule.
Make this more obvious by removing the definition of GPIO_EXTRA_HEADER,
and just force every legacy user of platform specific GPIO to include
the new sunxi_gpio.h header explicitly. Everyone doing so should feel
ashamed and should find a way to avoid it from now on.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Samuel Holland <samuel@sholland.org>
lib/acpi/acpigen.o is only compiled into SPL when SPL_ACPIGEN is enabled.
Update several files which reference these functions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Sandbox unit tests in U-Boot proper load a test device tree to have some
devices to work with. In order to do the same in SPL, we must enable
SPL_OF_REAL. However, we already have SPL_OF_PLATDATA enabled. When
generating platdata from a devicetree, it is expected that we will not need
devicetree access functions (even though SPL_OF_CONTROL is enabled). This
expectation does not hold for sandbox, so allow user control of
SPL_OF_REAL.
There are several places in the tree where conditions involving OF_PLATDATA
or OF_REAL no longer function correctly when both of these options can be
selected at the same time. Adjust these conditions accordingly.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This old patch was marked as deferred. Bring it back to life, to continue
towards the removal of common.h
Move this out of the common header and include it only where needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Errors were handled only if an I2C transfer timed out
and received a NACK which is very unlikely. This commit
changes the condition such that errors are handled if
an I2C transfer times out or received a NACK.
Signed-off-by: Francois Berder <fberder@outlook.fr>
Reviewed-by: Heiko Schocher <hs@denx.de>
The MVTWSI controller can act either as a master or slave device. When
acting as a master, the FSM is driven by the CPU. As a slave, the FSM is
driven by the bus directly. In what is (apparently) a safety mechanism,
if the bus transitions our FSM in any improper way, the FSM goes to a
"bus error" state (0x00). I could find no documented or experimental way
to get the FSM out of this state, except for a controller reset.
Since U-Boot only uses the MVTWSI controller as a bus master, this
feature only gets in the way: we do not care what happened on the bus
previously as long as the bus is ready for a new transaction. So, when
trying to start a new transaction, check for this state and reset the
controller if necessary.
Note that this should not be confused with the "deblocking" technique
(used by the `i2c reset` command), which involves pulsing SCL repeatedly
if SDA is found to be held low, in an attempt to force the bus back to
an idle state. This patch only resets the controller in case something
else had previously upset it, and (in principle) results in no
externally-observable change in behavior.
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Reviewed-by: Heiko Schocher <hs@denx.de>
It is not a parse error to have a default value of "0" for a "hex" type
entry, instead of "0x0". However, "0" and "0x0" are not treated the
same even by the tools themselves. Correct this by changing the default
value from "0" to "0x0" for all hex type questions that had the
incorrect default. Fix one instance (in two configs) of a default of "0"
being used on a hex question to be "0x0". Remove the cases where a
defconfig had set a value of "0x0" to be used as the default had been
"0".
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
MT7981 actually uses MediaTek I2C controller v3 instead of v1.
This patch adds support for I2C controller v3 fix fixes the I2C usability
for MT7981.
Signed-off-by: Sam Shih <sam.shih@mediatek.com>
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
As the Designware_i2c_pci.c uses ACPI APIs, If some SoCs (StarFive
JH7110) contain Designware i2c and PCI but do not use ACPI,
This file cannot be compiled. So add a new Kconfig for
designware_i2c_pci.c, which depends on ACPIGEN
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
In the current implementation, in case of I2C arbitration lost, a retry is
attempted; the message counter and pointer are reset to the original values
and the I2C xfer process is restart from the beginning.
However the message counter and message pointer are respectively
decremented and incremented by one before attempting any transfer, causing
the 1st transfer not to be actually retried (in case of a single transfer,
nothing is actually retried at all).
This patch fixes this: in case of retry, the 1st transfer is also retried.
Tested on a ZynqMP Kria board, with upstream older u-boot, but the involved
file and underlying logic seem basically the same.
Signed-off-by: Andrea Merello <andrea.merello@iit.it>
Failure can happen when i2c is used without initializing pinctrl properly,
which U-Boot happily allows in SPL. Without this fix, further I2C access would
fail, even after proper pinctrl initialization.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Cc: Heiko Schocher <hs@denx.de>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
This platform is currently unmaintained and untested, so remove it.
Further, as it is the only TI816X SoC example, remove related files as
well.
Signed-off-by: Tom Rini <trini@konsulko.com>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This driver is actually used for powerpc and m68k/ColdFire.
On ColdFire SoC's, interrupt flag get not set if IIEN flag (mbcr bit6,
interrupt enabled) is not set appropriately before each transfert.
As a result, the transfert hangs forever waiting for IIEN.
This patch set IIEN before each transfert, while considering this fix
as not harming powerpc arch.
Signed-off-by: Angelo Dureghello <angelo@kernel-space.org>
The IS_ENABLED, which does not consider SPL build, should be replaced
by CONFIG_IS_ENABLED.
For the case that we only enable DM CLK for u-boot but not in SPL, the
IS_ENABLED(CONFIG_CLK) still returns true, then cause clock failure.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Current code use dm_gpio_get_value() to get SDA and SCL value, and the
value depends on whether DTS file config the GPIO_ACTIVE_LOW. In ususal
case for i2c GPIO, DTS need to set GPIO_ACTIVE_LOW for SCL/SDA pins. So
here the logic is not correct.
And we must not use GPIOD_ACTIVE_LOW in client code include the
dm_gpio_set_dir_flags(), it is DTS's responsibility for this flag. So
remove GPIOD_ACTIVE_LOW here.
Fixes: aa54192d4a ("dm: i2c: implement gpio-based I2C deblock")
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Alexander Kochetkov <al.kochet@gmail.com <mailto:al.kochet@gmail.com>>
This code first figures out if there is an i2c,speeds property, if so
its size in u32s, and then reads the value into the local speeds[]
array. Both 'size' and 'speeds' are completely unused thereafter.
It's not at all clear what this is supposed to do. Of course, it could
be seen as a sanity check that the DT node does have an i2c,speeds
property with an appropriate number of elements, but for that one
wouldn't actually need to read it into speeds[]. Also, I can't find
anywhere else in the U-Boot code which makes use of values from that
property (this is is the only C code referencing "i2c,speeds"), so it
seems pointless to insist that it's there.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Add support for R-Car Gen4 SoCs into the driver.
While I2C on R-Car Gen4 does support some extra features (Slave Clock
Stretch Select), for now it is treated the same as I2C on R-Car Gen3,
which let us share the same driver.
Reviewed-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Signed-off-by: Hai Pham <hai.pham.ud@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> # Use RCAR_64 Kconfig
Reviewed-by: Heiko Schocher <hs@denx.de>
Sort the list of "depends" symbols in ascending order.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Sort the list of "depends" symbols in ascending order.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
At present we enable the sandbox I2C driver for all builds. Add a separate
Kconfig option to control this, so that it can be disabled in TPL, where
it is not needed.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Enable driver to fetch the optional parameter (fifo-depth) from device
tree. If the parameter is not found in the device tree, it will use
the default value declared in the driver.
Signed-off-by: Pei Yue Ho <peiyue.ho@starfivetech.com>
Reviewed-by: Wei Liang Lim <weiliang.lim@starfivetech.com>
Reviewed-by: Eng Lee Teh <englee.teh@starfivetech.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add i2c new register mode driver to support AST2600 i2c
new register mode. AST2600 i2c controller have legacy and
new register mode. The new register mode have global register
support 4 base clock for scl clock selection, and new clock
divider mode.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
Printing the I2C controller base address in decimal notation
is not helpful.
Change it to hex notation, which is the standard format found
in the Reference Manual and devicetree.
Signed-off-by: Fabio Estevam <festevam@denx.de>
Acked-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Add support for Qualcomm I2C QUP driver which is inspired from
corresponding driver in Linux: drivers/i2c/busses/i2c-qup.c.
Currently this driver only support FIFO polling mode which is sufficient
to support devices like eeprom, rtc etc.
Co-developed-by: Mike Worsfold <mworsfold@impinj.com>
Signed-off-by: Mike Worsfold <mworsfold@impinj.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
This converts 6 usages of this option to the non-SPL form, since there is
no SPL_IMX_MODULE_FUSE defined in Kconfig
Signed-off-by: Simon Glass <sjg@chromium.org>
At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This driver is used on both m68k, where CONFIG_SYS_IMMR is not used, and
PowerPC an ARM where it is. Abstract this to a new value rather than
re-defining a CONFIG symbol on m68k.
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove some CONFIG symbols and related comments, etc, that are unused
within the code itself at this point.
Signed-off-by: Tom Rini <trini@konsulko.com>
The uniphier i2c block can recognize some handshake errors.
But driver handles all error detections as no error if no timeout.
So this makes unrecoverable state.
This replaces the return values with the right ones to tell the i2c
framework the errors:
- EDEADLK for arbitration lost error
- ENODATA for no answer error
Signed-off-by: Dai Okamura <okamura.dai@socionext.com>
Acked-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
When the ti814x_evm config was removed most, but not all, of the
relevant support code was remove. Get rid of what was missed.
Fixes: 50b5326868 ("ti814x: Remove platform")
Signed-off-by: Tom Rini <trini@konsulko.com>
This functionality is part of the legacy I2C subsystem and is currently
unused anywhere. Remove the remaining references.
Signed-off-by: Tom Rini <trini@konsulko.com>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS namespace do
not easily transition to Kconfig. In many cases they likely should come
from the device tree instead. Move these out of CONFIG namespace and in
to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NUM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add newline at the end of the printed string.
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>
