| Message ID | 20191007112555.25278-1-jjhiblot@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/omap: OMAP_BO flags | expand |
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
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 >
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