linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Christoph Hellwig <hch@lst.de>, Claire Chang <tientzu@chromium.org>
Cc: heikki.krogerus@linux.intel.com, peterz@infradead.org,
	grant.likely@arm.com, paulus@samba.org, frowand.list@gmail.com,
	mingo@kernel.org, m.szyprowski@samsung.com,
	sstabellini@kernel.org, saravanak@google.com, joro@8bytes.org,
	rafael.j.wysocki@intel.com, bgolaszewski@baylibre.com,
	xen-devel@lists.xenproject.org, treding@nvidia.com,
	devicetree@vger.kernel.org, will@kernel.org,
	konrad.wilk@oracle.com, dan.j.williams@intel.com,
	robh+dt@kernel.org, boris.ostrovsky@oracle.com,
	andriy.shevchenko@linux.intel.com, jgross@suse.com,
	drinkcat@chromium.org, gregkh@linuxfoundation.org,
	rdunlap@infradead.org, linux-kernel@vger.kernel.org,
	tfiga@chromium.org, iommu@lists.linux-foundation.org,
	xypron.glpk@gmx.de, linuxppc-dev@lists.ozlabs.org,
	bauerman@linux.ibm.com
Subject: Re: [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support.
Date: Wed, 13 Jan 2021 18:27:08 +0000	[thread overview]
Message-ID: <82bb75bc-11e6-ac94-9d24-7c896e3aae98@arm.com> (raw)
In-Reply-To: <20210113124847.GC1383@lst.de>

On 2021-01-13 12:48, Christoph Hellwig wrote:
>> +#ifdef CONFIG_SWIOTLB
>> +	if (unlikely(dev->dma_io_tlb_mem))
>> +		return swiotlb_alloc(dev, size, dma_handle, attrs);
>> +#endif
> 
> Another place where the dma_io_tlb_mem is useful to avoid the ifdef.
> 
>> -phys_addr_t swiotlb_tbl_map_single(struct device *hwdev, phys_addr_t orig_addr,
>> -		size_t mapping_size, size_t alloc_size,
>> -		enum dma_data_direction dir, unsigned long attrs)
>> +static int swiotlb_tbl_find_free_region(struct device *hwdev,
>> +					dma_addr_t tbl_dma_addr,
>> +					size_t alloc_size,
>> +					unsigned long attrs)
> 
>> +static void swiotlb_tbl_release_region(struct device *hwdev, int index,
>> +				       size_t size)
> 
> This refactoring should be another prep patch.
> 
> 
>> +void *swiotlb_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
>> +		    unsigned long attrs)
> 
> I'd rather have the names convey there are for the per-device bounce
> buffer in some form.
> 
>> +	struct io_tlb_mem *mem = dev->dma_io_tlb_mem;
> 
> While we're at it I wonder if the io_tlb is something we could change
> while we're at it.  Maybe replace io_tlb_mem with struct swiotlb
> and rename the field in struct device to dev_swiotlb?
> 
>> +	int index;
>> +	void *vaddr;
>> +	phys_addr_t tlb_addr;
>> +
>> +	size = PAGE_ALIGN(size);
>> +	index = swiotlb_tbl_find_free_region(dev, mem->start, size, attrs);
>> +	if (index < 0)
>> +		return NULL;
>> +
>> +	tlb_addr = mem->start + (index << IO_TLB_SHIFT);
>> +	*dma_handle = phys_to_dma_unencrypted(dev, tlb_addr);
>> +
>> +	if (!dev_is_dma_coherent(dev)) {
>> +		unsigned long pfn = PFN_DOWN(tlb_addr);
>> +
>> +		/* remove any dirty cache lines on the kernel alias */
>> +		arch_dma_prep_coherent(pfn_to_page(pfn), size);
> 
> Can we hook in somewhat lower level in the dma-direct code so that all
> the remapping in dma-direct can be reused instead of duplicated?  That
> also becomes important if we want to use non-remapping uncached support,
> e.g. on mips or x86, or the direct changing of the attributes that Will
> planned to look into for arm64.

Indeed, AFAICS this ought to boil down to a direct equivalent of 
__dma_direct_alloc_pages() - other than the address there should be no 
conceptual difference between pages from the restricted pool and those 
from the regular page allocator, so this probably deserves to be plumbed 
in as an alternative to that.

Robin.

  reply	other threads:[~2021-01-13 18:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  3:41 [RFC PATCH v3 0/6] Restricted DMA Claire Chang
2021-01-06  3:41 ` [RFC PATCH v3 1/6] swiotlb: Add io_tlb_mem struct Claire Chang
2021-01-13 11:50   ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 2/6] swiotlb: Add restricted DMA pool Claire Chang
2021-01-06  7:50   ` Greg KH
2021-01-13 11:51     ` Christoph Hellwig
2021-01-13 12:29       ` Greg KH
2021-01-13 12:37         ` Christoph Hellwig
2021-01-06 18:52   ` Konrad Rzeszutek Wilk
2021-01-07 17:39     ` Claire Chang
2021-01-07 17:57       ` Konrad Rzeszutek Wilk
2021-01-07 18:09         ` Florian Fainelli
2021-01-07 21:19           ` Konrad Rzeszutek Wilk
2021-01-12 23:52             ` Florian Fainelli
2021-01-25  5:26           ` Jon Masters
2021-01-13  1:53         ` Robin Murphy
2021-01-13  0:03   ` Florian Fainelli
2021-01-13 13:59     ` Nicolas Saenz Julienne
2021-01-13 15:27       ` Robin Murphy
2021-01-13 17:43         ` Florian Fainelli
2021-01-13 18:03           ` Robin Murphy
2021-01-13 12:42   ` Christoph Hellwig
2021-01-14  9:06     ` Claire Chang
2021-01-06  3:41 ` [RFC PATCH v3 3/6] swiotlb: Use restricted DMA pool if available Claire Chang
2021-01-12 23:39   ` Florian Fainelli
2021-01-13 12:44   ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 4/6] swiotlb: Add restricted DMA alloc/free support Claire Chang
2021-01-12 23:41   ` Florian Fainelli
2021-01-13 12:48   ` Christoph Hellwig
2021-01-13 18:27     ` Robin Murphy [this message]
2021-01-13 18:32       ` Christoph Hellwig
2021-01-06  3:41 ` [RFC PATCH v3 5/6] dt-bindings: of: Add restricted DMA pool Claire Chang
2021-01-06 18:57   ` Konrad Rzeszutek Wilk
2021-01-07 17:39     ` Claire Chang
2021-01-07 18:00       ` Konrad Rzeszutek Wilk
2021-01-07 18:14         ` Florian Fainelli
2021-01-12  7:47           ` Claire Chang
2021-01-20 16:53   ` Rob Herring
2021-01-20 17:30     ` Robin Murphy
2021-01-20 21:31       ` Rob Herring
2021-01-21  1:09         ` Robin Murphy
2021-01-21 15:48           ` Rob Herring
2021-01-21 17:29             ` Robin Murphy
2021-01-06  3:41 ` [RFC PATCH v3 6/6] of: Add plumbing for " Claire Chang
2021-01-12 23:48   ` Florian Fainelli
2021-01-14  9:08     ` Claire Chang
2021-01-14 18:52       ` Florian Fainelli
2021-01-15  3:46         ` Claire Chang
2021-01-06 18:48 ` [RFC PATCH v3 0/6] Restricted DMA Florian Fainelli
2021-01-07 17:38   ` Claire Chang
2021-01-07 17:42   ` Claire Chang
2021-01-07 17:59     ` Florian Fainelli
2021-01-12  7:48       ` Claire Chang
2021-01-12 18:01         ` Florian Fainelli
2021-01-13  2:29           ` Tomasz Figa
2021-01-13  3:56             ` Florian Fainelli
2021-01-13  4:25               ` Tomasz Figa
2021-01-13  4:41                 ` Florian Fainelli
2021-02-09  6:27                   ` Claire Chang

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=82bb75bc-11e6-ac94-9d24-7c896e3aae98@arm.com \
    --to=robin.murphy@arm.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bauerman@linux.ibm.com \
    --cc=bgolaszewski@baylibre.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=frowand.list@gmail.com \
    --cc=grant.likely@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=m.szyprowski@samsung.com \
    --cc=mingo@kernel.org \
    --cc=paulus@samba.org \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rdunlap@infradead.org \
    --cc=robh+dt@kernel.org \
    --cc=saravanak@google.com \
    --cc=sstabellini@kernel.org \
    --cc=tfiga@chromium.org \
    --cc=tientzu@chromium.org \
    --cc=treding@nvidia.com \
    --cc=will@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xypron.glpk@gmx.de \
    /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).