Hi Jacopo,
On Fri, Jun 05, 2020 at 03:29:00PM +0200, Jacopo Mondi wrote:
On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote:
Could you kindly share the cross compilation steps for your kmsxx fork?
I usually build it on the target :)
Interesting approach. With ARM getting more and more potent, why not? :)
Just out of curiosity, have you ever tried to pull the display's HDMI cable while reading from CM2_LUT_TBL?
Ahem, not really :) Did I get you right, you mean disconnecting the HDMI cable from the board ?
Right.
At least with the out-of-tree CMM implementation [*], this sends the R-Car3 reference targets into an unrecoverable freeze, with no lockup reported by the kernel (i.e. looks like an serious HW issue).
CMM functionalities are retained between suspend/resume cycles (tested with suspend-to-idle) without requiring a re-programming of the LUT tables.
Hmm. Is this backed up by any statement in the HW User's manual? This comes in contrast with the original Renesas CMM implementation [**] which does make use of suspend (where the freeze actually happens).
Can we infer, based on your statement, that we could also get rid of the suspend callback in [**]?
As Geert (thanks) explained what I've tested with is suspend-to-idle, which retains the state of the LUT tables (and I assume other not-yet-implemented CMM features, like CLU). I recall the out-of-tree driver has suspend/resume routines but I never really tested that.
I see. JFYI, there is a flaw in the suspend handling in the out-of-tree CMM patch [*], which renders the SoC unresponsive on HDMI hotplug. The fix is currently under review. Hopefully it will make its way to [*] in the nearest future. Just to keep in mind for the moment when CMM s2ram will become a mainline feature.
[*] https://github.com/renesas-rcar/du_cmm [**] https://github.com/renesas-rcar/du_cmm/blob/c393ed49834bdbc/meta-rcar-gen3/r...