Hi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160419]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915
On 19/04/16 12:06, Chris Wilson wrote:
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
On 18/04/16 16:22, Chris Wilson wrote:
On Mon, Apr 18, 2016 at 04:08:55PM +0100, Tvrtko Ursulin wrote:
On 18/04/16 15:54, Chris Wilson wrote:
@@ -3378,6 +3378,8 @@ static int __i915_vma_unbind(struct i915_vma *vma, bool
wait)
ret = i915_gem_object_put_fence(obj);
On Mon, Apr 18, 2016 at 04:08:55PM +0100, Tvrtko Ursulin wrote:
> On 18/04/16 15:54, Chris Wilson wrote:
> >@@ -3378,6 +3378,8 @@ static int __i915_vma_unbind(struct i915_vma *vma,
> >bool wait)
> > ret = i915_gem_object_put_fence(obj);
> > if (ret)
> >
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160418]
[cannot apply to v4.6-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dr
On 18/04/16 15:54, Chris Wilson wrote:
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
On pe, 2016-04-15 at 11:38 +0100, Chris Wilson wrote:
> On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote:
> >
> > On 15/04/16 11:00, Chris Wilson wrote:
> > >
> > > On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
> > > >
> > > >
> > > > On 13/04/16 16:12, Chris Wil
On 15/04/16 11:38, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote:
On 15/04/16 11:00, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chri
On Fri, Apr 15, 2016 at 11:19:30AM +0100, Tvrtko Ursulin wrote:
> On 15/04/16 11:00, Chris Wilson wrote:
> >On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 13/04/16 16:12, Chris Wilson wrote:
> >>>On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
> + /* W
On 15/04/16 11:00, Chris Wilson wrote:
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
+ /* We also want to clear any cached iomaps as they wrap vmap */
+ list_for_
On Fri, Apr 15, 2016 at 10:40:42AM +0100, Tvrtko Ursulin wrote:
>
> On 13/04/16 16:12, Chris Wilson wrote:
> >On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
> >>+ /* We also want to clear any cached iomaps as they wrap vmap */
> >>+ list_for_each_entry_safe(vma, next,
> >>+
On 13/04/16 16:12, Chris Wilson wrote:
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
+ /* We also want to clear any cached iomaps as they wrap vmap */
+ list_for_each_entry_safe(vma, next,
+&dev_priv->ggtt.base.inactive_list, vm_link)
On Wed, Apr 13, 2016 at 03:47:58PM +0100, Chris Wilson wrote:
> + /* We also want to clear any cached iomaps as they wrap vmap */
> + list_for_each_entry_safe(vma, next,
> + &dev_priv->ggtt.base.inactive_list, vm_link)
> + if (vma->iomap && i915_vma_
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160413]
[cannot apply to v4.6-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dr
By tracking the iomapping on the VMA itself, we can share that area
between multiple users. Also by only revoking the iomapping upon
unbinding from the mappable portion of the GGTT, we can keep that iomap
across multiple invocations (e.g. execlists context pinning).
Note that by moving the iounnma
17 matches
Mail list logo
