[PATCH] drm/ttm: Make sure BOs being swapped out are cacheable

[Daniel Vetter]

On Fri, Jan 27, 2017 at 03:43:18PM +0100, Christian König wrote:
> Am 27.01.2017 um 15:12 schrieb Daniel Vetter:
> > On Fri, Jan 27, 2017 at 09:22:47AM +0100, Christian König wrote:
> > > Am 27.01.2017 um 08:30 schrieb Daniel Vetter:
> > > > On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote:
> > > > > On 01/27/2017 03:29 AM, Michel Dänzer wrote:
> > > > > > On 26/01/17 09:46 AM, Sinclair Yeh wrote:
> > > > > > > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote:
> > > > > > > > Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom:
> > > > > > > > > On 01/25/2017 09:21 AM, Michel Dänzer wrote:
> > > > > > > > > > From: Michel Dänzer <michel.daenzer at amd.com>
> > > > > > > > > > 
> > > > > > > > > > The current caching state may not be tt_cached, even though the
> > > > > > > > > > placement contains TTM_PL_FLAG_CACHED, because placement can contain
> > > > > > > > > > multiple caching flags. Trying to swap out such a BO would trip up the
> > > > > > > > > > 
> > > > > > > > > > 	BUG_ON(ttm->caching_state != tt_cached);
> > > > > > > > > > 
> > > > > > > > > > in ttm_tt_swapout.
> > > > > > > > > > 
> > > > > > > > > > Cc: stable at vger.kernel.org
> > > > > > > > > > Signed-off-by: Michel Dänzer <michel.daenzer at amd.com>
> > > > > > > > > Reviewed-by: Thomas Hellstrom <thellstrom at vmware.com>
> > > > > > > > Reviewed-by: Christian König <christian.koenig at amd.com>.
> > > > > > > Reviewed-by: Sinclair Yeh <syeh at vmware.com>
> > > > > > Thanks for the reviews! Via which tree should we merge this?
> > > > > > 
> > > > > > 
> > > > > I don't maintain a TTM tree any longer. Let's check with Daniel if he
> > > > > can merge it through drm-misc.
> > > > I'm trying very hard not to get volunteered for ttm maintainer :-)
> > > Yeah, ok I volunteer. Wanted to take that over for a while anyway.
> > I guess you didn't use the dim magic to push it? The test integration tree
> > isn't rebuild ... Quickstart for the tooling:
> 
> Autsch! Do I have to use that or can I just go with my usual tool set?
> 
> Would probably be a pain to set this up everywhere here.

We use it both for convience (e.g. it auto-adds the sob if need, and the
patchwork link by default), and to catch mistakes (e.g. it checks that
you're not pushing patches outside of the scope of drm-misc or i915 to the
wrong tree). For drm-misc specifically there's also the 3 defconfigs
you're supposed to build test before pushing (unfornately not scripted
since distros can't even agree on what cross-compiler prefixes work for a
given platform). And since 1 month ago we have an arm-soc ttm-based
driver, so doing that for ttm patches is kinda a good idea too :-)

But right now the main thing is this integration tree magic to regenerate
drm-tip, and that's also what intel CI and kernelci from collabora beat
on. Long term I'd love to push all this onto the server-side (github makes
scipting a lot of this dead easy). But we're still stuck with patches
scribbled on stones with emailed patches and all that, so client-side
scripts are kinda needed.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch