Hi all,
Today's linux-next merge of the akpm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_pages.c
between commit:
4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
from the drm-intel tree and patch:
"drm/i915: use vmap in i915_gem_object_map"
from the akpm tree.
I fixed it up (I just dropped the changes in the former commits) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
--
Cheers,
Stephen Rothwell
On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_pages.c
>
> between commit:
>
> 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
> ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
>
> from the drm-intel tree and patch:
>
> "drm/i915: use vmap in i915_gem_object_map"
>
> from the akpm tree.
>
> I fixed it up (I just dropped the changes in the former commits) and
Sigh. The solution is a bit more complicated, but I just redid my
patches to not depend on the above ones. I can revert back to the old
version, though. Andrew, let me know what works for you.
On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <[email protected]> wrote:
>
> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the akpm tree got a conflict in:
> >
> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> >
> > between commit:
> >
> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
Uh these patches shouldn't be in linux-next because they're for 5.11,
not the 5.10 merge window that will open soon. Joonas?
> > from the drm-intel tree and patch:
> >
> > "drm/i915: use vmap in i915_gem_object_map"
> >
> > from the akpm tree.
> >
> > I fixed it up (I just dropped the changes in the former commits) and
>
> Sigh. The solution is a bit more complicated, but I just redid my
> patches to not depend on the above ones. I can revert back to the old
> version, though. Andrew, let me know what works for you.
Imo ignore, rebasing onto linux-next without those intel patches was
the right thing for the 5.10 merge window.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, 01 Oct 2020, Daniel Vetter <[email protected]> wrote:
> On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <[email protected]> wrote:
>>
>> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
>> > Hi all,
>> >
>> > Today's linux-next merge of the akpm tree got a conflict in:
>> >
>> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
>> >
>> > between commit:
>> >
>> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
>> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
>
> Uh these patches shouldn't be in linux-next because they're for 5.11,
> not the 5.10 merge window that will open soon. Joonas?
I don't know anything else, but both are tagged Cc: stable.
BR,
Jani.
>
>> > from the drm-intel tree and patch:
>> >
>> > "drm/i915: use vmap in i915_gem_object_map"
>> >
>> > from the akpm tree.
>> >
>> > I fixed it up (I just dropped the changes in the former commits) and
>>
>> Sigh. The solution is a bit more complicated, but I just redid my
>> patches to not depend on the above ones. I can revert back to the old
>> version, though. Andrew, let me know what works for you.
>
> Imo ignore, rebasing onto linux-next without those intel patches was
> the right thing for the 5.10 merge window.
> -Daniel
--
Jani Nikula, Intel Open Source Graphics Center
On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula <[email protected]> wrote:
>
> On Thu, 01 Oct 2020, Daniel Vetter <[email protected]> wrote:
> > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <[email protected]> wrote:
> >>
> >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> >> > Hi all,
> >> >
> >> > Today's linux-next merge of the akpm tree got a conflict in:
> >> >
> >> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> >> >
> >> > between commit:
> >> >
> >> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
> >> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
> >
> > Uh these patches shouldn't be in linux-next because they're for 5.11,
> > not the 5.10 merge window that will open soon. Joonas?
>
> I don't know anything else, but both are tagged Cc: stable.
Uh right I got confused, they're on -fixes now. Well -next-fixes,
which seems like the wrong one for a cc: stable, I guess this should
go into 5.9 even. Apologies for my confusion.
-Daniel
>
> BR,
> Jani.
>
> >
> >> > from the drm-intel tree and patch:
> >> >
> >> > "drm/i915: use vmap in i915_gem_object_map"
> >> >
> >> > from the akpm tree.
> >> >
> >> > I fixed it up (I just dropped the changes in the former commits) and
> >>
> >> Sigh. The solution is a bit more complicated, but I just redid my
> >> patches to not depend on the above ones. I can revert back to the old
> >> version, though. Andrew, let me know what works for you.
> >
> > Imo ignore, rebasing onto linux-next without those intel patches was
> > the right thing for the 5.10 merge window.
> > -Daniel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula <[email protected]> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter <[email protected]> wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <[email protected]> wrote:
> > >>
> > >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote:
> > >> > Hi all,
> > >> >
> > >> > Today's linux-next merge of the akpm tree got a conflict in:
> > >> >
> > >> > drivers/gpu/drm/i915/gem/i915_gem_pages.c
> > >> >
> > >> > between commit:
> > >> >
> > >> > 4caf017ee937 ("drm/i915/gem: Avoid implicit vmap for highmem on x86-32")
> > >> > ba2ebf605d5f ("drm/i915/gem: Prevent using pgprot_writecombine() if PAT is not supported")
> > >
> > > Uh these patches shouldn't be in linux-next because they're for 5.11,
> > > not the 5.10 merge window that will open soon. Joonas?
> >
> > I don't know anything else, but both are tagged Cc: stable.
>
> Uh right I got confused, they're on -fixes now. Well -next-fixes,
> which seems like the wrong one for a cc: stable, I guess this should
> go into 5.9 even. Apologies for my confusion.
Yep, they happen to be Fixes: (Cc: stable even) so I asked Rodrigo to
pull them to drm-intel-next-fixes.
If they weren't Fixes: then indeed they would only have been queued for
5.11.
With regards to 5.9, due to the hiccup of doing the split PR, all the
-fixes for GT area were in limbo until -rc7. We didn't feel comfortable
including all the new commits this late in the cycle, so we agreed stable
porting those will be more appropriate.
Regards, Joonas
> -Daniel
>
> >
> > BR,
> > Jani.
> >
> > >
> > >> > from the drm-intel tree and patch:
> > >> >
> > >> > "drm/i915: use vmap in i915_gem_object_map"
> > >> >
> > >> > from the akpm tree.
> > >> >
> > >> > I fixed it up (I just dropped the changes in the former commits) and
> > >>
> > >> Sigh. The solution is a bit more complicated, but I just redid my
> > >> patches to not depend on the above ones. I can revert back to the old
> > >> version, though. Andrew, let me know what works for you.
> > >
> > > Imo ignore, rebasing onto linux-next without those intel patches was
> > > the right thing for the 5.10 merge window.
> > > -Daniel
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch