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 AFE2EC433EF for ; Wed, 30 Mar 2022 14:24:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1346825AbiC3O0a (ORCPT ); Wed, 30 Mar 2022 10:26:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245102AbiC3O0Y (ORCPT ); Wed, 30 Mar 2022 10:26:24 -0400 Received: from ns3.fnarfbargle.com (ns3.fnarfbargle.com [103.4.19.87]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0A9252B27F for ; Wed, 30 Mar 2022 07:24:38 -0700 (PDT) Received: from [10.8.0.1] (helo=srv.home) by ns3.fnarfbargle.com with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nZZFU-0004Nk-HQ; Thu, 31 Mar 2022 00:24:36 +1000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fnarfbargle.com; s=mail; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:References:Cc:To:Subject:From:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=kEnTz9AB7j594d5zirVLoMS5a5W3p3Vab2t0y5WVYfs=; b=LMZmUbV0pDHHcVPCZfEwhogPN2 JHPGSVulOHcyBWzilCjDf38r4qukc422I5Aqw6qvIqTub9tJBQWwr5b2lrZoFiIPYj9IwJpp4gx35 0Ij0tap/RXSimDNAeuR894rDAEDqsNAupnxuxg3LnKWKQsfu30hj1MP1ejYXWsLwYRGY=; Message-ID: Date: Wed, 30 Mar 2022 22:24:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 From: Brad Campbell Subject: Re: Apple Thunderbolt Display chaining To: Mika Westerberg Cc: linux-kernel@vger.kernel.org References: <0249a7da-9237-806b-b267-7911ad40f4a0@fnarfbargle.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 30/3/22 21:43, Mika Westerberg wrote: > Hi, > > On Wed, Mar 30, 2022 at 09:19:52PM +0800, Brad Campbell wrote: >> Hey Mika, >> >> On 30/3/22 18:18, Mika Westerberg wrote: >>> Hi, >>> >>> On Tue, Mar 29, 2022 at 10:06:35PM +0800, Brad Campbell wrote: >>>>> Indeed, I did not add this to the "discovery" path yet. >>>>> >>>>> I wonder what happens if you change this: >>>>> >>>>> + tunnel = tb_tunnel_alloc_dp(tb, in, out, available_up, available_down, >>>>> + first ? 0 : 1); >>>>> >>>>> to this in your tree: >>>>> >>>>> + tunnel = tb_tunnel_alloc_dp(tb, in, out, available_up, available_down, >>>>> + first ? 1 : 0); >>>>> >>>> >>>> Here's where it gets all "Apple..y". On the iMac this does the job no matter which >>>> port the chain is plugged into. Boots and displays correctly first time, every time. >>>> >>>> It turns out on the laptop, one port works and the other doesn't. Changing the order >>>> simply changes which port works. So I assume the EFI sets up the first display using >>>> the first lane if it's in the first port, and the second if it's in the second. >>>> >>>> That means had I managed to perform the first test in the "other port" consistently, >>>> it would have worked there also. >>> >>> Can you try the below patch too? I hard-code the lane based on the >>> DP adapter number in TBT gen1. >>> >>> Let's first figure out proper solution to this issue and then look at >>> the other one. >>> >>> diff --git a/drivers/thunderbolt/tunnel.c b/drivers/thunderbolt/tunnel.c >>> index a473cc7d9a8d..97d36a7bb527 100644 >>> --- a/drivers/thunderbolt/tunnel.c >>> +++ b/drivers/thunderbolt/tunnel.c >>> @@ -865,6 +865,7 @@ struct tb_tunnel *tb_tunnel_alloc_dp(struct tb *tb, struct tb_port *in, >> >> This one works from cold boot on both machines regardless of the port the chain is plugged into. >> It fails on both machines on any hotplug with the symptoms of allocating them both the same link. >> I added an extra debug into tunnel.c and verified that. > > Hm, okay. What if you change this: > > link_nr = in->port == 11 ? 1 : 0; > > to this > > link_nr = in->port == 11 ? 0 : 1; > > Please also keep the debugging you added too so we can see if it now > uses both lanes. > Nope, that did the same thing. I wonder though. I'm testing it on the laptop and that reports : [ 0.442832] thunderbolt 0000:07:00.0: Thunderbolt 2 Switch: 8086:156d (Revision: 0, TB Version: 2) Changing "if (in->sw->generation == 1)" to "if (in->sw->generation == 2)" on the laptop solves that. I can't test hotplug properly on the iMac due to the radeon training issue. The laptop still has the issue of a cold boot working in one socket and not the other, but hot plug is working correctly. Regards, Brad