Hi Tom
On 29/11/22 19:01, Tom Rini wrote:
On Tue, Nov 29, 2022 at 03:10:12PM +0300, Matwey V. Kornilov wrote:
вт, 29 нояб. 2022 г. в 09:50, Neha Malcom Francis <n-fran...@ti.com>:
EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
whether addressing is 1-byte or 2-byte. There are currently different
behaviours seen across boards as documented in commit bf6376642fe8
("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
the list, we see that there are 2-byte EEPROMs that read properly
with 1-byte addressing with no offset.
For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
earlier commit d2ab2a2bafd5 ("board: ti: common: board_detect: Fix
EEPROM read quirk for AM6 style data") tried to resolve this by running
ti_i2c_eeprom_get() twice. However this commit along with its former
commit fails on J7 platforms where EEPROM successfully return back the
header on 1-byte addressing and continues to do so until an offset is
introduced. So the second read incorrectly determines the EEPROM as
1-byte addressing.
A more generic solution is introduced here to solve
this issue: 1-byte read without offset and 1-byte read with offset. If
both passes, it follows 1-byte addressing else we proceed with 2-byte
addressing check.
Tested on J721E, J7200, DRA7xx, AM64x
I'll try to test this on the AM335x boards I have as soon as possible.
I wonder if we should re-factor this code a bit and not have a single
ti_i2c_eeprom_get but instead build for whichever sets of quirks a given
family of boards has with their EEPROMs. I really worry that we're going
to find that this change here breaks yet another different EEPROM than
before.
Yes that does make sense... considering a new behavior of EEPROM keeps
showing up. I will try refactoring the logic that way.
--
Thanking You
Neha Malcom Francis
