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

[Jean-Jacques Hiblot]

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
>