Halil Pasic writes:
> On Fri, 25 Mar 2022 11:27:41 +
> Robin Murphy wrote:
>
>> What muddies the waters a bit is that the opposite combination
>> sync_for_cpu(DMA_TO_DEVICE) really *should* always be a no-op, and I for
>> one have already made the case for eliding that in code elsewhere, b
Christoph Hellwig writes:
> On Thu, Mar 24, 2022 at 07:02:16PM +0100, Halil Pasic wrote:
>> > If
>> > ddbd89deb7d3 alone turns out to work OK then I'd be inclined to try a
>> > partial revert of just that one hunk.
>> >
>>
>> I'm not against being pragmatic and doing the partial revert. But as
Robin Murphy writes:
> On 2022-03-25 16:25, Toke Høiland-Jørgensen wrote:
>> Maxime Bizon writes:
>>
>>> On Thu, 2022-03-24 at 12:26 -0700, Linus Torvalds wrote:
>>>
It's actually very natural in that situation to flush the caches from
the CPU side again. And so dma_sync_single_f
Maxime Bizon writes:
> On Thu, 2022-03-24 at 12:26 -0700, Linus Torvalds wrote:
>
>>
>> It's actually very natural in that situation to flush the caches from
>> the CPU side again. And so dma_sync_single_for_device() is a fairly
>> reasonable thing to do in that situation.
>>
>
> In the non-cac
Linus Torvalds writes:
> On Thu, Mar 24, 2022 at 10:07 AM Toke Høiland-Jørgensen wrote:
>>
>> Right, but is that sync_for_device call really needed?
>
> Well, imagine that you have a non-cache-coherent DMA (not bounce
> buffers - just bad hardware)...
>
> So the driver first does that dma_sync_s
Robin Murphy writes:
> On 2022-03-24 16:31, Christoph Hellwig wrote:
>> On Thu, Mar 24, 2022 at 05:29:12PM +0100, Maxime Bizon wrote:
I'm looking into this; but in the interest of a speedy resolution of
the regression I would be in favour of merging that partial revert
and reinstat
Robin Murphy writes:
> On 2022-03-24 10:25, Oleksandr Natalenko wrote:
>> Hello.
>>
>> On čtvrtek 24. března 2022 6:57:32 CET Christoph Hellwig wrote:
>>> On Wed, Mar 23, 2022 at 08:54:08PM +, Robin Murphy wrote:
I'll admit I still never quite grasped the reason for also adding the
