[PATCH v3 0/8] drm/omap: OMAP_BO flags

[Tomi Valkeinen]

On 07/10/2019 14:25, Jean-Jacques Hiblot wrote:
> A first version of this work had been sent by Tomi Valkeinen in may 2017
> (https://www.spinics.net/lists/dri-devel/msg140663.html).
> 
> This series adds a few new OMAP_BO flags to help the userspace manage
> situations where it needs to use lots of buffers, and would currently run
> out of TILER space. The TILER space is limited to mapping 128MB at any given
> time and some applications might need more.
> 
> This seres is also the opportunity to do some cleanup in the flags and
> improve the comments describing them.
> 
> The user-space patches for libdrm, although ready, haven't been posted yet.
> It will be be done when this series have been discussed and hopefully in
> the process of getting merged.
> 
> JJ
> 
> changes in v3:
> - rebase on top of v5.4-rc2
> - Document omap_gem_new() and the new flags using the kernel-doc format
> 
> changes in v2:
> - fixed build error that crept in during rebase before sending (sorry
>    about that)
> - rework the refcount part a bit.
> 
> Jean-Jacques Hiblot (1):
>    drm/omap: use refcount API to track the number of users of dma_addr
> 
> Tomi Valkeinen (7):
>    drm/omap: add omap_gem_unpin_locked()
>    drm/omap: accept NULL for dma_addr in omap_gem_pin
>    drm/omap: cleanup OMAP_BO flags
>    drm/omap: remove OMAP_BO_TILED define
>    drm/omap: cleanup OMAP_BO_SCANOUT use
>    drm/omap: add omap_gem_validate_flags()
>    drm/omap: add OMAP_BO flags to affect buffer allocation
> 
>   drivers/gpu/drm/omapdrm/omap_dmm_tiler.h  |   2 +-
>   drivers/gpu/drm/omapdrm/omap_fb.c         |   6 +-
>   drivers/gpu/drm/omapdrm/omap_gem.c        | 191 ++++++++++++++++------
>   drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |   2 +-
>   include/uapi/drm/omap_drm.h               |  27 ++-
>   5 files changed, 164 insertions(+), 64 deletions(-)

Thanks! This looks good to me. One comment, though:

Some people may have different opinions on how to manage other people's 
patches, but here's mine:

If you have made changes to a patch from someone else (me, in this 
case), other than really trivial typo fixes or such, you should add your 
signed-off-by.

Also, if you change the patch in a way that might make it behave 
differently than the original, you should change the ownership to 
yourself, drop the original signed-off-by, and perhaps say in the desc 
that the original was written by xyz. I don't want "my" patch to cause 
kernel crashes, if it's really not my code =).

Actually, I see we now have "Co-developed-by" documented in 
Documentation/process/5.Posting.rst. That may be suitable here.

And for the patches that you didn't touch, I'm sure you've still gone 
through those, so you could add your reviewed-by.

  Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki