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
JJ
Tomi
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
