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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 10 Jun 2024 at 10:20, Arnd Bergmann <arnd@xxxxxxxx> 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@xxxxxxxx> 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.

Phil




[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux