From: Mikko Perttunen <cyndis@kapsi.fi> To: Thierry Reding <thierry.reding@gmail.com>, Mikko Perttunen <mperttunen@nvidia.com> Cc: jonathanh@nvidia.com, digetx@gmail.com, airlied@linux.ie, daniel@ffwll.ch, linux-tegra@vger.kernel.org, dri-devel@lists.freedesktop.org, talho@nvidia.com, bhuntsman@nvidia.com Subject: Re: [PATCH v5 07/21] gpu: host1x: Introduce UAPI header Date: Tue, 23 Mar 2021 13:12:36 +0200 [thread overview] Message-ID: <47840607-8e7c-cc02-bf9b-e001c91f7354@kapsi.fi> (raw) In-Reply-To: <YFnIef+dDuqLv5Ek@orome.fritz.box> On 3/23/21 12:52 PM, Thierry Reding wrote: > On Mon, Jan 11, 2021 at 03:00:05PM +0200, Mikko Perttunen wrote: >> Add the userspace interface header, specifying interfaces >> for allocating and accessing syncpoints from userspace, >> and for creating sync_file based fences based on syncpoint >> thresholds. >> >> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> >> --- >> include/uapi/linux/host1x.h | 134 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 134 insertions(+) >> create mode 100644 include/uapi/linux/host1x.h > > What's the number of these syncpoints that we expect userspace to > create? There's a limited amount of open file descriptors available by > default, so this needs to be kept reasonably low. > >> diff --git a/include/uapi/linux/host1x.h b/include/uapi/linux/host1x.h >> new file mode 100644 >> index 000000000000..9c8fb9425cb2 >> --- /dev/null >> +++ b/include/uapi/linux/host1x.h >> @@ -0,0 +1,134 @@ >> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ >> +/* Copyright (c) 2020 NVIDIA Corporation */ >> + >> +#ifndef _UAPI__LINUX_HOST1X_H >> +#define _UAPI__LINUX_HOST1X_H >> + >> +#include <linux/ioctl.h> >> +#include <linux/types.h> >> + >> +#if defined(__cplusplus) >> +extern "C" { >> +#endif >> + >> +struct host1x_allocate_syncpoint { >> + /** >> + * @fd: [out] >> + * >> + * New file descriptor representing the allocated syncpoint. >> + */ >> + __s32 fd; >> + >> + __u32 reserved[3]; >> +}; >> + >> +struct host1x_syncpoint_info { >> + /** >> + * @id: [out] >> + * >> + * System-global ID of the syncpoint. >> + */ >> + __u32 id; >> + >> + __u32 reserved[3]; >> +}; > > Given that this has only out parameters, I expect this will be called on > the FD returned by HOST1X_IOCTL_ALLOCATE_SYNCPOINT? It might be worth > pointing that out explicitly in a comment. > Correct. >> + >> +struct host1x_syncpoint_increment { >> + /** >> + * @count: [in] >> + * >> + * Number of times to increment the syncpoint. The syncpoint can >> + * be observed at in-between values, but each increment is atomic. >> + */ >> + __u32 count; >> +}; > > This seems like it would have to be called on the FD as well... Yep. > >> + >> +struct host1x_read_syncpoint { >> + /** >> + * @id: [in] >> + * >> + * ID of the syncpoint to read. >> + */ >> + __u32 id; >> + >> + /** >> + * @value: [out] >> + * >> + * Current value of the syncpoint. >> + */ >> + __u32 value; >> +}; > > ... but then, all of a sudden you seem to switch things around and allow > reading the value of an arbitrary syncpoint specified by ID. > > Now, I suspect that's because reading the syncpoint is harmless and does > not allow abuse, whereas incrementing could be abused if allowed on an > arbitrary syncpoint ID. But I think it's worth spelling all that out in > some documentation to make this clear from a security point of view and > from a usability point of view for people trying to figure out how to > use these interfaces. Yeah. The model is that reading any syncpoint is OK but writing is not. I think these things were mentioned in the original proposal text but I did not carry them over to the comments. Will fix (however see below) > >> + >> +struct host1x_create_fence { >> + /** >> + * @id: [in] >> + * >> + * ID of the syncpoint to create a fence for. >> + */ >> + __u32 id; >> + >> + /** >> + * @threshold: [in] >> + * >> + * When the syncpoint reaches this value, the fence will be signaled. >> + * The syncpoint is considered to have reached the threshold when the >> + * following condition is true: >> + * >> + * ((value - threshold) & 0x80000000U) == 0U >> + * >> + */ >> + __u32 threshold; >> + >> + /** >> + * @fence_fd: [out] >> + * >> + * New sync_file file descriptor containing the created fence. >> + */ >> + __s32 fence_fd; >> + >> + __u32 reserved[1]; >> +}; > > Again this takes an arbitrary syncpoint ID as input, so I expect that > the corresponding IOCTL will have to be called on the host1x device > node? Again, I think it would be good to either point that out for each > structure or IOCTL, or alternatively maybe reorder these such that this > becomes clearer. > >> + >> +struct host1x_fence_extract_fence { >> + __u32 id; >> + __u32 threshold; >> +}; >> + >> +struct host1x_fence_extract { >> + /** >> + * @fence_fd: [in] >> + * >> + * sync_file file descriptor >> + */ >> + __s32 fence_fd; >> + >> + /** >> + * @num_fences: [in,out] >> + * >> + * In: size of the `fences_ptr` array counted in elements. >> + * Out: required size of the `fences_ptr` array counted in elements. >> + */ >> + __u32 num_fences; >> + >> + /** >> + * @fences_ptr: [in] >> + * >> + * Pointer to array of `struct host1x_fence_extract_fence`. >> + */ >> + __u64 fences_ptr; >> + >> + __u32 reserved[2]; >> +}; > > For the others it's pretty clear to me what the purpose is, but I'm at a > complete loss with this one. What's the use-case for this? This is needed to process incoming prefences for userspace-programmed engines -- mainly, the GPU with usermode submit enabled. To align with other upstream code, I've been thinking of removing this whole UAPI; moving the syncpoint allocation part to the DRM UAPI, and dropping the sync_file stuff altogether (if we have support for job submission outputting syncobjs, those could still be converted into sync_files). This doesn't support usecases like GPU usermode submit, so for downstream we'll have to add it back in, though. Would like to hear your opinion on it as well. Mikko > > In general I think it'd make sense to add a bit more documentation about > how all these IOCTLs are meant to be used to give people a better > understanding of why these are needed. > > Thierry > >> + >> +#define HOST1X_IOCTL_ALLOCATE_SYNCPOINT _IOWR('X', 0x00, struct host1x_allocate_syncpoint) >> +#define HOST1X_IOCTL_READ_SYNCPOINT _IOR ('X', 0x01, struct host1x_read_syncpoint) >> +#define HOST1X_IOCTL_CREATE_FENCE _IOWR('X', 0x02, struct host1x_create_fence) >> +#define HOST1X_IOCTL_SYNCPOINT_INFO _IOWR('X', 0x03, struct host1x_syncpoint_info) >> +#define HOST1X_IOCTL_SYNCPOINT_INCREMENT _IOWR('X', 0x04, struct host1x_syncpoint_increment) >> +#define HOST1X_IOCTL_FENCE_EXTRACT _IOWR('X', 0x05, struct host1x_fence_extract) >> + >> +#if defined(__cplusplus) >> +} >> +#endif >> + >> +#endif >> -- >> 2.30.0 >>
WARNING: multiple messages have this Message-ID (diff)
From: Mikko Perttunen <cyndis@kapsi.fi> To: Thierry Reding <thierry.reding@gmail.com>, Mikko Perttunen <mperttunen@nvidia.com> Cc: airlied@linux.ie, dri-devel@lists.freedesktop.org, jonathanh@nvidia.com, talho@nvidia.com, bhuntsman@nvidia.com, linux-tegra@vger.kernel.org, digetx@gmail.com Subject: Re: [PATCH v5 07/21] gpu: host1x: Introduce UAPI header Date: Tue, 23 Mar 2021 13:12:36 +0200 [thread overview] Message-ID: <47840607-8e7c-cc02-bf9b-e001c91f7354@kapsi.fi> (raw) In-Reply-To: <YFnIef+dDuqLv5Ek@orome.fritz.box> On 3/23/21 12:52 PM, Thierry Reding wrote: > On Mon, Jan 11, 2021 at 03:00:05PM +0200, Mikko Perttunen wrote: >> Add the userspace interface header, specifying interfaces >> for allocating and accessing syncpoints from userspace, >> and for creating sync_file based fences based on syncpoint >> thresholds. >> >> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> >> --- >> include/uapi/linux/host1x.h | 134 ++++++++++++++++++++++++++++++++++++ >> 1 file changed, 134 insertions(+) >> create mode 100644 include/uapi/linux/host1x.h > > What's the number of these syncpoints that we expect userspace to > create? There's a limited amount of open file descriptors available by > default, so this needs to be kept reasonably low. > >> diff --git a/include/uapi/linux/host1x.h b/include/uapi/linux/host1x.h >> new file mode 100644 >> index 000000000000..9c8fb9425cb2 >> --- /dev/null >> +++ b/include/uapi/linux/host1x.h >> @@ -0,0 +1,134 @@ >> +/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */ >> +/* Copyright (c) 2020 NVIDIA Corporation */ >> + >> +#ifndef _UAPI__LINUX_HOST1X_H >> +#define _UAPI__LINUX_HOST1X_H >> + >> +#include <linux/ioctl.h> >> +#include <linux/types.h> >> + >> +#if defined(__cplusplus) >> +extern "C" { >> +#endif >> + >> +struct host1x_allocate_syncpoint { >> + /** >> + * @fd: [out] >> + * >> + * New file descriptor representing the allocated syncpoint. >> + */ >> + __s32 fd; >> + >> + __u32 reserved[3]; >> +}; >> + >> +struct host1x_syncpoint_info { >> + /** >> + * @id: [out] >> + * >> + * System-global ID of the syncpoint. >> + */ >> + __u32 id; >> + >> + __u32 reserved[3]; >> +}; > > Given that this has only out parameters, I expect this will be called on > the FD returned by HOST1X_IOCTL_ALLOCATE_SYNCPOINT? It might be worth > pointing that out explicitly in a comment. > Correct. >> + >> +struct host1x_syncpoint_increment { >> + /** >> + * @count: [in] >> + * >> + * Number of times to increment the syncpoint. The syncpoint can >> + * be observed at in-between values, but each increment is atomic. >> + */ >> + __u32 count; >> +}; > > This seems like it would have to be called on the FD as well... Yep. > >> + >> +struct host1x_read_syncpoint { >> + /** >> + * @id: [in] >> + * >> + * ID of the syncpoint to read. >> + */ >> + __u32 id; >> + >> + /** >> + * @value: [out] >> + * >> + * Current value of the syncpoint. >> + */ >> + __u32 value; >> +}; > > ... but then, all of a sudden you seem to switch things around and allow > reading the value of an arbitrary syncpoint specified by ID. > > Now, I suspect that's because reading the syncpoint is harmless and does > not allow abuse, whereas incrementing could be abused if allowed on an > arbitrary syncpoint ID. But I think it's worth spelling all that out in > some documentation to make this clear from a security point of view and > from a usability point of view for people trying to figure out how to > use these interfaces. Yeah. The model is that reading any syncpoint is OK but writing is not. I think these things were mentioned in the original proposal text but I did not carry them over to the comments. Will fix (however see below) > >> + >> +struct host1x_create_fence { >> + /** >> + * @id: [in] >> + * >> + * ID of the syncpoint to create a fence for. >> + */ >> + __u32 id; >> + >> + /** >> + * @threshold: [in] >> + * >> + * When the syncpoint reaches this value, the fence will be signaled. >> + * The syncpoint is considered to have reached the threshold when the >> + * following condition is true: >> + * >> + * ((value - threshold) & 0x80000000U) == 0U >> + * >> + */ >> + __u32 threshold; >> + >> + /** >> + * @fence_fd: [out] >> + * >> + * New sync_file file descriptor containing the created fence. >> + */ >> + __s32 fence_fd; >> + >> + __u32 reserved[1]; >> +}; > > Again this takes an arbitrary syncpoint ID as input, so I expect that > the corresponding IOCTL will have to be called on the host1x device > node? Again, I think it would be good to either point that out for each > structure or IOCTL, or alternatively maybe reorder these such that this > becomes clearer. > >> + >> +struct host1x_fence_extract_fence { >> + __u32 id; >> + __u32 threshold; >> +}; >> + >> +struct host1x_fence_extract { >> + /** >> + * @fence_fd: [in] >> + * >> + * sync_file file descriptor >> + */ >> + __s32 fence_fd; >> + >> + /** >> + * @num_fences: [in,out] >> + * >> + * In: size of the `fences_ptr` array counted in elements. >> + * Out: required size of the `fences_ptr` array counted in elements. >> + */ >> + __u32 num_fences; >> + >> + /** >> + * @fences_ptr: [in] >> + * >> + * Pointer to array of `struct host1x_fence_extract_fence`. >> + */ >> + __u64 fences_ptr; >> + >> + __u32 reserved[2]; >> +}; > > For the others it's pretty clear to me what the purpose is, but I'm at a > complete loss with this one. What's the use-case for this? This is needed to process incoming prefences for userspace-programmed engines -- mainly, the GPU with usermode submit enabled. To align with other upstream code, I've been thinking of removing this whole UAPI; moving the syncpoint allocation part to the DRM UAPI, and dropping the sync_file stuff altogether (if we have support for job submission outputting syncobjs, those could still be converted into sync_files). This doesn't support usecases like GPU usermode submit, so for downstream we'll have to add it back in, though. Would like to hear your opinion on it as well. Mikko > > In general I think it'd make sense to add a bit more documentation about > how all these IOCTLs are meant to be used to give people a better > understanding of why these are needed. > > Thierry > >> + >> +#define HOST1X_IOCTL_ALLOCATE_SYNCPOINT _IOWR('X', 0x00, struct host1x_allocate_syncpoint) >> +#define HOST1X_IOCTL_READ_SYNCPOINT _IOR ('X', 0x01, struct host1x_read_syncpoint) >> +#define HOST1X_IOCTL_CREATE_FENCE _IOWR('X', 0x02, struct host1x_create_fence) >> +#define HOST1X_IOCTL_SYNCPOINT_INFO _IOWR('X', 0x03, struct host1x_syncpoint_info) >> +#define HOST1X_IOCTL_SYNCPOINT_INCREMENT _IOWR('X', 0x04, struct host1x_syncpoint_increment) >> +#define HOST1X_IOCTL_FENCE_EXTRACT _IOWR('X', 0x05, struct host1x_fence_extract) >> + >> +#if defined(__cplusplus) >> +} >> +#endif >> + >> +#endif >> -- >> 2.30.0 >> _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2021-03-23 11:13 UTC|newest] Thread overview: 195+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-11 12:59 [PATCH v5 00/21] Host1x/TegraDRM UAPI Mikko Perttunen 2021-01-11 12:59 ` Mikko Perttunen 2021-01-11 12:59 ` [PATCH v5 01/21] gpu: host1x: Use different lock classes for each client Mikko Perttunen 2021-01-11 12:59 ` Mikko Perttunen 2021-03-22 14:46 ` Thierry Reding 2021-03-22 14:46 ` Thierry Reding 2021-03-22 14:48 ` Dmitry Osipenko 2021-03-22 14:48 ` Dmitry Osipenko 2021-03-22 15:19 ` Mikko Perttunen 2021-03-22 15:19 ` Mikko Perttunen 2021-03-22 16:01 ` Dmitry Osipenko 2021-03-22 16:01 ` Dmitry Osipenko 2021-03-23 10:20 ` Thierry Reding 2021-03-23 10:20 ` Thierry Reding 2021-03-23 13:25 ` Dmitry Osipenko 2021-03-23 13:25 ` Dmitry Osipenko 2021-03-26 14:54 ` Mikko Perttunen 2021-03-26 14:54 ` Mikko Perttunen 2021-03-26 18:31 ` Dmitry Osipenko 2021-03-26 18:31 ` Dmitry Osipenko 2021-03-26 19:10 ` Mikko Perttunen 2021-03-26 19:10 ` Mikko Perttunen 2021-03-26 22:47 ` Dmitry Osipenko 2021-03-26 22:47 ` Dmitry Osipenko 2021-01-11 13:00 ` [PATCH v5 02/21] gpu: host1x: Allow syncpoints without associated client Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:10 ` Thierry Reding 2021-03-23 10:10 ` Thierry Reding 2021-03-23 10:32 ` Mikko Perttunen 2021-03-23 10:32 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 03/21] gpu: host1x: Show number of pending waiters in debugfs Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:16 ` Thierry Reding 2021-03-23 10:16 ` Thierry Reding 2021-03-26 14:34 ` Mikko Perttunen 2021-03-26 14:34 ` Mikko Perttunen 2021-04-01 21:19 ` Michał Mirosław 2021-04-01 21:19 ` Michał Mirosław 2021-04-02 16:02 ` Dmitry Osipenko 2021-04-02 16:02 ` Dmitry Osipenko 2021-04-08 4:13 ` Michał Mirosław 2021-04-08 4:13 ` Michał Mirosław 2021-04-08 4:25 ` Michał Mirosław 2021-04-08 4:25 ` Michał Mirosław 2021-04-08 11:58 ` Mikko Perttunen 2021-04-08 11:58 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 04/21] gpu: host1x: Remove cancelled waiters immediately Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-12 22:07 ` Dmitry Osipenko 2021-01-12 22:07 ` Dmitry Osipenko 2021-01-12 22:20 ` Mikko Perttunen 2021-01-12 22:20 ` Mikko Perttunen 2021-01-13 16:29 ` Dmitry Osipenko 2021-01-13 16:29 ` Dmitry Osipenko 2021-01-13 18:16 ` Mikko Perttunen 2021-01-13 18:16 ` Mikko Perttunen 2021-03-23 10:23 ` Thierry Reding 2021-03-23 10:23 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 05/21] gpu: host1x: Use HW-equivalent syncpoint expiration check Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:26 ` Thierry Reding 2021-03-23 10:26 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 06/21] gpu: host1x: Cleanup and refcounting for syncpoints Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:36 ` Thierry Reding 2021-03-23 10:36 ` Thierry Reding 2021-03-23 10:44 ` Mikko Perttunen 2021-03-23 10:44 ` Mikko Perttunen 2021-03-23 11:21 ` Thierry Reding 2021-03-23 11:21 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 07/21] gpu: host1x: Introduce UAPI header Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 10:52 ` Thierry Reding 2021-03-23 10:52 ` Thierry Reding 2021-03-23 11:12 ` Mikko Perttunen [this message] 2021-03-23 11:12 ` Mikko Perttunen 2021-03-23 11:43 ` Thierry Reding 2021-03-23 11:43 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 08/21] gpu: host1x: Implement /dev/host1x device node Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:02 ` Thierry Reding 2021-03-23 11:02 ` Thierry Reding 2021-03-23 11:15 ` Mikko Perttunen 2021-03-23 11:15 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 09/21] gpu: host1x: DMA fences and userspace fence creation Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:15 ` Thierry Reding 2021-03-23 11:15 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 10/21] gpu: host1x: Add no-recovery mode Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 11/21] gpu: host1x: Add job release callback Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 11:55 ` Thierry Reding 2021-03-23 11:55 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 12/21] gpu: host1x: Add support for syncpoint waits in CDMA pushbuffer Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 13/21] gpu: host1x: Reset max value when freeing a syncpoint Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 14/21] gpu: host1x: Reserve VBLANK syncpoints at initialization Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 15/21] drm/tegra: Add new UAPI to header Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-13 18:14 ` Dmitry Osipenko 2021-01-13 18:14 ` Dmitry Osipenko 2021-01-13 18:56 ` Mikko Perttunen 2021-01-13 18:56 ` Mikko Perttunen 2021-01-14 8:36 ` Dmitry Osipenko 2021-01-14 8:36 ` Dmitry Osipenko 2021-01-14 10:34 ` Mikko Perttunen 2021-01-14 10:34 ` Mikko Perttunen 2021-03-23 12:30 ` Thierry Reding 2021-03-23 12:30 ` Thierry Reding 2021-03-23 14:00 ` Dmitry Osipenko 2021-03-23 14:00 ` Dmitry Osipenko 2021-03-23 16:44 ` Thierry Reding 2021-03-23 16:44 ` Thierry Reding 2021-03-23 17:32 ` Dmitry Osipenko 2021-03-23 17:32 ` Dmitry Osipenko 2021-03-23 17:57 ` Thierry Reding 2021-03-23 17:57 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 16/21] drm/tegra: Boot VIC during runtime PM resume Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 17/21] drm/tegra: Set resv fields when importing/exporting GEMs Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 18/21] drm/tegra: Allocate per-engine channel in core code Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 12:35 ` Thierry Reding 2021-03-23 12:35 ` Thierry Reding 2021-03-23 13:15 ` Mikko Perttunen 2021-03-23 13:15 ` Mikko Perttunen 2021-01-11 13:00 ` [PATCH v5 19/21] drm/tegra: Implement new UAPI Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-11 17:37 ` kernel test robot 2021-01-11 17:37 ` kernel test robot 2021-01-11 17:37 ` kernel test robot 2021-01-12 22:27 ` Dmitry Osipenko 2021-01-12 22:27 ` Dmitry Osipenko 2021-03-23 13:25 ` Thierry Reding 2021-03-23 13:25 ` Thierry Reding 2021-03-23 14:43 ` Mikko Perttunen 2021-03-23 14:43 ` Mikko Perttunen 2021-03-23 15:00 ` Dmitry Osipenko 2021-03-23 15:00 ` Dmitry Osipenko 2021-03-23 16:59 ` Thierry Reding 2021-03-23 16:59 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 20/21] drm/tegra: Implement job submission part of " Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-03-23 13:38 ` Thierry Reding 2021-03-23 13:38 ` Thierry Reding 2021-03-23 14:16 ` Mikko Perttunen 2021-03-23 14:16 ` Mikko Perttunen 2021-03-23 17:04 ` Thierry Reding 2021-03-23 17:04 ` Thierry Reding 2021-01-11 13:00 ` [PATCH v5 21/21] drm/tegra: Add job firewall Mikko Perttunen 2021-01-11 13:00 ` Mikko Perttunen 2021-01-19 22:29 ` [PATCH v5 00/21] Host1x/TegraDRM UAPI Dmitry Osipenko 2021-01-19 22:29 ` Dmitry Osipenko 2021-01-26 2:45 ` Mikko Perttunen 2021-01-26 2:45 ` Mikko Perttunen 2021-01-27 21:20 ` [PATCH v5 00/21] Host1x sync point UAPI should not be used for tracking DRM jobs Dmitry Osipenko 2021-01-27 21:20 ` Dmitry Osipenko 2021-01-28 11:08 ` Mikko Perttunen 2021-01-28 11:08 ` Mikko Perttunen 2021-01-28 16:58 ` Thierry Reding 2021-01-28 16:58 ` Thierry Reding 2021-01-29 17:30 ` Dmitry Osipenko 2021-01-29 17:30 ` Dmitry Osipenko 2021-02-03 11:18 ` Mikko Perttunen 2021-02-03 11:18 ` Mikko Perttunen 2021-02-27 11:19 ` Dmitry Osipenko 2021-02-27 11:19 ` Dmitry Osipenko 2021-03-01 8:19 ` Mikko Perttunen 2021-03-01 8:19 ` Mikko Perttunen 2021-03-23 18:21 ` Thierry Reding 2021-03-23 18:21 ` Thierry Reding 2021-03-23 19:57 ` Dmitry Osipenko 2021-03-23 19:57 ` Dmitry Osipenko 2021-03-23 20:13 ` Dmitry Osipenko 2021-03-23 20:13 ` Dmitry Osipenko 2021-01-27 21:26 ` [PATCH v5 00/21] Host1x/TegraDRM UAPI Dmitry Osipenko 2021-01-27 21:26 ` Dmitry Osipenko 2021-01-27 21:57 ` Mikko Perttunen 2021-01-27 21:57 ` Mikko Perttunen 2021-01-27 22:06 ` Dmitry Osipenko 2021-01-27 22:06 ` Dmitry Osipenko 2021-01-28 11:46 ` Mikko Perttunen 2021-01-28 11:46 ` Mikko Perttunen 2021-01-27 21:35 ` [PATCH v5 00/21] sync_file API is not very suitable for DRM Dmitry Osipenko 2021-01-27 21:35 ` Dmitry Osipenko 2021-01-27 21:53 ` Mikko Perttunen 2021-01-27 21:53 ` Mikko Perttunen 2021-01-27 22:26 ` Dmitry Osipenko 2021-01-27 22:26 ` Dmitry Osipenko 2021-01-27 21:52 ` [PATCH v5 00/21] support option where all commands are collected into a single,dedicated cmdstream Dmitry Osipenko 2021-01-27 21:52 ` Dmitry Osipenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=47840607-8e7c-cc02-bf9b-e001c91f7354@kapsi.fi \ --to=cyndis@kapsi.fi \ --cc=airlied@linux.ie \ --cc=bhuntsman@nvidia.com \ --cc=daniel@ffwll.ch \ --cc=digetx@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=jonathanh@nvidia.com \ --cc=linux-tegra@vger.kernel.org \ --cc=mperttunen@nvidia.com \ --cc=talho@nvidia.com \ --cc=thierry.reding@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.