[OpenWrt-Devel] ipq40xx: backport I2C QUP changes from 4.17

[Christian Lamparter]

Hello Piotr,

On Monday, March 4, 2019 9:28:51 PM CET Piotr Dymacz wrote:
> 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 [1].
> >> 
> >> I have patch ready in my staging tree [2] 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.
> >> 
> >> [1] https://do-db2.lkml.org/lkml/2018/3/12/432
> >> [2] 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"
Ok, never seen these on the MR33. But I do remember seeing something
like these back in the 4.8-days with the SPI chip on the RT-AC58U.

> 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.

I installed a new image with the patch onto the MR33

[    0.000000] Linux version 4.14.103 (gcc version 7.4.0 (OpenWrt GCC 7.4.0 r9032+5-eba905dd0c)) #0 SMP Tue Mar 5 17:14:52 2019
[...]
[    1.331193] i2c /dev entries driver
[    1.331456] i2c_qup 78b7000.i2c: using default clock-frequency 100000
[    1.334699] at24 0-0050: 8192 byte 24c64 EEPROM, read-only, 0 bytes/write
[    1.340328] i2c_qup 78b8000.i2c: using default clock-frequency 100000
[    1.410398] lp5562 1-0030: internal clock used

No surprises.

Tested-by: Christian Lamparter <chunkeey at gmail.com>



_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel