Linux-PCI Archive on lore.kernel.org
 help / color / Atom feed
From: Lucas Stach <dev@lynxeye.de>
To: Vidya Sagar <vidyas@nvidia.com>,
	bhelgaas@google.com, lorenzo.pieralisi@arm.com,
	treding@nvidia.com, swarren@nvidia.com, mperttunen@nvidia.com,
	jonathanh@nvidia.com
Cc: linux-tegra@vger.kernel.org, linux-pci@vger.kernel.org,
	kthota@nvidia.com, mmaddireddy@nvidia.com
Subject: Re: [PATCH] PCI: tegra: Do not allocate MSI target memory
Date: Thu, 28 Feb 2019 20:02:09 +0100
Message-ID: <247102e57e067d1477f3260bdeaa3ea011d0f3ed.camel@lynxeye.de> (raw)
In-Reply-To: <1551366004-32547-1-git-send-email-vidyas@nvidia.com>

Am Donnerstag, den 28.02.2019, 20:30 +0530 schrieb Vidya Sagar:
> The PCI host bridge found on Tegra SoCs doesn't require the MSI target
> address to be backed by physical system memory. Writes are intercepted
> within the controller and never make it to the memory pointed to.
> 
> Since no actual system memory is required, remove the allocation of a
> single page and hardcode the MSI target address with a special address
> on a per-SoC basis. Ideally this would be an address to an MMIO memory
> region (such as where the controller's register are located). However,
> those addresses don't work reliably across all Tegra generations. The
> only set of addresses that work consistently are those that point to
> external memory.
> 
> This is not ideal, since those addresses could technically be used for
> DMA and hence be confusing. However, the first page of external memory
> is unlikely to be used and special enough to avoid confusion.

So you are trading a slight memory waste of a single page against a
sporadic (and probably hard to debug) DMA failure if any device happens
to initiate DMA to the first page of physical memory? That does not
sound like a good deal...

Also why would the first page of external memory be unlikely to be
used?

Regards,
Lucas

> Original base patch was posted by Thierry Reding <treding@nvidia.com>
> ( http://patchwork.ozlabs.org/patch/848569/ )
> Current patch removes hardcoding of external RAM starting address instead
> gets it using memblock_start_of_DRAM() API
> 
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
>  drivers/pci/controller/pci-tegra.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pci/controller/pci-tegra.c b/drivers/pci/controller/pci-tegra.c
> index f4f53d092e00..b33de7c78425 100644
> --- a/drivers/pci/controller/pci-tegra.c
> +++ b/drivers/pci/controller/pci-tegra.c
> @@ -23,6 +23,7 @@
>  #include <linux/irqdomain.h>
>  #include <linux/kernel.h>
>  #include <linux/init.h>
> +#include <linux/memblock.h>
>  #include <linux/module.h>
>  #include <linux/msi.h>
>  #include <linux/of_address.h>
> @@ -231,9 +232,8 @@ struct tegra_msi {
>  	struct msi_controller chip;
>  	DECLARE_BITMAP(used, INT_PCI_MSI_NR);
>  	struct irq_domain *domain;
> -	unsigned long pages;
>  	struct mutex lock;
> -	u64 phys;
> +	phys_addr_t phys;
>  	int irq;
>  };
>  
> @@ -1548,9 +1548,7 @@ static int tegra_pcie_msi_setup(struct tegra_pcie *pcie)
>  		goto err;
>  	}
>  
> -	/* setup AFI/FPCI range */
> -	msi->pages = __get_free_pages(GFP_KERNEL, 0);
> -	msi->phys = virt_to_phys((void *)msi->pages);
> +	msi->phys = memblock_start_of_DRAM();
>  	host->msi = &msi->chip;
>  
>  	return 0;
> @@ -1592,8 +1590,6 @@ static void tegra_pcie_msi_teardown(struct tegra_pcie *pcie)
>  	struct tegra_msi *msi = &pcie->msi;
>  	unsigned int i, irq;
>  
> -	free_pages(msi->pages, 0);
> -
>  	if (msi->irq > 0)
>  		free_irq(msi->irq, pcie);
>  


  reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28 15:00 Vidya Sagar
2019-02-28 19:02 ` Lucas Stach [this message]
2019-03-01  3:15   ` Vidya Sagar
2019-03-01 14:56     ` Lucas Stach
2019-03-02  2:50       ` Vidya Sagar
2019-03-02 14:22         ` Lucas Stach
2019-03-04  5:38           ` Vidya Sagar
2019-03-04  8:37             ` Thierry Reding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=247102e57e067d1477f3260bdeaa3ea011d0f3ed.camel@lynxeye.de \
    --to=dev@lynxeye.de \
    --cc=bhelgaas@google.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=mperttunen@nvidia.com \
    --cc=swarren@nvidia.com \
    --cc=treding@nvidia.com \
    --cc=vidyas@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-PCI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-pci/0 linux-pci/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-pci linux-pci/ https://lore.kernel.org/linux-pci \
		linux-pci@vger.kernel.org
	public-inbox-index linux-pci

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-pci


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git