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 78DB6C32771 for ; Fri, 19 Aug 2022 20:14:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351796AbiHSUOn (ORCPT ); Fri, 19 Aug 2022 16:14:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33554 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351766AbiHSUOl (ORCPT ); Fri, 19 Aug 2022 16:14:41 -0400 Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E59FC2767 for ; Fri, 19 Aug 2022 13:14:37 -0700 (PDT) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-333b049f231so150426657b3.1 for ; Fri, 19 Aug 2022 13:14:37 -0700 (PDT) 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; bh=8L7+bHVm0h1+I67FWChZbZVTBcw+lGpUv6+U3fMiZWM=; b=awXeCwO8IpyJ6UloORqQrGJLvPY2JTkO9ru8WppfBpgYyBtTTPTtcvsujXWe8ticC6 e6oX/xjcqfQoCner5zndlF4U8WLn/q41ztORxe5jAOVij4tkFokRUbTpRbw3KxpGls3p LRQv5/eO4NvDlCbdewUPciS4nR7DM5YlqLngc= 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; bh=8L7+bHVm0h1+I67FWChZbZVTBcw+lGpUv6+U3fMiZWM=; b=eKBbEdRnkkSJadMQ1z6ZZC8twY+TSAVIRUgBu4HlA/JvUckNukINyUylzri4PcUkJh FXrILrQ3ryUhA/0r3Re1A8NIhAeMZx/QhKBKMAGA5PuBZ8DM6wBiD1Ew9WY4e70oLTK9 BVoSs8MP0Tkn+DRfVjz8xw0BGr4/4U0j19ZsaERsKkfxWqapODT1ktPgii6XmaXBKpwC p0vO/icXnjAd1ncuHLL0VfjThkR18Ktob3LctjD8BhEYTNSBk4ZpODrzDxZAd1LNE4vq NbeZNsMLHS0di9EYng1kzoI0ucPOw1dTJlmQNLRrj2FBN2Na9OVBvKbLODMzCFocISuq zrmA== X-Gm-Message-State: ACgBeo2VDCx2oygYSlL7Xk7XRD6d+HW+yVh8r7YXurxk8s56oN2lXWp5 eNTucfC/J3jmOEtpEs2k0zJNnZD3ZGbozLuuQJnLpg== X-Google-Smtp-Source: AA6agR6CCayhZnAMrxJ+v1bK9UJnwnwMBBlBDXq/U5wvwtoOFWPmWroCKCGDPD1Muwlj/dj3C1GkJk5po0HudLnx4iA= X-Received: by 2002:a25:8892:0:b0:66e:fe43:5aa0 with SMTP id d18-20020a258892000000b0066efe435aa0mr8893175ybl.445.1660940076645; Fri, 19 Aug 2022 13:14:36 -0700 (PDT) MIME-Version: 1.0 References: <20220810204750.3672362-1-bjorn.andersson@linaro.org> <20220810204750.3672362-2-bjorn.andersson@linaro.org> <20220814210104.GA690892-robh@kernel.org> In-Reply-To: From: Prashant Malani Date: Fri, 19 Aug 2022 13:14:25 -0700 Message-ID: Subject: Re: [PATCH 1/2] dt-bindings: usb: Introduce GPIO-based SBU mux To: Stephen Boyd Cc: Bjorn Andersson , Rob Herring , Krzysztof Kozlowski , Greg Kroah-Hartman , Krzysztof Kozlowski , Heikki Krogerus , linux-usb@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, Pin-yen Lin Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org > This would do that for us, but when all four lanes are connected from > the qmp phy directly to the connector we could just as easily have done > it with one endpoint. > > qmp_phy { > ports { > port@0 { > reg = <0>; > endpoint@0 { > reg = <0>; > remote-endpoint = <&usb_c_ss>; > data-lanes = <1 2 3 0> > }; > }; > }; > }; > > So should we explicitly have two endpoints in the usb-c-connector for > the two pairs all the time, or should we represent that via data-lanes > and only split up the connector's endpoint if we need to connect the > usb-c-connector to two different endpoints? I like 2 endpoints to represent the usb-c-connector, but that doesn't seem to be compatible (without introducing `data-lanes`, at least) with all the various combinations on the remote side, if that remote side is a DRM bridge with DP output capability (like it6505 or anx7625). That type of DRM bridge supports 1, 2 or 4 lane DP connections. So, how about 4 endpoints (1 for each SS lane) in the usb-c-connector port@1? That should support every conceivable configuration and bridge/PHY hardware. and also allows a way to specify any lane remapping (similar to what "data lanes" does) if that is required. Then we are consistent with what an endpoint represents, regardless of whether the DRM bridge has a DP panel (1,2 or 4 lane) or Type-C connector (2 or 4 lane) on its output side.