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 0A9CDC32773 for ; Fri, 19 Aug 2022 20:14:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351356AbiHSUOo (ORCPT ); Fri, 19 Aug 2022 16:14:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33476 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351210AbiHSUOk (ORCPT ); Fri, 19 Aug 2022 16:14:40 -0400 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E6E7C2775 for ; Fri, 19 Aug 2022 13:14:37 -0700 (PDT) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-3375488624aso120976257b3.3 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=A6xAYTGeUqAPed2ivOGZU+Rmyy32UHRgon8D/C3F9U2p6lhS0FCshyytQ3nAVhwftW BpFfsCT9rzqoDgRtuSdSfkZ2R6AnAOrOi9vSviWiIEsotxj96r9a/eE0s4t6saOOxA8O GjC74l+g44YEu9mz+Jwv7sCSgbQdnwV4u+OkV+vsho2gL3HJyqffq4zlnjDKSUkDQhj/ 152YYH/EY4osop/rci9X65rRNNBtiFhvMV9Mlh07OfOB9WjzK08O6jJfMUHC/QKdpEss EtiCamjyY5/n7mt1nGslcgtNZCvjLxNABvxOfQmoB6GVF6h2fh9eknwQ01YmnAAtEtgD 9V6Q== X-Gm-Message-State: ACgBeo3Ct5vuA6Y34BIYhWW0HYNmJToPC9NnB64P2p3EVE5XS6fTKBVG d3vhbotz/O6g/D+iYSXfTsA/vN3mttOKTLqAlXsz9g== 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-kernel@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.