Re: linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi all,

On Thu, 22 Mar 2018 17:37:22 +1100 Stephen Rothwell  
wrote:
>
> Today's linux-next merge of the drm tree got conflicts in several amdgpu
> files because there are a set of (mostly identical) patches that appear
> Linus' tree and the drm tree.  In each case I just used the version fo
> the file from the drm tree.
> 
> You should do a test merge between your tree and Linus' tree and see what
> you want to do about the resolution (either do the back merge (I think
> with v4.16-rc6), or provide Linus with branch that has the merge done).
> Its a bit of a mess :-(

I got a few more of these today.
-- 
Cheers,
Stephen Rothwell


pgp0UZxcTi53J.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: manual merge of the drm tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm tree got conflicts in:

  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

between commit:

  140bcaa23a1c ("drm/vmwgfx: Fix black screen and device errors when running 
without fbdev")

from Linus' tree and commit:

  c3b9b1657344 ("drm/vmwgfx: Improve on hibernation")

from the drm tree.

I fixed it up (see below) 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

diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 9116fe8baebc,9e60de95b863..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@@ -938,7 -947,8 +947,9 @@@ int vmw_kms_present(struct vmw_private 
  int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
  void vmw_kms_legacy_hotspot_clear(struct vmw_private *dev_priv);
 +void vmw_kms_lost_device(struct drm_device *dev);
+ int vmw_kms_suspend(struct drm_device *dev);
+ int vmw_kms_resume(struct drm_device *dev);
  
  int vmw_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3c824fd7cbf3,3628a9fe705f..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@@ -2561,11 -2551,10 +2557,12 @@@ int vmw_kms_helper_resource_prepare(str
if (res->backup) {
ret = vmw_kms_helper_buffer_prepare(res->dev_priv, res->backup,
interruptible,
-   res->dev_priv->has_mob);
+   res->dev_priv->has_mob,
+   false);
if (ret)
goto out_unreserve;
 +
 +  ctx->buf = vmw_dmabuf_reference(res->backup);
}
ret = vmw_resource_validate(res);
if (ret)
@@@ -2863,12 -2850,49 +2860,59 @@@ int vmw_kms_set_config(struct drm_mode_
  }
  
  
 +/**
 + * vmw_kms_lost_device - Notify kms that modesetting capabilities will be lost
 + *
 + * @dev: Pointer to the drm device
 + */
 +void vmw_kms_lost_device(struct drm_device *dev)
 +{
 +  drm_atomic_helper_shutdown(dev);
 +}
++
+ /**
+  * vmw_kms_suspend - Save modesetting state and turn modesetting off.
+  *
+  * @dev: Pointer to the drm device
+  * Return: 0 on success. Negative error code on failure.
+  */
+ int vmw_kms_suspend(struct drm_device *dev)
+ {
+   struct vmw_private *dev_priv = vmw_priv(dev);
+ 
+   dev_priv->suspend_state = drm_atomic_helper_suspend(dev);
+   if (IS_ERR(dev_priv->suspend_state)) {
+   int ret = PTR_ERR(dev_priv->suspend_state);
+ 
+   DRM_ERROR("Failed kms suspend: %d\n", ret);
+   dev_priv->suspend_state = NULL;
+ 
+   return ret;
+   }
+ 
+   return 0;
+ }
+ 
+ 
+ /**
+  * vmw_kms_resume - Re-enable modesetting and restore state
+  *
+  * @dev: Pointer to the drm device
+  * Return: 0 on success. Negative error code on failure.
+  *
+  * State is resumed from a previous vmw_kms_suspend(). It's illegal
+  * to call this function without a previous vmw_kms_suspend().
+  */
+ int vmw_kms_resume(struct drm_device *dev)
+ {
+   struct vmw_private *dev_priv = vmw_priv(dev);
+   int ret;
+ 
+   if (WARN_ON(!dev_priv->suspend_state))
+   return 0;
+ 
+   ret = drm_atomic_helper_resume(dev, dev_priv->suspend_state);
+   dev_priv->suspend_state = NULL;
+ 
+   return ret;
+ }


pgpYfWuSwRM3o.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amd/pp: silence a static checker warning

[Huang Rui]

On Fri, Mar 23, 2018 at 02:39:03PM +0300, Dan Carpenter wrote:
> This has a static checker warning because "frev" and "crev" can be
> uninitialized if "info" is NULL.  I just changed the order of the checks
> so that we check "info" first.
> 
> Signed-off-by: Dan Carpenter 

Reviewed-by: Huang Rui 

> 
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> index 75a465f771f0..7b26607c646a 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu8_hwmgr.c
> @@ -319,13 +319,13 @@ static int smu8_get_system_info_data(struct pp_hwmgr 
> *hwmgr)
>   GetIndexIntoMasterTable(DATA, IntegratedSystemInfo),
>   , , );
>  
> - if (crev != 9) {
> - pr_err("Unsupported IGP table: %d %d\n", frev, crev);
> + if (info == NULL) {
> + pr_err("Could not retrieve the Integrated System Info 
> Table!\n");
>   return -EINVAL;
>   }
>  
> - if (info == NULL) {
> - pr_err("Could not retrieve the Integrated System Info 
> Table!\n");
> + if (crev != 9) {
> + pr_err("Unsupported IGP table: %d %d\n", frev, crev);
>   return -EINVAL;
>   }
>  
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105018] Kernel panic when waking up after screen goes blank.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105018

--- Comment #27 from L.S.S.  ---
(In reply to Mez from comment #25)
> (In reply to L.S.S. from comment #23)
> > EDIT: It seems I'm experiencing some intermittent screen flicker with
> > current 4.16 kernel (on the same system, with only Patch 3 applied as it's
> > the only patch needed for 4.16), although it doesn't really affect normal
> > system usage.
> > 
> > I'm not sure if this flicker is related to this problem, but I'm putting it
> > up here as it's still a continuation of my watching this issue's condition.
> 
> Do you have TearFree on?
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=105530

I don't know about TearFree as I haven't actually configured it, so it should
be Manjaro's default setting. And I'm only getting the flicker on 4.16 kernel,
on 4.15 it is and has always been fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Julia Lawall]

On Sun, 25 Mar 2018, Arushi Singhal wrote:

>
>
> On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall  wrote:
>
>
>   On Mon, 19 Mar 2018, Arushi Singhal wrote:
>
>   > This patch replace list_entry with list_{next/prev}_entry as
>   it makes
>   > the code more clear to read.
>   > Done using coccinelle:
>   >
>   > @@
>   > expression e1;
>   > identifier e3;
>   > type t;
>   > @@
>   > (
>   > - list_entry(e1->e3.next,t,e3)
>   > + list_next_entry(e1,e3)
>   > |
>   > - list_entry(e1->e3.prev,t,e3)
>   > + list_prev_entry(e1,e3)
>   > )
>
>   This looks like a rule that could be nice for the Linux kernel
>   in general,
>   because the code really is much simpler.
>
>   I would suggest to write the rule in a more robust way, as
>   follows:
>
>   @@
>   identifier e3;
>   type t;
>   t *e1;
>   @@
>
>   (
>   - list_entry(e1->e3.next,t,e3)
>   + list_next_entry(e1,e3)
>   |
>   - list_entry(e1->e3.prev,t,e3)
>   + list_prev_entry(e1,e3)
>   )
>
>   @@
>   expression e1;
>   identifier e3;
>   @@
>
>   (
>   - list_entry(e1->e3.next,typeof(*e1),e3)
>   + list_next_entry(e1,e3)
>   |
>   - list_entry(e1->e3.prev,typeof(*e1),e3)
>   + list_prev_entry(e1,e3)
>
>   This checks that the type that is specified corresponds to the
>   one on e1.
>   It could actually be that the call is getting the first element
>   of a list,
>   from some different type, and coincidentally the two types have
>   the same
>   field name for the list element.
>
>   Unfortunately, the second rule, with the typeof call, doesn't
>   currently
>   work in Coccinelle, because the semantic patch language doesn't
>   actually
>   support typeof, and thinks that it is a function call.  I will
>   fix this.
>
>   To make a semantic patch for the kernel, you can try running
>   spgen on the
>   above file and answer the questions that it asks.  You can find
>   examples
>   in the coccinelle/scripts directory.  Just run
>
>   spgen foo.cocci
>
>   Then answer the questions.  Then run
>
>   spgen foo.cocci > foo_for_kernel.cocci
>
>   The second run will use the results of the first run to print
>   the semantic
>   patch.  Let me know if you have any questions.  You can always
>   adjust the
>   semantic patch that is generated by hand afterwards if needed.
>
>
> Hi Julia,
>
> I tried spgen and found that second rule is still not working. It's not able
> to detect the second rule.
> Is it working for you?

If you get the latest version of Coccinelle from github, it shoudl be
working now.

julia

>
> Thanks,
> Arushi
>
>
>   julia
>
>
>   >
>   > Signed-off-by: Arushi Singhal
>   
>   > ---
>   >  drivers/gpu/drm/drm_lease.c                    | 2 +-
>   >  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
>   >  2 files changed, 2 insertions(+), 2 deletions(-)
>   >
>   > diff --git a/drivers/gpu/drm/drm_lease.c
>   b/drivers/gpu/drm/drm_lease.c
>   > index 1402c0e..4dcfb5f 100644
>   > --- a/drivers/gpu/drm/drm_lease.c
>   > +++ b/drivers/gpu/drm/drm_lease.c
>   > @@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct
>   drm_master *top)
>   >                               break;
>   >
>   >                       /* Over */
>   > -                     master =
>   list_entry(master->lessee_list.next, struct drm_master,
>   lessee_list);
>   > +                     master = list_next_entry(master,
>   lessee_list);
>   >               }
>   >       }
>   >  }
>   > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > index e4c8d31..81c3567 100644
>   > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > @@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk
>   *clk, struct nvkm_pstate *pstate,
>   >                              nvkm_volt_map(volt,
>   volt->max2_id, clk->temp));
>   >
>   >       for (cstate = start; >head != >list;
>   > -          cstate = list_entry(cstate->head.prev,
>   typeof(*cstate), head)) {
>   > +          cstate = list_prev_entry(cstate, head)) {
>   >               if (nvkm_cstate_valid(clk, cstate, max_volt,
>   clk->temp))
>   >                       break;
>   >       }
>   > --
>   > 2.7.4
>   >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > 

Re: [PATCH] dma-buf: use parameter structure for dma_buf_attach

[kbuild test robot]

Hi Christian,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16-rc6 next-20180323]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Christian-K-nig/dma-buf-use-parameter-structure-for-dma_buf_attach/20180326-044631
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: xtensa-allmodconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   drivers/staging/media/tegra-vde/tegra-vde.c: In function 
'tegra_vde_attach_dmabuf':
>> drivers/staging/media/tegra-vde/tegra-vde.c:534:13: error: 'dmabuf' 
>> undeclared (first use in this function); did you mean 'dma_buf'?
  .dmabuf = dmabuf
^~
dma_buf
   drivers/staging/media/tegra-vde/tegra-vde.c:534:13: note: each undeclared 
identifier is reported only once for each function it appears in

vim +534 drivers/staging/media/tegra-vde/tegra-vde.c

   521  
   522  static int tegra_vde_attach_dmabuf(struct device *dev,
   523 int fd,
   524 unsigned long offset,
   525 unsigned int min_size,
   526 struct dma_buf_attachment **a,
   527 dma_addr_t *addr,
   528 struct sg_table **s,
   529 size_t *size,
   530 enum dma_data_direction dma_dir)
   531  {
   532  struct dma_buf_attach_info attach_info = {
   533  .dev = dev,
 > 534  .dmabuf = dmabuf
   535  };
   536  struct dma_buf_attachment *attachment;
   537  struct dma_buf *dmabuf;
   538  struct sg_table *sgt;
   539  int err;
   540  
   541  dmabuf = dma_buf_get(fd);
   542  if (IS_ERR(dmabuf)) {
   543  dev_err(dev, "Invalid dmabuf FD\n");
   544  return PTR_ERR(dmabuf);
   545  }
   546  
   547  if ((u64)offset + min_size > dmabuf->size) {
   548  dev_err(dev, "Too small dmabuf size %zu @0x%lX, "
   549   "should be at least %d\n",
   550  dmabuf->size, offset, min_size);
   551  return -EINVAL;
   552  }
   553  
   554  attachment = dma_buf_attach(_info);
   555  if (IS_ERR(attachment)) {
   556  dev_err(dev, "Failed to attach dmabuf\n");
   557  err = PTR_ERR(attachment);
   558  goto err_put;
   559  }
   560  
   561  sgt = dma_buf_map_attachment(attachment, dma_dir);
   562  if (IS_ERR(sgt)) {
   563  dev_err(dev, "Failed to get dmabufs sg_table\n");
   564  err = PTR_ERR(sgt);
   565  goto err_detach;
   566  }
   567  
   568  if (sgt->nents != 1) {
   569  dev_err(dev, "Sparse DMA region is unsupported\n");
   570  err = -EINVAL;
   571  goto err_unmap;
   572  }
   573  
   574  *addr = sg_dma_address(sgt->sgl) + offset;
   575  *a = attachment;
   576  *s = sgt;
   577  
   578  if (size)
   579  *size = dmabuf->size - offset;
   580  
   581  return 0;
   582  
   583  err_unmap:
   584  dma_buf_unmap_attachment(attachment, sgt, dma_dir);
   585  err_detach:
   586  dma_buf_detach(dmabuf, attachment);
   587  err_put:
   588  dma_buf_put(dmabuf);
   589  
   590  return err;
   591  }
   592  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105425

--- Comment #7 from MirceaKitsune  ---
I've been testing this crash using Xonotic during the past two days, granted
it's a game I have a lot of experience customizing. What I found is pretty
interesting and should be a good start in shedding light on this bug.

Initially the system freeze occurred somewhere between 10 and 40 minutes. Upon
changing a few cvars, I seem to have almost entirely gotten rid of it: After
nearly 5 hours of continuous testing, only one lockup has taken place! Below
are the cvar overrides I added to my autoexec.cfg for the test: At least one of
them had an influence... I'm still working on pinning down which, and that will
take several more days due to the probability rate of the issue.

r_batch_multidraw 0 // old: 1
r_batch_dynamicbuffer 0 // old: 1
r_depthfirst 0 // old: 2
gl_vbo 0 // old: 3
gl_vbo_dynamicindex 0 // old: 1
gl_vbo_dynamicvertex 0 // old: 1
r_glsl_skeletal 0 // old: 1
vid_samples 1 // old: 4
gl_texture_anisotropy 0 // old: 16

I know the issue has something to do with triangles or vertices: The crash
seems more frequent when there are a lot of players or objects present,
indicating that an increased surface count may be a contributor. I've suspected
mesh data stored on the video card to be the culprit, especially shared data
with multiple objects using one instance of a mesh from video memory. This is
why my bet is currently on gl_vbo (Vertex Buffer Objects /
GL_ARB_vertex_buffer_object) being the variable that made a difference... again
I still got a lockup even without it, so if anything it just heavily mitigated
the crash.

This belief is reinforced by my previous experience in Blender: The only scene
causing the GPU lockup is one where several high-poly objects share common mesh
data, and the crash always occurred upon me adding a Subdivision Surface to
just one of them (increasing its polygon count). It's been confirmed that as of
Blender 2.77 (I have 2.79) VBO is indeed enabled in the 3D viewport. Note that
I was also using the untextured viewport, thus I doubt textures play a role.

Lastly I ruled out the possibility of overheating having anything to do with
it: During the first 3 hours in which I got no lockup, the temperature in my
room was above 26°C. When I did get that one lockup later at night, the
temperature of my room had long dropped to 23°C. The stress on the GPU was the
same at all times, absolutely no settings were changed including the map.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC

[Stefan Schake]

Hey Daniel,

On Sun, Mar 25, 2018 at 10:01 AM, Daniel Stone  wrote:
> Hi Stefan,
>
> On 25 March 2018 at 02:52, Stefan Schake  wrote:
>> +static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4)
>> +{
>> +   return VC4_GET_FIELD(HVS_READ(SCALER_OLEDOFFS),
>> +SCALER_OLEDOFFS_DISPFIFO);
>> +}
>
> This needs to be managed as a global resource through atomic state
> objects, rather than checking the current hardware state.

Do you mean as a property or some such that is accessible to userland
or merely that this could be raced?

I haven't had much luck finding examples for resources shared between CRTCs
in the current tree. My understanding here was that if userland commits
on CRTC B after a check-only on A, we are no longer bound by the earlier
result for the check-only. Otherwise, I would have to already commit my
CTM block to one CRTC at check (possibly check only) time.

Thanks,
Stefan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

It's better to use list_entry instead of list_{next/prev}_entry
as it makes the code more clear to read.
This patch replace list_entry with list_{next/prev}_entry.

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index e4c8d31..81c3567 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
   nvkm_volt_map(volt, volt->max2_id, clk->temp));
 
for (cstate = start; >head != >list;
-cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
+cstate = list_prev_entry(cstate, head)) {
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
break;
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

It's better to use list_entry instead of list_{next/prev}_entry
as it makes the code more clear to read.
This patch replace list_entry with list_{next/prev}_entry.

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/drm_lease.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1402c0e..4dcfb5f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
break;
 
/* Over */
-   master = list_entry(master->lessee_list.next, struct 
drm_master, lessee_list);
+   master = list_next_entry(master, lessee_list);
}
}
 }
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 0/2] drm: Replace list_entry

[Arushi Singhal]

Replace list_entry with list_{next/prev}_entry.

Arushi Singhal (2):
  gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry
  gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry

 drivers/gpu/drm/drm_lease.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
changes in v2
*All the maintainers are added.
*More accurate coccinelle script is used
for this patch than the one used in previous version.
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104193] [radeonsi] The Witcher 3 freezes the system (POLARIS10)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=104193

--- Comment #9 from Lukas Jirkovsky  ---
For the record - the freeze also happens when using R600_DEBUG=nir on current
mesa from git (5a75019ad0). I also have RX 480.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105733

--- Comment #2 from Allan  ---
Tried getting all binaries available here
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
.

Even that I included the polaris binaries in the kernel, some binaries were
missing (exactly those that were required...).

I've seen that before, but since sometimes it got working I just thought that
some other bin was being used instead.

Well... I launched Unigine Valley as a test and now the problem is even worse :

[From dmesg]
```
[  517.630633] amdgpu :0e:00.0: GPU fault detected: 147 0x4802
[  517.630636] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  517.630638] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x08048002
[  517.630640] amdgpu :0e:00.0: VM fault (0x02, vmid 4) at page 0, read
from 'TC4' (0x54433400) (72)
[  517.630644] amdgpu :0e:00.0: GPU fault detected: 147 0x4802
[  517.630645] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR  
0x
[  517.630646] amdgpu :0e:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS
0x08084002
[  517.630648] amdgpu :0e:00.0: VM fault (0x02, vmid 4) at page 0, read
from 'TC7' (0x54433700) (132)
```

The symptoms and reactions are the same as above. I got the output from a ssh
because only the cursor was moving and nothing else working.

So ... did my card die or is it a bug?

By the way ... I also have an RX580 and the problem described firstly was
happening too. (I had not tried forcing binaries before)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: udl: Properly check framebuffer mmap offsets

[Kees Cook]

On Thu, Mar 22, 2018 at 2:54 AM, Daniel Vetter  wrote:
> On Thu, Mar 22, 2018 at 9:03 AM, Greg Kroah-Hartman
>  wrote:
>> On Thu, Mar 22, 2018 at 07:59:59AM +0100, Daniel Vetter wrote:
>>> Does anyone working on overflow-proof integers? That would make a lot of
>>> this code so much simpler if we could just ask the compiler to carry the
>>> oferflow bit around for a given expression and then check that and bail
>>> with -EINVAL.
>>
>> That would be nice, but no, I don't think that's part of any C standard
>> work that I have heard of :(
>
> Well we have refcount_t already, stitching something together that
> would work and not suck too badly with performance should be possible.
> But yeah direct compiler support would be better (and would allow
> optimizing the carry flag checks I guess). I kinda hoped Kees
> would be working on this eventually.

refcount_t could be used if it happens to match the needed semantics.

> Adding Kees+kernel-hardening, maybe he'll grow fond of this :-)

Yeah, general integer overflow is on the list of things to get fixed
in the kernel. It's a bit of a long road, though.

Clang has -fsanitize=integer (and sub-options) which could be added
for specific object or trees:
https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#ubsan-checks

GCC seems to only support manual marking of overflow detections:
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html

grsecurity/PaX has a gcc plugin for overflow detection, though it
hasn't been upstreamed and comes with various caveats:
http://forums.grsecurity.net/viewtopic.php?f=7=3043
https://github.com/ephox-gcc-plugins/size_overflow

-Kees

-- 
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/7] drm/sun4i: Allwinner MIPI-DSI support

[Jagan Teki]

Hi Maxime,

On Tue, Mar 6, 2018 at 7:25 PM, Maxime Ripard  wrote:
> Hi,
>
> Here is an preliminary version of the MIPI-DSI support for the Allwinner
> SoCs.
>
> This controller can be found on a number of recent SoCs, such as the
> A31, A33 or the A64.
>
> Given the sparse documentation, there's a number of obscure areas, but
> the current implementation has been tested with a 4-lanes DSI panel on
> an A33.
>
> The support is a bit rough around the edges at the time, and some artifacts
> are still shown on the screen for some reasons. Wider testing with
> different display will hopefully nail those down.
>
> Let me know what you think,
> Maxime
>
> Changes from v2:
>   - Added a ports node under the DSI node
>   - Changed the huarui panel driver to an ili9881c driver
>   - Changed the panel vendor to bananapi
>   - Made the init table static in the panel driver
>   - Dropped the huarui vendor patch for the DT doc.
>
> Changes from v1:
>   - Rebased on 4.16-rc1
>   - Constified a few function arguments and structures
>   - Reworked the DT binding example a bit
>   - Reworked the panel driver to check for DSI return codes, and use DCS
> helpers when possible
>
> Maxime Ripard (7):
>   drm/sun4i: tcon: Add TRI finish interrupt for vblank
>   dt-bindings: display: Add Allwinner MIPI-DSI bindings
>   drm/sun4i: Add Allwinner A31 MIPI-DSI controller support
>   dt-bindings: panel: Add the Ilitek ILI9881c panel documentation
>   drm/panel: Add Ilitek ILI9881c panel driver
>   arm: dts: sun8i: a33: Add the DSI-related nodes
>   [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display

Any dependencies for this series on linux-next? it is not applying directly.

Jagan.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC

[Martin Blumenstingl]

Hello Hans, Hi Neil,

(apologies in advance if any of this is wrong, I don't have any CEC
capable TV so I can't test it)

On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil  wrote:
> From: Hans Verkuil 
>
> Some boards (amlogic) have two CEC controllers: the DesignWare controller
> and their own CEC controller (meson ao-cec).
as far as I understand the Amlogic Meson SoCs have two domains:
- AO (always-on, powered even in suspend mode) where meson-ao-cec can
wake up the system from suspend
- EE (everything else, not powered during suspend) where dw-hdmi-cec lives

this far everything is OK

> Since the CEC line is not hooked up to the DW controller we need a way
> to disable that controller. This patch series adds the cec-disable
> property for that purpose.
drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and
ee_cec_pins, both use GPIOAO_12
drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and
ee_cec_pins, both use GPIOAO_8

@Neil: do you know if the CEC signal routing is:
ao_cec_pins -> meson-ao-cec
ee_cec_pins -> dw-hdmi-cec

I'm curious because if both CEC controllers can be used then it might
be worth mentioning this in the cover-letter and patch description


Regards
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6] ARM: dts: wheat: Fix ADV7513 address usage

[Simon Horman]

On Thu, Mar 22, 2018 at 09:30:40PM +, Kieran Bingham wrote:
> The r8a7792 Wheat board has two ADV7513 devices sharing a single I2C
> bus, however in low power mode the ADV7513 will reset it's slave maps to
> use the hardware defined default addresses.
> 
> The ADV7511 driver was adapted to allow the two devices to be registered
> correctly - but it did not take into account the fault whereby the
> devices reset the addresses.
> 
> This results in an address conflict between the device using the default
> addresses, and the other device if it is in low-power-mode.
> 
> Repair this issue by moving both devices away from the default address
> definitions.

Hi Kierean,

as this is a fix
a) Does it warrant a fixes tag?
   Fixes: f6eea82a87db ("ARM: dts: wheat: add DU support")
b) Does it warrant being posted as a fix for v4.16;
c) or v4.17?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCHv2 0/3] dw-hdmi: add property to disable CEC

[Martin Blumenstingl]

Hi Neil,

On Sat, Mar 24, 2018 at 2:41 PM, Neil Armstrong  wrote:
> Hi Martin,
>
>> Le 24 mars 2018 à 12:00, Martin Blumenstingl 
>>  a écrit :
>>
>> Hello Hans, Hi Neil,
>>
>> (apologies in advance if any of this is wrong, I don't have any CEC
>> capable TV so I can't test it)
>>
>> On Fri, Mar 23, 2018 at 1:59 PM, Hans Verkuil  wrote:
>>> From: Hans Verkuil 
>>>
>>> Some boards (amlogic) have two CEC controllers: the DesignWare controller
>>> and their own CEC controller (meson ao-cec).
>> as far as I understand the Amlogic Meson SoCs have two domains:
>> - AO (always-on, powered even in suspend mode) where meson-ao-cec can
>> wake up the system from suspend
>> - EE (everything else, not powered during suspend) where dw-hdmi-cec lives
>>
>
> Exact, except … the EE CEC is not hooked to the DW-HDMI TX but the RX, and 
> thus cannot be used on GXBB/GXL/GXM.
I see, thank you for the explanation

>> this far everything is OK
>>
>>> Since the CEC line is not hooked up to the DW controller we need a way
>>> to disable that controller. This patch series adds the cec-disable
>>> property for that purpose.
>> drivers/pinctrl/meson/pinctrl-meson-gxbb.c has ao_cec_pins and
>> ee_cec_pins, both use GPIOAO_12
>> drivers/pinctrl/meson/pinctrl-meson-gxl.c has ao_cec_pins and
>> ee_cec_pins, both use GPIOAO_8
>>
>> @Neil: do you know if the CEC signal routing is:
>> ao_cec_pins -> meson-ao-cec
>> ee_cec_pins -> dw-hdmi-cec
>
> It’s hooked to the DW-HDMI RX IP used in the TV SoCs.
>
>>
>> I'm curious because if both CEC controllers can be used then it might
>> be worth mentioning this in the cover-letter and patch description
>>
>
> Initially I thought it was hooked to the DW-HDMI TX, but no, I guess I should 
> remove the ee_cec pinmux…
right, or rename it to ee_cec_rx (or something similar)


Regards
Martin
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

[Frank Rowand]

Hi Geert,

On 03/22/18 07:26, Geert Uytterhoeven wrote:
> Hi Frank,
> 
> On Fri, Mar 16, 2018 at 2:39 AM,   wrote:
>> On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann [mailto:a...@arndb.de]  
>> wrote:
>>>
>>> The *.dtb and *.dtb.S files get removed by 'make' during the build
>>> process,
>>> and later seem to be missed during the 'modpost' stage:
>>>
>>> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
>>> WARNING: could not open
>>> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or
>>> directory
>>>
>>> As a workaround, this adds all those files to the 'extra-y' target list,
>>> but that's really ugly. Any ideas for a better fix?
>>
>> Does this work for you (untested, but the way it is done in
>> drivers/of/unittest-data/Makefile):
>>
>> .PRECIOUS: \
>> $(obj)/%.dtb.S \
>> $(obj)/%.dtb
> 
> Shouldn't that just be moved to scripts/Makefile.lib, just above the rule
> to make dtb.S, like is done for other precious objects?
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 

Thank you for adding Yamada-san (later in this thread).

I acked his patch series that does what you suggest.

-Frank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build

[Masahiro Yamada]

2018-03-23 0:13 GMT+09:00 Geert Uytterhoeven :
> Hi Laurent,
>
> CC Yamada-san
>
> On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart
>  wrote:
>> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
>>> On Fri, Mar 16, 2018 at 2:39 AM,   wrote:
>>> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote:
>>> >> The *.dtb and *.dtb.S files get removed by 'make' during the build
>>> >> process, and later seem to be missed during the 'modpost' stage:
>>> >>
>>> >> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S
>>> >> WARNING: could not open
>>> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or
>>> >> directory
>>> >>
>>> >> As a workaround, this adds all those files to the 'extra-y' target list,
>>> >> but that's really ugly. Any ideas for a better fix?
>>> >
>>> > Does this work for you (untested, but the way it is done in
>>> > drivers/of/unittest-data/Makefile):
>>> >
>>> > .PRECIOUS: \
>>> >
>>> > $(obj)/%.dtb.S \
>>> > $(obj)/%.dtb
>>>
>>> Shouldn't that just be moved to scripts/Makefile.lib, just above the rule
>>> to make dtb.S, like is done for other precious objects?
>>
>> Without any implied acknowledgment that keeping those intermediate files is
>> the right solution (I don't claim to master the kernel build system), I think
>
> Me neither, but I think it is.
>
> Cfr. .y => .tab.c => .tab.o with .tab.c marked PRECIOUS.
>
>> such a rule would indeed be better in a core Makefile, as the rules to build
>> the .dtb.o file comes from the core too. Could another option be to create a
>> rule to compile a .dtb.o from the .dts file directly without going through
>> intermediate files that will be removed automatically ?
>
> Such a rules needs to execute two commands, which is more tricky, considering
> error handling.
> It's easier (to get right) to have two separate rules, and let make chain them
> automatically.
>
> Gr{oetje,eeting}s,
>
> Geert
>


I submit the patches.
I'd like to queue them up for the next merge window,
so your problems will be fixed if Kbuild pull requests are pulled.

The driver Makefile has two problems.

[1] Objects are always rebuilt due to missing 'targets'
[2] Intermediate files are removed due to missing .SECONDARY (or .PRECIOUS)

If you want to fix them by yourself, you can.

But, those issues will be taken care of by the core Makefile.

Specifically, [1] will be fixed by
https://patchwork.kernel.org/patch/10304671/

and [2] by
https://patchwork.kernel.org/patch/10304651/




-- 
Best Regards
Masahiro Yamada
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format

[Peter Rosin]

Hi Laurent,

Thanks for the feedback!

On 2018-03-20 14:56, Laurent Pinchart wrote:
> Hi Peter,
> 
> Thank you for the patch.
> 
> On Sunday, 18 March 2018 00:15:24 EET Peter Rosin wrote:
>> Useful if the bridge does some kind of conversion of the bus format.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  drivers/gpu/drm/bridge/panel.c | 22 +-
>>  include/drm/drm_bridge.h   |  1 +
>>  2 files changed, 22 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
>> index 6d99d4a3beb3..ccef0283ff41 100644
>> --- a/drivers/gpu/drm/bridge/panel.c
>> +++ b/drivers/gpu/drm/bridge/panel.c
>> @@ -22,6 +22,7 @@ struct panel_bridge {
>>  struct drm_connector connector;
>>  struct drm_panel *panel;
>>  u32 connector_type;
>> +u32 bus_format;
>>  };
>>
>>  static inline struct panel_bridge *
>> @@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct
>> drm_connector *connector) {
>>  struct panel_bridge *panel_bridge =
>>  drm_connector_to_panel_bridge(connector);
>> +int ret;
>> +
>> +ret = drm_panel_get_modes(panel_bridge->panel);
>> +
>> +if (panel_bridge->bus_format)
>> +drm_display_info_set_bus_formats(>display_info,
>> + _bridge->bus_format, 1);
> 
> While I agree with the problem statement and, to some extent, the DT 
> bindings, 
> I don't think this is the right implementation. You've correctly noted that 
> display controller shouldn't blindly use the formats reported by the panel 
> through the connector formats, and that hacking the panel driver to override 
> the formats isn't a good idea, so I wouldn't override the formats reported by 
> the connector. I would instead extend the drm_bridge API to report formats at 
> bridge inputs. This would be more generic and allow each bridge to configure 
> itself according to the next bridge in the chain.
> 
> I'm not sure whether this API extension should be in the form of a new bridge 
> function, or if the formats should be stored in the drm_bridge structure 
> directly as done for connectors in the display info structure. I'm tempted by 
> the former, but I'm open to discussions.

Ok, I can look into that, but let me check if I got this right. From the very
little of the code that I have looked at, I have gathered that display
controllers handle bridges explicitly, right? If so, by extending the bridge
(with either a new function or new data) you impose changes to all display
controllers wanting to handle this new bridge input-format. If so, I assume
I can leave out the changes to all display controllers that I do not care
about. Correct?

Also, don't hold your breath waiting for a v2, but I'll try to get to it :-)

>> -return drm_panel_get_modes(panel_bridge->panel);
>> +return ret;
>>  }
>>
>>  static const struct drm_connector_helper_funcs
>> @@ -203,6 +211,18 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
>> }
>>  EXPORT_SYMBOL(drm_panel_bridge_remove);
>>
>> +void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32
>> bus_format) +{
>> +struct panel_bridge *panel_bridge;
>> +
>> +if (!bridge)
>> +return;
>> +
>> +panel_bridge = drm_bridge_to_panel_bridge(bridge);
>> +panel_bridge->bus_format = bus_format;
>> +}
>> +EXPORT_SYMBOL(drm_panel_bridge_set_bus_format);
>> +
>>  static void devm_drm_panel_bridge_release(struct device *dev, void *res)
>>  {
>>  struct drm_bridge **bridge = res;
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index 682d01ba920c..81903b92f187 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -268,6 +268,7 @@ void drm_bridge_enable(struct drm_bridge *bridge);
>>  struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
>>  u32 connector_type);
>>  void drm_panel_bridge_remove(struct drm_bridge *bridge);
>> +void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32
>> bus_format);
>> struct drm_bridge *devm_drm_panel_bridge_add(struct device
>> *dev,
>>   struct drm_panel *panel,
>>   u32 connector_type);
> 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Julia Lawall]

On Sun, 25 Mar 2018, Arushi Singhal wrote:

>
>
> On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall  wrote:
>
>
>   On Mon, 19 Mar 2018, Arushi Singhal wrote:
>
>   > This patch replace list_entry with list_{next/prev}_entry as
>   it makes
>   > the code more clear to read.
>   > Done using coccinelle:
>   >
>   > @@
>   > expression e1;
>   > identifier e3;
>   > type t;
>   > @@
>   > (
>   > - list_entry(e1->e3.next,t,e3)
>   > + list_next_entry(e1,e3)
>   > |
>   > - list_entry(e1->e3.prev,t,e3)
>   > + list_prev_entry(e1,e3)
>   > )
>
>   This looks like a rule that could be nice for the Linux kernel
>   in general,
>   because the code really is much simpler.
>
>   I would suggest to write the rule in a more robust way, as
>   follows:
>
>   @@
>   identifier e3;
>   type t;
>   t *e1;
>   @@
>
>   (
>   - list_entry(e1->e3.next,t,e3)
>   + list_next_entry(e1,e3)
>   |
>   - list_entry(e1->e3.prev,t,e3)
>   + list_prev_entry(e1,e3)
>   )
>
>   @@
>   expression e1;
>   identifier e3;
>   @@
>
>   (
>   - list_entry(e1->e3.next,typeof(*e1),e3)
>   + list_next_entry(e1,e3)
>   |
>   - list_entry(e1->e3.prev,typeof(*e1),e3)
>   + list_prev_entry(e1,e3)
>
>   This checks that the type that is specified corresponds to the
>   one on e1.
>   It could actually be that the call is getting the first element
>   of a list,
>   from some different type, and coincidentally the two types have
>   the same
>   field name for the list element.
>
>   Unfortunately, the second rule, with the typeof call, doesn't
>   currently
>   work in Coccinelle, because the semantic patch language doesn't
>   actually
>   support typeof, and thinks that it is a function call.  I will
>   fix this.
>
>   To make a semantic patch for the kernel, you can try running
>   spgen on the
>   above file and answer the questions that it asks.  You can find
>   examples
>   in the coccinelle/scripts directory.  Just run
>
>   spgen foo.cocci
>
>   Then answer the questions.  Then run
>
>   spgen foo.cocci > foo_for_kernel.cocci
>
>   The second run will use the results of the first run to print
>   the semantic
>   patch.  Let me know if you have any questions.  You can always
>   adjust the
>   semantic patch that is generated by hand afterwards if needed.
>
>
> Hi Julia,
>
> I tried spgen and found that second rule is still not working. It's not able
> to detect the second rule.
> Is it working for you?

No, I didn't have a chance to fix it yet.

julia


>
> Thanks,
> Arushi
>
>
>   julia
>
>
>   >
>   > Signed-off-by: Arushi Singhal
>   
>   > ---
>   >  drivers/gpu/drm/drm_lease.c                    | 2 +-
>   >  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
>   >  2 files changed, 2 insertions(+), 2 deletions(-)
>   >
>   > diff --git a/drivers/gpu/drm/drm_lease.c
>   b/drivers/gpu/drm/drm_lease.c
>   > index 1402c0e..4dcfb5f 100644
>   > --- a/drivers/gpu/drm/drm_lease.c
>   > +++ b/drivers/gpu/drm/drm_lease.c
>   > @@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct
>   drm_master *top)
>   >                               break;
>   >
>   >                       /* Over */
>   > -                     master =
>   list_entry(master->lessee_list.next, struct drm_master,
>   lessee_list);
>   > +                     master = list_next_entry(master,
>   lessee_list);
>   >               }
>   >       }
>   >  }
>   > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > index e4c8d31..81c3567 100644
>   > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
>   > @@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk
>   *clk, struct nvkm_pstate *pstate,
>   >                              nvkm_volt_map(volt,
>   volt->max2_id, clk->temp));
>   >
>   >       for (cstate = start; >head != >list;
>   > -          cstate = list_entry(cstate->head.prev,
>   typeof(*cstate), head)) {
>   > +          cstate = list_prev_entry(cstate, head)) {
>   >               if (nvkm_cstate_valid(clk, cstate, max_volt,
>   clk->temp))
>   >                       break;
>   >       }
>   > --
>   > 2.7.4
>   >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to
> 

Re: [PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.

[Paul Kocialkowski]

Hi,

Le mercredi 21 mars 2018 à 21:03 +0100, Giulio Benetti a écrit :
> The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
> for the needed pins.
> 
> Signed-off-by: Giulio Benetti 
> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index efb5607..bfe6728 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -922,6 +922,14 @@
>   pins = "PI20", "PI21";
>   function = "uart7";
>   };
> +
> + lcd0_rgb888_pins: lcd0-rgb888-pins {

It would be more consistent with other pins definitions to have
underscores in both names and to indicate the index, such as:
lcd0_rgb888_pins: lcd0_rgb888_pins@0 {

This way, other set of pins for LCD (PH0-PH27) can be declared as @1
when they are needed in the future.

> + pins = "PD0", "PD1", "PD2", "PD3",
> "PD4", "PD5", "PD6", "PD7",
> +"PD8", "PD9", "PD10", "PD11",
> "PD12", "PD13", "PD14", "PD15",
> +"PD16", "PD17", "PD18",
> "PD19", "PD20", "PD21", "PD22", "PD23",
> +"PD24", "PD25", "PD26",
> "PD27";
> + function = "lcd0";
> + };
>   };
>  
>   timer@1c20c00 {

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall  wrote:

>
>
> On Mon, 19 Mar 2018, Arushi Singhal wrote:
>
> > This patch replace list_entry with list_{next/prev}_entry as it makes
> > the code more clear to read.
> > Done using coccinelle:
> >
> > @@
> > expression e1;
> > identifier e3;
> > type t;
> > @@
> > (
> > - list_entry(e1->e3.next,t,e3)
> > + list_next_entry(e1,e3)
> > |
> > - list_entry(e1->e3.prev,t,e3)
> > + list_prev_entry(e1,e3)
> > )
>
> This looks like a rule that could be nice for the Linux kernel in general,
> because the code really is much simpler.
>
> I would suggest to write the rule in a more robust way, as follows:
>
> @@
> identifier e3;
> type t;
> t *e1;
> @@
>
> (
> - list_entry(e1->e3.next,t,e3)
> + list_next_entry(e1,e3)
> |
> - list_entry(e1->e3.prev,t,e3)
> + list_prev_entry(e1,e3)
> )
>
> @@
> expression e1;
> identifier e3;
> @@
>
> (
> - list_entry(e1->e3.next,typeof(*e1),e3)
> + list_next_entry(e1,e3)
> |
> - list_entry(e1->e3.prev,typeof(*e1),e3)
> + list_prev_entry(e1,e3)
>
> This checks that the type that is specified corresponds to the one on e1.
> It could actually be that the call is getting the first element of a list,
> from some different type, and coincidentally the two types have the same
> field name for the list element.
>
> Unfortunately, the second rule, with the typeof call, doesn't currently
> work in Coccinelle, because the semantic patch language doesn't actually
> support typeof, and thinks that it is a function call.  I will fix this.
>
> To make a semantic patch for the kernel, you can try running spgen on the
> above file and answer the questions that it asks.  You can find examples
> in the coccinelle/scripts directory.  Just run
>
> spgen foo.cocci
>
> Then answer the questions.  Then run
>
> spgen foo.cocci > foo_for_kernel.cocci
>
> The second run will use the results of the first run to print the semantic
> patch.  Let me know if you have any questions.  You can always adjust the
> semantic patch that is generated by hand afterwards if needed.
>

Hi Julia,

I tried spgen and found that second rule is still not working. It's not
able to detect the second rule.
Is it working for you?

Thanks,
Arushi


> julia
>
>
> >
> > Signed-off-by: Arushi Singhal 
> > ---
> >  drivers/gpu/drm/drm_lease.c| 2 +-
> >  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> > index 1402c0e..4dcfb5f 100644
> > --- a/drivers/gpu/drm/drm_lease.c
> > +++ b/drivers/gpu/drm/drm_lease.c
> > @@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
> >   break;
> >
> >   /* Over */
> > - master = list_entry(master->lessee_list.next,
> struct drm_master, lessee_list);
> > + master = list_next_entry(master, lessee_list);
> >   }
> >   }
> >  }
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > index e4c8d31..81c3567 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > @@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate,
> >  nvkm_volt_map(volt, volt->max2_id,
> clk->temp));
> >
> >   for (cstate = start; >head != >list;
> > -  cstate = list_entry(cstate->head.prev, typeof(*cstate),
> head)) {
> > +  cstate = list_prev_entry(cstate, head)) {
> >   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> >   break;
> >   }
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/
> msgid/outreachy-kernel/20180319050530.GA25589%40seema-Inspiron-15-3567.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 59681] Sony VAIO VPCZ23A4R: radeon doesn't like undocking

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=59681

Alexander E. Patrakov (patra...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INSUFFICIENT_DATA

--- Comment #4 from Alexander E. Patrakov (patra...@gmail.com) ---
The laptop is dead, closing bugs reproducible only on it

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] amdkfd fixes for 4.16 final

[Oded Gabbay]

Hi Dave,

Two small fixes for the final 4.16 release:

- Programming VMID correctly for scratch memory with HWS
- deallocating SDMA queues correctly in various situations

Thanks,

Oded

The following changes since commit 5a9f698feb11b198f17b2acebbfe0e2716a3beed:

  drm/ast: Fixed 1280x800 Display Issue (2018-03-23 09:50:54 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2018-03-25

for you to fetch changes up to 72a01d231dcb22a276209c7a924a8cd475fbaa9b:

  drm/amdkfd: Deallocate SDMA queues correctly (2018-03-23 15:30:34 -0400)


Felix Kuehling (2):
  drm/amdkfd: Fix scratch memory with HWS enabled
  drm/amdkfd: Deallocate SDMA queues correctly

 .../gpu/drm/amd/amdkfd/kfd_device_queue_manager.c| 20 ++--
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c  |  3 +--
 2 files changed, 15 insertions(+), 8 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] dma-buf: use parameter structure for dma_buf_attach

[Christian König]

Move the parameters into a structure to make it simpler to extend it in
follow up patches.

This also adds the importer private as parameter so that we can directly
work with a completely filled in attachment structure.

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c | 16 +---
 drivers/gpu/drm/armada/armada_gem.c   |  6 +-
 drivers/gpu/drm/drm_prime.c   |  6 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|  6 +-
 drivers/gpu/drm/tegra/gem.c   |  6 +-
 drivers/gpu/drm/udl/udl_dmabuf.c  |  6 +-
 drivers/media/common/videobuf2/videobuf2-dma-contig.c |  6 +-
 drivers/media/common/videobuf2/videobuf2-dma-sg.c |  6 +-
 drivers/staging/media/tegra-vde/tegra-vde.c   |  6 +-
 include/linux/dma-buf.h   | 19 +--
 10 files changed, 66 insertions(+), 17 deletions(-)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d78d5fc173dc..d2e8ca0d9427 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -534,8 +534,9 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
 /**
  * dma_buf_attach - Add the device to dma_buf's attachments list; optionally,
  * calls attach() of dma_buf_ops to allow device-specific attach functionality
- * @dmabuf:[in]buffer to attach device to.
- * @dev:   [in]device to be attached.
+ * @info:  [in]holds all the attach related information provided
+ * by the importer. see  dma_buf_attach_info
+ * for further details.
  *
  * Returns struct dma_buf_attachment pointer for this attachment. Attachments
  * must be cleaned up by calling dma_buf_detach().
@@ -549,26 +550,27 @@ EXPORT_SYMBOL_GPL(dma_buf_put);
  * accessible to @dev, and cannot be moved to a more suitable place. This is
  * indicated with the error code -EBUSY.
  */
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *dma_buf_attach(const struct dma_buf_attach_info 
*info)
 {
+   struct dma_buf *dmabuf = info->dmabuf;
struct dma_buf_attachment *attach;
int ret;
 
-   if (WARN_ON(!dmabuf || !dev))
+   if (WARN_ON(!dmabuf || !info->dev))
return ERR_PTR(-EINVAL);
 
attach = kzalloc(sizeof(*attach), GFP_KERNEL);
if (!attach)
return ERR_PTR(-ENOMEM);
 
-   attach->dev = dev;
+   attach->dev = info->dev;
attach->dmabuf = dmabuf;
+   attach->priv = info->priv;
 
mutex_lock(>lock);
 
if (dmabuf->ops->attach) {
-   ret = dmabuf->ops->attach(dmabuf, dev, attach);
+   ret = dmabuf->ops->attach(dmabuf, info->dev, attach);
if (ret)
goto err_attach;
}
diff --git a/drivers/gpu/drm/armada/armada_gem.c 
b/drivers/gpu/drm/armada/armada_gem.c
index a97f509743a5..f4d1c11f57ea 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -514,6 +514,10 @@ armada_gem_prime_export(struct drm_device *dev, struct 
drm_gem_object *obj,
 struct drm_gem_object *
 armada_gem_prime_import(struct drm_device *dev, struct dma_buf *buf)
 {
+   struct dma_buf_attach_info attach_info = {
+   .dev = dev->dev,
+   .dmabuf = buf
+   };
struct dma_buf_attachment *attach;
struct armada_gem_object *dobj;
 
@@ -529,7 +533,7 @@ armada_gem_prime_import(struct drm_device *dev, struct 
dma_buf *buf)
}
}
 
-   attach = dma_buf_attach(buf, dev->dev);
+   attach = dma_buf_attach(_info);
if (IS_ERR(attach))
return ERR_CAST(attach);
 
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 7856a9b3f8a8..4da242de51c2 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -707,6 +707,10 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
drm_device *dev,
struct dma_buf *dma_buf,
struct device *attach_dev)
 {
+   struct dma_buf_attach_info attach_info = {
+   .dev = attach_dev,
+   .dmabuf = dma_buf
+   };
struct dma_buf_attachment *attach;
struct sg_table *sgt;
struct drm_gem_object *obj;
@@ -727,7 +731,7 @@ struct drm_gem_object *drm_gem_prime_import_dev(struct 
drm_device *dev,
if (!dev->driver->gem_prime_import_sg_table)
return ERR_PTR(-EINVAL);
 
-   attach = dma_buf_attach(dma_buf, attach_dev);
+   attach = dma_buf_attach(_info);
if (IS_ERR(attach))
return ERR_CAST(attach);
 
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 

Re: [PATCH] drm/scheduler: remove incorrect param documentation

[Christian König]

Am 25.03.2018 um 13:21 schrieb Nayan Deshmukh:

On Sun, Mar 25, 2018 at 4:44 PM, Christian König
 wrote:

Am 25.03.2018 um 13:09 schrieb Nayan Deshmukh:

Signed-off-by: Nayan Deshmukh 
---
   drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 -
   1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..27fdda1264f7 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -117,7 +117,6 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
* @sched The pointer to the scheduler
* @entityThe pointer to a valid drm_sched_entity
* @rqThe run queue this entity belongs
- * @kernel If this is an entity for the kernel
* @jobs  The max number of jobs in the job queue


If I'm not completely mistaken the jobs parameter is unused and we also have
a @guilty parameter as well.


Yes. But I am not sure what should be done with the jobs parameter.
Should I remove it entirely?


Yes, probably a leftover from when we used a kfifo for the queue.

Regards,
Christian.




The description for the @guilty should be something like "atomic_t set to 1
when a job on this queue is found to be guilty causing a timeout".

Regards,
Christian.



*
* return 0 if succeed. negative error code on failure




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Outreachy kernel] [PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall  wrote:

>
>
> On Mon, 19 Mar 2018, Arushi Singhal wrote:
>
> > This patch replace list_entry with list_{next/prev}_entry as it makes
> > the code more clear to read.
> > Done using coccinelle:
> >
> > @@
> > expression e1;
> > identifier e3;
> > type t;
> > @@
> > (
> > - list_entry(e1->e3.next,t,e3)
> > + list_next_entry(e1,e3)
> > |
> > - list_entry(e1->e3.prev,t,e3)
> > + list_prev_entry(e1,e3)
> > )
>
> This looks like a rule that could be nice for the Linux kernel in general,
> because the code really is much simpler.
>
> I would suggest to write the rule in a more robust way, as follows:
>
> @@
> identifier e3;
> type t;
> t *e1;
> @@
>
> (
> - list_entry(e1->e3.next,t,e3)
> + list_next_entry(e1,e3)
> |
> - list_entry(e1->e3.prev,t,e3)
> + list_prev_entry(e1,e3)
> )
>
> @@
> expression e1;
> identifier e3;
> @@
>
> (
> - list_entry(e1->e3.next,typeof(*e1),e3)
> + list_next_entry(e1,e3)
> |
> - list_entry(e1->e3.prev,typeof(*e1),e3)
> + list_prev_entry(e1,e3)
>
> This checks that the type that is specified corresponds to the one on e1.
> It could actually be that the call is getting the first element of a list,
> from some different type, and coincidentally the two types have the same
> field name for the list element.
>
> Unfortunately, the second rule, with the typeof call, doesn't currently
> work in Coccinelle, because the semantic patch language doesn't actually
> support typeof, and thinks that it is a function call.  I will fix this.
>
> To make a semantic patch for the kernel, you can try running spgen on the
> above file and answer the questions that it asks.  You can find examples
> in the coccinelle/scripts directory.  Just run
>
> spgen foo.cocci
>
> Then answer the questions.  Then run
>
> spgen foo.cocci > foo_for_kernel.cocci
>
> The second run will use the results of the first run to print the semantic
> patch.  Let me know if you have any questions.  You can always adjust the
> semantic patch that is generated by hand afterwards if needed.
>
>
Thanks Julia for explanation and it helped me to learn about Spgen tool.
I'll make the changes and resend.

Arushi

> julia
>
>
> >
> > Signed-off-by: Arushi Singhal 
> > ---
> >  drivers/gpu/drm/drm_lease.c| 2 +-
> >  drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> > index 1402c0e..4dcfb5f 100644
> > --- a/drivers/gpu/drm/drm_lease.c
> > +++ b/drivers/gpu/drm/drm_lease.c
> > @@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
> >   break;
> >
> >   /* Over */
> > - master = list_entry(master->lessee_list.next,
> struct drm_master, lessee_list);
> > + master = list_next_entry(master, lessee_list);
> >   }
> >   }
> >  }
> > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > index e4c8d31..81c3567 100644
> > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
> > @@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct
> nvkm_pstate *pstate,
> >  nvkm_volt_map(volt, volt->max2_id,
> clk->temp));
> >
> >   for (cstate = start; >head != >list;
> > -  cstate = list_entry(cstate->head.prev, typeof(*cstate),
> head)) {
> > +  cstate = list_prev_entry(cstate, head)) {
> >   if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
> >   break;
> >   }
> > --
> > 2.7.4
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "outreachy-kernel" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to outreachy-kernel+unsubscr...@googlegroups.com.
> > To post to this group, send email to outreachy-ker...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/
> msgid/outreachy-kernel/20180319050530.GA25589%40seema-Inspiron-15-3567.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scheduler: remove incorrect param documentation

[Nayan Deshmukh]

On Sun, Mar 25, 2018 at 4:44 PM, Christian König
 wrote:
> Am 25.03.2018 um 13:09 schrieb Nayan Deshmukh:
>>
>> Signed-off-by: Nayan Deshmukh 
>> ---
>>   drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> index 0d95888ccc3e..27fdda1264f7 100644
>> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
>> @@ -117,7 +117,6 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
>>* @sched The pointer to the scheduler
>>* @entityThe pointer to a valid drm_sched_entity
>>* @rqThe run queue this entity belongs
>> - * @kernel If this is an entity for the kernel
>>* @jobs  The max number of jobs in the job queue
>
>
> If I'm not completely mistaken the jobs parameter is unused and we also have
> a @guilty parameter as well.
>
Yes. But I am not sure what should be done with the jobs parameter.
Should I remove it entirely?

> The description for the @guilty should be something like "atomic_t set to 1
> when a job on this queue is found to be guilty causing a timeout".
>
> Regards,
> Christian.
>
>
>>*
>>* return 0 if succeed. negative error code on failure
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/scheduler: remove incorrect param documentation

[Christian König]

Am 25.03.2018 um 13:09 schrieb Nayan Deshmukh:

Signed-off-by: Nayan Deshmukh 
---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..27fdda1264f7 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -117,7 +117,6 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
   * @sched The pointer to the scheduler
   * @entityThe pointer to a valid drm_sched_entity
   * @rqThe run queue this entity belongs
- * @kernel If this is an entity for the kernel
   * @jobs  The max number of jobs in the job queue


If I'm not completely mistaken the jobs parameter is unused and we also 
have a @guilty parameter as well.


The description for the @guilty should be something like "atomic_t set 
to 1 when a job on this queue is found to be guilty causing a timeout".


Regards,
Christian.


   *
   * return 0 if succeed. negative error code on failure


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/scheduler: remove incorrect param documentation

[Nayan Deshmukh]

Signed-off-by: Nayan Deshmukh 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 0d95888ccc3e..27fdda1264f7 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -117,7 +117,6 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
  * @sched  The pointer to the scheduler
  * @entity The pointer to a valid drm_sched_entity
  * @rq The run queue this entity belongs
- * @kernel If this is an entity for the kernel
  * @jobs   The max number of jobs in the job queue
  *
  * return 0 if succeed. negative error code on failure
-- 
2.14.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 7/8] drm/amdgpu: add amdgpu_gem_attach

[Christian König]

Check if we can do peer2peer on the PCIe bus.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 2566268806c3..133596df0775 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -134,6 +134,29 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return obj;
 }
 
+static int amdgpu_gem_attach(struct dma_buf *dma_buf, struct device *dev,
+struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+
+   if (!attach->peer2peer)
+   return 0;
+
+   if (!dev_is_pci(dev))
+   goto no_peer2peer;
+
+   if (!pci_peer_traffic_supported(adev->pdev, to_pci_dev(dev)))
+   goto no_peer2peer;
+
+   return 0;
+
+no_peer2peer:
+   attach->peer2peer = false;
+   return 0;
+}
+
 static struct sg_table *
 amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
   enum dma_data_direction dir)
@@ -274,6 +297,7 @@ static int amdgpu_gem_begin_cpu_access(struct dma_buf 
*dma_buf,
 }
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops = {
+   .attach = amdgpu_gem_attach,
.map_dma_buf = amdgpu_gem_map_dma_buf,
.unmap_dma_buf = amdgpu_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/8] drm/amdgpu: add support for exporting VRAM using DMA-buf

[Christian König]

We should be able to do this now after checking all the prerequisites.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 44 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h  |  9 +++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 91 
 3 files changed, 135 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 133596df0775..86d983a0678b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -197,23 +197,44 @@ amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
} else {
/* move buffer into GTT */
struct ttm_operation_ctx ctx = { false, false };
+   unsigned domains = AMDGPU_GEM_DOMAIN_GTT;
 
-   amdgpu_ttm_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
+   if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM &&
+   attach->peer2peer) {
+   bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
+   domains |= AMDGPU_GEM_DOMAIN_VRAM;
+   }
+   amdgpu_ttm_placement_from_domain(bo, domains);
r = ttm_bo_validate(>tbo, >placement, );
if (r)
goto error_unreserve;
}
 
-   sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
-   if (IS_ERR(sgt)) {
-   r = PTR_ERR(sgt);
+   switch (bo->tbo.mem.mem_type) {
+   case TTM_PL_TT:
+   sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
+   bo->tbo.num_pages);
+   if (IS_ERR(sgt)) {
+   r = PTR_ERR(sgt);
+   goto error_unreserve;
+   }
+
+   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
+ DMA_ATTR_SKIP_CPU_SYNC))
+   goto error_free;
+   break;
+
+   case TTM_PL_VRAM:
+   r = amdgpu_vram_mgr_alloc_sgt(adev, >tbo.mem, attach->dev,
+ dir, );
+   if (r)
+   goto error_unreserve;
+   break;
+   default:
+   r = -EINVAL;
goto error_unreserve;
}
 
-   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
- DMA_ATTR_SKIP_CPU_SYNC))
-   goto error_free;
-
if (attach->dev->driver != adev->dev->driver)
bo->prime_shared_count++;
 
@@ -254,10 +275,15 @@ static void amdgpu_gem_unmap_dma_buf(struct 
dma_buf_attachment *attach,
if (!attach->invalidate)
amdgpu_bo_unreserve(bo);
 
-   if (sgt) {
+   if (!sgt)
+   return;
+
+   if (sgt->sgl->page_link) {
dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
sg_free_table(sgt);
kfree(sgt);
+   } else {
+   amdgpu_vram_mgr_free_sgt(adev, attach->dev, dir, sgt);
}
 }
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
index 6ea7de863041..b483900abed2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
@@ -73,6 +73,15 @@ bool amdgpu_gtt_mgr_has_gart_addr(struct ttm_mem_reg *mem);
 uint64_t amdgpu_gtt_mgr_usage(struct ttm_mem_type_manager *man);
 int amdgpu_gtt_mgr_recover(struct ttm_mem_type_manager *man);
 
+int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
+ struct ttm_mem_reg *mem,
+ struct device *dev,
+ enum dma_data_direction dir,
+ struct sg_table **sgt);
+void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
+ struct device *dev,
+ enum dma_data_direction dir,
+ struct sg_table *sgt);
 uint64_t amdgpu_vram_mgr_usage(struct ttm_mem_type_manager *man);
 uint64_t amdgpu_vram_mgr_vis_usage(struct ttm_mem_type_manager *man);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index 9aca653bec07..eb8f75525a81 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -233,6 +233,97 @@ static void amdgpu_vram_mgr_del(struct 
ttm_mem_type_manager *man,
mem->mm_node = NULL;
 }
 
+/**
+ * amdgpu_vram_mgr_alloc_sgt - allocate and fill a sg table
+ *
+ * @adev: amdgpu device pointer
+ * @mem: TTM memory object
+ * @dev: the other device
+ * @dir: dma direction
+ * @sgt: resulting sg table
+ *
+ * Allocate and fill a sg table from a VRAM allocation.
+ */
+int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,

[PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper

[Christian König]

Use this function to set an sg entry to point to device resources mapped
using dma_map_resource(). The page pointer is set to NULL and only the DMA
address, length and offset values are valid.

Signed-off-by: Christian König 
---
 include/linux/scatterlist.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index 22b2131bcdcd..f944ee4e482c 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -149,6 +149,29 @@ static inline void sg_set_buf(struct scatterlist *sg, 
const void *buf,
sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
 }
 
+/**
+ * sg_set_dma_addr - Set sg entry to point at specified dma address
+ * @sg: SG entry
+ * @address:DMA address to set
+ * @len:Length of data
+ * @offset: Offset into page
+ *
+ * Description:
+ *   Use this function to set an sg entry to point to device resources mapped
+ *   using dma_map_resource(). The page pointer is set to NULL and only the DMA
+ *   address, length and offset values are valid.
+ *
+ **/
+static inline void sg_set_dma_addr(struct scatterlist *sg, dma_addr_t address,
+  unsigned int len, unsigned int offset)
+{
+   sg_set_page(sg, NULL, len, offset);
+   sg->dma_address = address;
+#ifdef CONFIG_NEED_SG_DMA_LENGTH
+   sg->dma_length = len;
+#endif
+}
+
 /*
  * Loop over each sg element, following the pointer to a new list if necessary
  */
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/8] drm/amdgpu: note that we can handle peer2peer DMA-buf

[Christian König]

Importing should work out of the box.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index fb43faf88eb0..2566268806c3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -353,6 +353,7 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(obj))
return obj;
 
+   attach_info.peer2peer = true;
attach_info.priv = obj;
attach = dma_buf_attach(_info);
if (IS_ERR(attach)) {
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/8] PCI: Add pci_peer_traffic_supported()

[Christian König]

From: "wda...@nvidia.com" 

Add checks for topology and ACS configuration to determine whether or not
peer traffic should be supported between two PCI devices.

Signed-off-by: Will Davis 
Signed-off-by: Christian König 
---
 drivers/pci/pci.c   | 112 
 include/linux/pci.h |   1 +
 2 files changed, 113 insertions(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index f6a4dd10d9b0..efdca3c9dad1 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -5285,6 +5286,117 @@ void pci_ignore_hotplug(struct pci_dev *dev)
 }
 EXPORT_SYMBOL_GPL(pci_ignore_hotplug);
 
+static bool pci_peer_host_traffic_supported(struct pci_host_bridge *host)
+{
+   struct pci_dev *bridge = pci_get_slot(host->bus, PCI_DEVFN(0, 0));
+   unsigned short vendor, device;
+
+   if (!bridge)
+   return false;
+
+   vendor = bridge->vendor;
+   device = bridge->device;
+   pci_dev_put(bridge);
+
+   /* AMD ZEN host bridges can do peer to peer */
+   if (vendor == PCI_VENDOR_ID_AMD && device == 0x1450)
+   return true;
+
+   /* TODO: Extend that to a proper whitelist */
+   return false;
+}
+
+bool pci_peer_traffic_supported(struct pci_dev *dev, struct pci_dev *peer)
+{
+   struct pci_dev *rp_dev, *rp_peer, *common_upstream;
+   struct pci_host_bridge *peer_host_bridge;
+   struct pci_host_bridge *dev_host_bridge;
+   int pos;
+   u16 cap;
+
+   /* This is tricky enough, focus on PCIe for now */
+   if (!pci_is_pcie(dev) || !pci_is_pcie(peer))
+   return false;
+
+   /*
+* Disallow the peer-to-peer traffic if the devices do not share a
+* host bridge. The PCI specifications does not make any guarantees
+* about P2P capabilities between devices under separate domains.
+*
+* PCI Local Bus Specification Revision 3.0, section 3.10:
+*"Peer-to-peer transactions crossing multiple host bridges
+* PCI host bridges may, but are not required to, support PCI
+* peer-to-peer transactions that traverse multiple PCI host
+* bridges."
+*/
+   dev_host_bridge = pci_find_host_bridge(dev->bus);
+   peer_host_bridge = pci_find_host_bridge(peer->bus);
+   if (dev_host_bridge != peer_host_bridge)
+   return pci_peer_host_traffic_supported(dev_host_bridge);
+
+   rp_dev = pcie_find_root_port(dev);
+   rp_peer = pcie_find_root_port(peer);
+   common_upstream = pci_find_common_upstream_dev(dev, peer);
+
+   /*
+* Access Control Services (ACS) Checks
+*
+* ACS has a capability bit for P2P Request Redirects (RR),
+* but unfortunately it doesn't tell us much about the real
+* capabilities of the hardware.
+*
+* PCI Express Base Specification Revision 3.0, section
+* 6.12.1.1:
+*"ACS P2P Request Redirect: must be implemented by Root
+* Ports that support peer-to-peer traffic with other
+* Root Ports; [80]"
+* but
+*"[80] Root Port indication of ACS P2P Request Redirect
+* or ACS P2P Completion Redirect support does not imply
+* any particular level of peer-to-peer support by the
+* Root Complex, or that peer-to-peer traffic is
+* supported at all"
+*/
+
+   /*
+* If ACS is not implemented, we have no idea about P2P
+* support. Optimistically allow this if there is a common
+* upstream device.
+*/
+   pos = pci_find_ext_capability(rp_dev, PCI_EXT_CAP_ID_ACS);
+   if (!pos)
+   return common_upstream != NULL;
+
+   /*
+* If the devices are under the same root port and have a common
+* upstream device, allow if the root port is further upstream
+* from the common upstream device and the common upstream
+* device has Upstream Forwarding disabled, or if the root port
+* is the common upstream device and ACS is not implemented.
+*/
+   pci_read_config_word(rp_dev, pos + PCI_ACS_CAP, );
+   if ((rp_dev == rp_peer && common_upstream) &&
+   (((common_upstream != rp_dev) &&
+ !pci_acs_enabled(common_upstream, PCI_ACS_UF)) ||
+((common_upstream == rp_dev) && ((cap & PCI_ACS_RR) == 0
+   return true;
+
+   /*
+* If ACS RR is implemented and disabled, allow only if the
+* devices are under the same root port.
+*/
+   if (cap & PCI_ACS_RR && !pci_acs_enabled(rp_dev, PCI_ACS_RR))
+   return rp_dev == rp_peer;
+
+   /*
+* If ACS RR is not implemented, or is implemented and enabled,
+* only allow if there's a translation agent enabled 

[PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

[Christian König]

From: "wda...@nvidia.com" 

Add an interface to find the first device which is upstream of both
devices.

Signed-off-by: Will Davis 
Signed-off-by: Christian König 
---
 drivers/pci/search.c | 24 
 include/linux/pci.h  |  2 ++
 2 files changed, 26 insertions(+)

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index bc1e023f1353..446648f4238b 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -393,3 +393,27 @@ int pci_dev_present(const struct pci_device_id *ids)
return 0;
 }
 EXPORT_SYMBOL(pci_dev_present);
+
+/**
+ * pci_find_common_upstream_dev - Returns the first common upstream device
+ * @dev: the PCI device from which the bus hierarchy walk will start
+ * @other: the PCI device whose bus number will be used for the search
+ *
+ * Walks up the bus hierarchy from the @dev device, looking for the first bus
+ * which the @other device is downstream of. Returns %NULL if the devices do
+ * not share any upstream devices.
+ */
+struct pci_dev *pci_find_common_upstream_dev(struct pci_dev *dev,
+struct pci_dev *other)
+{
+   struct pci_dev *pdev = dev;
+
+   while (pdev != NULL) {
+   if ((other->bus->number >= pdev->bus->busn_res.start) &&
+   (other->bus->number <= pdev->bus->busn_res.end))
+   return pdev;
+   pdev = pci_upstream_bridge(pdev);
+   }
+
+   return NULL;
+}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 024a1beda008..0d29f5cdcb04 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -956,6 +956,8 @@ static inline struct pci_dev *pci_get_bus_and_slot(unsigned 
int bus,
 }
 struct pci_dev *pci_get_class(unsigned int class, struct pci_dev *from);
 int pci_dev_present(const struct pci_device_id *ids);
+struct pci_dev *pci_find_common_upstream_dev(struct pci_dev *from,
+struct pci_dev *to);
 
 int pci_bus_read_config_byte(struct pci_bus *bus, unsigned int devfn,
 int where, u8 *val);
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/8] dma-buf: add peer2peer flag

[Christian König]

Add a peer2peer flag noting that the importer can deal with device
resources which are not backed by pages.

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c | 1 +
 include/linux/dma-buf.h   | 4 
 2 files changed, 5 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index ffaa2f9a9c2c..f420225f93c6 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -565,6 +565,7 @@ struct dma_buf_attachment *dma_buf_attach(const struct 
dma_buf_attach_info *info
 
attach->dev = info->dev;
attach->dmabuf = dmabuf;
+   attach->peer2peer = info->peer2peer;
attach->priv = info->priv;
attach->invalidate = info->invalidate;
 
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 15dd8598bff1..1ef50bd9bc5b 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -313,6 +313,7 @@ struct dma_buf {
  * @dmabuf: buffer for this attachment.
  * @dev: device attached to the buffer.
  * @node: list of dma_buf_attachment.
+ * @peer2peer: true if the importer can handle peer resources without pages.
  * @priv: exporter specific attachment data.
  *
  * This structure holds the attachment information between the dma_buf buffer
@@ -328,6 +329,7 @@ struct dma_buf_attachment {
struct dma_buf *dmabuf;
struct device *dev;
struct list_head node;
+   bool peer2peer;
void *priv;
 
/**
@@ -392,6 +394,7 @@ struct dma_buf_export_info {
  * @dmabuf:the exported dma_buf
  * @dev:   the device which wants to import the attachment
  * @priv:  private data of importer to this attachment
+ * @peer2peer: true if the importer can handle peer resources without pages
  * @invalidate:callback to use for invalidating mappings
  *
  * This structure holds the information required to attach to a buffer. Used
@@ -401,6 +404,7 @@ struct dma_buf_attach_info {
struct dma_buf *dmabuf;
struct device *dev;
void *priv;
+   bool peer2peer;
void (*invalidate)(struct dma_buf_attachment *attach);
 };
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/8] drm/amdgpu: print DMA-buf status in debugfs

[Christian König]

Just note if a BO was imported/exported.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 46b9ea4e6103..7c1f761bb1a5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -777,6 +777,8 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr, 
void *data)
struct amdgpu_bo *bo = gem_to_amdgpu_bo(gobj);
struct seq_file *m = data;
 
+   struct dma_buf_attachment *attachment;
+   struct dma_buf *dma_buf;
unsigned domain;
const char *placement;
unsigned pin_count;
@@ -805,6 +807,15 @@ static int amdgpu_debugfs_gem_bo_info(int id, void *ptr, 
void *data)
pin_count = READ_ONCE(bo->pin_count);
if (pin_count)
seq_printf(m, " pin count %d", pin_count);
+
+   dma_buf = READ_ONCE(bo->gem_base.dma_buf);
+   attachment = READ_ONCE(bo->gem_base.import_attach);
+
+   if (attachment)
+   seq_printf(m, " imported from %p", dma_buf);
+   else if (dma_buf)
+   seq_printf(m, " exported as %p", dma_buf);
+
seq_printf(m, "\n");
 
return 0;
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/5] drm/ttm: keep a reference to transfer pipelined BOs

[Christian König]

Make sure the transfered BO is never destroy before the transfer BO.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
 1 file changed, 30 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 1f730b3f18e5..1ee20558ee31 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -39,6 +39,11 @@
 #include 
 #include 
 
+struct ttm_transfer_obj {
+   struct ttm_buffer_object base;
+   struct ttm_buffer_object *bo;
+};
+
 void ttm_bo_free_old_node(struct ttm_buffer_object *bo)
 {
ttm_bo_mem_put(bo, >mem);
@@ -435,7 +440,11 @@ EXPORT_SYMBOL(ttm_bo_move_memcpy);
 
 static void ttm_transfered_destroy(struct ttm_buffer_object *bo)
 {
-   kfree(bo);
+   struct ttm_transfer_obj *fbo;
+
+   fbo = container_of(bo, struct ttm_transfer_obj, base);
+   ttm_bo_unref(>bo);
+   kfree(fbo);
 }
 
 /**
@@ -456,14 +465,15 @@ static void ttm_transfered_destroy(struct 
ttm_buffer_object *bo)
 static int ttm_buffer_object_transfer(struct ttm_buffer_object *bo,
  struct ttm_buffer_object **new_obj)
 {
-   struct ttm_buffer_object *fbo;
+   struct ttm_transfer_obj *fbo;
int ret;
 
fbo = kmalloc(sizeof(*fbo), GFP_KERNEL);
if (!fbo)
return -ENOMEM;
 
-   *fbo = *bo;
+   fbo->base = *bo;
+   fbo->bo = ttm_bo_reference(bo);
 
/**
 * Fix up members that we shouldn't copy directly:
@@ -471,25 +481,25 @@ static int ttm_buffer_object_transfer(struct 
ttm_buffer_object *bo,
 */
 
atomic_inc(>bdev->glob->bo_count);
-   INIT_LIST_HEAD(>ddestroy);
-   INIT_LIST_HEAD(>lru);
-   INIT_LIST_HEAD(>swap);
-   INIT_LIST_HEAD(>io_reserve_lru);
-   mutex_init(>wu_mutex);
-   fbo->moving = NULL;
-   drm_vma_node_reset(>vma_node);
-   atomic_set(>cpu_writers, 0);
-
-   kref_init(>list_kref);
-   kref_init(>kref);
-   fbo->destroy = _transfered_destroy;
-   fbo->acc_size = 0;
-   fbo->resv = >ttm_resv;
-   reservation_object_init(fbo->resv);
-   ret = reservation_object_trylock(fbo->resv);
+   INIT_LIST_HEAD(>base.ddestroy);
+   INIT_LIST_HEAD(>base.lru);
+   INIT_LIST_HEAD(>base.swap);
+   INIT_LIST_HEAD(>base.io_reserve_lru);
+   mutex_init(>base.wu_mutex);
+   fbo->base.moving = NULL;
+   drm_vma_node_reset(>base.vma_node);
+   atomic_set(>base.cpu_writers, 0);
+
+   kref_init(>base.list_kref);
+   kref_init(>base.kref);
+   fbo->base.destroy = _transfered_destroy;
+   fbo->base.acc_size = 0;
+   fbo->base.resv = >base.ttm_resv;
+   reservation_object_init(fbo->base.resv);
+   ret = reservation_object_trylock(fbo->base.resv);
WARN_ON(!ret);
 
-   *new_obj = fbo;
+   *new_obj = >base;
return 0;
 }
 
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

[Christian König]

Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.

v2: fix unintended recursion, remove debugging leftovers

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |   5 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  | 108 ++---
 4 files changed, 72 insertions(+), 43 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index a7e22298ce5c..190bada6f487 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -371,7 +371,6 @@ int amdgpu_gem_object_open(struct drm_gem_object *obj,
 void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
 unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
 struct drm_gem_object *
 amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
 struct dma_buf_attachment *attach,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 1bfce79bc074..33893f0311c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -892,7 +892,6 @@ static struct drm_driver kms_driver = {
.gem_prime_export = amdgpu_gem_prime_export,
.gem_prime_import = amdgpu_gem_prime_import,
.gem_prime_res_obj = amdgpu_gem_prime_res_obj,
-   .gem_prime_get_sg_table = amdgpu_gem_prime_get_sg_table,
.gem_prime_import_sg_table = amdgpu_gem_prime_import_sg_table,
.gem_prime_vmap = amdgpu_gem_prime_vmap,
.gem_prime_vunmap = amdgpu_gem_prime_vunmap,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index ac1fa3394a9e..11d2ac175b30 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -31,6 +31,7 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -935,6 +936,10 @@ void amdgpu_bo_move_notify(struct ttm_buffer_object *bo,
 
amdgpu_bo_kunmap(abo);
 
+   if (abo->gem_base.dma_buf && !abo->gem_base.import_attach &&
+   bo->mem.mem_type != TTM_PL_SYSTEM)
+   dma_buf_invalidate_mappings(abo->gem_base.dma_buf);
+
/* remember the eviction */
if (evict)
atomic64_inc(>num_evictions);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 4b584cb75bf4..7fef95f0fed1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -32,14 +32,6 @@
 
 static const struct dma_buf_ops amdgpu_dmabuf_ops;
 
-struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
-{
-   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
-   int npages = bo->tbo.num_pages;
-
-   return drm_prime_pages_to_sg(bo->tbo.ttm->pages, npages);
-}
-
 void *amdgpu_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
@@ -126,23 +118,22 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
-static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
-struct device *target_dev,
-struct dma_buf_attachment *attach)
+static struct sg_table *
+amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
+  enum dma_data_direction dir)
 {
+   struct dma_buf *dma_buf = attach->dmabuf;
struct drm_gem_object *obj = dma_buf->priv;
struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
+   struct sg_table *sgt;
long r;
 
-   r = drm_gem_map_attach(dma_buf, target_dev, attach);
-   if (r)
-   return r;
-
-   r = amdgpu_bo_reserve(bo, false);
-   if (unlikely(r != 0))
-   goto error_detach;
-
+   if (!attach->invalidate) {
+   r = amdgpu_bo_reserve(bo, false);
+   if (unlikely(r != 0))
+   return ERR_PTR(r);
+   }
 
if (attach->dev->driver != adev->dev->driver) {
/*
@@ -158,42 +149,77 @@ static int amdgpu_gem_map_attach(struct dma_buf *dma_buf,
}
}
 
-   /* pin buffer into GTT */
-   r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
-   if (r)
+   if (!attach->invalidate) {
+   /* pin buffer into GTT */
+   r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT, NULL);
+   if (r)
+   goto error_unreserve;
+
+   } else {
+   /* move buffer into GTT */
+ 

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

[Christian König]

Pipeline removal of the BOs backing store when the placement is given
during validation.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 98e06f8bf23b..17e821f01d0a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1078,6 +1078,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
uint32_t new_flags;
 
reservation_object_assert_held(bo->resv);
+
+   /*
+* Remove the backing store if no placement is given.
+*/
+   if (!placement->num_placement && !placement->num_busy_placement) {
+   ret = ttm_bo_pipeline_gutting(bo);
+   if (ret)
+   return ret;
+
+   return ttm_tt_create(bo, false);
+   }
+
/*
 * Check whether we need to move buffer.
 */
-- 
2.14.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/amdgpu: add independent DMA-buf import v3

[Christian König]

Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.

v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
v3: change to new dma_buf attach interface

Signed-off-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 72 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 32 +++---
 2 files changed, 89 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index 7fef95f0fed1..fb43faf88eb0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -86,28 +86,24 @@ int amdgpu_gem_prime_mmap(struct drm_gem_object *obj, 
struct vm_area_struct *vma
return ret;
 }
 
-struct drm_gem_object *
-amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-struct dma_buf_attachment *attach,
-struct sg_table *sg)
+static struct drm_gem_object *
+amdgpu_gem_prime_create_obj(struct drm_device *dev, struct dma_buf *dma_buf)
 {
-   struct reservation_object *resv = attach->dmabuf->resv;
+   struct reservation_object *resv = dma_buf->resv;
struct amdgpu_device *adev = dev->dev_private;
struct amdgpu_bo *bo;
int ret;
 
ww_mutex_lock(>lock, NULL);
-   ret = amdgpu_bo_create(adev, attach->dmabuf->size, PAGE_SIZE,
+   ret = amdgpu_bo_create(adev, dma_buf->size, PAGE_SIZE,
   AMDGPU_GEM_DOMAIN_CPU, 0, ttm_bo_type_sg,
   resv, );
if (ret)
goto error;
 
-   bo->tbo.sg = sg;
-   bo->tbo.ttm->sg = sg;
bo->allowed_domains = AMDGPU_GEM_DOMAIN_GTT;
bo->preferred_domains = AMDGPU_GEM_DOMAIN_GTT;
-   if (attach->dmabuf->ops != _dmabuf_ops)
+   if (dma_buf->ops != _dmabuf_ops)
bo->prime_shared_count = 1;
 
ww_mutex_unlock(>lock);
@@ -118,6 +114,26 @@ amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(ret);
 }
 
+struct drm_gem_object *
+amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
+struct dma_buf_attachment *attach,
+struct sg_table *sg)
+{
+   struct drm_gem_object *obj;
+   struct amdgpu_bo *bo;
+
+   obj = amdgpu_gem_prime_create_obj(dev, attach->dmabuf);
+   if (IS_ERR(obj))
+   return obj;
+
+   bo = gem_to_amdgpu_bo(obj);
+   amdgpu_bo_reserve(bo, true);
+   bo->tbo.sg = sg;
+   bo->tbo.ttm->sg = sg;
+   amdgpu_bo_unreserve(bo);
+   return obj;
+}
+
 static struct sg_table *
 amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
   enum dma_data_direction dir)
@@ -293,9 +309,29 @@ struct dma_buf *amdgpu_gem_prime_export(struct drm_device 
*dev,
return buf;
 }
 
+static void
+amdgpu_gem_prime_invalidate_mappings(struct dma_buf_attachment *attach)
+{
+   struct ttm_operation_ctx ctx = { false, false };
+   struct drm_gem_object *obj = attach->priv;
+   struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
+   struct ttm_placement placement = {};
+   int r;
+
+   r = ttm_bo_validate(>tbo, , );
+   if (r)
+   DRM_ERROR("Failed to unmap DMA-buf import (%d))\n", r);
+}
+
 struct drm_gem_object *amdgpu_gem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
 {
+   struct dma_buf_attach_info attach_info = {
+   .dev = dev->dev,
+   .dmabuf = dma_buf,
+   .invalidate = amdgpu_gem_prime_invalidate_mappings
+   };
+   struct dma_buf_attachment *attach;
struct drm_gem_object *obj;
 
if (dma_buf->ops == _dmabuf_ops) {
@@ -310,5 +346,21 @@ struct drm_gem_object *amdgpu_gem_prime_import(struct 
drm_device *dev,
}
}
 
-   return drm_gem_prime_import(dev, dma_buf);
+   if (!dma_buf->invalidation_supported)
+   return drm_gem_prime_import(dev, dma_buf);
+
+   obj = amdgpu_gem_prime_create_obj(dev, dma_buf);
+   if (IS_ERR(obj))
+   return obj;
+
+   attach_info.priv = obj;
+   attach = dma_buf_attach(_info);
+   if (IS_ERR(attach)) {
+   drm_gem_object_put(obj);
+   return ERR_CAST(attach);
+   }
+
+   get_dma_buf(dma_buf);
+   obj->import_attach = attach;
+   return obj;
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index d2ab40494a4c..ad93f201e7b6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "amdgpu.h"
 #include "amdgpu_object.h"
 

[PATCH 1/5] dma-buf: add optional invalidate_mappings callback v3

[Christian König]

Each importer can now provide an invalidate_mappings callback.

This allows the exporter to provide the mappings without the need to pin
the backing store.

v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to set the callback
v3: move flag for invalidation support into the DMA-buf,
use new attach_info structure to set the callback

Signed-off-by: Christian König 
---
 drivers/dma-buf/dma-buf.c | 43 +++
 include/linux/dma-buf.h   | 28 
 2 files changed, 71 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d2e8ca0d9427..ffaa2f9a9c2c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -566,6 +566,7 @@ struct dma_buf_attachment *dma_buf_attach(const struct 
dma_buf_attach_info *info
attach->dev = info->dev;
attach->dmabuf = dmabuf;
attach->priv = info->priv;
+   attach->invalidate = info->invalidate;
 
mutex_lock(>lock);
 
@@ -574,7 +575,9 @@ struct dma_buf_attachment *dma_buf_attach(const struct 
dma_buf_attach_info *info
if (ret)
goto err_attach;
}
+   reservation_object_lock(dmabuf->resv, NULL);
list_add(>node, >attachments);
+   reservation_object_unlock(dmabuf->resv);
 
mutex_unlock(>lock);
return attach;
@@ -600,7 +603,9 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
dma_buf_attachment *attach)
return;
 
mutex_lock(>lock);
+   reservation_object_lock(dmabuf->resv, NULL);
list_del(>node);
+   reservation_object_unlock(dmabuf->resv);
if (dmabuf->ops->detach)
dmabuf->ops->detach(dmabuf, attach);
 
@@ -634,10 +639,23 @@ struct sg_table *dma_buf_map_attachment(struct 
dma_buf_attachment *attach,
if (WARN_ON(!attach || !attach->dmabuf))
return ERR_PTR(-EINVAL);
 
+   /*
+* Mapping a DMA-buf can trigger its invalidation, prevent sending this
+* event to the caller by temporary removing this attachment from the
+* list.
+*/
+   if (attach->invalidate) {
+   reservation_object_assert_held(attach->dmabuf->resv);
+   list_del(>node);
+   }
+
sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
if (!sg_table)
sg_table = ERR_PTR(-ENOMEM);
 
+   if (attach->invalidate)
+   list_add(>node, >dmabuf->attachments);
+
return sg_table;
 }
 EXPORT_SYMBOL_GPL(dma_buf_map_attachment);
@@ -658,6 +676,9 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 {
might_sleep();
 
+   if (attach->invalidate)
+   reservation_object_assert_held(attach->dmabuf->resv);
+
if (WARN_ON(!attach || !attach->dmabuf || !sg_table))
return;
 
@@ -666,6 +687,26 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
*attach,
 }
 EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
 
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all attachmenst that they need to destroy and recreated all their
+ * mappings.
+ */
+void dma_buf_invalidate_mappings(struct dma_buf *dmabuf)
+{
+   struct dma_buf_attachment *attach;
+
+   reservation_object_assert_held(dmabuf->resv);
+
+   list_for_each_entry(attach, >attachments, node)
+   if (attach->invalidate)
+   attach->invalidate(attach);
+}
+EXPORT_SYMBOL_GPL(dma_buf_invalidate_mappings);
+
 /**
  * DOC: cpu access
  *
@@ -1123,10 +1164,12 @@ static int dma_buf_debug_show(struct seq_file *s, void 
*unused)
seq_puts(s, "\tAttached Devices:\n");
attach_count = 0;
 
+   reservation_object_lock(buf_obj->resv, NULL);
list_for_each_entry(attach_obj, _obj->attachments, node) {
seq_printf(s, "\t%s\n", dev_name(attach_obj->dev));
attach_count++;
}
+   reservation_object_unlock(buf_obj->resv);
 
seq_printf(s, "Total %d devices attached\n\n",
attach_count);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 2c27568d44af..15dd8598bff1 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -270,6 +270,8 @@ struct dma_buf_ops {
  * @poll: for userspace poll support
  * @cb_excl: for userspace poll support
  * @cb_shared: for userspace poll support
+ * @invalidation_supported: True when the exporter supports unpinned operation
+ *  using the reservation lock.
  *
  * This represents a shared buffer, created by calling dma_buf_export(). The
  * userspace representation is a normal file 

Re: [PATCH v2 4/4] drm/vc4: Restrict active CTM to one CRTC

[Daniel Stone]

Hi Stefan,

On 25 March 2018 at 02:52, Stefan Schake  wrote:
> +static int vc4_crtc_get_ctm_fifo(struct vc4_dev *vc4)
> +{
> +   return VC4_GET_FIELD(HVS_READ(SCALER_OLEDOFFS),
> +SCALER_OLEDOFFS_DISPFIFO);
> +}

This needs to be managed as a global resource through atomic state
objects, rather than checking the current hardware state.

Cheers,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel