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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD0FCCA5538 for ; Wed, 13 Sep 2023 10:34:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239152AbjIMKeW (ORCPT ); Wed, 13 Sep 2023 06:34:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231643AbjIMKeV (ORCPT ); Wed, 13 Sep 2023 06:34:21 -0400 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BD419C3; Wed, 13 Sep 2023 03:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694601257; x=1726137257; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=aSLZAhLlCUcLtEt71s9aVgFB3sPUO22k85ZuXX7lIvk=; b=C0Qmswudx36Cx1JSwSQi1JrAbNLUKyrE3OzO/BSKVw9soAN1W/S3bQcB eRkH66UHWXRHATsEaAXVhkNCMAx+khf52If5VuQpUn+hS+JbkyA5Dl+Iy 6TkXj7isNDZg/o+n6rrVlZfqr0IleNjdNUDkQB7ksbe6XXI04MagUfYz+ wB+DFgnH61/wBVsEzmEOqWp3YnzOeP8vpPiWMnA/La4DFtDqoKC5neRzf 70luKTEMlfZEQatf8zETCu/aqLpgpC4hHKT+l9hkDnwV8XWZ8GrDyv3bS BDPuCaDJtRdZsnEXbSbeQ7jCz9Yqj+S/Y1IjLKGmLirKJpOyXqDUXtUzF Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10831"; a="377534957" X-IronPort-AV: E=Sophos;i="6.02,142,1688454000"; d="scan'208";a="377534957" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 03:34:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10831"; a="990870840" X-IronPort-AV: E=Sophos;i="6.02,142,1688454000"; d="scan'208";a="990870840" Received: from kuha.fi.intel.com ([10.237.72.185]) by fmsmga006.fm.intel.com with SMTP; 13 Sep 2023 03:34:09 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 13 Sep 2023 13:34:08 +0300 Date: Wed, 13 Sep 2023 13:34:08 +0300 From: Heikki Krogerus To: Neil Armstrong Cc: Dmitry Baryshkov , David Airlie , Daniel Vetter , Andrzej Hajda , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Bryan O'Donoghue , Guenter Roeck , Janne Grunau , Simon Ser , Andy Gross , Bjorn Andersson , Konrad Dybcio , Greg Kroah-Hartman , dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, freedreno@lists.freedesktop.org, Won Chung Subject: Re: [RFC PATCH v1 01/12] Revert "drm/sysfs: Link DRM connectors to corresponding Type-C connectors" Message-ID: References: <20230903214150.2877023-2-dmitry.baryshkov@linaro.org> <6b6bacee-f7b6-4cfe-be3d-24bda44bfbcf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Hi Neil, On Wed, Sep 13, 2023 at 11:38:19AM +0200, Neil Armstrong wrote: > On new platforms (starting from SM8450) UCSI is mandatory to have > pmic_glink_altmode events triggering. You can also populate the typec devices conditionally, only if UCSI is not supported. However, I took a peek at drivers/soc/qcom/pmic_glink_altmode.c, and it seems to be mostly is dealing with the muxes and retimer, and sending the HPD notifications to the DRM side. All that is already done in typec drivers, so there is actually a potential race here when UCSI is used. On top of that, it is sending two commands to the PMIC (ALTMODE_PAN_EN and ALTMODE_PAN_ACK). I'm pretty sure both could be handled in the UCSI glue driver (drivers/usb/typec/ucsi/ucsi_glink.c) if they are even needed when UCSI is supported. So why do you need that pmic_glibk_altmode driver at all when UCSI is supported? I don't know the hardware, so I may be missing something. thanks, -- heikki 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id E4594CA5538 for ; Wed, 13 Sep 2023 10:34:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CF3BE10E00A; Wed, 13 Sep 2023 10:34:20 +0000 (UTC) Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4723110E00A; Wed, 13 Sep 2023 10:34:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1694601258; x=1726137258; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=aSLZAhLlCUcLtEt71s9aVgFB3sPUO22k85ZuXX7lIvk=; b=WWsqfxo7pz/+Mg/HKs07wEhs2nc5YW9KTJEsVycXBzoXtUs/SP+oUUn+ hWG3ulY8HHeK6vHeGNAoREqJ1XtQD3PJEF/+hrJNNygIVzvWqtHnKrVBw akMX9QKz2Qhz8K//nYhi6iDXIGUo2g+3d3O8gtgdkFMGpmBRM2NTf+LLq m8VnS0lfiQY9xDS9DTBzbh91B9ByaeXcysVgjG/urwxAX8kbHIkw41wUr tg2mp7SVl8IU9JsbLMp9K1eCTRMrx7gfwyxArovzhWYv62HvgQWQADZYo A/JRfz/VcHN/yLKUwCmtmLwOhnScA13ung8s6NxJVetky3YhHW8hxsgsp w==; X-IronPort-AV: E=McAfee;i="6600,9927,10831"; a="377534962" X-IronPort-AV: E=Sophos;i="6.02,142,1688454000"; d="scan'208";a="377534962" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Sep 2023 03:34:17 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10831"; a="990870840" X-IronPort-AV: E=Sophos;i="6.02,142,1688454000"; d="scan'208";a="990870840" Received: from kuha.fi.intel.com ([10.237.72.185]) by fmsmga006.fm.intel.com with SMTP; 13 Sep 2023 03:34:09 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 13 Sep 2023 13:34:08 +0300 Date: Wed, 13 Sep 2023 13:34:08 +0300 From: Heikki Krogerus To: Neil Armstrong Subject: Re: [RFC PATCH v1 01/12] Revert "drm/sysfs: Link DRM connectors to corresponding Type-C connectors" Message-ID: References: <20230903214150.2877023-2-dmitry.baryshkov@linaro.org> <6b6bacee-f7b6-4cfe-be3d-24bda44bfbcf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: dri-devel@lists.freedesktop.org, Laurent Pinchart , Andrzej Hajda , Janne Grunau , Robert Foss , Jernej Skrabec , Andy Gross , Bryan O'Donoghue , Guenter Roeck , Thomas Zimmermann , Jonas Karlman , linux-arm-msm@vger.kernel.org, Maxime Ripard , Greg Kroah-Hartman , Bjorn Andersson , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Konrad Dybcio , Won Chung , Dmitry Baryshkov , freedreno@lists.freedesktop.org Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi Neil, On Wed, Sep 13, 2023 at 11:38:19AM +0200, Neil Armstrong wrote: > On new platforms (starting from SM8450) UCSI is mandatory to have > pmic_glink_altmode events triggering. You can also populate the typec devices conditionally, only if UCSI is not supported. However, I took a peek at drivers/soc/qcom/pmic_glink_altmode.c, and it seems to be mostly is dealing with the muxes and retimer, and sending the HPD notifications to the DRM side. All that is already done in typec drivers, so there is actually a potential race here when UCSI is used. On top of that, it is sending two commands to the PMIC (ALTMODE_PAN_EN and ALTMODE_PAN_ACK). I'm pretty sure both could be handled in the UCSI glue driver (drivers/usb/typec/ucsi/ucsi_glink.c) if they are even needed when UCSI is supported. So why do you need that pmic_glibk_altmode driver at all when UCSI is supported? I don't know the hardware, so I may be missing something. thanks, -- heikki