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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F1DFAC433F5 for ; Mon, 29 Nov 2021 09:23:16 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 3321781EE5; Mon, 29 Nov 2021 10:23:14 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1638177794; bh=Euh4znwNNCWgT3t1IGQpdPW9sDc+MuuMbohJqJ2LZGc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=wDvov44jPyQ/r1STzutawfSNShTbb4WU6IrmblsMTGuhTm/hi3/09wGybch/nM4EU h5q2cU70c50Mnr3t/ezTtbXlnJ0HJc/ER548cJSi+M/cF0uy8Hm1aey9nm1hs9BQOx fg5R9EdWjl92XwcsTgKRByf5ZWSjVuXT0w4mUNXhZEJ+skmsgEug/vYb1A1E5rAUWW E5gNW9q+SGmFYj4Tc/PiXTBv8MY0oAuNJaOHct9VsXv6ZR/jWvI/MdE4FkkmQ8eY9I tm5zmwz9Elwd3+ElrZ3my80NXMGyEBFRdURuP2Mn8DGAspubanYlPkxJQmloCdZw9X AiJVdxstqqekA== Received: by phobos.denx.de (Postfix, from userid 109) id 5F8A18020E; Mon, 29 Nov 2021 10:23:06 +0100 (CET) Received: from mout-u-204.mailbox.org (mout-u-204.mailbox.org [IPv6:2001:67c:2050:1::465:204]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id F34B38020E for ; Mon, 29 Nov 2021 10:23:02 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp1.mailbox.org (unknown [91.198.250.123]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-204.mailbox.org (Postfix) with ESMTPS id 4J2fyt43QtzQjPq; Mon, 29 Nov 2021 10:23:02 +0100 (CET) Message-ID: <83bd5ea0-46ce-39be-d566-46c397db2037@denx.de> Date: Mon, 29 Nov 2021 10:22:58 +0100 MIME-Version: 1.0 Subject: Re: [PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c Content-Language: en-US To: =?UTF-8?Q?Pali_Roh=c3=a1r?= Cc: =?UTF-8?Q?Marek_Beh=c3=ban?= , u-boot@lists.denx.de, =?UTF-8?Q?Marek_Beh=c3=ban?= References: <20211111153549.29111-1-kabel@kernel.org> <20211111153549.29111-3-kabel@kernel.org> <20211118180103.wewgff3pqqrwqjxr@pali> <5ea0641f-cde6-e553-dfb8-993ab6daff67@denx.de> <20211123155953.4cuju6mtwgmrzumq@pali> <20211129090612.q3pdg64bhhk4gnvz@pali> From: Stefan Roese In-Reply-To: <20211129090612.q3pdg64bhhk4gnvz@pali> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.37 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean On 11/29/21 10:06, Pali Rohár wrote: >>> After this DTS change, pci-mvebu.c will just replace value of current >>> number of lanes (which is set to 4 by serdes code) to value from DTS, >>> which is 4. Therefore there should be no change. >>> >>> Could you test whole patch series with above DTS change if it works >>> properly on Theadorable board? >> >> Yes, I don't see any issues with this patchset applied plus this DT >> patch on theadorable. The PCIe links are up and with the correct width. >> >> What I'm wondering is, when exactly does the PCIe RP start the link >> establishment. In my case with AXP this is still in the AXP serdes code >> of course. But in the A38x code, it should be in the PCIe controller >> driver now AFAIU. I see that you configure the link width in the >> controller and do some other configuration (address windows etc), but >> at the end you "simply" wait for the link to come up via >> mvebu_pcie_wait_for_link(). I would have expected here some special >> command (config bit?) to the PCIe controller to start the link >> establishment. So when exactly does the A38x start this action? > > That is interesting question... While I'm reading it again, I really do > not know. Because you are right that mvebu_pcie_wait_for_link() is just > waiting for a link and it "magically" comes up. I have tested it on A385 > and it is stable with different Compex Atheros cards which caused issues > in past also on A3720. I would prefer, to fully understand when exactly the link establishment is started. Since this is crucial for the setup of the controller that needs to be done *before* the link starts to come up. Could you perhaps try to remove some of the register configurations in the MVEBU PCIe driver to see, if the link establishment relies on this register to be written to (e.g. PCI_EXP_LNKCAP)? Thanks, Stefan