Hi Pavel,
Ok, so you have indeed confirmed my worst fear - that TI shipped a product claiming it supports suspend/resume, but for some reason they don't think that should include the LCD. Wow. That's absolutely amazing.
I'm familiar with the example you pointed to for disabling the clocks on the DSP. If I were building some custom DSP application, that would be quite useful. However since we're talking about TI's binary firmware running on the M3, it isn't really any help. You suggested using syslink/rpmsg to put the core into suspend/resume. Does the FVID2 API for talking to TI's M3 firmware provide a call I can make to suspend the firmware? As far as I can tell, the answer is "no".
Do you have any idea what's going on inside the M3 when the suspend occurs? As far as I can tell, the power domains are not being touched and the clocks are in an identical state before the suspend compared to after the resume. Any information you can provide on *why* the core stops responding to syslink requests? Does it not recover properly when the clocks are restored? Is the firmware no longer running at all on the MPU?
If I have to reload the firmware, I'm going to lose all the internal state of the M3, and hence won't be able to have the graphics pipelines pick up where they left off. It would be good to know whether this is a case where I simply need to be configuring the clocks on the VPSS driver (e.g. adding suspend/resume PM events to the VPSS driver to manage the clocks), or whether the driver would have to tear down all the internal state inside of the VPSS driver, the M3 core and the FB driver, and then be able to recreate it on resume.
Again, I am absolutely amazed that I'm expected to do this work and not some employee of TI who wrote and maintains the VPSS driver.
Devin
