[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cfba57a6-01c1-4f47-80e2-9db4d5013986@web.de>
Date: Wed, 14 Jan 2026 16:56:19 +0100
From: Markus Elfring <Markus.Elfring@....de>
To: Tomeu Vizoso <tomeu@...euvizoso.net>, dri-devel@...ts.freedesktop.org,
linux-media@...r.kernel.org, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linaro-mm-sig@...ts.linaro.org
Cc: LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
Andrei Aldea <a-aldea@...com>, "Andrew F. Davis" <afd@...com>,
Chirag Shilwant <c-shilwant@...com>,
Christian König <christian.koenig@....com>,
Conor Dooley <conor+dt@...nel.org>, David Airlie <airlied@...il.com>,
Jonathan Corbet <corbet@....net>, Jonathan Humphreys <j-humphreys@...com>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Nishanth Menon <nm@...com>,
Oded Gabbay <ogabbay@...nel.org>, Randolph Sapp <rs@...com>,
Rob Herring <robh@...nel.org>, Robert Nelson <robertcnelson@...il.com>,
Simona Vetter <simona@...ll.ch>, Sumit Semwal <sumit.semwal@...aro.org>,
Tero Kristo <kristo@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
Vignesh Raghavendra <vigneshr@...com>
Subject: Re: [PATCH v2 3/5] accel/thames: Add IOCTLs for BO creation and
mapping
…
> Buffers belong to a context, which is used by the DSP to switch to the
> page table that mapped the buffers for the user of the job to execute.
>
> v2:
> - Add thames_accel.h UAPI header (Robert Nelson).
* Please move patch version descriptions behind the marker line.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc5#n785
* See also once more:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.19-rc5#n94
…
> +++ b/drivers/accel/thames/thames_gem.c
> @@ -0,0 +1,353 @@
…
> +static void thames_free_vaddr(struct thames_device *tdev, struct thames_gem_object *bo)
> +{
…
> + mutex_lock(&tdev->mm_lock);
> + drm_mm_remove_node(&bo->mm);
> + mutex_unlock(&tdev->mm_lock);
> +}
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&tdev->mm_lock);”?
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/mutex.h#L253
Regards,
Markus
Powered by blists - more mailing lists