[OpenWrt-Devel] ipq40xx: backport I2C QUP changes from 4.17
pepe2k at gmail.com
Mon Mar 4 15:28:51 EST 2019
On 04.03.2019 13:16, Christian Lamparter wrote:
> On Sunday, March 3, 2019 8:57:03 PM CET Piotr Dymacz wrote:
>> I'm observing various I2C related issues on ALFA Network AP120C-AC board
>> with AT97SC3205T TPM module. As there was a major update of the I2C QUP
>> driver in 4.17, I decided to backport whole series .
>> I have patch ready in my staging tree  and would like to get feedback
>> from others, using I2C on ipq40xx board, just to make sure this doesn't
>> introduce any regressions.
>> This driver is also used on ipq806x platform but AFAIK there are no
>> boards using I2C bus there.
>>  https://do-db2.lkml.org/lkml/2018/3/12/432
>>  https://git.openwrt.org/openwrt/staging/pepe2k.git
> Can you please tell us what I2C issues you observed with the
> AP120C-AC board and the Atmel/Microchip AT97SC3205T TPM chip?
> Is this something related to I2C Fast Mode or Fm+?
No, I was using only standard mode (with 100 kHz and lower clocks, to
make sure it's not related) and this TPM doesn't even support FM+.
The initial (known) issue was (TPM wasn't even detected then):
"bam-dma-engine 7884000.dma: Cannot free busy channel"
It was supposed to be fixed in: 7239872fb340 ("i2c: qup: fixed releasing
dma without flush operation completion") but it only made the problem to
occur less often/randomly, plus I started to see different 'tpm_recv'
and 'tpm_send' errors.
This TPM works without any issues on 4.19, so I decided to backport the
whole series instead of digging out and fixing exact reason.
> I have never seen any issue with the MR33's i2c-attached EEPROM
> and LED-controller. However, I guess nobody really (can) push the
> EEPROM or LED-Controller hard enough to trigger an issue.
Agree and as I don't have any other IPQ4k board with I2C bus in use, I
would be grateful for testing MR33 with updated driver.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel