Received-SPF: pass (google.com: domain of linux-kernel+bounces-174519-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <1be83f24-15bd-43a4-b310-f62c720cf064@arm.com>
Date: Thu, 9 May 2024 13:54:56 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] dma-direct: Set SG_DMA_SWIOTLB flag for dma-direct
To: Christoph Hellwig <hch@lst.de>, "T.J. Mercier" <tjmercier@google.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>, isaacmanjarres@google.com,
 Catalin Marinas <catalin.marinas@arm.com>, iommu@lists.linux.dev,
 linux-kernel@vger.kernel.org
References: <20240503183713.1557480-1-tjmercier@google.com>
 <20240506052955.GA4923@lst.de>
 <CABdmKX1XNTtoPTvfsJRobim8pHdDjPsKx=qVovVZDh5GEbKCfQ@mail.gmail.com>
 <20240506160244.GA16248@lst.de>
 <CABdmKX1n98+bw+1kewz=wdqq2Nbpaxao_Lx-Gq8oKGNUEP4ytQ@mail.gmail.com>
 <20240506161906.GA17237@lst.de>
 <CABdmKX3s_HnxciDA3XGM8Qj0kLY8OWENg+ifexrON4VYVbuLsA@mail.gmail.com>
 <20240507054314.GA31814@lst.de>
 <CABdmKX3PgcXaRUH3L7OV+POMiMd5L6pEF4fLXYPgfmQUNu_trg@mail.gmail.com>
 <20240508113353.GA31529@lst.de>
From: Robin Murphy <robin.murphy@arm.com>
Content-Language: en-GB
In-Reply-To: <20240508113353.GA31529@lst.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 08/05/2024 12:33 pm, Christoph Hellwig wrote:
> On Tue, May 07, 2024 at 01:07:25PM -0700, T.J. Mercier wrote:
>> On Mon, May 6, 2024 at 10:43???PM Christoph Hellwig <hch@lst.de> wrote:
>>>
>>> On Mon, May 06, 2024 at 09:39:53AM -0700, T.J. Mercier wrote:
>>>>> You should not check, you simply must handle it by doing the proper
>>>>> DMA API based ownership management.
>>>>
>>>> That doesn't really work for uncached buffers.
>>>
>>> What uncached buffers?
>>
>> For example these ones:
>> https://android.googlesource.com/kernel/common/+/refs/heads/android-mainline/drivers/dma-buf/heaps/system_heap.c#141
> 
> Whatever that code is doing is probably not upstream because it's too
> broken to live.

Indeed, at a glance it appears to be trying to reinvent 
dma_alloc_noncontiguous(). What's not immediately obvious is whether 
it's particular about allocations being DMA-contiguous; if not then I 
think it comes down to the same thing as vb2-dma-sg and the ideas we 
were tossing around for that[1].

Thanks,
Robin.

[1] 
https://lore.kernel.org/linux-media/20231228074645.765yytb2a7hvz7ti@chromium.org/