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 X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E5000C4360F for ; Tue, 2 Apr 2019 14:20:43 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B5A0A2084B for ; Tue, 2 Apr 2019 14:20:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="pAWBt6C7"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="QtP1HU07" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B5A0A2084B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wwgiTrYiyxA/OE8LJFv3T1brYh9T6vWGiHWR3466h7Y=; b=pAWBt6C78pXeYSCB5Jxjhfcdh PthmxoiuJ2zkhUxnfVZ+G956tP0YYoaWspb01TE+V5SYuvAYWlfNvZhX97FsftQguPbvwISeEn+JP 7L0VKITPjbHegGF243FLo0SLYhUH03wypHQUJUygJF1veSBwWeMz0M8unsM+lRhdUiS36uk5ipbEF HfxRYH0Ep6CGZ2OrYWP6d5hlsqCXShq5LTR1zlHk+0pK0ColMbpYSpR+AY1JqwuMgwkcPvRa6dEjs 4V21S7w83i1m5UabK72og7u4pjPbrqNN5IKtCUH15Uhqg4pvRiidoPwuhLKGEhPIZcy/BRBlpdMzj NHwfVBVGg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBKHG-0008BG-Rm; Tue, 02 Apr 2019 14:20:38 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBKHD-00089u-7r for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 14:20:36 +0000 Received: by mail-wr1-x444.google.com with SMTP id h4so16876876wre.7 for ; Tue, 02 Apr 2019 07:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TpI16h+PlFg1hU2/fJYFvYepCCzxfoRKL7JIq6ujNJU=; b=QtP1HU079fPxHCjwWi5CTo2DP8u6vEpUEC0XS70CBGJhUgVfDp1pzgin8Z3ig7CgBp 33aox3LCa1bWLktwbFmuQMWdYSGJeXQ2UdTvd9rHNS03I9idAgqV7IAUT/+JgkpBCudv auLqobfZ6J3NrC2DGuzhZyv4yfhsafd2TAuwad0aru6bOQVKVAuzwZNhr3aO9o+W4TEz Bjf6a3vEDh8/ket8jkJiIqWPCh8q3kXqLNOfOY/lvlapHmE417gP6mugpFPPRDblin0O 5sOL8gRxiFeieKQDOJwbUt4rgbr1cymLAfwXRbreaJ6LMHWgYhQG5G12hwHq3UL4uKQa iNBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TpI16h+PlFg1hU2/fJYFvYepCCzxfoRKL7JIq6ujNJU=; b=WtN18G48s9GHBP/Dq3JpQuLNu5PiGA9xn9BxTSUCG9MEyTcjk3VYMuuTLPDtAVHohH rGcTJ6V+/W8OHoZKJbDvD1bITL+ViLJobZwk57+kdlUCr5R62YyIeGdaeJSwnRF+6wOM beIBGlKCbm/rG+YV0DK4KJpxGZlkekxsQBBeOMgKUkleakmpVFP+ThobFLAxGgnTviZk N0oxp0E0MU49STcISUBk747dOkPSEmFl5IJD/fxHLuIH0aRnVHmzHJm7sf0YKeFb/3IC o+wWRbr/4a9vUszNBpIsCihod+NUu1CxWELNA1zYQAoakF0TgYOi5qCc1R55fetAu9vK 5h3A== X-Gm-Message-State: APjAAAWpFjDTUPkNwgnFcVbPityfX3lTIn1/DAcMLDuYDsJPvxeje+ea jV214uAPCO7AcLS6MlWabMs= X-Google-Smtp-Source: APXvYqzG51o0bcOitf2R7Na+As0TF/NGsnHW3fWX9diQWQO1Gsq/6hEA4rmsLtz0uXcKlP2j4k8OcA== X-Received: by 2002:adf:ee91:: with SMTP id b17mr45510414wro.234.1554214833528; Tue, 02 Apr 2019 07:20:33 -0700 (PDT) Received: from localhost (pD9E51B25.dip0.t-ipconnect.de. [217.229.27.37]) by smtp.gmail.com with ESMTPSA id c189sm17272143wme.32.2019.04.02.07.20.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Apr 2019 07:20:32 -0700 (PDT) Date: Tue, 2 Apr 2019 16:20:31 +0200 From: Thierry Reding To: Vidya Sagar Subject: Re: [PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194 Message-ID: <20190402142031.GC8017@ulmo> References: <1553613207-3988-1-git-send-email-vidyas@nvidia.com> <1553613207-3988-6-git-send-email-vidyas@nvidia.com> <5ca06149.1c69fb81.720fd.79e1@mx.google.com> <5ef50168-2476-1088-7156-8a4488d7a2e1@nvidia.com> <20190401143138.GA4874@ulmo> <67f9b726-c075-0291-7777-8f10ecc9e29d@nvidia.com> MIME-Version: 1.0 In-Reply-To: <67f9b726-c075-0291-7777-8f10ecc9e29d@nvidia.com> User-Agent: Mutt/1.11.4 (2019-03-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_072035_280324_0E864D6B X-CRM114-Status: GOOD ( 34.96 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, heiko@sntech.de, hayashi.kunihiko@socionext.com, maxime.ripard@bootlin.com, catalin.marinas@arm.com, spujar@nvidia.com, will.deacon@arm.com, kthota@nvidia.com, mperttunen@nvidia.com, linux-tegra@vger.kernel.org, jonathanh@nvidia.com, stefan.wahren@i2se.com, Rob Herring , lorenzo.pieralisi@arm.com, krzk@kernel.org, kishon@ti.com, tiwai@suse.de, jagan@amarulasolutions.com, linux-pci@vger.kernel.org, andy.gross@linaro.org, shawn.lin@rock-chips.com, devicetree@vger.kernel.org, mmaddireddy@nvidia.com, marc.w.gonzalez@free.fr, liviu.dudau@arm.com, yue.wang@amlogic.com, enric.balletbo@collabora.com, bhelgaas@google.com, horms+renesas@verge.net.au, bjorn.andersson@linaro.org, ezequiel@collabora.com, linux-arm-kernel@lists.infradead.org, xiaowei.bao@nxp.com, gustavo.pimentel@synopsys.com, linux-kernel@vger.kernel.org, skomatineni@nvidia.com, jingoohan1@gmail.com, olof@lixom.net, tpiepho@impinj.com, l.stach@pengutronix.de Content-Type: multipart/mixed; boundary="===============4908425219518720631==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============4908425219518720631== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TiqCXmo5T1hvSQQg" Content-Disposition: inline --TiqCXmo5T1hvSQQg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 02, 2019 at 02:46:27PM +0530, Vidya Sagar wrote: > On 4/1/2019 8:01 PM, Thierry Reding wrote: > > On Mon, Apr 01, 2019 at 04:48:42PM +0530, Vidya Sagar wrote: > > > On 3/31/2019 12:12 PM, Rob Herring wrote: > > > > On Tue, Mar 26, 2019 at 08:43:22PM +0530, Vidya Sagar wrote: [...] > > > > > +Optional properties: > > > > > +- nvidia,max-speed: limits controllers max speed to this value. > > > > > + 1 - Gen-1 (2.5 GT/s) > > > > > + 2 - Gen-2 (5 GT/s) > > > > > + 3 - Gen-3 (8 GT/s) > > > > > + 4 - Gen-4 (16 GT/s) > > > > > +- nvidia,init-speed: limits controllers init speed to this value. > > > > > + 1 - Gen-1 (2. 5 GT/s) > > > > > + 2 - Gen-2 (5 GT/s) > > > > > + 3 - Gen-3 (8 GT/s) > > > > > + 4 - Gen-4 (16 GT/s) > > > >=20 > > > > Don't we have standard speed properties? > > > Not that I'm aware of. If you come across any, please do let me know = and > > > I'll change these. > >=20 > > See Documentation/devicetree/bindings/pci/pci.txt, max-link-speed. > > There's a standard of_pci_get_max_link_speed() property that reads it > > from device tree. > Thanks for the pointer. I'll switch to this in the next patch. >=20 > >=20 > > > > Why do we need 2 values? > > > max-speed configures the controller to advertise the speed mentioned = through > > > this flag, whereas, init-speed gets the link up at this speed and sof= tware > > > can further take the link speed to a different speed by retraining th= e link. > > > This is to give flexibility to developers depending on the platform. > >=20 > > This seems to me like overcomplicating things. Couldn't we do something > > like start in the slowest mode by default and then upgrade if endpoints > > support higher speeds? > >=20 > > I'm assuming that the maximum speed is already fixed by the IP hardware > > instantiation, so why would we want to limit it additionally? Similarly, > > what's the use-case for setting the initial link speed to something > > other than the lowest speed? > You are right that maximum speed supported by hardware is fixed and throu= gh > max-link-speed DT option, flexibility is given to limit it to the desired= speed > for a controller on a given platform. As mentioned in the documentation f= or max-link-speed, > this is a strategy to avoid unnecessary operation for unsupported link sp= eed. > There is no real use-case as such even for setting the initial link speed= , but it is > there to give flexibility (for any debugging) to get the link up at a cer= tain speed > and then take it to a higher speed at a later point of time. Please note = that, hardware > as such already has the capability to take the link to maximum speed agre= ed by both > upstream and downstream ports. 'nvidia,init-speed' is only to give more f= lexibility > while debugging. I'm OK to remove it if this is not adding much value her= e. If this is primarily used for debugging or troubleshooting, maybe making it a module parameter is a better choice? I can see how max-link-speed might be good in certain situations where a board layout may mandate that a link speed slower than the one supported by the hardware is used, but I can't imagine a case where the initial link speed would have to be limited based on the hardware designe. Rob, do you know of any other cases where something like this is being used? > > > > > +- nvidia,disable-aspm-states : controls advertisement of ASPM st= ates > > > > > + bit-0 to '1' : disables advertisement of ASPM-L0s > > > > > + bit-1 to '1' : disables advertisement of ASPM-L1. This also = disables > > > > > + advertisement of ASPM-L1.1 and ASPM-L1.2 > > > > > + bit-2 to '1' : disables advertisement of ASPM-L1.1 > > > > > + bit-3 to '1' : disables advertisement of ASPM-L1.2 > > > >=20 > > > > Seems like these too should be common. > > > This flag controls the advertisement of different ASPM states by root= port. > > > Again, I'm not aware of any common method for this. > >=20 > > rockchip-pcie-host.txt documents an "aspm-no-l0s" property that prevents > > the root complex from advertising L0s. Sounds like maybe following a > > similar scheme would be best for consistency. I think we'll also want > > these to be non-NVIDIA specific, so drop the "nvidia," prefix and maybe > > document them in pci.txt so that they can be more broadly used. > Since we have ASPM-L0s, L1, L1.1 and L1.2 states, I prefer to have just o= ne entry > with different bit positions indicating which particular state should not= be > advertised by root port. Do you see any particular advantage to have 4 di= fferent options? > If having one options is fine, I'll remove "nvidia," and document it in p= ci.txt. I don't care strongly either way. It's really up to Rob to decide. Thierry --TiqCXmo5T1hvSQQg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlyjb68ACgkQ3SOs138+ s6FD5w/+Ph9LQU8GQsXjPzIJIldfOH1kjDq6hK38fLuzrABjWSsrRFvEIA9bHgJq Nsd7KXtwEaqoL22mL9NfByIWWiWlnGBeAMdHJ/XXZOwAUp/O9+VVs3W9DEynSffr Y75gYnUoI4u0OmQKGHRyKItqY/X6ZgiOfUEZikk6FEgFqMB+POTnWIFVtFj7sal+ B6BRmyX7JG6/7uj+5fR4D8s86QFLkhGbLLvH4pCk/4j+BoMtgxWkfnm4UwIohI3M JUJ498e50Wkv4b22K6EfgRWm3UTIlEqYvi5UA2dc2WPX0YftobDjnOzxM+xTmaG6 jTqMI54S01tmj+pZ1MYb4v+rWfcnZzBYdFU1kYww6YD9iUtZRfZ0xlEx4x5/4yRK Yc7jXQIdcPe0Cim7i4Gynu+LgnIm15rwXX0o3MzvYze2GdQ1KRu3enOvJI0OqavQ wiF2X2835v6dvgFMlYM6RQRG2prakluLnop4EeWe/kZR0Dq/F1wcNR6mSht/7QjN lmbOTOPhc3FCpjV7iZp3ljEeRllOB7Ri4C6s+Byzy7Vix4wDlatEc7fHqDqVMlYz rnGvFY5WvmuBX5nzyYzy27R/u2VBKwzYO1aTid7FSAVO39cFV8BScHZSxIncnwSH q49nsxqe58i6IIFB2rI3iT+an+TBypraHkp7inpQdULp2Jcnj3U= =BIli -----END PGP SIGNATURE----- --TiqCXmo5T1hvSQQg-- --===============4908425219518720631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============4908425219518720631==--