From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bjorn Helgaas Subject: Re: [PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194 Date: Tue, 2 Apr 2019 14:21:50 -0500 Message-ID: <20190402192150.GF141706@google.com> References: <1553613207-3988-1-git-send-email-vidyas@nvidia.com> <1553613207-3988-6-git-send-email-vidyas@nvidia.com> <20190328131508.GB5518@ulmo> <20190401150740.GB4874@ulmo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20190401150740.GB4874@ulmo> Sender: linux-kernel-owner@vger.kernel.org To: Thierry Reding Cc: Vidya Sagar , 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, 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, robh+dt@kernel.org, horms+renesas@verge.net.au, bjorn.andersson@linaro.org, ezequiel@collabora.com, linux-arm-kernel@lists.infradead.org List-Id: linux-tegra@vger.kernel.org On Mon, Apr 01, 2019 at 05:07:40PM +0200, Thierry Reding wrote: > On Mon, Apr 01, 2019 at 03:31:54PM +0530, Vidya Sagar wrote: > > On 3/28/2019 6:45 PM, Thierry Reding wrote: > > > On Tue, Mar 26, 2019 at 08:43:22PM +0530, Vidya Sagar wrote: > > > > Add support for Tegra194 PCIe controllers. These controllers are based > > > > on Synopsys DesignWare core IP. > > > > +- nvidia,disable-aspm-states : controls advertisement of ASPM states > > > > + 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 > > > > > > These seem more like configuration options rather than hardware > > > description. > > Yes. Since the platforms like Jetson-Xavier based on T194 are going to go in > > open market, we are providing these configuration options and hence they are > > optional > > Under what circumstances would we want to disable certain ASPM states? > My understanding is that PCI device drivers can already disable > individual ASPM states if they don't support them, so why would we ever > want to disable advertisement of certain ASPM states? The PCI core (not individual device drivers) configures ASPM, and if both ends of the link implement the spec correctly, there is nothing the device driver needs to do. There *are* a few drivers that fiddle with ASPM-related things. I think this is because either the core isn't doing things correctly and we haven't bothered to fix the root cause, or the device itself is broken and we need to disable something the hardware claims to support. Bjorn 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.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 82C2CC10F00 for ; Tue, 2 Apr 2019 19:21:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 4FC062084B for ; Tue, 2 Apr 2019 19:21:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554232915; bh=mUJl9GjIhaTcalhVS05kGWKKcfEf8ElNfTEsbhSNwf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=GYJaHKc/oa3/eH0wdwgfo+SmE4pbwXYr89wKX17etahsI45gzU/C6Qj+cyxQoSuz2 lHGzMNxOs8q4qSj3HqgymDMWkZedLUQeVQBlvIPCCSh5srijhtfUUQbL2DKtBYy4iy iVh+AUf8WHLk0WOAzpyrdtwli/JWUkIyAeDS275w= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730730AbfDBTVy (ORCPT ); Tue, 2 Apr 2019 15:21:54 -0400 Received: from mail.kernel.org ([198.145.29.99]:55902 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbfDBTVx (ORCPT ); Tue, 2 Apr 2019 15:21:53 -0400 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DA37F2082C; Tue, 2 Apr 2019 19:21:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554232912; bh=mUJl9GjIhaTcalhVS05kGWKKcfEf8ElNfTEsbhSNwf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N5P9FGFDbpYMpH0GL+c0OZBKn1SUopqqVSdewo44BeykQt+Xfim3gkd/68GSCicA4 LHrMrlSZ5+U4Adrd580pEILaiU6UxooXfuC6ntkvxHfLTWTa/EhToOFuLUMPfBEJzg qqUdZmQu3iipUTjblYjs7YV7uBrj7aIhZYn+wRq4= Date: Tue, 2 Apr 2019 14:21:50 -0500 From: Bjorn Helgaas To: Thierry Reding Cc: Vidya Sagar , 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, 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, robh+dt@kernel.org, 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 Subject: Re: [PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194 Message-ID: <20190402192150.GF141706@google.com> References: <1553613207-3988-1-git-send-email-vidyas@nvidia.com> <1553613207-3988-6-git-send-email-vidyas@nvidia.com> <20190328131508.GB5518@ulmo> <20190401150740.GB4874@ulmo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190401150740.GB4874@ulmo> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 01, 2019 at 05:07:40PM +0200, Thierry Reding wrote: > On Mon, Apr 01, 2019 at 03:31:54PM +0530, Vidya Sagar wrote: > > On 3/28/2019 6:45 PM, Thierry Reding wrote: > > > On Tue, Mar 26, 2019 at 08:43:22PM +0530, Vidya Sagar wrote: > > > > Add support for Tegra194 PCIe controllers. These controllers are based > > > > on Synopsys DesignWare core IP. > > > > +- nvidia,disable-aspm-states : controls advertisement of ASPM states > > > > + 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 > > > > > > These seem more like configuration options rather than hardware > > > description. > > Yes. Since the platforms like Jetson-Xavier based on T194 are going to go in > > open market, we are providing these configuration options and hence they are > > optional > > Under what circumstances would we want to disable certain ASPM states? > My understanding is that PCI device drivers can already disable > individual ASPM states if they don't support them, so why would we ever > want to disable advertisement of certain ASPM states? The PCI core (not individual device drivers) configures ASPM, and if both ends of the link implement the spec correctly, there is nothing the device driver needs to do. There *are* a few drivers that fiddle with ASPM-related things. I think this is because either the core isn't doing things correctly and we haven't bothered to fix the root cause, or the device itself is broken and we need to disable something the hardware claims to support. Bjorn 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.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 2E325C4360F for ; Tue, 2 Apr 2019 19:22:02 +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 EDF8D2082C for ; Tue, 2 Apr 2019 19:22:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Agb0FDZB"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="N5P9FGFD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EDF8D2082C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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-Transfer-Encoding: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-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=kUmL8HbLxS/KHefoYXtQk+v5GdmfFCu14m939E0kO60=; b=Agb0FDZBr9zWMw OJChIE4Chit8xNotTDsT0U/B2eawqLvX39PlafaO7UQ/JQzwXrb5ypSJD5AQFQONjUIlo/WxprdK3 pHeOChP0WXqUEDNdcNHWdznWs3XdXL01T+/5N06Sk0PzZTAlkWa6MtKcVK2uXu7ev2gFfRU3nChng Z4RWkYhroM3bZhVnMvC2mOlyN64mlMOgcGas6o0WF2TizhWoEcEytxkV+CLaR7ig2vCFjgpPcGFH8 GSzdodmI+9Xw27v4ySja8Z6/hZEj85ih/I4sZZ2wmz3+YSxLKc0qNsllp3kJFvgWmRZbdNqjgXK22 QXmyWlMKAccQt/zvnFcw==; 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 1hBOyq-0004qD-Hr; Tue, 02 Apr 2019 19:21:56 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hBOym-0004pT-Ld for linux-arm-kernel@lists.infradead.org; Tue, 02 Apr 2019 19:21:54 +0000 Received: from localhost (unknown [69.71.4.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id DA37F2082C; Tue, 2 Apr 2019 19:21:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554232912; bh=mUJl9GjIhaTcalhVS05kGWKKcfEf8ElNfTEsbhSNwf8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=N5P9FGFDbpYMpH0GL+c0OZBKn1SUopqqVSdewo44BeykQt+Xfim3gkd/68GSCicA4 LHrMrlSZ5+U4Adrd580pEILaiU6UxooXfuC6ntkvxHfLTWTa/EhToOFuLUMPfBEJzg qqUdZmQu3iipUTjblYjs7YV7uBrj7aIhZYn+wRq4= Date: Tue, 2 Apr 2019 14:21:50 -0500 From: Bjorn Helgaas To: Thierry Reding Subject: Re: [PATCH 05/10] dt-bindings: PCI: tegra: Add device tree support for T194 Message-ID: <20190402192150.GF141706@google.com> References: <1553613207-3988-1-git-send-email-vidyas@nvidia.com> <1553613207-3988-6-git-send-email-vidyas@nvidia.com> <20190328131508.GB5518@ulmo> <20190401150740.GB4874@ulmo> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190401150740.GB4874@ulmo> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190402_122152_748777_5EEF802D X-CRM114-Status: GOOD ( 16.36 ) 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, mperttunen@nvidia.com, jonathanh@nvidia.com, stefan.wahren@i2se.com, lorenzo.pieralisi@arm.com, krzk@kernel.org, kishon@ti.com, kthota@nvidia.com, 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, olof@lixom.net, robh+dt@kernel.org, linux-tegra@vger.kernel.org, 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, Vidya Sagar , skomatineni@nvidia.com, tiwai@suse.de, jingoohan1@gmail.com, enric.balletbo@collabora.com, l.stach@pengutronix.de, tpiepho@impinj.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Apr 01, 2019 at 05:07:40PM +0200, Thierry Reding wrote: > On Mon, Apr 01, 2019 at 03:31:54PM +0530, Vidya Sagar wrote: > > On 3/28/2019 6:45 PM, Thierry Reding wrote: > > > On Tue, Mar 26, 2019 at 08:43:22PM +0530, Vidya Sagar wrote: > > > > Add support for Tegra194 PCIe controllers. These controllers are based > > > > on Synopsys DesignWare core IP. > > > > +- nvidia,disable-aspm-states : controls advertisement of ASPM states > > > > + 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 > > > > > > These seem more like configuration options rather than hardware > > > description. > > Yes. Since the platforms like Jetson-Xavier based on T194 are going to go in > > open market, we are providing these configuration options and hence they are > > optional > > Under what circumstances would we want to disable certain ASPM states? > My understanding is that PCI device drivers can already disable > individual ASPM states if they don't support them, so why would we ever > want to disable advertisement of certain ASPM states? The PCI core (not individual device drivers) configures ASPM, and if both ends of the link implement the spec correctly, there is nothing the device driver needs to do. There *are* a few drivers that fiddle with ASPM-related things. I think this is because either the core isn't doing things correctly and we haven't bothered to fix the root cause, or the device itself is broken and we need to disable something the hardware claims to support. Bjorn _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel