Received-SPF: pass (google.com: domain of linux-kernel+bounces-42543-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Mon, 29 Jan 2024 11:23:16 +0100
From: Pavel Machek <pavel@ucw.cz>
To: Lucas Stach <dev@lynxeye.de>,
	kernel list <linux-kernel@vger.kernel.org>
Cc: Milan Zamazal <mzamazal@redhat.com>, Christoph Hellwig <hch@lst.de>,
	iommu@lists.linux.dev, Will Deacon <will@kernel.org>,
	catalin.marinas@arm.com,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Andrey Konovalov <andrey.konovalov.ynk@gmail.com>,
	Maxime Ripard <mripard@redhat.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	kieran.bingham@ideasonboard.com,
	Hans de Goede <hdegoede@redhat.com>
Subject: Re: Uncached buffers from CMA DMA heap on some Arm devices?
Message-ID: <Zbd8lOgVqfCrGUL7@duo.ucw.cz>
References: <87bk9ahex7.fsf@redhat.com>
 <d2ff8df896d8a167e9abf447ae184ce2f5823852.camel@lynxeye.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="hnxbezOAcVndUORq"
Content-Disposition: inline
In-Reply-To: <d2ff8df896d8a167e9abf447ae184ce2f5823852.camel@lynxeye.de>


--hnxbezOAcVndUORq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

> That's right and a reality you have to deal with on those small ARM
> systems. The ARM architecture allows for systems that don't enforce
> hardware coherency across the whole SoC and many of the small/cheap SoC
> variants make use of this architectural feature.
>=20
> What this means is that the CPU caches aren't coherent when it comes to
> DMA from other masters like the video capture units. There are two ways
> to enforce DMA coherency on such systems:
> 1. map the DMA buffers uncached on the CPU
> 2. require explicit cache maintenance when touching DMA buffers with
> the CPU
>=20
> Option 1 is what you see is happening in your setup, as it is simple,
> straight-forward and doesn't require any synchronization points.

Yeah, and it also does not work :-).

Userspace gets the buffers, and it is not really equipped to work with
them. For example, on pinephone, memcpy() crashes on uncached
memory. I'm pretty sure user could have some kind of kernel-crashing
fun if he passed the uncached memory to futex or something similar.

> Option 2 could be implemented by allocating cached DMA buffers in the
> V4L2 device and then executing the necessary cache synchronization in
> qbuf/dqbuf when ownership of the DMA buffer changes between CPU and DMA
> master. However this isn't guaranteed to be any faster, as the cache
> synchronization itself is a pretty heavy-weight operation when you are
> dealing with buffer that are potentially multi-megabytes in size.

Yes, cache synchronization can be slow, but IIRC it was on order of
milisecond in the worst case.. and copying megayte images is still
slower than that.

Note that it is faster to do read/write syscalls then deal with
uncached memory. And userspace can't simply flush the caches and remap
memory as cached.

v4l2 moved away from read/write "because it is slow" and switched to
interface that is even slower than that. And libcamera exposes
uncached memory to the user :-(.

Best regards,
								Pavel
--=20
People of Russia, stop Putin before his war on Ukraine escalates.

--hnxbezOAcVndUORq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCZbd8lAAKCRAw5/Bqldv6
8iYKAJ0cTLemxbgoFmela6/AGCR4/hC6PgCglJC5fmhFvpx6Hd9/0aGqZxh0V/I=
=AF/b
-----END PGP SIGNATURE-----

--hnxbezOAcVndUORq--