Am 2022-06-09 um 03:18 schrieb Christian König:
Am 09.06.22 um 02:05 schrieb Felix Kuehling:
[SNIP]
+ *
+ * ret = drm_exec_lock(&exec, boB, 1);
Where is drm_exec_lock? It's not in this patch.
I've renamed this function to drm_exec_prepare_obj() but forgot to
update the documentati
Am 09.06.22 um 02:05 schrieb Felix Kuehling:
[SNIP]
+ *
+ * ret = drm_exec_lock(&exec, boB, 1);
Where is drm_exec_lock? It's not in this patch.
I've renamed this function to drm_exec_prepare_obj() but forgot to
update the documentation. Going to fix this, thanks.
+ * drm_exec_c
On 2022-05-04 03:47, Christian König wrote:
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many differe
On Mon, May 09, 2022 at 05:01:33PM +0200, Christian König wrote:
> Am 09.05.22 um 16:31 schrieb Daniel Vetter:
> > On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
> > > [SNIP]
> > > +/* Make sure we have enough room and add an object the container */
> > > +static int drm_exec_obje
Am 09.05.22 um 16:31 schrieb Daniel Vetter:
On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
[SNIP]
+/* Make sure we have enough room and add an object the container */
+static int drm_exec_objects_add(struct drm_exec_objects *container,
+ struct drm
On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
> This adds the infrastructure for an execution context for GEM buffers
> which is similar to the existinc TTMs execbuf util and intended to replace
> it in the long term.
>
> The basic functionality is that we abstracts the necessar
