The TTM LRU-walk cherry-pick series

[Matthew Brost]

On Tue, Jul 09, 2024 at 12:54:13PM +0200, Christian König wrote:
> Am 08.07.24 um 17:34 schrieb Matthew Brost:
> > On Mon, Jul 08, 2024 at 05:29:30PM +0200, Christian König wrote:
> > > Am 08.07.24 um 17:23 schrieb Matthew Brost:
> > > > On Sun, Jul 07, 2024 at 05:49:16PM +0200, Thomas Hellström wrote:
> > > > > Christian, Matthew,
> > > > > 
> > > > > I think I addressed all review comments and a couple of anticipated
> > > > > ones (s/long/s64/) in the swapout- and eviction patches.
> > > > > 
> > > > > I'm heading off on vacation today, (4 weeks) so if something becomes
> > > > > urgent in-between feel free to pick up, modify and merge.
> > > > > 
> > > > I found a couple of nits in last patch of [1] but gave an RB as the nits
> > > > can be fixed on upon merge.
> > > > 
> > > > The series [1] is fully RB'd and CI looks good. I'm thinking we should
> > > > merge this. If any bugs pop after merging feel confident that I can
> > > > quickly fix them while Thomas is out. Also fine for waiting for Thomas
> > > > to return too.
> > > > 
> > > > What do you think Christian?
> > > I'm currently working on testing patches 1-7 and if that doesn't show any
> > > immediate problems will push them to drm-misc-next.
> > > 
> > +1
> 
> And pushed.
> 

Great.

> > 
> > > The kernel build bot also complained about something in #8 additionally to
> > > your nit picks so I think we should investigate that first.
> > > 
> > > > drivers/gpu/drm/ttm/ttm_resource.c:607: warning: Excess function parameter 'man' description in 'ttm_resource_manager_first'
> > That is the kernel doc nit I raised.
> 
> Ah, yeah ok. For that minor cleanup we can wait for Thomas to be back from
> vacation.
> 
> Important point is I can now rebase my drm_exec work on top of it.
>

Sounds good. Will keep an eye out for drm_exec changes.

Matt
 
> Regards,
> Christian.
> 
> > 
> > Matt
> > 
> > > Christian.
> > > 
> > > > Matt
> > > > 
> > > > [1] https://patchwork.freedesktop.org/series/135801/
> > > > 
> > > > > Regarding the drm_exec trylock functionality I'm for as much as
> > > > > possible that it should look like any other locking primitive trylock.
> > > > > i.e. no additional tricks needed.
> > > > > 
> > > > > Thanks,
> > > > > Thomas
> > > > > 
> > > > > 
>