From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9B626C433ED for ; Mon, 19 Apr 2021 22:57:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7DE3261177 for ; Mon, 19 Apr 2021 22:57:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231646AbhDSW5h (ORCPT ); Mon, 19 Apr 2021 18:57:37 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:37483 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232013AbhDSW5a (ORCPT ); Mon, 19 Apr 2021 18:57:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618873020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpWF35re5mO8T7PVOXIxt7+uN4UplGneHqyrdOS6vUo=; b=fH4TWXRwJV5lAGjRrwVKUZrfhSHT+GKGFb/Xh+E+MbG9ivD5VL2CdSh9B7urkhrb+aD1Xo iOfOFg0yg+uVS2BGYRb4def3Fo9sIn12vcYmkmOElS95GNERSW7lG40fbDKLZaN+dgV2A5 sY344aZ5Wa/NQs7wYSG5u7Nw8yhW6sY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-31-ogiio_rdMgmzkp-Hu38DaQ-1; Mon, 19 Apr 2021 18:56:53 -0400 X-MC-Unique: ogiio_rdMgmzkp-Hu38DaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D368107ACCD; Mon, 19 Apr 2021 22:56:51 +0000 (UTC) Received: from Ruby.lyude.net (ovpn-119-153.rdu2.redhat.com [10.10.119.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D375C1C4; Mon, 19 Apr 2021 22:56:49 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Jani Nikula , Rodrigo Vivi , Thomas Zimmermann , Thierry Reding Cc: Maarten Lankhorst , Maxime Ripard , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org (open list) Subject: [PATCH v3 07/20] drm/dp: Clarify DP AUX registration time Date: Mon, 19 Apr 2021 18:55:09 -0400 Message-Id: <20210419225523.184856-8-lyude@redhat.com> In-Reply-To: <20210419225523.184856-1-lyude@redhat.com> References: <20210419225523.184856-1-lyude@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 +++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A327C43470 for ; Mon, 19 Apr 2021 22:57:05 +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 C01A660FF1 for ; Mon, 19 Apr 2021 22:57:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C01A660FF1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=nouveau-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D3E4D6E47A; Mon, 19 Apr 2021 22:57:03 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2EEED6E479 for ; Mon, 19 Apr 2021 22:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618873020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpWF35re5mO8T7PVOXIxt7+uN4UplGneHqyrdOS6vUo=; b=fH4TWXRwJV5lAGjRrwVKUZrfhSHT+GKGFb/Xh+E+MbG9ivD5VL2CdSh9B7urkhrb+aD1Xo iOfOFg0yg+uVS2BGYRb4def3Fo9sIn12vcYmkmOElS95GNERSW7lG40fbDKLZaN+dgV2A5 sY344aZ5Wa/NQs7wYSG5u7Nw8yhW6sY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-31-ogiio_rdMgmzkp-Hu38DaQ-1; Mon, 19 Apr 2021 18:56:53 -0400 X-MC-Unique: ogiio_rdMgmzkp-Hu38DaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D368107ACCD; Mon, 19 Apr 2021 22:56:51 +0000 (UTC) Received: from Ruby.lyude.net (ovpn-119-153.rdu2.redhat.com [10.10.119.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D375C1C4; Mon, 19 Apr 2021 22:56:49 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Jani Nikula , Rodrigo Vivi , Thomas Zimmermann , Thierry Reding Date: Mon, 19 Apr 2021 18:55:09 -0400 Message-Id: <20210419225523.184856-8-lyude@redhat.com> In-Reply-To: <20210419225523.184856-1-lyude@redhat.com> References: <20210419225523.184856-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Subject: [Nouveau] [PATCH v3 07/20] drm/dp: Clarify DP AUX registration time X-BeenThere: nouveau@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Nouveau development list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Maarten Lankhorst , Daniel Vetter , Maxime Ripard , open list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: nouveau-bounces@lists.freedesktop.org Sender: "Nouveau" The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 +++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 _______________________________________________ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59EF5C43460 for ; Mon, 19 Apr 2021 22:57:06 +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 1BEBF60FF1 for ; Mon, 19 Apr 2021 22:57:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1BEBF60FF1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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 66A626E487; Mon, 19 Apr 2021 22:57:04 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 08EE26E479 for ; Mon, 19 Apr 2021 22:57:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618873022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpWF35re5mO8T7PVOXIxt7+uN4UplGneHqyrdOS6vUo=; b=MoJGZAQlnqAKtNyi0N2M6izP9yOs+bT1n5eKwsqf2gZxUcRzFwywpJEJQSWfe2nR3pjOEs nzXMS//nH2ZLFz31h+q3lJwP+CHEnUN5dQ2YLfOl9DjjvJ/z4Az7Bm+B8cubfO/XkU9EWL QDBmYvO0l6N6sF8rB8q8y3NbkKizAMY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-31-ogiio_rdMgmzkp-Hu38DaQ-1; Mon, 19 Apr 2021 18:56:53 -0400 X-MC-Unique: ogiio_rdMgmzkp-Hu38DaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D368107ACCD; Mon, 19 Apr 2021 22:56:51 +0000 (UTC) Received: from Ruby.lyude.net (ovpn-119-153.rdu2.redhat.com [10.10.119.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D375C1C4; Mon, 19 Apr 2021 22:56:49 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Jani Nikula , Rodrigo Vivi , Thomas Zimmermann , Thierry Reding Subject: [PATCH v3 07/20] drm/dp: Clarify DP AUX registration time Date: Mon, 19 Apr 2021 18:55:09 -0400 Message-Id: <20210419225523.184856-8-lyude@redhat.com> In-Reply-To: <20210419225523.184856-1-lyude@redhat.com> References: <20210419225523.184856-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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: , Cc: David Airlie , open list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 +++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D4BBC43461 for ; Mon, 19 Apr 2021 22:57:04 +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 3285660FF1 for ; Mon, 19 Apr 2021 22:57:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3285660FF1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 962EA6E479; Mon, 19 Apr 2021 22:57:03 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 43A816E486 for ; Mon, 19 Apr 2021 22:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618873020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpWF35re5mO8T7PVOXIxt7+uN4UplGneHqyrdOS6vUo=; b=fH4TWXRwJV5lAGjRrwVKUZrfhSHT+GKGFb/Xh+E+MbG9ivD5VL2CdSh9B7urkhrb+aD1Xo iOfOFg0yg+uVS2BGYRb4def3Fo9sIn12vcYmkmOElS95GNERSW7lG40fbDKLZaN+dgV2A5 sY344aZ5Wa/NQs7wYSG5u7Nw8yhW6sY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-31-ogiio_rdMgmzkp-Hu38DaQ-1; Mon, 19 Apr 2021 18:56:53 -0400 X-MC-Unique: ogiio_rdMgmzkp-Hu38DaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D368107ACCD; Mon, 19 Apr 2021 22:56:51 +0000 (UTC) Received: from Ruby.lyude.net (ovpn-119-153.rdu2.redhat.com [10.10.119.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D375C1C4; Mon, 19 Apr 2021 22:56:49 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Jani Nikula , Rodrigo Vivi , Thomas Zimmermann , Thierry Reding Date: Mon, 19 Apr 2021 18:55:09 -0400 Message-Id: <20210419225523.184856-8-lyude@redhat.com> In-Reply-To: <20210419225523.184856-1-lyude@redhat.com> References: <20210419225523.184856-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Subject: [Intel-gfx] [PATCH v3 07/20] drm/dp: Clarify DP AUX registration time X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Maxime Ripard , open list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 +++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B12B9C43462 for ; Mon, 19 Apr 2021 22:57:04 +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 6F08961221 for ; Mon, 19 Apr 2021 22:57:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F08961221 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=amd-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DB3546E47E; Mon, 19 Apr 2021 22:57:03 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4339A6E484 for ; Mon, 19 Apr 2021 22:57:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1618873020; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JpWF35re5mO8T7PVOXIxt7+uN4UplGneHqyrdOS6vUo=; b=fH4TWXRwJV5lAGjRrwVKUZrfhSHT+GKGFb/Xh+E+MbG9ivD5VL2CdSh9B7urkhrb+aD1Xo iOfOFg0yg+uVS2BGYRb4def3Fo9sIn12vcYmkmOElS95GNERSW7lG40fbDKLZaN+dgV2A5 sY344aZ5Wa/NQs7wYSG5u7Nw8yhW6sY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-31-ogiio_rdMgmzkp-Hu38DaQ-1; Mon, 19 Apr 2021 18:56:53 -0400 X-MC-Unique: ogiio_rdMgmzkp-Hu38DaQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6D368107ACCD; Mon, 19 Apr 2021 22:56:51 +0000 (UTC) Received: from Ruby.lyude.net (ovpn-119-153.rdu2.redhat.com [10.10.119.153]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75D375C1C4; Mon, 19 Apr 2021 22:56:49 +0000 (UTC) From: Lyude Paul To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, nouveau@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Jani Nikula , Rodrigo Vivi , Thomas Zimmermann , Thierry Reding Subject: [PATCH v3 07/20] drm/dp: Clarify DP AUX registration time Date: Mon, 19 Apr 2021 18:55:09 -0400 Message-Id: <20210419225523.184856-8-lyude@redhat.com> In-Reply-To: <20210419225523.184856-1-lyude@redhat.com> References: <20210419225523.184856-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Maarten Lankhorst , Daniel Vetter , Maxime Ripard , open list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" The docs we had for drm_dp_aux_init() and drm_dp_aux_register() were mostly correct, except for the fact that they made the assumption that all AUX devices were grandchildren of their respective DRM devices. This is the case for most normal GPUs, but is almost never the case with SoCs and display bridges. So, let's fix this documentation to clarify when the right time to use drm_dp_aux_init() or drm_dp_aux_register() is. Signed-off-by: Lyude Paul --- drivers/gpu/drm/drm_dp_helper.c | 57 +++++++++++++++++++++------------ 1 file changed, 37 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index b34105c41867..b197fdac2334 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,13 +1728,21 @@ EXPORT_SYMBOL(drm_dp_remote_aux_init); * drm_dp_aux_init() - minimally initialise an aux channel * @aux: DisplayPort AUX channel * - * If you need to use the drm_dp_aux's i2c adapter prior to registering it - * with the outside world, call drm_dp_aux_init() first. You must still - * call drm_dp_aux_register() once the connector has been registered to - * allow userspace access to the auxiliary DP channel. Once the AUX channel is - * no longer being used and has been unregistered with - * drm_dp_aux_unregister(), the driver must clean up any resources it's - * allocated with drm_dp_aux_fini(). + * If you need to use the drm_dp_aux's i2c adapter prior to registering it with + * the outside world, call drm_dp_aux_init() first. For drivers which are + * grandparents to their AUX adapters (e.g. the AUX adapter is parented by a + * &drm_connector), you must still call drm_dp_aux_register() once the connector + * has been registered to allow userspace access to the auxiliary DP channel. + * Likewise, for such drivers you should also assign &drm_dp_aux.drm_dev as + * early as possible so that the &drm_device that corresponds to the AUX adapter + * may be mentioned in debugging output from the DRM DP helpers. + * + * For devices which use a separate platform device for their AUX adapters, this + * may be called as early as required by the driver. + * + * Once the AUX channel is no longer being used and has been unregistered with + * drm_dp_aux_unregister(), the driver must clean up any resources its allocated with + * drm_dp_aux_fini(). * * Returns: * %0 on success, negative error code on failure @@ -1794,19 +1802,28 @@ EXPORT_SYMBOL(drm_dp_aux_fini); * drm_dp_aux_register() - register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. The - * driver must make sure to call drm_dp_aux_unregister() to unregister the - * device, and drm_dp_aux_fini() to cleanup the device after it's been - * unregistered. - * - * This should only be called when the underlying &struct drm_connector is - * initialized already. Therefore the best place to call this is from - * &drm_connector_funcs.late_register. Not that drivers which don't follow this - * will Oops when CONFIG_DRM_DP_AUX_CHARDEV is enabled. - * - * Drivers which need to use the aux channel before that point (e.g. at driver - * load time, before drm_dev_register() has been called) need to call - * drm_dp_aux_init(). + * Automatically calls drm_dp_aux_init() if this hasn't been done yet. This + * should only be called once the parent of @aux, &drm_dp_aux.dev, is + * initialized. For devices which are grandparents of their AUX channels, + * &drm_dp_aux.dev will typically be the &drm_connector &device which + * corresponds to @aux. For these devices, it's advised to call + * drm_dp_aux_register() in &drm_connector_funcs.late_register, and likewise to + * call drm_dp_aux_unregister() in &drm_connector_funcs.early_unregister. + * Functions which don't follow this will likely Oops when + * %CONFIG_DRM_DP_AUX_CHARDEV is enabled. + * + * For devices where the AUX channel is a device that exists independently of + * the &drm_device that uses it, such as SoCs and bridge devices, it is + * recommended to call drm_dp_aux_register() after a &drm_device has been + * assigned to &drm_dp_aux.drm_dev, and likewise to call + * drm_dp_aux_unregister() once the &drm_device should no longer be associated + * with the AUX channel (e.g. on bridge detach). Additionally, the driver must + * call drm_dp_aux_fini() on @aux once it's been unregistered and is no longer + * in use. + * + * Drivers which need to use the aux channel before either of the two points + * mentioned above need to call drm_dp_aux_init() in order to use the AUX + * channel before registration. * * Returns 0 on success or a negative error code on failure. */ -- 2.30.2 _______________________________________________ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx