WARNING: drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:364 vchiq_prepare_bulk_data

[Robin Murphy]

On 2024-06-10 10:24 am, Phil Elwell wrote:
> On Mon, 10 Jun 2024 at 10:20, Arnd Bergmann <arnd at arndb.de> wrote:
>>
>> On Mon, Jun 10, 2024, at 11:15, Laurent Pinchart wrote:
>>> On Mon, Jun 10, 2024 at 11:00:12AM +0200, Arnd Bergmann wrote:
>>>> On Mon, Jun 10, 2024, at 10:26, Phil Elwell wrote:
>>>>> On Mon, 10 Jun 2024 at 07:00, Arnd Bergmann <arnd at arndb.de> wrote:
>>>>>
>>>>> Why is swiotlb involved at all? The DMA controller on BCM2837 can
>>>>> access all RAM that is visible to the ARM cores.
>>>>
>>>> When a device is not cache-coherent and the buffer is not
>>>> cache aligned, we now use swiotlb to avoid clobbering data
>>>> in the same cache line during DMA synchronization.
>>>>
>>>> We used to rely on kmalloc() returning buffers that are
>>>> cacheline aligned, but that was very expensive.
>>>
>>> Could we reject buffers provided by userspace that are not
>>> cache-aligned ?
>>
>> My guess is that this will likely break existing applications,
>> in which case we cannot.
>>
>> It's probably a good idea to take a look at what buffers
>> are actually passed by userspace today. That would also
>> help decide how we allocate bounce buffers if we have to.
>> E.g. it's a big difference if the buffers are always
>> within a few bytes, kilobytes or megabytes.
>>
>>       Arnd
> 
> vchiq sends partial cache lines at the start and of reads (as seen
> from the ARM host) out of band, so the only misaligned DMA transfers
> should be from ARM to VPU. This should not require a bounce buffer.

Hmm, indeed the dma_kmalloc_safe() takes into account that unaligned 
DMA_TO_DEVICE does not need bouncing, so it would suggest that 
something's off in what vchiq is asking for.

Thanks,
Robin.