Hello Eugeniu, sorry for the late reply
On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote:
Hi Jacopo,
On Tue, Oct 15, 2019 at 12:46:13PM +0200, Jacopo Mondi wrote: ----8<---
- Testing
I have tested by injecting a color inversion LUT table and enabling/disabling it every 50 displayed frames: https://jmondi.org/cgit/kmsxx/log/?h=gamma_lut
Could you kindly share the cross compilation steps for your kmsxx fork?
I usually build it on the target :)
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 ?
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.
Thanks j
[*] https://github.com/renesas-rcar/du_cmm [**] https://github.com/renesas-rcar/du_cmm/blob/c393ed49834bdbc/meta-rcar-gen3/r...
-- Best regards, Eugeniu Rosca