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 880A7CA5534 for ; Wed, 13 Sep 2023 10:34:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239611AbjIMKeX (ORCPT ); Wed, 13 Sep 2023 06:34:23 -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-kernel@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