| Message ID | 20190708104520.24217-1-jjhiblot@ti.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | drm/omap: OMAP_BO flags | expand |
Hi JJ, On 08/07/2019 13:45, 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 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 Were there any changes to these patches compared to the ones I sent a few years back? If I recall right, one valid comment from Laurent was also about adding kernel-doc for include/uapi/drm/omap_drm.h. The OMAP_BO_* flags could have a bit more explanations in the form of kernel doc. Tomi
On 01/08/2019 11:02, Tomi Valkeinen wrote: > Hi JJ, > > On 08/07/2019 13:45, 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 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 > > Were there any changes to these patches compared to the ones I sent a > few years back? Yes they are a bit different. I took the patches from the TI tree no from ML. In thoses patches you had already taken in account most (all ?) of the comments, including a better description of the different flags and some changes in names. I only modified and reordered them to fix a build breakage. (this is related to OMAP_BO_TILED being removed) Also I added a patch to address Laurent's comment about the use of atomic > > If I recall right, one valid comment from Laurent was also about > adding kernel-doc for include/uapi/drm/omap_drm.h. The OMAP_BO_* flags > could have a bit more explanations in the form of kernel doc. OK I didn't address this one. I'll will for v2. > Tomi >
On 01/08/2019 11:02, Tomi Valkeinen wrote: > Hi JJ, > > On 08/07/2019 13:45, 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 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 > > Were there any changes to these patches compared to the ones I sent a > few years back? Yes they are a bit different. I took the patches from the TI tree no from ML. In thoses patches you had already taken in account most (all ?) of the comments, including a better description of the different flags and some changes in names. I only modified and reordered them to fix a build breakage. (this is related to OMAP_BO_TILED being removed) Also I added a patch to address Laurent's comment about the use of atomic > > If I recall right, one valid comment from Laurent was also about > adding kernel-doc for include/uapi/drm/omap_drm.h. The OMAP_BO_* flags > could have a bit more explanations in the form of kernel doc. OK I didn't address this one. I'll update the comments in a v3. > Tomi >