All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Tesarik <petrtesarik@huaweicloud.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Robin Murphy <robin.murphy@arm.com>, Borislav Petkov <bp@suse.de>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Damien Le Moal <damien.lemoal@opensource.wdc.com>,
	Kim Phillips <kim.phillips@amd.com>,
	"Steven Rostedt (Google)" <rostedt@goodmis.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:DMA MAPPING HELPERS" <iommu@lists.linux.dev>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	petr@tesarici.cz
Subject: Re: [RFC v1 1/4] dma-mapping: introduce the DMA_ATTR_MAY_SLEEP attribute
Date: Tue, 28 Mar 2023 09:21:10 +0200	[thread overview]
Message-ID: <f42723f3-6dda-037d-3dd2-dc60ac0dcc3d@huaweicloud.com> (raw)
In-Reply-To: <20230328035725.GA25506@lst.de>

On 3/28/2023 5:57 AM, Christoph Hellwig wrote:
> On Mon, Mar 20, 2023 at 01:28:13PM +0100, Petr Tesarik wrote:
>> From: Petr Tesarik <petr.tesarik.ext@huawei.com>
>>
>> Introduce a DMA attribute to tell the DMA-mapping subsystem that
>> the operation is allowed to sleep.
>>
>> This patch merely adds the flag, which is not used for anything at
>> the moment. It should be used by users who can sleep (e.g. dma-buf
>> ioctls) to allow page reclaim and/or allocations from CMA.
> 
> So what drivers would call this?  As-is it doesn't have any users in
> the series.

Yes, I removed one patch from the RFC series to reduce the Cc list while
I wasn't sure if the proposal would be considered at all.

The full series in my local tree added it to the implementation of
DRM_IOCTL_PRIME_FD_TO_HANDLE:

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index f924b8b4ab6b..f32e12445570 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -635,7 +635,7 @@ struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
 		return sgt;

 	ret = dma_map_sgtable(attach->dev, sgt, dir,
-			      DMA_ATTR_SKIP_CPU_SYNC);
+			      DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_MAY_SLEEP);
 	if (ret) {
 		sg_free_table(sgt);
 		kfree(sgt);

I also noticed a similar place in udmabuf, but since I don't have a use
case ATM, I haven't added the flag there (yet).

Petr T


  reply	other threads:[~2023-03-28  7:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-20 12:28 [RFC v1 0/4] Allow dynamic allocation of software IO TLB bounce buffers Petr Tesarik
2023-03-20 12:28 ` [RFC v1 1/4] dma-mapping: introduce the DMA_ATTR_MAY_SLEEP attribute Petr Tesarik
2023-03-28  3:57   ` Christoph Hellwig
2023-03-28  7:21     ` Petr Tesarik [this message]
2023-04-07  5:52       ` Christoph Hellwig
2023-03-31 13:06   ` Bagas Sanjaya
2023-03-20 12:28 ` [RFC v1 2/4] swiotlb: Move code around in preparation for dynamic bounce buffers Petr Tesarik
2023-03-20 12:28 ` [RFC v1 3/4] swiotlb: Allow dynamic allocation of " Petr Tesarik
2023-03-28  4:07   ` Christoph Hellwig
2023-03-28  7:54     ` Petr Tesarik
2023-03-28 12:43       ` Petr Tesarik
2023-04-07  5:57         ` Christoph Hellwig
2023-04-07 10:15           ` Petr Tesařík
2023-04-13 11:09             ` Petr Tesarik
2023-04-21 13:03             ` Petr Tesařík
2023-04-21 14:58               ` Robin Murphy
2023-04-21 15:09                 ` Petr Tesařík
2023-04-24  6:03                   ` Christoph Hellwig
2023-03-31  7:26       ` Juerg Haefliger
2023-03-31  9:00         ` Petr Tesařík
2023-04-06 11:44           ` Juerg Haefliger
2023-05-11 10:36             ` Petr Tesařík
2023-04-07  5:55       ` Christoph Hellwig
2023-04-07 10:46         ` Petr Tesařík
2023-04-11  3:51           ` Christoph Hellwig
2023-03-20 12:28 ` [RFC v1 4/4] swiotlb: Add an option to allow dynamic " Petr Tesarik
2023-03-27 11:06 ` [RFC v1 0/4] Allow dynamic allocation of software IO TLB " Petr Tesarik
2023-04-07  6:00   ` Christoph Hellwig

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=f42723f3-6dda-037d-3dd2-dc60ac0dcc3d@huaweicloud.com \
    --to=petrtesarik@huaweicloud.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=corbet@lwn.net \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hch@lst.de \
    --cc=iommu@lists.linux.dev \
    --cc=kim.phillips@amd.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=paulmck@kernel.org \
    --cc=petr@tesarici.cz \
    --cc=rdunlap@infradead.org \
    --cc=roberto.sassu@huawei.com \
    --cc=robin.murphy@arm.com \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.