linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vidya Sagar <vidyas@nvidia.com>
To: Lucas Stach <dev@lynxeye.de>, <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: Fri, 1 Mar 2019 08:45:19 +0530	[thread overview]
Message-ID: <8b6f53c4-ac39-40d6-0979-86137236f890@nvidia.com> (raw)
In-Reply-To: <247102e57e067d1477f3260bdeaa3ea011d0f3ed.camel@lynxeye.de>


On 3/1/2019 12:32 AM, Lucas Stach wrote:
> 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

We are not wasting single page of memory here and if any device's DMA is 
trying to

access it, it will still go through. Its just that we are using that 
same address for MSI (note that

MSI writes don't go beyond PCIe IP as they get decoded at PCIe IP level 
itself and only an interrupt

goes to CPU) and that might be a bit confusing as same address is used 
as normal memory as well

as MSI target address. Since there can never be any issue with this, 
would you suggest to

remove the last paragraph from commit description?

>> 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	other threads:[~2019-03-01  3:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-28 15:00 [PATCH] PCI: tegra: Do not allocate MSI target memory Vidya Sagar
2019-02-28 19:02 ` Lucas Stach
2019-03-01  3:15   ` Vidya Sagar [this message]
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=8b6f53c4-ac39-40d6-0979-86137236f890@nvidia.com \
    --to=vidyas@nvidia.com \
    --cc=bhelgaas@google.com \
    --cc=dev@lynxeye.de \
    --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 \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).