[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sgv14mcp.fsf@anholt.net>
Date: Mon, 01 Apr 2019 11:22:14 -0700
From: Eric Anholt <eric@...olt.net>
To: Rob Herring <robh@...nel.org>, Daniel Vetter <daniel@...ll.ch>
Cc: dri-devel <dri-devel@...ts.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Will Deacon <will.deacon@....com>,
Robin Murphy <robin.murphy@....com>,
Joerg Roedel <joro@...tes.org>,
"list\@263.net\:IOMMU DRIVERS \<iommu\@lists.linux-foundation.org\>\,
Joerg Roedel \<joro\@8bytes.org\>\,"
<iommu@...ts.linux-foundation.org>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <maxime.ripard@...tlin.com>,
Sean Paul <sean@...rly.run>, David Airlie <airlied@...ux.ie>,
Alyssa Rosenzweig <alyssa@...enzweig.io>,
Lyude Paul <lyude@...hat.com>,
Neil Armstrong <narmstrong@...libre.com>
Subject: Re: [PATCH v2 2/3] drm: Add a drm_gem_objects_lookup helper
Rob Herring <robh@...nel.org> writes:
> On Mon, Apr 1, 2019 at 8:07 AM Daniel Vetter <daniel@...ll.ch> wrote:
>>
>> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring <robh@...nel.org> wrote:
>> >
>> > Similar to the single handle drm_gem_object_lookup(),
>> > drm_gem_objects_lookup() takes an array of handles and returns an array
>> > of GEM objects.
>> >
>> > Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
>> > Cc: Maxime Ripard <maxime.ripard@...tlin.com>
>> > Cc: Sean Paul <sean@...rly.run>
>> > Cc: David Airlie <airlied@...ux.ie>
>> > Cc: Daniel Vetter <daniel@...ll.ch>
>> > Signed-off-by: Rob Herring <robh@...nel.org>
>> > ---
>> > drivers/gpu/drm/drm_gem.c | 46 +++++++++++++++++++++++++++++++--------
>> > include/drm/drm_gem.h | 2 ++
>> > 2 files changed, 39 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>> > index 388b3742e562..5c9bff45e5e1 100644
>> > --- a/drivers/gpu/drm/drm_gem.c
>> > +++ b/drivers/gpu/drm/drm_gem.c
>> > @@ -663,6 +663,42 @@ void drm_gem_put_pages(struct drm_gem_object *obj, struct page **pages,
>> > }
>> > EXPORT_SYMBOL(drm_gem_put_pages);
>> >
>> > +/**
>> > + * drm_gem_objects_lookup - look up GEM objects from an array of handles
>> > + * @filp: DRM file private date
>> > + * @handle: pointer to array of userspace handle
>> > + * @count: size of handle array
>> > + * @objs: pointer to array of drm_gem_object pointers
>> > + *
>> > + * Returns:
>> > + *
>> > + * @objs filled in with GEM object pointers. -ENOENT is returned on a lookup
>> > + * failure. 0 is returned on success.
>>
>> Bonus points for adding references between the array and normal lookup
>> functions to guide people around. Also a comment that the buffers need
>> to be released with drm_gem_object_put().
>>
>> > + */
>> > +int drm_gem_objects_lookup(struct drm_file *filp, u32 *handle, int count,
>> > + struct drm_gem_object **objs)
>>
>> With a pointer to a pointer I'd expect this function to do the
>> allocation, but it doesn't. Normal pointer is enough to pass an array.
>> Also maybe make the handle pointer
>> const, so it's clear that it's an input parameter.
>
> I thought about doing the allocation here, but then I couldn't
> implement the single drm_gem_object_lookup() using this function.
> Maybe I can refactor in 3 functions making this one a static function.
FWIW, I was thinking for v3d that I'd probably add a helper that took in
the user's pointer to handles :)
Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)
Powered by blists - more mailing lists