Re: linux-next: manual merge of the akpm tree with the drm-intel tree
Quoting Daniel Vetter (2020-10-01 18:13:26)
> On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula
> wrote:
> >
> > On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig 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
Re: linux-next: manual merge of the akpm tree with the drm-intel tree
On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula wrote:
>
> On Thu, 01 Oct 2020, Daniel Vetter wrote:
> > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig 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
On Thu, 01 Oct 2020, Daniel Vetter wrote:
> On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig 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
On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig 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
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.
linux-next: manual merge of the akpm tree with the drm-intel tree
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
pgpl21QwEW1P2.pgp
Description: OpenPGP digital signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index d31e15d,49db617..000
--- 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 = _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(>struct_mutex)) {
if (!mutex_is_locked_by(>struct_mutex, current))
@@@ -4683,75 -4653,36 +4681,109 @@@
mutex_unlock(>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(>struct_mutex)) {
+ if (!mutex_is_locked_by(>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(>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 == _priv->mm.aliasing_ppgtt->base)
+ vm = _priv->gtt.base;
+
+ BUG_ON(list_empty(>vma_list));
+ list_for_each_entry(vma, >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, >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, _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 == _priv->mm.aliasing_ppgtt->base)
+ vm = _priv->gtt.base;
+
+ BUG_ON(list_empty(>vma_list));
+
+ list_for_each_entry(vma, >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, >vma_list, vma_link)
+ if (vma->vm == vm)
+ return vma;
+
+ return NULL;
+}
pgpg6Jwhsp2kK.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index d31e15d,49db617..000
--- 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;
+}
pgpg6Jwhsp2kK.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index 50e26d3,a56feaa..000
--- 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 = _priv->gtt.base;
struct drm_i915_gem_object *obj;
bool unlock = true;
- long cnt;
+ unsigned long count;
if (!mutex_trylock(>struct_mutex)) {
if (!mutex_is_locked_by(>struct_mutex, current))
@@@ -4629,13 -4584,13 +4629,13 @@@
unlock = false;
}
- cnt = 0;
+ count = 0;
list_for_each_entry(obj, _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, _priv->mm.inactive_list, mm_list)
+ list_for_each_entry(obj, >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(>struct_mutex);
pgpuoOMS5PVA2.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index 50e26d3,a56feaa..000
--- 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);
pgpuoOMS5PVA2.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/i915_gem.c
index 8e57029,e743c27..000
--- 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, _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, _priv->mm.inactive_list, global_list)
+ list_for_each_entry(obj, _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(>struct_mutex);
pgpM2KBxB8ReH.pgp
Description: PGP signature
linux-next: manual merge of the akpm tree with the drm-intel tree
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 Rothwells...@canb.auug.org.au diff --cc drivers/gpu/drm/i915/i915_gem.c index 8e57029,e743c27..000 --- 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); pgpM2KBxB8ReH.pgp Description: PGP signature
