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