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 0D5CFC433F5 for ; Mon, 13 Dec 2021 10:28:42 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1404682F3E; Mon, 13 Dec 2021 11:28:41 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="NYIBEnTs"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 768528069E; Mon, 13 Dec 2021 11:28:38 +0100 (CET) Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E9F1382F3E for ; Mon, 13 Dec 2021 11:28:33 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id AE17CCE0EE1; Mon, 13 Dec 2021 10:28:31 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9383DC34601; Mon, 13 Dec 2021 10:28:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1639391309; bh=50XVwuAh1azKpKVQETOvr/cM37f7CJkV25XhObHz4sI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=NYIBEnTsP16qIbI45ZDIhEo6zTJYXzgSe8Q7wOIQdaDDta5pwEnLR8eeQZHVz+bsQ RpV99dgdIgp2bw0RrqKt4st5w/2A2Piydz4Sh0/ln1XxTTt3Q8YrOPrA6MzhbytWeQ 8nsIHCYY1wHKEZPt6DOtQlFcbtjQJ+hQMvSoPtBUurmh+dhWKdUfgoDpQTIbvEPPz/ l3gJGKGcFc3Gpm+CqJtJ+jOdwnVl7TViH9mYc1KiceU+Y/RNYv0OdKpzAUcY7R8R8O iUG9OIUToGH+5OxXp95CNBeT41nfWI3uTttcdGrBSJUztEDciUP5F7biqj/wEJvTw2 xx8X5A3Ndedbg== Received: by pali.im (Postfix) id 72CD97DA; Mon, 13 Dec 2021 11:28:27 +0100 (CET) Date: Mon, 13 Dec 2021 11:28:27 +0100 From: Pali =?utf-8?B?Um9ow6Fy?= To: Stefan Roese Cc: Marek =?utf-8?B?QmVow7pu?= , u-boot@lists.denx.de, Marek =?utf-8?B?QmVow7pu?= Subject: Re: [PATCH u-boot-marvell 02/10] arm: mvebu: a38x: serdes: Move non-serdes PCIe code to pci_mvebu.c Message-ID: <20211213102827.xxque5x3l7lmjcnf@pali> References: <20211129090612.q3pdg64bhhk4gnvz@pali> <83bd5ea0-46ce-39be-d566-46c397db2037@denx.de> <20211129114701.evkol44t6l3rvdpf@pali> <20211129132748.5tt4x5rnoxusk5eu@pali> <20211129142845.c7keue6h5fvcnypj@pali> <1e69be57-ca7a-9b96-de47-7f3faf146a64@denx.de> <20211210142345.srrdifa3iejac5ml@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20180716 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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 Monday 13 December 2021 08:36:00 Stefan Roese wrote: > Hi Pali, > > On 12/10/21 15:23, Pali Rohár wrote: > > > > > > > > So I think the correct behavior should be: > > > > > > > > > > 1. pci-mvebu.c configures all controller registers to correct values > > > > > 2. PCIe port is enabled via SoC-specific register > > > > > 3. pci-mvebu.c waits for link up > > > > > > > > > > I guess that reset-controller does not help, as core release this reset > > > > > prior starting driver initialization. > > > > > > > > Ok, it looks like that reset controller API allows to do this. It would > > > > mean to define that "system-controller@18200" as reset controller, > > > > exports from it for each PCIe port reset functionality and implements > > > > assert and deassert functions which disable and enable port. > > > > > > > > And because DTS for pci-mvebu.c driver is defined as multi-root-port, > > > > "resets" property would need to be defined for each port separately. > > > > > > Okay. Sounds like a plan to me. > > > > I'm looking at this right now and it is even more complicated. For > > example Armada XP has for some ports dedicated enable bits and for some > > ports has just one shared enable bit. > > > > And this HW design does not fit into current U-Boot PCI DM model where > > for each PCIe port there is dedicated mvebu_pcie_probe() call which > > should setup PCIe port, enable PCIe port and returns once PCIe port is > > ready. In U-Boot PCI DM model is every PCIe port as separate DM device. > > > > Any idea how to solve this issue? > > Sorry, but I don't have clear "solution" for this in my mind right now. Ok, I will try to invent something... > Thanks, > Stefan > > > > > Just I'm not sure if this "enable port functionality" should be > > > > implemented via Reset Controller API... > > > > > > How else should / could this be done then? Do you have alterative ideas? > > > > > > Thanks, > > > Stefan > > > > > > > > Anyway, this A385 SoC Control 1 Register is at address 0x18204 which is > > > > > part of following device defined in kernel DTS file: > > > > > > > > > > systemc: system-controller@18200 { > > > > > compatible = "marvell,armada-380-system-controller", > > > > > "marvell,armada-370-xp-system-controller"; > > > > > reg = <0x18200 0x100>; > > > > > }; > > > > > > > > > > Linux kernel has driver for this DTS device is file: > > > > > arch/arm/mach-mvebu/system-controller.c > > > > > > > > > > U-Boot does not have any driver for this compatible string. > > > > > > > > > > So PCIe port enable/disable should be in this driver. I can write simple > > > > > driver also for U-Boot which can control this register. But I really do > > > > > not know which interface should it use. > > > > > > > > > > Has somebody else any idea? > > > > > > > > > > > I just looked into some Linux PCIe DT bindings and found e.g. this in > > > > > > the mediatek spec: > > > > > > > > > > > > Documentation/devicetree/bindings/pci/mediatek-pcie.txt > > > > > > ... > > > > > > Required properties for MT7623/MT2701: > > > > > > ... > > > > > > - resets: Must contain an entry for each entry in reset-names. > > > > > > See ../reset/reset.txt for details. > > > > > > - reset-names: Must be "pcie-rst0", "pcie-rst1", "pcie-rstN".. based on the > > > > > > number of root ports. > > > > > > ... > > > > > > resets = <&hifsys MT2701_HIFSYS_PCIE0_RST>, > > > > > > <&hifsys MT2701_HIFSYS_PCIE1_RST>, > > > > > > <&hifsys MT2701_HIFSYS_PCIE2_RST>; > > > > > > reset-names = "pcie-rst0", "pcie-rst1", "pcie-rst2"; > > > > > > phys = <&pcie0_phy PHY_TYPE_PCIE>, <&pcie1_phy PHY_TYPE_PCIE>, > > > > > > <&pcie2_phy PHY_TYPE_PCIE>; > > > > > > phy-names = "pcie-phy0", "pcie-phy1", "pcie-phy2"; > > > > > > > > > > > > > > > > > > And make sure in the serdes code keeps (or actively sets?) these PCIe > > > > > > ports into the reset state. The PCIe driver would then release the ports > > > > > > out of reset after their configuration. > > > > > > > > > > > > Or is some other serdes code missing in between "get PCIe port out of > > > > > > reset" and the MVEBU PCIe driver taking over the control? > > > > > > > > > > > > What do you think? I might be missing something here. > > > > > > > > > > > > Thanks, > > > > > > Stefan > > Viele Grüße, > Stefan Roese > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de