Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp10010082rwb; Thu, 24 Nov 2022 23:14:29 -0800 (PST) X-Google-Smtp-Source: AA0mqf4+ag8JCzZOdGG4ocScB3Z3lFumIX4pW6ghJszSEBZAgUtLoaHdSg1wjfK3/GEr0bWlSB4R X-Received: by 2002:a17:906:1b51:b0:78d:a30f:3f3a with SMTP id p17-20020a1709061b5100b0078da30f3f3amr30746645ejg.386.1669360469436; Thu, 24 Nov 2022 23:14:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669360469; cv=none; d=google.com; s=arc-20160816; b=X9+YOOovXcqSh2f7z65NOvjj/zKFKs3Ho6qkB/MFMW0ctiiXyMPA7MKFS4gRJgMrSv 4HSEG2aWAe9lZOn+dVDiebNHi1IjnyE8KQzHMogZIBdVrreWbQcWgkDs9HasJUHCfzES G0eBs/ZYIRXRZl5WJL8D5VQJHvxacsalivLAc8kmCmMlY80vOD39MiF+ghvdeJ4jl9Ct YZVHYyAHhKoma/GILHTifOl9nO0EGN+aTXtTcyqxyP4f9Kkk7zFLvcCFsZ5A90GnKBNU 5FuAerTj0I6IMbxytRWOd0ztCK7SFksJeal3dMtm50aegsx+ZQPFivb0w6Fn0eOMQpll VOxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=ur6CY0ehyWvIsSYgBrRBd989RwDC6T3QUcqOKa4M1B4=; b=hFR3rqkSuvy3D0YHIwVUv6/uacVcJHtjmBtO7fn5uSTCxz4TZOtjwJYahiT3pg9lXZ cxjgK5DXCCwcigfdJ+eaO0HEutuLCHQ+6ao72CsNMw0pP7r2fzcs0vAlviUFecu+rI6i tLbFyP7ATLDzWOdU3dYPAnvCaB45ZQg3P6QDm4YuVbAi5bSHM51BqXQ5TTpCFLj6GIWi Yni+XJt4PFZikgXKMrGKy9TmvwwYmZfM8xPbHb5tw6CcDXNI8FOTa6Z2QxChzcgqc0OS oxTS/gGQ6Q4+SyyutcN7O7wkINQFa4WjobIuS9lczcp3f3AjxkUr0V1O32+XEc4F73t9 yCTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jNnSsHNc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cy15-20020a0564021c8f00b004627741e339si2640228edb.113.2022.11.24.23.14.07; Thu, 24 Nov 2022 23:14:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=jNnSsHNc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229476AbiKYGz0 (ORCPT + 88 others); Fri, 25 Nov 2022 01:55:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229541AbiKYGzZ (ORCPT ); Fri, 25 Nov 2022 01:55:25 -0500 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 685652C10C for ; Thu, 24 Nov 2022 22:55:24 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id r26so3056638edc.10 for ; Thu, 24 Nov 2022 22:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ur6CY0ehyWvIsSYgBrRBd989RwDC6T3QUcqOKa4M1B4=; b=jNnSsHNcd023P83kMILxiDJDJgirzXk5J8n8FkSm4NyIFaVmXexpO0DEMEkYn4Oedc euDEkry9V94wGcq3+3lQ6Mi2B+iMeAkFXyijmtRixfRM1DB4eAtFMzcxbOYsl6nm+fvX C5HULIDB1sjSdqQ16R3LmA6SplmEqmUPXk2Sc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ur6CY0ehyWvIsSYgBrRBd989RwDC6T3QUcqOKa4M1B4=; b=QeoL/0Q1Z5XBSLOPawxy8YKuNDyeUppRc57Mjy7t/ZlpgK0sPLfgFBq23f4SgHxh5n AuhpvobRcyaVC50+1TcrHHLWdMcO6hMWp684lpm1OhHrhfNGS/CGRWxY94uqbqwECiNI 9WkQkaWHPSPQa8tCFSxKQUykA9ks+4oqA3VA6Xqtc8q4zOPfQ1eTQk5aw8bxz/aLsrvu QDJs0WB0UZGC8LDwy9qF590HnkKEv1wWZhtUMcjGgLWPHkQ+sQ03LaWJlLKblhdOilHv 4w9chbr6GSKGyyUcD4SiKXJX11RowpFGn+fE/RC5iwiWtRJTGto3fTeUGaACl6B4/8bf EV9g== X-Gm-Message-State: ANoB5pnLIvrqm6a4+WxGQdrqStyCS7y3SS9klG3WnqkBeqD4YwyUSVgB VhZKMMsGqTWrcTCCZqm1vonzF+xTA1cJgU1cnZktkQ== X-Received: by 2002:a05:6402:3895:b0:468:15f1:54b5 with SMTP id fd21-20020a056402389500b0046815f154b5mr15230966edb.8.1669359322947; Thu, 24 Nov 2022 22:55:22 -0800 (PST) MIME-Version: 1.0 References: <20221124102056.393220-1-treapking@chromium.org> <20221124102056.393220-8-treapking@chromium.org> In-Reply-To: From: Pin-yen Lin Date: Fri, 25 Nov 2022 14:55:11 +0800 Message-ID: Subject: Re: [PATCH v6 7/7] drm/bridge: it6505: Register Type C mode switches To: Andy Shevchenko Cc: Andrzej Hajda , Neil Armstrong , Robert Foss , Laurent Pinchart , Jonas Karlman , Jernej Skrabec , David Airlie , Daniel Vetter , Rob Herring , Krzysztof Kozlowski , Daniel Scally , Heikki Krogerus , Sakari Ailus , Greg Kroah-Hartman , "Rafael J . Wysocki" , Prashant Malani , Benson Leung , Guenter Roeck , Javier Martinez Canillas , Stephen Boyd , dri-devel@lists.freedesktop.org, Hsin-Yi Wang , Thomas Zimmermann , devicetree@vger.kernel.org, chrome-platform@lists.linux.dev, linux-acpi@vger.kernel.org, Marek Vasut , Xin Ji , Lyude Paul , =?UTF-8?B?TsOtY29sYXMgRiAuIFIgLiBBIC4gUHJhZG8=?= , AngeloGioacchino Del Regno , linux-kernel@vger.kernel.org, Allen Chen Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, Thanks for reviewing the patch. On Thu, Nov 24, 2022 at 8:23 PM Andy Shevchenko wrote: > > On Thu, Nov 24, 2022 at 06:20:56PM +0800, Pin-yen Lin wrote: > > Register USB Type-C mode switches when the "mode-switch" property and > > relevant port are available in Device Tree. Configure the "lane_swap" > > state based on the entered alternate mode for a specific Type-C > > connector, which ends up updating the lane swap registers of the it6505 > > chip. > > ... > > > config DRM_ITE_IT6505 > > tristate "ITE IT6505 DisplayPort bridge" > > depends on OF > > + depends on TYPEC || TYPEC=n > > select DRM_DISPLAY_DP_HELPER > > select DRM_DISPLAY_HDCP_HELPER > > select DRM_DISPLAY_HELPER > > Something went wrong with the indentation. Perhaps you need to fix it first. > > ... > > > #include > > #include > > #include > > +#include > > Make it ordered? Will fix it in v7. > > ... > > > +struct it6505_port_data { > > > + bool dp_connected; > > Perhaps make it last? Will fix it in v7. > > > + struct typec_mux_dev *typec_mux; > > + struct it6505 *it6505; > > +}; > > ... > > > +static void it6505_typec_ports_update(struct it6505 *it6505) > > +{ > > + usleep_range(3000, 4000); > > + > > + if (it6505->typec_ports[0].dp_connected && it6505->typec_ports[1].dp_connected) > > + /* Both ports available, do nothing to retain the current one. */ > > + return; > > + else if (it6505->typec_ports[0].dp_connected) > > + it6505->lane_swap = false; > > + else if (it6505->typec_ports[1].dp_connected) > > + it6505->lane_swap = true; > > + > > + usleep_range(3000, 4000); > > +} > > As per previous patch comments. Will update it in v7. > > Also, comment out these long sleeps. Why they are needed. Actually, it turns out that these sleeps are not needed. I'll remove it in v7. > > ... > > > + int ret = pm_runtime_get_sync(dev); > > + > > + /* > > + * On system resume, mux_set can be triggered before > > + * pm_runtime_force_resume re-enables runtime power management. > > We refer to the functions as func(). Will fix this in v7. > > > + * Handling the error here to make sure the bridge is powered on. > > + */ > > + if (ret < 0) > > + it6505_poweron(it6505); > > This seems needed a bit more of explanation, esp. why you leave PM runtime > reference count bumped up. pm_runtime_force_suspend() disables runtime PM when the device enters suspend, and sometime it6505_typec_mux_set() is called before pm_runtime_force_resume brings runtime PM back. We force power up the bridge in this case and leave the ref count incremented to make the future pm_runtime_(get|put)_sync() calls balanced. I'll include more explanations around this in v7. > > ... > > > + num_lanes = drm_of_get_data_lanes_count(node, 0, 2); > > + if (num_lanes <= 0) { > > + dev_err(dev, "Error on getting data lanes count: %d\n", > > + num_lanes); > > + return num_lanes; > > + } > > + > > + ret = of_property_read_u32_array(node, "data-lanes", dp_lanes, num_lanes); > > + if (ret) { > > + dev_err(dev, "Failed to read the data-lanes variable: %d\n", > > + ret); > > + return ret; > > + } > > + > > + for (i = 0; i < num_lanes; i++) { > > + if (port_num != -1 && port_num != dp_lanes[i] / 2) { > > + dev_err(dev, "Invalid data lane numbers\n"); > > + return -EINVAL; > > + } > > As per previous patch comments. I'll remove this part in v7 and try to figure out how to do similar checking with schemas. > > > + port_num = dp_lanes[i] / 2; > > + } > > The above seems like tons of duplicating code that drivers need to implement. > Can we shrink that burden by adding some library functions? Could you advise where this lib file should go, and what the namings can be? The "port-switching" logic is specific to some of the DP bridges, and I'm not sure what kinds of naming/structure fit into this case. Thanks and regards, Pin-yen > > -- > With Best Regards, > Andy Shevchenko > >