Re: [patch V2 28/29] stacktrace: Provide common infrastructure

[Peter Zijlstra]

On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote:
> On Thu, 18 Apr 2019, Josh Poimboeuf wrote:

> > Another idea I had (but never got a chance to work on) was to extend the
> > x86 unwind interface to all arches.  So instead of the callbacks, each
> > arch would implement something like this API:

> I surely thought about that, but after staring at all incarnations of
> arch/*/stacktrace.c I just gave up.
> 
> Aside of that quite some archs already have callback based unwinders
> because they use them for more than stacktracing and just have a single
> implementation of that loop.
> 
> I'm fine either way. We can start with x86 and then let archs convert over
> their stuff, but I wouldn't hold my breath that this will be completed in
> the forseeable future.

I suggested the same to Thomas early on, and I even spend the time to
convert some $random arch to the iterator interface, and while it is
indeed entirely feasible, it is _far_ more work.

The callback thing OTOH is flexible enough to do what we want to do now,
and allows converting most archs to it without too much pain (as Thomas
said, many archs are already in this form and only need minor API
adjustments), which gets us in a far better place than we are now.

And we can always go to iterators later on. But I think getting the
generic unwinder improved across all archs is a really important first
step here.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110457] System resumes failed and hits [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout on Acer Squirtle_SR laptop

[bugzilla-daemon]

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

--- Comment #5 from jian-h...@endlessm.com ---
Created attachment 144042
  --> https://bugs.freedesktop.org/attachment.cgi?id=144042&action=edit
journal log on Acer TravelMate B114-21

Got more information after wait more time for resuming on Acer TravelMate
B114-21.

Apr 19 15:06:38 endless kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring
gfx timeout, signaled seq=2841, emitted seq=2845
Apr 19 15:06:38 endless kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR*
Process information: process Xorg pid 695 thread Xorg:cs0 pid 698
Apr 19 15:06:38 endless kernel: [drm] IP block:gfx_v8_0 is hung!
Apr 19 15:06:38 endless kernel: [drm] GPU recovery disabled.
Apr 19 15:06:40 endless kernel: INFO: task Xorg:695 blocked for more than 604
seconds.
Apr 19 15:06:40 endless kernel:   Tainted: GW 5.1.0-rc5+ #1
Apr 19 15:06:40 endless kernel: "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Apr 19 15:06:40 endless kernel: XorgD0   695683 0x0044
Apr 19 15:06:40 endless kernel: Call Trace:
Apr 19 15:06:40 endless kernel:  __schedule+0x2d4/0x840
Apr 19 15:06:40 endless kernel:  schedule+0x2c/0x70
Apr 19 15:06:40 endless kernel:  schedule_timeout+0x258/0x360
Apr 19 15:06:40 endless kernel:  ? amdgpu_atom_execute_table_locked+0x136/0x210
[amdgpu]
Apr 19 15:06:40 endless kernel:  dma_fence_default_wait+0x20a/0x280
Apr 19 15:06:40 endless kernel:  ? dma_fence_release+0xa0/0xa0
Apr 19 15:06:40 endless kernel:  dma_fence_wait_timeout+0xe7/0x110
Apr 19 15:06:40 endless kernel:  amdgpu_fence_wait_empty+0x61/0xc0 [amdgpu]
Apr 19 15:06:40 endless kernel:  amdgpu_pm_compute_clocks+0x70/0x590 [amdgpu]
Apr 19 15:06:40 endless kernel:  dm_pp_apply_display_requirements+0x19a/0x1b0
[amdgpu]
Apr 19 15:06:40 endless kernel: 
dce11_pplib_apply_display_requirements+0x1f4/0x210 [amdgpu]
Apr 19 15:06:40 endless kernel:  dce11_update_clocks+0xa0/0x100 [amdgpu]
Apr 19 15:06:40 endless kernel:  dce110_prepare_bandwidth+0x3e/0x50 [amdgpu]
Apr 19 15:06:40 endless kernel:  dc_commit_state+0x22d/0x5a0 [amdgpu]
Apr 19 15:06:40 endless kernel:  ? drm_calc_timestamping_constants+0x106/0x150
[drm]
Apr 19 15:06:40 endless kernel:  amdgpu_dm_atomic_commit_tail+0x1fb/0x1930
[amdgpu]
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x40/0x70
Apr 19 15:06:40 endless kernel:  ? __switch_to_xtra+0x3b8/0x5b0
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? ttm_bo_mem_compat+0x28/0x60 [ttm]
Apr 19 15:06:40 endless kernel:  ? ttm_bo_validate+0x3d/0x130 [ttm]
Apr 19 15:06:40 endless kernel:  ? __switch_to+0x48b/0x4f0
Apr 19 15:06:40 endless kernel:  ? __switch_to_asm+0x34/0x70
Apr 19 15:06:40 endless kernel:  ? __schedule+0x2dc/0x840
Apr 19 15:06:40 endless kernel:  ? amdgpu_bo_pin_restricted+0x1a2/0x270
[amdgpu]
Apr 19 15:06:40 endless kernel:  ? _cond_resched+0x19/0x30
Apr 19 15:06:40 endless kernel:  ? wait_for_completion_timeout+0x38/0x140
Apr 19 15:06:40 endless kernel:  ? _cond_resched+0x19/0x30
Apr 19 15:06:40 endless kernel:  ? wait_for_completion_interruptible+0x35/0x1a0
Apr 19 15:06:40 endless kernel:  commit_tail+0x42/0x70 [drm_kms_helper]
Apr 19 15:06:40 endless kernel:  ? commit_tail+0x42/0x70 [drm_kms_helper]
Apr 19 15:06:40 endless kernel:  drm_atomic_helper_commit+0x113/0x120
[drm_kms_helper]
Apr 19 15:06:40 endless kernel:  amdgpu_dm_atomic_commit+0x9b/0xe0 [amdgpu]
Apr 19 15:06:40 endless kernel:  drm_atomic_commit+0x4a/0x50 [drm]
Apr 19 15:06:40 endless kernel:  drm_atomic_helper_set_config+0x87/0x90
[drm_kms_helper]
Apr 19 15:06:40 endless kernel:  drm_mode_setcrtc+0x1bb/0x740 [drm]
Apr 19 15:06:40 endless kernel:  ? drm_is_current_master+0x1f/0x40 [drm]
Apr 19 15:06:40 endless kernel:  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
Apr 19 15:06:40 endless kernel:  drm_ioctl_kernel+0xb0/0x100 [drm]
Apr 19 15:06:40 endless kernel:  drm_ioctl+0x233/0x410 [drm]
Apr 19 15:06:40 endless kernel:  ? drm_mode_getcrtc+0x1a0/0x1a0 [drm]
Apr 19 15:06:40 endless kernel:  amdgpu_drm_ioctl+0x4f/0x80 [amdgpu]
Apr 19 15:06:40 endless kernel:  do_vfs_ioctl+0xa9/0x640
Apr 19 15:06:40 endless kernel:  ? tomoyo_file_ioctl+0x19/0x20
Apr 19 15:06:40 endless kernel:  ksys_ioctl+0x67/0x90
Apr 19 15:06:40 endless kernel:  __x64_sys_ioctl+0x1a/0x20
Apr 

Re: [patch V2 28/29] stacktrace: Provide common infrastructure

[Peter Zijlstra]

On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:

> +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> +  bool reliable);

> +void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
> +  struct task_struct *task, struct pt_regs *regs);
> +int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry, void 
> *cookie,
> +  struct task_struct *task);

This bugs me a little; ideally the _reliable() thing would not exists.

Thomas said that the existing __save_stack_trace_reliable() is different
enough for the unification to be non-trivial, but maybe Josh can help
out?

From what I can see the biggest significant differences are:

 - it looks at the regs sets on the stack and for FP bails early
 - bails for khreads and idle (after it does all the hard work!?!)

The first (FP checking for exceptions) should probably be reflected in
consume_fn(.reliable) anyway -- although that would mean a lot of extra
'?' entries where there are none today.

And the second (KTHREAD/IDLE) is something that the generic code can
easily do before calling into the arch unwinder.

Hmm?

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

Re: [PATCH 1/2] arm64: dts: mt8183: add dsi node

[CK Hu]

Hi, Jitao:

On Tue, 2019-04-16 at 16:54 +0800, Jitao Shi wrote:
> Add dsi and mipitx nodes to the mt8183
> 
> Signed-off-by: Jitao Shi 
> ---
>  arch/arm64/boot/dts/mediatek/mt8183.dtsi | 25 
>  1 file changed, 25 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8183.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> index b36e37fcdfe3..80929a0e5a6f 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8183.dtsi
> @@ -353,6 +353,16 @@
>   status = "disabled";
>   };
>  
> + mipi_tx0: mipi-dphy@11e5 {
> + compatible = "mediatek,mt8183-mipi-tx";
> + reg = <0 0x11e5 0 0x1000>;
> + clocks = <&apmixedsys CLK_APMIXED_MIPID0_26M>;
> + clock-names = "ref_clk";
> + #clock-cells = <0>;
> + #phy-cells = <0>;
> + clock-output-names = "mipi_tx0_pll";
> + };
> +
>   mfgcfg: syscon@1300 {
>   compatible = "mediatek,mt8183-mfgcfg", "syscon";
>   reg = <0 0x1300 0 0x1000>;
> @@ -365,6 +375,21 @@
>   #clock-cells = <1>;
>   };
>  
> + dsi0: dsi@14014000 {
> + compatible = "mediatek,mt8173-dsi",
> + "mediatek,mt8183-dsi";

I think you could directly remove "mediatek,mt8173-dsi".

Regards,
CK

> + reg = <0 0x14014000 0 0x1000>;
> + interrupts = ;
> + power-domains = <&scpsys MT8183_POWER_DOMAIN_DISP>;
> + mediatek,syscon-dsi = <&mmsys 0x140>;
> + clocks = <&mmsys CLK_MM_DSI0_MM>,
> + <&mmsys CLK_MM_DSI0_IF>,
> + <&mipi_tx0>;
> + clock-names = "engine", "digital", "hs";
> + phys = <&mipi_tx0>;
> + phy-names = "dphy";
> + };
> +
>   smi_common: smi@14019000 {
>   compatible = "mediatek,mt8183-smi-common", "syscon";
>   reg = <0 0x14019000 0 0x1000>;


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

[PATCH v1 0/2] drm/komeda: Add rotation support on Komeda driver

[Lowry Li (Arm Technology China)]

Hi,

This serie aims at adding the support for rotation on Komeda driver.
This patch series depends on:
- https://patchwork.freedesktop.org/series/54449/
- https://patchwork.freedesktop.org/series/54450/
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
- https://patchwork.freedesktop.org/series/59002/
- https://patchwork.freedesktop.org/series/59471/

Regards,
Lowry

Lowry Li (Arm Technology China) (2):
  drm/komeda: Add rotation support on Komeda driver
  drm/komeda: Adds limitation check for AFBC wide block not support
Rot90

 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c  | 15 +++
 .../gpu/drm/arm/display/komeda/komeda_format_caps.c   |  7 ++-
 .../gpu/drm/arm/display/komeda/komeda_format_caps.h   | 19 ++-
 .../gpu/drm/arm/display/komeda/komeda_framebuffer.c   | 18 +-
 .../gpu/drm/arm/display/komeda/komeda_framebuffer.h   |  5 +++--
 .../drm/arm/display/komeda/komeda_pipeline_state.c| 15 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 18 +-
 7 files changed, 82 insertions(+), 15 deletions(-)

-- 
1.9.1

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

[PATCH v1 2/2] drm/komeda: Adds limitation check for AFBC wide block not support Rot90

[Lowry Li (Arm Technology China)]

Komeda series hardware doesn't support Rot90 for AFBC wide block. So
add limitation check to reject it if such configuration has been posted.

Signed-off-by: Lowry Li (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c   | 15 +++
 .../gpu/drm/arm/display/komeda/komeda_format_caps.c|  7 ++-
 .../gpu/drm/arm/display/komeda/komeda_format_caps.h|  8 +++-
 .../gpu/drm/arm/display/komeda/komeda_framebuffer.c| 18 +-
 .../gpu/drm/arm/display/komeda/komeda_framebuffer.h|  5 +++--
 .../gpu/drm/arm/display/komeda/komeda_pipeline_state.c |  8 +++-
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c  |  2 +-
 7 files changed, 48 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c 
b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
index 34506ef..9603de9 100644
--- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
+++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
@@ -494,11 +494,26 @@ static int d71_enum_resources(struct komeda_dev *mdev)
{__HW_ID(6, 7), 0/*DRM_FORMAT_YUV420_10BIT*/, 1,RICH,   
Rot_ALL_H_V,LYT_NM, AFB_TH},
 };
 
+static bool d71_format_mod_supported(const struct komeda_format_caps *caps,
+u32 layer_type, u64 modifier, u32 rot)
+{
+   uint64_t layout = modifier & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK;
+
+   if ((layout == AFBC_FORMAT_MOD_BLOCK_SIZE_32x8) &&
+   drm_rotation_90_or_270(rot)) {
+   DRM_DEBUG_ATOMIC("D71 doesn't support ROT90 for WB-AFBC.\n");
+   return false;
+   }
+
+   return true;
+}
+
 static void d71_init_fmt_tbl(struct komeda_dev *mdev)
 {
struct komeda_format_caps_table *table = &mdev->fmt_tbl;
 
table->format_caps = d71_format_caps_table;
+   table->format_mod_supported = d71_format_mod_supported;
table->n_formats = ARRAY_SIZE(d71_format_caps_table);
 }
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
index b219514..cd4d9f5 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.c
@@ -74,7 +74,8 @@
 };
 
 bool komeda_format_mod_supported(struct komeda_format_caps_table *table,
-u32 layer_type, u32 fourcc, u64 modifier)
+u32 layer_type, u32 fourcc, u64 modifier,
+u32 rot)
 {
const struct komeda_format_caps *caps;
 
@@ -85,6 +86,10 @@ bool komeda_format_mod_supported(struct 
komeda_format_caps_table *table,
if (!(caps->supported_layer_types & layer_type))
return false;
 
+   if (table->format_mod_supported)
+   return table->format_mod_supported(caps, layer_type, modifier,
+  rot);
+
return true;
 }
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
index 96de22e..381e873 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
@@ -71,10 +71,15 @@ struct komeda_format_caps {
  *
  * @n_formats: the size of format_caps list.
  * @format_caps: format_caps list.
+ * @format_mod_supported: Optional. Some HW may have special requirements or
+ * limitations which can not be described by format_caps, this func supply HW
+ * the ability to do the further HW specific check.
  */
 struct komeda_format_caps_table {
u32 n_formats;
const struct komeda_format_caps *format_caps;
+   bool (*format_mod_supported)(const struct komeda_format_caps *caps,
+u32 layer_type, u64 modifier, u32 rot);
 };
 
 extern u64 komeda_supported_modifiers[];
@@ -100,6 +105,7 @@ u32 *komeda_get_layer_fourcc_list(struct 
komeda_format_caps_table *table,
 void komeda_put_fourcc_list(u32 *fourcc_list);
 
 bool komeda_format_mod_supported(struct komeda_format_caps_table *table,
-u32 layer_type, u32 fourcc, u64 modifier);
+u32 layer_type, u32 fourcc, u64 modifier,
+u32 rot);
 
 #endif
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
index f842c88..d5822a3 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c
@@ -239,20 +239,20 @@ struct drm_framebuffer *
 }
 
 /* if the fb can be supported by a specific layer */
-bool komeda_fb_is_layer_supported(struct komeda_fb *kfb, u32 layer_type)
+bool komeda_fb_is_layer_supported(struct komeda_fb *kfb, u32 layer_type,
+ u32 rot)
 {
struct drm_framebuffer *fb = &kfb->base;
struct kom

[PATCH v1 1/2] drm/komeda: Add rotation support on Komeda driver

[Lowry Li (Arm Technology China)]

- Adds rotation property to plane.
- Komeda display rotation support diverges from the specific formats,
so need to check the user required rotation type with the format caps
and reject the commit if it can not be supported.
- In the layer validate flow, sets the rotation value to the layer
state. If r90 or r270, swap the width and height of the data flow
for next stage.

Signed-off-by: Lowry Li (Arm Technology China) 
---
 drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h  | 11 +++
 .../gpu/drm/arm/display/komeda/komeda_pipeline_state.c   |  7 +++
 drivers/gpu/drm/arm/display/komeda/komeda_plane.c| 16 
 3 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
index bc3b2df36..96de22e 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_format_caps.h
@@ -79,6 +79,17 @@ struct komeda_format_caps_table {
 
 extern u64 komeda_supported_modifiers[];
 
+static inline const char *komeda_get_format_name(u32 fourcc, u64 modifier)
+{
+   struct drm_format_name_buf buf;
+   static char name[64];
+
+   snprintf(name, sizeof(name), "%s with modifier: 0x%llx.",
+drm_get_format_name(fourcc, &buf), modifier);
+
+   return name;
+}
+
 const struct komeda_format_caps *
 komeda_get_format_caps(struct komeda_format_caps_table *table,
   u32 fourcc, u64 modifier);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
index 9b29e9a..8c133e4 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
@@ -317,6 +317,13 @@ struct komeda_pipeline_state *
/* update the data flow for the next stage */
komeda_component_set_output(&dflow->input, &layer->base, 0);
 
+   /*
+* The rotation has been handled by layer, so adjusted the data flow for
+* the next stage.
+*/
+   if (drm_rotation_90_or_270(st->rot))
+   swap(dflow->in_h, dflow->in_w);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
index 14d6861..5e5bfdb 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_plane.c
@@ -9,12 +9,14 @@
 #include 
 #include "komeda_dev.h"
 #include "komeda_kms.h"
+#include "komeda_framebuffer.h"
 
 static int
 komeda_plane_init_data_flow(struct drm_plane_state *st,
struct komeda_data_flow_cfg *dflow)
 {
struct drm_framebuffer *fb = st->fb;
+   const struct komeda_format_caps *caps = to_kfb(fb)->format_caps;
 
memset(dflow, 0, sizeof(*dflow));
 
@@ -35,6 +37,15 @@
dflow->in_w = st->src_w >> 16;
dflow->in_h = st->src_h >> 16;
 
+   dflow->rot = drm_rotation_simplify(st->rotation, caps->supported_rots);
+   if (!has_bits(dflow->rot, caps->supported_rots)) {
+   DRM_DEBUG_ATOMIC("rotation(0x%x) isn't supported by %s.\n",
+dflow->rot,
+komeda_get_format_name(caps->fourcc,
+   fb->modifier));
+   return -EINVAL;
+   }
+
return 0;
 }
 
@@ -233,6 +244,11 @@ static int komeda_plane_add(struct komeda_kms_dev *kms,
 
drm_plane_helper_add(plane, &komeda_plane_helper_funcs);
 
+   err = drm_plane_create_rotation_property(plane, DRM_MODE_ROTATE_0,
+layer->supported_rots);
+   if (err)
+   goto cleanup;
+
err = drm_plane_create_alpha_property(plane);
if (err)
goto cleanup;
-- 
1.9.1

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

[PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Paul Kocialkowski]

Our components may still be using the DRM device driver (if only to
access our driver's private data), so make sure to unbind them before
the final drm_dev_put.

Also release our resserved memory adter unbind to match reverse
creation order.

Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master 
deletion")
Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
b/drivers/gpu/drm/sun4i/sun4i_drv.c
index 843b86661833..29258b404e54 100644
--- a/drivers/gpu/drm/sun4i/sun4i_drv.c
+++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
@@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
drm_kms_helper_poll_fini(drm);
drm_atomic_helper_shutdown(drm);
drm_mode_config_cleanup(drm);
-   of_reserved_mem_device_release(dev);
-   drm_dev_put(drm);
 
component_unbind_all(dev, NULL);
+   of_reserved_mem_device_release(dev);
+
+   drm_dev_put(drm);
 }
 
 static const struct component_master_ops sun4i_drv_master_ops = {
-- 
2.21.0

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

[Bug 46711] Monitor not turning on after DisplayPort re-plug in Xorg

[bugzilla-daemon]

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

--- Comment #25 from FiNeX  ---
Same problem here.

I'm using latest Linux Kernel (5.0.7) on Arch Linux, with Nvidia drivers
418.56-7, Xorg 1.20.4.

Hardware:
- GPU: NVIDIA GK106 [GeForce GTX 660]
- Mobo: Asus Z87-PRO
- Display: 2x Acer BE270U (DP with daisy chain), 1x DELL 2209WA (DVI)

The xrandr output is:

Screen 0: minimum 8 x 8, current 6170 x 1680, maximum 16384 x 16384
DVI-I-0 disconnected primary (normal left inverted right x axis y axis)
DP-1.8 connected 2560x1440+1050+0 (normal left inverted right x axis y axis)
597mm x 336mm
   2560x1440 74.92*+  59.95  
   1920x1080 60.0059.9450.00  
   1680x1050 59.95  
   1440x900  59.89  
   1280x1024 75.0260.02  
   1280x960  60.00  
   1280x720  60.0059.9450.00  
   1024x768  75.0370.0760.00  
   800x600   75.0072.1960.3256.25  
   720x576   50.00  
   720x480   59.94  
   640x480   75.0072.8159.9459.93  
DP-1.1.8 connected 2560x1440+3610+0 (normal left inverted right x axis y axis)
597mm x 336mm
   2560x1440 74.92*+  59.95  
   1920x1080 60.0059.9450.00  
   1680x1050 59.95  
   1440x900  59.89  
   1280x1024 75.0260.02  
   1280x960  60.00  
   1280x720  60.0059.9450.00  
   1024x768  75.0370.0760.00  
   800x600   75.0072.1960.3256.25  
   720x576   50.00  
   720x480   59.94  
   640x480   75.0072.8159.9459.93  
DVI-I-1 connected 1050x1680+0+0 left (normal left inverted right x axis y axis)
474mm x 296mm
   1680x1050 59.95*+
   1280x1024 75.0260.02  
   1152x864  75.00  
   1024x768  75.0360.00  
   800x600   75.0060.32  
   640x480   75.0059.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)
DP-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)

-- 
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: Support for 2D engines/blitters in V4L2 and DRM

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 20:30 -0400, Nicolas Dufresne wrote:
> Le jeudi 18 avril 2019 à 10:18 +0200, Daniel Vetter a écrit :
> > > It would be cool if both could be used concurrently and not just return
> > > -EBUSY when the device is used with the other subsystem.
> > 
> > We live in this world already :-) I think there's even patches (or merged
> > already) to add fences to v4l, for Android.
> 
> This work is currently suspended. It will require some feature on DRM
> display to really make this useful, but there is also a lot of
> challanges in V4L2. In GFX space, most of the use case are about
> rendering as soon as possible. Though, in multimedia we have two
> problems, we need to synchronize the frame rendering with the audio,
> and output buffers may comes out of order due to how video CODECs are
> made.

Definitely, it feels like the DRM display side is currently a good fit
for render use cases, but not so much for precise display cases where
we want to try and display a buffer at a given vblank target instead of
"as soon as possible".

I have a userspace project where I've implemented a page flip queue,
which only schedules the next flip when relevant and keeps ready
buffers in the queue until then. This requires explicit vblank
syncronisation (which DRM offsers, but pretty much all other display
APIs, that are higher-level don't, so I'm just using a refresh-rate
timer for them) and flip done notification.

I haven't looked too much at how to flip with a target vblank with DRM
directly but maybe the atomic API already has the bits in for that (but
I haven't heard of such a thing as a buffer queue, so that makes me
doubt it). Well, I need to handle stuff like SDL in my userspace
project, so I have to have all that queuing stuff in software anyway,
but it would be good if each project didn't have to implement that.
Worst case, it could be in libdrm too.

> In the first, we'd need a mechanism where we can schedule a render at a
> specific time or vblank. We can of course already implement this in
> software, but with fences, the scheduling would need to be done in the
> driver. Then if the fence is signalled earlier, the driver should hold
> on until the delay is met. If the fence got signalled late, we also
> need to think of a workflow. As we can't schedule more then one render
> in DRM at one time, I don't really see yet how to make that work.

Indeed, that's also one of the main issues I've spotted. Before using
an implicit fence, we basically have to make sure the frame is due for
display at the next vblank. Otherwise, we need to refrain from using
the fence and schedule the flip later, which is kind of counter-
productive.

So maybe adding this queue in DRM directly would make everyone's life
much easier for non-render applications.

I feel like specifying a target vblank would be a good unit for that,
since it's our native granularity after all (while a timestamp is not).

> For the second, it's complicated on V4L2 side. Currently we signal
> buffers when they are ready in the display order. With fences, we
> receive early pairs buffer and fence (in decoding order). There exist
> cases where reordering is done by the driver (stateful CODEC). We
> cannot schedule these immediately we would need a new mechanism to know
> which one come next. If we just reuse current mechnism, it would void
> the fence usage since the fence will always be signalled by the time it
> reaches DRM or other v4l2 component.

Well, our v4l2 buffers do have a timestamp and fences expose it too, so
we'd need DRM to convert that to a target vblank and add it to the
internal queue mentioned above. That seems doable.

I think we only gave a vague meaning to the v4l2 timestamp for the
decoding case and it could be any number, the timestamp when submitting
decoding or the target timestamp for the frame. I think we should aim
for the latter, but not sure it's always doable to know beforehand.
Perhaps you have a clear idea of this?

> There also other issues, for video capture pipeline, if you are not
> rendering ASAP, you need the HW timestamp in order to schedule. Again,
> we'd get the fence early, but the actual timestamp will be signalled at
> the very last minutes, so we also risk of turning the fence into pure
> overhead. Note that as we speak, I have colleagues who are
> experimenting with frame timestamp prediction that slaves to the
> effective timestamp (catching up over time). But we still have issues
> when the capture driver skipped a frame (missed a capture window).
> 
> I hope this is useful reflection data,

It is definitely very useful and there seems to be a few things that
could be improved already without too much effort.

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 1/4] drm/v3d: Fix debugfs reads of MMU regs.

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 17:10 -0700, Eric Anholt wrote:
> They're in the hub, not the individual cores.

Although I don't have docs to check, looks sane:

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/v3d/v3d_debugfs.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index a2dc4262955e..356a8acfa72d 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -26,6 +26,10 @@ static const struct v3d_reg_def v3d_hub_reg_defs[] = {
>   REGDEF(V3D_HUB_IDENT3),
>   REGDEF(V3D_HUB_INT_STS),
>   REGDEF(V3D_HUB_INT_MSK_STS),
> +
> + REGDEF(V3D_MMU_CTL),
> + REGDEF(V3D_MMU_VIO_ADDR),
> + REGDEF(V3D_MMU_VIO_ID),
>  };
>  
>  static const struct v3d_reg_def v3d_gca_reg_defs[] = {
> @@ -50,9 +54,6 @@ static const struct v3d_reg_def v3d_core_reg_defs[] = {
>   REGDEF(V3D_PTB_BPCA),
>   REGDEF(V3D_PTB_BPCS),
>  
> - REGDEF(V3D_MMU_CTL),
> - REGDEF(V3D_MMU_VIO_ADDR),
> -
>   REGDEF(V3D_GMP_STATUS),
>   REGDEF(V3D_GMP_CFG),
>   REGDEF(V3D_GMP_VIO_ADDR),
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 2/4] drm/v3d: Set the correct DMA mask according to the MMU's limits.

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 17:10 -0700, Eric Anholt wrote:
> On 7278, we've got 40 bits to work with.

Although I don't have docs to check, looks sane:

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/v3d/v3d_debugfs.c | 1 +
>  drivers/gpu/drm/v3d/v3d_drv.c | 6 +-
>  drivers/gpu/drm/v3d/v3d_regs.h| 8 
>  3 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index 356a8acfa72d..ab652a034959 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -30,6 +30,7 @@ static const struct v3d_reg_def v3d_hub_reg_defs[] = {
>   REGDEF(V3D_MMU_CTL),
>   REGDEF(V3D_MMU_VIO_ADDR),
>   REGDEF(V3D_MMU_VIO_ID),
> + REGDEF(V3D_MMU_DEBUG_INFO),
>  };
>  
>  static const struct v3d_reg_def v3d_gca_reg_defs[] = {
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index f8d1d2569c1f..7ab36192e6bc 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -472,9 +472,9 @@ static int v3d_platform_drm_probe(struct platform_device 
> *pdev)
>   struct drm_device *drm;
>   struct v3d_dev *v3d;
>   int ret;
> + u32 mmu_debug;
>   u32 ident1;
>  
> - dev->coherent_dma_mask = DMA_BIT_MASK(36);
>  
>   v3d = kzalloc(sizeof(*v3d), GFP_KERNEL);
>   if (!v3d)
> @@ -491,6 +491,10 @@ static int v3d_platform_drm_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto dev_free;
>  
> + mmu_debug = V3D_READ(V3D_MMU_DEBUG_INFO);
> + dev->coherent_dma_mask =
> + DMA_BIT_MASK(30 + V3D_GET_FIELD(mmu_debug, V3D_MMU_PA_WIDTH));
> +
>   ident1 = V3D_READ(V3D_HUB_IDENT1);
>   v3d->ver = (V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_TVER) * 10 +
>   V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_REV));
> diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
> index 9a8ff0ce648e..54c8c4320da0 100644
> --- a/drivers/gpu/drm/v3d/v3d_regs.h
> +++ b/drivers/gpu/drm/v3d/v3d_regs.h
> @@ -191,6 +191,14 @@
>  /* Address that faulted */
>  #define V3D_MMU_VIO_ADDR   0x01234
>  
> +#define V3D_MMU_DEBUG_INFO 0x01238
> +# define V3D_MMU_PA_WIDTH_MASK V3D_MASK(11, 8)
> +# define V3D_MMU_PA_WIDTH_SHIFT8
> +# define V3D_MMU_VA_WIDTH_MASK V3D_MASK(7, 4)
> +# define V3D_MMU_VA_WIDTH_SHIFT4
> +# define V3D_MMU_VERSION_MASK  V3D_MASK(3, 0)
> +# define V3D_MMU_VERSION_SHIFT 0
> +
>  /* Per-V3D-core registers */
>  
>  #define V3D_CTL_IDENT0 0x0
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 3/4] drm/v3d: Dump V3D error debug registers in debugfs, and one at reset.

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 17:10 -0700, Eric Anholt wrote:
> Looking at a hang recently, I noticed these registers that might tell
> me if something obvious was wrong.  They didn't help in this case, but
> keep it around for the future.

Although I don't have docs to check, looks sane:

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/v3d/v3d_debugfs.c |  5 
>  drivers/gpu/drm/v3d/v3d_gem.c |  4 +++-
>  drivers/gpu/drm/v3d/v3d_regs.h| 38 +++
>  3 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c 
> b/drivers/gpu/drm/v3d/v3d_debugfs.c
> index ab652a034959..78a78938e81f 100644
> --- a/drivers/gpu/drm/v3d/v3d_debugfs.c
> +++ b/drivers/gpu/drm/v3d/v3d_debugfs.c
> @@ -58,6 +58,11 @@ static const struct v3d_reg_def v3d_core_reg_defs[] = {
>   REGDEF(V3D_GMP_STATUS),
>   REGDEF(V3D_GMP_CFG),
>   REGDEF(V3D_GMP_VIO_ADDR),
> +
> + REGDEF(V3D_ERR_FDBGO),
> + REGDEF(V3D_ERR_FDBGB),
> + REGDEF(V3D_ERR_FDBGS),
> + REGDEF(V3D_ERR_STAT),
>  };
>  
>  static const struct v3d_reg_def v3d_csd_reg_defs[] = {
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> index f736e021467a..27e0f87075d9 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -109,7 +109,9 @@ v3d_reset(struct v3d_dev *v3d)
>  {
>   struct drm_device *dev = &v3d->drm;
>  
> - DRM_ERROR("Resetting GPU.\n");
> + DRM_DEV_ERROR(dev->dev, "Resetting GPU for hang.\n");
> + DRM_DEV_ERROR(dev->dev, "V3D_ERR_STAT: 0x%08x\n",
> +   V3D_CORE_READ(0, V3D_ERR_STAT));
>   trace_v3d_reset_begin(dev);
>  
>   /* XXX: only needed for safe powerdown, not reset. */
> diff --git a/drivers/gpu/drm/v3d/v3d_regs.h b/drivers/gpu/drm/v3d/v3d_regs.h
> index 54c8c4320da0..eda1e289976f 100644
> --- a/drivers/gpu/drm/v3d/v3d_regs.h
> +++ b/drivers/gpu/drm/v3d/v3d_regs.h
> @@ -455,4 +455,42 @@
>  # define V3D_CSD_CURRENT_ID0_WG_Y_MASK V3D_MASK(15, 0)
>  # define V3D_CSD_CURRENT_ID0_WG_Y_SHIFT0
>  
> +#define V3D_ERR_FDBGO  0x00f04
> +#define V3D_ERR_FDBGB  0x00f08
> +#define V3D_ERR_FDBGR  0x00f0c
> +
> +#define V3D_ERR_FDBGS  0x00f10
> +# define V3D_ERR_FDBGS_INTERPZ_IP_STALLBIT(17)
> +# define V3D_ERR_FDBGS_DEPTHO_FIFO_IP_STALLBIT(16)
> +# define V3D_ERR_FDBGS_XYNRM_IP_STALL  BIT(14)
> +# define V3D_ERR_FDBGS_EZREQ_FIFO_OP_VALID BIT(13)
> +# define V3D_ERR_FDBGS_QXYF_FIFO_OP_VALID  BIT(12)
> +# define V3D_ERR_FDBGS_QXYF_FIFO_OP_LAST   BIT(11)
> +# define V3D_ERR_FDBGS_EZTEST_ANYQVALIDBIT(7)
> +# define V3D_ERR_FDBGS_EZTEST_PASS BIT(6)
> +# define V3D_ERR_FDBGS_EZTEST_QREADY   BIT(5)
> +# define V3D_ERR_FDBGS_EZTEST_VLF_OKNOVALIDBIT(4)
> +# define V3D_ERR_FDBGS_EZTEST_QSTALL   BIT(3)
> +# define V3D_ERR_FDBGS_EZTEST_IP_VLFSTALL  BIT(2)
> +# define V3D_ERR_FDBGS_EZTEST_IP_PRSTALL   BIT(1)
> +# define V3D_ERR_FDBGS_EZTEST_IP_QSTALLBIT(0)
> +
> +#define V3D_ERR_STAT   0x00f20
> +# define V3D_ERR_L2CAREBIT(15)
> +# define V3D_ERR_VCMBE BIT(14)
> +# define V3D_ERR_VCMRE BIT(13)
> +# define V3D_ERR_VCDI  BIT(12)
> +# define V3D_ERR_VCDE  BIT(11)
> +# define V3D_ERR_VDWE  BIT(10)
> +# define V3D_ERR_VPMEASBIT(9)
> +# define V3D_ERR_VPMEFNA   BIT(8)
> +# define V3D_ERR_VPMEWNA   BIT(7)
> +# define V3D_ERR_VPMERNA   BIT(6)
> +# define V3D_ERR_VPMERRBIT(5)
> +# define V3D_ERR_VPMEWRBIT(4)
> +# define V3D_ERR_VPAERRGL  BIT(3)
> +# define V3D_ERR_VPAEBRGL  BIT(2)
> +# define V3D_ERR_VPAERGS   BIT(1)
> +# define V3D_ERR_VPAEABB   BIT(0)
> +
>  #endif /* V3D_REGS_H */
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 4/4] drm/v3d: Fix and extend MMU error handling.

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 17:10 -0700, Eric Anholt wrote:
> We were setting the wrong flags to enable PTI errors, so we were
> seeing reads to invalid PTEs show up as write errors.  Also, we
> weren't turning on the interrupts.  The AXI IDs we were dumping
> included the outstanding write number and so they looked basically
> random.  And the VIO_ADDR decoding was based on the MMU VA_WIDTH for
> the first platform I worked on and was wrong on others.  In short,
> this was a thorough mess from early HW enabling.
> 
> Tested on V3D 4.1 and 4.2 with intentional L2T, CLE, PTB, and TLB
> faults.

Didn't check the docs but looks sane too!

Reviewed-by: Paul Kocialkowski 

Cheers,

Paul

> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/v3d/v3d_drv.c  |  1 +
>  drivers/gpu/drm/v3d/v3d_drv.h  |  2 ++
>  drivers/gpu/drm/v3d/v3d_irq.c  | 31 +++
>  drivers/gpu/drm/v3d/v3d_mmu.c  |  7 +--
>  drivers/gpu/drm/v3d/v3d_regs.h |  3 ++-
>  5 files changed, 37 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
> index 7ab36192e6bc..9ce2e4ef6c2a 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.c
> +++ b/drivers/gpu/drm/v3d/v3d_drv.c
> @@ -494,6 +494,7 @@ static int v3d_platform_drm_probe(struct platform_device 
> *pdev)
>   mmu_debug = V3D_READ(V3D_MMU_DEBUG_INFO);
>   dev->coherent_dma_mask =
>   DMA_BIT_MASK(30 + V3D_GET_FIELD(mmu_debug, V3D_MMU_PA_WIDTH));
> + v3d->va_width = 30 + V3D_GET_FIELD(mmu_debug, V3D_MMU_VA_WIDTH);
>  
>   ident1 = V3D_READ(V3D_HUB_IDENT1);
>   v3d->ver = (V3D_GET_FIELD(ident1, V3D_HUB_IDENT1_TVER) * 10 +
> diff --git a/drivers/gpu/drm/v3d/v3d_drv.h b/drivers/gpu/drm/v3d/v3d_drv.h
> index 6d31a6a5a08e..64682923018d 100644
> --- a/drivers/gpu/drm/v3d/v3d_drv.h
> +++ b/drivers/gpu/drm/v3d/v3d_drv.h
> @@ -63,6 +63,8 @@ struct v3d_dev {
>*/
>   void *mmu_scratch;
>   dma_addr_t mmu_scratch_paddr;
> + /* virtual address bits from V3D to the MMU. */
> + int va_width;
>  
>   /* Number of V3D cores. */
>   u32 cores;
> diff --git a/drivers/gpu/drm/v3d/v3d_irq.c b/drivers/gpu/drm/v3d/v3d_irq.c
> index fac3c542860b..268d8a889ac5 100644
> --- a/drivers/gpu/drm/v3d/v3d_irq.c
> +++ b/drivers/gpu/drm/v3d/v3d_irq.c
> @@ -162,10 +162,33 @@ v3d_hub_irq(int irq, void *arg)
> V3D_HUB_INT_MMU_PTI |
> V3D_HUB_INT_MMU_CAP)) {
>   u32 axi_id = V3D_READ(V3D_MMU_VIO_ID);
> - u64 vio_addr = (u64)V3D_READ(V3D_MMU_VIO_ADDR) << 8;
> -
> - dev_err(v3d->dev, "MMU error from client %d at 
> 0x%08llx%s%s%s\n",
> - axi_id, (long long)vio_addr,
> + u64 vio_addr = ((u64)V3D_READ(V3D_MMU_VIO_ADDR) <<
> + (v3d->va_width - 32));
> + static const char *const v3d41_axi_ids[] = {
> + "L2T",
> + "PTB",
> + "PSE",
> + "TLB",
> + "CLE",
> + "TFU",
> + "MMU",
> + "GMP",
> + };
> + const char *client = "?";
> +
> + V3D_WRITE(V3D_MMU_CTL,
> +   V3D_READ(V3D_MMU_CTL) & (V3D_MMU_CTL_CAP_EXCEEDED |
> +V3D_MMU_CTL_PT_INVALID |
> +
> V3D_MMU_CTL_WRITE_VIOLATION));
> +
> + if (v3d->ver >= 41) {
> + axi_id = axi_id >> 5;
> + if (axi_id < ARRAY_SIZE(v3d41_axi_ids))
> + client = v3d41_axi_ids[axi_id];
> + }
> +
> + dev_err(v3d->dev, "MMU error from client %s (%d) at 
> 0x%llx%s%s%s\n",
> + client, axi_id, (long long)vio_addr,
>   ((intsts & V3D_HUB_INT_MMU_WRV) ?
>", write violation" : ""),
>   ((intsts & V3D_HUB_INT_MMU_PTI) ?
> diff --git a/drivers/gpu/drm/v3d/v3d_mmu.c b/drivers/gpu/drm/v3d/v3d_mmu.c
> index 7a21f1787ab1..395e81d97163 100644
> --- a/drivers/gpu/drm/v3d/v3d_mmu.c
> +++ b/drivers/gpu/drm/v3d/v3d_mmu.c
> @@ -69,10 +69,13 @@ int v3d_mmu_set_page_table(struct v3d_dev *v3d)
>   V3D_WRITE(V3D_MMU_PT_PA_BASE, v3d->pt_paddr >> V3D_MMU_PAGE_SHIFT);
>   V3D_WRITE(V3D_MMU_CTL,
> V3D_MMU_CTL_ENABLE |
> -   V3D_MMU_CTL_PT_INVALID |
> +   V3D_MMU_CTL_PT_INVALID_ENABLE |
> V3D_MMU_CTL_PT_INVALID_ABORT |
> +   V3D_MMU_CTL_PT_INVALID_INT |
> V3D_MMU_CTL_WRITE_VIOLATION_ABORT |
> -   V3D_MMU_CTL_CAP_EXCEEDED_ABORT);
> +   V3D_MMU_CTL_WRITE_VIOLATION_INT |
> +   V3D_MMU_CTL_CAP_EXCEEDED_ABORT |
> +   V3D_MMU_CTL_CAP_EXCEEDED_INT);
>   V3D_WRITE(V3D_MMU_ILLEGAL_ADDR,
> (v3d->mmu_scratch_paddr >> V3D_MMU_PAGE_

Re: [PATCH v3 3/6] drm/modes: Allow to specify rotation and reflection on the commandline

[Noralf Trønnes]

Den 18.04.2019 18.40, skrev Noralf Trønnes:
> 
> 
> Den 18.04.2019 14.41, skrev Maxime Ripard:
>> Rotations and reflections setup are needed in some scenarios to initialise
>> properly the initial framebuffer. Some drivers already had a bunch of
>> quirks to deal with this, such as either a private kernel command line
>> parameter (omapdss) or on the device tree (various panels).
>>
>> In order to accomodate this, let's create a video mode parameter to deal
>> with the rotation and reflexion.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  drivers/gpu/drm/drm_client_modeset.c |  10 +++-
>>  drivers/gpu/drm/drm_modes.c  | 110 ++--
>>  include/drm/drm_connector.h  |   9 ++-
>>  3 files changed, 109 insertions(+), 20 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_client_modeset.c 
>> b/drivers/gpu/drm/drm_client_modeset.c
>> index f2869c82510c..15145d2c86d5 100644
>> --- a/drivers/gpu/drm/drm_client_modeset.c
>> +++ b/drivers/gpu/drm/drm_client_modeset.c
>> @@ -823,6 +823,7 @@ EXPORT_SYMBOL(drm_client_modeset_probe);
>>  bool drm_client_panel_rotation(struct drm_mode_set *modeset, unsigned int 
>> *rotation)
>>  {
>>  struct drm_connector *connector = modeset->connectors[0];
>> +struct drm_cmdline_mode *cmdline;
>>  struct drm_plane *plane = modeset->crtc->primary;
>>  u64 valid_mask = 0;
>>  unsigned int i;
>> @@ -844,6 +845,15 @@ bool drm_client_panel_rotation(struct drm_mode_set 
>> *modeset, unsigned int *rotat
>>  *rotation = DRM_MODE_ROTATE_0;
>>  }
>>  
>> +/**
>> + * We want the rotation on the command line to overwrite
>> + * whatever comes from the panel.
>> + */
>> +cmdline = &connector->cmdline_mode;
>> +if (cmdline->specified &&
>> +cmdline->rotation != DRM_MODE_ROTATE_0)
> 
> I believe you need to drop that second check, otherwise rotate=0 will
> not overwrite panel rotation.
> 
>> +*rotation = cmdline->rotation;

I remembered that you wanted this to propagate to DRM userspace. That's
not happening here. The only way I see for that to happen, is to set
->panel_orientation. And to repeat myself, imo that makes 'orientation'
a better name for this video= option.

Noralf.

>> +
>>  /*
>>   * TODO: support 90 / 270 degree hardware rotation,
>>   * depending on the hardware this may require the framebuffer
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index 9613c1a28487..ac8d70b92b62 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1531,6 +1531,71 @@ static int drm_mode_parse_cmdline_res_mode(const char 
>> *str, unsigned int length,
>>  return 0;
>>  }
>>  
>> +static int drm_mode_parse_cmdline_options(char *str, size_t len,
>> +  struct drm_connector *connector,
>> +  struct drm_cmdline_mode *mode)
>> +{
>> +unsigned int rotation = 0;
>> +char *sep = str;
>> +
>> +while ((sep = strchr(sep, ','))) {
>> +char *delim, *option;
>> +
>> +option = sep + 1;
>> +delim = strchr(option, '=');
>> +if (!delim) {
>> +delim = strchr(option, ',');
>> +
>> +if (!delim)
>> +delim = str + len;
>> +}
>> +
>> +if (!strncmp(option, "rotate", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int deg;
>> +
>> +deg = simple_strtol(value, &sep, 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +switch (deg) {
>> +case 0:
>> +rotation |= DRM_MODE_ROTATE_0;
>> +break;
>> +
>> +case 90:
>> +rotation |= DRM_MODE_ROTATE_90;
>> +break;
>> +
>> +case 180:
>> +rotation |= DRM_MODE_ROTATE_180;
>> +break;
>> +
>> +case 270:
>> +rotation |= DRM_MODE_ROTATE_270;
>> +break;
>> +
>> +default:
>> +return -EINVAL;
>> +}
>> +} else if (!strncmp(option, "reflect_x", delim - option)) {
>> +rotation |= DRM_MODE_REFLECT_X;
>> +sep = delim;
>> +} else if (!strncmp(option, "reflect_y", delim - option)) {
> 
> I think you should drop reflect_x and _y for now since they're not
> supported. People like me that only reads code and not documentation
> (ahem..) will get the impression that this should work.
> 
> Documentation/fb/modedb.txt needs to be updated with this new video= 

Re: [git pull] drm fixes for 5.1-rc6

[Paul Kocialkowski]

Hi,

On Thu, 2019-04-18 at 13:40 +1000, Dave Airlie wrote:
> Since Easter is looming for me, I'm just pushing whatever is in my
> tree, I'll see what else turns up and maybe I'll send another pull
> early next week if there is anything.

Note that I submitted some drm/sun4i fixes which looked trivial and got
merged to drm-misc fixes yesterday, but there is a call order issue
there that I missed. I sent out a fixup for it earlier today, so it
would be good to include it along with the initial fixes before the
next PR.

The fixup is at: https://patchwork.freedesktop.org/patch/300883/

Just to be perfectly clear: it doesn't affect this PR, we just need to
be careful about the next one.

Cheers and sorry for the inconvenience,

Paul

> tegra:
> - stream id programming fix
> - avoid divide by 0 for bad hdmi audio setup code
> 
> ttm:
> - Hugepages fix
> - refcount imbalance in error path fix
> 
> amdgpu:
> - GPU VM fixes for Vega/RV
> - DC AUX fix for active DP-DVI dongles
> - DC fix for multihead regression.
> 
> Dave.
> 
> drm-fixes-2019-04-18:
> drm tegra, amdgpu fixes
> The following changes since commit dc4060a5dc2557e6b5aa813bf5b73677299d62d2:
> 
>   Linux 5.1-rc5 (2019-04-14 15:17:41 -0700)
> 
> are available in the Git repository at:
> 
>   git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-04-18
> 
> for you to fetch changes up to 00fd14ff3017f64a9a03a08291e4be0d87bedc17:
> 
>   Merge branch 'drm-fixes-5.1' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes (2019-04-18
> 06:56:35 +1000)
> 
> 
> drm tegra, amdgpu fixes
> 
> 
> Alex Deucher (1):
>   drm/amdgpu/gmc9: fix VM_L2_CNTL3 programming
> 
> Arnd Bergmann (1):
>   gpu: host1x: Program stream ID to bypass without SMMU
> 
> Christian König (3):
>   drm/ttm: fix out-of-bounds read in ttm_put_pages() v2
>   drm/ttm: fix start page for huge page check in ttm_put_pages()
>   drm/ttm: fix incrementing the page pointer for huge pages
> 
> Dave Airlie (2):
>   Merge tag 'drm/tegra/for-5.1-rc6' of
> git://anongit.freedesktop.org/tegra/linux into drm-fixes
>   Merge branch 'drm-fixes-5.1' of
> git://people.freedesktop.org/~agd5f/linux into drm-fixes
> 
> David Francis (1):
>   drm/amd/display: If one stream full updates, full update all planes
> 
> Lin Yi (1):
>   drm/ttm: fix dma_fence refcount imbalance on error path
> 
> Martin Leung (1):
>   drm/amd/display: extending AUX SW Timeout
> 
> Thierry Reding (1):
>   drm/tegra: hdmi: Setup audio only if configured
> 
> wentalou (1):
>   drm/amdgpu: shadow in shadow_list without tbo.mem.start cause
> page fault in sriov TDR
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   |  1 +
>  drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c  |  1 +
>  drivers/gpu/drm/amd/display/dc/core/dc.c | 19 +++
>  drivers/gpu/drm/amd/display/dc/dc.h  |  3 +++
>  drivers/gpu/drm/amd/display/dc/dce/dce_aux.c |  9 ++---
>  drivers/gpu/drm/amd/display/dc/dce/dce_aux.h |  6 +++---
>  drivers/gpu/drm/tegra/hdmi.c | 12 +---
>  drivers/gpu/drm/ttm/ttm_bo.c |  4 +++-
>  drivers/gpu/drm/ttm/ttm_page_alloc.c | 13 +++--
>  drivers/gpu/host1x/hw/channel_hw.c   |  8 ++--
>  10 files changed, 58 insertions(+), 18 deletions(-)
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH v3 4/6] drm/modes: Parse overscan properties

[Noralf Trønnes]

Den 18.04.2019 18.50, skrev Noralf Trønnes:
> 
> 
> Den 18.04.2019 14.41, skrev Maxime Ripard:
>> Properly configuring the overscan properties might be needed for the
>> initial setup of the framebuffer for display that still have overscan.
>> Let's allow for more properties on the kernel command line to setup each
>> margin.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  drivers/gpu/drm/drm_modes.c | 44 ++-
>>  include/drm/drm_connector.h | 14 -
>>  2 files changed, 58 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
>> index ac8d70b92b62..d93c44a97ce9 100644
>> --- a/drivers/gpu/drm/drm_modes.c
>> +++ b/drivers/gpu/drm/drm_modes.c
>> @@ -1586,6 +1586,50 @@ static int drm_mode_parse_cmdline_options(char *str, 
>> size_t len,
>>  } else if (!strncmp(option, "reflect_y", delim - option)) {
>>  rotation |= DRM_MODE_REFLECT_Y;
>>  sep = delim;
>> +} else if (!strncmp(option, "margin_right", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, &sep, 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.right = margin;
>> +} else if (!strncmp(option, "margin_left", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, &sep, 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.left = margin;
>> +} else if (!strncmp(option, "margin_top", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, &sep, 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.top = margin;
>> +} else if (!strncmp(option, "margin_bottom", delim - option)) {
>> +const char *value = delim + 1;
>> +unsigned int margin;
>> +
>> +margin = simple_strtol(value, &sep, 10);
>> +
>> +/* Make sure we have parsed something */
>> +if (sep == value)
>> +return -EINVAL;
>> +
>> +mode->tv_margins.bottom = margin;
>>  } else {
>>  return -EINVAL;
>>  }
>> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>> index 6f57c1a3afff..89bc6ac38043 100644
>> --- a/include/drm/drm_connector.h
>> +++ b/include/drm/drm_connector.h
>> @@ -917,6 +917,20 @@ struct drm_cmdline_mode {
>>   * DRM_MODE_ROTATE_180 are supported at the moment.
>>   */
>>  unsigned int rotation;
>> +
>> +/**
>> + * @tv_margins: TV margins (in pixels)
>> + * @tv_margins.left: left margin
>> + * @tv_margins.right: right margin
>> + * @tv_margins.top: top margin
>> + * @tv_margins.bottom: bottom margin
>> + */
> 
> I haven't seen kernel docs like this before so I assume you have tested
> with make htmldocs.
> 
> This one also needs mention in Documentation/fb/modedb.txt. With that:
> 

I discovered that the drm_mode_parse_command_line_for_connector() kernel
doc has the parameters mentioned, so it also needs to be updated.

> Reviewed-by: Noralf Trønnes 
> 
>> +struct {
>> +unsigned int left;
>> +unsigned int right;
>> +unsigned int top;
>> +unsigned int bottom;
>> +} tv_margins;
>>  };
>>  
>>  /**
>>
> ___
> 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

Re: [patch V2 28/29] stacktrace: Provide common infrastructure

[Peter Zijlstra]

On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote:
> On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> > 
> > > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long addr,
> > > +  bool reliable);
> > 
> > > +void arch_stack_walk(stack_trace_consume_fn consume_entry, void *cookie,
> > > +  struct task_struct *task, struct pt_regs *regs);
> > > +int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry, void 
> > > *cookie,
> > > +  struct task_struct *task);
> > 
> > This bugs me a little; ideally the _reliable() thing would not exists.
> > 
> > Thomas said that the existing __save_stack_trace_reliable() is different
> > enough for the unification to be non-trivial, but maybe Josh can help
> > out?
> > 
> > >From what I can see the biggest significant differences are:
> > 
> >  - it looks at the regs sets on the stack and for FP bails early
> >  - bails for khreads and idle (after it does all the hard work!?!)
> > 
> > The first (FP checking for exceptions) should probably be reflected in
> > consume_fn(.reliable) anyway -- although that would mean a lot of extra
> > '?' entries where there are none today.
> > 
> > And the second (KTHREAD/IDLE) is something that the generic code can
> > easily do before calling into the arch unwinder.
> 
> And looking at the powerpc version of it, that has even more interesting
> extra checks in that function.

Right, but not fundamentally different from determining @reliable I
think.

Anyway, it would be good if someone knowledgable could have a look at
this.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110214] radeonsi: xterm scrollback buffer disappears while Shift+PgUp and Shift+PgDn

[bugzilla-daemon]

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

--- Comment #83 from Michel Dänzer  ---
(In reply to Diego Viola from comment #82)
> I found that I can't reproduce this bug with Xephyr -glamor_gles2 (git) but
> it still happens with -glamor.

Presumably the GL_NV_texture_barrier extension isn't available with GLES2, so
this is the same as disabling that extension with OpenGL.

-- 
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: DMA-buf P2P

[Zhou, David(ChunMing)]

Which test are you using? Can share?

-David

> -Original Message-
> From: dri-devel  On Behalf Of
> Christian K?nig
> Sent: Thursday, April 18, 2019 8:09 PM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Subject: DMA-buf P2P
> 
> Hi guys,
> 
> as promised this is the patch set which enables P2P buffer sharing with DMA-
> buf.
> 
> Basic idea is that importers can set a flag noting that they can deal with and
> sgt which doesn't contains pages.
> 
> This in turn is the signal to the exporter that we don't need to move a buffer
> to system memory any more when a remote device wants to access it.
> 
> Please review and/or comment,
> Christian.
> 
> 
> ___
> 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

Re: [PATCH v2 6/6] drm/lima: handle shared irq case for lima_pp_bcast_irq_handler

[Qiang Yu]

Looks good for me, patch is:
Reviewed-by: Qiang Yu 

I'll push this patch to drm-misc-next.

Regards,
Qiang


On Fri, Apr 19, 2019 at 4:35 PM Peter Griffin  wrote:
>
> On Hikey board all lima ip blocks are shared with one irq.
> This patch avoids a NULL ptr deref crash on this platform
> on startup. Tested with Weston and kmscube.
>
> Signed-off-by: Peter Griffin 
> Cc: Rob Herring 
> Cc: Daniel Vetter 
> Cc: Qiang Yu 
> ---
>  drivers/gpu/drm/lima/lima_pp.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/lima/lima_pp.c b/drivers/gpu/drm/lima/lima_pp.c
> index d29721e..8fef224 100644
> --- a/drivers/gpu/drm/lima/lima_pp.c
> +++ b/drivers/gpu/drm/lima/lima_pp.c
> @@ -64,7 +64,13 @@ static irqreturn_t lima_pp_bcast_irq_handler(int irq, void 
> *data)
> struct lima_ip *pp_bcast = data;
> struct lima_device *dev = pp_bcast->dev;
> struct lima_sched_pipe *pipe = dev->pipe + lima_pipe_pp;
> -   struct drm_lima_m450_pp_frame *frame = pipe->current_task->frame;
> +   struct drm_lima_m450_pp_frame *frame;
> +
> +   /* for shared irq case */
> +   if (!pipe->current_task)
> +   return IRQ_NONE;
> +
> +   frame = pipe->current_task->frame;
>
> for (i = 0; i < frame->num_pp; i++) {
> struct lima_ip *ip = pipe->processor[i];
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch V2 22/29] tracing: Make ftrace_trace_userstack() static and conditional

[Steven Rostedt]

On Thu, 18 Apr 2019 10:41:41 +0200
Thomas Gleixner  wrote:

> It's only used in trace.c and there is absolutely no point in compiling it
> in when user space stack traces are not supported.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Steven Rostedt 

Funny, these were moved out to global functions along with the
ftrace_trace_stack() but I guess they were never used.

This basically just does a partial revert of:

 c0a0d0d3f6528 ("tracing/core: Make the stack entry helpers global")


> ---
>  kernel/trace/trace.c |   14 --
>  kernel/trace/trace.h |8 
>  2 files changed, 8 insertions(+), 14 deletions(-)
> 
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -159,6 +159,8 @@ static union trace_eval_map_item *trace_
>  #endif /* CONFIG_TRACE_EVAL_MAP_FILE */
>  
>  static int tracing_set_tracer(struct trace_array *tr, const char *buf);
> +static void ftrace_trace_userstack(struct ring_buffer *buffer,
> +unsigned long flags, int pc);
>  
>  #define MAX_TRACER_SIZE  100
>  static char bootup_tracer_buf[MAX_TRACER_SIZE] __initdata;
> @@ -2905,9 +2907,10 @@ void trace_dump_stack(int skip)
>  }
>  EXPORT_SYMBOL_GPL(trace_dump_stack);
>  
> +#ifdef CONFIG_USER_STACKTRACE_SUPPORT
>  static DEFINE_PER_CPU(int, user_stack_count);
>  
> -void
> +static void
>  ftrace_trace_userstack(struct ring_buffer *buffer, unsigned long flags, int 
> pc)
>  {
>   struct trace_event_call *call = &event_user_stack;
> @@ -2958,13 +2961,12 @@ ftrace_trace_userstack(struct ring_buffe
>   out:
>   preempt_enable();
>  }
> -
> -#ifdef UNUSED

Strange, I never knew about this ifdef. I would have nuked it when I
saw it.

Anyway,

Reviewed-by: Steven Rostedt (VMware) 

-- Steve


> -static void __trace_userstack(struct trace_array *tr, unsigned long flags)
> +#else /* CONFIG_USER_STACKTRACE_SUPPORT */
> +static void ftrace_trace_userstack(struct ring_buffer *buffer,
> +unsigned long flags, int pc)
>  {
> - ftrace_trace_userstack(tr, flags, preempt_count());
>  }
> -#endif /* UNUSED */
> +#endif /* !CONFIG_USER_STACKTRACE_SUPPORT */
>  
>  #endif /* CONFIG_STACKTRACE */
>  
> --- a/kernel/trace/trace.h
> +++ b/kernel/trace/trace.h
> @@ -782,17 +782,9 @@ void update_max_tr_single(struct trace_a
>  #endif /* CONFIG_TRACER_MAX_TRACE */
>  
>  #ifdef CONFIG_STACKTRACE
> -void ftrace_trace_userstack(struct ring_buffer *buffer, unsigned long flags,
> - int pc);
> -
>  void __trace_stack(struct trace_array *tr, unsigned long flags, int skip,
>  int pc);
>  #else
> -static inline void ftrace_trace_userstack(struct ring_buffer *buffer,
> -   unsigned long flags, int pc)
> -{
> -}
> -
>  static inline void __trace_stack(struct trace_array *tr, unsigned long flags,
>int skip, int pc)
>  {
> 

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

[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.

[bugzilla-daemon]

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

--- Comment #11 from tempel.jul...@gmail.com ---
Is it realistic that the maintainers and firms in charge might manage an effort
to solve this matter across vendors this year?

I unfortunately always notice the performance issue by simply browsing the web,
as even little text or hyperlink pop ups trigger fps drops, which are not there
without atomic modesetting on Xorg.

I personally would already be quite happy if the experimental patchset was
available e.g. in amd-staging-drm-next branch for the time being.

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

[pull] amdgpu drm-next-5.2

[Alex Deucher]

Hi Dave, Daniel,

More updates for 5.2:
- Add the amdgpu specific bits for timeline support
- Add internal interfaces for xgmi pstate support
- DC Z ordering fixes for planes
- Add support for NV12 planes in DC
- Add colorspace properties for planes in DC
- eDP optimizations if the GOP driver already initialized eDP
- DC bandwidth validation tracing support

The following changes since commit ecc4946f11a07884f230450a6d5a92337bc21375:

  Merge branch 'drm-next-5.2' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2019-04-12 14:46:58 +1000)

are available in the Git repository at:

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

for you to fetch changes up to f55be0be5b7296e73f1634e2839a1953dc12d11e:

  drm/amd/display: Add profiling tools for bandwidth validation (2019-04-15 
00:22:19 -0500)


Anthony Koo (2):
  drm/amd/display: Add switch for Fractional PWM on or off
  drm/amd/display: Read eDP link settings on detection

Aric Cyr (1):
  drm/amd/display: 3.2.26

Christian König (1):
  drm/amdgpu: fix old fence check in amdgpu_fence_emit

Chunming Zhou (2):
  drm/amdgpu: add timeline support in amdgpu CS v3
  drm/amdgpu: update version for timeline syncobj support in amdgpu v2

David Francis (1):
  drm/amd/display: Handle get crtc position error

Joshua Aberback (2):
  drm/amd/display: Add fast_validate parameter
  drm/amd/display: Add profiling tools for bandwidth validation

Jun Lei (1):
  drm/amd/display: expand plane caps to include fp16 and scaling capability

Nicholas Kazlauskas (11):
  drm/amd/display: Expose support for NV12 on suitable planes
  drm/amd/display: Add DRM color properties for primary planes
  drm/amd/display: Update plane scaling parameters for fast updates
  drm/amd/display: Maintain z-ordering when creating planes
  drm/amd/display: Recalculate pitch when buffers change
  drm/amd/display: Rework DC plane filling and surface updates
  drm/amd/display: Add basic downscale and upscale valdiation
  drm/amd/display: Use surface directly when checking update type
  drm/amd/display: Don't warn when DC update type > DM guess
  drm/amd/display: Check scaling info when determing update type
  drm/amd/display: Relax requirements for CRTCs to be enabled

Samson Tam (1):
  drm/amd/display: change name from dc_link_get_verified_link_cap to 
dc_link_get_link_cap

Yongqiang Sun (1):
  drm/amd/display: define HUBP_MASK_SH_LIST_DCN for Raven

shaoyunl (2):
  drm/powerplay: Add smu set xgmi pstate interface
  drm/amdgpu: Set proper function to set xgmi pstate

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 152 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c  |  24 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   |  13 +-
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 745 +
 drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.c   |  24 +-
 drivers/gpu/drm/amd/display/dc/core/dc.c   |   2 +-
 drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c   |  33 +-
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  |   6 +-
 drivers/gpu/drm/amd/display/dc/core/dc_stream.c|   3 +-
 drivers/gpu/drm/amd/display/dc/dc.h|  85 ++-
 drivers/gpu/drm/amd/display/dc/dc_link.h   |   2 +-
 drivers/gpu/drm/amd/display/dc/dce/dce_abm.c   |  18 +
 .../drm/amd/display/dc/dce100/dce100_resource.c|  22 +-
 .../drm/amd/display/dc/dce110/dce110_resource.c|  41 +-
 .../drm/amd/display/dc/dce112/dce112_resource.c|  22 +-
 .../drm/amd/display/dc/dce112/dce112_resource.h|   3 +-
 .../drm/amd/display/dc/dce120/dce120_resource.c|  19 +-
 .../gpu/drm/amd/display/dc/dce80/dce80_resource.c  |  22 +-
 drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hubp.h  |   9 +-
 .../gpu/drm/amd/display/dc/dcn10/dcn10_resource.c  |  20 +-
 drivers/gpu/drm/amd/display/dc/inc/core_types.h|   3 +-
 drivers/gpu/drm/amd/display/dc/inc/dcn_calcs.h |   3 +-
 drivers/gpu/drm/amd/powerplay/inc/amdgpu_smu.h |   4 +
 drivers/gpu/drm/amd/powerplay/smu_v11_0.c  |   9 +-
 include/uapi/drm/amdgpu_drm.h  |   8 +
 27 files changed, 944 insertions(+), 361 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: fix spelling mistake "gateing" -> "gating"

[Alex Deucher]

On Wed, Apr 17, 2019 at 3:04 AM Mukesh Ojha  wrote:
>
>
> On 4/16/2019 5:29 PM, Colin King wrote:
> > From: Colin Ian King 
> >
> > There is a spelling mistake in a DRM_INFO message. Fix it.
> >
> > Signed-off-by: Colin Ian King 
> Reviewed-by: Mukesh Ojha 


Applied.  thanks!

Alex

>
> Cheers,
> -Mukesh
> > ---
> >   drivers/gpu/drm/amd/amdgpu/vce_v2_0.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
> > index bed78a778e3f..40363ca6c5f1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/vce_v2_0.c
> > @@ -283,7 +283,7 @@ static int vce_v2_0_stop(struct amdgpu_device *adev)
> >   }
> >
> >   if (vce_v2_0_wait_for_idle(adev)) {
> > - DRM_INFO("VCE is busy, Can't set clock gateing");
> > + DRM_INFO("VCE is busy, Can't set clock gating");
> >   return 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

Re: [PATCH] drm/amd/amdgpu: fix spelling mistake "recieve" -> "receive"

[Alex Deucher]

On Thu, Apr 18, 2019 at 1:58 PM Mukesh Ojha  wrote:
>
>
> On 4/18/2019 3:55 PM, Colin King wrote:
> > From: Colin Ian King 
> >
> > There is a spelling mistake in a pr_err message. Fix it.
> >
> > Signed-off-by: Colin Ian King 
> Reviewed-by: Mukesh Ojha 

Applied.  thanks!

Alex


>
> Cheers,
> -Mukesh
> > ---
> >   drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c 
> > b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > index 6a0fcd67662a..aef9d059ae52 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
> > @@ -515,7 +515,7 @@ static void xgpu_vi_mailbox_flr_work(struct work_struct 
> > *work)
> >
> >   /* wait until RCV_MSG become 3 */
> >   if (xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL)) {
> > - pr_err("failed to recieve FLR_CMPL\n");
> > + pr_err("failed to receive FLR_CMPL\n");
> >   return;
> >   }
> >
> ___
> 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

Re: [patch V2 28/29] stacktrace: Provide common infrastructure

[Josh Poimboeuf]

On Fri, Apr 19, 2019 at 09:02:11AM +0200, Peter Zijlstra wrote:
> On Thu, Apr 18, 2019 at 05:42:55PM +0200, Thomas Gleixner wrote:
> > On Thu, 18 Apr 2019, Josh Poimboeuf wrote:
> 
> > > Another idea I had (but never got a chance to work on) was to extend the
> > > x86 unwind interface to all arches.  So instead of the callbacks, each
> > > arch would implement something like this API:
> 
> > I surely thought about that, but after staring at all incarnations of
> > arch/*/stacktrace.c I just gave up.
> > 
> > Aside of that quite some archs already have callback based unwinders
> > because they use them for more than stacktracing and just have a single
> > implementation of that loop.
> > 
> > I'm fine either way. We can start with x86 and then let archs convert over
> > their stuff, but I wouldn't hold my breath that this will be completed in
> > the forseeable future.
> 
> I suggested the same to Thomas early on, and I even spend the time to
> convert some $random arch to the iterator interface, and while it is
> indeed entirely feasible, it is _far_ more work.
> 
> The callback thing OTOH is flexible enough to do what we want to do now,
> and allows converting most archs to it without too much pain (as Thomas
> said, many archs are already in this form and only need minor API
> adjustments), which gets us in a far better place than we are now.
> 
> And we can always go to iterators later on. But I think getting the
> generic unwinder improved across all archs is a really important first
> step here.

Fair enough.

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

[PATCH] Revert "drm/virtio: drop prime import/export callbacks"

[Marc-André Lureau]

This patch does more harm than good, as it breaks both Xwayland and
gnome-shell with X11.

Xwayland requires DRI3 & DRI3 requires PRIME.

X11 crash for obscure double-free reason which are hard to debug
(starting X11 by hand doesn't trigger the crash).

I don't see an apparent problem implementing those stub prime
functions, they may return an error at run-time, and it seems to be
handled fine by GNOME at least.

Please consider a revert.

This reverts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.

Cc: Gerd Hoffmann 
Cc: Dave Airlie 
Signed-off-by: Marc-André Lureau 
---
 drivers/gpu/drm/virtio/virtgpu_drv.c   |  4 
 drivers/gpu/drm/virtio/virtgpu_drv.h   |  4 
 drivers/gpu/drm/virtio/virtgpu_prime.c | 14 ++
 3 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.c 
b/drivers/gpu/drm/virtio/virtgpu_drv.c
index b996ac1d4fcc..af92964b6889 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.c
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
@@ -205,10 +205,14 @@ static struct drm_driver driver = {
 #if defined(CONFIG_DEBUG_FS)
.debugfs_init = virtio_gpu_debugfs_init,
 #endif
+   .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
+   .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = virtgpu_gem_prime_pin,
.gem_prime_unpin = virtgpu_gem_prime_unpin,
+   .gem_prime_get_sg_table = virtgpu_gem_prime_get_sg_table,
+   .gem_prime_import_sg_table = virtgpu_gem_prime_import_sg_table,
.gem_prime_vmap = virtgpu_gem_prime_vmap,
.gem_prime_vunmap = virtgpu_gem_prime_vunmap,
.gem_prime_mmap = virtgpu_gem_prime_mmap,
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 3238fdf58eb4..d577cb76f5ad 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -354,6 +354,10 @@ int virtio_gpu_object_wait(struct virtio_gpu_object *bo, 
bool no_wait);
 /* virtgpu_prime.c */
 int virtgpu_gem_prime_pin(struct drm_gem_object *obj);
 void virtgpu_gem_prime_unpin(struct drm_gem_object *obj);
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
+struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
+   struct drm_device *dev, struct dma_buf_attachment *attach,
+   struct sg_table *sgt);
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj);
 void virtgpu_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 int virtgpu_gem_prime_mmap(struct drm_gem_object *obj,
diff --git a/drivers/gpu/drm/virtio/virtgpu_prime.c 
b/drivers/gpu/drm/virtio/virtgpu_prime.c
index c59ec34c80a5..86ce0ae93f59 100644
--- a/drivers/gpu/drm/virtio/virtgpu_prime.c
+++ b/drivers/gpu/drm/virtio/virtgpu_prime.c
@@ -39,6 +39,20 @@ void virtgpu_gem_prime_unpin(struct drm_gem_object *obj)
WARN_ONCE(1, "not implemented");
 }
 
+struct sg_table *virtgpu_gem_prime_get_sg_table(struct drm_gem_object *obj)
+{
+   WARN_ONCE(1, "not implemented");
+   return ERR_PTR(-ENODEV);
+}
+
+struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
+   struct drm_device *dev, struct dma_buf_attachment *attach,
+   struct sg_table *table)
+{
+   WARN_ONCE(1, "not implemented");
+   return ERR_PTR(-ENODEV);
+}
+
 void *virtgpu_gem_prime_vmap(struct drm_gem_object *obj)
 {
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(obj);
-- 
2.21.0.313.ge35b8cb8e2

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

Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Chen-Yu Tsai]

On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
 wrote:
>
> Our components may still be using the DRM device driver (if only to
> access our driver's private data), so make sure to unbind them before
> the final drm_dev_put.
>
> Also release our resserved memory adter unbind to match reverse

typos...

> creation order.
>
> Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component master 
> deletion")
> Signed-off-by: Paul Kocialkowski 
> ---
>  drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> b/drivers/gpu/drm/sun4i/sun4i_drv.c
> index 843b86661833..29258b404e54 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> drm_kms_helper_poll_fini(drm);
> drm_atomic_helper_shutdown(drm);
> drm_mode_config_cleanup(drm);
> -   of_reserved_mem_device_release(dev);
> -   drm_dev_put(drm);
>
> component_unbind_all(dev, NULL);
> +   of_reserved_mem_device_release(dev);

You should probably mention this change in the commit log as well.

Otherwise,

Reviewed-by: Chen-Yu Tsai 

> +
> +   drm_dev_put(drm);
>  }
>
>  static const struct component_master_ops sun4i_drv_master_ops = {
> --
> 2.21.0
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[ANNOUNCE] libdrm 2.4.98

[Emil Velikov]

This release adds marketing names for AMDGPU devices, a fallback path in
drmDevice for devices lacking OF data and drmIsMaster API, amongst other
changes.


-Emil


Alex Deucher (3):
  amdgpu: add some raven marketing names
  amdgpu: add marketing name for AMD Radeon VII
  amdgpu: update amdgpu_drm.h from drm-next for 5.2

Andreas Baierl (1):
  xf86drm: Fix segmentation fault while parsing device info

Anusha (1):
  intel: sync i915_pciids.h with kernel

Ayan Halder (1):
  headers: Sync with drm-next

Bas Nieuwenhuizen (1):
  amdgpu: Add context priority override function.

Christopher James Halse Rogers (1):
  xf86drm: Add drmIsMaster()

Cui, Flora (6):
  tests/amdgpu: add deadlock test for sdma
  tests/amdgpu: add memset dispatch test
  tests/amdgpu: add memcpy dispatch test
  tests/amdgpu: add memset draw test
  tests/amdgpu: add memcpy draw test
  tests/amdgpu: minor fix for dispatch/draw test

Emil Velikov (4):
  xf86drm: fallback to MODALIAS for OF less platform devices
  xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info
  Revert "libdrm: Fix issue about differrent domainID but same BDF"
  Bump the version to 2.4.98

Emily Deng (1):
  libdrm: Fix issue about differrent domainID but same BDF

Eric Engestrom (5):
  xf86drm: fix return type for drmIsMaster()
  freedreno: revert bad freedreno/atomic_ops commits
  gitlab-ci: fix archlinux builds
  amdgpu/tests: drop unused local vars
  fix various typos

Fritz Koenig (1):
  tests/modetest: add QCOM_COMPRESSED to supported modifiers list

Gurchetan Singh (1):
  virtgpu: Update kernel header

Lubomir Rintel (1):
  tests/util: Add armada-drm driver

Pan, Xinhui (1):
  amdgpu: Fix a structure initialization issue

Rodrigo Vivi (1):
  intel: sync i915_pciids.h with kernel

Seung-Woo Kim (1):
  configure.ac fix build error for config.h in autotools

Tapani Pälli (1):
  libkms: update list of intel_drivers for Android build

xinhui pan (2):
  amdgpu: add ras tests
  drm/amdgpu: support test mask

git tag: libdrm-2.4.98

https://dri.freedesktop.org/libdrm/libdrm-2.4.98.tar.bz2
MD5:  1320b43c4bdb8846c308ec2610b62b64  libdrm-2.4.98.tar.bz2
SHA1: 4c8a11870a89f59c294bef0109939a7ffaa1fb26  libdrm-2.4.98.tar.bz2
SHA256: 8be0edccaca3abde8b6bb1431b46354c7fab46e9b91cc6946ba65b51f56f1894  
libdrm-2.4.98.tar.bz2
SHA512: 
3d333d060ceb14fa8e204ef468ca2c95d6f07205185ca90a044b685832b9b2d7256faa5e81d5871ce8b70aa1fdf9fb1ade18b4e582ff0c7ef5551da8506eb27b
  libdrm-2.4.98.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.98.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.98.tar.gz
MD5:  0d3ba6c7196e0e14fb2c5426141cd5fc  libdrm-2.4.98.tar.gz
SHA1: 1afccb372f3cc06f3d3b0111eb653a4e35bf60c3  libdrm-2.4.98.tar.gz
SHA256: 39789e2c37e7300324777a5c0a4ea1846537822b15ea3e630b0a000d8243ee97  
libdrm-2.4.98.tar.gz
SHA512: 
a8a1d47f167b32d5e9c3bc023457d2284b3059774407c9167b7ca0b5aeae14bb79cdd3d367f41098685f9ee1e9b65729665e6974923bb48104549f5fbaad6c7c
  libdrm-2.4.98.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.98.tar.gz.sig




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

Re: [patch V2 28/29] stacktrace: Provide common infrastructure

[Josh Poimboeuf]

On Fri, Apr 19, 2019 at 11:07:17AM +0200, Peter Zijlstra wrote:
> On Fri, Apr 19, 2019 at 10:32:30AM +0200, Thomas Gleixner wrote:
> > On Fri, 19 Apr 2019, Peter Zijlstra wrote:
> > > On Thu, Apr 18, 2019 at 10:41:47AM +0200, Thomas Gleixner wrote:
> > > 
> > > > +typedef bool (*stack_trace_consume_fn)(void *cookie, unsigned long 
> > > > addr,
> > > > +  bool reliable);
> > > 
> > > > +void arch_stack_walk(stack_trace_consume_fn consume_entry, void 
> > > > *cookie,
> > > > +struct task_struct *task, struct pt_regs *regs);
> > > > +int arch_stack_walk_reliable(stack_trace_consume_fn consume_entry, 
> > > > void *cookie,
> > > > +struct task_struct *task);
> > > 
> > > This bugs me a little; ideally the _reliable() thing would not exists.
> > > 
> > > Thomas said that the existing __save_stack_trace_reliable() is different
> > > enough for the unification to be non-trivial, but maybe Josh can help
> > > out?
> > > 
> > > >From what I can see the biggest significant differences are:
> > > 
> > >  - it looks at the regs sets on the stack and for FP bails early
> > >  - bails for khreads and idle (after it does all the hard work!?!)

That's done for a reason, see the "Success path" comments.

> > > The first (FP checking for exceptions) should probably be reflected in
> > > consume_fn(.reliable) anyway -- although that would mean a lot of extra
> > > '?' entries where there are none today.
> > > 
> > > And the second (KTHREAD/IDLE) is something that the generic code can
> > > easily do before calling into the arch unwinder.
> > 
> > And looking at the powerpc version of it, that has even more interesting
> > extra checks in that function.
> 
> Right, but not fundamentally different from determining @reliable I
> think.
> 
> Anyway, it would be good if someone knowledgable could have a look at
> this.

Yeah, we could probably do that.

The flow would need to be changed a bit -- some of the errors are soft
errors which most users don't care about because they just want a best
effort.  The soft errors can be remembered without breaking out of the
loop, and just returned at the end.  Most users could just ignore the
return code.

The only thing I'd be worried about is performance for the non-livepatch
users, but I guess those checks don't look very expensive.  And the x86
unwinders are already pretty slow anyway...

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

Re: [PATCH] Revert "drm/virtio: drop prime import/export callbacks"

[Emil Velikov]

On Fri, 19 Apr 2019 at 16:57, Marc-André Lureau
 wrote:
>
> This patch does more harm than good, as it breaks both Xwayland and
> gnome-shell with X11.
>
> Xwayland requires DRI3 & DRI3 requires PRIME.
>
> X11 crash for obscure double-free reason which are hard to debug
> (starting X11 by hand doesn't trigger the crash).
>
> I don't see an apparent problem implementing those stub prime
> functions, they may return an error at run-time, and it seems to be
> handled fine by GNOME at least.
>
> Please consider a revert.
>
> This reverts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.
>
> Cc: Gerd Hoffmann 
> Cc: Dave Airlie 
> Signed-off-by: Marc-André Lureau 

The DRI3 code extensively uses prime_handle_to_fd and
prime_fd_to_handle for self-import.

Fwiw the patch is:
Reviewed-by: Emil Velikov 

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

Re: [PATCH] Revert "drm/virtio: drop prime import/export callbacks"

[Chia-I Wu]

On Fri, Apr 19, 2019 at 9:21 AM Emil Velikov  wrote:
>
> On Fri, 19 Apr 2019 at 16:57, Marc-André Lureau
>  wrote:
> >
> > This patch does more harm than good, as it breaks both Xwayland and
> > gnome-shell with X11.
> >
> > Xwayland requires DRI3 & DRI3 requires PRIME.
> >
> > X11 crash for obscure double-free reason which are hard to debug
> > (starting X11 by hand doesn't trigger the crash).
> >
> > I don't see an apparent problem implementing those stub prime
> > functions, they may return an error at run-time, and it seems to be
> > handled fine by GNOME at least.
> >
> > Please consider a revert.
> >
> > This reverts commit b318e3ff7ca065d6b107e424c85a63d7a6798a69.
> >
> > Cc: Gerd Hoffmann 
> > Cc: Dave Airlie 
> > Signed-off-by: Marc-André Lureau 
>
> The DRI3 code extensively uses prime_handle_to_fd and
> prime_fd_to_handle for self-import.
>
> Fwiw the patch is:
> Reviewed-by: Emil Velikov 
We also use Xwayland and will be helped by the revert.

I believe the cap was removed because the driver only supports
self-import.  But the driver only runs inside VMs where there is no(?)
other dma-buf clients, and it handles runtime errors fine even if
there are, I would also like to see this revert be considered.

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

Re: [linux-sunxi] [PATCH] drm/sun4i: Unbind components before releasing DRM and mem at master unbind

[Paul Kocialkowski]

Hi,

On Fri, 2019-04-19 at 09:02 -0700, Chen-Yu Tsai wrote:
> On Fri, Apr 19, 2019 at 1:03 AM Paul Kocialkowski
>  wrote:
> > Our components may still be using the DRM device driver (if only to
> > access our driver's private data), so make sure to unbind them before
> > the final drm_dev_put.
> > 
> > Also release our resserved memory adter unbind to match reverse
> 
> typos...

I'll probably spin up a v2 to fix them, they annoy me as well.

> > creation order.
> > 
> > Fixes: f5a9ed867c83 ("drm/sun4i: Fix component unbinding and component 
> > master deletion")
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/gpu/drm/sun4i/sun4i_drv.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c 
> > b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > index 843b86661833..29258b404e54 100644
> > --- a/drivers/gpu/drm/sun4i/sun4i_drv.c
> > +++ b/drivers/gpu/drm/sun4i/sun4i_drv.c
> > @@ -149,10 +149,11 @@ static void sun4i_drv_unbind(struct device *dev)
> > drm_kms_helper_poll_fini(drm);
> > drm_atomic_helper_shutdown(drm);
> > drm_mode_config_cleanup(drm);
> > -   of_reserved_mem_device_release(dev);
> > -   drm_dev_put(drm);
> > 
> > component_unbind_all(dev, NULL);
> > +   of_reserved_mem_device_release(dev);
> 
> You should probably mention this change in the commit log as well.

That's what I meant with the line that has typos. Maybe I should make
it slightly more explicit as:

Also released our reserved memory after component unbind instead of
before to match reverse creation order.

What do you think?

> Otherwise,
> 
> Reviewed-by: Chen-Yu Tsai 

Thanks for the review!

Cheers,

Paul

> > +
> > +   drm_dev_put(drm);
> >  }
> > 
> >  static const struct component_master_ops sun4i_drv_master_ops = {
> > --
> > 2.21.0
> > 
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an 
> > email to linux-sunxi+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

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

Re: [PATCH 2/6] PCI/P2PDMA: start with a whitelist for root complexes

[Alex Deucher]

On Thu, Apr 18, 2019 at 8:09 AM Christian König
 wrote:
>
> A lot of root complexes can still do P2P even when PCI devices
> don't share a common upstream bridge.
>
> Start adding a whitelist and allow P2P if both participants are
> attached to known good root complex.
>
> Signed-off-by: Christian König 
> ---
>  drivers/pci/p2pdma.c | 38 +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index c52298d76e64..212baaa7f93b 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -274,6 +274,31 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, 
> struct pci_dev *pdev)
> seq_buf_printf(buf, "%s;", pci_name(pdev));
>  }
>
> +/*
> + * If we can't find a common upstream bridge take a look at the root complex 
> and
> + * compare it to a whitelist of known good hardware.
> + */
> +static bool root_complex_whitelist(struct pci_dev *dev)
> +{
> +   struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
> +   struct pci_dev *root = pci_get_slot(host->bus, PCI_DEVFN(0, 0));
> +   unsigned short vendor, device;
> +
> +   if (!root)
> +   return false;
> +
> +   vendor = root->vendor;
> +   device = root->device;
> +   pci_dev_put(root);
> +
> +   /* AMD ZEN host bridges can do peer to peer */
> +   if (vendor == PCI_VENDOR_ID_AMD && device == 0x1450)

We should also add:
(vendor == PCI_VENDOR_ID_AMD && device == 0x1576) // Carrizo
(vendor == PCI_VENDOR_ID_AMD && device == 0x1536) // Kaveri/kabini/mullins

Alex

> +   return true;
> +
> +   /* TODO: Extend that to a proper whitelist */
> +   return false;
> +}
> +
>  /*
>   * Find the distance through the nearest common upstream bridge between
>   * two PCI devices.
> @@ -317,13 +342,13 @@ static void seq_buf_print_bus_devfn(struct seq_buf 
> *buf, struct pci_dev *pdev)
>   * In this case, a list of all infringing bridge addresses will be
>   * populated in acs_list (assuming it's non-null) for printk purposes.
>   */
> -static int upstream_bridge_distance(struct pci_dev *a,
> -   struct pci_dev *b,
> +static int upstream_bridge_distance(struct pci_dev *provider,
> +   struct pci_dev *client,
> struct seq_buf *acs_list)
>  {
> +   struct pci_dev *a = provider, *b = client, *bb;
> int dist_a = 0;
> int dist_b = 0;
> -   struct pci_dev *bb = NULL;
> int acs_cnt = 0;
>
> /*
> @@ -354,6 +379,13 @@ static int upstream_bridge_distance(struct pci_dev *a,
> dist_a++;
> }
>
> +   /* Allow the connection if both devices are on a whitelisted root
> +* complex, but add an arbitary large value to the distance.
> +*/
> +   if (root_complex_whitelist(provider) &&
> +   root_complex_whitelist(client))
> +   return 0x1000 + dist_a + dist_b;
> +
> return -1;
>
>  check_b_path_acs:
> --
> 2.17.1
>
> ___
> 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: [GIT PULL] drm/vmwgfx: vmwgfx-next

[Deepak Singh Rawat]

It seems this got missed, If no one has any objection I will submit the
patches via drm-mics route.

Deepak

On Tue, 2019-04-09 at 12:49 -0700, Deepak Singh Rawat wrote:
> Hi Daniel/Dave,
> 
> The vmwgfx-next changes for 5.2:
> Resource dirtying improvement by Thomas,
> user-space error logging improvement and
> some other minor fixes.
> 
> The following changes since commit
> 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
> 
>   Merge tag 'drm-misc-next-2019-04-04' of
> git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-04-05
> 11:38:02 +1000)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/drawat/linux.git vmwgfx-next
> 
> for you to fetch changes up to
> c601b12fb634e2d0c2669706b38dba98a3c3a832:
> 
>   drm/vmwgfx: Remove set but not used variable 'fb_offset, fb_depth'
> (2019-04-08 10:29:05 -0700)
> 
> 
> Chengguang Xu (1):
>   drm/vmwgfx: remove redundant unlikely annotation
> 
> Deepak Rawat (8):
>   drm/vmwgfx: Use preprocessor macro to get valid context node
>   drm/vmwgfx: Use preprocessor macro for cmd struct
>   drm/vmwgfx: Add a new define for vmwgfx user-space debugging
>   drm/vmwgfx: Print message when command verifier returns with
> error
>   drm/vmwgfx: Clean up some debug messages in vmwgfx_execbuf.c
>   drm/vmwgfx: Use VMW_DEBUG_USER for device command buffer errors
>   drm/vmwgfx: Fix formatting and spaces in vmwgfx_execbuf.c
>   drm/vmwgfx: Use preprocessor macro for FIFO allocation
> 
> Nathan Chancellor (1):
>   drm/vmwgfx: Zero initialize handle in vmw_execbuf_process
> 
> Thomas Hellstrom (1):
>   drm/vmwgfx: Be more restrictive when dirtying resources
> 
> YueHaibing (2):
>   drm/vmwgfx: Remove set but not used variable 'restart'
>   drm/vmwgfx: Remove set but not used variable 'fb_offset,
> fb_depth'
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_binding.c |   98 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_binding.h |2 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c  |   24 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_context.c |   59 ++
>  drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c |   23 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   29 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 1505
> +++
> ---
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c|   27 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c |9 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c   |   12 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   28 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |6 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_mob.c |   25 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_resource.c|   28 ++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|   23 +--
>  drivers/gpu/drm/vmwgfx/vmwgfx_shader.c  |   44 ++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_simple_resource.c |   12 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_so.c  |   45 +++--
>  drivers/gpu/drm/vmwgfx/vmwgfx_so.h  |1 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|   47 ++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |   80 +++-
>  drivers/gpu/drm/vmwgfx/vmwgfx_validation.c  |   61 --
>  drivers/gpu/drm/vmwgfx/vmwgfx_validation.h  |7 +
>  25 files changed, 972 insertions(+), 1231 deletions(-)
> 

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

[PATCH] drm: kirin: Fix for hikey620 display offset problem

[John Stultz]

From: Da Lv 

The original HiKey (620) board has had a long running issue
where when using a 1080p montior, the display would occasionally
blink and come come back with a horizontal offset (usually also
shifting the colors, depending on the value of the offset%4).

After lots of analysis by HiSi developers, they found the issue
was due to when running at 1080p, it was possible to hit the
device memory bandwidth limits, which could cause the DSI signal
to get out of sync.

Unfortunately the DSI logic doesn't have the ability to
automatically recover from this situation, but we can get a an
LDI underflow interrupt when it happens.

To then correct the issue, when we get an LDI underflow irq, we
we can simply suspend and resume the display, which resets the
hardware.

Thus, this patch enables the ldi underflow interrupt, and
initializes a workqueue that is used to suspend/resume the
display to recover. Then when the irq occurs we clear it and
schedule the workqueue to reset display engine.

Cc: Xinliang Liu 
Cc: Rongrong Zou 
Cc: Xinwei Kong 
Cc: Chen Feng 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel 
Signed-off-by: Da Lv 
Signed-off-by: Yidong Lin 
[jstultz: Reworded the commit message, checkpatch cleanups]
Signed-off-by: John Stultz 
Change-Id: I792ce0b50a1c941d94d8cbec6b52c0f838d967bd
---
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h |  6 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 23 +++
 2 files changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h 
b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
index 4cf281b7..ced40c6 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
@@ -87,6 +87,7 @@
 #define VSIZE_OFST 20
 #define LDI_INT_EN 0x741C
 #define FRAME_END_INT_EN_OFST  1
+#define UNDERFLOW_INT_EN_OFST  2
 #define LDI_CTRL   0x7420
 #define BPP_OFST   3
 #define DATA_GATE_EN   BIT(2)
@@ -97,6 +98,11 @@
 #define LDI_HDMI_DSI_GT0x7434
 
 /*
+ *BIT_LDI_UNFLOW
+ */
+#define BIT_LDI_UNFLOW BIT(2)
+
+/*
  * ADE media bus service regs
  */
 #define ADE0_QOSGENERATOR_MODE 0x010C
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
index 73611a9..1d935ab 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
@@ -58,6 +58,7 @@ struct ade_hw_ctx {
 struct ade_crtc {
struct drm_crtc base;
struct ade_hw_ctx *ctx;
+   struct work_struct drm_device_wq;
bool enable;
u32 out_format;
 };
@@ -176,6 +177,7 @@ static void ade_init(struct ade_hw_ctx *ctx)
 */
ade_update_bits(base + ADE_CTRL, FRM_END_START_OFST,
FRM_END_START_MASK, REG_EFFECTIVE_IN_ADEEN_FRMEND);
+   ade_update_bits(base + LDI_INT_EN, UNDERFLOW_INT_EN_OFST, MASK(1), 1);
 }
 
 static bool ade_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -345,6 +347,18 @@ static void ade_crtc_disable_vblank(struct drm_crtc *crtc)
MASK(1), 0);
 }
 
+static void drm_underflow_wq(struct work_struct *work)
+{
+   struct ade_crtc *acrtc = container_of(work, struct ade_crtc,
+ drm_device_wq);
+   struct drm_device *drm_dev = (&acrtc->base)->dev;
+   void __iomem *base = acrtc->ctx->base;
+   struct drm_atomic_state *state;
+
+   state = drm_atomic_helper_suspend(drm_dev);
+   drm_atomic_helper_resume(drm_dev, state);
+}
+
 static irqreturn_t ade_irq_handler(int irq, void *data)
 {
struct ade_crtc *acrtc = data;
@@ -362,6 +376,12 @@ static irqreturn_t ade_irq_handler(int irq, void *data)
MASK(1), 1);
drm_crtc_handle_vblank(crtc);
}
+   if (status & BIT_LDI_UNFLOW) {
+   ade_update_bits(base + LDI_INT_CLR, UNDERFLOW_INT_EN_OFST,
+   MASK(1), 1);
+   DRM_ERROR("LDI underflow!");
+   schedule_work(&acrtc->drm_device_wq);
+   }
 
return IRQ_HANDLED;
 }
@@ -1038,6 +1058,9 @@ static int ade_drm_init(struct platform_device *pdev)
/* vblank irq init */
ret = devm_request_irq(dev->dev, ctx->irq, ade_irq_handler,
   IRQF_SHARED, dev->driver->name, acrtc);
+
+   INIT_WORK(&acrtc->drm_device_wq, drm_underflow_wq);
+
if (ret)
return ret;
 
-- 
2.7.4

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

[Bug 110371] HP Dreamcolor display *Error* No EDID read

[bugzilla-daemon]

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

--- Comment #6 from babblebo...@gmail.com ---
Will do. Just switched my distro to Gentoo, specifically so I can stay on
kernel 4.18 for as long as necessary to combat the issue and apply a patch when
ready, and cleared all of the cruft out of the grub config.

I can drop my EDID itself here as well if that will help.

Give me a bit to get everything ready and I will post the drm debug of old and
new.

-- 
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] dma-buf: Remove unused sync_dump()

[Chris Wilson]

sync_dump() is an unused, unexported, function that adds 64k to the
kernel image and doesn't even provide locking around the global array it
uses.

add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
Function old new   delta
sync_dump198   --198
sync_dump_buf  65536   -  -65536

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
---
 drivers/dma-buf/sync_debug.c | 26 --
 drivers/dma-buf/sync_debug.h |  1 -
 2 files changed, 27 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index c0abf37df88b..434a66518e0d 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -197,29 +197,3 @@ static __init int sync_debugfs_init(void)
return 0;
 }
 late_initcall(sync_debugfs_init);
-
-#define DUMP_CHUNK 256
-static char sync_dump_buf[64 * 1024];
-void sync_dump(void)
-{
-   struct seq_file s = {
-   .buf = sync_dump_buf,
-   .size = sizeof(sync_dump_buf) - 1,
-   };
-   int i;
-
-   sync_info_debugfs_show(&s, NULL);
-
-   for (i = 0; i < s.count; i += DUMP_CHUNK) {
-   if ((s.count - i) > DUMP_CHUNK) {
-   char c = s.buf[i + DUMP_CHUNK];
-
-   s.buf[i + DUMP_CHUNK] = 0;
-   pr_cont("%s", s.buf + i);
-   s.buf[i + DUMP_CHUNK] = c;
-   } else {
-   s.buf[s.count] = 0;
-   pr_cont("%s", s.buf + i);
-   }
-   }
-}
diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
index 05e33f937ad0..6176e52ba2d7 100644
--- a/drivers/dma-buf/sync_debug.h
+++ b/drivers/dma-buf/sync_debug.h
@@ -68,6 +68,5 @@ void sync_timeline_debug_add(struct sync_timeline *obj);
 void sync_timeline_debug_remove(struct sync_timeline *obj);
 void sync_file_debug_add(struct sync_file *fence);
 void sync_file_debug_remove(struct sync_file *fence);
-void sync_dump(void);
 
 #endif /* _LINUX_SYNC_H */
-- 
2.20.1

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

Re: [Freedreno] [PATCH 1/3] drm/msm/gpu: add per-process pagetables param

[Jordan Crouse]

On Tue, Apr 16, 2019 at 06:30:24PM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> For now it always returns '0' (false), but once the iommu work is in
> place to enable per-process pagetables we can update the value returned.
> 
> Userspace needs to know this to make an informed decision about exposing
> KHR_robustness.
> 
> Signed-off-by: Rob Clark 

Reviewed-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 2cfee1a4fe0b..fbdf6f1c247e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -62,6 +62,9 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param, 
> uint64_t *value)
>   case MSM_PARAM_NR_RINGS:
>   *value = gpu->nr_rings;
>   return 0;
> + case MSM_PARAM_PP_PGTABLE:
> + *value = 0;
> + 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 91a16b333c69..a9fdcf1689ce 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -74,6 +74,7 @@ struct drm_msm_timespec {
>  #define MSM_PARAM_TIMESTAMP  0x05
>  #define MSM_PARAM_GMEM_BASE  0x06
>  #define MSM_PARAM_NR_RINGS   0x07
> +#define MSM_PARAM_PP_PGTABLE 0x08  /* => 1 for per-process pagetables, else 
> 0 */
>  
>  struct drm_msm_param {
>   __u32 pipe;   /* in, MSM_PIPE_x */
> -- 
> 2.20.1
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [Freedreno] [PATCH 2/3] drm/msm: add param to retrieve # of GPU faults (global)

[Jordan Crouse]

On Tue, Apr 16, 2019 at 06:30:25PM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> For KHR_robustness, userspace wants to know two things, the count of GPU
> faults globally, and the count of faults attributed to a given context.
> This patch providees the former, and the next patch provides the latter.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Jordan Crouse 

> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
>  drivers/gpu/drm/msm/msm_gpu.c   | 3 +++
>  drivers/gpu/drm/msm/msm_gpu.h   | 3 +++
>  include/uapi/drm/msm_drm.h  | 1 +
>  4 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index fbdf6f1c247e..8436caa4547f 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -65,6 +65,9 @@ int adreno_get_param(struct msm_gpu *gpu, uint32_t param, 
> uint64_t *value)
>   case MSM_PARAM_PP_PGTABLE:
>   *value = 0;
>   return 0;
> + case MSM_PARAM_FAULTS:
> + *value = gpu->global_faults;
> + return 0;
>   default:
>   DBG("%s: invalid param: %u", gpu->name, param);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index 10babd18e286..194847a220b6 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -443,6 +443,9 @@ static void recover_worker(struct work_struct *work)
>   if (submit) {
>   struct task_struct *task;
>  
> + /* Increment the fault count */
> + gpu->global_faults++;
> +
>   task = get_pid_task(submit->pid, PIDTYPE_PID);
>   if (task) {
>   comm = kstrdup(task->comm, GFP_KERNEL);
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index ca17086f72c9..3e9078ec3023 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -103,6 +103,9 @@ struct msm_gpu {
>   /* does gpu need hw_init? */
>   bool needs_hw_init;
>  
> + /* number of GPU hangs (for all contexts) */
> + int global_faults;
> +
>   /* worker for handling active-list retiring: */
>   struct work_struct retire_work;
>  
> diff --git a/include/uapi/drm/msm_drm.h b/include/uapi/drm/msm_drm.h
> index a9fdcf1689ce..178d7b407f3a 100644
> --- a/include/uapi/drm/msm_drm.h
> +++ b/include/uapi/drm/msm_drm.h
> @@ -75,6 +75,7 @@ struct drm_msm_timespec {
>  #define MSM_PARAM_GMEM_BASE  0x06
>  #define MSM_PARAM_NR_RINGS   0x07
>  #define MSM_PARAM_PP_PGTABLE 0x08  /* => 1 for per-process pagetables, else 
> 0 */
> +#define MSM_PARAM_FAULTS 0x09
>  
>  struct drm_msm_param {
>   __u32 pipe;   /* in, MSM_PIPE_x */
> -- 
> 2.20.1
> 
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno

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

Re: [PATCH v3 6/6] drm/vc4: hdmi: Set default state margin at reset

[Noralf Trønnes]

Den 18.04.2019 18.59, skrev Noralf Trønnes:
> 
> 
> Den 18.04.2019 14.41, skrev Maxime Ripard:
>> Now that the TV margins are properly parsed and filled into
>> drm_cmdline_mode, we just need to initialise the first state at reset to
>> get those values and start using them.
>>
>> Signed-off-by: Maxime Ripard 
>> ---
>>  drivers/gpu/drm/vc4/vc4_hdmi.c | 16 +++-
>>  1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> index 99fc8569e0f5..d86f154138f5 100644
>> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
>> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
>> @@ -255,11 +255,25 @@ static int vc4_hdmi_connector_get_modes(struct 
>> drm_connector *connector)
>>  return ret;
>>  }
>>  
>> +static void vc4_hdmi_connector_reset(struct drm_connector *connector)

You could turn this function into a helper
drm_atomic_helper_connector_tv_reset() or something.

>> +{
>> +struct drm_cmdline_mode *cmdline = &connector->cmdline_mode;
>> +struct drm_connector_state *state;
>> +
>> +drm_atomic_helper_connector_reset(connector);
> 
> Initially I wondered why not do this in the helper, but ofc that would
> apply the values to all the connectors. I know too little about this
> subject to argue for having it in the helper, and it can be changed
> later if deemed convinient, so:
> 
> Acked-by: Noralf Trønnes 
> 
>> +
>> +state = connector->state;
>> +state->tv.margins.left = cmdline->tv_margins.left;
>> +state->tv.margins.right = cmdline->tv_margins.right;
>> +state->tv.margins.top = cmdline->tv_margins.top;
>> +state->tv.margins.bottom = cmdline->tv_margins.bottom;
>> +}
>> +
>>  static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
>>  .detect = vc4_hdmi_connector_detect,
>>  .fill_modes = drm_helper_probe_single_connector_modes,
>>  .destroy = vc4_hdmi_connector_destroy,
>> -.reset = drm_atomic_helper_connector_reset,
>> +.reset = vc4_hdmi_connector_reset,
>>  .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
>>  .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
>>  };
>>
> ___
> 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

Re: [PATCH 05/12] dma-buf: add explicit buffer pinning

[Alex Deucher]

On Tue, Apr 16, 2019 at 2:39 PM Christian König
 wrote:
>
> Add optional explicit pinning callbacks instead of implicitly assume the
> exporter pins the buffer when a mapping is created.
>
> Signed-off-by: Christian König 
> ---
>  drivers/dma-buf/dma-buf.c | 39 +++
>  include/linux/dma-buf.h   | 37 +++--
>  2 files changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index a3738fab3927..f23ff8355505 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -630,6 +630,41 @@ void dma_buf_detach(struct dma_buf *dmabuf, struct 
> dma_buf_attachment *attach)
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_detach);
>
> +/**
> + * dma_buf_pin - Lock down the DMA-buf
> + *
> + * @dmabuf:[in]DMA-buf to lock down.
> + *
> + * Returns:
> + * 0 on success, negative error code on failure.
> + */
> +int dma_buf_pin(struct dma_buf *dmabuf)
> +{
> +   int ret = 0;
> +
> +   reservation_object_assert_held(dmabuf->resv);
> +
> +   if (dmabuf->ops->pin)
> +   ret = dmabuf->ops->pin(dmabuf);
> +
> +   return ret;
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_pin);
> +
> +/**
> + * dma_buf_unpin - Remove lock from DMA-buf
> + *
> + * @dmabuf:[in]DMA-buf to unlock.
> + */
> +void dma_buf_unpin(struct dma_buf *dmabuf)
> +{
> +   reservation_object_assert_held(dmabuf->resv);
> +
> +   if (dmabuf->ops->unpin)
> +   dmabuf->ops->unpin(dmabuf);
> +}
> +EXPORT_SYMBOL_GPL(dma_buf_unpin);
> +
>  /**
>   * dma_buf_map_attachment_locked - Maps the buffer into _device_ address 
> space
>   * with the reservation lock held. Is a wrapper for map_dma_buf() of the
> @@ -666,6 +701,8 @@ dma_buf_map_attachment_locked(struct dma_buf_attachment 
> *attach,
>  */
> if (attach->invalidate)
> list_del(&attach->node);
> +   else
> +   dma_buf_pin(attach->dmabuf);
> sg_table = attach->dmabuf->ops->map_dma_buf(attach, direction);
> if (attach->invalidate)
> list_add(&attach->node, &attach->dmabuf->attachments);
> @@ -735,6 +772,8 @@ void dma_buf_unmap_attachment_locked(struct 
> dma_buf_attachment *attach,
>
> attach->dmabuf->ops->unmap_dma_buf(attach, sg_table,
> direction);
> +   if (!attach->invalidate)
> +   dma_buf_unpin(attach->dmabuf);
>  }
>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment_locked);
>
> diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
> index ece4638359a8..a615b74e5894 100644
> --- a/include/linux/dma-buf.h
> +++ b/include/linux/dma-buf.h
> @@ -100,14 +100,40 @@ struct dma_buf_ops {
>  */
> void (*detach)(struct dma_buf *, struct dma_buf_attachment *);
>
> +   /**
> +* @pin_dma_buf:
> +*
> +* This is called by dma_buf_pin and lets the exporter know that an
> +* importer assumes that the DMA-buf can't be invalidated any more.
> +*
> +* This is called with the dmabuf->resv object locked.
> +*
> +* This callback is optional.
> +*
> +* Returns:
> +*
> +* 0 on success, negative error code on failure.
> +*/
> +   int (*pin)(struct dma_buf *);
> +
> +   /**
> +* @unpin_dma_buf:
> +*
> +* This is called by dma_buf_unpin and lets the exporter know that an
> +   * importer doesn't need to the DMA-buf to stay were it is any more.

This should read:
* importer doesn't need the DMA-buf to stay were it is anymore.

> +*
> +* This is called with the dmabuf->resv object locked.
> +*
> +* This callback is optional.
> +*/
> +   void (*unpin)(struct dma_buf *);
> +
> /**
>  * @map_dma_buf:
>  *
>  * This is called by dma_buf_map_attachment() and is used to map a
>  * shared &dma_buf into device address space, and it is mandatory. It
> -* can only be called if @attach has been called successfully. This
> -* essentially pins the DMA buffer into place, and it cannot be moved
> -* any more
> +* can only be called if @attach has been called successfully.
>  *
>  * This call may sleep, e.g. when the backing storage first needs to 
> be
>  * allocated, or moved to a location suitable for all currently 
> attached
> @@ -148,9 +174,6 @@ struct dma_buf_ops {
>  *
>  * This is called by dma_buf_unmap_attachment() and should unmap and
>  * release the &sg_table allocated in @map_dma_buf, and it is 
> mandatory.
> -* It should also unpin the backing storage if this is the last 
> mapping
> -* of the DMA buffer, it the exporter supports backing storage
> -* migration.
>  *
>  * This is always called with the dmabuf->resv object locked when
>  * no_sg

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

[Alex Deucher]

On Thu, Apr 18, 2019 at 8:09 AM Christian König
 wrote:
>
> We should be able to do this now after checking all the prerequisites.
>
> v2: fix entrie count in the sgt
>
> Signed-off-by: Christian König 

Series is:
Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 46 --
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h  |  9 ++
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 96 
>  3 files changed, 142 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> index a290ae830b11..55bb39281c5d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
> @@ -318,22 +318,45 @@ amdgpu_gem_map_dma_buf(struct dma_buf_attachment 
> *attach,
> }
>
> if (attach->invalidate) {
> -   /* move buffer into GTT */
> +   /* move buffer into GTT or VRAM */
> struct ttm_operation_ctx ctx = { false, false };
> +   unsigned domains = AMDGPU_GEM_DOMAIN_GTT;
>
> -   amdgpu_bo_placement_from_domain(bo, AMDGPU_GEM_DOMAIN_GTT);
> +   if (bo->preferred_domains & AMDGPU_GEM_DOMAIN_VRAM &&
> +   attach->peer2peer) {
> +   bo->flags |= AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED;
> +   domains |= AMDGPU_GEM_DOMAIN_VRAM;
> +   }
> +   amdgpu_bo_placement_from_domain(bo, domains);
> r = ttm_bo_validate(&bo->tbo, &bo->placement, &ctx);
> if (r)
> return ERR_PTR(r);
> }
>
> -   sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages, bo->tbo.num_pages);
> -   if (IS_ERR(sgt))
> -   return sgt;
> +   switch (bo->tbo.mem.mem_type) {
> +   case TTM_PL_TT:
> +   sgt = drm_prime_pages_to_sg(bo->tbo.ttm->pages,
> +   bo->tbo.num_pages);
> +   if (IS_ERR(sgt))
> +   return sgt;
> +
> +   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> + DMA_ATTR_SKIP_CPU_SYNC)) {
> +   r = -EINVAL;
> +   goto error_free;
> +   }
> +   break;
>
> -   if (!dma_map_sg_attrs(attach->dev, sgt->sgl, sgt->nents, dir,
> - DMA_ATTR_SKIP_CPU_SYNC))
> +   case TTM_PL_VRAM:
> +   r = amdgpu_vram_mgr_alloc_sgt(adev, &bo->tbo.mem, attach->dev,
> + dir, &sgt);
> +   if (r)
> +   goto error_free;
> +   break;
> +   default:
> +   r = -EINVAL;
> goto error_free;
> +   }
>
> if (attach->dev->driver != adev->dev->driver)
> bo->prime_shared_count++;
> @@ -343,7 +366,7 @@ amdgpu_gem_map_dma_buf(struct dma_buf_attachment *attach,
>  error_free:
> sg_free_table(sgt);
> kfree(sgt);
> -   return ERR_PTR(-ENOMEM);
> +   return ERR_PTR(r);
>  }
>
>  /**
> @@ -367,10 +390,15 @@ static void amdgpu_gem_unmap_dma_buf(struct 
> dma_buf_attachment *attach,
> if (attach->dev->driver != adev->dev->driver && 
> bo->prime_shared_count)
> bo->prime_shared_count--;
>
> -   if (sgt) {
> +   if (!sgt)
> +   return;
> +
> +   if (sgt->sgl->page_link) {
> dma_unmap_sg(attach->dev, sgt->sgl, sgt->nents, dir);
> sg_free_table(sgt);
> kfree(sgt);
> +   } else {
> +   amdgpu_vram_mgr_free_sgt(adev, attach->dev, dir, sgt);
> }
>  }
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> index c2b7669004ba..0b4cdbe867e7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> @@ -72,6 +72,15 @@ uint64_t amdgpu_gtt_mgr_usage(struct ttm_mem_type_manager 
> *man);
>  int amdgpu_gtt_mgr_recover(struct ttm_mem_type_manager *man);
>
>  u64 amdgpu_vram_mgr_bo_visible_size(struct amdgpu_bo *bo);
> +int amdgpu_vram_mgr_alloc_sgt(struct amdgpu_device *adev,
> + struct ttm_mem_reg *mem,
> + struct device *dev,
> + enum dma_data_direction dir,
> + struct sg_table **sgt);
> +void amdgpu_vram_mgr_free_sgt(struct amdgpu_device *adev,
> + struct device *dev,
> + enum dma_data_direction dir,
> + struct sg_table *sgt);
>  uint64_t amdgpu_vram_mgr_usage(struct ttm_mem_type_manager *man);
>  uint64_t amdgpu_vram_mgr_vis_usage(struct ttm_mem_type_manager *man);
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> i

[PATCH v2 0/3] drm/msm/a6xx: Add support for zap shader

[Jordan Crouse]

This patch series adds support for loading the zap shader on a6xx and using it
to get the GPU out of secure mode.

The Adreno a5xx and a6xx GPUs boot in "secure" mode which restricts the memory
the GPU is allowed to use. To get the GPU out of secure mode we need to write
to a register. However some bootloaders block access to this register and
require that the GPU instead perform a sequence to pull the GPU out of secure
mode. This sequence requires a special "zap" shader that will execute in
secure mode, clear out all the internal GPU settings and then transition to
in-secure mode.

This series adds support for loading and using the zap shader on a6xx assuming
that the shader exists and that the bootloader supports the secure mode. If any
part of the sequence fails then fall back to writing the register. If we get it
wrong, then writing to the register will trigger a protection mode error and
the system will go down.

The actual zap shader works almost identically to the one on 5xx outside of
a minor workaround for system resume. The first patch moves the a5xx specific
support to the generic adreno driver. The second patch add support for the
zap shader and the final two patches add the DT bindings and DT settings for
setting up the reserved memory that the shader requires.

v2: Reduced the redundant log messages for targets that don't need the zap
shader

Jordan Crouse (3):
  drm/msm/gpu: Move zap shader loading to adreno
  drm/msm/a6xx: Add zap shader load
  dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region

 .../devicetree/bindings/display/msm/gpu.txt|   7 ++
 drivers/gpu/drm/msm/adreno/a5xx_gpu.c  | 111 +
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  |  38 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |   1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c| 135 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.h|   6 +
 6 files changed, 187 insertions(+), 111 deletions(-)

-- 
2.7.4

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

[PATCH v2 1/3] drm/msm/gpu: Move zap shader loading to adreno

[Jordan Crouse]

a5xx and a6xx both share (mostly) the same code to load the zap shader and
bring the GPU out of secure mode. Move the formerly 5xx specific code to
adreno to make it available for a6xx too.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a5xx_gpu.c   | 111 +-
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 135 
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |   6 ++
 3 files changed, 142 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index 270da14..e5fcefa 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -15,9 +15,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -30,96 +27,6 @@ static void a5xx_dump(struct msm_gpu *gpu);
 
 #define GPU_PAS_ID 13
 
-static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname)
-{
-   struct device *dev = &gpu->pdev->dev;
-   const struct firmware *fw;
-   struct device_node *np, *mem_np;
-   struct resource r;
-   phys_addr_t mem_phys;
-   ssize_t mem_size;
-   void *mem_region = NULL;
-   int ret;
-
-   if (!IS_ENABLED(CONFIG_ARCH_QCOM))
-   return -EINVAL;
-
-   np = of_get_child_by_name(dev->of_node, "zap-shader");
-   if (!np)
-   return -ENODEV;
-
-   mem_np = of_parse_phandle(np, "memory-region", 0);
-   of_node_put(np);
-   if (!mem_np)
-   return -EINVAL;
-
-   ret = of_address_to_resource(mem_np, 0, &r);
-   of_node_put(mem_np);
-   if (ret)
-   return ret;
-
-   mem_phys = r.start;
-   mem_size = resource_size(&r);
-
-   /* Request the MDT file for the firmware */
-   fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
-   if (IS_ERR(fw)) {
-   DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
-   return PTR_ERR(fw);
-   }
-
-   /* Figure out how much memory we need */
-   mem_size = qcom_mdt_get_size(fw);
-   if (mem_size < 0) {
-   ret = mem_size;
-   goto out;
-   }
-
-   /* Allocate memory for the firmware image */
-   mem_region = memremap(mem_phys, mem_size,  MEMREMAP_WC);
-   if (!mem_region) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   /*
-* Load the rest of the MDT
-*
-* Note that we could be dealing with two different paths, since
-* with upstream linux-firmware it would be in a qcom/ subdir..
-* adreno_request_fw() handles this, but qcom_mdt_load() does
-* not.  But since we've already gotten thru adreno_request_fw()
-* we know which of the two cases it is:
-*/
-   if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
-   ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
-   mem_region, mem_phys, mem_size, NULL);
-   } else {
-   char *newname;
-
-   newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
-
-   ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
-   mem_region, mem_phys, mem_size, NULL);
-   kfree(newname);
-   }
-   if (ret)
-   goto out;
-
-   /* Send the image to the secure world */
-   ret = qcom_scm_pas_auth_and_reset(GPU_PAS_ID);
-   if (ret)
-   DRM_DEV_ERROR(dev, "Unable to authorize the image\n");
-
-out:
-   if (mem_region)
-   memunmap(mem_region);
-
-   release_firmware(fw);
-
-   return ret;
-}
-
 static void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -565,8 +472,6 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
 static int a5xx_zap_shader_init(struct msm_gpu *gpu)
 {
static bool loaded;
-   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
-   struct platform_device *pdev = gpu->pdev;
int ret;
 
/*
@@ -576,23 +481,9 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
if (loaded)
return a5xx_zap_shader_resume(gpu);
 
-   /* We need SCM to be able to load the firmware */
-   if (!qcom_scm_is_available()) {
-   DRM_DEV_ERROR(&pdev->dev, "SCM is not available\n");
-   return -EPROBE_DEFER;
-   }
-
-   /* Each GPU has a target specific zap shader firmware name to use */
-   if (!adreno_gpu->info->zapfw) {
-   DRM_DEV_ERROR(&pdev->dev,
-   "Zap shader firmware file not specified for this 
target\n");
-   return -ENODEV;
-   }
-
-   ret = zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw);
+   ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
 
loaded = !ret;
-
return ret;
 }
 
diff --git a/drivers/gpu/drm/msm/adreno/adreno_

[PATCH v2 3/3] dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region

[Jordan Crouse]

Describe the zap-shader node that defines a reserved memory region
to store the zap shader.

Signed-off-by: Jordan Crouse 
---

 Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index aad1aef..1e6d870 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -25,6 +25,9 @@ Required properties:
 - qcom,gmu: For GMU attached devices a phandle to the GMU device that will
   control the power for the GPU. Applicable targets:
 - qcom,adreno-630.2
+- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
+  points to reserved memory to store the zap shader that can be used to help
+  bring the GPU out of secure mode.
 
 Example 3xx/4xx/a5xx:
 
@@ -71,5 +74,9 @@ Example a6xx (with GMU):
operating-points-v2 = <&gpu_opp_table>;
 
qcom,gmu = <&gmu>;
+
+   zap-shader {
+   memory-region = <&zap_shader_region>;
+   };
};
 };
-- 
2.7.4

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

[Bug 108521] RX 580 as eGPU amdgpu: gpu post error!

[bugzilla-daemon]

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

--- Comment #50 from Dimitar Atanasov  ---
There is two windows on this system. Small one below 4GB which is 2.5GB and
bigger one over 4GB which is 64GB. Address space for thunderbolt is only 200
MB. As I know AMDGPU needs 250 MB in low 4GB and rest is in big space.
Interesting enough, is that I have XPS 9570 which is 8750h and there is BIOS
option how to assign MMIO space, there is no such option here.

-- 
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 v2 2/3] drm/msm/a6xx: Add zap shader load

[Jordan Crouse]

The a6xx GPU powers on in secure mode which restricts what memory it can
write to. To get out of secure mode the GPU driver can write to
REG_A6XX_RBBM_SECVID_TRUST_CNTL but on targets that are "secure" that
register region is blocked and writes will cause the system to go down.

For those targets we need to execute a special sequence that involves
loadinga special shader that clears the GPU registers and use a PM4
sequence to pull the GPU out of secure. Add support for loading the zap
shader and executing the secure sequence. For targets that do not support
SCM or the specific SCM sequence this should fail and we would fall back
to writing the register.

Signed-off-by: Jordan Crouse 
---

 drivers/gpu/drm/msm/adreno/a6xx_gpu.c  | 38 +-
 drivers/gpu/drm/msm/adreno/adreno_device.c |  1 +
 2 files changed, 38 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 576559a..7028bb7 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,8 @@
 
 #include 
 
+#define GPU_PAS_ID 13
+
 static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
 {
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -343,6 +345,20 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
return 0;
 }
 
+static int a6xx_zap_shader_init(struct msm_gpu *gpu)
+{
+   static bool loaded;
+   int ret;
+
+   if (loaded)
+   return 0;
+
+   ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
+
+   loaded = !ret;
+   return ret;
+}
+
 #define A6XX_INT_MASK (A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR | \
  A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW | \
  A6XX_RBBM_INT_0_MASK_CP_HW_ERROR | \
@@ -491,7 +507,27 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
if (ret)
goto out;
 
-   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+   /*
+* Try to load a zap shader into the secure world. If successful
+* we can use the CP to switch out of secure mode. If not then we
+* have no resource but to try to switch ourselves out manually. If we
+* guessed wrong then access to the RBBM_SECVID_TRUST_CNTL register will
+* be blocked and a permissions violation will soon follow.
+*/
+   ret = a6xx_zap_shader_init(gpu);
+   if (!ret) {
+   OUT_PKT7(gpu->rb[0], CP_SET_SECURE_MODE, 1);
+   OUT_RING(gpu->rb[0], 0x);
+
+   a6xx_flush(gpu, gpu->rb[0]);
+   if (!a6xx_idle(gpu, gpu->rb[0]))
+   return -EINVAL;
+   } else {
+   /* Print a warning so if we die, we know why */
+   dev_warn_once(gpu->dev->dev,
+   "Zap shader not enabled - using SECVID_TRUST_CNTL 
instead\n");
+   gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+   }
 
 out:
/*
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 0d87db7..b907245 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -155,6 +155,7 @@ static const struct adreno_info gpulist[] = {
.gmem = SZ_1M,
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
+   .zapfw = "a630_zap.mdt",
},
 };
 
-- 
2.7.4

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

[PATCH v4] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

[Jordan Crouse]

Add documentation for the interconnect and interconnect-names bindings
for the GPU node as detailed by bindings/interconnect/interconnect.txt.

Signed-off-by: Jordan Crouse 
Reviewed-by: Douglas Anderson 
Reviewed-by: Rob Herring 
Acked-by: Georgi Djakov 
---
v4: Fix spelling nits per Georgi

 Documentation/devicetree/bindings/display/msm/gpu.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt 
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index aad1aef..c04614c 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -22,6 +22,8 @@ Required properties:
- qcom,adreno-630.2
 - iommus: optional phandle to an adreno iommu instance
 - operating-points-v2: optional phandle to the OPP operating points
+- interconnects: optional phandle to an interconnect provider.  See
+  ../interconnect/interconnect.txt for details.
 - qcom,gmu: For GMU attached devices a phandle to the GMU device that will
   control the power for the GPU. Applicable targets:
 - qcom,adreno-630.2
@@ -70,6 +72,8 @@ Example a6xx (with GMU):
 
operating-points-v2 = <&gpu_opp_table>;
 
+   interconnects = <&rsc_hlos MASTER_GFX3D &rsc_hlos SLAVE_EBI1>;
+
qcom,gmu = <&gmu>;
};
 };
-- 
2.7.4

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

[radeon-alex:drm-next-5.2-wip 64/66] drivers/gpu/drm/ttm/ttm_bo.c:52:10: sparse: symbol 'ttm_bo_glob_use_count' was not declared. Should it be static?

[kbuild test robot]

tree:   git://people.freedesktop.org/~agd5f/linux.git drm-next-5.2-wip
head:   a70be09f90c0b211b45bae50eb98617d75713297
commit: 5c4923919f015e80e76d3d88d5743d422d105ff2 [64/66] drm/ttm: fix re-init 
of global structures
reproduce:
# apt-get install sparse
git checkout 5c4923919f015e80e76d3d88d5743d422d105ff2
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 



sparse warnings: (new ones prefixed by >>)

   drivers/gpu/drm/ttm/ttm_bo.c:51:1: sparse: symbol 'ttm_global_mutex' was not 
declared. Should it be static?
>> drivers/gpu/drm/ttm/ttm_bo.c:52:10: sparse: symbol 'ttm_bo_glob_use_count' 
>> was not declared. Should it be static?
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   drivers/gpu/drm/ttm/ttm_bo.c:559:28: sparse: context imbalance in 
'ttm_bo_cleanup_refs' - unexpected unlock
   drivers/gpu/drm/ttm/ttm_bo.c:619:27: sparse: context imbalance in 
'ttm_bo_delayed_delete' - different lock contexts for basic block
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   drivers/gpu/drm/ttm/ttm_bo.c:787:12: sparse: context imbalance in 
'ttm_mem_evict_first' - different lock contexts for basic block
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression
   drivers/gpu/drm/ttm/ttm_bo.c:1765:5: sparse: context imbalance in 
'ttm_bo_swapout' - different lock contexts for basic block
   include/linux/reservation.h:220:20: sparse: dereference of noderef expression
   include/linux/reservation.h:220:45: sparse: dereference of noderef expression

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH radeon-alex] drm/ttm: ttm_bo_glob_use_count can be static

[kbuild test robot]

Fixes: 5c4923919f01 ("drm/ttm: fix re-init of global structures")
Signed-off-by: kbuild test robot 
---
 ttm_bo.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2845fce..a7bb5a2 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -49,7 +49,7 @@ static void ttm_bo_global_kobj_release(struct kobject *kobj);
  * ttm_global_mutex - protecting the global BO state
  */
 DEFINE_MUTEX(ttm_global_mutex);
-unsigned ttm_bo_glob_use_count;
+static unsigned ttm_bo_glob_use_count;
 struct ttm_bo_global ttm_bo_glob;
 
 static struct attribute ttm_bo_count = {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

2019 Election Round 2 voting OPEN

[Wentland, Harry]

To all X.Org Foundation Members:

The round 2 of X.Org Foundation's annual election is now open and will remain 
open until 23:59 UTC on 2 May 2019.

Four of the eight director seats are open during this election, with the four 
nominees receiving the highest vote totals serving as directors for two year 
terms.

There were six candidates nominated. For a complete list of the candidates and 
their personal statements, please visit the 2019 X.Org Elections page at 
https://www.x.org/wiki/BoardOfDirectors/Elections/2019/

The new bylaw changes were approved in the first round of voting.

Here are some instructions on how to cast your vote:

Login to the membership system at: https://members.x.org/

If you do not remember your password, you can click on the "lost password" 
button and enter your user name. An e-mail will be sent to you with your 
password. If you have problems with the membership system, please e-mail 
members...@x.org.

When you login you will see an "Active Ballots" section with the "X.Org 2019 
Elections Round 2" ballot. When you click on that you will be presented with a 
page describing the ballot. At the bottom you will find a number of dropdowns 
that let you rank your candidates by order of preference.

For the election: There is a pull-down selection box for 1st choice, 2nd, 
choice, and so on. Pick your candidates top to bottom in order of preference, 
avoiding duplicates.

After you have completed your ballot, click the "Cast vote" button. Note that 
once you click this button, your votes will be cast and you will not be able to 
make further changes, so please make sure you are satisfied with your votes 
before clicking the "Cast vote" button.

After you click the "Vote" button, the system will verify that you have 
completed a valid ballot. If your ballot is invalid (e.g., you duplicated a 
selection or did not answer the By-laws approval question), it will return you 
to the previous voting page. If your ballot is valid, your votes will be 
recorded and the system will show you a notice that your votes were cast.

Note that the election will close at 23:59 UTC on 2 May 2019. At that time, the 
election committee will count the votes and present the results to the current 
board for validation. After the current board validates the results, the 
election committee will present the results to the Members.

Harry, on behalf of the X.Org elections committee
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch V2 24/29] tracing: Remove the last struct stack_trace usage

[Steven Rostedt]

On Thu, 18 Apr 2019 10:41:43 +0200
Thomas Gleixner  wrote:

> Simplify the stack retrieval code by using the storage array based
> interface.
> 
> Signed-off-by: Thomas Gleixner 


Reviewed-by: Steven Rostedt (VMware) 

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

Re: [patch V2 23/29] tracing: Simplify stack trace retrieval

[Steven Rostedt]

On Thu, 18 Apr 2019 10:41:42 +0200
Thomas Gleixner  wrote:

> Replace the indirection through struct stack_trace by using the storage
> array based interfaces.
> 
> Signed-off-by: Thomas Gleixner 
> Cc: Steven Rostedt 

Reviewed-by: Steven Rostedt (VMware) 

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

Re: [PATCH v2 4/6] reset: hi6220: Add support for AO reset controller

[Stephen Boyd]

Quoting Peter Griffin (2019-04-19 01:32:59)
> This is required to bring Mali450 gpu out of reset. Also
> we now use CLK_OF_DECLARE_DRIVER to probe in both the
> clock and reset drivers. The clock and reset parts have
> been done as one atomic commit to avoid a bisection hole.
> 
> Signed-off-by: Peter Griffin 
> Cc: Stephen Boyd 
> ---

>  drivers/clk/hisilicon/clk-hi6220.c|  3 +-

Acked-by: Stephen Boyd 

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

Re: Avoiding merge conflicts while adding new docs - Was: Re: [PATCH 00/57] Convert files to ReST

[Jonathan Corbet]

On Thu, 18 Apr 2019 09:42:23 -0300
Mauro Carvalho Chehab  wrote:

> After thinking a little bit and doing some tests, I think a good solution
> would be to add ":orphan:" markup to the new .rst files that were not
> added yet into the main body (e. g. something like the enclosed example).

Interesting...I didn't know about that.  Yes, I think it makes sense to
put that in...

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

[Bug 110443] vaapi/vpp: wrong output for non 64-bytes align width (ex: 1200)

[bugzilla-daemon]

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

--- Comment #5 from Marek Olšák  ---
Yes. It can be just 1 function returning both values and it doesn't have to
return boolean.

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

[RFC][PATCH 2/5] libdrm: amdgpu: Initialize unions with memset rather than "= {0}"

[John Stultz]

Clang complains when initializing unions using "= {0}"
so instead use memset.

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Signed-off-by: John Stultz 
---
 amdgpu/amdgpu_cs.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/amdgpu/amdgpu_cs.c b/amdgpu/amdgpu_cs.c
index 7ee844f..7c5b9d1 100644
--- a/amdgpu/amdgpu_cs.c
+++ b/amdgpu/amdgpu_cs.c
@@ -733,12 +733,13 @@ drm_public int amdgpu_cs_submit_raw(amdgpu_device_handle 
dev,
struct drm_amdgpu_cs_chunk *chunks,
uint64_t *seq_no)
 {
-   union drm_amdgpu_cs cs = {0};
+   union drm_amdgpu_cs cs;
uint64_t *chunk_array;
int i, r;
if (num_chunks == 0)
return -EINVAL;
 
+   memset(&cs, 0, sizeof(cs));
chunk_array = alloca(sizeof(uint64_t) * num_chunks);
for (i = 0; i < num_chunks; i++)
chunk_array[i] = (uint64_t)(uintptr_t)&chunks[i];
@@ -763,10 +764,11 @@ drm_public int amdgpu_cs_submit_raw2(amdgpu_device_handle 
dev,
 struct drm_amdgpu_cs_chunk *chunks,
 uint64_t *seq_no)
 {
-   union drm_amdgpu_cs cs = {0};
+   union drm_amdgpu_cs cs;
uint64_t *chunk_array;
int i, r;
 
+   memset(&cs, 0, sizeof(cs));
chunk_array = alloca(sizeof(uint64_t) * num_chunks);
for (i = 0; i < num_chunks; i++)
chunk_array[i] = (uint64_t)(uintptr_t)&chunks[i];
@@ -803,9 +805,10 @@ drm_public int 
amdgpu_cs_fence_to_handle(amdgpu_device_handle dev,
 uint32_t what,
 uint32_t *out_handle)
 {
-   union drm_amdgpu_fence_to_handle fth = {0};
+   union drm_amdgpu_fence_to_handle fth;
int r;
 
+   memset(&fth, 0, sizeof(fth));
fth.in.fence.ctx_id = fence->context->id;
fth.in.fence.ip_type = fence->ip_type;
fth.in.fence.ip_instance = fence->ip_instance;
-- 
2.7.4

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

[RFC][PATCH 5/5] libdrm: omap: Add DRM_RDWR flag to dmabuf export

[John Stultz]

From: Hemant Hariyani 

Allows mmap on dmabuf fd with MAP_SHARED and PROT_WRITE.

This fixes boot failures caused due to mmap() returning error

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Signed-off-by: Hemant Hariyani 
[picked and updated commitmsg from 
http://git.ti.com/cgit/cgit.cgi/android/external-libdrm.git/]
Signed-off-by: Praneeth Bajjuri 
Signed-off-by: Alistair Strachan 
Signed-off-by: John Stultz 
---
 omap/omap_drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/omap/omap_drm.c b/omap/omap_drm.c
index 3aed4e0..ffacea6 100644
--- a/omap/omap_drm.c
+++ b/omap/omap_drm.c
@@ -414,7 +414,7 @@ drm_public int omap_bo_dmabuf(struct omap_bo *bo)
if (bo->fd < 0) {
struct drm_prime_handle req = {
.handle = bo->handle,
-   .flags = DRM_CLOEXEC,
+   .flags = DRM_CLOEXEC | DRM_RDWR,
};
int ret;
 
-- 
2.7.4

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

[RFC][PATCH 0/5] libdrm: Patches from AOSP

[John Stultz]

Over the last few days I've been trying to sync the AOSP libdrm
tree with the upstream freedesktop branch.

Thanks to input from Sean, Alistair and Marissa, we've managed
to drop a bunch of stale patches AOSP was carrying, and get
the AOSP libdrm updated to 2.4.97

I've gone through the remaining patch delta and wanted to submit
the non-Android.bp changes, which seemed like they might be
relevant for upstream, for review and feedback.

With the exception of one of these, I'm not the original author,
so I do not have the full context for the patch. So if they
don't really make sense anymore, let me know and I can see if we
can drop them in AOSP.

Thoughts and feedback would be greatly appreciated!

thanks
-john

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 

Adrian Salido (1):
  libdrm: reduce number of reallocations in drmModeAtomicAddProperty

Hemant Hariyani (1):
  libdrm: omap: Add DRM_RDWR flag to dmabuf export

John Stultz (1):
  libdrm: amdgpu: Initialize unions with memset rather than "= {0}"

Prabhanjan Kandula (1):
  libdrm: Avoid additional drm open close

Sean Paul (1):
  libdrm: Use mmap64 instead of __mmap2

 amdgpu/amdgpu_cs.c | 9 ++---
 libdrm_macros.h| 4 +---
 omap/omap_drm.c| 2 +-
 xf86drm.c  | 4 ++--
 xf86drmMode.c  | 7 ---
 5 files changed, 14 insertions(+), 12 deletions(-)

-- 
2.7.4

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

[RFC][PATCH 4/5] libdrm: reduce number of reallocations in drmModeAtomicAddProperty

[John Stultz]

From: Adrian Salido 

When calling drmModeAtomicAddProperty allocation of memory happens as
needed in increments of 16 elements. This can be very slow if there are
multiple properties to be updated in an Atomic Commit call.

Increase this to as many as can fit in a memory PAGE to avoid having to
reallocate memory too often.

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Signed-off-by: John Stultz 
---
 xf86drmMode.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 8f8633e..c878d9e 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -1259,7 +1259,7 @@ drm_public drmModeAtomicReqPtr 
drmModeAtomicDuplicate(drmModeAtomicReqPtr old)
return NULL;
}
memcpy(new->items, old->items,
-  old->size_items * sizeof(*new->items));
+  old->cursor * sizeof(*new->items));
} else {
new->items = NULL;
}
@@ -1322,12 +1322,13 @@ drm_public int 
drmModeAtomicAddProperty(drmModeAtomicReqPtr req,
return -EINVAL;
 
if (req->cursor >= req->size_items) {
+   const uint32_t item_size_inc = getpagesize() / 
sizeof(*req->items);
drmModeAtomicReqItemPtr new;
 
-   req->size_items += 16;
+   req->size_items += item_size_inc;
new = realloc(req->items, req->size_items * 
sizeof(*req->items));
if (!new) {
-   req->size_items -= 16;
+   req->size_items -= item_size_inc;
return -ENOMEM;
}
req->items = new;
-- 
2.7.4

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

[RFC][PATCH 3/5] libdrm: Avoid additional drm open close

[John Stultz]

From: Prabhanjan Kandula 

Avoid additional drm device open and close.

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Signed-off-by: John Stultz 
---
 xf86drm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index fe822ca..2c19376 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -750,8 +750,8 @@ drm_public int drmOpen(const char *name, const char *busid)
  */
 drm_public int drmOpenWithType(const char *name, const char *busid, int type)
 {
-if (!drmAvailable() && name != NULL && drm_server_info &&
-drm_server_info->load_module) {
+if (name != NULL && drm_server_info &&
+drm_server_info->load_module && !drmAvailable()) {
 /* try to load the kernel module */
 if (!drm_server_info->load_module(name)) {
 drmMsg("[drm] failed to load kernel module \"%s\"\n", name);
-- 
2.7.4

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

[RFC][PATCH 1/5] libdrm: Use mmap64 instead of __mmap2

[John Stultz]

From: Sean Paul 

__mmap2 isn't supported on all platforms, mmap64 is the right way
to do this in android.

Also folds in a fix from Stéphane Marchesin 
to use an offset in bytes not pages, as that's what mmap64 takes.

Cc: Emil Velikov 
Cc: Sean Paul 
Cc: Alistair Strachan 
Cc: Marissa Wall 
Signed-off-by: Sean Paul 
Signed-off-by: John Stultz 
---
 libdrm_macros.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libdrm_macros.h b/libdrm_macros.h
index 95f0ef5..0dca827 100644
--- a/libdrm_macros.h
+++ b/libdrm_macros.h
@@ -48,8 +48,6 @@
 #if defined(ANDROID) && !defined(__LP64__)
 #include  /* for EINVAL */
 
-extern void *__mmap2(void *, size_t, int, int, int, size_t);
-
 static inline void *drm_mmap(void *addr, size_t length, int prot, int flags,
  int fd, loff_t offset)
 {
@@ -59,7 +57,7 @@ static inline void *drm_mmap(void *addr, size_t length, int 
prot, int flags,
   return MAP_FAILED;
}
 
-   return __mmap2(addr, length, prot, flags, fd, (size_t) (offset >> 12));
+   return mmap64(addr, length, prot, flags, fd, offset);
 }
 
 #  define drm_munmap(addr, length) \
-- 
2.7.4

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