On 27/06/2022 14:56, Kalyan Thota wrote:
Thanks for the comments, Dmitry. I haven't noticed mode->hdisplay being used. My idea was to run thru the topology and tie up the encoders with dspp to the CRTCs.
Since mode is available only in the commit, we cannot use the dpu_encoder_get_topology during initialization sequence.
The requirement here is that when we initialize the crtc, we need to enable drm_crtc_enable_color_mgmt only for the crtcs that support it. As I understand from Rob, chrome framework will check for the enablement in order to exercise the feature.
Do you have any ideas on how to handle this requirement ? Since we will reserve the dspp's only when a commit is issued, I guess it will be too late to enable color management by then.
I have been thinking about this for quite a while.
Basically I fear you have two options:
- Register the color management for all CRTCs. In dpu_rm_reserve() check
for the ctm, allocate LMs taking the available DSPPs into account. Fail
the atomic_check() if there are no available LMs with required
capabilities. Additional bonus point for moving LM/DSPP resource
allocation from dpu_encoder into dpu_crtc.
- Register CRTCs and it's colormanagement properties according to exact
available hardware. Let the userspace composer select the CRTC for the
connector basing on the availability of the CTM support.
I'd vote strongly against any attempt to put the policy ('e.g. enable
CTM only for the eDP and first DSI display') into the kernel, because we
can not predict the actual usecases the user needs. It well might be
that the user of the laptop will work with DP displays only and thus
require color management for DP.
@robdclark@xxxxxxxxx
Is it okay, if we disable color management for all the crtcs during initialization and enable it when we have dspps available during modeset. Can we framework code query for the property before issuing a commit for the frame after modeset ?
--
With best wishes
Dmitry
