From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liviu Dudau Subject: Re: [PATCH 09/10] PCI: tegra: Add Tegra194 PCIe support Date: Wed, 10 Apr 2019 09:14:48 +0100 Message-ID: <20190410081448.GC15144@e110455-lin.cambridge.arm.com> References: <20190329203159.GG24180@google.com> <5eb9599c-a6d6-d3a3-beef-5225ed7393f9@nvidia.com> <20190402183110.GE141706@google.com> <20190403173641.GI141706@google.com> <6cc7e047-bc7e-fa60-88ba-0b69c3d5a3f0@nvidia.com> <20190405185842.GC26522@google.com> <40c97eaa-e37e-860e-111d-879a135d9f51@nvidia.com> <20190409132604.GA256045@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Vidya Sagar Cc: Bjorn Helgaas , robh+dt@kernel.org, mark.rutland@arm.com, thierry.reding@gmail.com, jonathanh@nvidia.com, kishon@ti.com, catalin.marinas@arm.com, will.deacon@arm.com, lorenzo.pieralisi@arm.com, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, mperttunen@nvidia.com, tiwai@suse.de, spujar@nvidia.com, skomatineni@nvidia.com, krzk@kernel.org, heiko@sntech.de, horms+renesas@verge.net.au, olof@lixom.net, maxime.ripard@bootlin.com, andy.gross@linaro.org, bjorn.andersson@linaro.org, jagan@amarulasolutions.com, enric.balletbo@collabora.com, ezequiel@collabora.com, stefan.wahren@i2se.com, marc.w.gonzalez@free.fr, l.stach@pengutronix.de, tpiepho@impinj.com, hayashi.kunihiko@socionext.com, yue.wang@amlogic.com, shawn.lin@rock-chips.com, xiaowei.bao@nxp.com List-Id: linux-tegra@vger.kernel.org On Wed, Apr 10, 2019 at 11:40:40AM +0530, Vidya Sagar wrote: > On 4/9/2019 6:56 PM, Bjorn Helgaas wrote: > > On Tue, Apr 09, 2019 at 05:00:53PM +0530, Vidya Sagar wrote: > > > On 4/6/2019 12:28 AM, Bjorn Helgaas wrote: > > > > On Fri, Apr 05, 2019 at 01:23:51AM +0530, Vidya Sagar wrote: > > > > > On 4/3/2019 11:06 PM, Bjorn Helgaas wrote: > > > > > > On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote: > > > > > > > On 4/3/2019 12:01 AM, Bjorn Helgaas wrote: > > > > > > > > On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote: > > > > > > > > > On 3/30/2019 2:22 AM, Bjorn Helgaas wrote: > > > > > > > > > > On Tue, Mar 26, 2019 at 08:43:26PM +0530, Vidya Sagar wrote: > > > > > > > > > > > Add support for Synopsys DesignWare core IP based PCIe host controller > > > > > > > > > > > present in Tegra194 SoC. > > > > > > > > > > > > > > > > - Why does this chip require pcie_pme_disable_msi()? The only other > > > > > > > > use is a DMI quirk for "MSI Wind U-100", added by c39fae1416d5 > > > > > > > > ("PCI PM: Make it possible to force using INTx for PCIe PME > > > > > > > > signaling"). > > > > > > > > > > > > > > Because Tegra194 doesn't support raising PME interrupts through MSI line. > > > > > > There's something wrong here. Either the question of how PME is > > > > signaled is generic and the spec provides a way for the OS to discover > > > > that method, or it's part of the device-specific architecture that > > > > each host bridge driver has to know about its device. If the former, > > > > we need to make the PCI core smart enough to figure it out. If the > > > > latter, we need a better interface than this ad hoc > > > > pcie_pme_disable_msi() thing. But if it is truly the latter, your > > > > current code is sufficient and we can refine it over time. > > > > > > In case of Tegra194, it is the latter case. > > > > This isn't a Tegra194 question; it's a question of whether this > > behavior is covered by the PCIe spec. > AFAIU the spec and what I heard from Nvidia hardware folks is that spec doesn't > explicitly talk about this and it was a design choice made by Nvidia hardware > folks to route these interrupts through legacy line instead of MSI line. > > > > > > > What I suspect should happen eventually is the DWC driver should call > > > > devm_pci_alloc_host_bridge() directly, as all the non-DWC drivers do. > > > > That would require a little reorganization of the DWC data structures, > > > > but it would be good to be more consistent. > > > > > > > > For now, I think stashing the pointer in pcie_port or dw_pcie would be > > > > OK. I'm not 100% clear on the difference, but it looks like either > > > > should be common across all the DWC drivers, which is what we want. > > > > > > Since dw_pcie is common for both root port and end point mode structures, > > > I think it makes sense to keep the pointer in pcie_port as this structure > > > is specific to root port mode of operation. > > > I'll make a note to reorganize code to have devm_pci_alloc_host_bridge() > > > used in the beginning itself to be inline with non-DWC implementations. > > > But, I'll take it up later (after I'm done with upstreaming current series) > > > > Fair enough. > > > > > > > .remove() internally calls pm_runtime_put_sync() API which calls > > > > > .runtime_suspend(). I made a new patch to add a host_deinit() call > > > > > which make all these calls. Since host_init() is called from inside > > > > > .runtime_resume() of this driver, to be in sync, I'm now calling > > > > > host_deinit() from inside .runtime_suspend() API. > > > > > > > > I think this is wrong. pci_stop_root_bus() will detach all the > > > > drivers from all the devices. We don't want to do that if we're > > > > merely runtime suspending the host bridge, do we? > > > > > > In the current driver, the scenarios in which .runtime_suspend() is called > > > are > > > a) during .remove() call and > > > > It makes sense that you should call pci_stop_root_bus() during > > .remove(), i.e., when the host controller driver is being removed, > > because the PCI bus will no longer be accessible. I think you should > > call it *directly* from tegra_pcie_dw_remove() because that will match > > what other drivers do. > > > > > b) when there is no endpoint found and controller would be shutdown > > > In both cases, it is required to stop the root bus and remove all devices, > > > so, instead of having same call present in respective paths, I kept them > > > in .runtime_suspend() itself to avoid code duplication. > > > > I don't understand this part. We should be able to runtime suspend > > the host controller without detaching drivers for child devices. > > > > If you shutdown the controller completely and detach the *host > > controller driver*, sure, it makes sense to detach drivers from child > > devices. But that would be handled by the host controller .remove() > > method, not by the runtime suspend method. > I think it is time I give some background about why I chose to implement > .runtime_suspend() and .runtime_resume() APIs in the first place. We wanted to > powerdown PCIe controller if there is no link up (i.e. slot is open and no endpoint > devices are connected). We want to achieve this without returning a failure in > .probe() call. Given PCIe IP power partitioning is handled by generic power domain > framework, power partition gets unpowergated before .probe() gets called and gets > powergated either when a failure is returned in .probe() or when pm_runtime_put_sync() > is called. So, I chose to call pm_runtime_put_sync() in no-link-up scenario and chose > to implement .runtime_suspend() to handle all the cleanup work before PCIe partition > getting powergated. In fact, to match this, I'm doing all the PCIe IP bring up > activity in .runtime_resume() implementation which gets invoked by pm_runtime_get_sync() > which in turn is called in .probe() path. In fact the very dw_pcie_host_init() itself > is called from .runtime_resume() implementation. So, it is because of these reasons that > I called pci_stop_root_bus() and pci_remove_root_bus() as part of .runtime_suspend() > implementation as pm_runtime_put_sync() is called from both .remove() and also during > no-link-up scenario. Please do let me know if there is a better way to do this. I think you're missing the case where .runtime_suspend() is called when there are no *active* devices on the bus, i.e. everyone is dormant. It doesn't mean that you need to remove them from the bus and re-probe them back on .runtime_resume(). Most of the drivers for PCI devices don't expect to be removed during idle, as they will configure the hardware to be in a "quick wake" state (see PCIe Dx power states). You should probe and configure the bus during .probe() and remove and detach all drivers during .remove(). For .runtime_suspend() all you need to do is put the host controller in low power mode if it has one, or stop all clocks that are not required for responding to devices waking up from PCIe Dx state. For .runtime_resume() you then restore the clocks, without re-scanning the bus. Best regards, Liviu > > > > > Bjorn > > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ 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=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 66382C10F11 for ; Wed, 10 Apr 2019 08:14:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2178D204FD for ; Wed, 10 Apr 2019 08:14:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729118AbfDJIOw (ORCPT ); Wed, 10 Apr 2019 04:14:52 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:49564 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727042AbfDJIOv (ORCPT ); Wed, 10 Apr 2019 04:14:51 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DDE49A78; Wed, 10 Apr 2019 01:14:50 -0700 (PDT) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8884C3F718; Wed, 10 Apr 2019 01:14:50 -0700 (PDT) Received: by e110455-lin.cambridge.arm.com (Postfix, from userid 1000) id DB94E682408; Wed, 10 Apr 2019 09:14:48 +0100 (BST) Date: Wed, 10 Apr 2019 09:14:48 +0100 From: Liviu Dudau To: Vidya Sagar Cc: Bjorn Helgaas , robh+dt@kernel.org, mark.rutland@arm.com, thierry.reding@gmail.com, jonathanh@nvidia.com, kishon@ti.com, catalin.marinas@arm.com, will.deacon@arm.com, lorenzo.pieralisi@arm.com, jingoohan1@gmail.com, gustavo.pimentel@synopsys.com, mperttunen@nvidia.com, tiwai@suse.de, spujar@nvidia.com, skomatineni@nvidia.com, krzk@kernel.org, heiko@sntech.de, horms+renesas@verge.net.au, olof@lixom.net, maxime.ripard@bootlin.com, andy.gross@linaro.org, bjorn.andersson@linaro.org, jagan@amarulasolutions.com, enric.balletbo@collabora.com, ezequiel@collabora.com, stefan.wahren@i2se.com, marc.w.gonzalez@free.fr, l.stach@pengutronix.de, tpiepho@impinj.com, hayashi.kunihiko@socionext.com, yue.wang@amlogic.com, shawn.lin@rock-chips.com, xiaowei.bao@nxp.com, devicetree@vger.kernel.org, mmaddireddy@nvidia.com, kthota@nvidia.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH 09/10] PCI: tegra: Add Tegra194 PCIe support Message-ID: <20190410081448.GC15144@e110455-lin.cambridge.arm.com> References: <20190329203159.GG24180@google.com> <5eb9599c-a6d6-d3a3-beef-5225ed7393f9@nvidia.com> <20190402183110.GE141706@google.com> <20190403173641.GI141706@google.com> <6cc7e047-bc7e-fa60-88ba-0b69c3d5a3f0@nvidia.com> <20190405185842.GC26522@google.com> <40c97eaa-e37e-860e-111d-879a135d9f51@nvidia.com> <20190409132604.GA256045@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 10, 2019 at 11:40:40AM +0530, Vidya Sagar wrote: > On 4/9/2019 6:56 PM, Bjorn Helgaas wrote: > > On Tue, Apr 09, 2019 at 05:00:53PM +0530, Vidya Sagar wrote: > > > On 4/6/2019 12:28 AM, Bjorn Helgaas wrote: > > > > On Fri, Apr 05, 2019 at 01:23:51AM +0530, Vidya Sagar wrote: > > > > > On 4/3/2019 11:06 PM, Bjorn Helgaas wrote: > > > > > > On Wed, Apr 03, 2019 at 03:13:09PM +0530, Vidya Sagar wrote: > > > > > > > On 4/3/2019 12:01 AM, Bjorn Helgaas wrote: > > > > > > > > On Tue, Apr 02, 2019 at 12:47:48PM +0530, Vidya Sagar wrote: > > > > > > > > > On 3/30/2019 2:22 AM, Bjorn Helgaas wrote: > > > > > > > > > > On Tue, Mar 26, 2019 at 08:43:26PM +0530, Vidya Sagar wrote: > > > > > > > > > > > Add support for Synopsys DesignWare core IP based PCIe host controller > > > > > > > > > > > present in Tegra194 SoC. > > > > > > > > > > > > > > > > - Why does this chip require pcie_pme_disable_msi()? The only other > > > > > > > > use is a DMI quirk for "MSI Wind U-100", added by c39fae1416d5 > > > > > > > > ("PCI PM: Make it possible to force using INTx for PCIe PME > > > > > > > > signaling"). > > > > > > > > > > > > > > Because Tegra194 doesn't support raising PME interrupts through MSI line. > > > > > > There's something wrong here. Either the question of how PME is > > > > signaled is generic and the spec provides a way for the OS to discover > > > > that method, or it's part of the device-specific architecture that > > > > each host bridge driver has to know about its device. If the former, > > > > we need to make the PCI core smart enough to figure it out. If the > > > > latter, we need a better interface than this ad hoc > > > > pcie_pme_disable_msi() thing. But if it is truly the latter, your > > > > current code is sufficient and we can refine it over time. > > > > > > In case of Tegra194, it is the latter case. > > > > This isn't a Tegra194 question; it's a question of whether this > > behavior is covered by the PCIe spec. > AFAIU the spec and what I heard from Nvidia hardware folks is that spec doesn't > explicitly talk about this and it was a design choice made by Nvidia hardware > folks to route these interrupts through legacy line instead of MSI line. > > > > > > > What I suspect should happen eventually is the DWC driver should call > > > > devm_pci_alloc_host_bridge() directly, as all the non-DWC drivers do. > > > > That would require a little reorganization of the DWC data structures, > > > > but it would be good to be more consistent. > > > > > > > > For now, I think stashing the pointer in pcie_port or dw_pcie would be > > > > OK. I'm not 100% clear on the difference, but it looks like either > > > > should be common across all the DWC drivers, which is what we want. > > > > > > Since dw_pcie is common for both root port and end point mode structures, > > > I think it makes sense to keep the pointer in pcie_port as this structure > > > is specific to root port mode of operation. > > > I'll make a note to reorganize code to have devm_pci_alloc_host_bridge() > > > used in the beginning itself to be inline with non-DWC implementations. > > > But, I'll take it up later (after I'm done with upstreaming current series) > > > > Fair enough. > > > > > > > .remove() internally calls pm_runtime_put_sync() API which calls > > > > > .runtime_suspend(). I made a new patch to add a host_deinit() call > > > > > which make all these calls. Since host_init() is called from inside > > > > > .runtime_resume() of this driver, to be in sync, I'm now calling > > > > > host_deinit() from inside .runtime_suspend() API. > > > > > > > > I think this is wrong. pci_stop_root_bus() will detach all the > > > > drivers from all the devices. We don't want to do that if we're > > > > merely runtime suspending the host bridge, do we? > > > > > > In the current driver, the scenarios in which .runtime_suspend() is called > > > are > > > a) during .remove() call and > > > > It makes sense that you should call pci_stop_root_bus() during > > .remove(), i.e., when the host controller driver is being removed, > > because the PCI bus will no longer be accessible. I think you should > > call it *directly* from tegra_pcie_dw_remove() because that will match > > what other drivers do. > > > > > b) when there is no endpoint found and controller would be shutdown > > > In both cases, it is required to stop the root bus and remove all devices, > > > so, instead of having same call present in respective paths, I kept them > > > in .runtime_suspend() itself to avoid code duplication. > > > > I don't understand this part. We should be able to runtime suspend > > the host controller without detaching drivers for child devices. > > > > If you shutdown the controller completely and detach the *host > > controller driver*, sure, it makes sense to detach drivers from child > > devices. But that would be handled by the host controller .remove() > > method, not by the runtime suspend method. > I think it is time I give some background about why I chose to implement > .runtime_suspend() and .runtime_resume() APIs in the first place. We wanted to > powerdown PCIe controller if there is no link up (i.e. slot is open and no endpoint > devices are connected). We want to achieve this without returning a failure in > .probe() call. Given PCIe IP power partitioning is handled by generic power domain > framework, power partition gets unpowergated before .probe() gets called and gets > powergated either when a failure is returned in .probe() or when pm_runtime_put_sync() > is called. So, I chose to call pm_runtime_put_sync() in no-link-up scenario and chose > to implement .runtime_suspend() to handle all the cleanup work before PCIe partition > getting powergated. In fact, to match this, I'm doing all the PCIe IP bring up > activity in .runtime_resume() implementation which gets invoked by pm_runtime_get_sync() > which in turn is called in .probe() path. In fact the very dw_pcie_host_init() itself > is called from .runtime_resume() implementation. So, it is because of these reasons that > I called pci_stop_root_bus() and pci_remove_root_bus() as part of .runtime_suspend() > implementation as pm_runtime_put_sync() is called from both .remove() and also during > no-link-up scenario. Please do let me know if there is a better way to do this. I think you're missing the case where .runtime_suspend() is called when there are no *active* devices on the bus, i.e. everyone is dormant. It doesn't mean that you need to remove them from the bus and re-probe them back on .runtime_resume(). Most of the drivers for PCI devices don't expect to be removed during idle, as they will configure the hardware to be in a "quick wake" state (see PCIe Dx power states). You should probe and configure the bus during .probe() and remove and detach all drivers during .remove(). For .runtime_suspend() all you need to do is put the host controller in low power mode if it has one, or stop all clocks that are not required for responding to devices waking up from PCIe Dx state. For .runtime_resume() you then restore the clocks, without re-scanning the bus. Best regards, Liviu > > > > > Bjorn > > > -- ==================== | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --------------- ¯\_(ツ)_/¯ 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,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 A2146C10F11 for ; Wed, 10 Apr 2019 08:14:56 +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 6F6C8204FD for ; Wed, 10 Apr 2019 08:14:56 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="OpaF/VGK" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6F6C8204FD Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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-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=7okeylQd1OfiiowcEVDT6lX8HN4SaipXnWN0VFJ5XrU=; b=OpaF/VGKT3WC3Q w+tJt7B10o+Os9M0rbBg+7+/mcqz74Dzzb8jM4BQN2GtKEij62t5i0nPK9yn3cZ3wO3ZKF2LVo8mc /W+DPRvqH+YWIHqaY3QDlmtArRc39XB0nPMnnLdrlfC3oEyd9OtXJ4U4QCZiX2D9Fde85l5OqQiiA kDsUm6g3jNFSKPFpTQIg0w+ewNnmCQfK661LpsUGE1T4jumvXEvGNw5tiyRF6CVo4+LrdvAzq4JbK BZt+4XKjwdHMBuACYsFWm/1Nd6u2Y4t8CgqJ0peDJ7WRC1brotTc7SWN1lFQXDpknqT0Cogn6dfEe tvB5BwuWFt1vsz5tCGLg==; 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 1hE8Nj-0003sP-S4; Wed, 10 Apr 2019 08:14:55 +0000 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70] helo=foss.arm.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hE8Nh-0003s0-DV for linux-arm-kernel@lists.infradead.org; Wed, 10 Apr 2019 08:14:55 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DDE49A78; Wed, 10 Apr 2019 01:14:50 -0700 (PDT) Received: from e110455-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8884C3F718; Wed, 10 Apr 2019 01:14:50 -0700 (PDT) Received: by e110455-lin.cambridge.arm.com (Postfix, from userid 1000) id DB94E682408; Wed, 10 Apr 2019 09:14:48 +0100 (BST) Date: Wed, 10 Apr 2019 09:14:48 +0100 From: Liviu Dudau To: Vidya Sagar Subject: Re: [PATCH 09/10] PCI: tegra: Add Tegra194 PCIe support Message-ID: <20190410081448.GC15144@e110455-lin.cambridge.arm.com> References: <20190329203159.GG24180@google.com> <5eb9599c-a6d6-d3a3-beef-5225ed7393f9@nvidia.com> <20190402183110.GE141706@google.com> <20190403173641.GI141706@google.com> <6cc7e047-bc7e-fa60-88ba-0b69c3d5a3f0@nvidia.com> <20190405185842.GC26522@google.com> <40c97eaa-e37e-860e-111d-879a135d9f51@nvidia.com> <20190409132604.GA256045@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: 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-20190410_011453_468950_89EADB1B X-CRM114-Status: GOOD ( 46.15 ) 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, tiwai@suse.de, catalin.marinas@arm.com, spujar@nvidia.com, will.deacon@arm.com, kthota@nvidia.com, mperttunen@nvidia.com, thierry.reding@gmail.com, jonathanh@nvidia.com, stefan.wahren@i2se.com, lorenzo.pieralisi@arm.com, krzk@kernel.org, kishon@ti.com, maxime.ripard@bootlin.com, Bjorn Helgaas , 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, yue.wang@amlogic.com, enric.balletbo@collabora.com, 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, skomatineni@nvidia.com, jingoohan1@gmail.com, olof@lixom.net, tpiepho@impinj.com, l.stach@pengutronix.de Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBBcHIgMTAsIDIwMTkgYXQgMTE6NDA6NDBBTSArMDUzMCwgVmlkeWEgU2FnYXIgd3Jv dGU6Cj4gT24gNC85LzIwMTkgNjo1NiBQTSwgQmpvcm4gSGVsZ2FhcyB3cm90ZToKPiA+IE9uIFR1 ZSwgQXByIDA5LCAyMDE5IGF0IDA1OjAwOjUzUE0gKzA1MzAsIFZpZHlhIFNhZ2FyIHdyb3RlOgo+ ID4gPiBPbiA0LzYvMjAxOSAxMjoyOCBBTSwgQmpvcm4gSGVsZ2FhcyB3cm90ZToKPiA+ID4gPiBP biBGcmksIEFwciAwNSwgMjAxOSBhdCAwMToyMzo1MUFNICswNTMwLCBWaWR5YSBTYWdhciB3cm90 ZToKPiA+ID4gPiA+IE9uIDQvMy8yMDE5IDExOjA2IFBNLCBCam9ybiBIZWxnYWFzIHdyb3RlOgo+ ID4gPiA+ID4gPiBPbiBXZWQsIEFwciAwMywgMjAxOSBhdCAwMzoxMzowOVBNICswNTMwLCBWaWR5 YSBTYWdhciB3cm90ZToKPiA+ID4gPiA+ID4gPiBPbiA0LzMvMjAxOSAxMjowMSBBTSwgQmpvcm4g SGVsZ2FhcyB3cm90ZToKPiA+ID4gPiA+ID4gPiA+IE9uIFR1ZSwgQXByIDAyLCAyMDE5IGF0IDEy OjQ3OjQ4UE0gKzA1MzAsIFZpZHlhIFNhZ2FyIHdyb3RlOgo+ID4gPiA+ID4gPiA+ID4gPiBPbiAz LzMwLzIwMTkgMjoyMiBBTSwgQmpvcm4gSGVsZ2FhcyB3cm90ZToKPiA+ID4gPiA+ID4gPiA+ID4g PiBPbiBUdWUsIE1hciAyNiwgMjAxOSBhdCAwODo0MzoyNlBNICswNTMwLCBWaWR5YSBTYWdhciB3 cm90ZToKPiA+ID4gPiA+ID4gPiA+ID4gPiA+IEFkZCBzdXBwb3J0IGZvciBTeW5vcHN5cyBEZXNp Z25XYXJlIGNvcmUgSVAgYmFzZWQgUENJZSBob3N0IGNvbnRyb2xsZXIKPiA+ID4gPiA+ID4gPiA+ ID4gPiA+IHByZXNlbnQgaW4gVGVncmExOTQgU29DLgo+ID4gPiA+ID4gPiA+ID4gCj4gPiA+ID4g PiA+ID4gPiAgICAgICAtIFdoeSBkb2VzIHRoaXMgY2hpcCByZXF1aXJlIHBjaWVfcG1lX2Rpc2Fi bGVfbXNpKCk/ICBUaGUgb25seSBvdGhlcgo+ID4gPiA+ID4gPiA+ID4gICAgICAgICB1c2UgaXMg YSBETUkgcXVpcmsgZm9yICJNU0kgV2luZCBVLTEwMCIsIGFkZGVkIGJ5IGMzOWZhZTE0MTZkNQo+ ID4gPiA+ID4gPiA+ID4gICAgICAgICAoIlBDSSBQTTogTWFrZSBpdCBwb3NzaWJsZSB0byBmb3Jj ZSB1c2luZyBJTlR4IGZvciBQQ0llIFBNRQo+ID4gPiA+ID4gPiA+ID4gICAgICAgICBzaWduYWxp bmciKS4KPiA+ID4gPiA+ID4gPiAKPiA+ID4gPiA+ID4gPiBCZWNhdXNlIFRlZ3JhMTk0IGRvZXNu J3Qgc3VwcG9ydCByYWlzaW5nIFBNRSBpbnRlcnJ1cHRzIHRocm91Z2ggTVNJIGxpbmUuCj4gPiAK PiA+ID4gPiBUaGVyZSdzIHNvbWV0aGluZyB3cm9uZyBoZXJlLiAgRWl0aGVyIHRoZSBxdWVzdGlv biBvZiBob3cgUE1FIGlzCj4gPiA+ID4gc2lnbmFsZWQgaXMgZ2VuZXJpYyBhbmQgdGhlIHNwZWMg cHJvdmlkZXMgYSB3YXkgZm9yIHRoZSBPUyB0byBkaXNjb3Zlcgo+ID4gPiA+IHRoYXQgbWV0aG9k LCBvciBpdCdzIHBhcnQgb2YgdGhlIGRldmljZS1zcGVjaWZpYyBhcmNoaXRlY3R1cmUgdGhhdAo+ ID4gPiA+IGVhY2ggaG9zdCBicmlkZ2UgZHJpdmVyIGhhcyB0byBrbm93IGFib3V0IGl0cyBkZXZp Y2UuICBJZiB0aGUgZm9ybWVyLAo+ID4gPiA+IHdlIG5lZWQgdG8gbWFrZSB0aGUgUENJIGNvcmUg c21hcnQgZW5vdWdoIHRvIGZpZ3VyZSBpdCBvdXQuICBJZiB0aGUKPiA+ID4gPiBsYXR0ZXIsIHdl IG5lZWQgYSBiZXR0ZXIgaW50ZXJmYWNlIHRoYW4gdGhpcyBhZCBob2MKPiA+ID4gPiBwY2llX3Bt ZV9kaXNhYmxlX21zaSgpIHRoaW5nLiAgQnV0IGlmIGl0IGlzIHRydWx5IHRoZSBsYXR0ZXIsIHlv dXIKPiA+ID4gPiBjdXJyZW50IGNvZGUgaXMgc3VmZmljaWVudCBhbmQgd2UgY2FuIHJlZmluZSBp dCBvdmVyIHRpbWUuCj4gPiA+IAo+ID4gPiBJbiBjYXNlIG9mIFRlZ3JhMTk0LCBpdCBpcyB0aGUg bGF0dGVyIGNhc2UuCj4gPiAKPiA+IFRoaXMgaXNuJ3QgYSBUZWdyYTE5NCBxdWVzdGlvbjsgaXQn cyBhIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdGhpcwo+ID4gYmVoYXZpb3IgaXMgY292ZXJlZCBieSB0 aGUgUENJZSBzcGVjLgo+IEFGQUlVIHRoZSBzcGVjIGFuZCB3aGF0IEkgaGVhcmQgZnJvbSBOdmlk aWEgaGFyZHdhcmUgZm9sa3MgaXMgdGhhdCBzcGVjIGRvZXNuJ3QKPiBleHBsaWNpdGx5IHRhbGsg YWJvdXQgdGhpcyBhbmQgaXQgd2FzIGEgZGVzaWduIGNob2ljZSBtYWRlIGJ5IE52aWRpYSBoYXJk d2FyZQo+IGZvbGtzIHRvIHJvdXRlIHRoZXNlIGludGVycnVwdHMgdGhyb3VnaCBsZWdhY3kgbGlu ZSBpbnN0ZWFkIG9mIE1TSSBsaW5lLgo+IAo+ID4gCj4gPiA+ID4gV2hhdCBJIHN1c3BlY3Qgc2hv dWxkIGhhcHBlbiBldmVudHVhbGx5IGlzIHRoZSBEV0MgZHJpdmVyIHNob3VsZCBjYWxsCj4gPiA+ ID4gZGV2bV9wY2lfYWxsb2NfaG9zdF9icmlkZ2UoKSBkaXJlY3RseSwgYXMgYWxsIHRoZSBub24t RFdDIGRyaXZlcnMgZG8uCj4gPiA+ID4gVGhhdCB3b3VsZCByZXF1aXJlIGEgbGl0dGxlIHJlb3Jn YW5pemF0aW9uIG9mIHRoZSBEV0MgZGF0YSBzdHJ1Y3R1cmVzLAo+ID4gPiA+IGJ1dCBpdCB3b3Vs ZCBiZSBnb29kIHRvIGJlIG1vcmUgY29uc2lzdGVudC4KPiA+ID4gPiAKPiA+ID4gPiBGb3Igbm93 LCBJIHRoaW5rIHN0YXNoaW5nIHRoZSBwb2ludGVyIGluIHBjaWVfcG9ydCBvciBkd19wY2llIHdv dWxkIGJlCj4gPiA+ID4gT0suICBJJ20gbm90IDEwMCUgY2xlYXIgb24gdGhlIGRpZmZlcmVuY2Us IGJ1dCBpdCBsb29rcyBsaWtlIGVpdGhlcgo+ID4gPiA+IHNob3VsZCBiZSBjb21tb24gYWNyb3Nz IGFsbCB0aGUgRFdDIGRyaXZlcnMsIHdoaWNoIGlzIHdoYXQgd2Ugd2FudC4KPiA+ID4gCj4gPiA+ IFNpbmNlIGR3X3BjaWUgaXMgY29tbW9uIGZvciBib3RoIHJvb3QgcG9ydCBhbmQgZW5kIHBvaW50 IG1vZGUgc3RydWN0dXJlcywKPiA+ID4gSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBrZWVwIHRo ZSBwb2ludGVyIGluIHBjaWVfcG9ydCBhcyB0aGlzIHN0cnVjdHVyZQo+ID4gPiBpcyBzcGVjaWZp YyB0byByb290IHBvcnQgbW9kZSBvZiBvcGVyYXRpb24uCj4gPiA+IEknbGwgbWFrZSBhIG5vdGUg dG8gcmVvcmdhbml6ZSBjb2RlIHRvIGhhdmUgZGV2bV9wY2lfYWxsb2NfaG9zdF9icmlkZ2UoKQo+ ID4gPiB1c2VkIGluIHRoZSBiZWdpbm5pbmcgaXRzZWxmIHRvIGJlIGlubGluZSB3aXRoIG5vbi1E V0MgaW1wbGVtZW50YXRpb25zLgo+ID4gPiBCdXQsIEknbGwgdGFrZSBpdCB1cCBsYXRlciAoYWZ0 ZXIgSSdtIGRvbmUgd2l0aCB1cHN0cmVhbWluZyBjdXJyZW50IHNlcmllcykKPiA+IAo+ID4gRmFp ciBlbm91Z2guCj4gPiAKPiA+ID4gPiA+IC5yZW1vdmUoKSBpbnRlcm5hbGx5IGNhbGxzIHBtX3J1 bnRpbWVfcHV0X3N5bmMoKSBBUEkgd2hpY2ggY2FsbHMKPiA+ID4gPiA+IC5ydW50aW1lX3N1c3Bl bmQoKS4gSSBtYWRlIGEgbmV3IHBhdGNoIHRvIGFkZCBhIGhvc3RfZGVpbml0KCkgY2FsbAo+ID4g PiA+ID4gd2hpY2ggbWFrZSBhbGwgdGhlc2UgY2FsbHMuIFNpbmNlIGhvc3RfaW5pdCgpIGlzIGNh bGxlZCBmcm9tIGluc2lkZQo+ID4gPiA+ID4gLnJ1bnRpbWVfcmVzdW1lKCkgb2YgdGhpcyBkcml2 ZXIsIHRvIGJlIGluIHN5bmMsIEknbSBub3cgY2FsbGluZwo+ID4gPiA+ID4gaG9zdF9kZWluaXQo KSBmcm9tIGluc2lkZSAucnVudGltZV9zdXNwZW5kKCkgQVBJLgo+ID4gPiA+IAo+ID4gPiA+IEkg dGhpbmsgdGhpcyBpcyB3cm9uZy4gIHBjaV9zdG9wX3Jvb3RfYnVzKCkgd2lsbCBkZXRhY2ggYWxs IHRoZQo+ID4gPiA+IGRyaXZlcnMgZnJvbSBhbGwgdGhlIGRldmljZXMuICBXZSBkb24ndCB3YW50 IHRvIGRvIHRoYXQgaWYgd2UncmUKPiA+ID4gPiBtZXJlbHkgcnVudGltZSBzdXNwZW5kaW5nIHRo ZSBob3N0IGJyaWRnZSwgZG8gd2U/Cj4gPiA+IAo+ID4gPiBJbiB0aGUgY3VycmVudCBkcml2ZXIs IHRoZSBzY2VuYXJpb3MgaW4gd2hpY2ggLnJ1bnRpbWVfc3VzcGVuZCgpIGlzIGNhbGxlZAo+ID4g PiBhcmUKPiA+ID4gYSkgZHVyaW5nIC5yZW1vdmUoKSBjYWxsIGFuZAo+ID4gCj4gPiBJdCBtYWtl cyBzZW5zZSB0aGF0IHlvdSBzaG91bGQgY2FsbCBwY2lfc3RvcF9yb290X2J1cygpIGR1cmluZwo+ ID4gLnJlbW92ZSgpLCBpLmUuLCB3aGVuIHRoZSBob3N0IGNvbnRyb2xsZXIgZHJpdmVyIGlzIGJl aW5nIHJlbW92ZWQsCj4gPiBiZWNhdXNlIHRoZSBQQ0kgYnVzIHdpbGwgbm8gbG9uZ2VyIGJlIGFj Y2Vzc2libGUuICBJIHRoaW5rIHlvdSBzaG91bGQKPiA+IGNhbGwgaXQgKmRpcmVjdGx5KiBmcm9t IHRlZ3JhX3BjaWVfZHdfcmVtb3ZlKCkgYmVjYXVzZSB0aGF0IHdpbGwgbWF0Y2gKPiA+IHdoYXQg b3RoZXIgZHJpdmVycyBkby4KPiA+IAo+ID4gPiBiKSB3aGVuIHRoZXJlIGlzIG5vIGVuZHBvaW50 IGZvdW5kIGFuZCBjb250cm9sbGVyIHdvdWxkIGJlIHNodXRkb3duCj4gPiA+IEluIGJvdGggY2Fz ZXMsIGl0IGlzIHJlcXVpcmVkIHRvIHN0b3AgdGhlIHJvb3QgYnVzIGFuZCByZW1vdmUgYWxsIGRl dmljZXMsCj4gPiA+IHNvLCBpbnN0ZWFkIG9mIGhhdmluZyBzYW1lIGNhbGwgcHJlc2VudCBpbiBy ZXNwZWN0aXZlIHBhdGhzLCBJIGtlcHQgdGhlbQo+ID4gPiBpbiAucnVudGltZV9zdXNwZW5kKCkg aXRzZWxmIHRvIGF2b2lkIGNvZGUgZHVwbGljYXRpb24uCj4gPiAKPiA+IEkgZG9uJ3QgdW5kZXJz dGFuZCB0aGlzIHBhcnQuICBXZSBzaG91bGQgYmUgYWJsZSB0byBydW50aW1lIHN1c3BlbmQKPiA+ IHRoZSBob3N0IGNvbnRyb2xsZXIgd2l0aG91dCBkZXRhY2hpbmcgZHJpdmVycyBmb3IgY2hpbGQg ZGV2aWNlcy4KPiA+IAo+ID4gSWYgeW91IHNodXRkb3duIHRoZSBjb250cm9sbGVyIGNvbXBsZXRl bHkgYW5kIGRldGFjaCB0aGUgKmhvc3QKPiA+IGNvbnRyb2xsZXIgZHJpdmVyKiwgc3VyZSwgaXQg bWFrZXMgc2Vuc2UgdG8gZGV0YWNoIGRyaXZlcnMgZnJvbSBjaGlsZAo+ID4gZGV2aWNlcy4gIEJ1 dCB0aGF0IHdvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIGhvc3QgY29udHJvbGxlciAucmVtb3ZlKCkK PiA+IG1ldGhvZCwgbm90IGJ5IHRoZSBydW50aW1lIHN1c3BlbmQgbWV0aG9kLgo+IEkgdGhpbmsg aXQgaXMgdGltZSBJIGdpdmUgc29tZSBiYWNrZ3JvdW5kIGFib3V0IHdoeSBJIGNob3NlIHRvIGlt cGxlbWVudAo+IC5ydW50aW1lX3N1c3BlbmQoKSBhbmQgLnJ1bnRpbWVfcmVzdW1lKCkgQVBJcyBp biB0aGUgZmlyc3QgcGxhY2UuIFdlIHdhbnRlZCB0bwo+IHBvd2VyZG93biBQQ0llIGNvbnRyb2xs ZXIgaWYgdGhlcmUgaXMgbm8gbGluayB1cCAoaS5lLiBzbG90IGlzIG9wZW4gYW5kIG5vIGVuZHBv aW50Cj4gZGV2aWNlcyBhcmUgY29ubmVjdGVkKS4gV2Ugd2FudCB0byBhY2hpZXZlIHRoaXMgd2l0 aG91dCByZXR1cm5pbmcgYSBmYWlsdXJlIGluCj4gLnByb2JlKCkgY2FsbC4gR2l2ZW4gUENJZSBJ UCBwb3dlciBwYXJ0aXRpb25pbmcgaXMgaGFuZGxlZCBieSBnZW5lcmljIHBvd2VyIGRvbWFpbgo+ IGZyYW1ld29yaywgcG93ZXIgcGFydGl0aW9uIGdldHMgdW5wb3dlcmdhdGVkIGJlZm9yZSAucHJv YmUoKSBnZXRzIGNhbGxlZCBhbmQgZ2V0cwo+IHBvd2VyZ2F0ZWQgZWl0aGVyIHdoZW4gYSBmYWls dXJlIGlzIHJldHVybmVkIGluIC5wcm9iZSgpIG9yIHdoZW4gcG1fcnVudGltZV9wdXRfc3luYygp Cj4gaXMgY2FsbGVkLiBTbywgSSBjaG9zZSB0byBjYWxsIHBtX3J1bnRpbWVfcHV0X3N5bmMoKSBp biBuby1saW5rLXVwIHNjZW5hcmlvIGFuZCBjaG9zZQo+IHRvIGltcGxlbWVudCAucnVudGltZV9z dXNwZW5kKCkgdG8gaGFuZGxlIGFsbCB0aGUgY2xlYW51cCB3b3JrIGJlZm9yZSBQQ0llIHBhcnRp dGlvbgo+IGdldHRpbmcgcG93ZXJnYXRlZC4gSW4gZmFjdCwgdG8gbWF0Y2ggdGhpcywgSSdtIGRv aW5nIGFsbCB0aGUgUENJZSBJUCBicmluZyB1cAo+IGFjdGl2aXR5IGluIC5ydW50aW1lX3Jlc3Vt ZSgpIGltcGxlbWVudGF0aW9uIHdoaWNoIGdldHMgaW52b2tlZCBieSBwbV9ydW50aW1lX2dldF9z eW5jKCkKPiB3aGljaCBpbiB0dXJuIGlzIGNhbGxlZCBpbiAucHJvYmUoKSBwYXRoLiBJbiBmYWN0 IHRoZSB2ZXJ5IGR3X3BjaWVfaG9zdF9pbml0KCkgaXRzZWxmCj4gaXMgY2FsbGVkIGZyb20gLnJ1 bnRpbWVfcmVzdW1lKCkgaW1wbGVtZW50YXRpb24uIFNvLCBpdCBpcyBiZWNhdXNlIG9mIHRoZXNl IHJlYXNvbnMgdGhhdAo+IEkgY2FsbGVkIHBjaV9zdG9wX3Jvb3RfYnVzKCkgYW5kIHBjaV9yZW1v dmVfcm9vdF9idXMoKSBhcyBwYXJ0IG9mIC5ydW50aW1lX3N1c3BlbmQoKQo+IGltcGxlbWVudGF0 aW9uIGFzIHBtX3J1bnRpbWVfcHV0X3N5bmMoKSBpcyBjYWxsZWQgZnJvbSBib3RoIC5yZW1vdmUo KSBhbmQgYWxzbyBkdXJpbmcKPiBuby1saW5rLXVwIHNjZW5hcmlvLiBQbGVhc2UgZG8gbGV0IG1l IGtub3cgaWYgdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRvIGRvIHRoaXMuCgpJIHRoaW5rIHlvdSdy ZSBtaXNzaW5nIHRoZSBjYXNlIHdoZXJlIC5ydW50aW1lX3N1c3BlbmQoKSBpcyBjYWxsZWQgd2hl bgp0aGVyZSBhcmUgbm8gKmFjdGl2ZSogZGV2aWNlcyBvbiB0aGUgYnVzLCBpLmUuIGV2ZXJ5b25l IGlzIGRvcm1hbnQuIEl0CmRvZXNuJ3QgbWVhbiB0aGF0IHlvdSBuZWVkIHRvIHJlbW92ZSB0aGVt IGZyb20gdGhlIGJ1cyBhbmQgcmUtcHJvYmUgdGhlbQpiYWNrIG9uIC5ydW50aW1lX3Jlc3VtZSgp LiBNb3N0IG9mIHRoZSBkcml2ZXJzIGZvciBQQ0kgZGV2aWNlcyBkb24ndApleHBlY3QgdG8gYmUg cmVtb3ZlZCBkdXJpbmcgaWRsZSwgYXMgdGhleSB3aWxsIGNvbmZpZ3VyZSB0aGUgaGFyZHdhcmUg dG8KYmUgaW4gYSAicXVpY2sgd2FrZSIgc3RhdGUgKHNlZSBQQ0llIER4IHBvd2VyIHN0YXRlcyku CgpZb3Ugc2hvdWxkIHByb2JlIGFuZCBjb25maWd1cmUgdGhlIGJ1cyBkdXJpbmcgLnByb2JlKCkg YW5kIHJlbW92ZSBhbmQKZGV0YWNoIGFsbCBkcml2ZXJzIGR1cmluZyAucmVtb3ZlKCkuIEZvciAu cnVudGltZV9zdXNwZW5kKCkgYWxsIHlvdSBuZWVkCnRvIGRvIGlzIHB1dCB0aGUgaG9zdCBjb250 cm9sbGVyIGluIGxvdyBwb3dlciBtb2RlIGlmIGl0IGhhcyBvbmUsIG9yCnN0b3AgYWxsIGNsb2Nr cyB0aGF0IGFyZSBub3QgcmVxdWlyZWQgZm9yIHJlc3BvbmRpbmcgdG8gZGV2aWNlcyB3YWtpbmcK dXAgZnJvbSBQQ0llIER4IHN0YXRlLiBGb3IgLnJ1bnRpbWVfcmVzdW1lKCkgeW91IHRoZW4gcmVz dG9yZSB0aGUKY2xvY2tzLCB3aXRob3V0IHJlLXNjYW5uaW5nIHRoZSBidXMuCgpCZXN0IHJlZ2Fy ZHMsCkxpdml1CgoKPiAKPiA+IAo+ID4gQmpvcm4KPiA+IAo+IAoKLS0gCj09PT09PT09PT09PT09 PT09PT09CnwgSSB3b3VsZCBsaWtlIHRvIHwKfCBmaXggdGhlIHdvcmxkLCAgfAp8IGJ1dCB0aGV5 J3JlIG5vdCB8CnwgZ2l2aW5nIG1lIHRoZSAgIHwKIFwgc291cmNlIGNvZGUhICAvCiAgLS0tLS0t LS0tLS0tLS0tCiAgICDCr1xfKOODhClfL8KvCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpsaW51eC1hcm0ta2VybmVsIG1haWxpbmcgbGlzdApsaW51eC1h cm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcKaHR0cDovL2xpc3RzLmluZnJhZGVhZC5vcmcv bWFpbG1hbi9saXN0aW5mby9saW51eC1hcm0ta2VybmVsCg==