<feed xmlns='http://www.w3.org/2005/Atom'>
<title>u-boot.git/drivers/i2c, branch v2023.10</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/'/>
<entry>
<title>drivers: mediatek: Fix error handling in mtk_i2c_do_transfer</title>
<updated>2023-09-22T19:54:39+00:00</updated>
<author>
<name>Francois Berder</name>
<email>fberder@outlook.fr</email>
</author>
<published>2023-09-08T16:47:46+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=8cf61051ae6e13e253de0d18501c196bc70522fc'/>
<id>8cf61051ae6e13e253de0d18501c196bc70522fc</id>
<content type='text'>
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 &lt;fberder@outlook.fr&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;fberder@outlook.fr&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: mvtwsi: reset controller if stuck in "bus error" state</title>
<updated>2023-08-15T04:52:04+00:00</updated>
<author>
<name>Sam Edwards</name>
<email>cfsworks@gmail.com</email>
</author>
<published>2023-07-25T22:13:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=250454c59b1b056d47cbb0c6d8d09a68416c9776'/>
<id>250454c59b1b056d47cbb0c6d8d09a68416c9776</id>
<content type='text'>
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 &lt;CFSworks@gmail.com&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;CFSworks@gmail.com&gt;
Reviewed-by: Stefan Roese &lt;sr@denx.de&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: mediatek: fix I2C usability for MT7981</title>
<updated>2023-08-03T13:40:49+00:00</updated>
<author>
<name>Weijie Gao</name>
<email>weijie.gao@mediatek.com</email>
</author>
<published>2023-07-19T09:16:15+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7fa40df4825766c63b9d06e3e224814d8e5f4eed'/>
<id>7fa40df4825766c63b9d06e3e224814d8e5f4eed</id>
<content type='text'>
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 &lt;sam.shih@mediatek.com&gt;
Signed-off-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;sam.shih@mediatek.com&gt;
Signed-off-by: Weijie Gao &lt;weijie.gao@mediatek.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: designware: Add Kconfig for designware_i2c_pci.c</title>
<updated>2023-08-02T03:02:32+00:00</updated>
<author>
<name>Minda Chen</name>
<email>minda.chen@starfivetech.com</email>
</author>
<published>2023-07-25T09:46:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=7eb62cb7165791a9a98a2d498f88b0ef2192f4c9'/>
<id>7eb62cb7165791a9a98a2d498f88b0ef2192f4c9</id>
<content type='text'>
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 &lt;minda.chen@starfivetech.com&gt;
Reviewed-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;minda.chen@starfivetech.com&gt;
Reviewed-by: Leo Yu-Chi Liang &lt;ycliang@andestech.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: i2c-gpio: Correctly handle new {sda, scl}-gpios bindings</title>
<updated>2023-07-31T11:50:57+00:00</updated>
<author>
<name>Chris Packham</name>
<email>judge.packham@gmail.com</email>
</author>
<published>2023-07-25T23:13:08+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=414236b887a2270d714edf3654eaa0def6315ec6'/>
<id>414236b887a2270d714edf3654eaa0def6315ec6</id>
<content type='text'>
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 &lt;judge.packham@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;judge.packham@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag v2023.07-rc4 into next</title>
<updated>2023-06-12T18:55:33+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-06-12T18:55:33+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=260d4962e06c0a7d2713523c131416a3f70d7f2c'/>
<id>260d4962e06c0a7d2713523c131416a3f70d7f2c</id>
<content type='text'>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Tom Rini &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>I2C: cdns: Fix broken retry mechanism on arbitration lost.</title>
<updated>2023-06-05T04:54:25+00:00</updated>
<author>
<name>Andrea Merello</name>
<email>andrea.merello@iit.it</email>
</author>
<published>2023-05-26T14:56:16+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=419ddf944cbf376e3c1d5b8571e82d89056bebfa'/>
<id>419ddf944cbf376e3c1d5b8571e82d89056bebfa</id>
<content type='text'>
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 &lt;andrea.merello@iit.it&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;andrea.merello@iit.it&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>i2c: rockchip: De-initialize the bus after start bit failure</title>
<updated>2023-06-05T04:52:46+00:00</updated>
<author>
<name>Ondrej Jirman</name>
<email>megi@xff.cz</email>
</author>
<published>2023-05-25T12:18:17+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=ba5b9203f55bae1ef3566a84648cad46c6949270'/>
<id>ba5b9203f55bae1ef3566a84648cad46c6949270</id>
<content type='text'>
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 &lt;megi@xff.cz&gt;
Cc: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;megi@xff.cz&gt;
Cc: Heiko Schocher &lt;hs@denx.de&gt;
Reviewed-by: Kever Yang &lt;kever.yang@rock-chips.com&gt;
Reviewed-by: Heiko Schocher &lt;hs@denx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>arm: Remove ti816x_evm board and ti816x SoC support</title>
<updated>2023-05-31T14:11:46+00:00</updated>
<author>
<name>Tom Rini</name>
<email>trini@konsulko.com</email>
</author>
<published>2023-05-11T18:07:24+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=41e289bb1f6032694900afad017320d26f411066'/>
<id>41e289bb1f6032694900afad017320d26f411066</id>
<content type='text'>
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 &lt;trini@konsulko.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;trini@konsulko.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>drivers: use dev_read_addr_ptr when cast to pointer</title>
<updated>2023-05-06T09:28:18+00:00</updated>
<author>
<name>Johan Jonker</name>
<email>jbx6244@gmail.com</email>
</author>
<published>2023-03-13T00:32:04+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.235523.xyz/u-boot.git/commit/?id=a12a73b66476c48dfe5afd2c3711153d09feda6c'/>
<id>a12a73b66476c48dfe5afd2c3711153d09feda6c</id>
<content type='text'>
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 &lt;jbx6244@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;jbx6244@gmail.com&gt;
Reviewed-by: Simon Glass &lt;sjg@chromium.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
