date:20170727

Re: [PATCH] drm/bridge: tc358767: fix probe without attached output node

2017-07-27 Thread Archit Taneja




On 07/27/2017 06:26 PM, Andrey Gusakov wrote:

Hi,

On Mon, Jul 10, 2017 at 3:41 PM, Lucas Stach > wrote:


The output node of the TC358767 is only used if another bridge is chained
behind it. Panels attached to the TC358767 can be detected using the usual
DP AUX probing. This restores the old behavior of ignoring the output if
no endpoint is found.

Fixes: ebc944613567 (drm: convert drivers to use 
drm_of_find_panel_or_bridge)
CC: sta...@vger.kernel.org 
Signed-off-by: Lucas Stach >


Acked-by: Andrey Gusakov >


Thanks, queued to drm-misc-fixes.

Archit



---
  drivers/gpu/drm/bridge/tc358767.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 5c26488e7a2d..0529e500c534 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1255,7 +1255,7 @@ static int tc_probe(struct i2c_client *client, const 
struct i2c_device_id *id)

 /* port@2 is the output port */
 ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, >panel, 
NULL);
-   if (ret)
+   if (ret && ret != -ENODEV)
 return ret;

 /* Shut down GPIO is optional */
--
2.11.0

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





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2017-07-27 Thread bugzilla-daemon

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

Jan Vesely  changed:

   What|Removed |Added

 Depends on||101594


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=101594
[Bug 101594] Blender doesn't detect OpenCL with Clover
-- 
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 101594] Blender doesn't detect OpenCL with Clover

2017-07-27 Thread bugzilla-daemon

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

Jan Vesely  changed:

   What|Removed |Added

 Blocks||99553


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
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

[git pull] drm fixes for v4.13-rc3

2017-07-27 Thread Dave Airlie

Hi Linus,

This is the fixes for 4.13-rc3, as expected people woke up this week,
i915 didn't do an -rc2 pull so got a bumper -rc3 pull, and Ben
resurfaced on nouveau and fixed a bunch of major crashers seen on
Fedora 26, and there are a few vmwgfx fixes as well.

Otherwise exynos had some regression fixes/cleanups, and amdgpu has an
rcu locking regression fix and a couple of minor fixes.

Dave.

The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:

  Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.13-rc3

for you to fetch changes up to 20806588f015921ef0704de36a4750f828f399ea:

  Merge tag 'exynos-drm-fixes-for-v4.13-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-fixes (2017-07-28 12:32:59 +1000)


vmwgfx, exynos, i915, amdgpu, nouveau, host1x and displayport fixes


Alex Xie (1):
  drm/amdgpu: Fix blocking in RCU critical section(v2)

Andrzej Hajda (1):
  drm/exynos/hdmi: fix disable sequence

Arnd Bergmann (2):
  drm/rockchip: fix Kconfig dependencies
  drm: exynos: mark pm functions as __maybe_unused

Arvind Yadav (4):
  drm/vmwgfx: dma-buf: Constify ttm_place structures.
  drm/vmwgfx: constify pci_device_id.
  drm: exynos: constify mixer_match_types and *_mxr_drv_data.
  drm: exynos: hdmi: make of_device_ids const.

Ben Skeggs (5):
  drm/nouveau/i2c/gf119-: add support for address-only transactions
  drm/nouveau/disp: add tv encoders to output resource mapping
  drm/nouveau/kms/nv50: update vblank state in response to modeset actions
  drm/nouveau/kms: remove call to drm_crtc_vblank_off() during
unload/suspend
  drm/nouveau/bar/gf100: fix access to upper half of BAR2

Brian Paul (1):
  drm/vmwgfx: fix comment mistake for vmw_cmd_dx_set_index_buffer()

Chris Wilson (6):
  drm/dp: Fix read pointer for drm_dp_downsteam_debug()
  drm/dp: Don't trust drm_dp_downstream_id()
  drm/i915: Remove assertion from raw __i915_vma_unpin()
  drm/i915: Only mark the execobject as pinned on success
  drm/i915: Only skip updating execobject.offset after error
  drm/i915: Force CPU synchronisation even if userspace requests ASYNC

Christophe JAILLET (2):
  drm/vmwgfx: Fix handling of errors returned by 'vmw_cotable_alloc()'
  drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

Daniel Vetter (2):
  drm/i915: Unbreak gpu reset vs. modeset locking
  Merge tag 'gvt-fixes-2017-07-26' of
https://github.com/01org/gvt-linux into drm-intel-fixes

Dave Airlie (7):
  Merge branch 'linux-4.13' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-vmwgfx-fixes' of
git://people.freedesktop.org/~syeh/repos_linux into drm-fixes
  Merge branch 'linux-4.13' of git://github.com/skeggsb/linux into drm-fixes
  Merge branch 'drm-fixes-4.13' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes
  Merge tag 'drm-misc-fixes-2017-07-27' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge tag 'drm-intel-fixes-2017-07-27' of
git://anongit.freedesktop.org/git/drm-intel into drm-fixes
  Merge tag 'exynos-drm-fixes-for-v4.13-rc3' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-fixes

Eric Huang (1):
  drm/amd/powerplay: fix AVFS voltage offset for Vega10

Gabriel Krisman Bertazi (1):
  exynos_drm: Clean up duplicated assignment in exynos_drm_driver

Hans Verkuil (1):
  drm/exynos: select CEC_CORE if CEC_NOTIFIER

Hoegeun Kwon (1):
  drm/exynos/dsi: Remove error handling for bridge_node DT parsing

Ilia Mirkin (1):
  drm/nouveau/disp/nv50-: bump max chans to 21

Imre Deak (2):
  drm/i915: Fix user ptr check size in eb_relocate_vma()
  drm/i915: Fix scaler init during CRTC HW state readout

Inki Dae (2):
  drm/exynos: dsi: do not try to find bridge
  drm/exynos: mic: add a bridge at probe

Jian Jun Chen (1):
  drm/i915/gvt: Extend KBL platform support in GVT-g

Maarten Lankhorst (1):
  drm/i915: Fix bad comparison in skl_compute_plane_wm.

Navare, Manasi D (1):
  drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: simplify and fix GRBM index selection

Paul Kocialkowski (1):
  gpu: host1x: Free the IOMMU domain when there is no device to attach

Ravikant B Sharma (1):
  drm/vmwgfx: Fix NULL pointer comparison

Sinclair Yeh (3):
  drm/vmwgfx: Limit max desktop dimensions to 8Kx8K
  drm/vmwgfx: Fix cursor hotspot issue with Wayland on Fedora
  drm/vmwgfx: Fix gcc-7.1.1 warning

Souptick Joarder (1):
  drm/vmwgfx: Use dma_pool_zalloc

Ville Syrjälä (1):
  drm/i915: Fix cursor updates on some platforms

fred gao (1):
  drm/i915/gvt: Fix the vblank

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

2017-07-27 Thread Mark yao


Hi Heiko

On 2017年07月28日 09:02, Mark yao wrote:

Hi Heiko

Thanks for the test.

On 2017年07月27日 18:10, Heiko Stübner wrote:

Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner:

Hi Mark,

Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao:

Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.

Signed-off-by: Mark Yao 
---

  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99
  
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112

+++- 3 files changed, 144 insertions(+), 127
deletions(-)

This breaks display support on both rk3036 and rk3288 and I end up
with a null pointer dereference in

[   10.640297] Unable to handle kernel NULL pointer dereference at virtual
address  [   10.654430] pgd = c0204000
[   10.657452] [] *pgd=
[   10.661473] Internal error: Oops: 5 [#1] SMP ARM
[   10.35] Modules linked in: snd_pcm media snd_timer phy_rockchip_dp
snd soundcore rockchipdrm dw_hdmi analogix_dp rtc_rk808 pwm_rockchip
clk_rk808 spi_rockchip [   10.682897] CPU: 2 PID: 143 Comm: kworker/2:2 Not
tainted 4.13.0-rc2-01791-g2b86603d0515 #355 [   10.692430] Hardware name:
Rockchip (Device Tree)
[   10.697692] Workqueue: events deferred_probe_work_func
[   10.702152] Linux video capture interface: v2.00
[   10.708590] task: ee38c800 task.stack: ed2e6000
[   10.713656] PC is at vop_reg_set.constprop.4+0x4/0xa8 [rockchipdrm]
[   10.720668] LR is at vop_bind+0x568/0x8a0 [rockchipdrm]

The obvious reason for that is


@@ -164,14 +153,20 @@ static inline uint32_t vop_read_reg(struct vop *vop,
uint32_t base, return (vop_readl(vop, base + reg->offset) >> reg->shift) &
reg->mask; }

-static inline void vop_mask_write(struct vop *vop, uint32_t offset,
-  uint32_t mask, uint32_t shift, uint32_t v,
-  bool write_mask, bool relaxed)
+static void vop_reg_set(struct vop *vop, const struct vop_reg *reg,
+uint32_t _offset, uint32_t _mask, uint32_t v,
+const char *reg_name)
  {
-if (!mask)
+int offset = reg->offset + _offset;
+int mask = reg->mask & _mask;
+int shift = reg->shift;


Does the crash is that using reg->offset/mask/shift before !reg checking?


I reproduce this cause, from objdump, it crash on "int mask = reg->mask & _mask; 
"
Seems difference gcc has difference behavior, my aarch64 gcc maybe optimize it,
only access when the value be used. I think that is the reason why rk3399 works 
on my test.

I will fix it at next version.




+
+if (!reg || !reg->mask) {
+dev_dbg(vop->dev, "Warning: not support %s\n", reg_name);
  return;
+}

where the check for !reg happens after it got already dereferenced.
But even with that fixed I end up with

on rk3288:
[7.254823] rockchip-vop ff93.vop: Warning: not support global_regdone_en
[7.262847] rockchip-vop ff93.vop: Warning: not support gate
[7.269580] rockchip-vop ff93.vop: Warning: not support gate
[7.302765] rockchip-vop ff94.vop: Warning: not support global_regdone_en
[7.310758] rockchip-vop ff94.vop: Warning: not support gate
[7.317475] rockchip-vop ff94.vop: Warning: not support gate
[7.425724] rockchip-vop ff93.vop: Warning: not support edp_pin_pol
[7.526298] rockchip-vop ff94.vop: Warning: not support hdmi_pin_pol


Rk3288 does not support independent pin_pol settings, all output interfaces 
share the pin_pol register,
So not support hdmi_pin_pol here is correct.

hdmi pin pol would be set by following register:
.pin_pol = VOP_REG(RK3288_DSP_CTRL0, 0xf, 4),



on rk3036:
[   12.389138] rockchip-vop 10118000.vop: Warning: not support global_regdone_en
[   12.397324] rockchip-vop 10118000.vop: Warning: not support gate
[   12.404165] rockchip-vop 10118000.vop: Warning: not support gate
[   13.747361] rockchip-vop 10118000.vop: Warning: not support hdmi_pin_pol
[   13.747371] rockchip-vop 10118000.vop: Warning: not support hdmi_en
[   13.747379] rockchip-vop 10118000.vop: Warning: not support hpost_st_end
[   13.747385] rockchip-vop 10118000.vop: Warning: not support vpost_st_end
[   13.747461] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.767098] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.786060] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl

While reqdone and friends are obviously features of newer vops, at least
the hdmi pin-pol is available on both these socs.

With this patch applied (and null-ptr fixed) I end up without hdmi output
on both socs.


Hmmm, I am confused, from code review, I didn't see what will cause hdmi not 
work on rk3036 and rk3288,

Give me some time, I try to bringup my popmetal rk3288 board to do the test.

Heiko, Thanks very much for your test.


Hi Heiko

Re: [PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

2017-07-27 Thread Gustavo Padovan

2017-07-27 Chris Wilson :

> Quoting Gustavo Padovan (2017-07-27 20:03:53)
> > From: Gustavo Padovan 
> > 
> > If userspace already dropped its own reference by closing the sw_sync
> > fence fd we might end up in a deadlock where
> > dma_fence_is_signaled_locked() will trigger the release of the fence a
> > thus try to hold the lock to remove the fence from the list.
> 
> So the issue here is that call to dma_fence_is_signaled_lock() is
> triggering the unreference?

Exactly. I'll say that explicitely in the commit message.

>  
> > We need to grab a reference to the fence before calling into this chain if
> > we want to avoid this issue.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Gustavo Padovan 
> > ---
> >  drivers/dma-buf/sw_sync.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> > index af1bc84..8291434 100644
> > --- a/drivers/dma-buf/sw_sync.c
> > +++ b/drivers/dma-buf/sw_sync.c
> > @@ -144,11 +144,16 @@ static void sync_timeline_signal(struct sync_timeline 
> > *obj, unsigned int inc)
> > obj->value += inc;
> >  
> > list_for_each_entry_safe(pt, next, >pt_list, link) {
> > -   if (!dma_fence_is_signaled_locked(>base))
> > +   dma_fence_get(>base);
> 
> This would need to be dma_fence_get_rcu() to avoid grabbing the fence
> when its refcount has hit 0.
> 
> > +   if (!dma_fence_is_signaled_locked(>base)) {
> > +   dma_fence_put(>base);
> > break;
> > +   }
> >  
> > list_del_init(>link);
> > rb_erase(>node, >pt_tree);
> 
> But if I understand correctly, we just need to unlink first, then
> signal.
> 
> list_for_each_entry_safe() {
>   if (!timeline_fence_signaled(>base))
>   break;
> 
>   list_del_init(>link);
>   rb_erase(>node, >pt_tree);
> 
>   dma_fence_signal_locked(>base);
> }
> 
> The challenge is in writing the comment to explain the open-coding.

That is cleaner and doesn't need the get/put dance. I'll come up with a
comment to explain it.

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

Re: [PATCH] drm/amd/powerplay: rv: Use designated initializers

2017-07-27 Thread Alex Deucher

On Tue, Jul 25, 2017 at 5:47 PM, Kees Cook  wrote:
> As done for vega10 in commit 3ddd396f6b57 ("drm/amd/powerplay: Use
> designated initializers") mark other tableFunction entries with designated
> initializers. The randstruct plugin requires designated initializers for
> structures that are entirely function pointers.
>
> Cc: Rex Zhu 
> Cc: Hawking Zhang 
> Cc: Alex Deucher 
> Signed-off-by: Kees Cook 
> ---
> If I can get an Ack for this, I'll carry it in the gcc-plugins tree, unless
> you think this is worth landing for v4.13, in which case, please take it
> now. :)
>

Acked-by: Alex Deucher 

I'm happy to take this through my tree if that is ok with you.

Alex

> Thanks!
> ---
>  drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c 
> b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> index 4c7f430b36eb..8e6cfd89c7e0 100644
> --- a/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/rv_hwmgr.c
> @@ -308,8 +308,8 @@ static int rv_tf_set_num_active_display(struct pp_hwmgr 
> *hwmgr, void *input,
>  }
>
>  static const struct phm_master_table_item rv_set_power_state_list[] = {
> -   { NULL, rv_tf_set_clock_limit },
> -   { NULL, rv_tf_set_num_active_display },
> +   { .tableFunction = rv_tf_set_clock_limit },
> +   { .tableFunction = rv_tf_set_num_active_display },
> { }
>  };
>
> @@ -382,7 +382,7 @@ static int rv_tf_disable_gfx_off(struct pp_hwmgr *hwmgr,
>  }
>
>  static const struct phm_master_table_item rv_disable_dpm_list[] = {
> -   {NULL, rv_tf_disable_gfx_off},
> +   { .tableFunction = rv_tf_disable_gfx_off },
> { },
>  };
>
> @@ -407,7 +407,7 @@ static int rv_tf_enable_gfx_off(struct pp_hwmgr *hwmgr,
>  }
>
>  static const struct phm_master_table_item rv_enable_dpm_list[] = {
> -   {NULL, rv_tf_enable_gfx_off},
> +   { .tableFunction = rv_tf_enable_gfx_off },
> { },
>  };
>
> --
> 2.7.4
>
>
> --
> Kees Cook
> Pixel Security
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

2017-07-27 Thread Mark yao


Hi Heiko

Thanks for the test.

On 2017年07月27日 18:10, Heiko Stübner wrote:

Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner:

Hi Mark,

Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao:

Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.

Signed-off-by: Mark Yao 
---

  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99
  
  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112

+++- 3 files changed, 144 insertions(+), 127
deletions(-)

This breaks display support on both rk3036 and rk3288 and I end up
with a null pointer dereference in

[   10.640297] Unable to handle kernel NULL pointer dereference at virtual
address  [   10.654430] pgd = c0204000
[   10.657452] [] *pgd=
[   10.661473] Internal error: Oops: 5 [#1] SMP ARM
[   10.35] Modules linked in: snd_pcm media snd_timer phy_rockchip_dp
snd soundcore rockchipdrm dw_hdmi analogix_dp rtc_rk808 pwm_rockchip
clk_rk808 spi_rockchip [   10.682897] CPU: 2 PID: 143 Comm: kworker/2:2 Not
tainted 4.13.0-rc2-01791-g2b86603d0515 #355 [   10.692430] Hardware name:
Rockchip (Device Tree)
[   10.697692] Workqueue: events deferred_probe_work_func
[   10.702152] Linux video capture interface: v2.00
[   10.708590] task: ee38c800 task.stack: ed2e6000
[   10.713656] PC is at vop_reg_set.constprop.4+0x4/0xa8 [rockchipdrm]
[   10.720668] LR is at vop_bind+0x568/0x8a0 [rockchipdrm]

The obvious reason for that is


@@ -164,14 +153,20 @@ static inline uint32_t vop_read_reg(struct vop *vop,
uint32_t base, return (vop_readl(vop, base + reg->offset) >> reg->shift) &
reg->mask; }

-static inline void vop_mask_write(struct vop *vop, uint32_t offset,
- uint32_t mask, uint32_t shift, uint32_t v,
- bool write_mask, bool relaxed)
+static void vop_reg_set(struct vop *vop, const struct vop_reg *reg,
+   uint32_t _offset, uint32_t _mask, uint32_t v,
+   const char *reg_name)
  {
-   if (!mask)
+   int offset = reg->offset + _offset;
+   int mask = reg->mask & _mask;
+   int shift = reg->shift;


Does the crash is that using reg->offset/mask/shift before !reg checking?


+
+   if (!reg || !reg->mask) {
+   dev_dbg(vop->dev, "Warning: not support %s\n", reg_name);
return;
+   }

where the check for !reg happens after it got already dereferenced.
But even with that fixed I end up with

on rk3288:
[7.254823] rockchip-vop ff93.vop: Warning: not support global_regdone_en
[7.262847] rockchip-vop ff93.vop: Warning: not support gate
[7.269580] rockchip-vop ff93.vop: Warning: not support gate
[7.302765] rockchip-vop ff94.vop: Warning: not support global_regdone_en
[7.310758] rockchip-vop ff94.vop: Warning: not support gate
[7.317475] rockchip-vop ff94.vop: Warning: not support gate
[7.425724] rockchip-vop ff93.vop: Warning: not support edp_pin_pol
[7.526298] rockchip-vop ff94.vop: Warning: not support hdmi_pin_pol


Rk3288 does not support independent pin_pol settings, all output interfaces 
share the pin_pol register,
So not support hdmi_pin_pol here is correct.

hdmi pin pol would be set by following register:
.pin_pol = VOP_REG(RK3288_DSP_CTRL0, 0xf, 4),



on rk3036:
[   12.389138] rockchip-vop 10118000.vop: Warning: not support global_regdone_en
[   12.397324] rockchip-vop 10118000.vop: Warning: not support gate
[   12.404165] rockchip-vop 10118000.vop: Warning: not support gate
[   13.747361] rockchip-vop 10118000.vop: Warning: not support hdmi_pin_pol
[   13.747371] rockchip-vop 10118000.vop: Warning: not support hdmi_en
[   13.747379] rockchip-vop 10118000.vop: Warning: not support hpost_st_end
[   13.747385] rockchip-vop 10118000.vop: Warning: not support vpost_st_end
[   13.747461] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.767098] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.786060] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl

While reqdone and friends are obviously features of newer vops, at least
the hdmi pin-pol is available on both these socs.

With this patch applied (and null-ptr fixed) I end up without hdmi output
on both socs.


Hmmm, I am confused, from code review, I didn't see what will cause hdmi not 
work on rk3036 and rk3288,

Give me some time, I try to bringup my popmetal rk3288 board to do the test.

Heiko, Thanks very much for your test.




Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip






--
Ｍark Yao


___
dri-devel mailing

Re: [PATCHv1 00/14] omapdrm: DSI command mode panel support

2017-07-27 Thread Tony Lindgren

* Sebastian Reichel  [170724 10:34]:
> Hi,
> 
> This adds support for command mode DSI panels to
> omapdrm. I tested the patches on Nokia N950 (omap3)
> and Motorola Droid 4 (omap4). This is basically
> PATCHv3 of my series adding N950 display support,
> but I started from scratch without reverting the
> removal of manual display update support.

Works for me:

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

Re: [PATCH v2 resend] drm/panel: Add driver for Seiko 43WVF1G panel

2017-07-27 Thread Marco Frank

Thierry,

2017-07-20 13:12 GMT-03:00 Marco Franchi :

> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel.
>
> Datasheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Seiko 43WVF1G panel has two power supplies: avdd and dvdd and they
> require a specific power on/down sequence.
> For this reason the simple panel driver cannot be used to drive this
> panel, so create a new one heavily based on simple panel.
>
> Based on initial patch submission from Breno Lima.
>
> Signed-off-by: Marco Franchi 
> ---
> Changes since v1:
> -Change supply names to dvdd-supply and avdd-supply
>

I tried pingin Rob with no sucess so far. Given that this is a very simples
LCD driver, could you please apply it directly?
Thanks
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-27 Thread Mauro Rossi

2017-07-27 10:30 GMT+02:00 Chih-Wei Huang :
>> 2017-07-26 17:27 GMT+02:00 Emil Velikov :
>>> On 25 July 2017 at 08:28, Chih-Wei Huang  wrote:
 Hi Mauro,
 Please note AMDGPU_ASIC_ID_TABLE
 should be a path in the target device (i.e., Android).
 So using $(LIBDRM_TOP) is incorrect.

 Actually I've sent a fix for it about one week ago.

>>> Did you sent v2 of the patch? I cannot see any in my inbox.
>
> OK. I re-submitted v2 patch to replace
> /etc with /system/etc.
>
> 2017-07-27 1:36 GMT+08:00 Mauro Rossi :
>> This one has conceptual error and is to be dropped.
>>
>> The ones submitted by Chih-Wei are here:
>>
>> https://github.com/maurossi/drm/commits/2.4.82_android-x86
>>
>> where in the (v2) of the second I just replaced /etc path with 
>> $(TARGET_OUT_ETC)
>
> No. TARGET_OUT_ETC is still the host path.
> (which is out/target/product/$target/system/etc )

I had this kind of doubt,
I think there is a precedent we can use to support original 2of2 patch (v1)

https://github.com/robherring/libpciaccess/blob/master/Android.mk

where /etc/hwdata was the folder used at runtime for pci.ids

So original 2of2 patch is signed-off by Chih-Wei and me.

Mauro

>
>> Chih-Wei if you like the (v2) could you please resubmit to dri-devel
>> using [PATCH libdrm] in the title?
>
> --
> Chih-Wei
> Android-x86 project
> http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-intel-fixes

2017-07-27 Thread Daniel Vetter

Hi Dave,

drm-intel-fixes-2017-07-27:
i915 fixes for -rc3

Bit more than usual since we missed -rc2. 4x cc: stable, 2 gvt
patches, but all fairly minor stuff. Last minute rebase was to add a
few missing cc: stable, I did prep the pull this morning already and
made sure CI approves.

Cheers, Daniel


The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:

  Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-07-27

for you to fetch changes up to 5fe220a160e5422cebc076393c6bfd6d920243fd:

  Merge tag 'gvt-fixes-2017-07-26' of https://github.com/01org/gvt-linux into 
drm-intel-fixes (2017-07-27 22:07:53 +0200)


i915 fixes for -rc3

Bit more than usual since we missed -rc2. 4x cc: stable, 2 gvt
patches, but all fairly minor stuff. Last minute rebase was to add a
few missing cc: stable, I did prep the pull this morning already and
made sure CI approves.


Chris Wilson (4):
  drm/i915: Remove assertion from raw __i915_vma_unpin()
  drm/i915: Only mark the execobject as pinned on success
  drm/i915: Only skip updating execobject.offset after error
  drm/i915: Force CPU synchronisation even if userspace requests ASYNC

Christophe JAILLET (1):
  drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'

Daniel Vetter (2):
  drm/i915: Unbreak gpu reset vs. modeset locking
  Merge tag 'gvt-fixes-2017-07-26' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Imre Deak (2):
  drm/i915: Fix user ptr check size in eb_relocate_vma()
  drm/i915: Fix scaler init during CRTC HW state readout

Jian Jun Chen (1):
  drm/i915/gvt: Extend KBL platform support in GVT-g

Maarten Lankhorst (1):
  drm/i915: Fix bad comparison in skl_compute_plane_wm.

Navare, Manasi D (1):
  drm/i915/cnl: Fix loadgen select programming on ddi vswing sequence

Ville Syrjälä (1):
  drm/i915: Fix cursor updates on some platforms

fred gao (1):
  drm/i915/gvt: Fix the vblank timer close issue after shutdown VMs in 
reverse

 drivers/gpu/drm/i915/gvt/display.c   | 22 +++---
 drivers/gpu/drm/i915/i915_gem_clflush.c  |  7 +-
 drivers/gpu/drm/i915/i915_gem_clflush.h  |  2 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c   | 24 ---
 drivers/gpu/drm/i915/i915_vma.h  |  2 +-
 drivers/gpu/drm/i915/intel_ddi.c |  4 +-
 drivers/gpu/drm/i915/intel_display.c | 86 ++--
 drivers/gpu/drm/i915/intel_gvt.c |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  |  4 +-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  2 +-
 10 files changed, 72 insertions(+), 83 deletions(-)

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

[PULL] drm-misc-fixes

2017-07-27 Thread Sean Paul

Hi Dave,
Only a handful of patches for -fixes from -misc. Everything is pretty easy to
rationalize, nothing newsworthy.

drm-misc-fixes-2017-07-27:
Core Changes:
- dp: A few fixes in drm_dp_downstream_debug() (Chris)
- rockchip: sanitize the Kconfig dependencies (fallout from EXTCON) (Arnd)
- host1x: Free the iommu domain when attach_device fails (Paul)

Cc: Chris Wilson 
Cc: Arnd Bergmann 
Cc: Paul Kocialkowski 

Cheers, Sean


The following changes since commit 636c4c3e762b62aa93632c645ca65879285b16e3:

  drm/mst: Avoid processing partially received up/down message transactions 
(2017-07-20 10:20:31 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-fixes-2017-07-27

for you to fetch changes up to fea20995976f4b2e8968f852a18e280487d42f0d:

  gpu: host1x: Free the IOMMU domain when there is no device to attach 
(2017-07-27 16:57:34 +0200)


Core Changes:
- dp: A few fixes in drm_dp_downstream_debug() (Chris)
- rockchip: sanitize the Kconfig dependencies (fallout from EXTCON) (Arnd)
- host1x: Free the iommu domain when attach_device fails (Paul)

Cc: Chris Wilson 
Cc: Arnd Bergmann 
Cc: Paul Kocialkowski 


Arnd Bergmann (1):
  drm/rockchip: fix Kconfig dependencies

Chris Wilson (2):
  drm/dp: Fix read pointer for drm_dp_downsteam_debug()
  drm/dp: Don't trust drm_dp_downstream_id()

Paul Kocialkowski (1):
  gpu: host1x: Free the IOMMU domain when there is no device to attach

 drivers/gpu/drm/drm_dp_helper.c  |  5 +++--
 drivers/gpu/drm/rockchip/Kconfig | 19 +--
 drivers/gpu/host1x/dev.c |  8 +++-
 3 files changed, 19 insertions(+), 13 deletions(-)

-- 
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] dma-buf/sw_sync: hold a fence reference when check if it signaled

2017-07-27 Thread Chris Wilson

Quoting Gustavo Padovan (2017-07-27 20:03:53)
> From: Gustavo Padovan 
> 
> If userspace already dropped its own reference by closing the sw_sync
> fence fd we might end up in a deadlock where
> dma_fence_is_signaled_locked() will trigger the release of the fence a
> thus try to hold the lock to remove the fence from the list.

So the issue here is that call to dma_fence_is_signaled_lock() is
triggering the unreference?
 
> We need to grab a reference to the fence before calling into this chain if
> we want to avoid this issue.
> 
> Cc: Chris Wilson 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/dma-buf/sw_sync.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index af1bc84..8291434 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -144,11 +144,16 @@ static void sync_timeline_signal(struct sync_timeline 
> *obj, unsigned int inc)
> obj->value += inc;
>  
> list_for_each_entry_safe(pt, next, >pt_list, link) {
> -   if (!dma_fence_is_signaled_locked(>base))
> +   dma_fence_get(>base);

This would need to be dma_fence_get_rcu() to avoid grabbing the fence
when its refcount has hit 0.

> +   if (!dma_fence_is_signaled_locked(>base)) {
> +   dma_fence_put(>base);
> break;
> +   }
>  
> list_del_init(>link);
> rb_erase(>node, >pt_tree);

But if I understand correctly, we just need to unlink first, then
signal.

list_for_each_entry_safe() {
if (!timeline_fence_signaled(>base))
break;

list_del_init(>link);
rb_erase(>node, >pt_tree);

dma_fence_signal_locked(>base);
}

The challenge is in writing the comment to explain the open-coding.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/41] drm/atmel-hlcdc: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-27 Thread Boris Brezillon

Le Sun, 23 Jul 2017 21:16:22 +0200,
Noralf Trønnes  a écrit :

> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Boris Brezillon 
> Signed-off-by: Noralf Trønnes 

Acked-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 64f54dc..74d66e1 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -761,8 +761,6 @@ static struct drm_driver atmel_hlcdc_dc_driver = {
>   .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
>   .gem_prime_mmap = drm_gem_cma_prime_mmap,
>   .dumb_create = drm_gem_cma_dumb_create,
> - .dumb_map_offset = drm_gem_cma_dumb_map_offset,
> - .dumb_destroy = drm_gem_dumb_destroy,
>   .fops = ,
>   .name = "atmel-hlcdc",
>   .desc = "Atmel HLCD Controller DRM",

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

Re: [PATCH 0/5] drm/atomic: Interruptible locks for everyone!

2017-07-27 Thread Emil Velikov

On 27 July 2017 at 16:30, Daniel Vetter  wrote:
> On Thu, Jul 27, 2017 at 03:45:11PM +0100, Emil Velikov wrote:
>> Hi Maarten
>>
>> On 27 July 2017 at 13:58, Maarten Lankhorst
>>  wrote:
>> > drm_atomic_commit could previous have always failed when waits failed,
>> > but locking was always done uninterruptibly. Add infrastructure to make
>> > it possible for callers to choose interruptible locking, and convert the
>> > 4 most common ioctl's to use it.
>> >
>> > All other atomic helpers can be converted when Daniel's "acquire_ctx
>> > for everyone!" patch series lands.
>> >
>> There's a KMS locking documentation/example in drm_modeset_lock.c.
>> Can you please update that as well?
>
> Not sure what we should update there? As-is it still works for the
> non-interruptible case. Or do you mean we should have an interruptible
> variant of it too?
>
Don't think another example is needed.

After the example add a line which says "hey you can have
Interruptable locking", pointing to drm_modeset_acquire_init and/or
drm_modeset_backoff.
Updating the drm_modeset_acquire_init() call to have the flags
argument would also be nice.

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

[PATCH] dma-buf/sw_sync: hold a fence reference when check if it signaled

2017-07-27 Thread Gustavo Padovan

From: Gustavo Padovan 

If userspace already dropped its own reference by closing the sw_sync
fence fd we might end up in a deadlock where
dma_fence_is_signaled_locked() will trigger the release of the fence a
thus try to hold the lock to remove the fence from the list.

We need to grab a reference to the fence before calling into this chain if
we want to avoid this issue.

Cc: Chris Wilson 
Signed-off-by: Gustavo Padovan 
---
 drivers/dma-buf/sw_sync.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index af1bc84..8291434 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -144,11 +144,16 @@ static void sync_timeline_signal(struct sync_timeline 
*obj, unsigned int inc)
obj->value += inc;
 
list_for_each_entry_safe(pt, next, >pt_list, link) {
-   if (!dma_fence_is_signaled_locked(>base))
+   dma_fence_get(>base);
+   if (!dma_fence_is_signaled_locked(>base)) {
+   dma_fence_put(>base);
break;
+   }
 
list_del_init(>link);
rb_erase(>node, >pt_tree);
+
+   dma_fence_put(>base);
}
 
spin_unlock_irq(>lock);
-- 
2.9.4

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

Re: [PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

2017-07-27 Thread Maarten Lankhorst

Op 27-07-17 om 17:19 schreef Daniel Vetter:
> On Thu, Jul 27, 2017 at 02:58:36PM +0200, Maarten Lankhorst wrote:
>> When we want to make drm_atomic_commit interruptible, there are a lot of
>> places that call the lock function, which we don't have control over.
>>
>> Rather than trying to convert every single one, it's easier to toggle
>> interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
>> called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
>> interruptible waits in drm_modeset_lock and drm_modeset_backoff.
>>
>> Signed-off-by: Maarten Lankhorst 
> I wonder whether we should do a drm_modeset_lock_single without the
> context attribute too, for OCD. But not really needed.
>
> Reviewed-by: Daniel Vetter 
>
If it was up to me, we didn't rename drm_modeset_lock_interruptible and allowed 
it
to pass a ctx. Most likely it would have been NULL, but at least we'd have 
symmetry.

The same discussion was held ww_mutex_lock iirc, and we ended up with a single 
locking
function where we could pass a NULL context if needed. :)

~Maarten

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

[PATCH 08/17] drm/msm: Add per-instance submit queues

2017-07-27 Thread Jordan Crouse

Currently the behavior of a command stream is provided by the user
application during submission and the application is expected to internally
maintain the settings for each 'context' or 'rendering queue' and specify
the correct ones.

This works okay for simple cases but as applications become more
complex we will want to set context specific flags and do various
permission checks to allow certain contexts to enable additional
privileges.

Add kernel-side submit queues to be analogous to 'contexts' or
'rendering queues' on the application side. Each file descriptor
instance will maintain its own list of queues. Queues cannot be
shared between file descriptors.

For backwards compatibility context id '0' is defined as a default
context specifying no priority and no special flags. This is
intended to be the usual configuration for 99% of applications so
that a garden variety application can function correctly without
creating a queue. Only those applications requiring the specific
benefit of different queues need create one.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile  |   3 +-
 drivers/gpu/drm/msm/msm_drv.c |  51 +++--
 drivers/gpu/drm/msm/msm_drv.h |  20 +++--
 drivers/gpu/drm/msm/msm_gem.h |   1 +
 drivers/gpu/drm/msm/msm_gem_submit.c  |  13 +++-
 drivers/gpu/drm/msm/msm_gpu.h |  15 
 drivers/gpu/drm/msm/msm_submitqueue.c | 139 ++
 include/uapi/drm/msm_drm.h|  22 ++
 8 files changed, 249 insertions(+), 15 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/msm_submitqueue.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 33008fa..3c234e7 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -57,7 +57,8 @@ msm-y := \
msm_iommu.o \
msm_perf.o \
msm_rd.o \
-   msm_ringbuffer.o
+   msm_ringbuffer.o \
+   msm_submitqueue.o
 
 msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f49f6ac..f4bb909 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -510,24 +510,37 @@ static void load_gpu(struct drm_device *dev)
mutex_unlock(_lock);
 }
 
-static int msm_open(struct drm_device *dev, struct drm_file *file)
+static int context_init(struct drm_file *file)
 {
struct msm_file_private *ctx;
 
-   /* For now, load gpu on open.. to avoid the requirement of having
-* firmware in the initrd.
-*/
-   load_gpu(dev);
-
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
 
+   msm_submitqueue_init(ctx);
+
file->driver_priv = ctx;
 
return 0;
 }
 
+static int msm_open(struct drm_device *dev, struct drm_file *file)
+{
+   /* For now, load gpu on open.. to avoid the requirement of having
+* firmware in the initrd.
+*/
+   load_gpu(dev);
+
+   return context_init(file);
+}
+
+static void context_close(struct msm_file_private *ctx)
+{
+   msm_submitqueue_close(ctx);
+   kfree(ctx);
+}
+
 static void msm_postclose(struct drm_device *dev, struct drm_file *file)
 {
struct msm_drm_private *priv = dev->dev_private;
@@ -538,7 +551,7 @@ static void msm_postclose(struct drm_device *dev, struct 
drm_file *file)
priv->lastctx = NULL;
mutex_unlock(>struct_mutex);
 
-   kfree(ctx);
+   context_close(ctx);
 }
 
 static void msm_lastclose(struct drm_device *dev)
@@ -783,6 +796,28 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev, 
void *data,
return ret;
 }
 
+
+static int msm_ioctl_submitqueue_new(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct drm_msm_submitqueue *args = data;
+
+   if (args->flags & ~MSM_SUBMITQUEUE_FLAGS)
+   return -EINVAL;
+
+   return msm_submitqueue_create(file->driver_priv, args->prio,
+   args->flags, >id);
+}
+
+
+static int msm_ioctl_submitqueue_close(struct drm_device *dev, void *data,
+   struct drm_file *file)
+{
+   struct drm_msm_submitqueue *args = data;
+
+   return msm_submitqueue_remove(file->driver_priv, args->id);
+}
+
 static const struct drm_ioctl_desc msm_ioctls[] = {
DRM_IOCTL_DEF_DRV(MSM_GET_PARAM,msm_ioctl_get_param,
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_NEW,  msm_ioctl_gem_new,  
DRM_AUTH|DRM_RENDER_ALLOW),
@@ -792,6 +827,8 @@ static int msm_ioctl_gem_madvise(struct drm_device *dev, 
void *data,
DRM_IOCTL_DEF_DRV(MSM_GEM_SUBMIT,   msm_ioctl_gem_submit,   
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_WAIT_FENCE,   msm_ioctl_wait_fence,   
DRM_AUTH|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(MSM_GEM_MADVISE,  msm_ioctl_gem_madvise,

[PATCH 15/17] drm/msm: Shadow current pointer in the ring until command is complete

2017-07-27 Thread Jordan Crouse

Add a shadow pointer to track the current command being written into
the ring. Don't commit it as 'cur' until the command is submitted.
Because 'cur' is used to construct the software copy of the wptr this
ensures that somebody peeking in on the ring doesn't assume that a
command is inflight while it is being written. This isn't a huge deal
with a single ring (though technically the hangcheck could assume
the system is prematurely busy when it isn't) but it will be rather
important for preemption where the decision to preempt is based
on a non-empty ringbuffer. Without a shadow an aggressive preemption
scheme could assume that the ringbuffer is non empty and switch to it
before the CPU is done writing the command and boom.

Even though preemption won't be supported for all targets because of
the way the code is organized it is simpler to make this generic for
all targets. The extra load for non-preemption targets should be
minimal.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c |  9 +++--
 drivers/gpu/drm/msm/msm_ringbuffer.c|  1 +
 drivers/gpu/drm/msm/msm_ringbuffer.h| 12 
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 39ff842..a2777d8 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -82,6 +82,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
}
 
ring->cur = ring->start;
+   ring->next = ring->start;
 
/* reset completed fence seqno: */
ring->memptrs->fence = ring->seqno;
@@ -226,12 +227,15 @@ void adreno_flush(struct msm_gpu *gpu, struct 
msm_ringbuffer *ring)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
uint32_t wptr;
 
+   /* Copy the shadow to the actual register */
+   ring->cur = ring->next;
+
/*
 * Mask wptr value that we calculate to fit in the HW range. This is
 * to account for the possibility that the last command fit exactly into
 * the ringbuffer and rb->next hasn't wrapped to zero yet
 */
-   wptr = get_wptr(ring) % (MSM_GPU_RINGBUFFER_SZ >> 2);
+   wptr = (ring->cur - ring->start) % (MSM_GPU_RINGBUFFER_SZ >> 2);
 
/* ensure writes to ringbuffer have hit system memory: */
mb();
@@ -343,7 +347,8 @@ static uint32_t ring_freewords(struct msm_ringbuffer *ring)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(ring->gpu);
uint32_t size = MSM_GPU_RINGBUFFER_SZ >> 2;
-   uint32_t wptr = get_wptr(ring);
+   /* Use ring->next to calculate free size */
+   uint32_t wptr = ring->next - ring->start;
uint32_t rptr = get_rptr(adreno_gpu, ring);
return (rptr + (size - 1) - wptr) % size;
 }
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.c 
b/drivers/gpu/drm/msm/msm_ringbuffer.c
index a74d66a..899145b 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.c
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.c
@@ -45,6 +45,7 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu 
*gpu, int id,
goto fail;
}
ring->end   = ring->start + (MSM_GPU_RINGBUFFER_SZ >> 2);
+   ring->next  = ring->start;
ring->cur   = ring->start;
 
ring->memptrs = memptrs;
diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h 
b/drivers/gpu/drm/msm/msm_ringbuffer.h
index 5907063f..8cff38a 100644
--- a/drivers/gpu/drm/msm/msm_ringbuffer.h
+++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
@@ -32,7 +32,7 @@ struct msm_ringbuffer {
struct msm_gpu *gpu;
int id;
struct drm_gem_object *bo;
-   uint32_t *start, *end, *cur;
+   uint32_t *start, *end, *cur, *next;
struct list_head submits;
uint64_t iova;
uint32_t seqno;
@@ -50,9 +50,13 @@ struct msm_ringbuffer *msm_ringbuffer_new(struct msm_gpu 
*gpu, int id,
 static inline void
 OUT_RING(struct msm_ringbuffer *ring, uint32_t data)
 {
-   if (ring->cur == ring->end)
-   ring->cur = ring->start;
-   *(ring->cur++) = data;
+   /*
+* ring->next points to the current command being written - it won't be
+* committed as ring->cur until the flush
+*/
+   if (ring->next == ring->end)
+   ring->next = ring->start;
+   *(ring->next++) = data;
 }
 
 #endif /* __MSM_RINGBUFFER_H__ */
-- 
1.9.1

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

[PATCH 16/17] drm/msm: Make the value of RB_CNTL (almost) generic

2017-07-27 Thread Jordan Crouse

We use a global ringbuffer size and block size for all targets and
at least for 5XX preemption we need to know the value the RB_CNTL
in several locations so it makes sense to calculate it once and use
it everywhere.

The only monkey wrench is that we need to disable the RPTR shadow
for A430 targets but that only needs to be done once and doesn't
affect A5XX so we can or in the value at init time.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 +++-
 drivers/gpu/drm/msm/msm_gpu.h   |  5 +
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index a2777d8..85e2368 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -21,7 +21,6 @@
 #include "msm_gem.h"
 #include "msm_mmu.h"
 
-#define RB_BLKSIZE 32
 
 int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value)
 {
@@ -89,11 +88,14 @@ int adreno_hw_init(struct msm_gpu *gpu)
ring->memptrs->rptr = 0;
}
 
-   /* Setup REG_CP_RB_CNTL: */
+   /*
+* Setup REG_CP_RB_CNTL.  The same value is used across targets (with
+* the excpetion of A430 that disables the RPTR shadow) - the cacluation
+* for the ringbuffer size and block size is moved to msm_gpu.h for the
+* pre-processor to deal with and the A430 variant is ORed in here
+*/
adreno_gpu_write(adreno_gpu, REG_ADRENO_CP_RB_CNTL,
-   /* size is log2(quad-words): */
-   AXXX_CP_RB_CNTL_BUFSZ(ilog2(MSM_GPU_RINGBUFFER_SZ / 8)) |
-   AXXX_CP_RB_CNTL_BLKSZ(ilog2(RB_BLKSIZE / 8)) |
+   MSM_GPU_RB_CNTL_DEFAULT |
(adreno_is_a430(adreno_gpu) ? AXXX_CP_RB_CNTL_NO_UPDATE : 0));
 
/* Setup ringbuffer address - use ringbuffer[0] for GPU init */
diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
index dbc4835..914cd2f 100644
--- a/drivers/gpu/drm/msm/msm_gpu.h
+++ b/drivers/gpu/drm/msm/msm_gpu.h
@@ -132,6 +132,11 @@ struct msm_gpu {
 
 /* It turns out that all targets use the same ringbuffer size */
 #define MSM_GPU_RINGBUFFER_SZ SZ_32K
+#define MSM_GPU_RINGBUFFER_BLKSIZE 32
+
+#define MSM_GPU_RB_CNTL_DEFAULT \
+   (AXXX_CP_RB_CNTL_BUFSZ(ilog2(MSM_GPU_RINGBUFFER_SZ / 8)) | \
+   AXXX_CP_RB_CNTL_BLKSZ(ilog2(MSM_GPU_RINGBUFFER_BLKSIZE / 8)))
 
 static inline bool msm_gpu_active(struct msm_gpu *gpu)
 {
-- 
1.9.1

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

[PATCH 17/17] drm/msm: Implement preemption for A5XX targets

2017-07-27 Thread Jordan Crouse

Implement preemption for A5XX targets - this allows multiple
ringbuffers for different priorities with automatic preemption
of a lower priority ringbuffer if a higher one is ready.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/Makefile  |   1 +
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 176 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 101 +-
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 294 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  14 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |   7 +-
 drivers/gpu/drm/msm/msm_drv.h |   2 +-
 drivers/gpu/drm/msm/msm_gpu.c |   5 +-
 drivers/gpu/drm/msm/msm_ringbuffer.c  |   1 +
 drivers/gpu/drm/msm/msm_ringbuffer.h  |   1 +
 drivers/gpu/drm/msm/msm_submitqueue.c |   4 +-
 11 files changed, 584 insertions(+), 22 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a5xx_preempt.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 3c234e7..d0b26dd 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -8,6 +8,7 @@ msm-y := \
adreno/a4xx_gpu.o \
adreno/a5xx_gpu.o \
adreno/a5xx_power.o \
+   adreno/a5xx_preempt.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index a195d5d..eba2a02 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -80,13 +80,65 @@ static int zap_shader_load_mdt(struct device *dev, const 
char *fwname)
 }
 #endif
 
+static void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
+   uint32_t wptr;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+
+   /* Copy the shadow to the actual register */
+   ring->cur = ring->next;
+
+   /* Make sure to wrap wptr if we need to */
+   wptr = get_wptr(ring);
+
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Make sure everything is posted before making a decision */
+   mb();
+
+   /* Update HW if this is the current ring and we are not in preempt */
+   if (a5xx_gpu->cur_ring == ring && !a5xx_in_preempt(a5xx_gpu))
+   gpu_write(gpu, REG_A5XX_CP_RB_WPTR, wptr);
+}
+
 static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
struct msm_drm_private *priv = gpu->dev->dev_private;
struct msm_ringbuffer *ring = submit->ring;
unsigned int i, ibs = 0;
 
+   OUT_PKT7(ring, CP_PREEMPT_ENABLE_GLOBAL, 1);
+   OUT_RING(ring, 0x02);
+
+   /* Turn off protected mode to write to special registers */
+   OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
+   OUT_RING(ring, 0);
+
+   /* Set the save preemption record for the ring/command */
+   OUT_PKT4(ring, REG_A5XX_CP_CONTEXT_SWITCH_SAVE_ADDR_LO, 2);
+   OUT_RING(ring, lower_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
+   OUT_RING(ring, upper_32_bits(a5xx_gpu->preempt_iova[submit->ring->id]));
+
+   /* Turn back on protected mode */
+   OUT_PKT7(ring, CP_SET_PROTECTED_MODE, 1);
+   OUT_RING(ring, 1);
+
+   /* Enable local preemption for finegrain preemption */
+   OUT_PKT7(ring, CP_PREEMPT_ENABLE_GLOBAL, 1);
+   OUT_RING(ring, 0x02);
+
+   /* Allow CP_CONTEXT_SWITCH_YIELD packets in the IB2 */
+   OUT_PKT7(ring, CP_YIELD_ENABLE, 1);
+   OUT_RING(ring, 0x02);
+
+   /* Submit the commands */
for (i = 0; i < submit->nr_cmds; i++) {
switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
@@ -104,16 +156,54 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
}
}
 
+   /*
+* Write the render mode to NULL (0) to indicate to the CP that the IBs
+* are done rendering - otherwise a lucky preemption would start
+* replaying from the last checkpoint
+*/
+   OUT_PKT7(ring, CP_SET_RENDER_MODE, 5);
+   OUT_RING(ring, 0);
+   OUT_RING(ring, 0);
+   OUT_RING(ring, 0);
+   OUT_RING(ring, 0);
+   OUT_RING(ring, 0);
+
+   /* Turn off IB level preemptions */
+   OUT_PKT7(ring, CP_YIELD_ENABLE, 1);
+   OUT_RING(ring, 0x01);
+
+   /* Write the fence to the scratch register */
OUT_PKT4(ring, REG_A5XX_CP_SCRATCH_REG(2), 1);
OUT_RING(ring, submit->seqno);
 
+   /*
+* Execute a CACHE_FLUSH_TS event. This will ensure that the
+* timestamp is written to the memory and then triggers the interrupt
+*/

[PATCH 11/17] drm/msm: Add a helper function for in-kernel buffer allocations

2017-07-27 Thread Jordan Crouse

Nearly all of the buffer allocations for kernel allocate an buffer object,
virtual address and GPU iova at the same time. Make a helper function to
handle the details.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 22 +++-
 drivers/gpu/drm/msm/adreno/a5xx_power.c | 14 +++---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 26 +--
 drivers/gpu/drm/msm/msm_drv.h   |  6 +
 drivers/gpu/drm/msm/msm_fbdev.c | 35 ++---
 drivers/gpu/drm/msm/msm_gem.c   | 46 +
 drivers/gpu/drm/msm/msm_ringbuffer.c| 12 -
 7 files changed, 86 insertions(+), 75 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 3acbba1..e533007 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -269,28 +269,14 @@ static int a5xx_me_init(struct msm_gpu *gpu)
 static struct drm_gem_object *a5xx_ucode_load_bo(struct msm_gpu *gpu,
const struct firmware *fw, u64 *iova)
 {
-   struct drm_device *drm = gpu->dev;
struct drm_gem_object *bo;
void *ptr;
 
-   bo = msm_gem_new_locked(drm, fw->size - 4, MSM_BO_UNCACHED);
-   if (IS_ERR(bo))
-   return bo;
+   ptr = msm_gem_kernel_new_locked(gpu->dev, fw->size - 4,
+   MSM_BO_UNCACHED | MSM_BO_GPU_READONLY, gpu->aspace, , iova);
 
-   ptr = msm_gem_get_vaddr(bo);
-   if (!ptr) {
-   drm_gem_object_unreference(bo);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   if (iova) {
-   int ret = msm_gem_get_iova(bo, gpu->aspace, iova);
-
-   if (ret) {
-   drm_gem_object_unreference(bo);
-   return ERR_PTR(ret);
-   }
-   }
+   if (IS_ERR(ptr))
+   return ERR_CAST(ptr);
 
memcpy(ptr, >data[4], fw->size - 4);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c 
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index 87af6ee..04aab1d 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -294,16 +294,10 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
 */
bosize = (cmds_size + (cmds_size / TYPE4_MAX_PAYLOAD) + 1) << 2;
 
-   a5xx_gpu->gpmu_bo = msm_gem_new_locked(drm, bosize, MSM_BO_UNCACHED);
-   if (IS_ERR(a5xx_gpu->gpmu_bo))
-   goto err;
-
-   if (msm_gem_get_iova(a5xx_gpu->gpmu_bo, gpu->aspace,
-   _gpu->gpmu_iova))
-   goto err;
-
-   ptr = msm_gem_get_vaddr(a5xx_gpu->gpmu_bo);
-   if (!ptr)
+   ptr = msm_gem_kernel_new_locked(drm, bosize,
+   MSM_BO_UNCACHED | MSM_BO_GPU_READONLY, gpu->aspace,
+   _gpu->gpmu_bo, _gpu->gpmu_iova);
+   if (IS_ERR(ptr))
goto err;
 
while (cmds_size > 0) {
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 634e724..6d65684 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -384,29 +384,17 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
return ret;
}
 
-   adreno_gpu->memptrs_bo = msm_gem_new(drm, sizeof(*adreno_gpu->memptrs),
-   MSM_BO_UNCACHED);
-   if (IS_ERR(adreno_gpu->memptrs_bo)) {
-   ret = PTR_ERR(adreno_gpu->memptrs_bo);
-   adreno_gpu->memptrs_bo = NULL;
-   dev_err(drm->dev, "could not allocate memptrs: %d\n", ret);
-   return ret;
-   }
+   adreno_gpu->memptrs = msm_gem_kernel_new(drm,
+   sizeof(*adreno_gpu->memptrs), MSM_BO_UNCACHED, gpu->aspace,
+   _gpu->memptrs_bo, _gpu->memptrs_iova);
 
-   adreno_gpu->memptrs = msm_gem_get_vaddr(adreno_gpu->memptrs_bo);
if (IS_ERR(adreno_gpu->memptrs)) {
-   dev_err(drm->dev, "could not vmap memptrs\n");
-   return -ENOMEM;
-   }
-
-   ret = msm_gem_get_iova(adreno_gpu->memptrs_bo, gpu->aspace,
-   _gpu->memptrs_iova);
-   if (ret) {
-   dev_err(drm->dev, "could not map memptrs: %d\n", ret);
-   return ret;
+   ret = PTR_ERR(adreno_gpu->memptrs);
+   adreno_gpu->memptrs = NULL;
+   dev_err(drm->dev, "could not allocate memptrs: %d\n", ret);
}
 
-   return 0;
+   return ret;
 }
 
 void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 0fa9a7d..696413d 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -235,6 +235,12 @@ struct drm_gem_object *msm_gem_new(struct drm_device *dev,
uint32_t size, uint32_t flags);
 struct drm_gem_object

[PATCH 13/17] drm/msm: Support multiple ringbuffers

2017-07-27 Thread Jordan Crouse

Add the infrastructure to support the idea of multiple ringbuffers.
Assign each ringbuffer an id and use that as an index for the various
ring specific operations.

The biggest delta is to support legacy fences. Each fence gets its own
sequence number but the legacy functions expect to use a unique integer.
To handle this we return a unique identifier for each submission but
map it to a specific ring/sequence under the covers. Newer users use
a dma_fence pointer anyway so they don't care about the actual sequence
ID or ring.

The actual mechanics for multiple ringbuffers are very target specific
so this code just allows for the possibility but still only defines
one ringbuffer for each target family.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |   9 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |   9 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  45 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h   |   2 +-
 drivers/gpu/drm/msm/adreno/a5xx_power.c |   6 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 133 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  20 +++--
 drivers/gpu/drm/msm/msm_drv.h   |   2 +
 drivers/gpu/drm/msm/msm_gem.h   |   3 +-
 drivers/gpu/drm/msm/msm_gem_submit.c|   5 +-
 drivers/gpu/drm/msm/msm_gpu.c   | 146 +---
 drivers/gpu/drm/msm/msm_gpu.h   |  39 -
 drivers/gpu/drm/msm/msm_ringbuffer.c|  27 +++---
 drivers/gpu/drm/msm/msm_ringbuffer.h|  19 -
 14 files changed, 287 insertions(+), 178 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 789f7fb..4baef27 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -44,7 +44,7 @@
 
 static bool a3xx_me_init(struct msm_gpu *gpu)
 {
-   struct msm_ringbuffer *ring = gpu->rb;
+   struct msm_ringbuffer *ring = gpu->rb[0];
 
OUT_PKT3(ring, CP_ME_INIT, 17);
OUT_RING(ring, 0x03f7);
@@ -65,7 +65,7 @@ static bool a3xx_me_init(struct msm_gpu *gpu)
OUT_RING(ring, 0x);
OUT_RING(ring, 0x);
 
-   gpu->funcs->flush(gpu);
+   gpu->funcs->flush(gpu, ring);
return a3xx_idle(gpu);
 }
 
@@ -339,7 +339,7 @@ static void a3xx_destroy(struct msm_gpu *gpu)
 static bool a3xx_idle(struct msm_gpu *gpu)
 {
/* wait for ringbuffer to drain: */
-   if (!adreno_idle(gpu))
+   if (!adreno_idle(gpu, gpu->rb[0]))
return false;
 
/* then wait for GPU to finish: */
@@ -446,6 +446,7 @@ static void a3xx_dump(struct msm_gpu *gpu)
.recover = a3xx_recover,
.submit = adreno_submit,
.flush = adreno_flush,
+   .active_ring = adreno_active_ring,
.irq = a3xx_irq,
.destroy = a3xx_destroy,
 #ifdef CONFIG_DEBUG_FS
@@ -491,7 +492,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a3xx_registers;
adreno_gpu->reg_offsets = a3xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, );
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, , 1);
if (ret)
goto fail;
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index f87c4312..8199a4b 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -116,7 +116,7 @@ static void a4xx_enable_hwcg(struct msm_gpu *gpu)
 
 static bool a4xx_me_init(struct msm_gpu *gpu)
 {
-   struct msm_ringbuffer *ring = gpu->rb;
+   struct msm_ringbuffer *ring = gpu->rb[0];
 
OUT_PKT3(ring, CP_ME_INIT, 17);
OUT_RING(ring, 0x03f7);
@@ -137,7 +137,7 @@ static bool a4xx_me_init(struct msm_gpu *gpu)
OUT_RING(ring, 0x);
OUT_RING(ring, 0x);
 
-   gpu->funcs->flush(gpu);
+   gpu->funcs->flush(gpu, ring);
return a4xx_idle(gpu);
 }
 
@@ -337,7 +337,7 @@ static void a4xx_destroy(struct msm_gpu *gpu)
 static bool a4xx_idle(struct msm_gpu *gpu)
 {
/* wait for ringbuffer to drain: */
-   if (!adreno_idle(gpu))
+   if (!adreno_idle(gpu, gpu->rb[0]))
return false;
 
/* then wait for GPU to finish: */
@@ -534,6 +534,7 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
.recover = a4xx_recover,
.submit = adreno_submit,
.flush = adreno_flush,
+   .active_ring = adreno_active_ring,
.irq = a4xx_irq,
.destroy = a4xx_destroy,
 #ifdef CONFIG_DEBUG_FS
@@ -573,7 +574,7 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
adreno_gpu->registers = a4xx_registers;
adreno_gpu->reg_offsets = a4xx_register_offsets;
 
-   ret = adreno_gpu_init(dev, pdev, adreno_gpu, );
+   ret = adreno_gpu_init(dev, pdev, adreno_gpu, ,

[PATCH 14/17] drm/msm: Add a parameter query for the number of ringbuffers

2017-07-27 Thread Jordan Crouse

In order to manage ringbuffer priority to its fullest userspace
should know how many ringbuffers it has to work with. Add a
parameter to return the number of active rings.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
 include/uapi/drm/msm_drm.h  | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 5f62244..39ff842 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -50,6 +50,9 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param, 
uint64_t *value)
if (adreno_gpu->funcs->get_timestamp)
return adreno_gpu->funcs->get_timestamp(gpu, value);
return -EINVAL;
+   case MSM_PARAM_NR_RINGS:
+   *value = gpu->nr_rings;
+   return 0;
default:
DBG("%s: invalid param: %u", gpu->name, param);
return -EINVAL;
diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index a06bf97..711ea30 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -73,6 +73,7 @@ struct drm_msm_timespec {
 #define MSM_PARAM_MAX_FREQ   0x04
 #define MSM_PARAM_TIMESTAMP  0x05
 #define MSM_PARAM_GMEM_BASE  0x06
+#define MSM_PARAM_NR_RINGS   0x07
 
 struct drm_msm_param {
__u32 pipe;   /* in, MSM_PIPE_x */
-- 
1.9.1

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

[PATCH 10/17] drm/msm: Attach the GPU MMU when it is created

2017-07-27 Thread Jordan Crouse

Currently the GPU MMU is attached in the adreno_gpu code but as
more and more of the GPU initialization moves to the generic
GPU path we have a need to map and use GPU memory earlier and
earlier.  There isn't any reason to defer attaching the MMU
until later so attach it right after the address space is
created so it can be used immediately.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 27 ++-
 drivers/gpu/drm/msm/msm_gpu.c   | 83 ++---
 2 files changed, 61 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index b1c1639..634e724 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -330,11 +330,6 @@ void adreno_wait_ring(struct msm_gpu *gpu, uint32_t 
ndwords)
DRM_ERROR("%s: timeout waiting for ringbuffer space\n", 
gpu->name);
 }
 
-static const char *iommu_ports[] = {
-   "gfx3d_user", "gfx3d_priv",
-   "gfx3d1_user", "gfx3d1_priv",
-};
-
 int adreno_gpu_init(struct drm_device *drm, struct platform_device *pdev,
struct adreno_gpu *adreno_gpu, const struct adreno_gpu_funcs 
*funcs)
 {
@@ -366,15 +361,15 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
 
adreno_gpu_config.ringsz = RB_SIZE;
 
+   pm_runtime_set_autosuspend_delay(>dev, DRM_MSM_INACTIVE_PERIOD);
+   pm_runtime_use_autosuspend(>dev);
+   pm_runtime_enable(>dev);
+
ret = msm_gpu_init(drm, pdev, _gpu->base, >base,
adreno_gpu->info->name, _gpu_config);
if (ret)
return ret;
 
-   pm_runtime_set_autosuspend_delay(>dev, DRM_MSM_INACTIVE_PERIOD);
-   pm_runtime_use_autosuspend(>dev);
-   pm_runtime_enable(>dev);
-
ret = request_firmware(_gpu->pm4, adreno_gpu->info->pm4fw, 
drm->dev);
if (ret) {
dev_err(drm->dev, "failed to load %s PM4 firmware: %d\n",
@@ -389,14 +384,6 @@ int adreno_gpu_init(struct drm_device *drm, struct 
platform_device *pdev,
return ret;
}
 
-   if (gpu->aspace && gpu->aspace->mmu) {
-   struct msm_mmu *mmu = gpu->aspace->mmu;
-   ret = mmu->funcs->attach(mmu, iommu_ports,
-   ARRAY_SIZE(iommu_ports));
-   if (ret)
-   return ret;
-   }
-
adreno_gpu->memptrs_bo = msm_gem_new(drm, sizeof(*adreno_gpu->memptrs),
MSM_BO_UNCACHED);
if (IS_ERR(adreno_gpu->memptrs_bo)) {
@@ -439,10 +426,4 @@ void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
release_firmware(adreno_gpu->pfp);
 
msm_gpu_cleanup(gpu);
-
-   if (gpu->aspace) {
-   gpu->aspace->mmu->funcs->detach(gpu->aspace->mmu,
-   iommu_ports, ARRAY_SIZE(iommu_ports));
-   msm_gem_address_space_put(gpu->aspace);
-   }
 }
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 69bd60e..35533d3 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -577,11 +577,49 @@ static int get_clocks(struct platform_device *pdev, 
struct msm_gpu *gpu)
return 0;
 }
 
+static struct msm_gem_address_space *
+msm_gpu_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev,
+   uint64_t va_start, uint64_t va_end)
+{
+   struct iommu_domain *iommu;
+   struct msm_gem_address_space *aspace;
+   int ret;
+
+   /*
+* Setup IOMMU.. eventually we will (I think) do this once per context
+* and have separate page tables per context.  For now, to keep things
+* simple and to get something working, just use a single address space:
+*/
+   iommu = iommu_domain_alloc(_bus_type);
+   if (!iommu)
+   return NULL;
+
+   iommu->geometry.aperture_start = va_start;
+   iommu->geometry.aperture_end = va_end;
+
+   dev_info(gpu->dev->dev, "%s: using IOMMU\n", gpu->name);
+
+   aspace = msm_gem_address_space_create(>dev, iommu, "gpu");
+   if (IS_ERR(aspace)) {
+   dev_err(gpu->dev->dev, "failed to init iommu: %ld\n",
+   PTR_ERR(aspace));
+   iommu_domain_free(iommu);
+   return ERR_CAST(aspace);
+   }
+
+   ret = aspace->mmu->funcs->attach(aspace->mmu, NULL, 0);
+   if (ret) {
+   msm_gem_address_space_put(aspace);
+   return ERR_PTR(ret);
+   }
+
+   return aspace;
+}
+
 int msm_gpu_init(struct drm_device *drm, struct platform_device *pdev,
struct msm_gpu *gpu, const struct msm_gpu_funcs *funcs,
const char *name, struct msm_gpu_config *config)
 {
-   struct iommu_domain *iommu;
int ret;
 
if (WARN_ON(gpu->num_perfcntrs > ARRAY_SIZE(gpu->last_cntrs)))
@@

[PATCH 09/17] drm/msm: Implement per-submitqueue fences

2017-07-27 Thread Jordan Crouse

Currently we use a single fence context for the entire GPU. That
works until we start dealing with multiple ringbuffers that will
all need their own sequence number.

So in order for the user to continue using the fence functions
we will need some way to uniquely identify a submission that
gets mapped into the appropriate ringbuffer and sequence ID.

The best way to do this is to move to per-submitqueue fences.
This allows each user context to have their own monotonically
increasing identifier and we can easily map back and forth.

To implement this, create a fence context for each submitqueue
and assign user fences from that context.  Each submission will
have be assigned a submitqueue fence and a unique sequence ID for
the target ringbuffer. When the submission is retired on the ring
the fence will get signaled.

struct drm_msm_wait_fence in the UABI needs to be extended to include
the queue ID for the fence being queried. Legacy applications that
don't use submitqueues will use queue 0 by default.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  4 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 10 -
 drivers/gpu/drm/msm/msm_drv.c   | 19 -
 drivers/gpu/drm/msm/msm_drv.h   |  6 +++---
 drivers/gpu/drm/msm/msm_fence.c |  2 +-
 drivers/gpu/drm/msm/msm_fence.h |  2 +-
 drivers/gpu/drm/msm/msm_gem.h   |  1 +
 drivers/gpu/drm/msm/msm_gem_submit.c|  7 ---
 drivers/gpu/drm/msm/msm_gpu.c   | 36 +++--
 drivers/gpu/drm/msm/msm_gpu.h   |  8 +---
 drivers/gpu/drm/msm/msm_submitqueue.c   | 33 --
 include/uapi/drm/msm_drm.h  |  1 +
 12 files changed, 85 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 6361193..3acbba1 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -106,13 +106,13 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
}
 
OUT_PKT4(ring, REG_A5XX_CP_SCRATCH_REG(2), 1);
-   OUT_RING(ring, submit->fence->seqno);
+   OUT_RING(ring, submit->seqno);
 
OUT_PKT7(ring, CP_EVENT_WRITE, 4);
OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
OUT_RING(ring, lower_32_bits(rbmemptr(adreno_gpu, fence)));
OUT_RING(ring, upper_32_bits(rbmemptr(adreno_gpu, fence)));
-   OUT_RING(ring, submit->fence->seqno);
+   OUT_RING(ring, submit->seqno);
 
gpu->funcs->flush(gpu);
 }
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index f1ab270..b1c1639 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -75,7 +75,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
gpu->rb->cur = gpu->rb->start;
 
/* reset completed fence seqno: */
-   adreno_gpu->memptrs->fence = gpu->fctx->completed_fence;
+   adreno_gpu->memptrs->fence = gpu->seqno;
adreno_gpu->memptrs->rptr  = 0;
 
/* Setup REG_CP_RB_CNTL: */
@@ -165,7 +165,7 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
}
 
OUT_PKT0(ring, REG_AXXX_CP_SCRATCH_REG2, 1);
-   OUT_RING(ring, submit->fence->seqno);
+   OUT_RING(ring, submit->seqno);
 
if (adreno_is_a3xx(adreno_gpu) || adreno_is_a4xx(adreno_gpu)) {
/* Flush HLSQ lazy updates to make sure there is nothing
@@ -182,7 +182,7 @@ void adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
OUT_PKT3(ring, CP_EVENT_WRITE, 3);
OUT_RING(ring, CACHE_FLUSH_TS);
OUT_RING(ring, rbmemptr(adreno_gpu, fence));
-   OUT_RING(ring, submit->fence->seqno);
+   OUT_RING(ring, submit->seqno);
 
/* we could maybe be clever and only CP_COND_EXEC the interrupt: */
OUT_PKT3(ring, CP_INTERRUPT, 1);
@@ -255,7 +255,7 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
adreno_gpu->rev.patchid);
 
seq_printf(m, "fence:%d/%d\n", adreno_gpu->memptrs->fence,
-   gpu->fctx->last_fence);
+   gpu->seqno);
seq_printf(m, "rptr: %d\n", get_rptr(adreno_gpu));
seq_printf(m, "rb wptr:  %d\n", get_wptr(gpu->rb));
 
@@ -290,7 +290,7 @@ void adreno_dump_info(struct msm_gpu *gpu)
adreno_gpu->rev.patchid);
 
printk("fence:%d/%d\n", adreno_gpu->memptrs->fence,
-   gpu->fctx->last_fence);
+   gpu->seqno);
printk("rptr: %d\n", get_rptr(adreno_gpu));
printk("rb wptr:  %d\n", get_wptr(gpu->rb));
 }
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index f4bb909..9599d02 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -510,7 +510,7 @@ static void

[PATCH 06/17] drm/msm: Remove user from u64 data types

2017-07-27 Thread Jordan Crouse

__user should be used to identify user pointers and not __u64
variables containing pointers.

Signed-off-by: Jordan Crouse 
---
 include/uapi/drm/msm_drm.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
index 26c54f6..ad4eb28 100644
--- a/include/uapi/drm/msm_drm.h
+++ b/include/uapi/drm/msm_drm.h
@@ -171,7 +171,7 @@ struct drm_msm_gem_submit_cmd {
__u32 size;   /* in, cmdstream size */
__u32 pad;
__u32 nr_relocs;  /* in, number of submit_reloc's */
-   __u64 __user relocs;  /* in, ptr to array of submit_reloc's */
+   __u64 relocs; /* in, ptr to array of submit_reloc's */
 };
 
 /* Each buffer referenced elsewhere in the cmdstream submit (ie. the
@@ -215,8 +215,8 @@ struct drm_msm_gem_submit {
__u32 fence;  /* out */
__u32 nr_bos; /* in, number of submit_bo's */
__u32 nr_cmds;/* in, number of submit_cmd's */
-   __u64 __user bos; /* in, ptr to array of submit_bo's */
-   __u64 __user cmds;/* in, ptr to array of submit_cmd's */
+   __u64 bos;/* in, ptr to array of submit_bo's */
+   __u64 cmds;   /* in, ptr to array of submit_cmd's */
__s32 fence_fd;   /* in/out fence fd (see 
MSM_SUBMIT_FENCE_FD_IN/OUT) */
 };
 
-- 
1.9.1

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

[PATCH 05/17] drm/msm: args->fence should be args->flags

2017-07-27 Thread Jordan Crouse

Fix a typo in msm_ioctl_gem_submit - check args->flags for the
MSM_SUBMIT_NO_IMPLICIT flag instead of args->fence.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 6bfca74..c0bfe18b 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -451,7 +451,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
if (ret)
goto out;
 
-   if (!(args->fence & MSM_SUBMIT_NO_IMPLICIT)) {
+   if (!(args->flags & MSM_SUBMIT_NO_IMPLICIT)) {
ret = submit_fence_sync(submit);
if (ret)
goto out;
-- 
1.9.1

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

[PATCH 12/17] drm/msm: Move memptrs to msm_gpu

2017-07-27 Thread Jordan Crouse

When we move to multiple ringbuffers we're going to store the data
in the memptrs on a per-ring basis. In order to prepare for that
move the current memptrs from the adreno namespace into msm_gpu.
This is way cleaner and immediately lets us kill off some sub
functions so there is much less cost later when we do move to
per-ring structs.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 -
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c   |  1 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   |  6 ++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 52 -
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 16 --
 drivers/gpu/drm/msm/msm_gpu.c   | 35 --
 drivers/gpu/drm/msm/msm_gpu.h   | 17 +--
 7 files changed, 61 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 7791313..789f7fb 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -444,7 +444,6 @@ static void a3xx_dump(struct msm_gpu *gpu)
.pm_suspend = msm_gpu_pm_suspend,
.pm_resume = msm_gpu_pm_resume,
.recover = a3xx_recover,
-   .last_fence = adreno_last_fence,
.submit = adreno_submit,
.flush = adreno_flush,
.irq = a3xx_irq,
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 58341ef..f87c4312 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -532,7 +532,6 @@ static int a4xx_get_timestamp(struct msm_gpu *gpu, uint64_t 
*value)
.pm_suspend = a4xx_pm_suspend,
.pm_resume = a4xx_pm_resume,
.recover = a4xx_recover,
-   .last_fence = adreno_last_fence,
.submit = adreno_submit,
.flush = adreno_flush,
.irq = a4xx_irq,
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index e533007..c986a76 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -83,7 +83,6 @@ static int zap_shader_load_mdt(struct device *dev, const char 
*fwname)
 static void a5xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct msm_drm_private *priv = gpu->dev->dev_private;
struct msm_ringbuffer *ring = gpu->rb;
unsigned int i, ibs = 0;
@@ -110,8 +109,8 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
 
OUT_PKT7(ring, CP_EVENT_WRITE, 4);
OUT_RING(ring, CACHE_FLUSH_TS | (1 << 31));
-   OUT_RING(ring, lower_32_bits(rbmemptr(adreno_gpu, fence)));
-   OUT_RING(ring, upper_32_bits(rbmemptr(adreno_gpu, fence)));
+   OUT_RING(ring, lower_32_bits(rbmemptr(gpu, fence)));
+   OUT_RING(ring, upper_32_bits(rbmemptr(gpu, fence)));
OUT_RING(ring, submit->seqno);
 
gpu->funcs->flush(gpu);
@@ -1025,7 +1024,6 @@ static void a5xx_show(struct msm_gpu *gpu, struct 
seq_file *m)
.pm_suspend = a5xx_pm_suspend,
.pm_resume = a5xx_pm_resume,
.recover = a5xx_recover,
-   .last_fence = adreno_last_fence,
.submit = a5xx_submit,
.flush = adreno_flush,
.irq = a5xx_irq,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 6d65684..552e692 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -75,8 +75,8 @@ int adreno_hw_init(struct msm_gpu *gpu)
gpu->rb->cur = gpu->rb->start;
 
/* reset completed fence seqno: */
-   adreno_gpu->memptrs->fence = gpu->seqno;
-   adreno_gpu->memptrs->rptr  = 0;
+   gpu->memptrs->fence = gpu->seqno;
+   gpu->memptrs->rptr  = 0;
 
/* Setup REG_CP_RB_CNTL: */
adreno_gpu_write(adreno_gpu, REG_ADRENO_CP_RB_CNTL,
@@ -91,8 +91,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
 
if (!adreno_is_a430(adreno_gpu)) {
adreno_gpu_write64(adreno_gpu, REG_ADRENO_CP_RB_RPTR_ADDR,
-   REG_ADRENO_CP_RB_RPTR_ADDR_HI,
-   rbmemptr(adreno_gpu, rptr));
+   REG_ADRENO_CP_RB_RPTR_ADDR_HI, rbmemptr(gpu, rptr));
}
 
return 0;
@@ -106,17 +105,13 @@ static uint32_t get_wptr(struct msm_ringbuffer *ring)
 /* Use this helper to read rptr, since a430 doesn't update rptr in memory */
 static uint32_t get_rptr(struct adreno_gpu *adreno_gpu)
 {
+   struct msm_gpu *gpu = _gpu->base;
+
if (adreno_is_a430(adreno_gpu))
-   return adreno_gpu->memptrs->rptr = adreno_gpu_read(
+   return gpu->memptrs->rptr = adreno_gpu_read(

[PATCH 04/17] drm/msm: Remove uneeded platform dev members

2017-07-27 Thread Jordan Crouse

Commit eeb754746b14 ("drm/msm/gpu: use pm-runtime") adds a pointer
for the GPU platform device to the msm_gpu struct so we can
happily remove the same pointers from the individual GPU
structs.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 2 --
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h | 1 -
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 2 --
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h | 1 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 +--
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 1 -
 6 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 0e3828ed..7791313 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -486,8 +486,6 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
adreno_gpu = _gpu->base;
gpu = _gpu->base;
 
-   a3xx_gpu->pdev = pdev;
-
gpu->perfcntrs = perfcntrs;
gpu->num_perfcntrs = ARRAY_SIZE(perfcntrs);
 
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
index 85ff66c..ab60dc9 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.h
@@ -28,7 +28,6 @@
 
 struct a3xx_gpu {
struct adreno_gpu base;
-   struct platform_device *pdev;
 
/* if OCMEM is used for GMEM: */
uint32_t ocmem_base;
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index 19abf22..58341ef 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -568,8 +568,6 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
adreno_gpu = _gpu->base;
gpu = _gpu->base;
 
-   a4xx_gpu->pdev = pdev;
-
gpu->perfcntrs = NULL;
gpu->num_perfcntrs = 0;
 
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.h
index 0124720..f757184 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.h
@@ -23,7 +23,6 @@
 
 struct a4xx_gpu {
struct adreno_gpu base;
-   struct platform_device *pdev;
 
/* if OCMEM is used for GMEM: */
uint32_t ocmem_base;
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 33763b0..3af29cae 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -397,7 +397,7 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
static bool loaded;
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
-   struct platform_device *pdev = a5xx_gpu->pdev;
+   struct platform_device *pdev = gpu->pdev;
int ret;
 
/*
@@ -1046,7 +1046,6 @@ struct msm_gpu *a5xx_gpu_init(struct drm_device *dev)
adreno_gpu = _gpu->base;
gpu = _gpu->base;
 
-   a5xx_gpu->pdev = pdev;
adreno_gpu->registers = a5xx_registers;
adreno_gpu->reg_offsets = a5xx_register_offsets;
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index d24796f..3d62f00 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -23,7 +23,6 @@
 
 struct a5xx_gpu {
struct adreno_gpu base;
-   struct platform_device *pdev;
 
struct drm_gem_object *pm4_bo;
uint64_t pm4_iova;
-- 
1.9.1

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

[PATCH 07/17] drm/msm: Add A5XX hardware fault detection

2017-07-27 Thread Jordan Crouse

The A5XX GPU has really good hardware fault detection that can
detect a abnormal hardware condition and fire an interrupt in
a matter of milliseconds which is a lot better than waiting for
the hangcheck timer.

Enable the interrupt and log information before kicking off
recovery.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 3af29cae..6361193 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -438,6 +438,7 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
  A5XX_RBBM_INT_0_MASK_RBBM_ETS_MS_TIMEOUT | \
  A5XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNC_OVERFLOW | \
  A5XX_RBBM_INT_0_MASK_CP_HW_ERROR | \
+ A5XX_RBBM_INT_0_MASK_MISC_HANG_DETECT | \
  A5XX_RBBM_INT_0_MASK_CP_CACHE_FLUSH_TS | \
  A5XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS | \
  A5XX_RBBM_INT_0_MASK_GPMU_VOLTAGE_DROOP)
@@ -843,6 +844,28 @@ static void a5xx_gpmu_err_irq(struct msm_gpu *gpu)
dev_err_ratelimited(gpu->dev->dev, "GPMU | voltage droop\n");
 }
 
+static void a5xx_fault_detect_irq(struct msm_gpu *gpu)
+{
+   struct drm_device *dev = gpu->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct msm_ringbuffer *ring = gpu->funcs->active_ring(gpu);
+
+   dev_err(dev->dev, "gpu fault ring %d fence %x status %8.8X rb 
%4.4x/%4.4x ib1 %16.16llX/%4.4x ib2 %16.16llX/%4.4x\n",
+   ring ? ring->id : -1, ring ? ring->seqno : 0,
+   gpu_read(gpu, REG_A5XX_RBBM_STATUS),
+   gpu_read(gpu, REG_A5XX_CP_RB_RPTR),
+   gpu_read(gpu, REG_A5XX_CP_RB_WPTR),
+   gpu_read64(gpu, REG_A5XX_CP_IB1_BASE, REG_A5XX_CP_IB1_BASE_HI),
+   gpu_read(gpu, REG_A5XX_CP_IB1_BUFSZ),
+   gpu_read64(gpu, REG_A5XX_CP_IB2_BASE, REG_A5XX_CP_IB2_BASE_HI),
+   gpu_read(gpu, REG_A5XX_CP_IB2_BUFSZ));
+
+   /* Turn off the hangcheck timer to keep it from bothering us */
+   del_timer(>hangcheck_timer);
+
+   queue_work(priv->wq, >recover_work);
+}
+
 #define RBBM_ERROR_MASK \
(A5XX_RBBM_INT_0_MASK_RBBM_AHB_ERROR | \
A5XX_RBBM_INT_0_MASK_RBBM_TRANSFER_TIMEOUT | \
@@ -869,6 +892,9 @@ static irqreturn_t a5xx_irq(struct msm_gpu *gpu)
if (status & A5XX_RBBM_INT_0_MASK_CP_HW_ERROR)
a5xx_cp_err_irq(gpu);
 
+   if (status & A5XX_RBBM_INT_0_MASK_MISC_HANG_DETECT)
+   a5xx_fault_detect_irq(gpu);
+
if (status & A5XX_RBBM_INT_0_MASK_UCHE_OOB_ACCESS)
a5xx_uche_err_irq(gpu);
 
-- 
1.9.1

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

[PATCH 03/17] drm/msm: Turn off hardware clock gating before reading A5XX registers

2017-07-27 Thread Jordan Crouse

On A5XX GPU hardware clock gating needs to be turned off before
reading certain GPU registers via AHB. Turn off HWCG before calling
adreno_show() to safely dump all the registers without a system hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index c1f8c20..33763b0 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -995,7 +995,14 @@ static void a5xx_show(struct msm_gpu *gpu, struct seq_file 
*m)
 {
seq_printf(m, "status:   %08x\n",
gpu_read(gpu, REG_A5XX_RBBM_STATUS));
+
+   /*
+* Temporarily disable hardware clock gating before going into
+* adreno_show to avoid issues while reading the registers
+*/
+   a5xx_set_hwcg(gpu, false);
adreno_show(gpu, m);
+   a5xx_set_hwcg(gpu, true);
 }
 #endif
 
-- 
1.9.1

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

[PATCH 01/17] drm/msm: Remove some potentially blocked register ranges

2017-07-27 Thread Jordan Crouse

The 0xf400 and 0xf800 ranges are in the RBBM_SECVID block which may
be protected from CPU access. Skip dumping them since they are minimally
useful for debugging and they aren't worth a system hang.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 49 +--
 1 file changed, 24 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index b4b54f1..1f60a9a 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -920,31 +920,30 @@ static irqreturn_t a5xx_irq(struct msm_gpu *gpu)
0x, 0x0002, 0x0004, 0x0020, 0x0022, 0x0026, 0x0029, 0x002B,
0x002E, 0x0035, 0x0038, 0x0042, 0x0044, 0x0044, 0x0047, 0x0095,
0x0097, 0x00BB, 0x03A0, 0x0464, 0x0469, 0x046F, 0x04D2, 0x04D3,
-   0x04E0, 0x0533, 0x0540, 0x0555, 0xF400, 0xF400, 0xF800, 0xF807,
-   0x0800, 0x081A, 0x081F, 0x0841, 0x0860, 0x0860, 0x0880, 0x08A0,
-   0x0B00, 0x0B12, 0x0B15, 0x0B28, 0x0B78, 0x0B7F, 0x0BB0, 0x0BBD,
-   0x0BC0, 0x0BC6, 0x0BD0, 0x0C53, 0x0C60, 0x0C61, 0x0C80, 0x0C82,
-   0x0C84, 0x0C85, 0x0C90, 0x0C98, 0x0CA0, 0x0CA0, 0x0CB0, 0x0CB2,
-   0x2180, 0x2185, 0x2580, 0x2585, 0x0CC1, 0x0CC1, 0x0CC4, 0x0CC7,
-   0x0CCC, 0x0CCC, 0x0CD0, 0x0CD8, 0x0CE0, 0x0CE5, 0x0CE8, 0x0CE8,
-   0x0CEC, 0x0CF1, 0x0CFB, 0x0D0E, 0x2100, 0x211E, 0x2140, 0x2145,
-   0x2500, 0x251E, 0x2540, 0x2545, 0x0D10, 0x0D17, 0x0D20, 0x0D23,
-   0x0D30, 0x0D30, 0x20C0, 0x20C0, 0x24C0, 0x24C0, 0x0E40, 0x0E43,
-   0x0E4A, 0x0E4A, 0x0E50, 0x0E57, 0x0E60, 0x0E7C, 0x0E80, 0x0E8E,
-   0x0E90, 0x0E96, 0x0EA0, 0x0EA8, 0x0EB0, 0x0EB2, 0xE140, 0xE147,
-   0xE150, 0xE187, 0xE1A0, 0xE1A9, 0xE1B0, 0xE1B6, 0xE1C0, 0xE1C7,
-   0xE1D0, 0xE1D1, 0xE200, 0xE201, 0xE210, 0xE21C, 0xE240, 0xE268,
-   0xE000, 0xE006, 0xE010, 0xE09A, 0xE0A0, 0xE0A4, 0xE0AA, 0xE0EB,
-   0xE100, 0xE105, 0xE380, 0xE38F, 0xE3B0, 0xE3B0, 0xE400, 0xE405,
-   0xE408, 0xE4E9, 0xE4F0, 0xE4F0, 0xE280, 0xE280, 0xE282, 0xE2A3,
-   0xE2A5, 0xE2C2, 0xE940, 0xE947, 0xE950, 0xE987, 0xE9A0, 0xE9A9,
-   0xE9B0, 0xE9B6, 0xE9C0, 0xE9C7, 0xE9D0, 0xE9D1, 0xEA00, 0xEA01,
-   0xEA10, 0xEA1C, 0xEA40, 0xEA68, 0xE800, 0xE806, 0xE810, 0xE89A,
-   0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB, 0xE900, 0xE905, 0xEB80, 0xEB8F,
-   0xEBB0, 0xEBB0, 0xEC00, 0xEC05, 0xEC08, 0xECE9, 0xECF0, 0xECF0,
-   0xEA80, 0xEA80, 0xEA82, 0xEAA3, 0xEAA5, 0xEAC2, 0xA800, 0xA8FF,
-   0xAC60, 0xAC60, 0xB000, 0xB97F, 0xB9A0, 0xB9BF,
-   ~0
+   0x04E0, 0x0533, 0x0540, 0x0555, 0x0800, 0x081A, 0x081F, 0x0841,
+   0x0860, 0x0860, 0x0880, 0x08A0, 0x0B00, 0x0B12, 0x0B15, 0x0B28,
+   0x0B78, 0x0B7F, 0x0BB0, 0x0BBD, 0x0BC0, 0x0BC6, 0x0BD0, 0x0C53,
+   0x0C60, 0x0C61, 0x0C80, 0x0C82, 0x0C84, 0x0C85, 0x0C90, 0x0C98,
+   0x0CA0, 0x0CA0, 0x0CB0, 0x0CB2, 0x2180, 0x2185, 0x2580, 0x2585,
+   0x0CC1, 0x0CC1, 0x0CC4, 0x0CC7, 0x0CCC, 0x0CCC, 0x0CD0, 0x0CD8,
+   0x0CE0, 0x0CE5, 0x0CE8, 0x0CE8, 0x0CEC, 0x0CF1, 0x0CFB, 0x0D0E,
+   0x2100, 0x211E, 0x2140, 0x2145, 0x2500, 0x251E, 0x2540, 0x2545,
+   0x0D10, 0x0D17, 0x0D20, 0x0D23, 0x0D30, 0x0D30, 0x20C0, 0x20C0,
+   0x24C0, 0x24C0, 0x0E40, 0x0E43, 0x0E4A, 0x0E4A, 0x0E50, 0x0E57,
+   0x0E60, 0x0E7C, 0x0E80, 0x0E8E, 0x0E90, 0x0E96, 0x0EA0, 0x0EA8,
+   0x0EB0, 0x0EB2, 0xE140, 0xE147, 0xE150, 0xE187, 0xE1A0, 0xE1A9,
+   0xE1B0, 0xE1B6, 0xE1C0, 0xE1C7, 0xE1D0, 0xE1D1, 0xE200, 0xE201,
+   0xE210, 0xE21C, 0xE240, 0xE268, 0xE000, 0xE006, 0xE010, 0xE09A,
+   0xE0A0, 0xE0A4, 0xE0AA, 0xE0EB, 0xE100, 0xE105, 0xE380, 0xE38F,
+   0xE3B0, 0xE3B0, 0xE400, 0xE405, 0xE408, 0xE4E9, 0xE4F0, 0xE4F0,
+   0xE280, 0xE280, 0xE282, 0xE2A3, 0xE2A5, 0xE2C2, 0xE940, 0xE947,
+   0xE950, 0xE987, 0xE9A0, 0xE9A9, 0xE9B0, 0xE9B6, 0xE9C0, 0xE9C7,
+   0xE9D0, 0xE9D1, 0xEA00, 0xEA01, 0xEA10, 0xEA1C, 0xEA40, 0xEA68,
+   0xE800, 0xE806, 0xE810, 0xE89A, 0xE8A0, 0xE8A4, 0xE8AA, 0xE8EB,
+   0xE900, 0xE905, 0xEB80, 0xEB8F, 0xEBB0, 0xEBB0, 0xEC00, 0xEC05,
+   0xEC08, 0xECE9, 0xECF0, 0xECF0, 0xEA80, 0xEA80, 0xEA82, 0xEAA3,
+   0xEAA5, 0xEAC2, 0xA800, 0xA8FF, 0xAC60, 0xAC60, 0xB000, 0xB97F,
+   0xB9A0, 0xB9BF, ~0
 };
 
 static void a5xx_dump(struct msm_gpu *gpu)
-- 
1.9.1

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

[PATCH 02/17] drm/msm: Allow hardware clock gating to be toggled

2017-07-27 Thread Jordan Crouse

There are some use cases wherein we need to turn off hardware clock
gating before reading certain registers. Modify the A5XX HWCG function
to allow user to enable or disable clock gating at will.

Signed-off-by: Jordan Crouse 
---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 42 ---
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h |  1 +
 2 files changed, 10 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 1f60a9a..c1f8c20 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -117,12 +117,10 @@ static void a5xx_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
gpu->funcs->flush(gpu);
 }
 
-struct a5xx_hwcg {
+static const struct {
u32 offset;
u32 value;
-};
-
-static const struct a5xx_hwcg a530_hwcg[] = {
+} a5xx_hwcg[] = {
{REG_A5XX_RBBM_CLOCK_CNTL_SP0, 0x0222},
{REG_A5XX_RBBM_CLOCK_CNTL_SP1, 0x0222},
{REG_A5XX_RBBM_CLOCK_CNTL_SP2, 0x0222},
@@ -217,38 +215,16 @@ struct a5xx_hwcg {
{REG_A5XX_RBBM_CLOCK_DELAY_VFD, 0x}
 };
 
-static const struct {
-   int (*test)(struct adreno_gpu *gpu);
-   const struct a5xx_hwcg *regs;
-   unsigned int count;
-} a5xx_hwcg_regs[] = {
-   { adreno_is_a530, a530_hwcg, ARRAY_SIZE(a530_hwcg), },
-};
-
-static void _a5xx_enable_hwcg(struct msm_gpu *gpu,
-   const struct a5xx_hwcg *regs, unsigned int count)
+void a5xx_set_hwcg(struct msm_gpu *gpu, bool state)
 {
unsigned int i;
 
-   for (i = 0; i < count; i++)
-   gpu_write(gpu, regs[i].offset, regs[i].value);
-
-   gpu_write(gpu, REG_A5XX_RBBM_CLOCK_CNTL, 0xAAA8AA00);
-   gpu_write(gpu, REG_A5XX_RBBM_ISDB_CNT, 0x182);
-}
+   for (i = 0; i < ARRAY_SIZE(a5xx_hwcg); i++)
+   gpu_write(gpu, a5xx_hwcg[i].offset,
+   state ? a5xx_hwcg[i].value : 0);
 
-static void a5xx_enable_hwcg(struct msm_gpu *gpu)
-{
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
-   unsigned int i;
-
-   for (i = 0; i < ARRAY_SIZE(a5xx_hwcg_regs); i++) {
-   if (a5xx_hwcg_regs[i].test(adreno_gpu)) {
-   _a5xx_enable_hwcg(gpu, a5xx_hwcg_regs[i].regs,
-   a5xx_hwcg_regs[i].count);
-   return;
-   }
-   }
+   gpu_write(gpu, REG_A5XX_RBBM_CLOCK_CNTL, state ? 0xAAA8AA00 : 0);
+   gpu_write(gpu, REG_A5XX_RBBM_ISDB_CNT, state ? 0x182 : 0x180);
 }
 
 static int a5xx_me_init(struct msm_gpu *gpu)
@@ -545,7 +521,7 @@ static int a5xx_hw_init(struct msm_gpu *gpu)
gpu_write(gpu, REG_A5XX_RBBM_AHB_CNTL1, 0xA6FF);
 
/* Enable HWCG */
-   a5xx_enable_hwcg(gpu);
+   a5xx_set_hwcg(gpu, true);
 
gpu_write(gpu, REG_A5XX_RBBM_AHB_CNTL2, 0x003F);
 
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
index 6638bc8..d24796f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.h
@@ -59,5 +59,6 @@ static inline int spin_usecs(struct msm_gpu *gpu, uint32_t 
usecs,
 }
 
 bool a5xx_idle(struct msm_gpu *gpu);
+void a5xx_set_hwcg(struct msm_gpu *gpu, bool state);
 
 #endif /* __A5XX_GPU_H__ */
-- 
1.9.1

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

[PATCH 00/17] drm/msm: GPU fixes and features for 4.14

2017-07-27 Thread Jordan Crouse

Here is my stack of Adreno GPU goodness for 4.14.  Starting off with a few
fixes that could be appropriate for 4.13 if you deem them so and
then moving into some new features:

 - a5xx hardware fault detection - can detect a legitimate fault within
 microseconds and fires an interrupt so you should be able to recover
 and move on much faster than relying on the timer.

 - submitqueues - submitqueues are the kernel side equivalent of a
 context. The user can set submitqueue specific flags and features
 (such as ringbuffer priority) and in the following patch we move
 to per-submitqueue fences.

 - multiple ringbuffer preemption - provide for multiple ringbuffers,
  allow the user to select a ringbuffer to submit on and preempt
  between the different priorities.  You've seen some of this code
  before but some of our newer features have cleaned things up
  significantly. 

Jordan Crouse (17):
  drm/msm: Remove some potentially blocked register ranges
  drm/msm: Allow hardware clock gating to be toggled
  drm/msm: Turn off hardware clock gating before reading A5XX registers
  drm/msm: Remove uneeded platform dev members
  drm/msm: args->fence should be args->flags
  drm/msm: Remove __user from __u64 data types
  drm/msm: Add A5XX hardware fault detection
  drm/msm: Add per-instance submit queues
  drm/msm: Implement per-submitqueue fences
  drm/msm: Attach the GPU MMU when it is created
  drm/msm: Add a helper function for in-kernel buffer allocations
  drm/msm: Move memptrs to msm_gpu
  drm/msm: Support multiple ringbuffers
  drm/msm: Add a parameter query for the number of ringbuffers
  drm/msm: Shadow current pointer in the ring until command is complete
  drm/msm: Make the value of RB_CNTL (almost) generic
  drm/msm: Implement preemption for A5XX targets

 drivers/gpu/drm/msm/Makefile  |   4 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  12 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h |   1 -
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  12 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.h |   1 -
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 366 +-
 drivers/gpu/drm/msm/adreno/a5xx_gpu.h | 105 -
 drivers/gpu/drm/msm/adreno/a5xx_power.c   |  20 +-
 drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 294 
 drivers/gpu/drm/msm/adreno/adreno_gpu.c   | 224 --
 drivers/gpu/drm/msm/adreno/adreno_gpu.h   |  43 ++--
 drivers/gpu/drm/msm/msm_drv.c |  62 -
 drivers/gpu/drm/msm/msm_drv.h |  28 ++-
 drivers/gpu/drm/msm/msm_fbdev.c   |  35 ++-
 drivers/gpu/drm/msm/msm_fence.c   |   2 +-
 drivers/gpu/drm/msm/msm_fence.h   |   2 +-
 drivers/gpu/drm/msm/msm_gem.c |  46 
 drivers/gpu/drm/msm/msm_gem.h |   5 +-
 drivers/gpu/drm/msm/msm_gem_submit.c  |  27 ++-
 drivers/gpu/drm/msm/msm_gpu.c | 259 +++--
 drivers/gpu/drm/msm/msm_gpu.h |  54 -
 drivers/gpu/drm/msm/msm_ringbuffer.c  |  35 +--
 drivers/gpu/drm/msm/msm_ringbuffer.h  |  32 ++-
 drivers/gpu/drm/msm/msm_submitqueue.c | 160 +
 include/uapi/drm/msm_drm.h|  30 ++-
 25 files changed, 1422 insertions(+), 437 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a5xx_preempt.c
 create mode 100644 drivers/gpu/drm/msm/msm_submitqueue.c

-- 
1.9.1

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

[pull] radeon and amdgpu drm-next-4.14

2017-07-27 Thread Alex Deucher

Hi Dave,

New features for 4.14:
- Stop reprogramming the MC, the vbios already does this in asic_init
- Reduce internal gart to 256M (this does not affect the ttm GTT pool size)
- Initial support for huge pages
- Rework bo migration logic
- Lots of improvements for vega10
- Powerplay fixes
- Additional Raven enablement
- SR-IOV improvements
- Bug fixes
- Code cleanup

The following changes since commit 6419ec78c6726aa54ff103aceffbf19d546d3d1b:

  Merge branch 'drm-next-4.13' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-07-13 13:38:22 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.14

for you to fetch changes up to 799c7b20b26078e1e3b1c7d38e9ffce9bb56348d:

  drm/amdgpu: fix header on gfx9 clear state (2017-07-27 11:17:45 -0400)


Alex Deucher (31):
  drm/amdgpu: use kernel is_power_of_2 rather than local version
  drm/amdgpu: disable vga render in dce hw_init
  drm/amdgpu/gmc8: use the vram location programmed by the vbios
  drm/amdgpu/gmc7: use the vram location programmed by the vbios
  drm/amdgpu/gmc6: use the vram location programmed by the vbios
  drm/amdgpu/gmc8: drop fb location programming
  drm/amdgpu/gmc7: drop fb location programming
  drm/amdgpu/gmc6: drop fb location programming
  drm/amdgpu: drop set_vga_render_state from display funcs
  drm/amdgpu: remove *_mc_access from display funcs
  drm/amdgpu/atombios: use bios_scratch_reg_offset for atombios
  drm/amdgpu: unify some atombios/atomfirmware scratch reg functions
  drm/amdgpu/atombios: add function for whether we need asic_init
  drm/amdgpu/atom: fix atom_fw check
  drm/amdgpu/atomfirmware: implement vram_width for APUs
  drm/amdgpu/gmc9: get vram width from atom for Raven
  drm/amdgpu: add nbio 6.1 register init function
  drm/amdgpu/soc15: init nbio registers for vega10
  drm/amdgpu: check scratch registers to see if we need post (v2)
  drm/amdgpu: add get_clock_info for atomfirmware
  drm/amdgpu: call atomfirmware get_clock_info for atomfirmware systems
  drm/amdgpu/soc15: drop dead function
  drm/amdgpu: implement si_read_bios_from_rom
  drm/amdgpu/gfx: keep all compute queues on the same pipe
  drm/amdgpu: remove VM shadow WARN_ONs
  drm/amdgpu: enable huge page handling in the VM v5
  drm/amdgpu/gmc6: disable legacy vga features in gmc init (v2)
  drm/amdgpu/gmc7: disable legacy vga features in gmc init
  drm/amdgpu/gmc8: disable legacy vga features in gmc init
  drm/amdgpu/gmc9: disable legacy vga features in gmc init
  drm/amdgpu: fix header on gfx9 clear state

Alex Xie (2):
  drm/amdgpu: Free resources of bo_list when idr_alloc fails
  drm/amdgpu: Fix blocking in RCU critical section(v2)

Arvind Yadav (3):
  drm: radeon: radeon_ttm: constify ttm_place structures.
  drm: radeon: constify drm_prop_enum_list structures.
  drm: amd: amdgpu: constify ttm_place structures.

Christian König (31):
  drm/amdgpu: simplify VM shadow handling v2
  drm/amdgpu: cleanup initializing gtt_size
  drm/amdgpu: fix amdgpu_debugfs_gem_bo_info
  drm/amdgpu: move ring helpers to amdgpu_ring.h
  drm/amdgpu: fix amdgpu_ring_write_multiple
  drm/amdgpu: allow flushing VMID0 before IB execution as well
  drm/amdgpu: add vm_needs_flush parameter to amdgpu_copy_buffer
  drm/amdgpu: bind BOs to TTM only once
  drm/amdgpu: bind BOs with GTT space allocated directly v2
  drm/amdgpu: remove stale TODO comment
  drm/amdgpu: trace VM flags as 64bits
  drm/amdgpu: reserve the first 2x512 pages of GART
  drm/amdgpu: add amdgpu_gart_map function v2
  drm/amdgpu: use the GTT windows for BO moves v2
  drm/amdgpu: stop mapping BOs to GTT
  drm/amdgpu: remove maximum BO size limitation v2
  drm/amdgpu: use TTM values instead of MC values for the info queries
  drm/amdgpu: move GART struct and function into amdgpu_gart.h v2
  drm/amdgpu: remove gtt_base_align handling
  drm/amdgpu: consistent name all GART related parts
  drm/amdgpu: limit the GTT manager address space
  drm/amdgpu: add new gttsize module parameter v2
  drm/amdgpu: change gartsize default to 256MB
  drm/amdgpu: fix VM flush for CPU based updates
  drm/amdgpu: fix amdgpu_vm_bo_wait
  drm/amdgpu: trace setting VM page tables with the CPU as well
  drm/amdgpu: flush the HDP only once for CPU based VM updates
  drm/amdgpu: make sure BOs are always kunmapped
  drm/amdgpu: map VM BOs for CPU based updates only once
  drm/amdgpu: fix amdgpu_bo_gpu_accessible()
  drm/amdgpu: increase fragmentation size for Vega10 v2

Chunming Zhou (1):
  drm/amdgpu: ttm_bind only when user needs gpu_addr in bo pin

Colin Ian King (1):
  drm/amdgpu: make arrays pctl0_data and pctl1_data static

Dan Carpenter (1):

Re: [PATCH 01/41] drm/gem: Add drm_gem_dumb_map_offset()

2017-07-27 Thread Noralf Trønnes



Den 27.07.2017 02.13, skrev Emil Velikov:

On 26 July 2017 at 19:41, Noralf Trønnes  wrote:

Den 26.07.2017 14.05, skrev Emil Velikov:

Hi Noralf,


On 23 July 2017 at 20:16, Noralf Trønnes  wrote:

Add a common drm_driver.dumb_map_offset function for GEM backed drivers.

Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/drm_gem.c | 35 +++
   include/drm/drm_gem.h |  2 ++
   2 files changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 5df028a..a8d396b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -311,6 +311,41 @@ drm_gem_handle_delete(struct drm_file *filp, u32
handle)
   EXPORT_SYMBOL(drm_gem_handle_delete);

   /**
+ * drm_gem_dumb_map_offset - return the fake mmap offset for a gem
object
+ * @file: drm file-private structure containing the gem object
+ * @dev: corresponding drm_device
+ * @handle: gem object handle
+ * @offset: return location for the fake mmap offset
+ *
+ * This implements the _driver.dumb_map_offset kms driver callback
for
+ * drivers which use gem to manage their backing storage.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ */
+int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
*dev,
+   u32 handle, u64 *offset)
+{
+   struct drm_gem_object *obj;
+   int ret;
+
+   obj = drm_gem_object_lookup(file, handle);
+   if (!obj)
+   return -ENOENT;
+
+   ret = drm_gem_create_mmap_offset(obj);

With later patches one goes to reuse this helper instead of
drm_gem_cma_dumb_map_offset().
At the same time, the latter does not have the
drm_gem_create_mmap_offset() call we see here.


You're rigth, the cma library and a couple of other drivers if I recall
correctly, call drm_gem_create_mmap_offset() during object creation.
Daniel was of the opinion that this should happen when mmap is called.
drm_gem_create_mmap_offset() is idempotent as the docs call it. Calling
it a second time is ok, since it does nothing (needs to take a lock
though).

I haven't removed drm_gem_create_mmap_offset() from the drivers that do
it during object creation, trying to keep this from doing to much.
The cma library will be changed though when I add the generic fb/gem
helper.


I was not concerned about calling the function twice, but that it's
not called at all ...
Which doesn't seems to be the case - virtually all the .dumb_create
callbacks effectively end up in __drm_gem_cma_create() which itself
calls drm_gem_create_mmap_offset().

I should have looked deeper into the rabbit hole :-)

One thing that I forgot to mention:
Depending on the tree you're working on, please grep through staging
as well - the vbox drm driver got merged somewhat recently.


Meanwhile some drivers have their own offset function which is
virtually identical to the original drm_gem_cma_dumb_map_offset.
Yet those are left unchanged.

For example in cirrus [1]:
There the only code difference seems to be an "upcast" followed
immediately by a "downcast". Which should effectively be a noop.


The main reason for that is to try and keep this simple so I'm able to
add my shmem/gem library in reasonable time :-) I didn't want to do
changes that wasn't straight forward. But yes, the cirrus drivers looks
quite straight forward and the functions isn't used by other parts of
the driver. I looked at a driver (omap?) that had similar functions,
and those where called from other parts of the driver, so I expected
the same here I guess.

You say "some drivers", can you name them?
Some drivers takes locks or do other stuff that made me skip them.


Agreed - keeping that cleanup separate might be the wise thing to do.
Pardon if I came too impatient.

About a list - initial grep showed cirrus, bochs, qxl.
Now, after having a more extensive look - cirrus, qxl, ast, nouveau,
exynos, hibmc, mgag200, bochs, virtio.


All of those except exynos gets their offset from 
ttm_buffer_object->vma_node

and not drm_gem_object.vma_node. Is it the same vma_node?

I'll add exynos in the second round, I missed that one.

Thanks for the scrutiny, it's appreciated.

Noralf.


On the "maybe" list - msm and omap have extra locking (is it still
needed?) while armada has an import_attach restriction (where nobody
else seems to bother?).

The remaining drivers seem a bit more complicated.

HTH
Emil



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

Re: [PATCH v2 3/4] drm/i915: Call uncore_suspend before platform suspend handlers

2017-07-27 Thread Imre Deak

On Thu, Jul 06, 2017 at 09:24:49PM +0200, Hans de Goede wrote:
> Quoting Ville: "the forcewake timer might still be active until the uncore
> suspend, and having active forcewakes while we've already told the GT wake
> stuff to stop acting normally doesn't seem quite right to me."
> 
> Reported-by: Ville Syrjälä 
> Suggested-by: Imre Deak 
> Signed-off-by: Hans de Goede 

> ---
> Changes in v2:
> -Rebase on current (July 6th 2017) drm-next
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ce31d9ed23dc..4a6cd3176e0a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2415,6 +2415,8 @@ static int intel_runtime_suspend(struct device *kdev)
>  
>   intel_runtime_pm_disable_interrupts(dev_priv);
>  
> + intel_uncore_suspend(dev_priv);
> +

Yep, this fixes a problem on VLV independent of your IOSF/forcewake
fix. vlv_suspend_complete() calls vlv_allow_gt_wake(false) after which
we shouldn't have any pending forcewakes until resume.

AFAICS after this point there isn't anything requiring forcewake until
resume so the change looks ok:

Reviewed-by: Imre Deak 

>   ret = 0;
>   if (IS_GEN9_LP(dev_priv)) {
>   bxt_display_core_uninit(dev_priv);
> @@ -2427,6 +2429,8 @@ static int intel_runtime_suspend(struct device *kdev)
>  
>   if (ret) {
>   DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
> + intel_uncore_runtime_resume(dev_priv);
> +
>   intel_runtime_pm_enable_interrupts(dev_priv);
>  
>   enable_rpm_wakeref_asserts(dev_priv);
> @@ -2434,8 +2438,6 @@ static int intel_runtime_suspend(struct device *kdev)
>   return ret;
>   }
>  
> - intel_uncore_suspend(dev_priv);
> -
>   enable_rpm_wakeref_asserts(dev_priv);
>   WARN_ON_ONCE(atomic_read(_priv->pm.wakeref_count));
>  
> -- 
> 2.13.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/4] drm/i915: Re-register PMIC bus access notifier on runtime resume

2017-07-27 Thread Imre Deak

On Thu, Jul 06, 2017 at 09:24:48PM +0200, Hans de Goede wrote:
> intel_uncore_suspend() unregisters the uncore code's PMIC bus access
> notifier and gets called on both normal and runtime suspend.
> 
> intel_uncore_resume_early() re-registers the notifier, but only on
> normal resume. Add a new intel_uncore_runtime_resume() function which
> only re-registers the notifier and call that on runtime resume.
> 
> Reported-by: Imre Deak 
> Signed-off-by: Hans de Goede 

Reviewed-by: Imre Deak 

> ---
> Changes in v2:
> -Rebase on current (July 6th 2017) drm-next
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 ++
>  drivers/gpu/drm/i915/intel_uncore.c | 6 ++
>  drivers/gpu/drm/i915/intel_uncore.h | 1 +
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ee2325b180e7..ce31d9ed23dc 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2510,6 +2510,8 @@ static int intel_runtime_resume(struct device *kdev)
>   ret = vlv_resume_prepare(dev_priv, true);
>   }
>  
> + intel_uncore_runtime_resume(dev_priv);
> +
>   /*
>* No point of rolling back things in case of an error, as the best
>* we can do is to hope that things will still work (and disable RPM).
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 168b28a87f76..4a547cdfafa9 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct drm_i915_private 
> *dev_priv)
>   i915_check_and_clear_faults(dev_priv);
>  }
>  
> +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
> +{
> + iosf_mbi_register_pmic_bus_access_notifier(
> + _priv->uncore.pmic_bus_access_nb);
> +}
> +
>  void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
>  {
>   i915.enable_rc6 = sanitize_rc6_option(dev_priv, i915.enable_rc6);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
> b/drivers/gpu/drm/i915/intel_uncore.h
> index 5f90278da461..0bdc3fcc0e64 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -121,6 +121,7 @@ bool intel_uncore_arm_unclaimed_mmio_detection(struct 
> drm_i915_private *dev_priv
>  void intel_uncore_fini(struct drm_i915_private *dev_priv);
>  void intel_uncore_suspend(struct drm_i915_private *dev_priv);
>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
> +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
>  
>  u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
>  void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
> -- 
> 2.13.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

2017-07-27 Thread bugzilla-daemon

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

Jan Vesely  changed:

   What|Removed |Added

 Depends on||101952


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=101952
[Bug 101952] OpenCL enqueueReadBuffer returns trash
-- 
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 0/5] drm/atomic: Interruptible locks for everyone!

2017-07-27 Thread Daniel Vetter

On Thu, Jul 27, 2017 at 03:45:11PM +0100, Emil Velikov wrote:
> Hi Maarten
> 
> On 27 July 2017 at 13:58, Maarten Lankhorst
>  wrote:
> > drm_atomic_commit could previous have always failed when waits failed,
> > but locking was always done uninterruptibly. Add infrastructure to make
> > it possible for callers to choose interruptible locking, and convert the
> > 4 most common ioctl's to use it.
> >
> > All other atomic helpers can be converted when Daniel's "acquire_ctx
> > for everyone!" patch series lands.
> >
> There's a KMS locking documentation/example in drm_modeset_lock.c.
> Can you please update that as well?

Not sure what we should update there? As-is it still works for the
non-interruptible case. Or do you mean we should have an interruptible
variant of it too?

Anyway, with the testcase added also for cursor and plane code, patches
4&5 also get my Reviewed-by: Daniel Vetter 

Any reason you didn't convert the set_config path too? That's probably the
one most will be stuck in when something goes wrong ... Another one is the
various get* and setprop calls (but the later needs my patch series
first).
-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 3/5] drm/atomic: Convert pageflip ioctl locking to interruptible.

2017-07-27 Thread Daniel Vetter

On Thu, Jul 27, 2017 at 02:58:38PM +0200, Maarten Lankhorst wrote:
> Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
> drm_modeset_backoff which can now fail by returning the error.
> 
> Signed-off-by: Maarten Lankhorst 

Same comment as the atomic ioctl. With the testcase added this gets my

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_plane.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 5dc8c4350602..4997229d397b 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -866,7 +866,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   return -EINVAL;
>   }
>  
> - drm_modeset_acquire_init(, 0);
> + drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  retry:
>   ret = drm_modeset_lock(>mutex, );
>   if (ret)
> @@ -955,8 +955,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
>   crtc->primary->old_fb = NULL;
>  
>   if (ret == -EDEADLK) {
> - drm_modeset_backoff();
> - goto retry;
> + ret = drm_modeset_backoff();
> + if (!ret)
> + goto retry;
>   }
>  
>   drm_modeset_drop_locks();
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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: [Intel-gfx] [PATCH 2/5] drm/atomic: Convert atomic ioctl locking to interruptible.

2017-07-27 Thread Daniel Vetter

On Thu, Jul 27, 2017 at 02:58:37PM +0200, Maarten Lankhorst wrote:
> Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and
> handle drm_modeset_backoff which can now fail by returning the error.
> 
> Signed-off-by: Maarten Lankhorst 

Requires a testcase, with that addressed:

Reviewed-by: Daniel Vetter 

I think the test should be:

1. On thread stuck on a blocking plane update (using a vgem fence that
doesn't get signalled).

2. Second thread does a blocking plane update on that the same plane.

3. Gets interrupted by a signal, and we confirm that we receive that
signal before we've unblocked the first thread.

This would give us positive confirmation that interruptible actually
works.

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_atomic.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 01192dd3ed79..4a1ff90fd73e 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -2217,7 +2217,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>   (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
>   return -EINVAL;
>  
> - drm_modeset_acquire_init(, 0);
> + drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
>  
>   state = drm_atomic_state_alloc(dev);
>   if (!state)
> @@ -2327,8 +2327,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>  
>   if (ret == -EDEADLK) {
>   drm_atomic_state_clear(state);
> - drm_modeset_backoff();
> - goto retry;
> + ret = drm_modeset_backoff();
> + if (!ret)
> + goto retry;
>   }
>  
>   drm_atomic_state_put(state);
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Bug 101954] WARNING: suspicious RCU usage in amdgpu_bo_list_get

2017-07-27 Thread bugzilla-daemon

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

Bug ID: 101954
   Summary: WARNING: suspicious RCU usage in amdgpu_bo_list_get
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: yan...@declera.com

Fedora rawhide with debug config as 
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/kernel-x86_64-debug.config

01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Baffin [Radeon RX 460] (rev cf)
1 DP 4k monitor

This is something that seems to've started appearing after the rcu changes in
this merge window


[   12.958667] =
[   12.958678] WARNING: suspicious RCU usage
[   12.958691] 4.13.0-0.rc2.git1.1.fc27.x86_64 #1 Not tainted
[   12.958701] -
[   12.958714] ./include/linux/rcupdate.h:297 Illegal context switch in RCU
read-side critical section!
[   12.958724] 
   other info that might help us debug this:

[   12.958737] 
   rcu_scheduler_active = 2, debug_locks = 1
[   12.958749] 1 lock held by amdgpu_cs:0/1226:
[   12.958758]  #0:  (rcu_read_lock){..}, at: []
amdgpu_bo_list_get+0x5/0x130 [amdgpu]
[   12.958874] 
   stack backtrace:
[   12.958890] CPU: 3 PID: 1226 Comm: amdgpu_cs:0 Not tainted
4.13.0-0.rc2.git1.1.fc27.x86_64 #1
[   12.958901] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./990FXA-UD3 R5, BIOS F2 04/01/2015
[   12.958911] Call Trace:
[   12.958931]  dump_stack+0x8e/0xd6
[   12.958953]  lockdep_rcu_suspicious+0xc5/0x100
[   12.959033]  ? amdgpu_bo_list_get+0x81/0x130 [amdgpu]
[   12.959051]  ___might_sleep+0x1ad/0x250
[   12.959073]  __might_sleep+0x4a/0x80
[   12.959095]  __mutex_lock+0x59/0xa00
[   12.959110]  ? trace_hardirqs_on+0xd/0x10
[   12.959141]  ? lock_acquire+0xa3/0x1f0
[   12.959217]  ? amdgpu_bo_list_get+0x5/0x130 [amdgpu]
[   12.959243]  mutex_lock_nested+0x1b/0x20
[   12.959253]  ? mutex_lock_nested+0x1b/0x20
[   12.959321]  amdgpu_bo_list_get+0x81/0x130 [amdgpu]
[   12.959389]  amdgpu_cs_ioctl+0xcb/0x1c50 [amdgpu]
[   12.959413]  ? debug_check_no_obj_freed+0x15f/0x24a
[   12.959562]  ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu]
[   12.959607]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[   12.959657]  drm_ioctl+0x31b/0x3d0 [drm]
[   12.959726]  ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu]
[   12.959767]  ? trace_hardirqs_on_caller+0xf4/0x190
[   12.959787]  ? trace_hardirqs_on+0xd/0x10
[   12.959870]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[   12.959895]  do_vfs_ioctl+0xa6/0x6c0
[   12.959940]  SyS_ioctl+0x79/0x90
[   12.959968]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   12.959981] RIP: 0033:0x7fc88df4a267
[   12.959991] RSP: 002b:7fc86a0b98b8 EFLAGS: 0246 ORIG_RAX:
0010
[   12.960008] RAX: ffda RBX: 7fc85c00 RCX:
7fc88df4a267
[   12.960031] RDX: 7fc86a0b9a10 RSI: c0186444 RDI:
000c
[   12.960040] RBP: 00021000 R08: 7fc86a0b9900 R09:
7fc86a0b9950
[   12.960050] R10: 0002 R11: 0246 R12:
7fc86000
[   12.960061] R13: 02ef5000 R14:  R15:

[   12.960287] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:747
[   12.960301] in_atomic(): 1, irqs_disabled(): 0, pid: 1226, name: amdgpu_cs:0
[   12.960313] 1 lock held by amdgpu_cs:0/1226:
[   12.960323]  #0:  (rcu_read_lock){..}, at: []
amdgpu_bo_list_get+0x5/0x130 [amdgpu]
[   12.960422] CPU: 3 PID: 1226 Comm: amdgpu_cs:0 Not tainted
4.13.0-0.rc2.git1.1.fc27.x86_64 #1
[   12.960431] Hardware name: Gigabyte Technology Co., Ltd. To be filled by
O.E.M./990FXA-UD3 R5, BIOS F2 04/01/2015
[   12.960439] Call Trace:
[   12.960453]  dump_stack+0x8e/0xd6
[   12.960470]  ___might_sleep+0x164/0x250
[   12.960492]  __might_sleep+0x4a/0x80
[   12.960515]  __mutex_lock+0x59/0xa00
[   12.960530]  ? trace_hardirqs_on+0xd/0x10
[   12.960561]  ? lock_acquire+0xa3/0x1f0
[   12.960638]  ? amdgpu_bo_list_get+0x5/0x130 [amdgpu]
[   12.960673]  mutex_lock_nested+0x1b/0x20
[   12.960686]  ? mutex_lock_nested+0x1b/0x20
[   12.960758]  amdgpu_bo_list_get+0x81/0x130 [amdgpu]
[   12.960832]  amdgpu_cs_ioctl+0xcb/0x1c50 [amdgpu]
[   12.960861]  ? debug_check_no_obj_freed+0x15f/0x24a
[   12.961043]  ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu]
[   12.961083]  drm_ioctl_kernel+0x5d/0xb0 [drm]
[   12.961134]  drm_ioctl+0x31b/0x3d0 [drm]
[   12.961204]  ? amdgpu_cs_find_mapping+0xa0/0xa0 [amdgpu]
[   12.961241]  ? trace_hardirqs_on_caller+0xf4/0x190
[   12.961262]  ? trace_hardirqs_on+0xd/0x10
[   12.961346]  amdgpu_drm_ioctl+0x4f/0x90 [amdgpu]
[   12.961371]  do_vfs_ioctl+0xa6/0x6c0
[   12.961415]  SyS_ioctl+0x79/0x90
[   12.961443]  entry_SYSCALL_64_fastpath+0x1f/0xbe
[   12.961455] RIP:

Re: [PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

2017-07-27 Thread Daniel Vetter

On Thu, Jul 27, 2017 at 02:58:36PM +0200, Maarten Lankhorst wrote:
> When we want to make drm_atomic_commit interruptible, there are a lot of
> places that call the lock function, which we don't have control over.
> 
> Rather than trying to convert every single one, it's easier to toggle
> interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
> called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
> interruptible waits in drm_modeset_lock and drm_modeset_backoff.
> 
> Signed-off-by: Maarten Lankhorst 

I wonder whether we should do a drm_modeset_lock_single without the
context attribute too, for OCD. But not really needed.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_debugfs_crc.c  |  2 +-
>  drivers/gpu/drm/drm_modeset_lock.c | 75 
> ++
>  include/drm/drm_modeset_lock.h | 12 --
>  3 files changed, 44 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
> b/drivers/gpu/drm/drm_debugfs_crc.c
> index f9e26dda56d6..9dd879589a2c 100644
> --- a/drivers/gpu/drm/drm_debugfs_crc.c
> +++ b/drivers/gpu/drm/drm_debugfs_crc.c
> @@ -155,7 +155,7 @@ static int crtc_crc_open(struct inode *inode, struct file 
> *filep)
>   int ret = 0;
>  
>   if (drm_drv_uses_atomic_modeset(crtc->dev)) {
> - ret = drm_modeset_lock_interruptible(>mutex, NULL);
> + ret = drm_modeset_lock_single_interruptible(>mutex);
>   if (ret)
>   return ret;
>  
> diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
> b/drivers/gpu/drm/drm_modeset_lock.c
> index af4e906c630d..5db47e04e68e 100644
> --- a/drivers/gpu/drm/drm_modeset_lock.c
> +++ b/drivers/gpu/drm/drm_modeset_lock.c
> @@ -178,7 +178,11 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
>  /**
>   * drm_modeset_acquire_init - initialize acquire context
>   * @ctx: the acquire context
> - * @flags: for future
> + * @flags: 0 or %DRM_MODESET_ACQUIRE_INTERRUPTIBLE
> + *
> + * When passing %DRM_MODESET_ACQUIRE_INTERRUPTIBLE to @flags,
> + * all calls to drm_modeset_lock() will perform an interruptible
> + * wait.
>   */
>  void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
>   uint32_t flags)
> @@ -186,6 +190,9 @@ void drm_modeset_acquire_init(struct 
> drm_modeset_acquire_ctx *ctx,
>   memset(ctx, 0, sizeof(*ctx));
>   ww_acquire_init(>ww_ctx, _ww_class);
>   INIT_LIST_HEAD(>locked);
> +
> + if (flags & DRM_MODESET_ACQUIRE_INTERRUPTIBLE)
> + ctx->interruptible = true;
>  }
>  EXPORT_SYMBOL(drm_modeset_acquire_init);
>  
> @@ -261,8 +268,19 @@ static inline int modeset_lock(struct drm_modeset_lock 
> *lock,
>   return ret;
>  }
>  
> -static int modeset_backoff(struct drm_modeset_acquire_ctx *ctx,
> - bool interruptible)
> +/**
> + * drm_modeset_backoff - deadlock avoidance backoff
> + * @ctx: the acquire context
> + *
> + * If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
> + * you must call this function to drop all currently held locks and
> + * block until the contended lock becomes available.
> + *
> + * This function returns 0 on success, or -ERESTARTSYS if this context
> + * is initialized with %DRM_MODESET_ACQUIRE_INTERRUPTIBLE and the
> + * wait has been interrupted.
> + */
> +int drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx)
>  {
>   struct drm_modeset_lock *contended = ctx->contended;
>  
> @@ -273,36 +291,11 @@ static int modeset_backoff(struct 
> drm_modeset_acquire_ctx *ctx,
>  
>   drm_modeset_drop_locks(ctx);
>  
> - return modeset_lock(contended, ctx, interruptible, true);
> -}
> -
> -/**
> - * drm_modeset_backoff - deadlock avoidance backoff
> - * @ctx: the acquire context
> - *
> - * If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
> - * you must call this function to drop all currently held locks and
> - * block until the contended lock becomes available.
> - */
> -void drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx)
> -{
> - modeset_backoff(ctx, false);
> + return modeset_lock(contended, ctx, ctx->interruptible, true);
>  }
>  EXPORT_SYMBOL(drm_modeset_backoff);
>  
>  /**
> - * drm_modeset_backoff_interruptible - deadlock avoidance backoff
> - * @ctx: the acquire context
> - *
> - * Interruptible version of drm_modeset_backoff()
> - */
> -int drm_modeset_backoff_interruptible(struct drm_modeset_acquire_ctx *ctx)
> -{
> - return modeset_backoff(ctx, true);
> -}
> -EXPORT_SYMBOL(drm_modeset_backoff_interruptible);
> -
> -/**
>   * drm_modeset_lock_init - initialize lock
>   * @lock: lock to init
>   */
> @@ -324,14 +317,18 @@ EXPORT_SYMBOL(drm_modeset_lock_init);
>   * deadlock scenario has been detected and it is an error to attempt
>   * to take any more locks without first calling drm_modeset_backoff().
>   *
> + * If the @ctx is not NULL and initialized with
> + *

[Bug 101672] radeonsi: 3D engines causing frequent GPU lockups

2017-07-27 Thread bugzilla-daemon

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

--- Comment #18 from MirceaKitsune  ---
I used 'dmesg -w' via SSH to monitor dmesg output as the system froze. I have
not seen anything of interest, and no new messages were printed before the
crash took place. The only arguably suspicious line was:

[ 1286.800069] perf: interrupt took too long (2502 > 2500), lowering
kernel.perf_event_max_sample_rate to 79750

Never the less, I have discovered another important factor during my tests: I
decided to look through my BIOS settings again, as I remembered I had left
enabled a memory overclock setting called Performance Enhance. In the past when
I had a different set of memories, this option caused the exact same freeze
when I was watching Youtube (1080p @ 60fps videos). Later on I got new
memories, and due to how my clocks are synced I'm running those at an
underclocked (therefore more stable) frequency, so I figured I can leave this
enabled without problems. The highly erratic probabilities of the freezes threw
me off (once it's after 10 minutes, then it's after 2 hours), whereas a crash
this obvious would have been all over the bug tracker by now if it was Mesa.

After disabling it, I no longer seem to get any immediate system freezes. It
will however require more testing to confirm it was that option, so please give
me a few more weeks before we close this. If my theory is proven wrong, I'll
immediately post a new comment and let everyone know.

-- 
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 0/5] drm/atomic: Interruptible locks for everyone!

2017-07-27 Thread Emil Velikov

Hi Maarten

On 27 July 2017 at 13:58, Maarten Lankhorst
 wrote:
> drm_atomic_commit could previous have always failed when waits failed,
> but locking was always done uninterruptibly. Add infrastructure to make
> it possible for callers to choose interruptible locking, and convert the
> 4 most common ioctl's to use it.
>
> All other atomic helpers can be converted when Daniel's "acquire_ctx
> for everyone!" patch series lands.
>
There's a KMS locking documentation/example in drm_modeset_lock.c.
Can you please update that as well?

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

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

--- Comment #5 from Alex Deucher  ---
Created attachment 133075
  --> https://bugs.freedesktop.org/attachment.cgi?id=133075=edit
possible fix 2/2

-- 
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 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

--- Comment #4 from Alex Deucher  ---
Created attachment 133074
  --> https://bugs.freedesktop.org/attachment.cgi?id=133074=edit
possible fix 1/2

Do the attached patches help (based on my drm-next-4.14-wip branch)?

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

Re: [PATCH v2 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

2017-07-27 Thread Imre Deak

Hi,

On Thu, Jul 06, 2017 at 09:24:47PM +0200, Hans de Goede wrote:
> assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
> even though it gets unregistered on (runtime) suspend, this is caused
> by a race happening under the following circumstances:
> 
> intel_runtime_pm_put does:
> 
>atomic_dec(_priv->pm.wakeref_count);
> 
>pm_runtime_mark_last_busy(kdev);
>pm_runtime_put_autosuspend(kdev);
> 
> And pm_runtime_put_autosuspend calls intel_runtime_suspend from
> a workqueue, so there is ample of time between the atomic_dec() and
> intel_runtime_suspend() unregistering the notifier. If the notifier
> gets called in this windowd assert_rpm_wakelock_held falsely triggers
> (at this point we're not runtime-suspended yet).
> 
> This commit adds disable_rpm_wakeref_asserts and
> enable_rpm_wakeref_asserts calls around the
> intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
> i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
> 
> Reported-by: FKr 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Rebase on current (July 6th 2017) drm-next
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 9882724bc2b6..168b28a87f76 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier(struct 
> notifier_block *nb,
>* bus, which will be busy after this notification, leading to:
>* "render: timed out waiting for forcewake ack request."
>* errors.
> +  *
> +  * This notifier may get called between intel_runtime_pm_put()
> +  * doing atomic_dec(wakeref_count) and intel_runtime_resume()
> +  * unregistering this notifier, which leads to false-positive
> +  * assert_rpm_wakelock_held() triggering.

the following would describe better the reason for disabling wakeref asserts.
That is we access the HW without holding a runtime PM reference, but it's ok
here since it's handled as a special case during runtime suspend:

* The notifier is unregistered during intel_runtime_suspend(),
* so it's ok to access the HW here without holding an RPM
* wake reference -> disable wakeref asserts for the time of
* the access.

With that this looks ok:
Reviewed-by: Imre Deak 


>*/
> + disable_rpm_wakeref_asserts(dev_priv);
>   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
> + enable_rpm_wakeref_asserts(dev_priv);
>   break;
>   case MBI_PMIC_BUS_ACCESS_END:
>   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> -- 
> 2.13.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/5] drm/legacy: Convert setplane ioctl locking to interruptible.

2017-07-27 Thread Maarten Lankhorst

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 63ced2e69386..7aef8611ce9d 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -549,7 +549,7 @@ static int setplane_internal(struct drm_plane *plane,
struct drm_modeset_acquire_ctx ctx;
int ret;
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock_all_ctx(plane->dev, );
if (ret)
@@ -560,8 +560,9 @@ static int setplane_internal(struct drm_plane *plane,
 
 fail:
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
-- 
2.11.0

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

[PATCH 0/5] drm/atomic: Interruptible locks for everyone!

2017-07-27 Thread Maarten Lankhorst

drm_atomic_commit could previous have always failed when waits failed,
but locking was always done uninterruptibly. Add infrastructure to make
it possible for callers to choose interruptible locking, and convert the
4 most common ioctl's to use it.

All other atomic helpers can be converted when Daniel's "acquire_ctx
for everyone!" patch series lands.

Maarten Lankhorst (5):
  drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible
waiting
  drm/atomic: Convert atomic ioctl locking to interruptible.
  drm/atomic: Convert pageflip ioctl locking to interruptible.
  drm/legacy: Convert cursor ioctl locking to interruptible.
  drm/legacy: Convert setplane ioctl locking to interruptible.

 drivers/gpu/drm/drm_atomic.c   |  7 ++--
 drivers/gpu/drm/drm_debugfs_crc.c  |  2 +-
 drivers/gpu/drm/drm_modeset_lock.c | 75 ++
 drivers/gpu/drm/drm_plane.c| 21 ++-
 include/drm/drm_modeset_lock.h | 12 --
 5 files changed, 60 insertions(+), 57 deletions(-)

-- 
2.11.0

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

[PATCH 2/5] drm/atomic: Convert atomic ioctl locking to interruptible.

2017-07-27 Thread Maarten Lankhorst

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and
handle drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 01192dd3ed79..4a1ff90fd73e 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -2217,7 +2217,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
(arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
return -EINVAL;
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 
state = drm_atomic_state_alloc(dev);
if (!state)
@@ -2327,8 +2327,9 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
 
if (ret == -EDEADLK) {
drm_atomic_state_clear(state);
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_atomic_state_put(state);
-- 
2.11.0

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

[PATCH 1/5] drm/atomic: Prepare drm_modeset_lock infrastructure for interruptible waiting

2017-07-27 Thread Maarten Lankhorst

When we want to make drm_atomic_commit interruptible, there are a lot of
places that call the lock function, which we don't have control over.

Rather than trying to convert every single one, it's easier to toggle
interruptible waiting per acquire_ctx. If drm_modeset_acquire_init is
called with DRM_MODESET_ACQUIRE_INTERRUPTIBLE, then we will perform
interruptible waits in drm_modeset_lock and drm_modeset_backoff.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_debugfs_crc.c  |  2 +-
 drivers/gpu/drm/drm_modeset_lock.c | 75 ++
 include/drm/drm_modeset_lock.h | 12 --
 3 files changed, 44 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index f9e26dda56d6..9dd879589a2c 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -155,7 +155,7 @@ static int crtc_crc_open(struct inode *inode, struct file 
*filep)
int ret = 0;
 
if (drm_drv_uses_atomic_modeset(crtc->dev)) {
-   ret = drm_modeset_lock_interruptible(>mutex, NULL);
+   ret = drm_modeset_lock_single_interruptible(>mutex);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index af4e906c630d..5db47e04e68e 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -178,7 +178,11 @@ EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
 /**
  * drm_modeset_acquire_init - initialize acquire context
  * @ctx: the acquire context
- * @flags: for future
+ * @flags: 0 or %DRM_MODESET_ACQUIRE_INTERRUPTIBLE
+ *
+ * When passing %DRM_MODESET_ACQUIRE_INTERRUPTIBLE to @flags,
+ * all calls to drm_modeset_lock() will perform an interruptible
+ * wait.
  */
 void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags)
@@ -186,6 +190,9 @@ void drm_modeset_acquire_init(struct 
drm_modeset_acquire_ctx *ctx,
memset(ctx, 0, sizeof(*ctx));
ww_acquire_init(>ww_ctx, _ww_class);
INIT_LIST_HEAD(>locked);
+
+   if (flags & DRM_MODESET_ACQUIRE_INTERRUPTIBLE)
+   ctx->interruptible = true;
 }
 EXPORT_SYMBOL(drm_modeset_acquire_init);
 
@@ -261,8 +268,19 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,
return ret;
 }
 
-static int modeset_backoff(struct drm_modeset_acquire_ctx *ctx,
-   bool interruptible)
+/**
+ * drm_modeset_backoff - deadlock avoidance backoff
+ * @ctx: the acquire context
+ *
+ * If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
+ * you must call this function to drop all currently held locks and
+ * block until the contended lock becomes available.
+ *
+ * This function returns 0 on success, or -ERESTARTSYS if this context
+ * is initialized with %DRM_MODESET_ACQUIRE_INTERRUPTIBLE and the
+ * wait has been interrupted.
+ */
+int drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx)
 {
struct drm_modeset_lock *contended = ctx->contended;
 
@@ -273,36 +291,11 @@ static int modeset_backoff(struct drm_modeset_acquire_ctx 
*ctx,
 
drm_modeset_drop_locks(ctx);
 
-   return modeset_lock(contended, ctx, interruptible, true);
-}
-
-/**
- * drm_modeset_backoff - deadlock avoidance backoff
- * @ctx: the acquire context
- *
- * If deadlock is detected (ie. drm_modeset_lock() returns -EDEADLK),
- * you must call this function to drop all currently held locks and
- * block until the contended lock becomes available.
- */
-void drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx)
-{
-   modeset_backoff(ctx, false);
+   return modeset_lock(contended, ctx, ctx->interruptible, true);
 }
 EXPORT_SYMBOL(drm_modeset_backoff);
 
 /**
- * drm_modeset_backoff_interruptible - deadlock avoidance backoff
- * @ctx: the acquire context
- *
- * Interruptible version of drm_modeset_backoff()
- */
-int drm_modeset_backoff_interruptible(struct drm_modeset_acquire_ctx *ctx)
-{
-   return modeset_backoff(ctx, true);
-}
-EXPORT_SYMBOL(drm_modeset_backoff_interruptible);
-
-/**
  * drm_modeset_lock_init - initialize lock
  * @lock: lock to init
  */
@@ -324,14 +317,18 @@ EXPORT_SYMBOL(drm_modeset_lock_init);
  * deadlock scenario has been detected and it is an error to attempt
  * to take any more locks without first calling drm_modeset_backoff().
  *
+ * If the @ctx is not NULL and initialized with
+ * %DRM_MODESET_ACQUIRE_INTERRUPTIBLE, this function will behave
+ * as drm_modeset_lock_interruptible().
+ *
  * If @ctx is NULL then the function call behaves like a normal,
- * non-nesting mutex_lock() call.
+ * uninterruptible non-nesting mutex_lock() call.
  */
 int drm_modeset_lock(struct drm_modeset_lock *lock,
struct drm_modeset_acquire_ctx *ctx)
 {
if (ctx)
-   return modeset_lock(lock, ctx, false, false);
+   return

[PATCH 3/5] drm/atomic: Convert pageflip ioctl locking to interruptible.

2017-07-27 Thread Maarten Lankhorst

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..4997229d397b 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -866,7 +866,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -EINVAL;
}
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock(>mutex, );
if (ret)
@@ -955,8 +955,9 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
crtc->primary->old_fb = NULL;
 
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_modeset_drop_locks();
-- 
2.11.0

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

[PATCH 4/5] drm/legacy: Convert cursor ioctl locking to interruptible.

2017-07-27 Thread Maarten Lankhorst

Pass DRM_MODESET_ACQUIRE_INTERRUPTIBLE to acquire_init, and handle
drm_modeset_backoff which can now fail by returning the error.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_plane.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 4997229d397b..63ced2e69386 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -715,7 +715,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
return -ENOENT;
}
 
-   drm_modeset_acquire_init(, 0);
+   drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
 retry:
ret = drm_modeset_lock(>mutex, );
if (ret)
@@ -757,8 +757,9 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
 out:
if (ret == -EDEADLK) {
-   drm_modeset_backoff();
-   goto retry;
+   ret = drm_modeset_backoff();
+   if (!ret)
+   goto retry;
}
 
drm_modeset_drop_locks();
-- 
2.11.0

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

Re: [PATCH] drm/bridge: tc358767: fix probe without attached output node

2017-07-27 Thread Andrey Gusakov

Hi,

On Mon, Jul 10, 2017 at 3:41 PM, Lucas Stach  wrote:

> The output node of the TC358767 is only used if another bridge is chained
> behind it. Panels attached to the TC358767 can be detected using the usual
> DP AUX probing. This restores the old behavior of ignoring the output if
> no endpoint is found.
>
> Fixes: ebc944613567 (drm: convert drivers to use
> drm_of_find_panel_or_bridge)
> CC: sta...@vger.kernel.org
> Signed-off-by: Lucas Stach 
>

Acked-by: Andrey Gusakov 

---
>  drivers/gpu/drm/bridge/tc358767.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index 5c26488e7a2d..0529e500c534 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -1255,7 +1255,7 @@ static int tc_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
>
> /* port@2 is the output port */
> ret = drm_of_find_panel_or_bridge(dev->of_node, 2, 0, >panel,
> NULL);
> -   if (ret)
> +   if (ret && ret != -ENODEV)
> return ret;
>
> /* Shut down GPIO is optional */
> --
> 2.11.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

[PATCH 0/6] drm/bridge: tc358767: fixes and improvements

2017-07-27 Thread Andrey Gusakov

This set of patches fixes several issues that was found during testing
tc358767 with desktop DisplayPort displays.

Andrey Gusakov (6):
  drm/bridge: tc358767: do no fail on hi-res displays
  drm/bridge: tc358767: filter out too high modes
  drm/bridge: tc358767: fix DP0_MISC register set
  drm/bridge: tc358767: fix timing calculations
  drm/bridge: tc358767: fix AUXDATAn registers access
  drm/bridge: tc358767: fix 1-lane behavior

 drivers/gpu/drm/bridge/tc358767.c | 73 +--
 1 file changed, 40 insertions(+), 33 deletions(-)

-- 
2.13.0

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

[PATCH 2/6] drm/bridge: tc358767: filter out too high modes

2017-07-27 Thread Andrey Gusakov

Minimum pixel clock period is 6.5 nS for DPI. Do not accept  modes
with lower pixel clock period.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index f605bb7d1aa3..e8008e0c2e88 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct drm_bridge 
*bridge,
 static int tc_connector_mode_valid(struct drm_connector *connector,
   struct drm_display_mode *mode)
 {
-   /* Accept any mode */
+   /* PCLK limitation = 6.5 nS */
+   if (mode->clock > 163000)
+   return MODE_CLOCK_HIGH;
+
return MODE_OK;
 }
 
-- 
2.13.0

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

[PATCH 3/6] drm/bridge: tc358767: fix DP0_MISC register set

2017-07-27 Thread Andrey Gusakov

Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index e8008e0c2e88..4aee6178d889 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -97,7 +97,7 @@
 #define DP0_ACTIVEVAL  0x0650
 #define DP0_SYNCVAL0x0654
 #define DP0_MISC   0x0658
-#define TU_SIZE_RECOMMENDED(0x3f << 16) /* LSCLK cycles per TU */
+#define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */
 #define BPC_6  (0 << 5)
 #define BPC_8  (1 << 5)
 
@@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
 * Must be less than tu_size.
 */
max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
-   tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8);
+   tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
+  BPC_8);
 
return 0;
 err:
-- 
2.13.0

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

[PATCH 6/6] drm/bridge: tc358767: fix 1-lane behavior

2017-07-27 Thread Andrey Gusakov

Use drm_dp_channel_eq_ok helper

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 84b0b0fff854..24abffae6edb 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_data *tc)
unsigned int rate;
u32 dp_phy_ctrl;
int timeout;
-   bool aligned;
-   bool ready;
u32 value;
int ret;
u8 tmp[8];
@@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_data *tc)
ret = drm_dp_dpcd_read_link_status(aux, tmp + 2);
if (ret < 0)
goto err_dpcd_read;
-   ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */
-DP_CHANNEL_EQ_BITS));  /* Lane0 */
-   aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE;
-   } while ((--timeout) && !(ready && aligned));
+   } while ((--timeout) &&
+!(drm_dp_channel_eq_ok(tmp + 2,  tc->link.base.num_lanes)));
 
if (timeout == 0) {
/* Read DPCD 0x200-0x201 */
ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2);
if (ret < 0)
goto err_dpcd_read;
+   dev_err(dev, "channel(s) EQ not ok\n");
dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]);
dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n",
 tmp[1]);
@@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_data *tc)
dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n",
 tmp[6]);
 
-   if (!ready)
-   dev_err(dev, "Lane0/1 not ready\n");
-   if (!aligned)
-   dev_err(dev, "Lane0/1 not aligned\n");
return -EAGAIN;
}
 
-- 
2.13.0

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

[PATCH 4/6] drm/bridge: tc358767: fix timing calculations

2017-07-27 Thread Andrey Gusakov

Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 4aee6178d889..c657a00af508 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
 
+   /*
+* Recommended maximum number of symbols transferred in a transfer unit:
+* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+*  (output active video bandwidth in bytes))
+* Must be less than tu_size.
+*/
+   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
+
dev_dbg(tc->dev, "set mode %dx%d\n",
mode->hdisplay, mode->vdisplay);
dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
@@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
 
 
-   /* LCD Ctl Frame Size */
-   tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
+   /*
+* LCD Ctl Frame Size
+* datasheet is not clear of vsdelay in case of DPI
+* assume we do not need any delay when DPI is a source of
+* sync signals
+*/
+   tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
 OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
-   tc_write(HTIM01, (left_margin << 16) |  /* H back porch */
-(hsync_len << 0)); /* Hsync */
-   tc_write(HTIM02, (right_margin << 16) | /* H front porch */
-(mode->hdisplay << 0));/* width */
+   tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
+(ALIGN(hsync_len, 2) << 0));/* Hsync */
+   tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
+(ALIGN(mode->hdisplay, 2) << 0)); /* width */
tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
 (vsync_len << 0)); /* Vsync */
tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
@@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
tc_write(DP0_VIDSYNCDELAY,
-(0x003e << 16) |   /* thresh_dly */
+(max_tu_symbol << 16) |/* thresh_dly */
 (vid_sync_dly << 0));
 
tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal));
@@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW |
 DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888);
 
-   /*
-* Recommended maximum number of symbols transferred in a transfer unit:
-* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
-*  (output active video bandwidth in bytes))
-* Must be less than tu_size.
-*/
-   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
   BPC_8);
 
-- 
2.13.0

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

[PATCH 5/6] drm/bridge: tc358767: fix AUXDATAn registers access

2017-07-27 Thread Andrey Gusakov

First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index c657a00af508..84b0b0fff854 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
tmp = (tmp << 8) | buf[i];
i++;
if (((i % 4) == 0) || (i == size)) {
-   tc_write(DP0_AUXWDATA(i >> 2), tmp);
+   tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
tmp = 0;
}
}
-- 
2.13.0

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

[PATCH 1/6] drm/bridge: tc358767: do no fail on hi-res displays

2017-07-27 Thread Andrey Gusakov

Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 5c26488e7a2d..f605bb7d1aa3 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -603,8 +603,15 @@ static int tc_get_display_props(struct tc_data *tc)
ret = drm_dp_link_probe(>aux, >link.base);
if (ret < 0)
goto err_dpcd_read;
-   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27))
-   goto err_dpcd_inval;
+   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27)) {
+   dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
+   tc->link.base.rate = 27;
+   }
+
+   if (tc->link.base.num_lanes > 2) {
+   dev_dbg(tc->dev, "Falling to 2 lanes\n");
+   tc->link.base.num_lanes = 2;
+   }
 
ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, tmp);
if (ret < 0)
@@ -637,9 +644,6 @@ static int tc_get_display_props(struct tc_data *tc)
 err_dpcd_read:
dev_err(tc->dev, "failed to read DPCD: %d\n", ret);
return ret;
-err_dpcd_inval:
-   dev_err(tc->dev, "invalid DPCD\n");
-   return -EINVAL;
 }
 
 static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode)
-- 
2.13.0

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

Re: [PATCH 18/41] drm/tilcdc: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-27 Thread Jyri Sarha

On 07/23/17 22:16, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 
> Signed-off-by: Noralf Trønnes 

Acked-by: Jyri Sarha 

Thanks!

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index 049d2f5..b0d70f9 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -542,8 +542,6 @@ static struct drm_driver tilcdc_driver = {
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
>   .gem_vm_ops = _gem_cma_vm_ops,
>   .dumb_create= drm_gem_cma_dumb_create,
> - .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> - .dumb_destroy   = drm_gem_dumb_destroy,
>  
>   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
>   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> 

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

Re: [PATCH 1/2] ASoC: hdmi-codec: Allow drivers to restrict sample sizes.

2017-07-27 Thread Srinivas Kandagatla




On 27/07/17 11:34, Jyri Sarha wrote:

On 07/17/17 17:02, srinivas.kandaga...@linaro.org wrote:

From: Srinivas Kandagatla 

Currently hdmi client drivers does have means to limit the
sample sizes that it can only support. Having formats parameter
option would solve this.

This issue was noticed on DB410c board when adv7511 hdmi codec driver
failed to play a 32 bits audio samples, as it does not support them.

Signed-off-by: Srinivas Kandagatla 


I left this feature out because I did not need it. All the HDMI encoders
I have used are able to take all the i2s formats I am able to send.

You should probably also update the comment above I2S_FORMATS
definition. Othewise:

Make sense, I will update it and send a v2 patch.




Reviewed-by: Jyri Sarha 


thanks
--srini




---
  include/sound/hdmi-codec.h| 1 +
  sound/soc/codecs/hdmi-codec.c | 3 +++
  2 files changed, 4 insertions(+)

diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
index 9483c55f871b..89fc4cce5785 100644
--- a/include/sound/hdmi-codec.h
+++ b/include/sound/hdmi-codec.h
@@ -104,6 +104,7 @@ struct hdmi_codec_pdata {
uint i2s:1;
uint spdif:1;
int max_i2s_channels;
+   u64 formats;
void *data;
  };
  
diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c

index 22ed0dc88f0a..1ece73f4be92 100644
--- a/sound/soc/codecs/hdmi-codec.c
+++ b/sound/soc/codecs/hdmi-codec.c
@@ -780,6 +780,9 @@ static int hdmi_codec_probe(struct platform_device *pdev)
hcp->daidrv[i] = hdmi_i2s_dai;
hcp->daidrv[i].playback.channels_max =
hcd->max_i2s_channels;
+
+   if (hcd->formats)
+   hcp->daidrv[i].playback.formats = hcd->formats;
i++;
}
  




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

[Bug 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

--- Comment #3 from Robin  ---
What I noticed from the kern.log is that it seems to try and skip init steps
the second time amdgpu loads. So perhaps the unbind doesn't do a clean enough
shutdown or there may be a bug in the init step skipping.

For example, the first time:
> [  129.439652] amdgpu :01:00.0: enabling device ( -> 0003)
> ...
> [  129.918128] [drm] GPU posting now...

The second time:
No mention of enabling device.
> [  159.722828] [drm] GPU post is not needed

-- 
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 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

Robin  changed:

   What|Removed |Added

 CC||bea...@oscp.info
Version|XOrg git|unspecified

-- 
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 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

--- Comment #2 from Robin  ---
Created attachment 133070
  --> https://bugs.freedesktop.org/attachment.cgi?id=133070=edit
kern.log

-- 
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 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

--- Comment #1 from Robin  ---
Created attachment 133069
  --> https://bugs.freedesktop.org/attachment.cgi?id=133069=edit
Script output

-- 
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 101946] Rebinding AMDGPU causes initialization errors [R9 290 / 4.10 kernel]

2017-07-27 Thread bugzilla-daemon

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

Bug ID: 101946
   Summary: Rebinding AMDGPU causes initialization errors [R9 290
/ 4.10 kernel]
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: bea...@oscp.info

Created attachment 133068
  --> https://bugs.freedesktop.org/attachment.cgi?id=133068=edit
The script used to reproduce the error.

As I attempted to hotplug my R9 290 for a VM gaming setup, I stumbled on this
issue.

The main kern.log error to come up is:

> [  160.013733] [drm:ci_dpm_enable [amdgpu]] *ERROR* ci_start_dpm failed
> [  160.014134] [drm:amdgpu_device_init [amdgpu]] *ERROR* hw_init of IP block 
>  failed -22
> [  160.014531] amdgpu :01:00.0: amdgpu_init failed


For my setup I use a Kaby Lake iGPU running i915.
With the R9 290 using vfio-pci / amdgpu.
Ubuntu 17.04 (4.10.0-28-generic).
Mesa 17.1.4 from the padoka stable PPA.


I'm able to reproduce this as follows.

1. Boot with vfio-pci capturing the card and amdgpu blacklisted. Kernel flags:
> intel_iommu=on iommu=pt vfio-pci.ids=1002:67b1,1002:aac8

2. Since I run Gnome3 on Ubuntu 17.04, this will bring me to a wayland greeter
which uses my iGPU. Drop to a free TTY, without logging in. This prevents Xorg
from responding to the AMD card becoming available.

3. Run the attached script "rebind-amd.sh" as root to bind back and forth
between vfio-pci and amdgpu in an infinite loop.

This will:

A. modprobe both drivers to be sure they're loaded.
B. Print information about the driver and card usage.
C. Use the new_id > unbind > bind > remove_id sequence to switch drivers.

What happens is:

vfio-pci -> vfio-pci, Gives no problems, of course.
vfio-pci -> amdgpu, This works and the amdgpu driver initializes the card.
Attached monitor(s) start searching for signals.
amdgpu -> vfio-pci, Since no Xorg is using the dGPU this works without
problems.
vfio-pci -> amdgpu, Fails to initialize dGPU with the kernel error above.


I've attached the script, the output of the script and the full kern.log.

-- 
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] dim: Continue also for dry runs

2017-07-27 Thread Daniel Vetter

It's a bit silly to have to spec both -d and -f to see what dim would
all complain about. And dry-run should never cause bad side-effects.

Signed-off-by: Daniel Vetter 
---
 dim | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/dim b/dim
index c0cbe352b165..96aaf7101d6b 100755
--- a/dim
+++ b/dim
@@ -126,6 +126,8 @@ function warn_or_fail
 {
if [[ $FORCE ]] ; then
echoerr "WARNING: $1, but continuing"
+   elif [[ $DRY ]] ; then
+   echoerr "WARNING: $1, but continuing dry-run"
else
echoerr "ERROR: $1, aborting"
exit 1
-- 
2.13.3

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

Re: [PATCH 1/2] ASoC: hdmi-codec: Allow drivers to restrict sample sizes.

2017-07-27 Thread Jyri Sarha

On 07/17/17 17:02, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla 
> 
> Currently hdmi client drivers does have means to limit the
> sample sizes that it can only support. Having formats parameter
> option would solve this.
> 
> This issue was noticed on DB410c board when adv7511 hdmi codec driver
> failed to play a 32 bits audio samples, as it does not support them.
> 
> Signed-off-by: Srinivas Kandagatla 

I left this feature out because I did not need it. All the HDMI encoders
I have used are able to take all the i2s formats I am able to send.

You should probably also update the comment above I2S_FORMATS
definition. Othewise:

Reviewed-by: Jyri Sarha 


> ---
>  include/sound/hdmi-codec.h| 1 +
>  sound/soc/codecs/hdmi-codec.c | 3 +++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/include/sound/hdmi-codec.h b/include/sound/hdmi-codec.h
> index 9483c55f871b..89fc4cce5785 100644
> --- a/include/sound/hdmi-codec.h
> +++ b/include/sound/hdmi-codec.h
> @@ -104,6 +104,7 @@ struct hdmi_codec_pdata {
>   uint i2s:1;
>   uint spdif:1;
>   int max_i2s_channels;
> + u64 formats;
>   void *data;
>  };
>  
> diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c
> index 22ed0dc88f0a..1ece73f4be92 100644
> --- a/sound/soc/codecs/hdmi-codec.c
> +++ b/sound/soc/codecs/hdmi-codec.c
> @@ -780,6 +780,9 @@ static int hdmi_codec_probe(struct platform_device *pdev)
>   hcp->daidrv[i] = hdmi_i2s_dai;
>   hcp->daidrv[i].playback.channels_max =
>   hcd->max_i2s_channels;
> +
> + if (hcd->formats)
> + hcp->daidrv[i].playback.formats = hcd->formats;
>   i++;
>   }
>  
> 

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

Re: [PATCH v2 09/12] drm/tilcdc: Handle drm_atomic_helper_swap_state failure

2017-07-27 Thread Maarten Lankhorst

Op 27-07-17 om 09:49 schreef Jyri Sarha:
> On 07/11/17 17:33, Maarten Lankhorst wrote:
>> drm_atomic_helper_swap_state() will be changed to interruptible waiting
>> in the next few commits, so all drivers have to be changed to handling
>> failure.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Jyri Sarha 
>> Cc: Tomi Valkeinen 
> This has probably been applied already, but here is my
>
> Acked-by: Jyri Sarha 
>
> just in case it is not.
Yeah it has been applied. :)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

2017-07-27 Thread Heiko Stübner

Am Donnerstag, 27. Juli 2017, 11:51:06 CEST schrieb Heiko Stübner:
> Hi Mark,
> 
> Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao:
> > Grouping the vop registers facilitates make register
> > definition clearer, and also is useful for different vop
> > reuse the same group register.
> > 
> > Signed-off-by: Mark Yao 
> > ---
> > 
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99
> >  
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
> >  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112
> > 
> > +++- 3 files changed, 144 insertions(+), 127
> > deletions(-)
> 
> This breaks display support on both rk3036 and rk3288 and I end up
> with a null pointer dereference in
> 
> [   10.640297] Unable to handle kernel NULL pointer dereference at virtual
> address  [   10.654430] pgd = c0204000
> [   10.657452] [] *pgd=
> [   10.661473] Internal error: Oops: 5 [#1] SMP ARM
> [   10.35] Modules linked in: snd_pcm media snd_timer phy_rockchip_dp
> snd soundcore rockchipdrm dw_hdmi analogix_dp rtc_rk808 pwm_rockchip
> clk_rk808 spi_rockchip [   10.682897] CPU: 2 PID: 143 Comm: kworker/2:2 Not
> tainted 4.13.0-rc2-01791-g2b86603d0515 #355 [   10.692430] Hardware name:
> Rockchip (Device Tree)
> [   10.697692] Workqueue: events deferred_probe_work_func
> [   10.702152] Linux video capture interface: v2.00
> [   10.708590] task: ee38c800 task.stack: ed2e6000
> [   10.713656] PC is at vop_reg_set.constprop.4+0x4/0xa8 [rockchipdrm]
> [   10.720668] LR is at vop_bind+0x568/0x8a0 [rockchipdrm]

The obvious reason for that is

> @@ -164,14 +153,20 @@ static inline uint32_t vop_read_reg(struct vop *vop,
> uint32_t base, return (vop_readl(vop, base + reg->offset) >> reg->shift) &
> reg->mask; }
> 
> -static inline void vop_mask_write(struct vop *vop, uint32_t offset,
> -   uint32_t mask, uint32_t shift, uint32_t v,
> -   bool write_mask, bool relaxed)
> +static void vop_reg_set(struct vop *vop, const struct vop_reg *reg,
> + uint32_t _offset, uint32_t _mask, uint32_t v,
> + const char *reg_name)
>  {
> - if (!mask)
> + int offset = reg->offset + _offset;
> + int mask = reg->mask & _mask;
> + int shift = reg->shift;
> +
> + if (!reg || !reg->mask) {
> + dev_dbg(vop->dev, "Warning: not support %s\n", reg_name);
>   return;
> + }

where the check for !reg happens after it got already dereferenced.
But even with that fixed I end up with

on rk3288:
[7.254823] rockchip-vop ff93.vop: Warning: not support global_regdone_en
[7.262847] rockchip-vop ff93.vop: Warning: not support gate
[7.269580] rockchip-vop ff93.vop: Warning: not support gate
[7.302765] rockchip-vop ff94.vop: Warning: not support global_regdone_en
[7.310758] rockchip-vop ff94.vop: Warning: not support gate
[7.317475] rockchip-vop ff94.vop: Warning: not support gate
[7.425724] rockchip-vop ff93.vop: Warning: not support edp_pin_pol
[7.526298] rockchip-vop ff94.vop: Warning: not support hdmi_pin_pol

on rk3036:
[   12.389138] rockchip-vop 10118000.vop: Warning: not support global_regdone_en
[   12.397324] rockchip-vop 10118000.vop: Warning: not support gate
[   12.404165] rockchip-vop 10118000.vop: Warning: not support gate
[   13.747361] rockchip-vop 10118000.vop: Warning: not support hdmi_pin_pol
[   13.747371] rockchip-vop 10118000.vop: Warning: not support hdmi_en
[   13.747379] rockchip-vop 10118000.vop: Warning: not support hpost_st_end
[   13.747385] rockchip-vop 10118000.vop: Warning: not support vpost_st_end
[   13.747461] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.767098] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl
[   13.786060] rockchip-vop 10118000.vop: Warning: not support src_alpha_ctl

While reqdone and friends are obviously features of newer vops, at least
the hdmi pin-pol is available on both these socs.

With this patch applied (and null-ptr fixed) I end up without hdmi output
on both socs.


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

Re: [PATCH 01/41] drm/gem: Add drm_gem_dumb_map_offset()

2017-07-27 Thread Laurent Pinchart

Hi Noralf,

On Wednesday 26 Jul 2017 20:41:53 Noralf Trønnes wrote:
> Den 26.07.2017 14.05, skrev Emil Velikov:
> > On 23 July 2017 at 20:16, Noralf Trønnes  wrote:
> >> Add a common drm_driver.dumb_map_offset function for GEM backed drivers.
> >> 
> >> Signed-off-by: Noralf Trønnes 
> >> ---
> >> 
> >>   drivers/gpu/drm/drm_gem.c | 35 +++
> >>   include/drm/drm_gem.h |  2 ++
> >>   2 files changed, 37 insertions(+)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> >> index 5df028a..a8d396b 100644
> >> --- a/drivers/gpu/drm/drm_gem.c
> >> +++ b/drivers/gpu/drm/drm_gem.c
> >> @@ -311,6 +311,41 @@ drm_gem_handle_delete(struct drm_file *filp, u32
> >> handle)>> 
> >>   EXPORT_SYMBOL(drm_gem_handle_delete);
> >>   
> >>   /**
> >> + * drm_gem_dumb_map_offset - return the fake mmap offset for a gem
> >> object
> >> + * @file: drm file-private structure containing the gem object
> >> + * @dev: corresponding drm_device
> >> + * @handle: gem object handle
> >> + * @offset: return location for the fake mmap offset
> >> + *
> >> + * This implements the _driver.dumb_map_offset kms driver callback
> >> for
> >> + * drivers which use gem to manage their backing storage.
> >> + *
> >> + * Returns:
> >> + * 0 on success or a negative error code on failure.
> >> + */
> >> +int drm_gem_dumb_map_offset(struct drm_file *file, struct drm_device
> >> *dev,
> >> +   u32 handle, u64 *offset)
> >> +{
> >> +   struct drm_gem_object *obj;
> >> +   int ret;
> >> +
> >> +   obj = drm_gem_object_lookup(file, handle);
> >> +   if (!obj)
> >> +   return -ENOENT;
> >> +
> >> +   ret = drm_gem_create_mmap_offset(obj);
> > 
> > With later patches one goes to reuse this helper instead of
> > drm_gem_cma_dumb_map_offset().
> > At the same time, the latter does not have the
> > drm_gem_create_mmap_offset() call we see here.
> 
> You're rigth, the cma library and a couple of other drivers if I recall
> correctly, call drm_gem_create_mmap_offset() during object creation.
> Daniel was of the opinion that this should happen when mmap is called.
> drm_gem_create_mmap_offset() is idempotent as the docs call it. Calling
> it a second time is ok, since it does nothing (needs to take a lock
> though).

I came to the exact same conclusion. It might be a slightly more efficient if 
we coudl call drm_gem_create_mmap_offset() at the GEM object creation time, 
but as that's not possible for all drivers, and as the .dumb_map_offset() 
operation is not in any hot path anyway, I stopped investigating how we could 
optimize the implementation.

> I haven't removed drm_gem_create_mmap_offset() from the drivers that do
> it during object creation, trying to keep this from doing to much.
> The cma library will be changed though when I add the generic fb/gem
> helper.
> 
> > Meanwhile some drivers have their own offset function which is
> > virtually identical to the original drm_gem_cma_dumb_map_offset.
> > Yet those are left unchanged.
> > 
> > For example in cirrus [1]:
> > There the only code difference seems to be an "upcast" followed
> > immediately by a "downcast". Which should effectively be a noop.
> 
> The main reason for that is to try and keep this simple so I'm able to
> add my shmem/gem library in reasonable time :-) I didn't want to do
> changes that wasn't straight forward. But yes, the cirrus drivers looks
> quite straight forward and the functions isn't used by other parts of
> the driver. I looked at a driver (omap?) that had similar functions,
> and those where called from other parts of the driver, so I expected
> the same here I guess.

For omapdrm I believe we could drop the custom .dumb_map_offset() operation, 
as the only use for customs offsets in the driver is for tiled buffers, which 
are created by an omapdrm-specific IOCTL. However, I can't tell at the moment 
whether userspace code that create tiled buffers with the OMAP_GEM_NEW ioctl 
get the mmap offset with OMAP_GEM_INFO as they should, or if 
DRM_IOCTL_MODE_MAP_DUMB gets sometimes abused for non-dumb buffers.

> You say "some drivers", can you name them?
> Some drivers takes locks or do other stuff that made me skip them.
> 
> Noralf.
> 
> > That said, I could be loosing my marbles.
> > 
> > HTH
> > Emil
> > 
> > [1]
> > https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/cirrus/cir
> > rus_main.c#n292

-- 
Regards,

Laurent Pinchart

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

[PATCH] tinydrm: repaper: add CONFIG_THERMAL dependency

2017-07-27 Thread Arnd Bergmann

The new RePaper driver uses the thermal subsystem, and fails to link
when it is built-in but thermal is a loadable module:

drivers/gpu/drm/tinydrm/repaper.o: In function `repaper_probe':
repaper.c:(.text+0x540): undefined reference to `thermal_zone_get_zone_by_name'
drivers/gpu/drm/tinydrm/repaper.o: In function `repaper_fb_dirty':
repaper.c:(.text+0xff4): undefined reference to `thermal_zone_get_temp'

This adds another Kconfig dependency to prevent the broken configuration,
forcing repaper to be a module too.

Fixes: 3589211e9b03 ("drm/tinydrm: Add RePaper e-ink driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tinydrm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 9596e447f877..f17c3caceab2 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -23,6 +23,7 @@ config TINYDRM_MI0283QT
 config TINYDRM_REPAPER
tristate "DRM support for Pervasive Displays RePaper panels (V231)"
depends on DRM_TINYDRM && SPI
+   depends on THERMAL || !THERMAL
help
  DRM driver for the following Pervasive Displays panels:
  1.44" TFT EPD Panel (E1144CS021)
-- 
2.9.0

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

Re: [PATCH v6 4/7] drm/rockchip: vop: group vop registers

2017-07-27 Thread Heiko Stübner

Hi Mark,

Am Mittwoch, 26. Juli 2017, 14:19:25 CEST schrieb Mark Yao:
> Grouping the vop registers facilitates make register
> definition clearer, and also is useful for different vop
> reuse the same group register.
> 
> Signed-off-by: Mark Yao 
> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  99 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  60 ---
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 112
> +++- 3 files changed, 144 insertions(+), 127
> deletions(-)

This breaks display support on both rk3036 and rk3288 and I end up
with a null pointer dereference in

[   10.640297] Unable to handle kernel NULL pointer dereference at virtual 
address 
[   10.654430] pgd = c0204000
[   10.657452] [] *pgd=
[   10.661473] Internal error: Oops: 5 [#1] SMP ARM
[   10.35] Modules linked in: snd_pcm media snd_timer phy_rockchip_dp snd 
soundcore rockchipdrm dw_hdmi analogix_dp rtc_rk808 pwm_rockchip clk_rk808 
spi_rockchip
[   10.682897] CPU: 2 PID: 143 Comm: kworker/2:2 Not tainted 
4.13.0-rc2-01791-g2b86603d0515 #355
[   10.692430] Hardware name: Rockchip (Device Tree)
[   10.697692] Workqueue: events deferred_probe_work_func
[   10.702152] Linux video capture interface: v2.00
[   10.708590] task: ee38c800 task.stack: ed2e6000
[   10.713656] PC is at vop_reg_set.constprop.4+0x4/0xa8 [rockchipdrm]
[   10.720668] LR is at vop_bind+0x568/0x8a0 [rockchipdrm]
[   10.726507] pc : []lr : []psr: 40010013
[   10.733514] sp : ed2e7d68  ip : 0004  fp : bf054988
[   10.739350] r10: bf054988  r9 :   r8 : 0001
[   10.745189] r7 : ed66f500  r6 : ee29da10  r5 :   r4 : ed22e010
[   10.752487] r3 :   r2 :   r1 :   r0 : ed22e010
[   10.759785] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   10.767763] Control: 10c5387d  Table: 2d4e806a  DAC: 0051
[   10.774188] Process kworker/2:2 (pid: 143, stack limit = 0xed2e6220)
[...]
[   11.058818] [] (vop_reg_set.constprop.4 [rockchipdrm]) from 
[] (vop_bind+0x568/0x8a0 [rockchipdrm])
[   11.058828] [] (vop_bind [rockchipdrm]) from [] 
(component_bind_all+0x11c/0x23c)
[   11.058836] [] (component_bind_all) from [] 
(rockchip_drm_bind+0x90/0x1d4 [rockchipdrm])
[   11.058843] [] (rockchip_drm_bind [rockchipdrm]) from [] 
(try_to_bring_up_master+0x148/0x184)
[   11.058847] [] (try_to_bring_up_master) from [] 
(component_add+0x98/0x144)
[   11.058853] [] (component_add) from [] 
(rockchip_dp_probe+0x7c/0x8c [rockchipdrm])
[   11.058860] [] (rockchip_dp_probe [rockchipdrm]) from [] 
(platform_drv_probe+0x50/0xb0)
[   11.058865] [] (platform_drv_probe) from [] 
(driver_probe_device+0x230/0x2e4)
[   11.058869] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x60/0x94)
[   11.058873] [] (bus_for_each_drv) from [] 
(__device_attach+0xb0/0x114)
[   11.058876] [] (__device_attach) from [] 
(bus_probe_device+0x84/0x8c)
[   11.058879] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x68/0x94)
[   11.058884] [] (deferred_probe_work_func) from [] 
(process_one_work+0x200/0x504)
[   11.058889] [] (process_one_work) from [] 
(worker_thread+0x38/0x594)
[   11.058894] [] (worker_thread) from [] 
(kthread+0x128/0x158)
[   11.058900] [] (kthread) from [] 
(ret_from_fork+0x14/0x3c)
[   11.058904] Code: eae0 e3a03004 eaef e92d4070 (e5914000)
[   11.058930] ---[ end trace 9caa88bbcb1af5e4 ]---

I'll try to investigate a bit more, but maybe you'll be able to
find the issue faster than me in the meantime.


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

Re: [PATCH v3 0/3] Add support for the otm8009a dsi panel

2017-07-27 Thread Philippe CORNU

Hi Thierry,

The 2 dt-bindings patches have been "acked" by Rob.
The driver itself has been "reviewed" two times by Andrzej.

Do not hesitate to send me any comments so I can take them into account 
before my holidays (end of next week)...

Many thanks for your support,

Philippe :-)


On 07/17/2017 03:19 PM, Philippe CORNU wrote:
> Version 3:
> - panel-orisetech-otm8009a.c: Remove a FIXME (Andrzej Hajda)
> - panel/Makefile & Kconfig: Alphabetical order (Andrzej Hajda)
> 
> Version 2:
> - panel-orisetech-otm8009a.c: Add Manufacturer Command Set defines,
>add new macro for handling address shifting, improve reset
>sequence, use more mipi dcs helpers (Andrzej Hajda)
> - dt-bindings/display/panel/orisetech,otm8009a.txt: Fix reset gpio
>active level in the example (Andrzej Hajda), Add an "Optional
>Properties" section (Rob Herring).
> 
> Version 1:
> - Initial commit
> 
> The purpose of this patch is to add support for the Orise Tech
> otm8009a 3.97" 480x800 TFT LCD panel (MIPI-DSI video mode).
> This LCD panel is used in several STM32 boards.
> 
> Philippe CORNU (3):
>dt-bindings: Add vendor prefix for Orise Technology
>dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi
>  panel
>drm/panel: Add support for otm8009a panel driver
> 
>   .../bindings/display/panel/orisetech,otm8009a.txt  |  21 +
>   .../devicetree/bindings/vendor-prefixes.txt|   1 +
>   drivers/gpu/drm/panel/Kconfig  |   9 +
>   drivers/gpu/drm/panel/Makefile |   1 +
>   drivers/gpu/drm/panel/panel-orisetech-otm8009a.c   | 491 
> +
>   5 files changed, 523 insertions(+)
>   create mode 100644 
> Documentation/devicetree/bindings/display/panel/orisetech,otm8009a.txt
>   create mode 100755 drivers/gpu/drm/panel/panel-orisetech-otm8009a.c
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v6,5/7] drm/rockchip: vop: add a series of vop support

2017-07-27 Thread jeffy


Hi mark,

On 07/26/2017 02:19 PM, Mark yao wrote:

Vop Full framework now has following vops:
IP versionchipname
   3.1   rk3288
   3.2   rk3368
   3.4   rk3366
   3.5   rk3399 big
   3.6   rk3399 lit
   3.7   rk3228
   3.8   rk3328

The above IP version is from H/W define, some of vop support get
the IP version from VERSION_INFO register, some are not.
hardcode the IP version for each vop to identify them.

major version: used for IP structure, Vop full framework is 3,
vop little framework is 2.
minor version: on same structure, newer design vop will bigger
then old one.

Signed-off-by: Mark Yao


Reviewed-by: Jeffy Chen 

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

Re: [v6,4/7] drm/rockchip: vop: group vop registers

2017-07-27 Thread jeffy


Hi mark,

On 07/26/2017 02:19 PM, Mark yao wrote:

Grouping the vop registers facilitates make register
definition clearer, and also is useful for different vop
reuse the same group register.

Signed-off-by: Mark Yao


Reviewed-by: Jeffy Chen 

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

Re: [v6, 2/7] drm/rockchip: vop: move write_relaxed flags to vop register

2017-07-27 Thread jeffy


Hi mark,

On 07/26/2017 02:19 PM, Mark yao wrote:

Since the drm atomic framework, only a small part of the vop
register needs sync write, Currently seems only following registers
need sync write:
cfg_done, standby and interrupt related register.

All ctrl registers are using the sync write method that is
inefficient, hardcode the write_relaxed flags to vop registers,
then can only do synchronize write for those actual needed register.

Signed-off-by: Mark Yao
Tested-by: Heiko Stuebner


Reviewed-by: Jeffy Chen 

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

Re: [v6,7/7] drm/rockchip: vop: rk3328: fix overlay abnormal

2017-07-27 Thread jeffy


Hi mark,

On 07/26/2017 02:19 PM, Mark yao wrote:

It's a hardware bug, all window's overlay channel reset
value is same, hardware overlay would be die.

so we must initial difference id for each overlay channel.

The Channel register is supported on all vop will full design.
Following is the details for this register
VOP_WIN0_CTRL2
   bit[7:4] win_rid_win0_cbr
axi read id of win0 cbr channel
   bit[3:0] win_rid_win0_yrgb
axi read id of win0 yrgb channel

Signed-off-by: Mark Yao


Reviewed-by: Jeffy Chen 

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

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

2017-07-27 Thread Takashi Iwai

On Thu, 27 Jul 2017 10:25:24 +0200,
Daniel Vetter wrote:
> 
> On Thu, Jul 27, 2017 at 10:22 AM, Takashi Iwai  wrote:
> > On Thu, 27 Jul 2017 08:52:48 +0200,
> > Daniel Vetter wrote:
> >>
> >> On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote:
> >> > The virtio drm driver doesn't treat with DPMS, so we should return an
> >> > error from the connector dpms callback so that the fbcon can fall back
> >> > to the generic blank mode.
> >> >
> >> > Signed-off-by: Takashi Iwai 
> >> > ---
> >> >  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> >> >  1 file changed, 8 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> >> > b/drivers/gpu/drm/virtio/virtgpu_display.c
> >> > index d51bd4521f17..77d5bad49c5f 100644
> >> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> >> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> >> > @@ -249,8 +249,15 @@ static void virtio_gpu_conn_destroy(struct 
> >> > drm_connector *connector)
> >> > kfree(virtio_gpu_output);
> >> >  }
> >> >
> >> > +static int virtio_gpu_conn_dpms(struct drm_connector *connector, int 
> >> > mode)
> >> > +{
> >> > +   drm_atomic_helper_connector_dpms(connector, mode);
> >> > +   /* FIXME: return error to make fbcon generic blank working */
> >>
> >> Why FIXME here? You just fixed that issue, feels like should just be a
> >> normal comment. I'd just say
> >>
> >>   /* no DPMS for virtual drivers, it would close the window, making
> >>* the guest inaccesible */
> >>
> >> > +   return -EINVAL;
> >>
> >> Ok, I've changed my plans for properties and DPMS a bit for atomic
> >> drivers, and the ->dpms hook will be gone really soon. There's also the
> >> problem that rejecting DPMS through the legacy interface, but allowing it
> >> through the atomic interface isn't good api (and yes we have igts to check
> >> for that).
> >>
> >> I think it'd be better to reject this properly in the atomic_check phase
> >> in the crtc_helper_funcs->atomic_check function, with something like this:
> >>
> >>   if (crtc->state->enable && !crtc->state->active)
> >>   return -EINVAL;
> >>
> >> That should result in an -EINVAL for any caller who tries to update the
> >> DPMS property. Which is important, since with the new atomic fbdev helper
> >> code, fbdev does directly call into the atomic code and entirely bypasses
> >> the ->dpms hook (that part is merged already, and why you need to rebase
> >> patch 1).
> >>
> >> That would also make sure that we don't return -EINVAL and still shut down
> >> the screen (atomic does that for you, there's no difference between DPMS
> >> off and fully disabling it).
> >>
> >> Sorry that I'm dragging you all over with this for yet another respin :-/
> >
> > OK, no problem, my patchset was a quite easy one.
> >
> > The atomic fb helper change looks going to a right direction.  When
> > the above check is implemented in the helper side, is still anything
> > needed in each driver side?
> 
> The above check would need to be added to the crtc_funcs->atomic_check
> callback for vritio and qxl, not the shared atomic helpers.

Ah, now it's clearly understood.

> > Also, for legacy drivers, we still need tricks as done in this
> > patchset, right?
> 
> Yes, those still need a dpms callback that just returns -EINVAL.

OK.


thanks,

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

Re: [v6,1/7] drm/rockchip: vop: initialize registers directly

2017-07-27 Thread jeffy


Hi mark,

On 07/26/2017 02:19 PM, Mark yao wrote:

At present we are using init_table to initialize some
registers, but the Register init table use un-document define,
it is unreadable, and sometimes we only want to update tiny
bits, init table method is not friendly, it's diffcult to
reuse for difference chips.

To make it clean, initialize registers directly, and drops
init_table mechanism out.

Signed-off-by: Mark Yao
Tested-by: Heiko Stuebner


Reviewed-by: Jeffy Chen 

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

Re: [PATCH] android: amdgpu: move asic id table to a separate file

2017-07-27 Thread Chih-Wei Huang

> 2017-07-26 17:27 GMT+02:00 Emil Velikov :
>> On 25 July 2017 at 08:28, Chih-Wei Huang  wrote:
>>> Hi Mauro,
>>> Please note AMDGPU_ASIC_ID_TABLE
>>> should be a path in the target device (i.e., Android).
>>> So using $(LIBDRM_TOP) is incorrect.
>>>
>>> Actually I've sent a fix for it about one week ago.
>>>
>> Did you sent v2 of the patch? I cannot see any in my inbox.

OK. I re-submitted v2 patch to replace
/etc with /system/etc.

2017-07-27 1:36 GMT+08:00 Mauro Rossi :
> This one has conceptual error and is to be dropped.
>
> The ones submitted by Chih-Wei are here:
>
> https://github.com/maurossi/drm/commits/2.4.82_android-x86
>
> where in the (v2) of the second I just replaced /etc path with 
> $(TARGET_OUT_ETC)

No. TARGET_OUT_ETC is still the host path.
(which is out/target/product/$target/system/etc )

> Chih-Wei if you like the (v2) could you please resubmit to dri-devel
> using [PATCH libdrm] in the title?

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

2017-07-27 Thread Daniel Vetter

On Thu, Jul 27, 2017 at 10:22 AM, Takashi Iwai  wrote:
> On Thu, 27 Jul 2017 08:52:48 +0200,
> Daniel Vetter wrote:
>>
>> On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote:
>> > The virtio drm driver doesn't treat with DPMS, so we should return an
>> > error from the connector dpms callback so that the fbcon can fall back
>> > to the generic blank mode.
>> >
>> > Signed-off-by: Takashi Iwai 
>> > ---
>> >  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
>> >  1 file changed, 8 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
>> > b/drivers/gpu/drm/virtio/virtgpu_display.c
>> > index d51bd4521f17..77d5bad49c5f 100644
>> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
>> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
>> > @@ -249,8 +249,15 @@ static void virtio_gpu_conn_destroy(struct 
>> > drm_connector *connector)
>> > kfree(virtio_gpu_output);
>> >  }
>> >
>> > +static int virtio_gpu_conn_dpms(struct drm_connector *connector, int mode)
>> > +{
>> > +   drm_atomic_helper_connector_dpms(connector, mode);
>> > +   /* FIXME: return error to make fbcon generic blank working */
>>
>> Why FIXME here? You just fixed that issue, feels like should just be a
>> normal comment. I'd just say
>>
>>   /* no DPMS for virtual drivers, it would close the window, making
>>* the guest inaccesible */
>>
>> > +   return -EINVAL;
>>
>> Ok, I've changed my plans for properties and DPMS a bit for atomic
>> drivers, and the ->dpms hook will be gone really soon. There's also the
>> problem that rejecting DPMS through the legacy interface, but allowing it
>> through the atomic interface isn't good api (and yes we have igts to check
>> for that).
>>
>> I think it'd be better to reject this properly in the atomic_check phase
>> in the crtc_helper_funcs->atomic_check function, with something like this:
>>
>>   if (crtc->state->enable && !crtc->state->active)
>>   return -EINVAL;
>>
>> That should result in an -EINVAL for any caller who tries to update the
>> DPMS property. Which is important, since with the new atomic fbdev helper
>> code, fbdev does directly call into the atomic code and entirely bypasses
>> the ->dpms hook (that part is merged already, and why you need to rebase
>> patch 1).
>>
>> That would also make sure that we don't return -EINVAL and still shut down
>> the screen (atomic does that for you, there's no difference between DPMS
>> off and fully disabling it).
>>
>> Sorry that I'm dragging you all over with this for yet another respin :-/
>
> OK, no problem, my patchset was a quite easy one.
>
> The atomic fb helper change looks going to a right direction.  When
> the above check is implemented in the helper side, is still anything
> needed in each driver side?

The above check would need to be added to the crtc_funcs->atomic_check
callback for vritio and qxl, not the shared atomic helpers.

> Also, for legacy drivers, we still need tricks as done in this
> patchset, right?

Yes, those still need a dpms callback that just returns -EINVAL.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

2017-07-27 Thread Takashi Iwai

On Thu, 27 Jul 2017 08:52:48 +0200,
Daniel Vetter wrote:
> 
> On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote:
> > The virtio drm driver doesn't treat with DPMS, so we should return an
> > error from the connector dpms callback so that the fbcon can fall back
> > to the generic blank mode.
> > 
> > Signed-off-by: Takashi Iwai 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
> >  1 file changed, 8 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> > b/drivers/gpu/drm/virtio/virtgpu_display.c
> > index d51bd4521f17..77d5bad49c5f 100644
> > --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> > +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> > @@ -249,8 +249,15 @@ static void virtio_gpu_conn_destroy(struct 
> > drm_connector *connector)
> > kfree(virtio_gpu_output);
> >  }
> >  
> > +static int virtio_gpu_conn_dpms(struct drm_connector *connector, int mode)
> > +{
> > +   drm_atomic_helper_connector_dpms(connector, mode);
> > +   /* FIXME: return error to make fbcon generic blank working */
> 
> Why FIXME here? You just fixed that issue, feels like should just be a
> normal comment. I'd just say
> 
>   /* no DPMS for virtual drivers, it would close the window, making
>* the guest inaccesible */
> 
> > +   return -EINVAL;
> 
> Ok, I've changed my plans for properties and DPMS a bit for atomic
> drivers, and the ->dpms hook will be gone really soon. There's also the
> problem that rejecting DPMS through the legacy interface, but allowing it
> through the atomic interface isn't good api (and yes we have igts to check
> for that).
> 
> I think it'd be better to reject this properly in the atomic_check phase
> in the crtc_helper_funcs->atomic_check function, with something like this:
> 
>   if (crtc->state->enable && !crtc->state->active)
>   return -EINVAL;
> 
> That should result in an -EINVAL for any caller who tries to update the
> DPMS property. Which is important, since with the new atomic fbdev helper
> code, fbdev does directly call into the atomic code and entirely bypasses
> the ->dpms hook (that part is merged already, and why you need to rebase
> patch 1).
> 
> That would also make sure that we don't return -EINVAL and still shut down
> the screen (atomic does that for you, there's no difference between DPMS
> off and fully disabling it).
> 
> Sorry that I'm dragging you all over with this for yet another respin :-/

OK, no problem, my patchset was a quite easy one.

The atomic fb helper change looks going to a right direction.  When
the above check is implemented in the helper side, is still anything
needed in each driver side?

Also, for legacy drivers, we still need tricks as done in this
patchset, right?


thanks,

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

[PATCH libdrm v2 2/2] android: amdgpu: fix build break

2017-07-27 Thread Chih-Wei Huang

Define two macros to avoid building errors.

Fixes: 7e6bf88cac (amdgpu: move asic id table to a separate file)

Signed-off-by: Chih-Wei Huang 
---
 amdgpu/Android.mk | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/amdgpu/Android.mk b/amdgpu/Android.mk
index bf0611b..88d3765 100644
--- a/amdgpu/Android.mk
+++ b/amdgpu/Android.mk
@@ -10,5 +10,11 @@ LOCAL_SHARED_LIBRARIES := libdrm
 
 LOCAL_SRC_FILES := $(LIBDRM_AMDGPU_FILES)
 
+LOCAL_CFLAGS := \
+   -DAMDGPU_ASIC_ID_TABLE=\"/system/etc/hwdata/amdgpu.ids\" \
+   -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(shell egrep -ci 
'^[0-9a-f]{4},.*[0-9a-f]+,' $(LIBDRM_TOP)/data/amdgpu.ids)
+
+LOCAL_REQUIRED_MODULES := amdgpu.ids
+
 include $(LIBDRM_COMMON_MK)
 include $(BUILD_SHARED_LIBRARY)
-- 
1.9.1

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

[PATCH libdrm v2 1/2] android: add rules to build amdgpu.ids

2017-07-27 Thread Chih-Wei Huang

Signed-off-by: Chih-Wei Huang 
---
 data/Android.mk | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 data/Android.mk

diff --git a/data/Android.mk b/data/Android.mk
new file mode 100644
index 000..3c1fd7c
--- /dev/null
+++ b/data/Android.mk
@@ -0,0 +1,9 @@
+LOCAL_PATH := $(call my-dir)
+
+include $(CLEAR_VARS)
+LOCAL_MODULE := amdgpu.ids
+LOCAL_MODULE_TAGS := optional
+LOCAL_MODULE_CLASS := ETC
+LOCAL_MODULE_PATH := $(TARGET_OUT_ETC)/hwdata
+LOCAL_SRC_FILES := $(LOCAL_MODULE)
+include $(BUILD_PREBUILT)
-- 
1.9.1

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

Re: [PATCH v2 09/12] drm/tilcdc: Handle drm_atomic_helper_swap_state failure

2017-07-27 Thread Jyri Sarha

On 07/11/17 17:33, Maarten Lankhorst wrote:
> drm_atomic_helper_swap_state() will be changed to interruptible waiting
> in the next few commits, so all drivers have to be changed to handling
> failure.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Jyri Sarha 
> Cc: Tomi Valkeinen 

This has probably been applied already, but here is my

Acked-by: Jyri Sarha 

just in case it is not.

> ---
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index d67e18983a7d..049d2f5a1ee4 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -108,7 +108,11 @@ static int tilcdc_commit(struct drm_device *dev,
>   if (ret)
>   return ret;
>  
> - drm_atomic_helper_swap_state(state, true);
> + ret = drm_atomic_helper_swap_state(state, true);
> + if (ret) {
> + drm_atomic_helper_cleanup_planes(dev, state);
> + return ret;
> + }
>  
>   /*
>* Everything below can be run asynchronously without the need to grab
> 

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

Re: [PATCH 3/5] drm/virtio: Return an error from connector dpms callback

2017-07-27 Thread Daniel Vetter

On Wed, Jul 26, 2017 at 10:56:34PM +0200, Takashi Iwai wrote:
> The virtio drm driver doesn't treat with DPMS, so we should return an
> error from the connector dpms callback so that the fbcon can fall back
> to the generic blank mode.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/virtio/virtgpu_display.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c 
> b/drivers/gpu/drm/virtio/virtgpu_display.c
> index d51bd4521f17..77d5bad49c5f 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_display.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_display.c
> @@ -249,8 +249,15 @@ static void virtio_gpu_conn_destroy(struct drm_connector 
> *connector)
>   kfree(virtio_gpu_output);
>  }
>  
> +static int virtio_gpu_conn_dpms(struct drm_connector *connector, int mode)
> +{
> + drm_atomic_helper_connector_dpms(connector, mode);
> + /* FIXME: return error to make fbcon generic blank working */

Why FIXME here? You just fixed that issue, feels like should just be a
normal comment. I'd just say

/* no DPMS for virtual drivers, it would close the window, making
 * the guest inaccesible */

> + return -EINVAL;

Ok, I've changed my plans for properties and DPMS a bit for atomic
drivers, and the ->dpms hook will be gone really soon. There's also the
problem that rejecting DPMS through the legacy interface, but allowing it
through the atomic interface isn't good api (and yes we have igts to check
for that).

I think it'd be better to reject this properly in the atomic_check phase
in the crtc_helper_funcs->atomic_check function, with something like this:

if (crtc->state->enable && !crtc->state->active)
return -EINVAL;

That should result in an -EINVAL for any caller who tries to update the
DPMS property. Which is important, since with the new atomic fbdev helper
code, fbdev does directly call into the atomic code and entirely bypasses
the ->dpms hook (that part is merged already, and why you need to rebase
patch 1).

That would also make sure that we don't return -EINVAL and still shut down
the screen (atomic does that for you, there's no difference between DPMS
off and fully disabling it).

Sorry that I'm dragging you all over with this for yet another respin :-/

Thanks, Daniel

> +}
> +
>  static const struct drm_connector_funcs virtio_gpu_connector_funcs = {
> - .dpms = drm_atomic_helper_connector_dpms,
> + .dpms = virtio_gpu_conn_dpms,
>   .detect = virtio_gpu_conn_detect,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy = virtio_gpu_conn_destroy,
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 2/5] drm/bochs: Return an error from connector dpms callback

2017-07-27 Thread Daniel Vetter

On Wed, Jul 26, 2017 at 10:56:33PM +0200, Takashi Iwai wrote:
> The bochs drm driver doesn't treat with DPMS, so we should return an
> error from the connector dpms callback so that the fbcon can fall back
> to the generic blank mode.
> 
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/gpu/drm/bochs/bochs_kms.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c 
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 6a91e62da2f4..a60d1a05950f 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -217,6 +217,13 @@ bochs_connector_best_encoder(struct drm_connector 
> *connector)
>   return NULL;
>  }
>  
> +static int bochs_connector_dpms(struct drm_connector *connector, int mode)
> +{
> + drm_helper_connector_dpms(connector, mode);
> + /* FIXME: return error to make fbcon generic blank working */
> + return -EINVAL;

Thought about this some more, disabling the screen and return -EINVAL (to
userspace even) feels like rather bad semantics. Could we just do an
-EINVAL instead?

I thought the DPMS off change doesn't do anything anyway, so this is pure
dead code.
-Daniel

> +}
> +
>  static const struct drm_connector_helper_funcs 
> bochs_connector_connector_helper_funcs = {
>   .get_modes = bochs_connector_get_modes,
>   .mode_valid = bochs_connector_mode_valid,
> @@ -224,7 +231,7 @@ static const struct drm_connector_helper_funcs 
> bochs_connector_connector_helper_
>  };
>  
>  static const struct drm_connector_funcs bochs_connector_connector_funcs = {
> - .dpms = drm_helper_connector_dpms,
> + .dpms = bochs_connector_dpms,
>   .fill_modes = drm_helper_probe_single_connector_modes,
>   .destroy = drm_connector_cleanup,
>  };
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 1/5] drm: Propagate error from connector dpms function in drm_fb_helper_blank()

2017-07-27 Thread Daniel Vetter

On Wed, Jul 26, 2017 at 10:56:32PM +0200, Takashi Iwai wrote:
> Currently the DRM fbcon helper for console blank,
> drm_fb_helper_blank(), simply calls drm_fb_helper_dpms() and always
> returns zero, supposing the driver dealing with DPMS properly for
> blanking the screen.  However, it turned out that the console blank
> doesn't work at all on KVM/QEMU when DRM driver is used: most of the
> relevant drivers (bochs, qxl, and virtio) just ignore DPMS, and even
> cirrus driver doesn't work because the DPMS register bits the driver
> fiddles with are also ignored by KVM/QEMU.
> 
> A simple fix for this problem would be not to rely on DPMS but let
> fbcon performs the generic blank code.  This can be achieved just by
> returning an error from drm_fb_helper_blank().
> 
> In this patch, we change the drm_fb_helper_dpms() to give back an
> error code returned from the connector dpms callback, so that the
> error is propagated to drm_fb_helper_blank().  After this change, each
> driver needs just to return an error to fall back to the generic fbcon
> blank mode.
> 
> Signed-off-by: Takashi Iwai 

This needs to be rebased onto -next, this code changed a lot.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 30 --
>  1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 574af01d3ce9..db31747ae598 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -581,21 +581,22 @@ static struct sysrq_key_op 
> sysrq_drm_fb_helper_restore_op = {
>  static struct sysrq_key_op sysrq_drm_fb_helper_restore_op = { };
>  #endif
>  
> -static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
> +static int drm_fb_helper_dpms(struct fb_info *info, int dpms_mode)
>  {
>   struct drm_fb_helper *fb_helper = info->par;
>   struct drm_device *dev = fb_helper->dev;
>   struct drm_crtc *crtc;
>   struct drm_connector *connector;
>   int i, j;
> + int ret = 0;
>  
>   /*
>* For each CRTC in this fb, turn the connectors on/off.
>*/
>   drm_modeset_lock_all(dev);
>   if (!drm_fb_helper_is_bound(fb_helper)) {
> - drm_modeset_unlock_all(dev);
> - return;
> + ret = -ENODEV;
> + goto out;
>   }
>  
>   for (i = 0; i < fb_helper->crtc_count; i++) {
> @@ -607,12 +608,16 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
> int dpms_mode)
>   /* Walk the connectors & encoders on this fb turning them 
> on/off */
>   drm_fb_helper_for_each_connector(fb_helper, j) {
>   connector = fb_helper->connector_info[j]->connector;
> - connector->funcs->dpms(connector, dpms_mode);
> + ret = connector->funcs->dpms(connector, dpms_mode);
> + if (ret < 0)
> + goto out;
>   drm_object_property_set_value(>base,
>   dev->mode_config.dpms_property, dpms_mode);
>   }
>   }
> + out:
>   drm_modeset_unlock_all(dev);
> + return ret;
>  }
>  
>  /**
> @@ -622,32 +627,37 @@ static void drm_fb_helper_dpms(struct fb_info *info, 
> int dpms_mode)
>   */
>  int drm_fb_helper_blank(int blank, struct fb_info *info)
>  {
> + int dpms_mode;
> +
>   if (oops_in_progress)
>   return -EBUSY;
>  
>   switch (blank) {
>   /* Display: On; HSync: On, VSync: On */
>   case FB_BLANK_UNBLANK:
> - drm_fb_helper_dpms(info, DRM_MODE_DPMS_ON);
> + dpms_mode = DRM_MODE_DPMS_ON;
>   break;
>   /* Display: Off; HSync: On, VSync: On */
>   case FB_BLANK_NORMAL:
> - drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> + dpms_mode = DRM_MODE_DPMS_STANDBY;
>   break;
>   /* Display: Off; HSync: Off, VSync: On */
>   case FB_BLANK_HSYNC_SUSPEND:
> - drm_fb_helper_dpms(info, DRM_MODE_DPMS_STANDBY);
> + dpms_mode = DRM_MODE_DPMS_STANDBY;
>   break;
>   /* Display: Off; HSync: On, VSync: Off */
>   case FB_BLANK_VSYNC_SUSPEND:
> - drm_fb_helper_dpms(info, DRM_MODE_DPMS_SUSPEND);
> + dpms_mode = DRM_MODE_DPMS_SUSPEND;
>   break;
>   /* Display: Off; HSync: Off, VSync: Off */
>   case FB_BLANK_POWERDOWN:
> - drm_fb_helper_dpms(info, DRM_MODE_DPMS_OFF);
> + dpms_mode = DRM_MODE_DPMS_OFF;
>   break;
> + default:
> + return 0; /* ignored */
>   }
> - return 0;
> +
> + return drm_fb_helper_dpms(info, dpms_mode);
>  }
>  EXPORT_SYMBOL(drm_fb_helper_blank);
>  
> -- 
> 2.13.3
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter

Re: [PATCH 17/41] drm/sun4i: Use .dumb_map_offset and .dumb_destroy defaults

2017-07-27 Thread Maxime Ripard

On Sun, Jul 23, 2017 at 09:16:33PM +0200, Noralf Trønnes wrote:
> This driver can use the drm_driver.dumb_destroy and
> drm_driver.dumb_map_offset defaults, so no need to set them.
> 
> Cc: Maxime Ripard 
> Signed-off-by: Noralf Trønnes 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 89cd590..d599206 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -40,8 +40,6 @@ static struct drm_driver sun4i_drv_driver = {
>  
>   /* GEM Operations */
>   .dumb_create= drm_gem_cma_dumb_create,
> - .dumb_destroy   = drm_gem_dumb_destroy,
> - .dumb_map_offset= drm_gem_cma_dumb_map_offset,
>   .gem_free_object_unlocked = drm_gem_cma_free_object,
>   .gem_vm_ops = _gem_cma_vm_ops,

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


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

96 matches

Mail list logo