From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C91E812B94; Tue, 3 Sep 2024 15:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725377736; cv=none; b=syeMUOL912vhaKs8yqH0nOW8Nu9daVCTcp7Vm0+RJ9sHBdYvjbELSieWJnWW7XUVAgBN7fKBA75OxGzlPAYAoIFZPwryR6Y7ojx3e6zNKC601vUdkIsUI7cRstpLeDN/lu6rc3BqdjMlO2Mct1xtvJb90Ku7H+b8c6Jz6H2A8jQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1725377736; c=relaxed/simple; bh=t6e3G7q3f5emkzw8EoVbd6PITMUf/pOi2Q6k8ITflpc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Fj7JKTm5J7K1mabqGV48GIYryvM9t+rCfnnHFWpd4LXG7LWoBN9uVLBJs5n4dcd/zqhuGqaW2vYOirbfDIXwfjcFYS//1QbvfZmiHN8g3S8rWUJXqQAuIZvnKArEkmTNQsR2iuACr7e43weOR9SHMAYT4TO0v7UnCvBhbmVcuaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RYQ0vpG7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RYQ0vpG7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6DE50C4CEC4; Tue, 3 Sep 2024 15:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1725377736; bh=t6e3G7q3f5emkzw8EoVbd6PITMUf/pOi2Q6k8ITflpc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=RYQ0vpG7jRDFlWoikaPdbcFzrRbCnv2PbH5rQHxFbvKcnOxhBNAK+rOPKKXtezdwQ I5WqCJChbeZx3fc+P5yoEjoGJMBiNfup4Uqw1l3P9hvrjV7BrAZff5OChcp9LiPs+6 Fpz8EULJGifu7rnmXsGZi1T33dZr85Nx8+Rb/bHiVxVZ/TH07rDFT4szi2Y5CSYS/C 38E75nDJu1TFYB+7jxKYcgB/NwU1XJeUwV/rpTQqjeiwm2iYNTEQG7NK4YDbOaVLbx DAhQ20gAcW2E2kQI2EDS86aHnGrHLV7lLI/oxosVRXuSuFwcaKvaVG/OrweDLwecOx ncvVjHAoa76Bw== Date: Tue, 3 Sep 2024 16:35:26 +0100 From: Lee Jones To: Stephen Boyd Cc: chrome-platform@lists.linux.dev, linux-kernel@vger.kernel.org, patches@lists.linux.dev, devicetree@vger.kernel.org, Douglas Anderson , Pin-yen Lin , Andrzej Hajda , Benson Leung , Conor Dooley , Daniel Vetter , David Airlie , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, Guenter Roeck , Jernej Skrabec , Jonas Karlman , Krzysztof Kozlowski , Laurent Pinchart , Maarten Lankhorst , Maxime Ripard , Neil Armstrong , Prashant Malani , Robert Foss , Rob Herring , Thomas Zimmermann , Tzung-Bi Shih , Alexandre Belloni , Andy Shevchenko , Daniel Scally , Greg Kroah-Hartman , Heikki Krogerus , Ivan Orlov , linux-acpi@vger.kernel.org, linux-usb@vger.kernel.org, Mika Westerberg , "Rafael J . Wysocki" , Sakari Ailus , Vinod Koul , "Rob Herring (Arm)" Subject: Re: [PATCH v4 15/18] dt-bindings: usb: Add ports to google,cros-ec-typec for DP altmode Message-ID: <20240903153526.GA6858@google.com> References: <20240901040658.157425-1-swboyd@chromium.org> <20240901040658.157425-16-swboyd@chromium.org> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240901040658.157425-16-swboyd@chromium.org> On Sat, 31 Aug 2024, Stephen Boyd wrote: > Add a DT graph binding to google,cros-ec-typec so that it can combine > DisplayPort (DP) and USB SuperSpeed (SS) data into a USB type-c endpoint > that is connected to the usb-c-connector node's SS endpoint. This also > allows us to connect the DP and USB nodes in the graph to the USB type-c > connectors, providing the full picture of the USB type-c data flows in > the system. > > Allow there to be multiple typec nodes underneath the EC node so that > one DT graph exists per DP bridge. The EC is actually controlling TCPCs > and redrivers that combine the DP and USB signals together so this more > accurately reflects the hardware design without introducing yet another > DT node underneath the EC for USB type-c. > > If the type-c ports are being shared between a single DP controller then > the ports need to know about each other and determine a policy to drive > DP to one type-c port. If the type-c ports each have their own dedicated > DP controller then they're able to operate independently and enter/exit > DP altmode independently as well. We can't connect the DP controller's > endpoint to one usb-c-connector port@1 endpoint and the USB controller's > endpoint to another usb-c-connector port@1 endpoint either because the > DP muxing case would have DP connected to two usb-c-connector endpoints > which the graph binding doesn't support. > > Therefore, one typec node is required per the capabilities of the type-c > port(s) being managed. This also lets us indicate which type-c ports the > DP controller is wired to. For example, if DP was connected to ports 0 > and 2, while port 1 was connected to another DP controller we wouldn't > be able to implement that without having some other DT property to > indicate which output ports are connected to the DP endpoint. > > Reviewed-by: Rob Herring (Arm) > Cc: Krzysztof Kozlowski > Cc: Conor Dooley > Acked-by: Lee Jones > Cc: Benson Leung > Cc: Guenter Roeck > Cc: Prashant Malani > Cc: Tzung-Bi Shih > Cc: > Cc: > Cc: Pin-yen Lin > Signed-off-by: Stephen Boyd > --- > .../bindings/mfd/google,cros-ec.yaml | 7 +- Acked-by: Lee Jones > .../bindings/usb/google,cros-ec-typec.yaml | 229 ++++++++++++++++++ > 2 files changed, 233 insertions(+), 3 deletions(-) -- Lee Jones [李琼斯]