Hi,
on imx7ulp-evk board, I've changed hardware configuration ( Removed resistors: R41 , R43-R46, R51 and populated the resistors: R30-R35 ) to support MIPI interface and attach LCD to the board. In normal (RUN) mode, display works. I was using imx-linux-zeus Yocto release (imx-linux-zeus -m imx-5.4.70-2.3.0.xml ) and added changes in dtb for MIPI.
Using following command echo mem > /sys/power/state I've put the board in low power mode - Suspend to RAM.
After wake up from this mode ( using serial console for cortex M4 and "W" option for wake up), LCD remains off.
Is there anything else that should be done to power on the display?
Thanks in advance,
Tijana
Hello,
Your steps look correct, may I ask which changes you made to the dtb for MIPI?
Also, I would like to know if you're using the Power supply that comes with the evaluation kit?
Best regards,
Aldo.
Hi,
as suggested here (https://community.nxp.com/t5/i-MX-Processors/Getting-started-with-MCIMX7ULP-EVK-and-TFT3P5581-T/td-p... ) I'm using this file : imx7ulp-evk-mipi.dtb in following steps :
Yes I'm using power supply that comes with evaluation kit.
Best regards,
Tijana
Hi Aldo,
No, the backlight doesn't work when it wakes up.
LCD is completely off once the CA7 enters Suspend-to-RAM, and it remains off (backlight also off) when it wakes up.
Best regards,
Bogdan
Hi Aldo,
I've just double checked the resistors. I wouldn't say the resistors are causing the issue.
We have 3 different boards with MIPI modification made, and all of these boards have MIPI working on boot. The problem exists only after waking from Suspend-to-RAM (waking from freeze or standby doesn't cause any issue). I have also checked resistor 207. I don't see any problem there.
The board I am using have MCIMX7ULP-EVK REV B1 printed on PCB and at the back there's a sticker saying SCH-29164 REV B1.
It looks like a software issue to me?
Hello,
This indeed seems like a sw issue, I'm still investigating this, meanwhile could you help me doing a couple of measures and share them with me.
Please measure TP62 activity when entering low power mode (Suspend to RAM) and when exiting
In the same test point but now when entering/exiting any of the other 2 low power modes
BR,
Aldo.
Hi Aldo,
I am measuring 1.8V on TP62 in all states.
Unfortunately at the moment I don't have the scope to track level changes in case there are any when switching between states.
However I am sure the issue can be replicated on MCIMX7ULP-EVK REV B1. I guess you have one too?
I have checked the source of the driver and as far as I could see there's no API available to reinitialize the driver and try to get the LCD working that way?
When do you expect to have this resolved? We need this feature working in order to prepare our demo on EVK.
Thanks,
Bogdan
Hello,
I received an update from team, the issue seems to be solved in latest GA release could you try it and let me know if you still getting the same result?
https://www.nxp.com/webapp/Download?colCode=L5.10.35_2.0.0_MX7ULP1&appType=license
Thanks,
Aldo.
Ok, I tried hardknott release and it seems it is working.
However I noticed that sometimes I have to touch the LCD after the CA7 is awoken in order to see what it displays. Sometimes it just displays the content as it should.
Can you elaborate more on this behavior?
Thanks,
Bogdan
Hello,
Please check the following update from team:
"With weston/wayland Yocto rootfs. When do the suspend / resume. It need take some time to recover the weston. User can try to restart the weston when the issue happens.This is a known issue from some version after yocto upgrade the weston/wayland."
Based on this, on 5.10.35_2.0.0 standard release, I tried suspend/wakeup for 20 times. About 75% times can wakeup and restore LCD in 5 seconds, 25% times need 45 seconds to restore.
And yes, the LCD can restore every time.
So this should be an issue in weston/wayland.
Best regards,
Aldo.
Hello,
I apologize for not giving an update, this has been escalated to software team, it has been identified to work correctly using 4.19.35 release and this release wakes up with LCD resumed.
It is under investigation which patch caused this issue in later releases.
Thanks,
Aldo.