On 7/13/26 11:50 AM, Maxime Ripard wrote:
> On Thu, Jul 09, 2026 at 10:25:54PM +0300, Cristian Ciocaltea wrote:
>> 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.
>
> I'm not sure why we would need to unset them. If the driver states that
> it support HDMI 2.0, then it needs to be there, if it doesn't, then who
> cares? it's not going to be used. We can log a warning that it's
> inconsistent I guess, but there's no need to actively remove it.
I was trying to address the use case where drivers provide the scrambler
callbacks despite not supporting HDMI 2.0. If we replace the
scrambler_supported flag with a helper checking the presence of the scrambler
callbacks, then we would need to ensure the callbacks do not exist in this case.
Since we cannot/don't want to unset them, the remaining solution would be to
bail out in init().
>> 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.
>
> We can have several structures instances in that case.
Fair enough, I wasn't sure if that'd be an acceptable drawback.
Thanks,
Cristian
