Cc: Ville, Imre

On Thu, 02 Jul 2026, "Liou, Mei Fan" <[email protected]> wrote:
> Rather than adding a new module parameter or DMI quirk, I would like
> to pursue your suggestion of fixing the existing video=eDP-1:d path
> (tested: not working for this case).
> May I rework that?

I had a glance.

intel_dp_init_connector() -> drm_connector_init_with_ddc() ->
drm_connector_init_and_add() -> drm_connector_init_only() ->
drm_connector_get_cmdline_mode() ->
drm_mode_parse_command_line_for_connector() ->
drm_mode_parse_cmdline_extra().

drm_mode_parse_cmdline_extra() sets mode->force.

drm_connector_get_cmdline_mode() sets connector->force if mode->force.

It's an interesting idea to use connector->force == DRM_FORCE_OFF to
bail out from eDP init in a way that cleans up the eDP connector but
doesn't fail the probe altogether. (And I think currently this happens
automatically if the PPS/AUX fail, it just takes a while.)

For other connectors we should keep it dynamic, i.e. the connector
should stay around even if forced off at probe, as the status may change
later, but eDP is kind of static. E.g. we don't try all the DPCD reads
again later.

I'm not dismissing the idea immediately, and it might work, but I'm also
not pre-emptively acking. There may be corner cases that I can't think
of right now. Maybe we need to keep the connector around but just not
try to probe it, and then leave it disconnected. Not sure.


BR,
Jani.


-- 
Jani Nikula, Intel

Reply via email to