date:20180703

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

Andrew Dorney  changed:

   What|Removed |Added

 Attachment #140442|0   |1
is obsolete||

--- Comment #3 from Andrew Dorney  ---
Created attachment 140458
  --> https://bugs.freedesktop.org/attachment.cgi?id=140458=edit
dmesg

Updated dmesg from 2018-07-03. VM Fault occurs at 123s, in Fluxbox. I started
Firefox around 120s which is the easiest way to get the crash.

-- 
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 107095] Artifacts in X sessions, GPU fault 147

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

--- Comment #2 from Andrew Dorney  ---
Created attachment 140457
  --> https://bugs.freedesktop.org/attachment.cgi?id=140457=edit
Xorg log

Log lasts 6 seconds, GPU Fault occurs at 123s into this log (that is, X doesn't
report any issues).

-- 
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

Drive

2018-07-03 Thread rosdi ablatiff

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

[Bug 107065] "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921

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

--- Comment #15 from Andrey Grodzovsky  ---
(In reply to dwagner from comment #14)
> (In reply to Andrey Grodzovsky from comment #13)
> > What ASIC are you using ? I also tested with
> > gfx8 ASIC and haven't observed any issues with resume. Did you update the
> > firmware for this ASIC to latest #
> 
> The GPU is an RX460 "POLARIS11 0x1002:0x67EF 0x1682:0x9460 0xCF",
> with the latest firmware from the kernel git, you can see the
> details from https://bugs.freedesktop.org/attachment.cgi?id=140383
> uploaded earlier.

We have only minor differences but I can't reproduce it. Maybe the resume
failure is indeed due the eviction failure during suspend. Is S3 failure is
happening only when you switch to CPU update mode ?

-- 
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 1/2] dt-bindings: display: rockchip: add document for px30 vop

On Tue, Jun 26, 2018 at 04:53:34PM +0800, Sandy Huang wrote:
> Signed-off-by: Sandy Huang 
> ---
>  Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 2 ++
>  1 file changed, 2 insertions(+)

Acked-by: Rob Herring 

> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
> index eeda359..5de2a0f 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
> @@ -8,6 +8,8 @@ Required properties:
>  - compatible: value should be one of the following
>   "rockchip,rk3036-vop";
>   "rockchip,rk3126-vop";
> + "rockchip,px30-vop-lit";
> + "rockchip,px30-vop-big";
>   "rockchip,rk3288-vop";
>   "rockchip,rk3368-vop";
>   "rockchip,rk3366-vop";
> -- 
> 2.7.4
> 
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()

A CRTC being enabled doesn't mean it's on! It doesn't even necessarily
mean it's being used. This fixes runtime PM leaks on the P50 I've got
next to me.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d9da69c83ae7..9bae4db84cfb 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
nv50_disp_atomic_commit_tail(state);
 
drm_for_each_crtc(crtc, dev) {
-   if (crtc->state->enable) {
+   if (crtc->state->active) {
if (!drm->have_disp_power_ref) {
drm->have_disp_power_ref = true;
return 0;
-- 
2.17.1

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

[PATCH 1/2] drm/nouveau: Fix runtime PM leak in drm_open()

Noticed this as I was skimming through, if we fail to allocate memory
for cli we'll end up returning without dropping the runtime PM ref we
got. Additionally, we'll even return the wrong return code! (ret most
likely will == 0 here, we want -ENOMEM).

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 0452b18d36b9..0f668e275ee1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -919,8 +919,10 @@ nouveau_drm_open(struct drm_device *dev, struct drm_file 
*fpriv)
get_task_comm(tmpname, current);
snprintf(name, sizeof(name), "%s[%d]", tmpname, pid_nr(fpriv->pid));
 
-   if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL)))
-   return ret;
+   if (!(cli = kzalloc(sizeof(*cli), GFP_KERNEL))) {
+   ret = -ENOMEM;
+   goto done;
+   }
 
ret = nouveau_cli_init(drm, name, cli);
if (ret)
-- 
2.17.1

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

[PATCH 0/2] drm/nouveau: Fix runtime PM leaks

One very easy to trigger runtime PM leak, along with a rare never before
seen runtime PM leak!

Lyude Paul (2):
  drm/nouveau: Fix runtime PM leak in drm_open()
  drm/nouveau: Fix runtime PM leak in nv50_disp_atomic_commit()

 drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

-- 
2.17.1

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

Re: [PATCH 2/2] drm/panel: simple: Add support for DataImage SCF0700C48GGU18

On Mon, Jun 25, 2018 at 02:41:30PM +0200, Michal Vokáč wrote:
> This adds support for the DataImage SCF0700C48GGU18 7.0" WVGA (800x480)
> TFT LCD panel. The panel has 24-bit parallel interface and can be
> supported by the simple panel driver.
> 
> Signed-off-by: Michal Vokáč 
> ---
>  .../display/panel/dataimage,scf0700c48ggu18.txt|  8 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 29 
> ++
>  2 files changed, 37 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/dataimage,scf0700c48ggu18.txt

Reviewed-by: Rob Herring 

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

Re: [PATCH 1/2] dt-bindings: Add DataImage, Inc. vendor prefix

On Mon, Jun 25, 2018 at 02:41:29PM +0200, Michal Vokáč wrote:
> DataImage is a Taiwan-based manufacturer of LCD panels.
> 
> Signed-off-by: Michal Vokáč 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Reviewed-by: Rob Herring 

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

[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260

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

--- Comment #12 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to mikita.lip...@amd.com from comment #10)
> Johannes,
> My patch wasn't merged into DRM, but Daniel Vetter proposed another patch
> that might remove legacy code that causes the issue. Could you remove my
> patch from your tree and apply the following patch:
> 
> https://patchwork.freedesktop.org/patch/230355/
> 
> Could you please if it fixes the Kasan issue for you, thanks.

Sorry, I don't have access to the Carrizo system at moment. I hope, I'll have
it back in a week or so. Will test it, as soon as possible.

-- 
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

Re: [PATCH 1/4] drm/v3d: Delay the scheduler timeout if we're still making progress.

2018-07-03 Thread Alex Deucher

On Tue, Jul 3, 2018 at 1:05 PM, Eric Anholt  wrote:
> GTF-GLES2.gtf.GL.acos.acos_float_vert_xvary submits jobs that take 4
> seconds at maximum resolution, but we still want to reset quickly if a
> job is really hung.  Sample the CL's current address and the return
> address (since we call into tile lists repeatedly) and if either has
> changed then assume we've made progress.
>
> Signed-off-by: Eric Anholt 
> Cc: Lucas Stach 

Series is:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/v3d/v3d_drv.h   |  2 ++
>  drivers/gpu/drm/v3d/v3d_regs.h  |  1 +
>  drivers/gpu/drm/v3d/v3d_sched.c | 18 ++
>  3 files changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> index f546e0ab9562..a5d96d823416 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -189,6 +189,8 @@ struct v3d_job {
>
> /* GPU virtual addresses of the start/end of the CL job. */
> u32 start, end;
> +
> +   u32 timedout_ctca, timedout_ctra;
>  };
>
>  struct v3d_exec_info {
> diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
> index fc13282dfc2f..854046565989 100644
> --- a/drivers/gpu/drm/v3d/v3d_regs.h
> +++ b/drivers/gpu/drm/v3d/v3d_regs.h
> @@ -222,6 +222,7 @@
>  #define V3D_CLE_CTNCA(n) (V3D_CLE_CT0CA + 4 * n)
>  #define V3D_CLE_CT0RA  0x00118
>  #define V3D_CLE_CT1RA  0x0011c
> +#define V3D_CLE_CTNRA(n) (V3D_CLE_CT0RA + 4 * n)
>  #define V3D_CLE_CT0LC  0x00120
>  #define V3D_CLE_CT1LC  0x00124
>  #define V3D_CLE_CT0PC  0x00128
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
> index 808bc901f567..00667c733dca 100644
> --- a/drivers/gpu/drm/v3d/v3d_sched.c
> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
> @@ -153,7 +153,25 @@ v3d_job_timedout(struct drm_sched_job *sched_job)
> struct v3d_job *job = to_v3d_job(sched_job);
> struct v3d_exec_info *exec = job->exec;
> struct v3d_dev *v3d = exec->v3d;
> +   enum v3d_queue job_q = job == >bin ? V3D_BIN : V3D_RENDER;
> enum v3d_queue q;
> +   u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
> +   u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(job_q));
> +
> +   /* If the current address or return address have changed, then
> +* the GPU has probably made progress and we should delay the
> +* reset.  This could fail if the GPU got in an infinite loop
> +* in the CL, but that is pretty unlikely outside of an i-g-t
> +* testcase.
> +*/
> +   if (job->timedout_ctca != ctca || job->timedout_ctra != ctra) {
> +   job->timedout_ctca = ctca;
> +   job->timedout_ctra = ctra;
> +
> +   schedule_delayed_work(>base.work_tdr,
> + job->base.sched->timeout);
> +   return;
> +   }
>
> mutex_lock(>reset_lock);
>
> --
> 2.18.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107065] "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921

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

--- Comment #14 from dwagner  ---
(In reply to Andrey Grodzovsky from comment #13)
> What ASIC are you using ? I also tested with
> gfx8 ASIC and haven't observed any issues with resume. Did you update the
> firmware for this ASIC to latest #

The GPU is an RX460 "POLARIS11 0x1002:0x67EF 0x1682:0x9460 0xCF",
with the latest firmware from the kernel git, you can see the
details from https://bugs.freedesktop.org/attachment.cgi?id=140383
uploaded earlier.

-- 
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

[PATCH] drm/nouveau: Set DRIVER_ATOMIC cap earlier to fix debugfs

Currently nouveau doesn't actually expose the state debugfs file that's
usually provided for any modesetting driver that supports atomic, even
if nouveau is loaded with atomic=1. This is due to the fact that the
standard debugfs files that DRM creates for atomic drivers is called
when drm_get_pci_dev() is called from nouveau_drm.c. This happens well
before we've initialized the display core, which is currently
responsible for setting the DRIVER_ATOMIC cap.

So, move the atomic option into nouveau_drm.c and just add the
DRIVER_ATOMIC cap whenever it's enabled on the kernel commandline. This
shouldn't cause any actual issues, as the atomic ioctl will still fail
as expected even if the display core doesn't disable it until later in
the init sequence. This also provides the added benefit of being able to
use the state debugfs file to check the current display state even if
clients aren't allowed to modify it through anything other than the
legacy ioctls.

Additionally, disable the DRIVER_ATOMIC cap in nv04's display core, as
this was already disabled there previously.

Signed-off-by: Lyude Paul 
Cc: sta...@vger.kernel.org
---
 drivers/gpu/drm/nouveau/dispnv04/disp.c | 3 +++
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 --
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 7 +++
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c 
b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 501d2d290e9c..70dce544984e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -55,6 +55,9 @@ nv04_display_create(struct drm_device *dev)
nouveau_display(dev)->init = nv04_display_init;
nouveau_display(dev)->fini = nv04_display_fini;
 
+   /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */
+   dev->driver->driver_features &= ~DRIVER_ATOMIC;
+
nouveau_hw_save_vga_fonts(dev, 1);
 
nv04_crtc_create(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 9382e99a0bc7..d9da69c83ae7 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2126,10 +2126,6 @@ nv50_display_destroy(struct drm_device *dev)
kfree(disp);
 }
 
-MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
-static int nouveau_atomic = 0;
-module_param_named(atomic, nouveau_atomic, int, 0400);
-
 int
 nv50_display_create(struct drm_device *dev)
 {
@@ -2154,8 +2150,6 @@ nv50_display_create(struct drm_device *dev)
disp->disp = _display(dev)->disp;
dev->mode_config.funcs = _disp_func;
dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP;
-   if (nouveau_atomic)
-   dev->driver->driver_features |= DRIVER_ATOMIC;
 
/* small shared memory area we use for notifiers and semaphores */
ret = nouveau_bo_new(>client, 4096, 0x1000, TTM_PL_FLAG_VRAM,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 775443c9af94..0452b18d36b9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -81,6 +81,10 @@ MODULE_PARM_DESC(modeset, "enable driver (default: auto, "
 int nouveau_modeset = -1;
 module_param_named(modeset, nouveau_modeset, int, 0400);
 
+MODULE_PARM_DESC(atomic, "Expose atomic ioctl (default: disabled)");
+static int nouveau_atomic = 0;
+module_param_named(atomic, nouveau_atomic, int, 0400);
+
 MODULE_PARM_DESC(runpm, "disable (0), force enable (1), optimus only default 
(-1)");
 static int nouveau_runtime_pm = -1;
 module_param_named(runpm, nouveau_runtime_pm, int, 0400);
@@ -509,6 +513,9 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
 
pci_set_master(pdev);
 
+   if (nouveau_atomic)
+   driver_pci.driver_features |= DRIVER_ATOMIC;
+
ret = drm_get_pci_dev(pdev, pent, _pci);
if (ret) {
nvkm_device_del();
-- 
2.17.1

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

Re: [PATCH] drm/writeback: Fix the "overview" section of the doc

2018-07-03 Thread Boris Brezillon

On Tue, 3 Jul 2018 19:44:00 +0200
Boris Brezillon  wrote:

> On Tue,  3 Jul 2018 19:40:46 +0200
> Boris Brezillon  wrote:
> 
> > Fix the bullet list declaration in the overview section.
> > 
> > Signed-off-by: Boris Brezillon   
> 
> Forgot to add:
> 
> Reported-by: Daniel Vetter 

And

Fixes: 935774cd71fe ("drm: Add writeback connector type")

is missing too.

> 
> > ---
> >  drivers/gpu/drm/drm_writeback.c | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_writeback.c 
> > b/drivers/gpu/drm/drm_writeback.c
> > index 827395071f0b..69e7a63cfcc3 100644
> > --- a/drivers/gpu/drm/drm_writeback.c
> > +++ b/drivers/gpu/drm/drm_writeback.c
> > @@ -22,10 +22,13 @@
> >   * Writeback connectors are used to expose hardware which can write the 
> > output
> >   * from a CRTC to a memory buffer. They are used and act similarly to other
> >   * types of connectors, with some important differences:
> > - *  - Writeback connectors don't provide a way to output visually to the 
> > user.
> > - *  - Writeback connectors should always report as "disconnected" (so that
> > - *clients which don't understand them will ignore them).
> > - *  - Writeback connectors don't have EDID.
> > + *
> > + * * Writeback connectors don't provide a way to output visually to the 
> > user.
> > + *
> > + * * Writeback connectors should always report as "disconnected" (so that
> > + *   clients which don't understand them will ignore them).
> > + *
> > + * * Writeback connectors don't have EDID.
> >   *
> >   * A framebuffer may only be attached to a writeback connector when the
> >   * connector is attached to a CRTC. The WRITEBACK_FB_ID property which 
> > sets the  
> 

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

[PATCH -next 15/15] drm/vmwgfx: Remove an obsolete __le32 conversion

We've long ago given up on enforcing the device format is always little
endian, so remove a leftover conversion.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index f2af53613803..e90f8d39de53 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -1072,7 +1072,7 @@ static int vmw_gb_surface_create(struct vmw_resource *res)
cmd2->header.size = cmd_len;
cmd2->body.sid = srf->res.id;
cmd2->body.surfaceFlags = srf->flags;
-   cmd2->body.format = cpu_to_le32(srf->format);
+   cmd2->body.format = srf->format;
cmd2->body.numMipLevels = srf->mip_levels[0];
cmd2->body.multisampleCount = srf->multisample_count;
cmd2->body.autogenFilter = srf->autogen_filter;
@@ -1085,7 +1085,7 @@ static int vmw_gb_surface_create(struct vmw_resource *res)
cmd->header.size = cmd_len;
cmd->body.sid = srf->res.id;
cmd->body.surfaceFlags = srf->flags;
-   cmd->body.format = cpu_to_le32(srf->format);
+   cmd->body.format = srf->format;
cmd->body.numMipLevels = srf->mip_levels[0];
cmd->body.multisampleCount = srf->multisample_count;
cmd->body.autogenFilter = srf->autogen_filter;
-- 
2.18.0.rc1

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

[PATCH -next 10/15] drm/vmwgfx: Use a mutex to protect gui positioning in vmw_display_unit

From: Deepak Rawat 

To avoid race condition between update_layout ioctl and modeset ioctl
for access to gui_x/y positioning added a new mutex
requested_layout_mutex.

Also used drm_for_each_connector_iter to iterate over connector list.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |  9 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 38 -
 3 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 4f18304226bc..45dfff7733d6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -644,6 +644,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
mutex_init(_priv->cmdbuf_mutex);
mutex_init(_priv->release_mutex);
mutex_init(_priv->binding_mutex);
+   mutex_init(_priv->requested_layout_mutex);
mutex_init(_priv->global_kms_state_mutex);
rwlock_init(_priv->resource_lock);
ttm_lock_init(_priv->reservation_sem);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 769d72fabb56..a38318c3efe4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -411,6 +411,15 @@ struct vmw_private {
 
uint32_t num_displays;
 
+   /*
+* Currently requested_layout_mutex is used to protect the gui
+* positionig state in display unit. With that use case currently this
+* mutex is only taken during layout ioctl and atomic check_modeset.
+* Other display unit state can be protected with this mutex but that
+* needs careful consideration.
+*/
+   struct mutex requested_layout_mutex;
+
/*
 * Framebuffer info.
 */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index f0ae0b2ee2e6..a592d10e5c76 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1577,6 +1577,7 @@ static int vmw_kms_check_display_memory(struct drm_device 
*dev,
 static int vmw_kms_check_topology(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
+   struct vmw_private *dev_priv = vmw_priv(dev);
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_rect *rects;
struct drm_crtc *crtc;
@@ -1588,6 +1589,8 @@ static int vmw_kms_check_topology(struct drm_device *dev,
if (!rects)
return -ENOMEM;
 
+   mutex_lock(_priv->requested_layout_mutex);
+
drm_for_each_crtc(crtc, dev) {
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct drm_crtc_state *crtc_state = crtc->state;
@@ -1595,10 +1598,6 @@ static int vmw_kms_check_topology(struct drm_device *dev,
i = drm_crtc_index(crtc);
 
if (crtc_state && crtc_state->enable) {
-   /*
-* There could be a race condition with update of gui_x/
-* gui_y. Those are protected by dev->mode_config.mutex.
-*/
rects[i].x1 = du->gui_x;
rects[i].y1 = du->gui_y;
rects[i].x2 = du->gui_x + crtc_state->mode.hdisplay;
@@ -1636,6 +1635,7 @@ static int vmw_kms_check_topology(struct drm_device *dev,
   rects);
 
 clean:
+   mutex_unlock(_priv->requested_layout_mutex);
kfree(rects);
return ret;
 }
@@ -1987,10 +1987,14 @@ static int vmw_du_update_layout(struct vmw_private 
*dev_priv,
struct drm_device *dev = dev_priv->dev;
struct vmw_display_unit *du;
struct drm_connector *con;
+   struct drm_connector_list_iter conn_iter;
 
-   mutex_lock(>mode_config.mutex);
-
-   list_for_each_entry(con, >mode_config.connector_list, head) {
+   /*
+* Currently only gui_x/y is protected with requested_layout_mutex.
+*/
+   mutex_lock(_priv->requested_layout_mutex);
+   drm_connector_list_iter_begin(dev, _iter);
+   drm_for_each_connector_iter(con, _iter) {
du = vmw_connector_to_du(con);
if (num_rects > du->unit) {
du->pref_width = drm_rect_width([du->unit]);
@@ -1998,6 +2002,21 @@ static int vmw_du_update_layout(struct vmw_private 
*dev_priv,
du->pref_active = true;
du->gui_x = rects[du->unit].x1;
du->gui_y = rects[du->unit].y1;
+   } else {
+   du->pref_width = 800;
+   du->pref_height = 600;
+   du->pref_active = false;
+   du->gui_x = 0;
+   du->gui_y = 0;
+

[PATCH -next 14/15] drm/vmwgfx: Fix host message module function declarations

Make the host message module function declarations similar to the other
declarations in vmwgfx_drv.h and include the header in vmwgfx_msg.c

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 11 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c |  1 +
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index a38318c3efe4..a3a0826958a1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1230,6 +1230,11 @@ int vmw_bo_cpu_blit(struct ttm_buffer_object *dst,
u32 w, u32 h,
struct vmw_diff_cpy *diff);
 
+/* Host messaging -vmwgfx_msg.c: */
+int vmw_host_get_guestinfo(const char *guest_info_param,
+  char *buffer, size_t *length);
+int vmw_host_log(const char *log);
+
 /**
  * Inline helper functions
  */
@@ -1309,10 +1314,4 @@ static inline void vmw_mmio_write(u32 value, u32 *addr)
 {
WRITE_ONCE(*addr, value);
 }
-
-/**
- * Add vmw_msg module function
- */
-extern int vmw_host_log(const char *log);
-
 #endif
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index a72268e97042..3549e6bd4178 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include "vmwgfx_drv.h"
 #include "vmwgfx_msg.h"
 
 
-- 
2.18.0.rc1

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

[PATCH -next 09/15] drm/vmwgfx: Remove primary memory validation against mode while creating fb

From: Deepak Rawat 

This validation is not required because user-space will send create_fb
request once the memory is allocated. This check should be performed
during mode-setting.

Signed-off-by: Deepak Rawat 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 3605ac1702c2..f0ae0b2ee2e6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1433,19 +1433,6 @@ static struct drm_framebuffer *vmw_kms_fb_create(struct 
drm_device *dev,
struct ttm_base_object *user_obj;
int ret;
 
-   /**
-* This code should be conditioned on Screen Objects not being used.
-* If screen objects are used, we can allocate a GMR to hold the
-* requested framebuffer.
-*/
-
-   if (!vmw_kms_validate_mode_vram(dev_priv,
-   mode_cmd->pitches[0],
-   mode_cmd->height)) {
-   DRM_ERROR("Requested mode exceed bounding box limit.\n");
-   return ERR_PTR(-ENOMEM);
-   }
-
/*
 * Take a reference on the user object of the resource
 * backing the kms fb. This ensures that user-space handle
-- 
2.18.0.rc1

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

[Bug 200387] amdgpu uses unusually high memory

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

--- Comment #25 from phoenix (fe...@feldspaten.org) ---
Created attachment 277153
  --> https://bugzilla.kernel.org/attachment.cgi?id=277153=edit
Memor usage measurements for different programs using Kernel 4.9.111 and
4.15.0-24

Ok, I've tested the issue using Kernel 4.15.0-24-generic (Shipped with Ubuntu
Mate) using the amdgpu driver and a 4.9.111 Kernel using the amdgpu-pro driver
(17.40).

Sadly building the amdgpu-pro driver for Kernel linux-4.14.53 failed, so I
couldn't test that one.

The issue occurs also in the 4.15.0-24-generic Kernel, while the 4.9.111 Kernel
has significantly lower main memory requirements using Cities Skylines.

Also I found out, that neither the output of mstat nor proc shows significant
differences in the processes between the Kernel versions. So as of now the only
accessible metric for measuring the memory usage is to look at the output for
'free'.


In addition I could observe the same memory issue (but without a system freeze)
in Civilization Beyond earth using the above mentioned Kernel versions. That
program is more suitable than a rather low-resource program like Stardew
Valley.

Find attached the text file MemUsage.txt with my current measurements.


Attaching Valgrind to a Steam Game is kind of non-trivial, do you still think
that this gives us some meaningful insights? I can work that out, but fear that
this soon goes beyond the scopes of my available time, still can give it a
shot.

-- 
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

[PATCH -next 12/15] drm/vmwgfx: Improve on host message error messages

Make sure the error messages are a bit more descriptive, so that
a log reader may understand what's gone wrong.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
index 21d746bdc922..a72268e97042 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
@@ -234,7 +234,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void 
**msg,
 
if ((HIGH_WORD(ecx) & MESSAGE_STATUS_SUCCESS) == 0 ||
(HIGH_WORD(ecx) & MESSAGE_STATUS_HB) == 0) {
-   DRM_ERROR("Failed to get reply size\n");
+   DRM_ERROR("Failed to get reply size for host 
message.\n");
return -EINVAL;
}
 
@@ -245,7 +245,7 @@ static int vmw_recv_msg(struct rpc_channel *channel, void 
**msg,
reply_len = ebx;
reply = kzalloc(reply_len + 1, GFP_KERNEL);
if (!reply) {
-   DRM_ERROR("Cannot allocate memory for reply\n");
+   DRM_ERROR("Cannot allocate memory for host message 
reply.\n");
return -ENOMEM;
}
 
@@ -338,7 +338,8 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
 
msg = kasprintf(GFP_KERNEL, "info-get %s", guest_info_param);
if (!msg) {
-   DRM_ERROR("Cannot allocate memory to get %s", guest_info_param);
+   DRM_ERROR("Cannot allocate memory to get guest info \"%s\".",
+ guest_info_param);
return -ENOMEM;
}
 
@@ -374,7 +375,7 @@ int vmw_host_get_guestinfo(const char *guest_info_param,
 out_open:
*length = 0;
kfree(msg);
-   DRM_ERROR("Failed to get %s", guest_info_param);
+   DRM_ERROR("Failed to get guest info \"%s\".", guest_info_param);
 
return -EINVAL;
 }
@@ -403,7 +404,7 @@ int vmw_host_log(const char *log)
 
msg = kasprintf(GFP_KERNEL, "log %s", log);
if (!msg) {
-   DRM_ERROR("Cannot allocate memory for log message\n");
+   DRM_ERROR("Cannot allocate memory for host log message.\n");
return -ENOMEM;
}
 
@@ -422,7 +423,7 @@ int vmw_host_log(const char *log)
vmw_close_channel();
 out_open:
kfree(msg);
-   DRM_ERROR("Failed to send log\n");
+   DRM_ERROR("Failed to send host log message.\n");
 
return -EINVAL;
 }
-- 
2.18.0.rc1

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

[PATCH -next 13/15] drm/vmwgfx: Reorganize the fence wait loop

Reorganize the fence wait loop somewhat to make it look more like the
examples in set_current_state() kerneldoc, and add some code comments.

Also if we're about to time out, make sure we check again whether the fence
is actually signaled.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 38 ++-
 1 file changed, 26 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 9ed544f8958f..ea41d74d8341 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -175,7 +175,6 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr, 
signed long timeout)
struct vmw_private *dev_priv = fman->dev_priv;
struct vmwgfx_wait_cb cb;
long ret = timeout;
-   unsigned long irq_flags;
 
if (likely(vmw_fence_obj_signaled(fence)))
return timeout;
@@ -183,7 +182,7 @@ static long vmw_fence_wait(struct dma_fence *f, bool intr, 
signed long timeout)
vmw_fifo_ping_host(dev_priv, SVGA_SYNC_GENERIC);
vmw_seqno_waiter_add(dev_priv);
 
-   spin_lock_irqsave(f->lock, irq_flags);
+   spin_lock(f->lock);
 
if (intr && signal_pending(current)) {
ret = -ERESTARTSYS;
@@ -194,30 +193,45 @@ static long vmw_fence_wait(struct dma_fence *f, bool 
intr, signed long timeout)
cb.task = current;
list_add(, >cb_list);
 
-   while (ret > 0) {
+   for (;;) {
__vmw_fences_update(fman);
-   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
-   break;
 
+   /*
+* We can use the barrier free __set_current_state() since
+* DMA_FENCE_FLAG_SIGNALED_BIT + wakeup is protected by the
+* fence spinlock.
+*/
if (intr)
__set_current_state(TASK_INTERRUPTIBLE);
else
__set_current_state(TASK_UNINTERRUPTIBLE);
-   spin_unlock_irqrestore(f->lock, irq_flags);
 
-   ret = schedule_timeout(ret);
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags)) {
+   if (ret == 0 && timeout > 0)
+   ret = 1;
+   break;
+   }
 
-   spin_lock_irqsave(f->lock, irq_flags);
-   if (ret > 0 && intr && signal_pending(current))
+   if (intr && signal_pending(current)) {
ret = -ERESTARTSYS;
-   }
+   break;
+   }
 
+   if (ret == 0)
+   break;
+
+   spin_unlock(f->lock);
+
+   ret = schedule_timeout(ret);
+
+   spin_lock(f->lock);
+   }
+   __set_current_state(TASK_RUNNING);
if (!list_empty())
list_del();
-   __set_current_state(TASK_RUNNING);
 
 out:
-   spin_unlock_irqrestore(f->lock, irq_flags);
+   spin_unlock(f->lock);
 
vmw_seqno_waiter_remove(dev_priv);
 
-- 
2.18.0.rc1

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

[PATCH -next 06/15] drm/vmwgfx: Perform topology validation during atomic modeset.

From: Deepak Rawat 

This patch adds display (primary) memory validation during modeset
check. Display memory validation are applicable to both SOU and STDU,
so allow both display unit to undergo this check.

Also added check for SVGA_CAP_NO_BB_RESTRICTION capability which lifts
bounding box restriction for STDU.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 .../gpu/drm/vmwgfx/device_include/svga_reg.h  |  31 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   | 184 ++
 2 files changed, 177 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/device_include/svga_reg.h 
b/drivers/gpu/drm/vmwgfx/device_include/svga_reg.h
index 88e72bf9a534..cdd48a3763db 100644
--- a/drivers/gpu/drm/vmwgfx/device_include/svga_reg.h
+++ b/drivers/gpu/drm/vmwgfx/device_include/svga_reg.h
@@ -672,8 +672,34 @@ SVGASignedPoint;
  * SVGA_CAP_GBOBJECTS --
  *Enable guest-backed objects and surfaces.
  *
- * SVGA_CAP_CMD_BUFFERS_3 --
- *Enable support for command buffers in a mob.
+ * SVGA_CAP_DX --
+ *Enable support for DX commands, and command buffers in a mob.
+ *
+ * SVGA_CAP_HP_CMD_QUEUE --
+ *Enable support for the high priority command queue, and the
+ *ScreenCopy command.
+ *
+ * SVGA_CAP_NO_BB_RESTRICTION --
+ *Allow ScreenTargets to be defined without regard to the 32-bpp
+ *bounding-box memory restrictions. ie:
+ *
+ *The summed memory usage of all screens (assuming they were defined as
+ *32-bpp) must always be less than the value of the
+ *SVGA_REG_MAX_PRIMARY_MEM register.
+ *
+ *If this cap is not present, the 32-bpp bounding box around all screens
+ *must additionally be under the value of the SVGA_REG_MAX_PRIMARY_MEM
+ *register.
+ *
+ *If the cap is present, the bounding box restriction is lifted (and only
+ *the screen-sum limit applies).
+ *
+ *(Note that this is a slight lie... there is still a sanity limit on any
+ * dimension of the topology to be less than SVGA_SCREEN_ROOT_LIMIT, even
+ * when SVGA_CAP_NO_BB_RESTRICTION is present, but that should be
+ * large enough to express any possible topology without holes between
+ * monitors.)
+ *
  */
 
 #define SVGA_CAP_NONE   0x
@@ -699,6 +725,7 @@ SVGASignedPoint;
 #define SVGA_CAP_GBOBJECTS  0x0800
 #define SVGA_CAP_DX 0x1000
 #define SVGA_CAP_HP_CMD_QUEUE   0x2000
+#define SVGA_CAP_NO_BB_RESTRICTION  0x4000
 
 #define SVGA_CAP_CMD_RESERVED   0x8000
 
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 6b8541f9215d..a7c9a017fc3c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1507,66 +1507,178 @@ static struct drm_framebuffer 
*vmw_kms_fb_create(struct drm_device *dev,
return >base;
 }
 
+/**
+ * vmw_kms_check_display_memory - Validates display memory required for a
+ * topology
+ * @dev: DRM device
+ * @num_rects: number of drm_rect in rects
+ * @rects: array of drm_rect representing the topology to validate indexed by
+ * crtc index.
+ *
+ * Returns:
+ * 0 on success otherwise negative error code
+ */
+static int vmw_kms_check_display_memory(struct drm_device *dev,
+   uint32_t num_rects,
+   struct drm_rect *rects)
+{
+   struct vmw_private *dev_priv = vmw_priv(dev);
+   struct drm_mode_config *mode_config = >mode_config;
+   struct drm_rect bounding_box = {0};
+   u64 total_pixels = 0, pixel_mem, bb_mem;
+   int i;
+
+   for (i = 0; i < num_rects; i++) {
+   /*
+* Currently this check is limiting the topology within max
+* texture/screentarget size. This should change in future when
+* user-space support multiple fb with topology.
+*/
+   if (rects[i].x1 < 0 ||  rects[i].y1 < 0 ||
+   rects[i].x2 > mode_config->max_width ||
+   rects[i].y2 > mode_config->max_height) {
+   DRM_ERROR("Invalid GUI layout.\n");
+   return -EINVAL;
+   }
+
+   /* Bounding box upper left is at (0,0). */
+   if (rects[i].x2 > bounding_box.x2)
+   bounding_box.x2 = rects[i].x2;
+
+   if (rects[i].y2 > bounding_box.y2)
+   bounding_box.y2 = rects[i].y2;
+
+   total_pixels += (u64) drm_rect_width([i]) *
+   (u64) drm_rect_height([i]);
+   }
+
+   /* Virtual svga device primary limits are always in 32-bpp. */
+   pixel_mem = total_pixels * 4;
+
+   /*
+* For HV10 and below prim_bb_mem is vram size. When
+* SVGA_REG_MAX_PRIMARY_BOUNDING_BOX_MEM is not present vram size is
+* limit on primary bounding box
+*/
+   if (pixel_mem >

[PATCH -next 04/15] drm/vmwgfx: Use blocking buffer object reserves when evicting resources

Previously when evicting resources we were unconditionally calling
ttm_eu_reserve_buffers with a NULL ww acquire context. That meant all
buffer object reserves were done using trylock semantics.
That makes sense when evicting during resource validation, because then
there already are a number of buffers reserved and using waiting locks
would cause lockdep errors.

That's not the case when unconditionally evicting all resources as part
of driver takedown or hibernation, so in that code path, make sure
we have a ww acquire context to get waiting lock buffer object reserve
semantics.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 29 
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 6d2cad744f5d..3b2d9b6c50fc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -433,6 +433,7 @@ void vmw_resource_unreserve(struct vmw_resource *res,
  * for a resource and in that case, allocate
  * one, reserve and validate it.
  *
+ * @ticket: The ww aqcquire context to use, or NULL if trylocking.
  * @res:The resource for which to allocate a backup buffer.
  * @interruptible:  Whether any sleeps during allocation should be
  *  performed while interruptible.
@@ -440,7 +441,8 @@ void vmw_resource_unreserve(struct vmw_resource *res,
  *  reserved and validated backup buffer.
  */
 static int
-vmw_resource_check_buffer(struct vmw_resource *res,
+vmw_resource_check_buffer(struct ww_acquire_ctx *ticket,
+ struct vmw_resource *res,
  bool interruptible,
  struct ttm_validate_buffer *val_buf)
 {
@@ -459,7 +461,7 @@ vmw_resource_check_buffer(struct vmw_resource *res,
val_buf->bo = ttm_bo_reference(>backup->base);
val_buf->shared = false;
list_add_tail(_buf->head, _list);
-   ret = ttm_eu_reserve_buffers(NULL, _list, interruptible, NULL);
+   ret = ttm_eu_reserve_buffers(ticket, _list, interruptible, NULL);
if (unlikely(ret != 0))
goto out_no_reserve;
 
@@ -477,7 +479,7 @@ vmw_resource_check_buffer(struct vmw_resource *res,
return 0;
 
 out_no_validate:
-   ttm_eu_backoff_reservation(NULL, _list);
+   ttm_eu_backoff_reservation(ticket, _list);
 out_no_reserve:
ttm_bo_unref(_buf->bo);
if (backup_dirty)
@@ -524,10 +526,12 @@ int vmw_resource_reserve(struct vmw_resource *res, bool 
interruptible,
  * vmw_resource_backoff_reservation - Unreserve and unreference a
  *backup buffer
  *.
+ * @ticket: The ww acquire ctx used for reservation.
  * @val_buf:Backup buffer information.
  */
 static void
-vmw_resource_backoff_reservation(struct ttm_validate_buffer *val_buf)
+vmw_resource_backoff_reservation(struct ww_acquire_ctx *ticket,
+struct ttm_validate_buffer *val_buf)
 {
struct list_head val_list;
 
@@ -536,7 +540,7 @@ vmw_resource_backoff_reservation(struct ttm_validate_buffer 
*val_buf)
 
INIT_LIST_HEAD(_list);
list_add_tail(_buf->head, _list);
-   ttm_eu_backoff_reservation(NULL, _list);
+   ttm_eu_backoff_reservation(ticket, _list);
ttm_bo_unref(_buf->bo);
 }
 
@@ -544,10 +548,12 @@ vmw_resource_backoff_reservation(struct 
ttm_validate_buffer *val_buf)
  * vmw_resource_do_evict - Evict a resource, and transfer its data
  * to a backup buffer.
  *
+ * @ticket: The ww acquire ticket to use, or NULL if trylocking.
  * @res:The resource to evict.
  * @interruptible:  Whether to wait interruptible.
  */
-static int vmw_resource_do_evict(struct vmw_resource *res, bool interruptible)
+static int vmw_resource_do_evict(struct ww_acquire_ctx *ticket,
+struct vmw_resource *res, bool interruptible)
 {
struct ttm_validate_buffer val_buf;
const struct vmw_res_func *func = res->func;
@@ -557,7 +563,7 @@ static int vmw_resource_do_evict(struct vmw_resource *res, 
bool interruptible)
 
val_buf.bo = NULL;
val_buf.shared = false;
-   ret = vmw_resource_check_buffer(res, interruptible, _buf);
+   ret = vmw_resource_check_buffer(ticket, res, interruptible, _buf);
if (unlikely(ret != 0))
return ret;
 
@@ -572,7 +578,7 @@ static int vmw_resource_do_evict(struct vmw_resource *res, 
bool interruptible)
res->backup_dirty = true;
res->res_dirty = false;
 out_no_unbind:
-   vmw_resource_backoff_reservation(_buf);
+   vmw_resource_backoff_reservation(ticket, _buf);
 
return ret;
 }
@@ -626,7 +632,8 @@ int vmw_resource_validate(struct vmw_resource

[PATCH -next 11/15] drm/vmwgfx: Add gui_x/y to vmw_connector_state

From: Deepak Rawat 

As gui_x/y positioning is display unit is protected by
requested_layout_mutex adding vmw_connector_state copy of the same and
modeset commit will refer the state copy to sync with modeset_check
state.

v2: Tested with CONFIG_PROVE_LOCKING enabled.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 37 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  | 18 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 38 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 29 +
 4 files changed, 86 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a592d10e5c76..0fb363458ab5 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1609,26 +1609,43 @@ static int vmw_kms_check_topology(struct drm_device 
*dev,
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
  new_crtc_state, i) {
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct vmw_connector_state *vmw_conn_state;
 
if (!new_crtc_state->enable && old_crtc_state->enable) {
rects[i].x1 = 0;
rects[i].y1 = 0;
rects[i].x2 = 0;
rects[i].y2 = 0;
+   continue;
}
 
-   if (new_crtc_state->enable) {
-   /* If display unit is not active cannot enable CRTC */
-   if (!du->pref_active) {
-   ret = -EINVAL;
-   goto clean;
-   }
+   if (!du->pref_active) {
+   ret = -EINVAL;
+   goto clean;
+   }
 
-   rects[i].x1 = du->gui_x;
-   rects[i].y1 = du->gui_y;
-   rects[i].x2 = du->gui_x + new_crtc_state->mode.hdisplay;
-   rects[i].y2 = du->gui_y + new_crtc_state->mode.vdisplay;
+   /*
+* For vmwgfx each crtc has only one connector attached and it
+* is not changed so don't really need to check the
+* crtc->connector_mask and iterate over it.
+*/
+   connector = >connector;
+   conn_state = drm_atomic_get_connector_state(state, connector);
+   if (IS_ERR(conn_state)) {
+   ret = PTR_ERR(conn_state);
+   goto clean;
}
+
+   vmw_conn_state = vmw_connector_state_to_vcs(conn_state);
+   vmw_conn_state->gui_x = du->gui_x;
+   vmw_conn_state->gui_y = du->gui_y;
+
+   rects[i].x1 = du->gui_x;
+   rects[i].y1 = du->gui_y;
+   rects[i].x2 = du->gui_x + new_crtc_state->mode.hdisplay;
+   rects[i].y2 = du->gui_y + new_crtc_state->mode.vdisplay;
}
 
ret = vmw_kms_check_display_memory(dev, dev->mode_config.num_crtc,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index ff1caed38f94..1f2b01862652 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -192,6 +192,24 @@ struct vmw_connector_state {
struct drm_connector_state base;
 
bool is_implicit;
+
+   /**
+* @gui_x:
+*
+* vmwgfx connector property representing the x position of this display
+* unit (connector is synonymous to display unit) in overall topology.
+* This is what the device expect as xRoot while creating screen.
+*/
+   int gui_x;
+
+   /**
+* @gui_y:
+*
+* vmwgfx connector property representing the y position of this display
+* unit (connector is synonymous to display unit) in overall topology.
+* This is what the device expect as yRoot while creating screen.
+*/
+   int gui_y;
 };
 
 /**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 74dfd4621b7e..df21d5a6f84a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -109,7 +109,7 @@ static void vmw_sou_crtc_destroy(struct drm_crtc *crtc)
  */
 static int vmw_sou_fifo_create(struct vmw_private *dev_priv,
   struct vmw_screen_object_unit *sou,
-  uint32_t x, uint32_t y,
+  int x, int y,
   struct drm_display_mode *mode)
 {
size_t fifo_size;
@@ -139,13 +139,8 @@ static int vmw_sou_fifo_create(struct vmw_private 
*dev_priv,

[PATCH -next 02/15] drm/vmwgfx: Move buffer object related code to vmwgfx_bo.c

It makes more sense to have all the buffer object related code in
a single file rather than splitting it up between the resource code
and buffer object pinning utilities.

Place all buffer object related code in vmwgfx_bo.c. Fix up headers
and export resource functionality when needed in the buffer object
code.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 816 -
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c|   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c|   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  73 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|   2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c|   6 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c   | 640 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c |   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c|   4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c |   4 +-
 11 files changed, 851 insertions(+), 708 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index f26f658cccdb..d950244798fe 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -1,6 +1,6 @@
 /**
  *
- * Copyright © 2011-2015 VMware, Inc., Palo Alto, CA., USA
+ * Copyright © 2011-2018 VMware, Inc., Palo Alto, CA., USA
  * All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -29,6 +29,51 @@
 
 #include 
 #include "vmwgfx_drv.h"
+#include "drm/ttm/ttm_object.h"
+
+
+/**
+ * struct vmw_user_buffer_object - User-space-visible buffer object
+ *
+ * @prime: The prime object providing user visibility.
+ * @vbo: The struct vmw_buffer_object
+ */
+struct vmw_user_buffer_object {
+   struct ttm_prime_object prime;
+   struct vmw_buffer_object vbo;
+};
+
+
+/**
+ * vmw_buffer_object - Convert a struct ttm_buffer_object to a struct
+ * vmw_buffer_object.
+ *
+ * @bo: Pointer to the TTM buffer object.
+ * Return: Pointer to the struct vmw_buffer_object embedding the
+ * TTM buffer object.
+ */
+static struct vmw_buffer_object *
+vmw_buffer_object(struct ttm_buffer_object *bo)
+{
+   return container_of(bo, struct vmw_buffer_object, base);
+}
+
+
+/**
+ * vmw_user_buffer_object - Convert a struct ttm_buffer_object to a struct
+ * vmw_user_buffer_object.
+ *
+ * @bo: Pointer to the TTM buffer object.
+ * Return: Pointer to the struct vmw_buffer_object embedding the TTM buffer
+ * object.
+ */
+static struct vmw_user_buffer_object *
+vmw_user_buffer_object(struct ttm_buffer_object *bo)
+{
+   struct vmw_buffer_object *vmw_bo = vmw_buffer_object(bo);
+
+   return container_of(vmw_bo, struct vmw_user_buffer_object, vbo);
+}
 
 
 /**
@@ -38,9 +83,8 @@
  * @buf:  DMA buffer to move.
  * @placement:  The placement to pin it.
  * @interruptible:  Use interruptible wait.
- *
- * Returns
- *  -ERESTARTSYS if interrupted by a signal.
+ * Return: Zero on success, Negative error code on failure. In particular
+ * -ERESTARTSYS if interrupted by a signal
  */
 int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
struct vmw_buffer_object *buf,
@@ -78,6 +122,7 @@ int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
return ret;
 }
 
+
 /**
  * vmw_bo_pin_in_vram_or_gmr - Move a buffer to vram or gmr.
  *
@@ -88,9 +133,8 @@ int vmw_bo_pin_in_placement(struct vmw_private *dev_priv,
  * @buf:  DMA buffer to move.
  * @pin:  Pin buffer if true.
  * @interruptible:  Use interruptible wait.
- *
- * Returns
- * -ERESTARTSYS if interrupted by a signal.
+ * Return: Zero on success, Negative error code on failure. In particular
+ * -ERESTARTSYS if interrupted by a signal
  */
 int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
  struct vmw_buffer_object *buf,
@@ -133,6 +177,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
return ret;
 }
 
+
 /**
  * vmw_bo_pin_in_vram - Move a buffer to vram.
  *
@@ -142,9 +187,8 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
  * @interruptible:  Use interruptible wait.
- *
- * Returns
- * -ERESTARTSYS if interrupted by a signal.
+ * Return: Zero on success, Negative error code on failure. In particular
+ * -ERESTARTSYS if interrupted by a signal
  */
 int vmw_bo_pin_in_vram(struct vmw_private *dev_priv,
   struct vmw_buffer_object *buf,
@@ -154,6 +198,7 @@ int vmw_bo_pin_in_vram(struct vmw_private *dev_priv,
   interruptible);
 }
 
+
 /**
  * vmw_bo_pin_in_start_of_vram - Move a buffer to start of vram.
  *
@@ -163,9 +208,8 @@ int vmw_bo_pin_in_vram(struct vmw_private *dev_priv,
  * @dev_priv:  Driver private.
  * @buf:

[PATCH -next 07/15] drm/vmwgfx: Use modeset display memory validation for layout ioctl

From: Deepak Rawat 

Call the same display memory validation function which is used by
modeset_check. This ensure consistency that kernel change preferred
mode/topology only if supported.

Also change the internal function to use drm_rect instead of
drm_vmw_rect.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 120 
 1 file changed, 51 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index a7c9a017fc3c..387bb39de839 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1968,13 +1968,15 @@ void vmw_disable_vblank(struct drm_device *dev, 
unsigned int pipe)
 {
 }
 
-
-/*
- * Small shared kms functions.
+/**
+ * vmw_du_update_layout - Update the display unit with topology from resolution
+ * plugin and generate DRM uevent
+ * @dev_priv: device private
+ * @num_rects: number of drm_rect in rects
+ * @rects: toplogy to update
  */
-
-static int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num,
-struct drm_vmw_rect *rects)
+static int vmw_du_update_layout(struct vmw_private *dev_priv,
+   unsigned int num_rects, struct drm_rect *rects)
 {
struct drm_device *dev = dev_priv->dev;
struct vmw_display_unit *du;
@@ -1982,26 +1984,14 @@ static int vmw_du_update_layout(struct vmw_private 
*dev_priv, unsigned num,
 
mutex_lock(>mode_config.mutex);
 
-#if 0
-   {
-   unsigned int i;
-
-   DRM_INFO("%s: new layout ", __func__);
-   for (i = 0; i < num; i++)
-   DRM_INFO("(%i, %i %ux%u) ", rects[i].x, rects[i].y,
-rects[i].w, rects[i].h);
-   DRM_INFO("\n");
-   }
-#endif
-
list_for_each_entry(con, >mode_config.connector_list, head) {
du = vmw_connector_to_du(con);
-   if (num > du->unit) {
-   du->pref_width = rects[du->unit].w;
-   du->pref_height = rects[du->unit].h;
+   if (num_rects > du->unit) {
+   du->pref_width = drm_rect_width([du->unit]);
+   du->pref_height = drm_rect_height([du->unit]);
du->pref_active = true;
-   du->gui_x = rects[du->unit].x;
-   du->gui_y = rects[du->unit].y;
+   du->gui_x = rects[du->unit].x1;
+   du->gui_y = rects[du->unit].y1;
drm_object_property_set_value
  (>base, dev->mode_config.suggested_x_property,
   du->gui_x);
@@ -2322,7 +2312,25 @@ vmw_du_connector_atomic_get_property(struct 
drm_connector *connector,
return 0;
 }
 
-
+/**
+ * vmw_kms_update_layout_ioctl - Handler for DRM_VMW_UPDATE_LAYOUT ioctl
+ * @dev: drm device for the ioctl
+ * @data: data pointer for the ioctl
+ * @file_priv: drm file for the ioctl call
+ *
+ * Update preferred topology of display unit as per ioctl request. The topology
+ * is expressed as array of drm_vmw_rect.
+ * e.g.
+ * [0 0 640 480] [640 0 800 600] [0 480 640 480]
+ *
+ * NOTE:
+ * The x and y offset (upper left) in drm_vmw_rect cannot be less than 0. 
Beside
+ * device limit on topology, x + w and y + h (lower right) cannot be greater
+ * than INT_MAX. So topology beyond these limits will return with error.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
 int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
@@ -2331,15 +2339,12 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, 
void *data,
(struct drm_vmw_update_layout_arg *)data;
void __user *user_rects;
struct drm_vmw_rect *rects;
+   struct drm_rect *drm_rects;
unsigned rects_size;
-   int ret;
-   int i;
-   u64 total_pixels = 0;
-   struct drm_mode_config *mode_config = >mode_config;
-   struct drm_vmw_rect bounding_box = {0};
+   int ret, i;
 
if (!arg->num_outputs) {
-   struct drm_vmw_rect def_rect = {0, 0, 800, 600};
+   struct drm_rect def_rect = {0, 0, 800, 600};
vmw_du_update_layout(dev_priv, 1, _rect);
return 0;
}
@@ -2358,52 +2363,29 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, 
void *data,
goto out_free;
}
 
-   for (i = 0; i < arg->num_outputs; ++i) {
-   if (rects[i].x < 0 ||
-   rects[i].y < 0 ||
-   rects[i].x + rects[i].w > mode_config->max_width ||
-   rects[i].y + rects[i].h > mode_config->max_height) {
-   DRM_ERROR("Invalid GUI layout.\n");
-   ret = -EINVAL;
-

[PATCH -next 08/15] drm/vmwgfx: Perform memory validations only when need full modeset.

From: Deepak Rawat 

For cases when full modeset is not requested like page-flip, skip
memory validation as the topology is not changed.

Signed-off-by: Deepak Rawat 
Reviewed-by: Thomas Hellstrom 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 387bb39de839..3605ac1702c2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1670,13 +1670,32 @@ static int
 vmw_kms_atomic_check_modeset(struct drm_device *dev,
 struct drm_atomic_state *state)
 {
-   int ret;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   bool need_modeset = false;
+   int i, ret;
 
ret = drm_atomic_helper_check(dev, state);
if (ret)
return ret;
 
-   return vmw_kms_check_topology(dev, state);
+   if (!state->allow_modeset)
+   return ret;
+
+   /*
+* Legacy path do not set allow_modeset properly like
+* @drm_atomic_helper_update_plane, This will result in unnecessary call
+* to vmw_kms_check_topology. So extra set of check.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   need_modeset = true;
+   }
+
+   if (need_modeset)
+   return vmw_kms_check_topology(dev, state);
+
+   return ret;
 }
 
 static const struct drm_mode_config_funcs vmw_kms_funcs = {
-- 
2.18.0.rc1

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

[PATCH -next 03/15] drm/vmwgfx: Optimize the buffer object swap_notify callback somewhat.

Only try to unmap cached maps when the buffer is moved into or out from
vram. Otherwise the underlying pages stay the same.

Also when unbinding resources from MOBs about to move, make sure we're
really moving out of MOB memory.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index d950244798fe..87204ff67c09 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -1105,16 +1105,18 @@ void vmw_bo_move_notify(struct ttm_buffer_object *bo,
vbo = container_of(bo, struct vmw_buffer_object, base);
 
/*
-* Kill any cached kernel maps before move. An optimization could
-* be to do this iff source or destination memory type is in VRAM.
+* Kill any cached kernel maps before move to or from VRAM.
+* With other types of moves, the underlying pages stay the same,
+* and the map can be kept.
 */
-   vmw_bo_unmap(vbo);
+   if (mem->mem_type == TTM_PL_VRAM || bo->mem.mem_type == TTM_PL_VRAM)
+   vmw_bo_unmap(vbo);
 
/*
 * If we're moving a backup MOB out of MOB placement, then make sure we
 * read back all resource content first, and unbind the MOB from
 * the resource.
 */
-   if (mem->mem_type != VMW_PL_MOB)
+   if (mem->mem_type != VMW_PL_MOB && bo->mem.mem_type == VMW_PL_MOB)
vmw_resource_unbind_list(vbo);
 }
-- 
2.18.0.rc1

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

[PATCH -next 00/15] vmwgfx cleanups and modesetting changes

A series of cleanups / reorganizations and modesetting changes that mostly
target atomic state validation.


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

[PATCH -next 05/15] drm/vmwgfx: Fix atomic mode set check

From: Sinclair Yeh 

vmw_kms_atomic_check_modeset() is currently checking config using the
legacy state, which is updated after a commit has happened.

This means vmw_kms_atomic_check_modeset() will reject an invalid config
on the next update rather than the current one.

Fix this by using the new states for config checking

Signed-off-by: Sinclair Yeh 
Reviewed-by: Deepak Rawat 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 40 +++--
 1 file changed, 26 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index e7a7a2e73bbf..6b8541f9215d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1526,33 +1526,45 @@ static int
 vmw_kms_atomic_check_modeset(struct drm_device *dev,
 struct drm_atomic_state *state)
 {
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *new_crtc_state;
+   struct drm_plane_state *new_plane_state;
+   struct drm_plane *plane;
struct drm_crtc *crtc;
struct vmw_private *dev_priv = vmw_priv(dev);
-   int i;
+   int i, ret, cpp = 0;
 
-   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
-   unsigned long requested_bb_mem = 0;
+   ret = drm_atomic_helper_check(dev, state);
 
-   if (dev_priv->active_display_unit == vmw_du_screen_target) {
-   struct drm_plane *plane = crtc->primary;
-   struct drm_plane_state *plane_state;
+   /* If this is not a STDU, then no more checking is necessary */
+   if (ret || dev_priv->active_display_unit != vmw_du_screen_target)
+   return ret;
 
-   plane_state = drm_atomic_get_new_plane_state(state, 
plane);
+   for_each_new_plane_in_state(state, plane, new_plane_state, i) {
+   if (new_plane_state->fb) {
+   int current_cpp = new_plane_state->fb->pitches[0] /
+ new_plane_state->fb->width;
 
-   if (plane_state && plane_state->fb) {
-   int cpp = plane_state->fb->format->cpp[0];
+   if (cpp == 0)
+   cpp = current_cpp;
+   else if (current_cpp != cpp)
+   return -EINVAL;
+   }
+   }
 
-   requested_bb_mem += crtc->mode.hdisplay * cpp *
-   crtc->mode.vdisplay;
-   }
+   for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+   unsigned long requested_bb_mem = 0;
+
+   if (drm_atomic_crtc_needs_modeset(new_crtc_state)) {
+   requested_bb_mem += new_crtc_state->mode.hdisplay *
+   new_crtc_state->mode.vdisplay *
+   cpp;
 
if (requested_bb_mem > dev_priv->prim_bb_mem)
return -EINVAL;
}
}
 
-   return drm_atomic_helper_check(dev, state);
+   return ret;
 }
 
 static const struct drm_mode_config_funcs vmw_kms_funcs = {
-- 
2.18.0.rc1

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

Re: [PATCH] drm/bridge: adv7511: Reset registers on hotplug

2018-07-03 Thread Sean Paul

On Tue, Jul 3, 2018 at 2:58 PM Rob Clark  wrote:
>
> On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul  wrote:
> > The bridge loses its hw state when the cable is unplugged. If we detect
> > this case in the hpd handler, reset its state.
> >
> > Reported-by: Rob Clark 
> > Signed-off-by: Sean Paul 
>
> Tested-by: Rob Clark 
>
> > ---
> > This is the follow-up to "drm/msm: Disable mdp5 crtc when there are no
> > active planes". I incorrectly assumed the modeset was required from the
> > msm side, but Rob pointed out that he thought it might be a bridge
> > issue.
>
> To elaborate, this is an atomic userspace (weston), when it sees the
> display disconnected, it removes the planes from the CRTC but does not
> disable the CRTC.  So drm/msm sets up the LM to scanout a solid color,
> and leaves the encoder and dsi cranking along happily.  When
> replugging the display, the atomic helpers see the CRTC is still
> active and (correctly) doesn't do a full modeset.  So the bridge is
> not re-configured/re-enabled.
>
> Arguably this perhaps isn't what weston *wanted* to do, but in the end
> the bug is in the bridge.
>

Fwiw, I've also filed
https://gitlab.freedesktop.org/wayland/weston/issues/123 against
weston so they can save some power on disconnected displays. But yeah,
multiple pieces all working against each other here.

Sean

> We could possibly set the connector link_status to BAD as an
> alternative.  But at least the build of weston I'm using atm doesn't
> handle the link_status propery, this approach requires each atomic
> userspace to handle this case.  Compared to Sean's approach which is
> transparent to userspace, which seems attractive.
>
> BR,
> -R
>
> >
> >  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > index 73021b388e12..dd3ff2f2cdce 100644
> > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> > @@ -429,6 +429,18 @@ static void adv7511_hpd_work(struct work_struct *work)
> > else
> > status = connector_status_disconnected;
> >
> > +   /*
> > +* The bridge resets its registers on unplug. So when we get a plug
> > +* event and we're already supposed to be powered, cycle the bridge 
> > to
> > +* restore its state.
> > +*/
> > +   if (status == connector_status_connected &&
> > +   adv7511->connector.status == connector_status_disconnected &&
> > +   adv7511->powered) {
> > +   regcache_mark_dirty(adv7511->regmap);
> > +   adv7511_power_on(adv7511);
> > +   }
> > +
> > if (adv7511->connector.status != status) {
> > adv7511->connector.status = status;
> > if (status == connector_status_disconnected)
> > --
> > Sean Paul, Software Engineer, Google / Chromium OS
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: adv7511: Reset registers on hotplug

2018-07-03 Thread Rob Clark

On Tue, Jul 3, 2018 at 12:56 PM, Sean Paul  wrote:
> The bridge loses its hw state when the cable is unplugged. If we detect
> this case in the hpd handler, reset its state.
>
> Reported-by: Rob Clark 
> Signed-off-by: Sean Paul 

Tested-by: Rob Clark 

> ---
> This is the follow-up to "drm/msm: Disable mdp5 crtc when there are no
> active planes". I incorrectly assumed the modeset was required from the
> msm side, but Rob pointed out that he thought it might be a bridge
> issue.

To elaborate, this is an atomic userspace (weston), when it sees the
display disconnected, it removes the planes from the CRTC but does not
disable the CRTC.  So drm/msm sets up the LM to scanout a solid color,
and leaves the encoder and dsi cranking along happily.  When
replugging the display, the atomic helpers see the CRTC is still
active and (correctly) doesn't do a full modeset.  So the bridge is
not re-configured/re-enabled.

Arguably this perhaps isn't what weston *wanted* to do, but in the end
the bug is in the bridge.

We could possibly set the connector link_status to BAD as an
alternative.  But at least the build of weston I'm using atm doesn't
handle the link_status propery, this approach requires each atomic
userspace to handle this case.  Compared to Sean's approach which is
transparent to userspace, which seems attractive.

BR,
-R

>
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 73021b388e12..dd3ff2f2cdce 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -429,6 +429,18 @@ static void adv7511_hpd_work(struct work_struct *work)
> else
> status = connector_status_disconnected;
>
> +   /*
> +* The bridge resets its registers on unplug. So when we get a plug
> +* event and we're already supposed to be powered, cycle the bridge to
> +* restore its state.
> +*/
> +   if (status == connector_status_connected &&
> +   adv7511->connector.status == connector_status_disconnected &&
> +   adv7511->powered) {
> +   regcache_mark_dirty(adv7511->regmap);
> +   adv7511_power_on(adv7511);
> +   }
> +
> if (adv7511->connector.status != status) {
> adv7511->connector.status = status;
> if (status == connector_status_disconnected)
> --
> Sean Paul, Software Engineer, Google / Chromium OS
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 1/2] devicetree/bindings: display: Add document for rockchip RGB output

On Tue, Jun 26, 2018 at 03:15:39PM +0800, Sandy Huang wrote:
> This path add support rv1108 and px30 rgb output interface driver.

Bindings are for h/w, not drivers.

> 
> Signed-off-by: Sandy Huang 
> Link: 
> https://patchwork.freedesktop.org/patch/msgid/1509522765-118759-1-git-send-email-...@rock-chips.com
> ---
> 
> Changes in v4: Add support px30
> Changes in v3: None
> Changes in v2: None
> 
> .../bindings/display/rockchip/rockchip-rgb.txt | 73 ++
>  1 file changed, 73 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> new file mode 100644
> index 000..077b9ad
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-rgb.txt
> @@ -0,0 +1,73 @@
> +Rockchip RV1108 RGB interface
> +
> +
> +Required properties:
> +- compatible: matching the soc type:
> + - "rockchip,px30-rgb";
> + - "rockchip,rv1108-rgb";

This doesn't look right? What (and how) is getting programmed here 
because you don't have any register interface.

> +
> +Optional properties:
> +- pinctrl-names: should be a "lcdc" entry or a "default" entry.
> +- pinctrl-0: pin control group to be used for this interface.
> +
> +The rgb has two video ports described by:
> + Documentation/devicetree/bindings/media/video-interfaces.txt
> +Their connections are modeled using the OF graph bindings specified in
> + Documentation/devicetree/bindings/graph.txt.
> +
> +- video port 0 for the VOP input, the remote endpoint maybe vopb/vopl/vop

So there is a mux for these inputs and they are switched with pinctrl? 

Just put the pinctrl nodes of the sources and enable whichever one is 
active.

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

Re: [PATCH] drm/writeback: Fix the "overview" section of the doc

2018-07-03 Thread Boris Brezillon

On Tue,  3 Jul 2018 19:40:46 +0200
Boris Brezillon  wrote:

> Fix the bullet list declaration in the overview section.
> 
> Signed-off-by: Boris Brezillon 

Forgot to add:

Reported-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_writeback.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index 827395071f0b..69e7a63cfcc3 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -22,10 +22,13 @@
>   * Writeback connectors are used to expose hardware which can write the 
> output
>   * from a CRTC to a memory buffer. They are used and act similarly to other
>   * types of connectors, with some important differences:
> - *  - Writeback connectors don't provide a way to output visually to the 
> user.
> - *  - Writeback connectors should always report as "disconnected" (so that
> - *clients which don't understand them will ignore them).
> - *  - Writeback connectors don't have EDID.
> + *
> + * * Writeback connectors don't provide a way to output visually to the user.
> + *
> + * * Writeback connectors should always report as "disconnected" (so that
> + *   clients which don't understand them will ignore them).
> + *
> + * * Writeback connectors don't have EDID.
>   *
>   * A framebuffer may only be attached to a writeback connector when the
>   * connector is attached to a CRTC. The WRITEBACK_FB_ID property which sets 
> the

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

[PATCH] drm/writeback: Fix the "overview" section of the doc

2018-07-03 Thread Boris Brezillon

Fix the bullet list declaration in the overview section.

Signed-off-by: Boris Brezillon 
---
 drivers/gpu/drm/drm_writeback.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 827395071f0b..69e7a63cfcc3 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -22,10 +22,13 @@
  * Writeback connectors are used to expose hardware which can write the output
  * from a CRTC to a memory buffer. They are used and act similarly to other
  * types of connectors, with some important differences:
- *  - Writeback connectors don't provide a way to output visually to the user.
- *  - Writeback connectors should always report as "disconnected" (so that
- *clients which don't understand them will ignore them).
- *  - Writeback connectors don't have EDID.
+ *
+ * * Writeback connectors don't provide a way to output visually to the user.
+ *
+ * * Writeback connectors should always report as "disconnected" (so that
+ *   clients which don't understand them will ignore them).
+ *
+ * * Writeback connectors don't have EDID.
  *
  * A framebuffer may only be attached to a writeback connector when the
  * connector is attached to a CRTC. The WRITEBACK_FB_ID property which sets the
-- 
2.14.1

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

[Bug 200395] nv04_timer_read() hangs a CPU

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

--- Comment #5 from Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) ---
Created attachment 277151
  --> https://bugzilla.kernel.org/attachment.cgi?id=277151=edit
Kernel .config

-- 
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

[Bug 200387] amdgpu uses unusually high memory

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

--- Comment #24 from phoenix (fe...@feldspaten.org) ---
Hi Michel,

wiredly not, I just double-checked them an in Stardew Valley the 4.4 number is
really the 400 MB bigger one. For now I'm gonna give the kernel version numbers
a try before we're working here on two things at the same time.

-- 
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

[Bug 200395] nv04_timer_read() hangs a CPU

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

Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) changed:

   What|Removed |Added

 Attachment #277145|0   |1
is obsolete||

--- Comment #4 from Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) ---
Created attachment 277149
  --> https://bugzilla.kernel.org/attachment.cgi?id=277149=edit
4.17.4 dmesg output

-- 
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

[Bug 200395] nv04_timer_read() hangs a CPU

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

Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) changed:

   What|Removed |Added

 Kernel Version|4.17.3  |4.17.4

--- Comment #3 from Thomas (be11f157cd19c4a2ba1e9c70a38b1...@protonmail.com) ---
I tested again with 4.17.4. Same behavior. I attached the new dmesg output and
the kernel config.

-- 
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

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

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

--- Comment #7 from Lyude Paul  ---
(In reply to mikita.lip...@amd.com from comment #6)
> I have just

???

-- 
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 v5 3/4] dt-bindings: Add Innolux P097PFG panel bindings

On Mon, Jul 02, 2018 at 12:27:20PM +0200, Heiko Stuebner wrote:
> From: huang lin 
> 
> The Innolux P097PFG panel is 9.7" panel with 1536X2048
> resolution, it reuse P079ZCA panel driver, so improve
> p079ZCA dt-binding to support P097PFG.
> 
> Changes in v2:
> - None
> Changes in v3:
> - None
> Changes in v4:
> - None
> Changes in v5:
> - use separate file for binding
> - keep power supplies as required
> 
> Signed-off-by: Lin Huang 
> Signed-off-by: Heiko Stuebner 
> ---
>  .../display/panel/innolux,p097pfg.txt | 24 +++
>  1 file changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/innolux,p097pfg.txt

Reviewed-by: Rob Herring 

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

Re: [PATCH] fb: fix lost console when the user unplugs a USB adapter

2018-07-03 Thread Mikulas Patocka



On Tue, 3 Jul 2018, Bartlomiej Zolnierkiewicz wrote:

> 
> Hi,
> 
> On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote:
> > I have a USB display adapter using the udlfb driver and I use it on an ARM
> > board that doesn't have any graphics card. When I plug the adapter in, the
> > console is properly displayed, however when I unplug and re-plug the
> > adapter, the console is not displayed and I can't access it until I reboot
> > the board.
> > 
> > The reason is this:
> > When the adapter is unplugged, dlfb_usb_disconnect calls
> > unlink_framebuffer, then it waits until the reference count drops to zero
> > and then it deallocates the framebuffer. However, the console that is
> > attached to the framebuffer device keeps the reference count non-zero, so
> > the framebuffer device is never destroyed. When the USB adapter is plugged
> > again, it creates a new device /dev/fb1 and the console is not attached to
> > it.
> > 
> > This patch fixes the bug by unbinding the console from unlink_framebuffer.
> > The code to unbind the console is moved from do_unregister_framebuffer to
> > a function unbind_console. When the console is unbound, the reference
> > count drops to zero and the udlfb driver frees the framebuffer. When the
> > adapter is plugged back, a new framebuffer is created and the console is
> > attached to it.
> > 
> > Signed-off-by: Mikulas Patocka 
> > Cc: sta...@vger.kernel.org
> 
> After this change unbind_console() will be called twice in the standard
> framebuffer unregister path:
> 
> - first time, directly by do_unregister_framebuffer()
> 
> - second time, indirectly by do_unregister_framebuffer()->unlink_framebuffer()
> 
> This doesn't look correctly.

unbind_console calls the FB_EVENT_FB_UNBIND notifier, FB_EVENT_FB_UNBIND 
goes to the function fbcon_fb_unbind and fbcon_fb_unbind checks if the 
console is bound to the framebuffer for which unbind is requested. So a 
double call won't cause any trouble.

> Also why can't udlfb just use unregister_framebuffer() like all other
> drivers (it uses unlink_framebuffer() and it is the only user of this
> helper)?

It uses unregister_framebuffer() - but - unregister_framebuffer() may only 
be called when the open count of the framebuffer is zero. So, the udlfb 
driver waits until the open count drops to zero and then calls 
unregister_framebuffer().

But the console subsystem keeps the framebuffer open - which means that if 
user use unplugs the USB adapter, the open count won't drop to zero 
(because the console is bound to it) - which means that 
unregister_framebuffer() will not be called.

You must unbind the console before calling unregister_framebuffer(). The 
PCI framebuffer drivers don't have this problem because the user is not 
expected to just unplug the PCI card while it is being used by the 
console.

Mikulas

> > ---
> >  drivers/video/fbdev/core/fbmem.c |   21 +
> >  1 file changed, 17 insertions(+), 4 deletions(-)
> > 
> > Index: linux-4.16.12/drivers/video/fbdev/core/fbmem.c
> > ===
> > --- linux-4.16.12.orig/drivers/video/fbdev/core/fbmem.c 2018-05-26 
> > 06:13:20.0 +0200
> > +++ linux-4.16.12/drivers/video/fbdev/core/fbmem.c  2018-05-26 
> > 06:13:20.0 +0200
> > @@ -1805,12 +1805,12 @@ static int do_register_framebuffer(struc
> > return 0;
> >  }
> >  
> > -static int do_unregister_framebuffer(struct fb_info *fb_info)
> > +static int unbind_console(struct fb_info *fb_info)
> >  {
> > struct fb_event event;
> > -   int i, ret = 0;
> > +   int ret;
> > +   int i = fb_info->node;
> >  
> > -   i = fb_info->node;
> > if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
> > return -EINVAL;
> >  
> > @@ -1825,6 +1825,16 @@ static int do_unregister_framebuffer(str
> > unlock_fb_info(fb_info);
> > console_unlock();
> >  
> > +   return ret;
> > +}
> > +
> > +static int do_unregister_framebuffer(struct fb_info *fb_info)
> > +{
> > +   struct fb_event event;
> > +   int ret;
> > +
> > +   ret = unbind_console(fb_info);
> > +
> > if (ret)
> > return -EINVAL;
> >  
> > @@ -1835,7 +1845,7 @@ static int do_unregister_framebuffer(str
> > (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
> > kfree(fb_info->pixmap.addr);
> > fb_destroy_modelist(_info->modelist);
> > -   registered_fb[i] = NULL;
> > +   registered_fb[fb_info->node] = NULL;
> > num_registered_fb--;
> > fb_cleanup_device(fb_info);
> > event.info = fb_info;
> > @@ -1860,6 +1870,9 @@ int unlink_framebuffer(struct fb_info *f
> > device_destroy(fb_class, MKDEV(FB_MAJOR, i));
> > fb_info->dev = NULL;
> > }
> > +
> > +   unbind_console(fb_info);
> > +
> > return 0;
> >  }
> >  EXPORT_SYMBOL(unlink_framebuffer);
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>

Re: [PATCH v2 7/8] drm/bridge/synopsys: dsi: add dual-dsi support

2018-07-03 Thread Andrzej Hajda

On 18.06.2018 12:28, Heiko Stuebner wrote:
> From: Nickey Yang 
>
> Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
> setup. This will require additional implementation-specific
> code to look up the slave instance and do specific setup.
> Also will probably need code in the specific crtcs as dual-dsi
> does not equal two separate dsi outputs.
>
> To activate, the implementation-specific code should set the slave
> using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().
>
> v2:
> - expect real interface number of lanes
> - keep links to both master and slave

I did not see the whole driver/pipeline, but it seems the point of this
patch is to perform the same work on the slave as on the master in case
of dual mode. I think DSI should not be a place for it,
DSI masters usually are stupid devices from display stack PoV, they just
convert video streams, in dual mode also. In this case the panel and/or
crtc adds complications so they should be responsible for handling it.
Panel should:
- register its both mipi interfaces with proper mode_flags (maybe some
dual-mode indication flags should be added if necessary),
- register drm_panel for both interfaces (it requires change in
drm_panel api), and provide video mode timings.
- in case it needs perform transfers perform it to master/slave/both
interfaces according to its needs,

I am not sure about DRM pipeline, it should model, maybe it could be
done this way:
CRTC -->ENCODER0(dsi master) --> CONNECTOR0 (panel interface 0)
  |---> ENCODER1(dsi slave) --> CONNECTOR1 (panel interface 1)

But I am not sure if it is not reserved only for mirroring.

For me more tempting solution is to create meta-encoder-connector let's
call it dual-encoder (maybe it could be even generic), which is visible
to userspace as single pipeline and encapsulates both dsi bridges/panel
inputs. So its every callback will be translated usually to sequence of
callbacks to 1st and 2nd dsi, or in case of get_modes it should return
mode which represent sum of modes in both panels.
Maybe it looks more complicated, but it can be more universal - you can
use it with different bridges/panels even two single-panels if necessary.

Of course I do not see the whole picture, or I can be just wrong, or
just freaking purist :). If there are arguments against my vision please
provide them.
I am also not strongly against your solution, I just want to show
alternatives, which could be better/more generic.

Regards
Andrzej

>
> Signed-off-by: Nickey Yang 
> Signed-off-by: Heiko Stuebner 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 93 +--
>  include/drm/bridge/dw_mipi_dsi.h  |  1 +
>  2 files changed, 86 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> index bd503f000ed5..6a345d1dde25 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c
> @@ -230,9 +230,20 @@ struct dw_mipi_dsi {
>   u32 format;
>   unsigned long mode_flags;
>  
> + struct dw_mipi_dsi *master; /* dual-dsi master ptr */
> + struct dw_mipi_dsi *slave; /* dual-dsi slave ptr */
> +
>   const struct dw_mipi_dsi_plat_data *plat_data;
>  };
>  
> +/*
> + * Check if either a link to a master or slave is present
> + */
> +static inline bool dw_mipi_is_dual_mode(struct dw_mipi_dsi *dsi)
> +{
> + return dsi->slave || dsi->master;
> +}
> +
>  /*
>   * The controller should generate 2 frames before
>   * preparing the peripheral.
> @@ -273,18 +284,26 @@ static int dw_mipi_dsi_host_attach(struct mipi_dsi_host 
> *host,
>   struct drm_bridge *bridge;
>   struct drm_panel *panel;
>   int ret;
> + int lanes = device->lanes;
>  
> - if (device->lanes > dsi->plat_data->max_data_lanes) {
> + if (lanes > dsi->plat_data->max_data_lanes) {
>   dev_err(dsi->dev, "the number of data lanes(%u) is too many\n",
>   device->lanes);
>   return -EINVAL;
>   }
>  
> - dsi->lanes = device->lanes;
> + dsi->lanes = lanes;
>   dsi->channel = device->channel;
>   dsi->format = device->format;
>   dsi->mode_flags = device->mode_flags;
>  
> + if (dsi->slave) {
> + dsi->slave->lanes = dsi->lanes;
> + dsi->slave->channel = dsi->channel;
> + dsi->slave->format = dsi->format;
> + dsi->slave->mode_flags = dsi->mode_flags;
> + }
> +
>   ret = drm_of_find_panel_or_bridge(host->dev->of_node, 1, 0,
> , );
>   if (ret)
> @@ -441,10 +460,17 @@ static ssize_t dw_mipi_dsi_host_transfer(struct 
> mipi_dsi_host *host,
>   }
>  
>   dw_mipi_message_config(dsi, msg);
> + if (dsi->slave)
> + dw_mipi_message_config(dsi->slave, msg);
>  
>   ret = dw_mipi_dsi_write(dsi, );
>   if (ret)
>   return ret;
> + if

Re: [amdgpu][tahiti xt] cursor motion smoothness

2018-07-03 Thread Michel Dänzer

On 2018-07-03 04:46 PM, sylvain.bertr...@gmail.com wrote:
> On Tue, Jul 03, 2018 at 11:01:46AM +0200, Michel Dänzer wrote:
>> Also make sure you do not pass -dumbSched on the Xorg command line, and
>> do not disable Option "SilkenMouse" in xorg.conf.
> 
> No pb on this side. I tried to enable -dumbSched, I could not see any
> difference.
> 
> I did run a fast moving game at 60Hz, it was horrible, I ran it at 144Hz,
> smooth... the culprit may well be the monitor or my eyes.

Yeah, we've pretty much ruled out any possible software issue at this
point. :)

Regarding the monitor, maybe double-check its settings for anything
(e.g. picture quality / post processing) which might delay its output.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/v3d: Delay the scheduler timeout if we're still making progress.

GTF-GLES2.gtf.GL.acos.acos_float_vert_xvary submits jobs that take 4
seconds at maximum resolution, but we still want to reset quickly if a
job is really hung.  Sample the CL's current address and the return
address (since we call into tile lists repeatedly) and if either has
changed then assume we've made progress.

Signed-off-by: Eric Anholt 
Cc: Lucas Stach 
---
 drivers/gpu/drm/v3d/v3d_drv.h   |  2 ++
 drivers/gpu/drm/v3d/v3d_regs.h  |  1 +
 drivers/gpu/drm/v3d/v3d_sched.c | 18 ++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
index f546e0ab9562..a5d96d823416 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.h
+++ b/drivers/gpu/drm/v3d/v3d_drv.h
@@ -189,6 +189,8 @@ struct v3d_job {
 
/* GPU virtual addresses of the start/end of the CL job. */
u32 start, end;
+
+   u32 timedout_ctca, timedout_ctra;
 };
 
 struct v3d_exec_info {
diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
index fc13282dfc2f..854046565989 100644
--- a/drivers/gpu/drm/v3d/v3d_regs.h
+++ b/drivers/gpu/drm/v3d/v3d_regs.h
@@ -222,6 +222,7 @@
 #define V3D_CLE_CTNCA(n) (V3D_CLE_CT0CA + 4 * n)
 #define V3D_CLE_CT0RA  0x00118
 #define V3D_CLE_CT1RA  0x0011c
+#define V3D_CLE_CTNRA(n) (V3D_CLE_CT0RA + 4 * n)
 #define V3D_CLE_CT0LC  0x00120
 #define V3D_CLE_CT1LC  0x00124
 #define V3D_CLE_CT0PC  0x00128
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 808bc901f567..00667c733dca 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -153,7 +153,25 @@ v3d_job_timedout(struct drm_sched_job *sched_job)
struct v3d_job *job = to_v3d_job(sched_job);
struct v3d_exec_info *exec = job->exec;
struct v3d_dev *v3d = exec->v3d;
+   enum v3d_queue job_q = job == >bin ? V3D_BIN : V3D_RENDER;
enum v3d_queue q;
+   u32 ctca = V3D_CORE_READ(0, V3D_CLE_CTNCA(job_q));
+   u32 ctra = V3D_CORE_READ(0, V3D_CLE_CTNRA(job_q));
+
+   /* If the current address or return address have changed, then
+* the GPU has probably made progress and we should delay the
+* reset.  This could fail if the GPU got in an infinite loop
+* in the CL, but that is pretty unlikely outside of an i-g-t
+* testcase.
+*/
+   if (job->timedout_ctca != ctca || job->timedout_ctra != ctra) {
+   job->timedout_ctca = ctca;
+   job->timedout_ctra = ctra;
+
+   schedule_delayed_work(>base.work_tdr,
+ job->base.sched->timeout);
+   return;
+   }
 
mutex_lock(>reset_lock);
 
-- 
2.18.0

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

[PATCH 4/4] drm/v3d: Fix a grammar nit in the scheduler docs.

Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/v3d/v3d_sched.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 00667c733dca..a5501581d96b 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -14,8 +14,8 @@
  * to the HW only when it has completed the last one, instead of
  * filling up the CT[01]Q FIFOs with jobs.  Similarly, we use
  * v3d_job_dependency() to manage the dependency between bin and
- * render, instead of having the clients submit jobs with using the
- * HW's semaphores to interlock between them.
+ * render, instead of having the clients submit jobs using the HW's
+ * semaphores to interlock between them.
  */
 
 #include 
-- 
2.18.0

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

[PATCH 3/4] drm/v3d: Add missing v3d documentation structure.

This was a failure of "git add" on my part -- we already referenced
the doc from drivers.rst.

Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
---
 Documentation/gpu/v3d.rst | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/gpu/v3d.rst

diff --git a/Documentation/gpu/v3d.rst b/Documentation/gpu/v3d.rst
new file mode 100644
index ..543f7fbf526e
--- /dev/null
+++ b/Documentation/gpu/v3d.rst
@@ -0,0 +1,28 @@
+=
+ drm/v3d Broadcom V3D Graphics Driver
+=
+
+.. kernel-doc:: drivers/gpu/drm/v3d/v3d_drv.c
+   :doc: Broadcom V3D Graphics Driver
+
+GPU buffer object (BO) management
+-
+
+.. kernel-doc:: drivers/gpu/drm/v3d/v3d_bo.c
+   :doc: V3D GEM BO management support
+
+Address space management
+===
+.. kernel-doc:: drivers/gpu/drm/v3d/v3d_mmu.c
+   :doc: Broadcom V3D MMU
+
+GPU Scheduling
+===
+.. kernel-doc:: drivers/gpu/drm/v3d/v3d_sched.c
+   :doc: Broadcom V3D scheduling
+
+Interrupts
+--
+
+.. kernel-doc:: drivers/gpu/drm/v3d/v3d_irq.c
+   :doc: Interrupt management for the V3D engine
-- 
2.18.0

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

[PATCH 2/4] drm/v3d: Remove unnecessary dma_fence_ops.

The dma-fence core as of commit 418cc6ca0607 ("dma-fence: Make ->wait
callback optional") provides appropriate defaults for these methods.

Signed-off-by: Eric Anholt 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/v3d/v3d_fence.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/gpu/drm/v3d/v3d_fence.c b/drivers/gpu/drm/v3d/v3d_fence.c
index bfe31a89668b..50bfcf9a8a1a 100644
--- a/drivers/gpu/drm/v3d/v3d_fence.c
+++ b/drivers/gpu/drm/v3d/v3d_fence.c
@@ -35,19 +35,7 @@ static const char *v3d_fence_get_timeline_name(struct 
dma_fence *fence)
return "v3d-render";
 }
 
-static bool v3d_fence_enable_signaling(struct dma_fence *fence)
-{
-   return true;
-}
-
 const struct dma_fence_ops v3d_fence_ops = {
.get_driver_name = v3d_fence_get_driver_name,
.get_timeline_name = v3d_fence_get_timeline_name,
-   .enable_signaling = v3d_fence_enable_signaling,
-   /* Each of our fences gets signaled as complete by the IRQ
-* handler, so we rely on the core's tracking of signaling.
-*/
-   .signaled = NULL,
-   .wait = dma_fence_default_wait,
-   .release = dma_fence_free,
 };
-- 
2.18.0

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

Re: [PATCH] drm/msm/mdp5: fix missing CTL flush

2018-07-03 Thread Sean Paul

On Tue, Jul 03, 2018 at 12:43:50PM -0400, Rob Clark wrote:
> f9cb8d8d836e fixed various race conditions with CTL flush, in particular
> flushing and sending the START signal before encoder state was updated.
> But it did this a little too well in some cases that don't trigger
> encoder->enable(), and CTL[n].FLUSH would never be set.  When page flips
> happen it would paper over the bug, since the first plag flip would
> flush out the state to the hardware.
> 
> The issue could be reproduced with, for example, modetest (without the
> '-v' argument).
> 
> Fixes: f9cb8d8d836e drm/msm/mdp5: rework CTL START signal handling
> Signed-off-by: Rob Clark 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
> index 9af94e35f678..fcd44d1d1068 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
> @@ -319,7 +319,17 @@ static int mdp5_encoder_atomic_check(struct drm_encoder 
> *encoder,
>  
>   mdp5_cstate->ctl = ctl;
>   mdp5_cstate->pipeline.intf = intf;
> - mdp5_cstate->defer_start = true;
> +
> + /*
> +  * This is a bit awkward, but we want to flush the CTL and hit the
> +  * START bit at most once for an atomic update.  In the non-full-
> +  * modeset case, this is done from crtc->atomic_flush(), but that
> +  * is too early in the case of full modeset, in which case we
> +  * defer to encoder->enable().  But we need to *know* whether
> +  * encoder->enable() will be called to do this:
> +  */
> + if (drm_atomic_crtc_needs_modeset(crtc_state))
> + mdp5_cstate->defer_start = true;
>  
>   return 0;
>  }
> -- 
> 2.17.1
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/bridge: adv7511: Reset registers on hotplug

2018-07-03 Thread Sean Paul

The bridge loses its hw state when the cable is unplugged. If we detect
this case in the hpd handler, reset its state.

Reported-by: Rob Clark 
Signed-off-by: Sean Paul 
---
This is the follow-up to "drm/msm: Disable mdp5 crtc when there are no
active planes". I incorrectly assumed the modeset was required from the
msm side, but Rob pointed out that he thought it might be a bridge
issue.

 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 73021b388e12..dd3ff2f2cdce 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -429,6 +429,18 @@ static void adv7511_hpd_work(struct work_struct *work)
else
status = connector_status_disconnected;
 
+   /*
+* The bridge resets its registers on unplug. So when we get a plug
+* event and we're already supposed to be powered, cycle the bridge to
+* restore its state.
+*/
+   if (status == connector_status_connected &&
+   adv7511->connector.status == connector_status_disconnected &&
+   adv7511->powered) {
+   regcache_mark_dirty(adv7511->regmap);
+   adv7511_power_on(adv7511);
+   }
+
if (adv7511->connector.status != status) {
adv7511->connector.status = status;
if (status == connector_status_disconnected)
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

[Bug 200387] amdgpu uses unusually high memory

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

--- Comment #23 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to phoenix from comment #22)
> 
> ## /proc/$ID/statm for Stardew Valley (Similar problem see the data segment)
> # statm for 4917 on 4.17.3
> 978381 424915 23927 849 0 449695 0
> # statm for 4370 on 4.4.0
> 979917 418188 23774 849 0 874146 0

Did you swap these numbers? The only significant difference is the data size
(second to last number), but the 4.4 number is bigger by ~400MB.

-- 
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

[PATCH] drm/msm/mdp5: fix missing CTL flush

2018-07-03 Thread Rob Clark

f9cb8d8d836e fixed various race conditions with CTL flush, in particular
flushing and sending the START signal before encoder state was updated.
But it did this a little too well in some cases that don't trigger
encoder->enable(), and CTL[n].FLUSH would never be set.  When page flips
happen it would paper over the bug, since the first plag flip would
flush out the state to the hardware.

The issue could be reproduced with, for example, modetest (without the
'-v' argument).

Fixes: f9cb8d8d836e drm/msm/mdp5: rework CTL START signal handling
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
index 9af94e35f678..fcd44d1d1068 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_encoder.c
@@ -319,7 +319,17 @@ static int mdp5_encoder_atomic_check(struct drm_encoder 
*encoder,
 
mdp5_cstate->ctl = ctl;
mdp5_cstate->pipeline.intf = intf;
-   mdp5_cstate->defer_start = true;
+
+   /*
+* This is a bit awkward, but we want to flush the CTL and hit the
+* START bit at most once for an atomic update.  In the non-full-
+* modeset case, this is done from crtc->atomic_flush(), but that
+* is too early in the case of full modeset, in which case we
+* defer to encoder->enable().  But we need to *know* whether
+* encoder->enable() will be called to do this:
+*/
+   if (drm_atomic_crtc_needs_modeset(crtc_state))
+   mdp5_cstate->defer_start = true;
 
return 0;
 }
-- 
2.17.1

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

Re: [PATCH v5 3/3] console/fbcon: Add support for deferred console takeover

2018-07-03 Thread Sergey Senozhatsky

On (07/03/18 12:14), Steven Rostedt wrote:
> > Can we please default this to 'n'?
> >
> 
> No explicit default means 'n'. You don't need to specify it.

Ah, OK. Thanks.

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

[Bug 200387] amdgpu uses unusually high memory

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

--- Comment #22 from phoenix (fe...@feldspaten.org) ---
Apperently it's not that easy to attach valgrind to any Steam game, so I'm
going the suggested approach of trying it out using different Kernel version.

Interestingly I could observe similar behaviour in Stardew Valley but not in
Kerbal Space program, as the following attached statm shows:


## /proc/$ID/statm for Stardew Valley (Similar problem see the data segment)
# statm for 4917 on 4.17.3
978381 424915 23927 849 0 449695 0
# statm for 4370 on 4.4.0
979917 418188 23774 849 0 874146 0

## /proc/$ID/statm for Kerbal Space Program (Problem does not occur)
# statm of 5419 on 4.4.0
532753 381415 19974 7863 0 446822 0
# statm of on 4.17.3
529142 389210 19754 7863 0 441862 0

I'm investigating using different Kernel versions and maybe I'm able to write a
simple OpenGL program that triggers the problem.

-- 
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

Re: [PATCH] drm/amdgpu/acp: Fix slab-out-of-bounds in mfd_add_device in acp_hw_init

2018-07-03 Thread Alex Deucher

On Mon, Jul 2, 2018 at 5:48 PM, Daniel Kurtz  wrote:
> Hi Alex,
>
> On Sun, Apr 15, 2018 at 9:48 PM Agrawal, Akshu  wrote:
>>
>>
>>
>> On 4/13/2018 9:45 PM, Daniel Kurtz wrote:
>> > Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
>> > stoney/cz") added support for the "BT_I2S" ACP i2s channel.  As part of
>> > this change, one additional acp resource was added, but the "num_resource"
>> > count was accidentally incremented by 2.
>> >
>> > This incorrect count eventually causes mfd_add_device() to try to access
>> > an invalid memory address (the location of non-existent resource 5.
>> >
>> > This fault was detected by running a KASAN enabled kernel, which produced
>> > the following splat at boot:
>> >
>> > [6.612987] 
>> > ==
>> > [6.613509] BUG: KASAN: slab-out-of-bounds in mfd_add_device+0x4bc/0x7a7
>> > [6.613509] Read of size 8 at addr 880107d4dc58 by task swapper/0/1
>> > [6.613509]
>> > [6.613509] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.33 #349
>> > [6.613509] Hardware name: Google Grunt/Grunt, BIOS 
>> > Google_Grunt.10543.0.2018_04_03_1812 04/02/2018
>> > [6.613509] Call Trace:
>> > [6.613509]  dump_stack+0x4d/0x63
>> > [6.613509]  print_address_description+0x80/0x2d6
>> > [6.613509]  ? mfd_add_device+0x4bc/0x7a7
>> > [6.613509]  kasan_report+0x255/0x295
>> > [6.613509]  mfd_add_device+0x4bc/0x7a7
>> > [6.613509]  ? kasan_kmalloc+0x99/0xa8
>> > [6.613509]  ? mfd_add_devices+0x58/0xe4
>> > [6.613509]  ? __kmalloc+0x154/0x178
>> > [6.613509]  mfd_add_devices+0xa5/0xe4
>> > [6.613509]  acp_hw_init+0x92e/0xc4a
>> > [6.613509]  amdgpu_device_init+0x1dfb/0x22a2
>> > [6.613509]  ? kmalloc_order+0x53/0x5d
>> > [6.613509]  ? kmalloc_order_trace+0x23/0xb3
>> > [6.613509]  amdgpu_driver_load_kms+0xce/0x267
>> > [6.613509]  drm_dev_register+0x169/0x2fb
>> > [6.613509]  amdgpu_pci_probe+0x217/0x242
>> > [6.613509]  pci_device_probe+0x101/0x18e
>> > [6.613509]  driver_probe_device+0x1dd/0x419
>> > [6.613509]  ? ___might_sleep+0x80/0x1b6
>> > [6.613509]  __driver_attach+0x9f/0xc9
>> > [6.613509]  ? driver_probe_device+0x419/0x419
>> > [6.613509]  bus_for_each_dev+0xbc/0xe1
>> > [6.613509]  bus_add_driver+0x189/0x2c0
>> > [6.613509]  driver_register+0x108/0x156
>> > [6.613509]  ? ttm_init+0x67/0x67
>> > [6.613509]  do_one_initcall+0xb2/0x161
>> > [6.613509]  kernel_init_freeable+0x25a/0x308
>> > [6.613509]  ? rest_init+0xcc/0xcc
>> > [6.613509]  kernel_init+0x11/0x10d
>> > [6.613509]  ? rest_init+0xcc/0xcc
>> > [6.613509]  ret_from_fork+0x22/0x40
>> > [6.613509]
>> > [6.613509] Allocated by task 1:
>> > [6.613509]  save_stack+0x46/0xce
>> > [6.613509]  kasan_kmalloc+0x99/0xa8
>> > [6.613509]  kmem_cache_alloc_trace+0x11a/0x13e
>> > [6.613509]  acp_hw_init+0x210/0xc4a
>> > [6.613509]  amdgpu_device_init+0x1dfb/0x22a2
>> > [6.613509]  amdgpu_driver_load_kms+0xce/0x267
>> > [6.613509]  drm_dev_register+0x169/0x2fb
>> > [6.613509]  amdgpu_pci_probe+0x217/0x242
>> > [6.613509]  pci_device_probe+0x101/0x18e
>> > [6.613509]  driver_probe_device+0x1dd/0x419
>> > [6.613509]  __driver_attach+0x9f/0xc9
>> > [6.613509]  bus_for_each_dev+0xbc/0xe1
>> > [6.613509]  bus_add_driver+0x189/0x2c0
>> > [6.613509]  driver_register+0x108/0x156
>> > [6.613509]  do_one_initcall+0xb2/0x161
>> > [6.613509]  kernel_init_freeable+0x25a/0x308
>> > [6.613509]  kernel_init+0x11/0x10d
>> > [6.613509]  ret_from_fork+0x22/0x40
>> > [6.613509]
>> > [6.613509] Freed by task 0:
>> > [6.613509] (stack is not available)
>> > [6.613509]
>> > [6.613509] The buggy address belongs to the object at 880107d4db08
>> > [6.613509]  which belongs to the cache kmalloc-512 of size 512
>> > [6.613509] The buggy address is located 336 bytes inside of
>> > [6.613509]  512-byte region [880107d4db08, 880107d4dd08)
>> > [6.613509] The buggy address belongs to the page:
>> > [6.613509] page:ea00041f5300 count:1 mapcount:0 mapping:  
>> > (null) index:0x0 compound_mapcount: 0
>> > [6.613509] flags: 0x80008100(slab|head)
>> > [6.613509] raw: 80008100   
>> > 000100120012
>> > [6.613509] raw: ea0004208520 88010b001680 88010b002cc0 
>> > 
>> > [6.613509] page dumped because: kasan: bad access detected
>> > [6.613509]
>> > [6.613509] Memory state around the buggy address:
>> > [6.613509]  880107d4db00: fc 00 00 00 00 00 00 00 00 00 00 00 00 
>> > 00 00 00
>> > [6.613509]  880107d4db80: 00 00 00 00 00 00 00 00 00 00 00 00 00 
>> > 00 00 00
>> > [6.613509] >880107d4dc00: 00 00 00 00 00 00 00 00 00 fc fc fc fc 
>> > fc fc fc
>> > [6.613509]

Re: [PATCH v5 3/3] console/fbcon: Add support for deferred console takeover

2018-07-03 Thread Steven Rostedt

On Wed, 4 Jul 2018 01:13:27 +0900
Sergey Senozhatsky  wrote:

> On (06/28/18 11:03), Hans de Goede wrote:
> [..]
> >  
> > +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > +   bool "Framebuffer Console Deferred Takeover"
> > +   depends on FRAMEBUFFER_CONSOLE=y && DUMMY_CONSOLE=y  
> 
> + default n
> 
> > +   help
> > + If enabled this defers the framebuffer console taking over the
> > + console from the dummy console until the first text is displayed on
> > + the console. This is useful in combination with the "quiet" kernel
> > + commandline option to keep the framebuffer contents initially put up
> > + by the firmware in place, rather then replacing the contents with a
> > + black screen as soon as fbcon loads.  
> 
> Can we please default this to 'n'?
>

No explicit default means 'n'. You don't need to specify it.

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

Re: [PATCH v5 3/3] console/fbcon: Add support for deferred console takeover

2018-07-03 Thread Sergey Senozhatsky

On (06/28/18 11:03), Hans de Goede wrote:
[..]
>  
> +config FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> + bool "Framebuffer Console Deferred Takeover"
> + depends on FRAMEBUFFER_CONSOLE=y && DUMMY_CONSOLE=y

+   default n

> + help
> +   If enabled this defers the framebuffer console taking over the
> +   console from the dummy console until the first text is displayed on
> +   the console. This is useful in combination with the "quiet" kernel
> +   commandline option to keep the framebuffer contents initially put up
> +   by the firmware in place, rather then replacing the contents with a
> +   black screen as soon as fbcon loads.

Can we please default this to 'n'?

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

[PATCH v5 7/8] drm/tinydrm: Use drm_fbdev_generic_setup()

Make full use of the generic fbdev client.

Cc: David Lechner 
Signed-off-by: Noralf Trønnes 
Reviewed-by: David Lechner 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 3 +--
 drivers/gpu/drm/tinydrm/ili9225.c   | 1 -
 drivers/gpu/drm/tinydrm/ili9341.c   | 1 -
 drivers/gpu/drm/tinydrm/mi0283qt.c  | 1 -
 drivers/gpu/drm/tinydrm/st7586.c| 1 -
 drivers/gpu/drm/tinydrm/st7735r.c   | 1 -
 6 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 24a33bf862fa..19c7f70adfa5 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -204,7 +204,7 @@ static int tinydrm_register(struct tinydrm_device *tdev)
if (ret)
return ret;
 
-   ret = drm_fb_cma_fbdev_init_with_funcs(drm, 0, 0, tdev->fb_funcs);
+   ret = drm_fbdev_generic_setup(drm, 0);
if (ret)
DRM_ERROR("Failed to initialize fbdev: %d\n", ret);
 
@@ -214,7 +214,6 @@ static int tinydrm_register(struct tinydrm_device *tdev)
 static void tinydrm_unregister(struct tinydrm_device *tdev)
 {
drm_atomic_helper_shutdown(tdev->drm);
-   drm_fb_cma_fbdev_fini(tdev->drm);
drm_dev_unregister(tdev->drm);
 }
 
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
index 841c69aba059..455fefe012f5 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -368,7 +368,6 @@ static struct drm_driver ili9225_driver = {
  DRIVER_ATOMIC,
.fops   = _fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.name   = "ili9225",
.desc   = "Ilitek ILI9225",
.date   = "20171106",
diff --git a/drivers/gpu/drm/tinydrm/ili9341.c 
b/drivers/gpu/drm/tinydrm/ili9341.c
index 8864dcde6edc..6701037749a7 100644
--- a/drivers/gpu/drm/tinydrm/ili9341.c
+++ b/drivers/gpu/drm/tinydrm/ili9341.c
@@ -145,7 +145,6 @@ static struct drm_driver ili9341_driver = {
.driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME | 
DRIVER_ATOMIC,
.fops   = _fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "ili9341",
.desc   = "Ilitek ILI9341",
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c 
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 015d03f2acba..d7bb4c5e6657 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -154,7 +154,6 @@ static struct drm_driver mi0283qt_driver = {
  DRIVER_ATOMIC,
.fops   = _fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "mi0283qt",
.desc   = "Multi-Inno MI0283QT",
diff --git a/drivers/gpu/drm/tinydrm/st7586.c b/drivers/gpu/drm/tinydrm/st7586.c
index 5c29e3803ecb..2fcbc3067d71 100644
--- a/drivers/gpu/drm/tinydrm/st7586.c
+++ b/drivers/gpu/drm/tinydrm/st7586.c
@@ -304,7 +304,6 @@ static struct drm_driver st7586_driver = {
  DRIVER_ATOMIC,
.fops   = _fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "st7586",
.desc   = "Sitronix ST7586",
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c 
b/drivers/gpu/drm/tinydrm/st7735r.c
index 6c7b15c9da4f..3081bc57c116 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -120,7 +120,6 @@ static struct drm_driver st7735r_driver = {
  DRIVER_ATOMIC,
.fops   = _fops,
TINYDRM_GEM_DRIVER_OPS,
-   .lastclose  = drm_fb_helper_lastclose,
.debugfs_init   = mipi_dbi_debugfs_init,
.name   = "st7735r",
.desc   = "Sitronix ST7735R",
-- 
2.15.1

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

[PATCH v5 8/8] drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

Remove drm_fb_cma_fbdev_init_with_funcs(), its only user tinydrm has
moved to drm_fbdev_generic_setup().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Reviewed-by: David Lechner 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 21 -
 include/drm/drm_fb_cma_helper.h |  3 ---
 2 files changed, 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 718c7f961d8a..9da36a6271d3 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -99,27 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
 
-/**
- * drm_fb_cma_fbdev_init_with_funcs() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- *  @dev->mode_config.num_connector is used if this is zero.
- * @funcs: Framebuffer functions, in particular a custom dirty() callback.
- * Can be NULL.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs)
-{
-   return drm_fb_cma_fbdev_init(dev, preferred_bpp, max_conn_count);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init_with_funcs);
-
 /**
  * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
  * @dev: DRM device
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index a0546c3451f9..96e26e3b9a0c 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -16,9 +16,6 @@ struct drm_mode_fb_cmd2;
 struct drm_plane;
 struct drm_plane_state;
 
-int drm_fb_cma_fbdev_init_with_funcs(struct drm_device *dev,
-   unsigned int preferred_bpp, unsigned int max_conn_count,
-   const struct drm_framebuffer_funcs *funcs);
 int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
  unsigned int max_conn_count);
 void drm_fb_cma_fbdev_fini(struct drm_device *dev);
-- 
2.15.1

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

[PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation

This switches the CMA helper drivers that use its fbdev emulation over
to the generic fbdev emulation. It's the first phase of using generic
fbdev. A later phase will use DRM client callbacks for the
lastclose/hotplug/remove callbacks.

There are currently 2 fbdev init/fini functions:
- drm_fb_cma_fbdev_init/drm_fb_cma_fbdev_fini
- drm_fbdev_cma_init/drm_fbdev_cma_fini

This is because the work on generic fbdev came up during a fbdev
refactoring and thus wasn't completed. No point in completing that
refactoring when drivers will soon move to drm_fb_helper_generic_probe().

tinydrm uses drm_fb_cma_fbdev_init_with_funcs().

Cc: Laurent Pinchart 
Signed-off-by: Noralf Trønnes 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_cma_helper.c | 360 +---
 include/drm/drm_fb_cma_helper.h |   3 -
 2 files changed, 42 insertions(+), 321 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 186d00adfb5f..718c7f961d8a 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -18,6 +18,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -26,11 +27,8 @@
 #include 
 #include 
 
-#define DEFAULT_FBDEFIO_DELAY_MS 50
-
 struct drm_fbdev_cma {
struct drm_fb_helperfb_helper;
-   const struct drm_framebuffer_funcs *fb_funcs;
 };
 
 /**
@@ -44,36 +42,6 @@ struct drm_fbdev_cma {
  *
  * An fbdev framebuffer backed by cma is also available by calling
  * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
- * If the _framebuffer_funcs.dirty callback is set, fb_deferred_io will be
- * set up automatically. _framebuffer_funcs.dirty is called by
- * drm_fb_helper_deferred_io() in process context ( delayed_work).
- *
- * Example fbdev deferred io code::
- *
- * static int driver_fb_dirty(struct drm_framebuffer *fb,
- *struct drm_file *file_priv,
- *unsigned flags, unsigned color,
- *struct drm_clip_rect *clips,
- *unsigned num_clips)
- * {
- * struct drm_gem_cma_object *cma = drm_fb_cma_get_gem_obj(fb, 0);
- * ... push changes ...
- * return 0;
- * }
- *
- * static struct drm_framebuffer_funcs driver_fb_funcs = {
- * .destroy   = drm_gem_fb_destroy,
- * .create_handle = drm_gem_fb_create_handle,
- * .dirty = driver_fb_dirty,
- * };
- *
- * Initialize::
- *
- * fbdev = drm_fb_cma_fbdev_init_with_funcs(dev, 16,
- *   dev->mode_config.num_crtc,
- *   dev->mode_config.num_connector,
- *   _fb_funcs);
- *
  */
 
 static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
@@ -131,153 +99,6 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer 
*fb,
 }
 EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
 
-static int drm_fb_cma_mmap(struct fb_info *info, struct vm_area_struct *vma)
-{
-   return dma_mmap_writecombine(info->device, vma, info->screen_base,
-info->fix.smem_start, info->fix.smem_len);
-}
-
-static struct fb_ops drm_fbdev_cma_ops = {
-   .owner  = THIS_MODULE,
-   DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_fillrect= drm_fb_helper_sys_fillrect,
-   .fb_copyarea= drm_fb_helper_sys_copyarea,
-   .fb_imageblit   = drm_fb_helper_sys_imageblit,
-   .fb_mmap= drm_fb_cma_mmap,
-};
-
-static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
- struct vm_area_struct *vma)
-{
-   fb_deferred_io_mmap(info, vma);
-   vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
-
-   return 0;
-}
-
-static int drm_fbdev_cma_defio_init(struct fb_info *fbi,
-   struct drm_gem_cma_object *cma_obj)
-{
-   struct fb_deferred_io *fbdefio;
-   struct fb_ops *fbops;
-
-   /*
-* Per device structures are needed because:
-* fbops: fb_deferred_io_cleanup() clears fbops.fb_mmap
-* fbdefio: individual delays
-*/
-   fbdefio = kzalloc(sizeof(*fbdefio), GFP_KERNEL);
-   fbops = kzalloc(sizeof(*fbops), GFP_KERNEL);
-   if (!fbdefio || !fbops) {
-   kfree(fbdefio);
-   kfree(fbops);
-   return -ENOMEM;
-   }
-
-   /* can't be offset from vaddr since dirty() uses cma_obj */
-   fbi->screen_buffer = cma_obj->vaddr;
-   /* fb_deferred_io_fault() needs a physical address */
-   fbi->fix.smem_start = page_to_phys(virt_to_page(fbi->screen_buffer));
-
-   *fbops = *fbi->fbops;
-   fbi->fbops = fbops;
-
-   fbdefio->delay = msecs_to_jiffies(DEFAULT_FBDEFIO_DELAY_MS);
-   fbdefio->deferred_io = drm_fb_helper_deferred_io;
-   fbi->fbdefio = fbdefio;
-

[PATCH v5 6/8] drm/fb-helper: Finish the generic fbdev emulation

This adds a drm_fbdev_generic_setup() function that sets up generic
fbdev emulation with client callbacks for restore, hotplug and
unregister.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 117 
 include/drm/drm_fb_helper.h |   7 +++
 2 files changed, 124 insertions(+)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index bea3a0cb324a..e2f0db1432aa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -67,6 +67,9 @@ static DEFINE_MUTEX(kernel_fb_helper_lock);
  * helper functions used by many drivers to implement the kernel mode setting
  * interfaces.
  *
+ * Drivers that support a dumb buffer with a virtual address and mmap support,
+ * should try out the generic fbdev emulation using drm_fbdev_generic_setup().
+ *
  * Setup fbdev emulation by calling drm_fb_helper_fbdev_setup() and tear it
  * down by calling drm_fb_helper_fbdev_teardown().
  *
@@ -3118,6 +3121,120 @@ int drm_fb_helper_generic_probe(struct drm_fb_helper 
*fb_helper,
 }
 EXPORT_SYMBOL(drm_fb_helper_generic_probe);
 
+static const struct drm_fb_helper_funcs drm_fb_helper_generic_funcs = {
+   .fb_probe = drm_fb_helper_generic_probe,
+};
+
+static void drm_fbdev_client_unregister(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+   if (fb_helper->fbdev) {
+   drm_fb_helper_unregister_fbi(fb_helper);
+   /* drm_fbdev_fb_destroy() takes care of cleanup */
+   return;
+   }
+
+   /* Did drm_fb_helper_fbdev_setup() run? */
+   if (fb_helper->dev)
+   drm_fb_helper_fini(fb_helper);
+
+   drm_client_release(client);
+   kfree(fb_helper);
+}
+
+static int drm_fbdev_client_restore(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+
+   drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
+
+   return 0;
+}
+
+static int drm_fbdev_client_hotplug(struct drm_client_dev *client)
+{
+   struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
+   struct drm_device *dev = client->dev;
+   int ret;
+
+   /* If drm_fb_helper_fbdev_setup() failed, we only try once */
+   if (!fb_helper->dev && fb_helper->funcs)
+   return 0;
+
+   if (dev->fb_helper)
+   return drm_fb_helper_hotplug_event(dev->fb_helper);
+
+   if (!dev->mode_config.num_connector)
+   return 0;
+
+   ret = drm_fb_helper_fbdev_setup(dev, fb_helper, 
_fb_helper_generic_funcs,
+   fb_helper->preferred_bpp, 0);
+   if (ret) {
+   fb_helper->dev = NULL;
+   fb_helper->fbdev = NULL;
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct drm_client_funcs drm_fbdev_client_funcs = {
+   .owner  = THIS_MODULE,
+   .unregister = drm_fbdev_client_unregister,
+   .restore= drm_fbdev_client_restore,
+   .hotplug= drm_fbdev_client_hotplug,
+};
+
+/**
+ * drm_fb_helper_generic_fbdev_setup() - Setup generic fbdev emulation
+ * @dev: DRM device
+ * @preferred_bpp: Preferred bits per pixel for the device.
+ * @dev->mode_config.preferred_depth is used if this is zero.
+ *
+ * This function sets up generic fbdev emulation for drivers that supports
+ * dumb buffers with a virtual address and that can be mmap'ed.
+ *
+ * Restore, hotplug events and teardown are all taken care of. Drivers that do
+ * suspend/resume need to call drm_fb_helper_set_suspend_unlocked() themselves.
+ * Simple drivers might use drm_mode_config_helper_suspend().
+ *
+ * Drivers that set the dirty callback on their framebuffer will get a shadow
+ * fbdev buffer that is blitted onto the real buffer. This is done in order to
+ * make deferred I/O work with all kinds of buffers.
+ *
+ * This function is safe to call even when there are no connectors present.
+ * Setup will be retried on the next hotplug event.
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_fbdev_generic_setup(struct drm_device *dev, unsigned int preferred_bpp)
+{
+   struct drm_fb_helper *fb_helper;
+   int ret;
+
+   if (!drm_fbdev_emulation)
+   return 0;
+
+   fb_helper = kzalloc(sizeof(*fb_helper), GFP_KERNEL);
+   if (!fb_helper)
+   return -ENOMEM;
+
+   ret = drm_client_new(dev, _helper->client, "fbdev", 
_fbdev_client_funcs);
+   if (ret) {
+   kfree(fb_helper);
+   return ret;
+   }
+
+   fb_helper->preferred_bpp = preferred_bpp;
+
+   drm_fbdev_client_hotplug(_helper->client);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_fbdev_generic_setup);
+
 /* The Kconfig DRM_KMS_HELPER selects FRAMEBUFFER_CONSOLE (if !EXPERT)
  * but the module doesn't depend on

[PATCH v5 1/8] drm: Begin an API for in-kernel clients

This the beginning of an API for in-kernel clients.
First out is a way to get a framebuffer backed by a dumb buffer.

Only GEM drivers are supported.
The original idea of using an exported dma-buf was dropped because it
also creates an anonomous file descriptor which doesn't work when the
buffer is created from a kernel thread. The easy way out is to use
drm_driver.gem_prime_vmap to get the virtual address, which requires a
GEM object. This excludes the vmwgfx driver which is the only non-GEM
driver apart from the legacy ones. A solution for vmwgfx will have to be
worked out later if it wants to support the client API which it probably
will when we have a bootsplash client.

Suggested-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 Documentation/gpu/drm-client.rst   |  12 ++
 Documentation/gpu/index.rst|   1 +
 drivers/gpu/drm/Makefile   |   2 +-
 drivers/gpu/drm/drm_client.c   | 387 +
 drivers/gpu/drm/drm_drv.c  |   8 +
 drivers/gpu/drm/drm_file.c |   3 +
 drivers/gpu/drm/drm_probe_helper.c |   3 +
 include/drm/drm_client.h   | 136 +
 include/drm/drm_device.h   |  21 ++
 9 files changed, 572 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/gpu/drm-client.rst
 create mode 100644 drivers/gpu/drm/drm_client.c
 create mode 100644 include/drm/drm_client.h

diff --git a/Documentation/gpu/drm-client.rst b/Documentation/gpu/drm-client.rst
new file mode 100644
index ..7e672063e7eb
--- /dev/null
+++ b/Documentation/gpu/drm-client.rst
@@ -0,0 +1,12 @@
+=
+Kernel clients
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+   :doc: overview
+
+.. kernel-doc:: include/drm/drm_client.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_client.c
+   :export:
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index 00288f34c5a6..1fcf8e851e15 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide
drm-kms
drm-kms-helpers
drm-uapi
+   drm-client
drivers
vga-switcheroo
vgaarbiter
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 69c13517ea3a..d6657a61d037 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -18,7 +18,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \
-   drm_syncobj.o drm_lease.o drm_writeback.o
+   drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o
 
 drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
 drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
new file mode 100644
index ..743495f7f833
--- /dev/null
+++ b/drivers/gpu/drm/drm_client.c
@@ -0,0 +1,387 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm_crtc_internal.h"
+#include "drm_internal.h"
+
+/**
+ * DOC: overview
+ *
+ * This library provides support for clients running in the kernel like fbdev 
and bootsplash.
+ * Currently it's only partially implemented, just enough to support fbdev.
+ *
+ * GEM drivers which provide a GEM based dumb buffer with a virtual address 
are supported.
+ */
+
+static int drm_client_open(struct drm_client_dev *client)
+{
+   struct drm_device *dev = client->dev;
+   struct drm_file *file;
+
+   file = drm_file_alloc(dev->primary);
+   if (IS_ERR(file))
+   return PTR_ERR(file);
+
+   mutex_lock(>filelist_mutex);
+   list_add(>lhead, >filelist_internal);
+   mutex_unlock(>filelist_mutex);
+
+   client->file = file;
+
+   return 0;
+}
+
+static void drm_client_close(struct drm_client_dev *client)
+{
+   struct drm_device *dev = client->dev;
+
+   mutex_lock(>filelist_mutex);
+   list_del(>file->lhead);
+   mutex_unlock(>filelist_mutex);
+
+   drm_file_free(client->file);
+}
+EXPORT_SYMBOL(drm_client_close);
+
+/**
+ * drm_client_new - Create a DRM client
+ * @dev: DRM device
+ * @client: DRM client
+ * @name: Client name
+ * @funcs: DRM client functions (optional)
+ *
+ * The caller needs to hold a reference on @dev before calling this function.
+ * The client is freed when the _device is unregistered. See 
drm_client_release().
+ *
+ * Returns:
+ * Zero on success or negative error code on failure.
+ */
+int drm_client_new(struct drm_device *dev, struct drm_client_dev *client,
+  const char *name, const struct drm_client_funcs *funcs)
+{
+   bool registered;
+   int ret;
+
+

[PATCH v5 3/8] drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap

These are needed for pl111 to use the generic fbdev emulation.

Cc: Eric Anholt 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Eric Anholt 
---
 drivers/gpu/drm/pl111/pl111_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 054b93689d94..17a38e85ba7d 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -250,6 +250,8 @@ static struct drm_driver pl111_drm_driver = {
.gem_prime_import_sg_table = pl111_gem_import_sg_table,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
+   .gem_prime_mmap = drm_gem_cma_prime_mmap,
+   .gem_prime_vmap = drm_gem_cma_prime_vmap,
 
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = pl111_debugfs_init,
-- 
2.15.1

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

[PATCH v5 5/8] drm/debugfs: Add internal client debugfs file

Print the names of the internal clients currently attached.

Reviewed-by: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
---
 drivers/gpu/drm/drm_client.c  | 28 
 drivers/gpu/drm/drm_debugfs.c |  7 +++
 include/drm/drm_client.h  |  3 +++
 3 files changed, 38 insertions(+)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 743495f7f833..4039a4d103a8 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -385,3 +385,31 @@ void drm_client_framebuffer_delete(struct 
drm_client_buffer *buffer)
drm_client_buffer_delete(buffer);
 }
 EXPORT_SYMBOL(drm_client_framebuffer_delete);
+
+#ifdef CONFIG_DEBUG_FS
+static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_printer p = drm_seq_file_printer(m);
+   struct drm_client_dev *client;
+
+   mutex_lock(>clientlist_mutex);
+   list_for_each_entry(client, >clientlist, list)
+   drm_printf(, "%s\n", client->name);
+   mutex_unlock(>clientlist_mutex);
+
+   return 0;
+}
+
+static const struct drm_info_list drm_client_debugfs_list[] = {
+   { "internal_clients", drm_client_debugfs_internal_clients, 0 },
+};
+
+int drm_client_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(drm_client_debugfs_list,
+   ARRAY_SIZE(drm_client_debugfs_list),
+   minor->debugfs_root, minor);
+}
+#endif
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b2482818fee8..50a20bfc07ea 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -164,6 +165,12 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
DRM_ERROR("Failed to create framebuffer debugfs 
file\n");
return ret;
}
+
+   ret = drm_client_debugfs_init(minor);
+   if (ret) {
+   DRM_ERROR("Failed to create client debugfs file\n");
+   return ret;
+   }
}
 
if (dev->driver->debugfs_init) {
diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h
index 671052d80e38..989f8e52864d 100644
--- a/include/drm/drm_client.h
+++ b/include/drm/drm_client.h
@@ -10,6 +10,7 @@ struct drm_device;
 struct drm_file;
 struct drm_framebuffer;
 struct drm_gem_object;
+struct drm_minor;
 struct module;
 
 /**
@@ -133,4 +134,6 @@ struct drm_client_buffer *
 drm_client_framebuffer_create(struct drm_client_dev *client, u32 width, u32 
height, u32 format);
 void drm_client_framebuffer_delete(struct drm_client_buffer *buffer);
 
+int drm_client_debugfs_init(struct drm_minor *minor);
+
 #endif
-- 
2.15.1

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

[PATCH v5 0/8] drm: Add generic fbdev emulation

This patchset adds generic fbdev emulation for drivers that supports GEM
based dumb buffers which support .gem_prime_vmap and gem_prime_mmap. An
API is begun to support in-kernel clients in general.

I've squashed the client patches to ease review.
All patches have ack's and rb's so I'll apply this next week unless
something more comes up. It's taken me 6 months to get this done so I
look forward to getting it applied.

Thanks a lot Daniel for helping me make this happen!

Noralf.

Changes since version 4:
- Squash the two client patches to ease review.
- Remove drm_client_put() doc references.
- Remove drm_client_funcs->release, it's use went away in version 3.
- Add drm_client_dev_hotplug() doc

Changes since version 3:
- drm/cma-helper: Use the generic fbdev emulation: Fix error path
- Remove setting .lastclose in new tinydrm driver ili9341

Changes since version 2:
- Applied first 3 patches to drm-misc-next
- Drop client reference counting and only allow the driver to release
clients.

Noralf Trønnes (8):
  drm: Begin an API for in-kernel clients
  drm/fb-helper: Add generic fbdev emulation .fb_probe function
  drm/pl111: Set .gem_prime_vmap and .gem_prime_mmap
  drm/cma-helper: Use the generic fbdev emulation
  drm/debugfs: Add internal client debugfs file
  drm/fb-helper: Finish the generic fbdev emulation
  drm/tinydrm: Use drm_fbdev_generic_setup()
  drm/cma-helper: Remove drm_fb_cma_fbdev_init_with_funcs()

 Documentation/gpu/drm-client.rst|  12 +
 Documentation/gpu/index.rst |   1 +
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_client.c| 415 
 drivers/gpu/drm/drm_debugfs.c   |   7 +
 drivers/gpu/drm/drm_drv.c   |   8 +
 drivers/gpu/drm/drm_fb_cma_helper.c | 379 +++--
 drivers/gpu/drm/drm_fb_helper.c | 316 -
 drivers/gpu/drm/drm_file.c  |   3 +
 drivers/gpu/drm/drm_probe_helper.c  |   3 +
 drivers/gpu/drm/pl111/pl111_drv.c   |   2 +
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c |   3 +-
 drivers/gpu/drm/tinydrm/ili9225.c   |   1 -
 drivers/gpu/drm/tinydrm/ili9341.c   |   1 -
 drivers/gpu/drm/tinydrm/mi0283qt.c  |   1 -
 drivers/gpu/drm/tinydrm/st7586.c|   1 -
 drivers/gpu/drm/tinydrm/st7735r.c   |   1 -
 include/drm/drm_client.h| 139 ++
 include/drm/drm_device.h|  21 ++
 include/drm/drm_fb_cma_helper.h |   6 -
 include/drm/drm_fb_helper.h |  38 +++
 21 files changed, 1007 insertions(+), 353 deletions(-)
 create mode 100644 Documentation/gpu/drm-client.rst
 create mode 100644 drivers/gpu/drm/drm_client.c
 create mode 100644 include/drm/drm_client.h

-- 
2.15.1

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

[PATCH v5 2/8] drm/fb-helper: Add generic fbdev emulation .fb_probe function

This is the first step in getting generic fbdev emulation.
A drm_fb_helper_funcs.fb_probe function is added which uses the
DRM client API to get a framebuffer backed by a dumb buffer.

Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c | 199 +++-
 include/drm/drm_fb_helper.h |  31 +++
 2 files changed, 229 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index cab14f253384..bea3a0cb324a 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -30,6 +30,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -738,6 +739,24 @@ static void drm_fb_helper_resume_worker(struct work_struct 
*work)
console_unlock();
 }
 
+static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
+ struct drm_clip_rect *clip)
+{
+   struct drm_framebuffer *fb = fb_helper->fb;
+   unsigned int cpp = drm_format_plane_cpp(fb->format->format, 0);
+   size_t offset = clip->y1 * fb->pitches[0] + clip->x1 * cpp;
+   void *src = fb_helper->fbdev->screen_buffer + offset;
+   void *dst = fb_helper->buffer->vaddr + offset;
+   size_t len = (clip->x2 - clip->x1) * cpp;
+   unsigned int y;
+
+   for (y = clip->y1; y < clip->y2; y++) {
+   memcpy(dst, src, len);
+   src += fb->pitches[0];
+   dst += fb->pitches[0];
+   }
+}
+
 static void drm_fb_helper_dirty_work(struct work_struct *work)
 {
struct drm_fb_helper *helper = container_of(work, struct drm_fb_helper,
@@ -753,8 +772,12 @@ static void drm_fb_helper_dirty_work(struct work_struct 
*work)
spin_unlock_irqrestore(>dirty_lock, flags);
 
/* call dirty callback only when it has been really touched */
-   if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2)
+   if (clip_copy.x1 < clip_copy.x2 && clip_copy.y1 < clip_copy.y2) {
+   /* Generic fbdev uses a shadow buffer */
+   if (helper->buffer)
+   drm_fb_helper_dirty_blit_real(helper, _copy);
helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, _copy, 1);
+   }
 }
 
 /**
@@ -2921,6 +2944,180 @@ void drm_fb_helper_output_poll_changed(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_fb_helper_output_poll_changed);
 
+/* @user: 1=userspace, 0=fbcon */
+static int drm_fbdev_fb_open(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (!try_module_get(fb_helper->dev->driver->fops->owner))
+   return -ENODEV;
+
+   return 0;
+}
+
+static int drm_fbdev_fb_release(struct fb_info *info, int user)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   module_put(fb_helper->dev->driver->fops->owner);
+
+   return 0;
+}
+
+/*
+ * fb_ops.fb_destroy is called by the last put_fb_info() call at the end of
+ * unregister_framebuffer() or fb_release().
+ */
+static void drm_fbdev_fb_destroy(struct fb_info *info)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+   struct fb_info *fbi = fb_helper->fbdev;
+   struct fb_ops *fbops = NULL;
+   void *shadow = NULL;
+
+   if (fbi->fbdefio) {
+   fb_deferred_io_cleanup(fbi);
+   shadow = fbi->screen_buffer;
+   fbops = fbi->fbops;
+   }
+
+   drm_fb_helper_fini(fb_helper);
+
+   if (shadow) {
+   vfree(shadow);
+   kfree(fbops);
+   }
+
+   drm_client_framebuffer_delete(fb_helper->buffer);
+   /*
+* FIXME:
+* Remove conditional when all CMA drivers have been moved over to using
+* drm_fbdev_generic_setup().
+*/
+   if (fb_helper->client.funcs) {
+   drm_client_release(_helper->client);
+   kfree(fb_helper);
+   }
+}
+
+static int drm_fbdev_fb_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+   struct drm_fb_helper *fb_helper = info->par;
+
+   if (fb_helper->dev->driver->gem_prime_mmap)
+   return 
fb_helper->dev->driver->gem_prime_mmap(fb_helper->buffer->gem, vma);
+   else
+   return -ENODEV;
+}
+
+static struct fb_ops drm_fbdev_fb_ops = {
+   .owner  = THIS_MODULE,
+   DRM_FB_HELPER_DEFAULT_OPS,
+   .fb_open= drm_fbdev_fb_open,
+   .fb_release = drm_fbdev_fb_release,
+   .fb_destroy = drm_fbdev_fb_destroy,
+   .fb_mmap= drm_fbdev_fb_mmap,
+   .fb_read= drm_fb_helper_sys_read,
+   .fb_write   = drm_fb_helper_sys_write,
+   .fb_fillrect= drm_fb_helper_sys_fillrect,
+   .fb_copyarea= drm_fb_helper_sys_copyarea,
+   .fb_imageblit   = drm_fb_helper_sys_imageblit,
+};
+
+static struct fb_deferred_io drm_fbdev_defio = {
+   .delay  = HZ / 20,
+   .deferred_io

Re: [PATCH] drm/sun4i: Implement zpos for DE2

2018-07-03 Thread Paul Kocialkowski

On Wed, 2018-06-27 at 18:45 +0200, Jernej Skrabec wrote:
> Initial implementation of DE2 planes only supported fixed zpos.
> 
> Expand implementation with configurable zpos property.

Thanks for adding support for this! Tested with the Sunxi-Cedrus VPU
driver on H3 with:
https://github.com/free-electrons/cedrus-frame-test/commit/9f46aa83cae1b9fa4d4901d3d2999c8d41265532

Tested-by: Paul Kocialkowski 

> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/sun4i/sun8i_mixer.c| 15 +++--
>  drivers/gpu/drm/sun4i/sun8i_mixer.h|  4 +++
>  drivers/gpu/drm/sun4i/sun8i_ui_layer.c | 45 --
>  drivers/gpu/drm/sun4i/sun8i_vi_layer.c | 45 --
>  4 files changed, 72 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> index ee8febb25903..0747a9a69654 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> @@ -260,6 +260,17 @@ const struct de2_fmt_info *sun8i_mixer_format_info(u32 
> format)
>   return NULL;
>  }
>  
> +static void sun8i_mixer_atomic_begin(struct sunxi_engine *engine,
> +  struct drm_crtc_state *old_state)
> +{
> + /*
> +  * Disable all pipes at the beginning. They will be enabled
> +  * again if needed in plane update callback.
> +  */
> + regmap_update_bits(engine->regs, SUN8I_MIXER_BLEND_PIPE_CTL,
> +SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSK, 0);
> +}
> +
>  static void sun8i_mixer_commit(struct sunxi_engine *engine)
>  {
>   DRM_DEBUG_DRIVER("Committing changes\n");
> @@ -311,6 +322,7 @@ static struct drm_plane **sun8i_layers_init(struct 
> drm_device *drm,
>  }
>  
>  static const struct sunxi_engine_ops sun8i_engine_ops = {
> + .atomic_begin   = sun8i_mixer_atomic_begin,
>   .commit = sun8i_mixer_commit,
>   .layers_init= sun8i_layers_init,
>  };
> @@ -432,9 +444,6 @@ static int sun8i_mixer_bind(struct device *dev, struct 
> device *master,
>   regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ATTR_FCOLOR(0),
>SUN8I_MIXER_BLEND_COLOR_BLACK);
>  
> - /* Fixed zpos for now */
> - regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_ROUTE, 0x43210);
> -
>   plane_cnt = mixer->cfg->vi_num + mixer->cfg->ui_num;
>   for (i = 0; i < plane_cnt; i++)
>   regmap_write(mixer->engine.regs, SUN8I_MIXER_BLEND_MODE(i),
> diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.h 
> b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> index f34e70c42adf..406c42e752d7 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_mixer.h
> +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.h
> @@ -44,6 +44,7 @@
>  #define SUN8I_MIXER_BLEND_CK_MIN(x)  (0x10e0 + 0x04 * (x))
>  #define SUN8I_MIXER_BLEND_OUTCTL 0x10fc
>  
> +#define SUN8I_MIXER_BLEND_PIPE_CTL_EN_MSKGENMASK(12, 8)
>  #define SUN8I_MIXER_BLEND_PIPE_CTL_EN(pipe)  BIT(8 + pipe)
>  #define SUN8I_MIXER_BLEND_PIPE_CTL_FC_EN(pipe)   BIT(pipe)
>  /* colors are always in AARRGGBB format */
> @@ -51,6 +52,9 @@
>  /* The following numbers are some still unknown magic numbers */
>  #define SUN8I_MIXER_BLEND_MODE_DEF   0x03010301
>  
> +#define SUN8I_MIXER_BLEND_ROUTE_PIPE_MSK(n)  (0xf << ((n) << 2))
> +#define SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(n)((n) << 2)
> +
>  #define SUN8I_MIXER_BLEND_OUTCTL_INTERLACED  BIT(1)
>  
>  #define SUN8I_MIXER_FBFMT_ARGB   0
> diff --git a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c 
> b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> index 9a540330cb79..518e1921f47e 100644
> --- a/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun8i_ui_layer.c
> @@ -27,7 +27,7 @@
>  #include "sun8i_ui_scaler.h"
>  
>  static void sun8i_ui_layer_enable(struct sun8i_mixer *mixer, int channel,
> -   int overlay, bool enable)
> +   int overlay, bool enable, unsigned int zpos)
>  {
>   u32 val;
>  
> @@ -43,18 +43,24 @@ static void sun8i_ui_layer_enable(struct sun8i_mixer 
> *mixer, int channel,
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR(channel, overlay),
>  SUN8I_MIXER_CHAN_UI_LAYER_ATTR_EN, val);
>  
> - if (enable)
> - val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel);
> - else
> - val = 0;
> + if (enable) {
> + val = SUN8I_MIXER_BLEND_PIPE_CTL_EN(zpos);
>  
> - regmap_update_bits(mixer->engine.regs,
> -SUN8I_MIXER_BLEND_PIPE_CTL,
> -SUN8I_MIXER_BLEND_PIPE_CTL_EN(channel), val);
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_PIPE_CTL, val, val);
> +
> + val = channel << SUN8I_MIXER_BLEND_ROUTE_PIPE_SHIFT(zpos);
> +
> + regmap_update_bits(mixer->engine.regs,
> +SUN8I_MIXER_BLEND_ROUTE,
> +

Re: [PATCH v2 1/2] efi/bgrt: Drop __initdata from bgrt_image_size

On Monday, July 02, 2018 02:02:47 PM Ard Biesheuvel wrote:
> On 2 July 2018 at 13:57, Bartlomiej Zolnierkiewicz
>  wrote:
> > On Monday, July 02, 2018 01:46:09 PM Ard Biesheuvel wrote:
> >> On 2 July 2018 at 13:26, Hans de Goede  wrote:
> >> > Bartlomiej,
> >> >
> >> > Now that the fbcon deferred console takeover patches have been
> >> > merged I believe this series can be merged too ?
> >> >
> >> > Note the first patch has an ack from Ard for merging the
> >> > 1 line efi change through the fbdev tree.
> >> >
> >>
> >> ... or I could take everything through the efi tree instead, as
> >> already discussed between Bartlomiej and me in the context of another
> >> patch series that touches both the fbdev and efi trees.
> >>
> >> Bartlomiej, that would require your ack on patch
> >>
> >> [PATCH v2 2/2] efifb: Copy the ACPI BGRT boot graphics to the framebuffer
> >>
> >> https://marc.info/?l=linux-fbdev=152933484616993=2
> >>
> >> so if you're ok with that, I will queue both of these for v4.19
> >
> > I would really prefer to merge this patchset through fbdev tree
> > as efi tree doesn't have fbcon deferred console takeover patches
> > (which are required by efifb changes under discussion).
> >
> 
> Ah ok, I didn't realise that. I don't think there will be any
> conflicts, since the efifb changes in the efi tree and these changes
> operate on different parts of the file. But let's double check before
> taking stuff into -next.
> (efi/next is not pulled into -next directly, but via the tip:efi tree,
> and I haven't sent a pull request yet for v4.19)

I've verified this with -next from today and it auto-merged fine (for
testing purposes I've applied both patches to -next and then pulled in
efi/next from efi.git tree).

I've applied both patches to fbdev-for-next (I hope it is fine with you).

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

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

mikita.lip...@amd.com  changed:

   What|Removed |Added

 CC||mikita.lip...@amd.com

--- Comment #6 from mikita.lip...@amd.com  ---
I have just

-- 
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] video: fbdev: simplefb: Stop including

On Tuesday, June 19, 2018 07:22:21 PM Geert Uytterhoeven wrote:
> Simplefb is not a clock provider, but it uses of_clk_get_parent_count(),
> so it can just include  instead.
> 
> Signed-off-by: Geert Uytterhoeven 

Patch queued for 4.19, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH v2 6/8] drm/dsi: add helper function to find the second host in a dual-dsi setup

2018-07-03 Thread Andrzej Hajda

On 18.06.2018 12:28, Heiko Stuebner wrote:
> >From a specified output port of one dsi controller this function allows to
> iterate over the list of registered dsi controllers trying to find a second
> instance connected to the same display, like it is used in dual-dsi setups.
>
> Signed-off-by: Heiko Stuebner 

The code looks hacky to me - it iterates over external nodes, it assumes
all graph links are dedicated exclusively to dsi, it assumes that there
is no additional node between dsi host and the panel.
Anyway let's skip it for a moment, and look at the following patches.

Regards
Andrzej

> ---
>  drivers/gpu/drm/drm_mipi_dsi.c | 56 ++
>  include/drm/drm_mipi_dsi.h |  2 ++
>  2 files changed, 58 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index bc73b7f5b9fc..0c3c9c7aa3b8 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -30,6 +30,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -282,6 +283,61 @@ struct mipi_dsi_host 
> *of_find_mipi_dsi_host_by_node(struct device_node *node)
>  }
>  EXPORT_SYMBOL(of_find_mipi_dsi_host_by_node);
>  
> +struct device_node *of_mipi_dsi_find_second_host(struct device_node 
> *first_np,
> +  int port, int endpoint)
> +{
> + struct mipi_dsi_host *first, *host;
> + struct device_node *remote, *np, *second_np = NULL;
> + int num = 0;
> +
> + first = of_find_mipi_dsi_host_by_node(first_np);
> + if (!first) {
> + pr_err("no dsi-host for node %s\n", first_np->full_name);
> + return ERR_PTR(-ENODEV);
> + }
> +
> + /* output-node of the known dsi-host */
> + remote = of_graph_get_remote_node(first_np, port, endpoint);
> + if (!remote) {
> + dev_err(first->dev, "no output node found\n");
> + return ERR_PTR(-ENODEV);
> + }
> +
> + mutex_lock(_lock);
> +
> + list_for_each_entry(host, _list, list) {
> + np = of_graph_get_remote_node(host->dev->of_node,
> +   port, endpoint);
> +
> + /* found a host connected to this panel */
> + if (np == remote)
> + num++;
> +
> + /* found one second host */
> + if (host->dev->of_node != first_np)
> + second_np = host->dev->of_node;
> +
> + of_node_put(np);
> + }
> +
> + /* of_node_get the node under host_lock */
> + if (num == 2)
> + of_node_get(second_np);
> +
> + mutex_unlock(_lock);
> +
> + of_node_put(remote);
> +
> + if (num > 2) {
> + dev_err(first->dev,
> +   "too many DSI links for output: %d links\n", num);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + return second_np;
> +}
> +EXPORT_SYMBOL(of_mipi_dsi_find_second_host);
> +
>  int mipi_dsi_host_register(struct mipi_dsi_host *host)
>  {
>   struct device_node *node;
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 4fef19064b0f..89532ae69c91 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -107,6 +107,8 @@ struct mipi_dsi_host {
>  int mipi_dsi_host_register(struct mipi_dsi_host *host);
>  void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>  struct mipi_dsi_host *of_find_mipi_dsi_host_by_node(struct device_node 
> *node);
> +struct device_node *of_mipi_dsi_find_second_host(struct device_node 
> *first_np,
> +  int port, int endpoint);
>  
>  /* DSI mode flags */
>  


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

Re: [PATCH 18/21] udlfb: allow reallocating the framebuffer

On Tuesday, June 12, 2018 12:32:34 PM Mikulas Patocka wrote:
> 
> On Mon, 4 Jun 2018, kbuild test robot wrote:
> 
> > Hi Mikulas,
> > 
> > I love your patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on drm/drm-next]
> > [also build test WARNING on v4.17-rc7 next-20180601]
> > [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/Mikulas-Patocka/USB-DisplayLink-patches/20180603-233013
> 
> What is it really complaining about? That URL shows 404 Not Found and this 
> email has no warnings at all.

screen_base in struct fb_info is annotated with __iomem tag:

...
char __iomem *screen_base;  /* Virtual address */
...

and this tag should be preserved (or explicitly casted).

> > base:   git://people.freedesktop.org/~airlied/linux.git drm-next
> > reproduce:
> > # apt-get install sparse
> > make ARCH=x86_64 allmodconfig
> > make C=1 CF=-D__CHECK_ENDIAN__

You should be able to reproduce the issue with the above sequence.

> > sparse warnings: (new ones prefixed by >>)

[...]

> >   1178  u32 old_len = info->fix.smem_len;
> > > 1179  unsigned char *old_fb = info->screen_base;
> >   1180  unsigned char *new_fb;

[...]

> >   1196  if (info->screen_base) {
> >   1197  memcpy(new_fb, old_fb, old_len);
> > > 1198  dlfb_deferred_vfree(dlfb, 
> > > info->screen_base);
> >   1199  }

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH] fb: fix lost console when the user unplugs a USB adapter


Hi,

On Sunday, June 03, 2018 11:46:29 AM Mikulas Patocka wrote:
> I have a USB display adapter using the udlfb driver and I use it on an ARM
> board that doesn't have any graphics card. When I plug the adapter in, the
> console is properly displayed, however when I unplug and re-plug the
> adapter, the console is not displayed and I can't access it until I reboot
> the board.
> 
> The reason is this:
> When the adapter is unplugged, dlfb_usb_disconnect calls
> unlink_framebuffer, then it waits until the reference count drops to zero
> and then it deallocates the framebuffer. However, the console that is
> attached to the framebuffer device keeps the reference count non-zero, so
> the framebuffer device is never destroyed. When the USB adapter is plugged
> again, it creates a new device /dev/fb1 and the console is not attached to
> it.
> 
> This patch fixes the bug by unbinding the console from unlink_framebuffer.
> The code to unbind the console is moved from do_unregister_framebuffer to
> a function unbind_console. When the console is unbound, the reference
> count drops to zero and the udlfb driver frees the framebuffer. When the
> adapter is plugged back, a new framebuffer is created and the console is
> attached to it.
> 
> Signed-off-by: Mikulas Patocka 
> Cc: sta...@vger.kernel.org

After this change unbind_console() will be called twice in the standard
framebuffer unregister path:

- first time, directly by do_unregister_framebuffer()

- second time, indirectly by do_unregister_framebuffer()->unlink_framebuffer()

This doesn't look correctly.

Also why can't udlfb just use unregister_framebuffer() like all other
drivers (it uses unlink_framebuffer() and it is the only user of this
helper)?

> ---
>  drivers/video/fbdev/core/fbmem.c |   21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> Index: linux-4.16.12/drivers/video/fbdev/core/fbmem.c
> ===
> --- linux-4.16.12.orig/drivers/video/fbdev/core/fbmem.c   2018-05-26 
> 06:13:20.0 +0200
> +++ linux-4.16.12/drivers/video/fbdev/core/fbmem.c2018-05-26 
> 06:13:20.0 +0200
> @@ -1805,12 +1805,12 @@ static int do_register_framebuffer(struc
>   return 0;
>  }
>  
> -static int do_unregister_framebuffer(struct fb_info *fb_info)
> +static int unbind_console(struct fb_info *fb_info)
>  {
>   struct fb_event event;
> - int i, ret = 0;
> + int ret;
> + int i = fb_info->node;
>  
> - i = fb_info->node;
>   if (i < 0 || i >= FB_MAX || registered_fb[i] != fb_info)
>   return -EINVAL;
>  
> @@ -1825,6 +1825,16 @@ static int do_unregister_framebuffer(str
>   unlock_fb_info(fb_info);
>   console_unlock();
>  
> + return ret;
> +}
> +
> +static int do_unregister_framebuffer(struct fb_info *fb_info)
> +{
> + struct fb_event event;
> + int ret;
> +
> + ret = unbind_console(fb_info);
> +
>   if (ret)
>   return -EINVAL;
>  
> @@ -1835,7 +1845,7 @@ static int do_unregister_framebuffer(str
>   (fb_info->pixmap.flags & FB_PIXMAP_DEFAULT))
>   kfree(fb_info->pixmap.addr);
>   fb_destroy_modelist(_info->modelist);
> - registered_fb[i] = NULL;
> + registered_fb[fb_info->node] = NULL;
>   num_registered_fb--;
>   fb_cleanup_device(fb_info);
>   event.info = fb_info;
> @@ -1860,6 +1870,9 @@ int unlink_framebuffer(struct fb_info *f
>   device_destroy(fb_class, MKDEV(FB_MAJOR, i));
>   fb_info->dev = NULL;
>   }
> +
> + unbind_console(fb_info);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(unlink_framebuffer);

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [amdgpu][tahiti xt] cursor motion smoothness

2018-07-03 Thread sylvain . bertrand

On Tue, Jul 03, 2018 at 11:01:46AM +0200, Michel Dänzer wrote:
> Also make sure you do not pass -dumbSched on the Xorg command line, and
> do not disable Option "SilkenMouse" in xorg.conf.

No pb on this side. I tried to enable -dumbSched, I could not see any
difference.

I did run a fast moving game at 60Hz, it was horrible, I ran it at 144Hz,
smooth... the culprit may well be the monitor or my eyes.

Don't bother anyway, I'll wait for a more solid element of comparison. If I get
one which is obvious to my eyes, I will get back to you on this matter.

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

Re: [amdgpu][tahiti xt] cursor motion smoothness

2018-07-03 Thread sylvain . bertrand

On Tue, Jul 03, 2018 at 10:54:15AM +0200, Michel Dänzer wrote:
> Unless your xserver build ends up with INPUTTHREAD undefined for some
> reason, input events are processed in a separate thread, and the HW
> cursor position is updated accordingly ASAP.

I did check on that: INPUTTHREAD is properly defined.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] omapfb: encoder-tpd12s015: fix error return code

On Sunday, June 10, 2018 04:24:13 PM Julia Lawall wrote:
> Return an error code on failure.
> 
> Problem found using Coccinelle.
> 
> Signed-off-by: Julia Lawall 

Patch queued for 4.19, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH v2 3/3] video: fbdev: Set pixclock = 0 in goldfishfb

On Friday, June 08, 2018 12:11:00 PM r...@google.com wrote:
> From: Christoffer Dall 
> 
> User space Android code identifies pixclock == 0 as a sign for emulation
> and will set the frame rate to 60 fps when reading this value, which is
> the desired outcome.
> 
> Signed-off-by: Christoffer Dall 
> Signed-off-by: Peter Maydell 
> Signed-off-by: Roman Kiryanov 

Patch queued for 4.19, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH v2 2/3] video: fbdev: Enable ACPI-based enumeration for goldfishfb

On Friday, June 08, 2018 12:10:59 PM r...@google.com wrote:
> From: Yu Ning 
> 
> Add an ACPI id to make goldfish framebuffer to support ACPI enumeration.
> 
> Signed-off-by: Yu Ning 
> Signed-off-by: Roman Kiryanov 

Patch queued for 4.19, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH v2 1/3] video: fbdev: Fix checkpatch warnings in goldfishfb.c

On Friday, June 08, 2018 12:10:58 PM r...@google.com wrote:
> From: Roman Kiryanov 
> 
> Address issues pointed by checkpatch.pl
> 
> Signed-off-by: Roman Kiryanov 

Patch queued for 4.19, thanks.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

2018-07-03 Thread Christian König

Am 03.07.2018 um 15:11 schrieb Daniel Vetter:

On Tue, Jul 03, 2018 at 03:02:11PM +0200, Christian König wrote:

Am 03.07.2018 um 14:52 schrieb Daniel Vetter:

On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:

Am 25.06.2018 um 11:12 schrieb Daniel Vetter:

On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:

On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:

First step towards unpinned DMA buf operation.

I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.

v2: reordered

Signed-off-by: Christian König

Reviewed-by: Daniel Vetter

Ok I did review drivers a bit, but apparently not well enough by far. i915
CI is unhappy:

https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html

So yeah inserting that lock in there isn't the most trivial thing :-/

I kinda assume that other drivers will have similar issues, e.g. omapdrm's
use of dev->struct_mutex also very much looks like it'll result in a new
locking inversion.

Ah, crap. Already feared that this wouldn't be easy, but yeah that it is as
bad as this is rather disappointing.

Thanks for the info, going to keep thinking about how to solve those issues.

Side note: We want to make sure that drivers don't get the reservation_obj
locking hierarchy wrong in other places (using dev->struct_mutex is kinda
a pre-existing mis-use that we can't wish away retroactively
unfortunately). One really important thing is that shrinker vs resv_obj
must work with trylocks in the shrinker, so that you can allocate memory
while holding reservation objects.

One neat trick to teach lockdep about this would be to have a dummy

if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
ww_mutex_lock(dma_buf->resv_obj);
fs_reclaim_acquire(GFP_KERNEL);
fs_reclaim_release(GFP_KERNEL);
ww_mutex_unlock(dma_buf->resv_obj);
}

in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
successfully to improve our igt test coverage for i915.ko in other areas.

Totally unrelated to dev->struct_mutex, but thoughts? Well for
dev->struct_mutex we could at least decide on one true way to nest
resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
much that would help.

I don't think that would help. As far as I can see we only have two choices:

1. Either have a big patch which fixes all DMA-buf implementations to allow
the reservation lock to be held during map/unmap (unrealistic).

2. Add a flag to at least in the mid term tell the DMA-buf helper functions
what to do. E.g. create the mapping without the reservation lock held.

How about moving the SGL caching from the DRM layer into the DMA-buf layer
and add a flag if the exporter wants/needs this caching?

Then only the implementations which can deal with dynamic invalidation
disable SGL caching and with it enable creating the sgl with the reservation
object locked.

This way we can kill two birds with one stone by both avoiding the SGL
caching in the DRM layer as well as having a sane handling for the locking.

Thoughts?

I don't see how the SGL stuff factors into neither the dev->struct_mutex
nor into the need to do allocations while holding resv_obj. Neither
changes by moving that piece around. At least as far as I can see it SGL
caching is fully orthogonal to any kind of locking fun.

Why do you see a connection here?

When the exporter's map_dma_buf() callback can't be called with the
reservation lock held we must call it before taking the lock.

Now importers able to deal with dynamic invalidation always want to call
the callback with the reservation lock held. Otherwise they would have
two different code paths, one for the dynamic invalidation and one for
the pinning.

One possibility to solve that problem is to call map_dma_buf() during
the attach phase and cache the resulting sg_table in the attach object.

Only when the exporter says: Ok I can deal with the reservation lock
held during the map_dma_buf() callback we disable the caching.

The only possible drawback I can see is that we now always cache the
sg_table in the DMA-buf handling, while previously we have done it in
the DRM midlayer.

Christian.

-Daniel

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

Re: [PATCH v4 5/9] drm/client: Add client callbacks

2018-07-03 Thread Daniel Vetter

On Tue, Jul 03, 2018 at 03:07:50PM +0200, Noralf Trønnes wrote:
> 
> Den 03.07.2018 09.46, skrev Daniel Vetter:
> > On Mon, Jul 02, 2018 at 03:54:29PM +0200, Noralf Trønnes wrote:
> > > Add client callbacks and hook them up.
> > > Add a list of clients per drm_device.
> > > 
> > > Signed-off-by: Noralf Trønnes 
> > btw for reviewing it'd be simpler if you merge the 2 patches that add the
> > client library, avoids me having to jump back ..
> > 
> > Bunch of comments below still.
> > -Daniel
> > 
> > > ---
> > >   drivers/gpu/drm/drm_client.c| 92 
> > > -
> > >   drivers/gpu/drm/drm_drv.c   |  7 +++
> > >   drivers/gpu/drm/drm_fb_cma_helper.c |  2 +-
> > >   drivers/gpu/drm/drm_fb_helper.c | 11 -
> > >   drivers/gpu/drm/drm_file.c  |  3 ++
> > >   drivers/gpu/drm/drm_probe_helper.c  |  3 ++
> > >   include/drm/drm_client.h| 75 +-
> > >   include/drm/drm_device.h| 14 ++
> > >   8 files changed, 201 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > > index 9c9b8ac7aea3..f05ee98bd10c 100644
> > > --- a/drivers/gpu/drm/drm_client.c
> > > +++ b/drivers/gpu/drm/drm_client.c
> > > @@ -4,6 +4,7 @@
> > >*/
> > >   #include 
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -66,6 +67,7 @@ EXPORT_SYMBOL(drm_client_close);
> > >* @dev: DRM device
> > >* @client: DRM client
> > >* @name: Client name
> > > + * @funcs: DRM client functions (optional)
> > >*
> > >* Use drm_client_put() to free the client.
> > >*
> > > @@ -73,24 +75,47 @@ EXPORT_SYMBOL(drm_client_close);
> > >* Zero on success or negative error code on failure.
> > >*/
> > >   int drm_client_new(struct drm_device *dev, struct drm_client_dev 
> > > *client,
> > > -const char *name)
> > > +const char *name, const struct drm_client_funcs *funcs)
> > >   {
> > > + bool registered;
> > >   int ret;
> > >   if (!drm_core_check_feature(dev, DRIVER_MODESET) ||
> > >   !dev->driver->dumb_create || !dev->driver->gem_prime_vmap)
> > >   return -ENOTSUPP;
> > > + if (funcs && !try_module_get(funcs->owner))
> > > + return -ENODEV;
> > > +
> > >   client->dev = dev;
> > >   client->name = name;
> > > + client->funcs = funcs;
> > >   ret = drm_client_open(client);
> > >   if (ret)
> > > - return ret;
> > > + goto err_put_module;
> > > +
> > > + mutex_lock(>clientlist_mutex);
> > > + registered = dev->registered;
> > > + if (registered)
> > > + list_add(>list, >clientlist);
> > > + mutex_unlock(>clientlist_mutex);
> > > + if (!registered) {
> > > + ret = -ENODEV;
> > > + goto err_close;
> > > + }
> > >   drm_dev_get(dev);
> > This only works if the caller holds a reference for us on dev already, or
> > has some other guarantee that it won't disappear. Would be good to mention
> > this in the kerneldoc.
> > 
> > >   return 0;
> > > +
> > > +err_close:
> > > + drm_client_close(client);
> > > +err_put_module:
> > > + if (funcs)
> > > + module_put(funcs->owner);
> > > +
> > > + return ret;
> > >   }
> > >   EXPORT_SYMBOL(drm_client_new);
> > > @@ -116,9 +141,72 @@ void drm_client_release(struct drm_client_dev 
> > > *client)
> > >   drm_client_close(client);
> > >   drm_dev_put(dev);
> > > + if (client->funcs)
> > > + module_put(client->funcs->owner);
> > >   }
> > >   EXPORT_SYMBOL(drm_client_release);
> > > +void drm_client_dev_unregister(struct drm_device *dev)
> > > +{
> > > + struct drm_client_dev *client, *tmp;
> > > +
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > + return;
> > > +
> > > + mutex_lock(>clientlist_mutex);
> > > + list_for_each_entry_safe(client, tmp, >clientlist, list) {
> > > + list_del(>list);
> > > + if (client->funcs && client->funcs->unregister) {
> > > + client->funcs->unregister(client);
> > Hm, not ->unregister is called while holding the lock. I thought that
> > blows up for you?
> 
> It is fine now that we decided that the client can't remove itself.
> Only the driver can do it on drm_dev_unregister().

I was more wondering about creating an unecessary locking hierarchy
complication. But through the ->hotplug and ->restore callbacks we already
require that all client locks (which will also include anything related to
fbdev and fbcon, hence also console_lock) must nest within
dev->clientlist_mutex. That's the part I was worried about, but that's not
a good concern really.

So all fine for me on 2nd thought.
> 
> > > + } else {
> > > + drm_client_release(client);
> > > + kfree(client);
> > > + }
> > > + }
> > > + mutex_unlock(>clientlist_mutex);
> > > +}
> > > +
> > Needs a bit of kerneldoc here

Re: [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

2018-07-03 Thread Daniel Vetter

On Tue, Jul 03, 2018 at 03:02:11PM +0200, Christian König wrote:
> Am 03.07.2018 um 14:52 schrieb Daniel Vetter:
> > On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote:
> > > Am 25.06.2018 um 11:12 schrieb Daniel Vetter:
> > > > On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote:
> > > > > On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote:
> > > > > > First step towards unpinned DMA buf operation.
> > > > > > 
> > > > > > I've checked the DRM drivers to potential locking of the reservation
> > > > > > object, but essentially we need to audit all implementations of the
> > > > > > dma_buf _ops for this to work.
> > > > > > 
> > > > > > v2: reordered
> > > > > > 
> > > > > > Signed-off-by: Christian König 
> > > > > Reviewed-by: Daniel Vetter 
> > > > Ok I did review drivers a bit, but apparently not well enough by far. 
> > > > i915
> > > > CI is unhappy:
> > > > 
> > > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_9400/fi-whl-u/igt@gem_mmap_...@basic-small-bo-tiledx.html
> > > > 
> > > > So yeah inserting that lock in there isn't the most trivial thing :-/
> > > > 
> > > > I kinda assume that other drivers will have similar issues, e.g. 
> > > > omapdrm's
> > > > use of dev->struct_mutex also very much looks like it'll result in a new
> > > > locking inversion.
> > > Ah, crap. Already feared that this wouldn't be easy, but yeah that it is 
> > > as
> > > bad as this is rather disappointing.
> > > 
> > > Thanks for the info, going to keep thinking about how to solve those 
> > > issues.
> > Side note: We want to make sure that drivers don't get the reservation_obj
> > locking hierarchy wrong in other places (using dev->struct_mutex is kinda
> > a pre-existing mis-use that we can't wish away retroactively
> > unfortunately). One really important thing is that shrinker vs resv_obj
> > must work with trylocks in the shrinker, so that you can allocate memory
> > while holding reservation objects.
> > 
> > One neat trick to teach lockdep about this would be to have a dummy
> > 
> > if (IS_ENABLED(CONFIG_PROVE_LOCKING)) {
> > ww_mutex_lock(dma_buf->resv_obj);
> > fs_reclaim_acquire(GFP_KERNEL);
> > fs_reclaim_release(GFP_KERNEL);
> > ww_mutex_unlock(dma_buf->resv_obj);
> > }
> > 
> > in dma_buf_init(). We're using the fs_reclaim_acquire/release check very
> > successfully to improve our igt test coverage for i915.ko in other areas.
> > 
> > Totally unrelated to dev->struct_mutex, but thoughts? Well for
> > dev->struct_mutex we could at least decide on one true way to nest
> > resv_obj vs. dev->struct_mutex as maybe an interim step, but not sure how
> > much that would help.
> 
> I don't think that would help. As far as I can see we only have two choices:
> 
> 1. Either have a big patch which fixes all DMA-buf implementations to allow
> the reservation lock to be held during map/unmap (unrealistic).
> 
> 2. Add a flag to at least in the mid term tell the DMA-buf helper functions
> what to do. E.g. create the mapping without the reservation lock held.
> 
> 
> How about moving the SGL caching from the DRM layer into the DMA-buf layer
> and add a flag if the exporter wants/needs this caching?
> 
> Then only the implementations which can deal with dynamic invalidation
> disable SGL caching and with it enable creating the sgl with the reservation
> object locked.
> 
> This way we can kill two birds with one stone by both avoiding the SGL
> caching in the DRM layer as well as having a sane handling for the locking.
> 
> Thoughts?

I don't see how the SGL stuff factors into neither the dev->struct_mutex
nor into the need to do allocations while holding resv_obj. Neither
changes by moving that piece around. At least as far as I can see it SGL
caching is fully orthogonal to any kind of locking fun.

Why do you see a connection here?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/9] drm/client: Add client callbacks