From patchwork Thu Jun 4 09:20:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Ser X-Patchwork-Id: 11587671 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id C5F2D1391 for ; Thu, 4 Jun 2020 09:20:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A37C520738 for ; Thu, 4 Jun 2020 09:20:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=emersion.fr header.i=@emersion.fr header.b="rBpdAcog" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A37C520738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=emersion.fr Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1EE356E21D; Thu, 4 Jun 2020 09:20:37 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by gabe.freedesktop.org (Postfix) with ESMTPS id 47CA16E2BC for ; Thu, 4 Jun 2020 09:20:36 +0000 (UTC) Date: Thu, 04 Jun 2020 09:20:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emersion.fr; s=protonmail; t=1591262434; bh=S77ijj3zO/iqtCoxNNl6Le0cycvdwXVNi7kBaWwXqlo=; h=Date:To:From:Cc:Reply-To:Subject:From; b=rBpdAcogQoaZWmPC5crBw+Nzo+MG42yBMXajnus/ghqG/joo07y0r59CMXAwTPxe4 BTI3A1vATE7DiBMxv10HJcqx8Wt/Oa8aDoa2btpOs8D+m2RviCsHH4j49eSiu6C03V 6CB490mbVrvDHSGbZVVRhQ89pw8FAve5iu3ABvos= To: dri-devel@lists.freedesktop.org From: Simon Ser Subject: [PATCH v3] drm: document how user-space should use link-status Message-ID: MIME-Version: 1.0 X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Simon Ser Cc: Manasi Navare Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Describe what a "BAD" link-status means for user-space and how it should handle it. The logic described has been implemented in igt [1]. v2: - Change wording to avoid "enabled" (Daniel) - Add paragraph about multiple connectors sharing the same CRTC (Pekka) - Add paragraph about performing an atomic commit on a connector without updating the link-status property (Daniel) v3: - Fix description of what happens when link-status isn't reset to "GOOD", and when link-status is reset without ALLOW_MODESET (Daniel, Ville) - Changing link-status to "BAD" is a no-op - Clearly state that "BAD" means black screen (Manasi) [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbe Signed-off-by: Simon Ser Cc: Daniel Vetter Cc: Manasi Navare Cc: Ville Syrjala Cc: Pekka Paalanen --- I'm not 100% sure the paragraph about not resetting link-status or not using ALLOW_MODESET is accurate. Just like the previous version, this is just an attempt at documenting the current kernel behaviour. drivers/gpu/drm/drm_connector.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c index f2b20fd66319..1df036b3353b 100644 --- a/drivers/gpu/drm/drm_connector.c +++ b/drivers/gpu/drm/drm_connector.c @@ -994,6 +994,26 @@ static const struct drm_prop_enum_list dp_colorspaces[] = { * after modeset, the kernel driver may set this to "BAD" and issue a * hotplug uevent. Drivers should update this value using * drm_connector_set_link_status_property(). + * + * When user-space receives the hotplug uevent and detects a "BAD" + * link-status, the sink doesn't receive pixels anymore (e.g. the screen + * becomes completely black). The list of available modes may have + * changed. User-space is expected to pick a new mode if the current one + * has disappeared and perform a new modeset with link-status set to + * "GOOD" to re-enable the connector. + * + * If multiple connectors share the same CRTC and one of them gets a "BAD" + * link-status, the other are unaffected (ie. the sinks still continue to + * receive pixels). + * + * When user-space performs an atomic commit on a connector with a "BAD" + * link-status without resetting the property to "GOOD", the sink may + * still not receive pixels. When user-space performs an atomic commit + * which resets the link-status property to "GOOD" without the + * ALLOW_MODESET flag set, it might fail because a modeset is required. + * + * User-space can only change link-status to "GOOD", changing it to "BAD" + * is a no-op. * non_desktop: * Indicates the output should be ignored for purposes of displaying a * standard desktop environment or console. This is most likely because