Observing the crash when we add the i2c-arbitrator node in the device
tree as per the DT bindings. The issue is with the child node of
i2c-arbitrator@72 i.e., i2c@f1950000->i2c-arbitrator@72->i2c-arb, as the
arbitrator uses the uclass of mux(UCLASS_I2C_MUX) and the mux uclass driver
checks for the "reg" property using the i2c_mux_child_post_bind() function,
if it won't find the "reg" property it will return -EINVAL which is leading
to the crash.
So, add the logic to check whether the  child node has the "reg" property,
if the "reg" property exists then read the "reg" and update the channel.

https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-arb.txt

Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

Change the return value for timeout errors in i2c-designware from 1 to
-ETIMEDOUT. Returning errors as negative values is standard practice in the
u-boot, which enhances error handling consistency across the codebase.

The current behavior can lead to silent errors when functions check for
negative return values to identify errors. For example, in
`dm_i2c_reg_read` from i2c-uclass.c, a timeout results in an uninitialized
value being returned, potentially causing unexpected behavior.

Cc: Heiko Schocher <hs@denx.de>
Cc: Tom Rini <trini@konsulko.com>
Cc: Wojciech Szamocki <wojciech.szamocki@nokia.com>
Signed-off-by: Wojciech Szamocki <wojciech.szamocki@nokia.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

This removes a duplicate entry in mt_i2c_regs_v1[].

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reviewed-by: Heiko Schocher <hs@denx.de>

This adds the missing empty entry at the end of mtk_i2c_ids[].

Signed-off-by: Martin Schiller <ms@dev.tdt.de>
Reviewed-by: Heiko Schocher <hs@denx.de>

Add a Kconfig option to disable sending Stop conditions between multiple
i2c_msgs within a single xfer. Enable this config by default for ARCH_K3
platforms.

Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

Repeated Start Condition (Sr) can be used to transfer multiple i2c msgs
without sending a Stop condition (P). So far, the driver default was to
always send a Stop condition after every i2c msg.

Add support for a config option (CONFIG_SYS_I2C_OMAP24XX_REPEATED_START)
to disable sending the Stop condition by default. If this config is
enabled, Stop condition will be sent only if explicitly requested in the
msg flags OR if it is the last msg in the transfer.

Consequently, handle the Repeated Start condition (Sr) in the next msg
by not calling the wait_for_bb() check since it will simply timeout in
the absence of a stop condition (BB will be 1 until Stop is programmed)

Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

Remove __omap24_i2c_read/write() usage from omap_i2c_xfer() in favour of
the more flexible __omap24_i2c_xfer_msg().
Consequently, these are also no longer needed when DM_I2C is enabled.

New function __omap24_i2c_xfer_msg() will take care of individual read
OR write transfers with a target device. It goes through below sequence:
- Program the provided Target Chip address (OMAP_I2C_SA_REG)
- Program the provided Data len (OMAP_I2C_CNT_REG)
- Program the provided Control register flags (OMAP_I2C_CON_REG)
- Read from or Write to the provided Data buffer (OMAP_I2C_DATA_REG)

For a detailed programming guide, refer to the TRM[0] (12.1.3.4 I2C
Programming Guide).

This patch by itself should be a transparent change. However this is
needed for implementing a proper Repeated Start (Sr) functionality for
i2c_msgs.

Previous implementation for omap_i2c_xfer called __omap24_i2c_read/write
functions, with hardcoded addr=0 and alen=0 for each i2c_msg. Each of
these calls would program the registers always with a Stop bit set, not
allowing for a repeated start between i2c_msgs in the same xfer().

[0]: https://www.ti.com/lit/zip/spruj28 (TRM)

Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

Remove unused piece of code under CONFIG_I2C_REPEATED_START which does
not have any Kconfig entry at all.

Signed-off-by: Aniket Limaye <a-limaye@ti.com>
Reviewed-by: Heiko Schocher <hs@denx.de>

It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.

Signed-off-by: Tom Rini <trini@konsulko.com>

Co-developed-by: Greg Malysa <malysagreg@gmail.com>
Signed-off-by: Greg Malysa <malysagreg@gmail.com>
Co-developed-by: Ian Roberts <ian.roberts@timesys.com>
Signed-off-by: Ian Roberts <ian.roberts@timesys.com>
Co-developed-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Signed-off-by: Angelo Dureghello <angelo.dureghello@timesys.com>
Signed-off-by: Vasileios Bimpikas <vasileios.bimpikas@analog.com>
Signed-off-by: Utsav Agarwal <utsav.agarwal@analog.com>
Signed-off-by: Arturs Artamonovs <arturs.artamonovs@analog.com>
Signed-off-by: Oliver Gaskell <Oliver.Gaskell@analog.com>
Signed-off-by: Nathan Barrett-Morrison <nathan.morrison@timesys.com>
Reviewed-by: Heiko Schocher <hs@denx.de>