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 CCE28C433EF for ; Mon, 13 Dec 2021 07:36:12 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 020CD82F3E; Mon, 13 Dec 2021 08:36:09 +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=1639380970; bh=ejja6xi5NqjBDq2QBHoUiftVcq3JRsSXAEOw9UEU7lA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=Tx1DrO6ycqgg5G0aDbocoL4NltmQxOF6zRF4JvSHj19MuJaXLfmB9VWEADlppxLUN 3TYqJQYrJa9r61yz8T1AMdlw0tUlURjTMQFtNPutwRPse1zipRFn/LRP4e/Xs32JMD Q3jaa123XirJhN8cpzZSYwuwjnMUVX3LKs+SZfG51VVhHFDf24CVkXDSD/oejQrv7M TB+daiLw65no4ClT24FyBYy7WPtx672gSlsl8Zwle+bO+T0WTCuHoEzor11vWz739P wl7nI3OP1a/BMJma7yN90ppAXfVceYOGm+ctcO7mLLQKlEEOOXRoH7Q7kENLiMIGzG G2e10fzB9NJfw== Received: by phobos.denx.de (Postfix, from userid 109) id 181B682F95; Mon, 13 Dec 2021 08:36:08 +0100 (CET) Received: from mout-u-107.mailbox.org (mout-u-107.mailbox.org [91.198.250.252]) (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 A108282C7D for ; Mon, 13 Dec 2021 08:36:04 +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 smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:105:465:1:4:0]) (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-107.mailbox.org (Postfix) with ESMTPS id 4JCCx03xMHzQjPq; Mon, 13 Dec 2021 08:36:04 +0100 (CET) Message-ID: Date: Mon, 13 Dec 2021 08:36:00 +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: <5ea0641f-cde6-e553-dfb8-993ab6daff67@denx.de> <20211123155953.4cuju6mtwgmrzumq@pali> <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> From: Stefan Roese In-Reply-To: <20211210142345.srrdifa3iejac5ml@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.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 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. 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