I have tried latest Android O master branch where hikey960 supported with SPI2 is enabled on LS connector.
And observed that SPI2 and I2C0 speed is very very slow 1:10.
Whatever clock frequency set in dt configuration is not taking effect.
With Older master branch installer images were working fine but SPI2 support was not added.
@leo-yan and @ric96 any idea on this where installer images with clock settings?
hi, It’s the time Oreo branch is being merged into master branch, hikey960 is based on master branch and not oreo/8.0 branch. All I can say now is to expect bugs, that will eventually be flattened out and things may be differ for some time.
maybe @leo-yan or @jstultz have some more info on this.
I would recommend posting it on bugs.96boards.org
If it is a bug, it’s more likely to be solved there.
@rvmanjumce, yes could you please open an issue on bugs.96boards.org
what do you expect ? and what makes you say this is slow ?
The current i2c bus driver (i2c-designware) says:
Only standard mode at 100kHz, fast mode at 400kHz, fast mode plus at 1MHz and high speed mode at 3.4MHz are supported.
So the only possible values for “clock-frequency” in DT are 100000, 400000, 1000000 and 3400000.
Are you aligned with this ?
@Loic Yes i have raised the bug report in bugs.96boards.org.
I have tried the configuration with 400k and 1MHZ for I2C0 and measured the SCL line in Oscilloscope showing around
40HZ and also clearly visible its slow during data communication.
For SPI2 also same behavior measured SPI_CLK line its showing around 30HZ.
This issue is observed only on LS connector.
With SPI3 on HS its working as expected.
As per my understanding they have added SPI2 support on LS connector with IOMCU initialisation changes on xloader after this change only it has impacted clock speed on LS connector.
bug#512 bugs.96boards.org explained these changes.
@rvmanjumce, thanks for your detailed observation.
Issue will be discussed here; https://bugs.96boards.org/show_bug.cgi?id=578
Hi,
I also found something strange on I2C line.
I work with kernel 4.9, and android master branch.
I2C speed is set to 400kHz.
When I observe SCL/SDA signals, I can see that bytes are read one by one, separated by about 0.5 ms.
I do not understand this pause between each byte.
When I make the same integration on a DragonBoard, all the bytes are read i none shot, without delay between each bytes.
In my driver I use i2c_master_recv, with length of several bytes.
Any idea of how I could remove this delay between each byte ?
thanks in advance for your help !
Issue is root caused. Clock source configuration in xloader for i2c and spi2 are wrong. A fix is being prepared, stay tuned.
Thanks a lot Loic.
If some fix is available, I can make some tests.
Do you think it could also explain that i2c_master_recv regularly returns error 110 (connection timed out) ?
Hi, @jmg
A fix is ready now. Depending on how you update your boards, you can follow one of these:
AOSP: https://android-review.googlesource.com/#/c/device/linaro/hikey/+/489042/
General: https://github.com/96boards-hikey/tools-images-hikey960/commits/master HEAD
They are binary the same.
-Guodong
@jmg Let me know when you get a chance to verify that. Verification in our side shows good very good result.
One query regarding Android build ,If we download master AOSP branch its already updated to P.
Is there any link for Latest Android O with Hikey960 support.
No. We only target AOSP master.
Hi,
I’ve made some tests and it works much better, thank you.
However, I still see something strange.
My test consists on sending blocks of 248 bytes to my I2C device, at 400kHz. Then my device send an acknowledge thanks to an IRQ GPIO (GPIO_210) that triggs a read action.
I execute such data transfer around 1000 times.
At the beginning I can see 248 bytes blocks transferred correctly. Then my device immediately set the IRQ, but the read occurs only about 50ms after. This is VERY late and I do not understand why, as I do not have such behavior in DragonBoard for instance.
Then, after a couple of time, I can see that the 248 bytes are not transmitted anymore in one shot, but in several blocks (up to 4) separated by ~3ms. Once the latest block has been sent, my device set the IRQ line and the hikey read data after ~7ms.
jmg
@jmg,
Did you observed any crash related IRQ on kernel log ?
If yes please try below changes in /kernel/irq/manage.c
set first parameter to 0 earlier it was set to 1.
WARN(0, “Unbalanced IRQ %d wake disable\n”, irq);
