Am 04.06.21 um 16:11 schrieb Thomas Hellström:
On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote:
Am 04.06.21 um 16:03 schrieb Thomas Hellström:
On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote:
Am 04.06.21 um 11:12 schrieb Daniel Vetter:
On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström
wrote:
On 6/4/21 9:51 AM, Christian König wrote:
Am 03.06.21 um 09:36 schrieb Daniel Vetter:
On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström
<thomas.hellstrom@xxxxxxxxxxxxxxx> wrote:
On 6/2/21 8:40 PM, Daniel Vetter wrote:
On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian
König
wrote:
Am 02.06.21 um 11:16 schrieb Thomas Hellström
(Intel):
On 6/2/21 10:32 AM, Christian König wrote:
Uff I'm just waiting for feedback from Philip
to
merge a large patch
set for TTM through drm-misc-next.
I'm pretty sure we will run into merge
conflicts if
you try to push
your changes through the Intel tree.
Christian.
OK, so what would be the best approach here?,
Adding
the TTM patches to
drm-misc-next when your set has landed?
I think I will send out out my set to Matthew once
more
for review, then
push the common TTM stuff to drm-misc-next as much
as
possible.
Then you should be able to land your stuff to
drm-misc-next and rebase on
the end result.
Just need to note to David that drm-misc-next
should be
merged to drm-next
before the Intel patches depending on that stuff
land
as well.
Other option (because the backmerges tend to be slow)
is
a
topic branch,
and we just eat/resolve the conflicts in both drm-
misc-
next and
drm-intel-gt-next in the merge commit. If it's not
too
bad (I haven't
looked at what exactly we need for the i915 side from
ttm
in detail).
But also often figuring out the topic branch
logistics
takes
longer than
just merging to drm-misc-next as the patches get
ready.
-Daniel
Daniel: So the thing we need to get into TTM is the
iterator-based
move_memcpy which is more adaptable than the current
one
and needed to
support non-linear lmem buffers, some bug-fixes and
minor
changes to be
able to keep our short-term-pinning while on the LRU. A
necessary evil.
Christian: it looks like you have landed some TTM
changes
already, in
particular the &bo->mem -> bo->resource change which is
the
main
conflict I think.
Yes, I thought that pushing this with Matthew rb should
solve
at least a
bit of the conflict.
Is the 10 patches self-allocation series the main
remaining part?
Yes, exactly. I only need Matthew's, Daniel's or your ok
and
I'm good to
go as well
That will probably cause some conflicts with already
pushed i915 TTM setup code, but otherwise will not
conflict
with the
rest of the TTM code I think, which should make it
possible
to bring in
our TTM changes after conflict resolution with what
you've
already
pushed. The memcpy code is pretty self-contained.
I think in that case topic branch on top of drm-next
(once
the ttm
bits we conflict with are there) is probably best, and
then
pull that
into drm-misc-next and drm-intel-gt-next. Merge window
freeze
is also
approach, so without topic branch we'd be stuck until
like -
rc2 when
drm-next reopens. I guess Maarten can do the topic branch
logistics in
drm-misc.git for this.
That approach sounds good to me as well.
The amdgpu branch had some merge conflicts as well, but
nothing
we
couldn't fix.
OK, so this is going to be a little tricky, I guess.
From what I can tell, the memcpy TTM stuff is resolved
locally
and can be
merged to drm-misc-next immediately. It might have a very
minor
conflict
with your 10 patches I think, if any.
Your 10 patches will conflict slightly with current drm-
intel-gt-
next I
think.
Remaining intel patches will conflict only with current drm-
misc-
next.
So We could have pull order
- drm-misc-next up to bot not including your 10 patches,
- drm-intel-gt-next
- drm-misc-next from your 10 paches and onwards,
- Intel's ttm enablement topic branch.
If it's just slight conflicts then I wouldn't bother with
careful
merge
order. Because if we do this we can get around to the i915 ttm
topic
branch only when we're back to -rc2.
I've just pushed the remaining 10 patches to drm-misc-next and
ran
into
minor merge conflicts in drm-tip.
I'm working on this, but I'm not very familiar with drm-tip
handling.
Christian.
Np, I'll hold off until Monday.
Ok I've fixed up drm-tip for amdgpu, but there are also merge
conflicts
for i915.
Can you handle those? Doesn't looks to hard, but I would prefer not
to
touch code I can't test.
Christian.
Hi, Christian,
Unfortunately I can't (not until monday at least as I'm off for the
weekend). But I did warn you twice about those.
Ok in this case I will just fix them up as best as I can.
Thanks,
Christian.
/Thomas
/Thomas
