[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190212174942.if2ene44f5m5mern@wunner.de>
Date: Tue, 12 Feb 2019 18:49:42 +0100
From: Lukas Wunner <lukas@...ner.de>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org,
Michael Jamet <michael.jamet@...el.com>,
Yehezkel Bernat <YehezkelShB@...il.com>,
Andreas Noever <andreas.noever@...il.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Subject: Re: [PATCH v2 16/28] thunderbolt: Discover preboot PCIe paths the
boot firmware established
On Wed, Feb 06, 2019 at 04:17:26PM +0300, Mika Westerberg wrote:
> /* dword 0 */
> hop.next_hop = path->hops[i].next_hop_index;
> hop.out_port = path->hops[i].out_port->port;
> - /* TODO: figure out why these are good values */
> - hop.initial_credits = (i == path->path_length - 1) ? 16 : 7;
> + hop.initial_credits = path->hops[i].initial_credits;
> hop.unknown1 = 0;
> hop.enable = 1;
[...]
> @@ -78,6 +78,74 @@ static void tb_pci_init_path(struct tb_path *path)
> path->weight = 1;
> path->drop_packages = 0;
> path->nfc_credits = 0;
> + path->hops[0].initial_credits = 7;
> + path->hops[1].initial_credits = 16;
I guess Andreas' algorithm (the last hop in the path is assigned
16 and all the ones before are assigned 7) was reverse-engineered
from Apple's driver. The fact that this algorithm works for paths
of arbitrary length could indicate that Apple indeed does establish
tunnels between non-adjacent switches.
Also, why are these good values? (You've deleted the comment.)
Thanks,
Lukas
Powered by blists - more mailing lists