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=-16.0 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 A2874C433E5 for ; Fri, 26 Mar 2021 20:40:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C17B61A18 for ; Fri, 26 Mar 2021 20:40:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230444AbhCZUji (ORCPT ); Fri, 26 Mar 2021 16:39:38 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:56554 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230335AbhCZUjM (ORCPT ); Fri, 26 Mar 2021 16:39:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616791151; 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=EBwcu+4SZ0MiVhXsRC+eFR75OwHmxyKtpUAh+axYYMA=; b=NlmpsjWBN9Pz/K95wCXq3gWqqSpXH3jwSRXBanxtTDpQKnYnhOOsf7MRgyZ0EthEGDz+lc VnzNnprfcfijG0TCR9akKh0WxVEF7axv6pjGd4esVTDQiQBd+RDuv/kFU+p8U6K4qNKAhd TsPlnluFGr67LHjDR8FwcSHBnz7llUA= 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-360-CpFTDH7GO2-LB5Kc0vJj7g-1; Fri, 26 Mar 2021 16:39:07 -0400 X-MC-Unique: CpFTDH7GO2-LB5Kc0vJj7g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8B6A1853026; Fri, 26 Mar 2021 20:39:05 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-114-133.rdu2.redhat.com [10.10.114.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096345DEAD; Fri, 26 Mar 2021 20:39:02 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Cc: Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , linux-kernel@vger.kernel.org (open list) Subject: [PATCH v2 06/20] drm/dp: Clarify DP AUX registration time Date: Fri, 26 Mar 2021 16:37:53 -0400 Message-Id: <20210326203807.105754-7-lyude@redhat.com> In-Reply-To: <20210326203807.105754-1-lyude@redhat.com> References: <20210326203807.105754-1-lyude@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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 | 44 +++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index eedbb48815b7..3fa858b9691c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,10 +1728,17 @@ 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. + * 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. */ void drm_dp_aux_init(struct drm_dp_aux *aux) { @@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init); * drm_dp_aux_register() - initialise and register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. - * This should only be called when the underlying &struct drm_connector is - * initialiazed 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). + * + * 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 19D44C433E1 for ; Fri, 26 Mar 2021 20:39:15 +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 0232061A0D for ; Fri, 26 Mar 2021 20:39:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0232061A0D 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 31DC46F496; Fri, 26 Mar 2021 20:39:14 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id BCB3C6F49C for ; Fri, 26 Mar 2021 20:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616791152; 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=EBwcu+4SZ0MiVhXsRC+eFR75OwHmxyKtpUAh+axYYMA=; b=Ptmc50ICy1/GyO9bhStx13ypUz+kxGcb3kD2GDfrcXdf3yB5Injf1q2lQlWh2xvWkY/7mt Z/SB99m7tAPTDQnQjsDY/FcuR4dxA48ER2IR8okn34dsbatsQBnj2SvWEcUzWPM+sBw8aC sOPghyYa0KrA0i0iTDESapSb9C1Yn1c= 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-360-CpFTDH7GO2-LB5Kc0vJj7g-1; Fri, 26 Mar 2021 16:39:07 -0400 X-MC-Unique: CpFTDH7GO2-LB5Kc0vJj7g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8B6A1853026; Fri, 26 Mar 2021 20:39:05 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-114-133.rdu2.redhat.com [10.10.114.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096345DEAD; Fri, 26 Mar 2021 20:39:02 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Date: Fri, 26 Mar 2021 16:37:53 -0400 Message-Id: <20210326203807.105754-7-lyude@redhat.com> In-Reply-To: <20210326203807.105754-1-lyude@redhat.com> References: <20210326203807.105754-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Subject: [Nouveau] [PATCH v2 06/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 , open list , Maxime Ripard , Daniel Vetter 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 | 44 +++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index eedbb48815b7..3fa858b9691c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,10 +1728,17 @@ 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. + * 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. */ void drm_dp_aux_init(struct drm_dp_aux *aux) { @@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init); * drm_dp_aux_register() - initialise and register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. - * This should only be called when the underlying &struct drm_connector is - * initialiazed 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). + * + * 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=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 DEF8FC433C1 for ; Fri, 26 Mar 2021 20:39:11 +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 C767E61A13 for ; Fri, 26 Mar 2021 20:39:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C767E61A13 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 15F976E2DC; Fri, 26 Mar 2021 20:39:11 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id 95C296E2DC for ; Fri, 26 Mar 2021 20:39:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616791149; 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=EBwcu+4SZ0MiVhXsRC+eFR75OwHmxyKtpUAh+axYYMA=; b=Dxx7MkZvj1vJNUdD3cevDzr+6m5VMj5lExMKW8Qbq4ojF/v3FD445CMhTPIrlCbo23U6iJ jgbmlXJ91uCbGog6+Ecjci/4EUxIYPvu9zjqO1VthQEYq96fCi5o12Tx48Y3UMud63/e1r LrgrHwKIAUvJuoEEWazNECHSivvv6qI= 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-360-CpFTDH7GO2-LB5Kc0vJj7g-1; Fri, 26 Mar 2021 16:39:07 -0400 X-MC-Unique: CpFTDH7GO2-LB5Kc0vJj7g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8B6A1853026; Fri, 26 Mar 2021 20:39:05 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-114-133.rdu2.redhat.com [10.10.114.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096345DEAD; Fri, 26 Mar 2021 20:39:02 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Subject: [PATCH v2 06/20] drm/dp: Clarify DP AUX registration time Date: Fri, 26 Mar 2021 16:37:53 -0400 Message-Id: <20210326203807.105754-7-lyude@redhat.com> In-Reply-To: <20210326203807.105754-1-lyude@redhat.com> References: <20210326203807.105754-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: Thomas Zimmermann , 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 | 44 +++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index eedbb48815b7..3fa858b9691c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,10 +1728,17 @@ 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. + * 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. */ void drm_dp_aux_init(struct drm_dp_aux *aux) { @@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init); * drm_dp_aux_register() - initialise and register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. - * This should only be called when the underlying &struct drm_connector is - * initialiazed 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). + * + * 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=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 9504EC433E0 for ; Fri, 26 Mar 2021 20:39:14 +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 82D0B61A13 for ; Fri, 26 Mar 2021 20:39:14 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 82D0B61A13 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 CF7E46E2D5; Fri, 26 Mar 2021 20:39:13 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id AA23E6F49B for ; Fri, 26 Mar 2021 20:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616791151; 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=EBwcu+4SZ0MiVhXsRC+eFR75OwHmxyKtpUAh+axYYMA=; b=NlmpsjWBN9Pz/K95wCXq3gWqqSpXH3jwSRXBanxtTDpQKnYnhOOsf7MRgyZ0EthEGDz+lc VnzNnprfcfijG0TCR9akKh0WxVEF7axv6pjGd4esVTDQiQBd+RDuv/kFU+p8U6K4qNKAhd TsPlnluFGr67LHjDR8FwcSHBnz7llUA= 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-360-CpFTDH7GO2-LB5Kc0vJj7g-1; Fri, 26 Mar 2021 16:39:07 -0400 X-MC-Unique: CpFTDH7GO2-LB5Kc0vJj7g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8B6A1853026; Fri, 26 Mar 2021 20:39:05 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-114-133.rdu2.redhat.com [10.10.114.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096345DEAD; Fri, 26 Mar 2021 20:39:02 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Date: Fri, 26 Mar 2021 16:37:53 -0400 Message-Id: <20210326203807.105754-7-lyude@redhat.com> In-Reply-To: <20210326203807.105754-1-lyude@redhat.com> References: <20210326203807.105754-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Subject: [Intel-gfx] [PATCH v2 06/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: Thomas Zimmermann , David Airlie , open list , Maxime Ripard 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 | 44 +++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index eedbb48815b7..3fa858b9691c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,10 +1728,17 @@ 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. + * 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. */ void drm_dp_aux_init(struct drm_dp_aux *aux) { @@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init); * drm_dp_aux_register() - initialise and register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. - * This should only be called when the underlying &struct drm_connector is - * initialiazed 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). + * + * 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 4424CC433DB for ; Fri, 26 Mar 2021 20:39:12 +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 2D6EE61A13 for ; Fri, 26 Mar 2021 20:39:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D6EE61A13 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 5D28F6F486; Fri, 26 Mar 2021 20:39:11 +0000 (UTC) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by gabe.freedesktop.org (Postfix) with ESMTPS id AECCB6F496 for ; Fri, 26 Mar 2021 20:39:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616791149; 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=EBwcu+4SZ0MiVhXsRC+eFR75OwHmxyKtpUAh+axYYMA=; b=Dxx7MkZvj1vJNUdD3cevDzr+6m5VMj5lExMKW8Qbq4ojF/v3FD445CMhTPIrlCbo23U6iJ jgbmlXJ91uCbGog6+Ecjci/4EUxIYPvu9zjqO1VthQEYq96fCi5o12Tx48Y3UMud63/e1r LrgrHwKIAUvJuoEEWazNECHSivvv6qI= 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-360-CpFTDH7GO2-LB5Kc0vJj7g-1; Fri, 26 Mar 2021 16:39:07 -0400 X-MC-Unique: CpFTDH7GO2-LB5Kc0vJj7g-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D8B6A1853026; Fri, 26 Mar 2021 20:39:05 +0000 (UTC) Received: from Whitewolf.lyude.net (ovpn-114-133.rdu2.redhat.com [10.10.114.133]) by smtp.corp.redhat.com (Postfix) with ESMTP id 096345DEAD; Fri, 26 Mar 2021 20:39:02 +0000 (UTC) From: Lyude Paul To: nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Subject: [PATCH v2 06/20] drm/dp: Clarify DP AUX registration time Date: Fri, 26 Mar 2021 16:37:53 -0400 Message-Id: <20210326203807.105754-7-lyude@redhat.com> In-Reply-To: <20210326203807.105754-1-lyude@redhat.com> References: <20210326203807.105754-1-lyude@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 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: Thomas Zimmermann , David Airlie , Maarten Lankhorst , open list , Maxime Ripard , Daniel Vetter 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 | 44 +++++++++++++++++++++++---------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index eedbb48815b7..3fa858b9691c 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -1728,10 +1728,17 @@ 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. + * 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. */ void drm_dp_aux_init(struct drm_dp_aux *aux) { @@ -1751,15 +1758,26 @@ EXPORT_SYMBOL(drm_dp_aux_init); * drm_dp_aux_register() - initialise and register aux channel * @aux: DisplayPort AUX channel * - * Automatically calls drm_dp_aux_init() if this hasn't been done yet. - * This should only be called when the underlying &struct drm_connector is - * initialiazed 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). + * + * 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