On 7/3/26 11:54 PM, Cristian Ciocaltea wrote:
> On 7/3/26 5:34 PM, Dmitry Baryshkov wrote:
>> On Thu, Jul 02, 2026 at 05:46:17PM +0300, Cristian Ciocaltea wrote:
>>> Add the connector-level infrastructure to support HDMI 2.0 scrambling:
>>>
>>> - A scrambler_supported flag to indicate whether the source supports the
>>> scrambling capability, in which case the newly introduced
>>> .scrambler_{enable|disable}() callbacks in drm_connector_hdmi_funcs
>>> are mandatory
>>
>> Do we need a flag? What would it mean if the flag is set, but the
>> callbacks are not? Can we drop the flag and use the presence of the
>> callbacks as a way to identify that scrambler is enabled?
>
> The flag is intended to be set only within
> drmm_connector_hdmi_init_with_caps()
> when drivers advertise HDMI 2.x capability, in which case it also ensures the
> callbacks are provided.
>
> We could drop the flag and instead have the init helper clear the callbacks if
> they were provided for HDMI 1.x. This might slightly reduce code readability,
> as it relies on checking the presence of individual callbacks - especially
> since
> we plan to extend this further with HDMI 2.1 support, providing four or five
> additional FRL-specific callbacks.
I tried to replace the flag with a helper that checks the presence of (one of)
the callbacks, but it's not straightforward to unset those for non-HDMI 2.x
cases since the hdmi_funcs argument is immutable.
Also, rejecting that use case is less than ideal, since we would restrict
reusing the struct instance, e.g. to support HW revisions with varying
scrambling capabilities.
Therefore, I'd keep the flag for now.
Cristian
