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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/10/2019 19:08, Jean-Jacques Hiblot wrote:

On 07/10/2019 14:16, Tomi Valkeinen wrote:
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 didn't touch those patches a lot. Apart from the first one (the atomic stuff) and the kernel-doc style comment in the last patch, it is pretty much the stuff that you authored and is now part of TI's tree.

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.

Done.

Thanks! I'll push these to drm-misc-next.

 Tomi

--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux