Re: [PATCH 4/7] drm/omap: Implement CTM property for CRTC using OVL managers CPR matrix

[Jyri Sarha <jsarha@ti.com>]

On 05/09/2019 13:05, Laurent Pinchart wrote:
> Hi Jyri,
> 
> On Thu, Sep 05, 2019 at 01:00:51PM +0300, Jyri Sarha wrote:
>> On 05/09/2019 00:52, Laurent Pinchart wrote:
>>>>>>>>  static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
>>>>>>>>  {
>>>>>>>>  	struct omap_drm_private *priv = crtc->dev->dev_private;
>>>>>>>> @@ -402,7 +428,16 @@ static void omap_crtc_write_crtc_properties(struct drm_crtc *crtc)
>>>>>>>>  	info.default_color = 0x000000;
>>>>>>>>  	info.trans_enabled = false;
>>>>>>>>  	info.partial_alpha_enabled = false;
>>>>>>>> -	info.cpr_enable = false;
>>>>>>>> +
>>>>>>>> +	if (crtc->state->ctm) {
>>>>>>>> +		struct drm_color_ctm *ctm =
>>>>>>>> +			(struct drm_color_ctm *) crtc->state->ctm->data;
>>>>>>>> +
>>>>>>>> +		info.cpr_enable = true;
>>>>>>>> +		omap_crtc_cpr_coefs_from_ctm(ctm, &info.cpr_coefs);
>>>>>>>
>>>>>>> As an optimisation it would be nice to only write the coefficients when
>>>>>>> they actually change. That could be implemented on top of this series.
>>>>>>
>>>>>> E.g. apply this ?
>>>>>>
>>>>>> - if (crtc->state->ctm)
>>>>>> + if (crtc->state->color_mgmt_changed && crtc->state->ctm)
>>>>>
>>>>> Something like that, but .mgr_setup() should then be taught not to write
>>>>> unchanged CTM tables to registers. Do you think it would be worth it ?
>>>>
>>>> Hmmm, jess I should do it like this:
>>>> if (crtc->state->color_mgmt_changed) {
>>>> 	if (crtc->state->ctm) {
>>>> ...
>>>>>>>> +	} else {
>>>>>>>> +		info.cpr_enable = false;
>>>>>>>> +	}
>>>> }
>>>>
>>>> This way the whole CPR functionality is turned off, if the there is no
>>>> CTM in the crtc state.
>>>
>>> Yes, but you would also need to update .mgr_setup() :-) A new
>>> color_mgmt_changed flag would be needed in the info structure too.
>>
>> I am starting to thing that such an "optimization" may not be worth the
>> added complexity. The arithmetic and writing three registers is not that
>> costly and we do not commit a new crtc state that often.
> 
> We call omap_crtc_write_crtc_properties() in omap_crtc_atomic_flush(),
> so that's at every page flip...
> 

Still, the mgr_setup() accesses five different registers even if we do
not touch CPR settings (another 4 registers). All of those have static
values in the mainline omapdrm (there are custom properties to control
those in ti-linux).

I would rather keep this patch as it is and implement another one with a
cached struct omap_overlay_manager_info, that calls mgr_setup() only if
the info values have changed.

With the cached values in place the unneeded conversion arithmetic can
also be skipped based on color_mgmt_changed.

BR,
Jyri

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel