linux-next: manual merge of the akpm tree with the drm-intel tree

linux-next: manual merge of the akpm tree with the drm-intel tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

[Christoph Hellwig]

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.

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

[Daniel Vetter]

On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <hch@lst.de> 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

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

[Jani Nikula]

On Thu, 01 Oct 2020, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <hch@lst.de> 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

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

[Daniel Vetter]

On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Thu, 01 Oct 2020, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <hch@lst.de> 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

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

[Joonas Lahtinen]

Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig <hch@lst.de> 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

linux-next: manual merge of the akpm tree with the drm-intel tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3916 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit a70a3148b0c6 ("drm/i915:
Make proper functions for VMs") from the drm-intel tree and commit
e6950216e0af ("drivers: convert shrinkers to new count/scan API") from
the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index d31e15d,49db617..0000000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4642,10 -4626,10 +4650,9 @@@ i915_gem_inactive_count(struct shrinke
  			     struct drm_i915_private,
  			     mm.inactive_shrinker);
  	struct drm_device *dev = dev_priv->dev;
 -	struct i915_address_space *vm = &dev_priv->gtt.base;
  	struct drm_i915_gem_object *obj;
- 	int nr_to_scan = sc->nr_to_scan;
  	bool unlock = true;
- 	int cnt;
+ 	long cnt;
  
  	if (!mutex_trylock(&dev->struct_mutex)) {
  		if (!mutex_is_locked_by(&dev->struct_mutex, current))
@@@ -4683,75 -4653,36 +4681,109 @@@
  		mutex_unlock(&dev->struct_mutex);
  	return cnt;
  }
 +
+ static long
+ i915_gem_inactive_scan(struct shrinker *shrinker, struct shrink_control *sc)
+ {
+ 	struct drm_i915_private *dev_priv =
+ 		container_of(shrinker,
+ 			     struct drm_i915_private,
+ 			     mm.inactive_shrinker);
+ 	struct drm_device *dev = dev_priv->dev;
+ 	int nr_to_scan = sc->nr_to_scan;
+ 	long freed;
+ 	bool unlock = true;
+ 
+ 	if (!mutex_trylock(&dev->struct_mutex)) {
+ 		if (!mutex_is_locked_by(&dev->struct_mutex, current))
+ 			return 0;
+ 
+ 		if (dev_priv->mm.shrinker_no_lock_stealing)
+ 			return 0;
+ 
+ 		unlock = false;
+ 	}
+ 
+ 	freed = i915_gem_purge(dev_priv, nr_to_scan);
+ 	if (freed < nr_to_scan)
+ 		freed += __i915_gem_shrink(dev_priv, nr_to_scan,
+ 							false);
+ 	if (freed < nr_to_scan)
+ 		freed += i915_gem_shrink_all(dev_priv);
+ 
+ 	if (unlock)
+ 		mutex_unlock(&dev->struct_mutex);
+ 	return freed;
+ }
++
 +/* All the new VM stuff */
 +unsigned long i915_gem_obj_offset(struct drm_i915_gem_object *o,
 +				  struct i915_address_space *vm)
 +{
 +	struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +	struct i915_vma *vma;
 +
 +	if (vm == &dev_priv->mm.aliasing_ppgtt->base)
 +		vm = &dev_priv->gtt.base;
 +
 +	BUG_ON(list_empty(&o->vma_list));
 +	list_for_each_entry(vma, &o->vma_list, vma_link) {
 +		if (vma->vm == vm)
 +			return vma->node.start;
 +
 +	}
 +	return -1;
 +}
 +
 +bool i915_gem_obj_bound(struct drm_i915_gem_object *o,
 +			struct i915_address_space *vm)
 +{
 +	struct i915_vma *vma;
 +
 +	list_for_each_entry(vma, &o->vma_list, vma_link)
 +		if (vma->vm == vm)
 +			return true;
 +
 +	return false;
 +}
 +
 +bool i915_gem_obj_bound_any(struct drm_i915_gem_object *o)
 +{
 +	struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +	struct i915_address_space *vm;
 +
 +	list_for_each_entry(vm, &dev_priv->vm_list, global_link)
 +		if (i915_gem_obj_bound(o, vm))
 +			return true;
 +
 +	return false;
 +}
 +
 +unsigned long i915_gem_obj_size(struct drm_i915_gem_object *o,
 +				struct i915_address_space *vm)
 +{
 +	struct drm_i915_private *dev_priv = o->base.dev->dev_private;
 +	struct i915_vma *vma;
 +
 +	if (vm == &dev_priv->mm.aliasing_ppgtt->base)
 +		vm = &dev_priv->gtt.base;
 +
 +	BUG_ON(list_empty(&o->vma_list));
 +
 +	list_for_each_entry(vma, &o->vma_list, vma_link)
 +		if (vma->vm == vm)
 +			return vma->node.size;
 +
 +	return 0;
 +}
 +
 +struct i915_vma *i915_gem_obj_to_vma(struct drm_i915_gem_object *obj,
 +				     struct i915_address_space *vm)
 +{
 +	struct i915_vma *vma;
 +	list_for_each_entry(vma, &obj->vma_list, vma_link)
 +		if (vma->vm == vm)
 +			return vma;
 +
 +	return NULL;
 +}

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the drm-intel tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 5cef07e16283 ("drm/i915:
Move active/inactive lists to new mm") from the drm-intel tree and commit
"drivers-convert-shrinkers-to-new-count-scan-api-fix" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index 50e26d3,a56feaa..0000000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4614,10 -4570,9 +4614,10 @@@ i915_gem_inactive_count(struct shrinke
  			     struct drm_i915_private,
  			     mm.inactive_shrinker);
  	struct drm_device *dev = dev_priv->dev;
 +	struct i915_address_space *vm = &dev_priv->gtt.base;
  	struct drm_i915_gem_object *obj;
  	bool unlock = true;
- 	long cnt;
+ 	unsigned long count;
  
  	if (!mutex_trylock(&dev->struct_mutex)) {
  		if (!mutex_is_locked_by(&dev->struct_mutex, current))
@@@ -4629,13 -4584,13 +4629,13 @@@
  		unlock = false;
  	}
  
- 	cnt = 0;
+ 	count = 0;
  	list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
  		if (obj->pages_pin_count == 0)
- 			cnt += obj->base.size >> PAGE_SHIFT;
+ 			count += obj->base.size >> PAGE_SHIFT;
 -	list_for_each_entry(obj, &dev_priv->mm.inactive_list, mm_list)
 +	list_for_each_entry(obj, &vm->inactive_list, mm_list)
  		if (obj->pin_count == 0 && obj->pages_pin_count == 0)
- 			cnt += obj->base.size >> PAGE_SHIFT;
+ 			count += obj->base.size >> PAGE_SHIFT;
  
  	if (unlock)
  		mutex_unlock(&dev->struct_mutex);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the akpm tree with the drm-intel tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1319 bytes --]

Hi Andrew,

Today's linux-next merge of the akpm tree got a conflict in
drivers/gpu/drm/i915/i915_gem.c between commit 857d0a9a6e9e ("drm/i915:
Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list") from
the drm-intel tree and commit
"drivers-convert-shrinkers-to-new-count-scan-api-fix" from the akpm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/gpu/drm/i915/i915_gem.c
index 8e57029,e743c27..0000000
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@@ -4605,13 -4605,13 +4605,13 @@@ i915_gem_inactive_count(struct shrinke
  		unlock = false;
  	}
  
- 	cnt = 0;
+ 	count = 0;
  	list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_list)
  		if (obj->pages_pin_count == 0)
- 			cnt += obj->base.size >> PAGE_SHIFT;
+ 			count += obj->base.size >> PAGE_SHIFT;
 -	list_for_each_entry(obj, &dev_priv->mm.inactive_list, global_list)
 +	list_for_each_entry(obj, &dev_priv->mm.inactive_list, mm_list)
  		if (obj->pin_count == 0 && obj->pages_pin_count == 0)
- 			cnt += obj->base.size >> PAGE_SHIFT;
+ 			count += obj->base.size >> PAGE_SHIFT;
  
  	if (unlock)
  		mutex_unlock(&dev->struct_mutex);

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]