[PATCH] drm/qxl: use ttm_tt

2018-11-06 Thread Gerd Hoffmann
qxl device will not dma, so we don't need ttm_dma_tt.  Go use ttm_tt
instead, to avoid wasting resources (swiotlb bounce buffers for
example).

Signed-off-by: Gerd Hoffmann 
---
 drivers/gpu/drm/qxl/qxl_ttm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 559a101138..7a778a46a2 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -252,7 +252,7 @@ static void qxl_ttm_io_mem_free(struct ttm_bo_device *bdev,
  * TTM backend functions.
  */
 struct qxl_ttm_tt {
-   struct ttm_dma_tt   ttm;
+   struct ttm_tt   ttm;
struct qxl_device   *qdev;
u64 offset;
 };
@@ -281,7 +281,7 @@ static void qxl_ttm_backend_destroy(struct ttm_tt *ttm)
 {
struct qxl_ttm_tt *gtt = (void *)ttm;
 
-   ttm_dma_tt_fini(>ttm);
+   ttm_tt_fini(>ttm);
kfree(gtt);
 }
 
@@ -301,13 +301,13 @@ static struct ttm_tt *qxl_ttm_tt_create(struct 
ttm_buffer_object *bo,
gtt = kzalloc(sizeof(struct qxl_ttm_tt), GFP_KERNEL);
if (gtt == NULL)
return NULL;
-   gtt->ttm.ttm.func = _backend_func;
+   gtt->ttm.func = _backend_func;
gtt->qdev = qdev;
-   if (ttm_dma_tt_init(>ttm, bo, page_flags)) {
+   if (ttm_tt_init(>ttm, bo, page_flags)) {
kfree(gtt);
return NULL;
}
-   return >ttm.ttm;
+   return >ttm;
 }
 
 static void qxl_move_null(struct ttm_buffer_object *bo,
-- 
2.9.3

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


[Bug 108685] Raven Ridge: VMC page fault on resume from suspend

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108685

Bug ID: 108685
   Summary: Raven Ridge: VMC page fault on resume from suspend
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: samant...@posteo.net

Created attachment 142395
  --> https://bugs.freedesktop.org/attachment.cgi?id=142395=edit
kernel log with lockup on resume

This is using 4.20.0-rc1-2.g0587eb8. I believe this is the issue I have had in
the past where the system does not resume from suspend, or at least the
graphics are locked up when I do.

I am able to fix these resume from suspend gpu lockups by using a script to
disable C6 states on the CPU before suspend and then enabling C6 states on
resume (this uses zenstates.py to set MSR through a systemd sleep script).

Nov 06 20:26:29 kernel: gmc_v9_0_process_interrupt: 35 callbacks suppressed
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200135
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200135
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200135
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: amdgpu :05:00.0: [mmhub] VMC page fault (src_id:0
ring:154 vmid:2 pasid:32771, for process kwin_x11 pid 2792 thread amdgpu_cs:0
pid 2906)
Nov 06 20:26:29 kernel: amdgpu :05:00.0:   in page starting at address
0x800100aaa000 from 18
Nov 06 20:26:29 kernel: amdgpu :05:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00200134
Nov 06 20:26:29 kernel: PM: suspend exit

-- 
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: [radeon-alex:amd-staging-drm-next 12/15] drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:117:1: warning: the frame size of 1040 bytes is larger than 1024 bytes

2018-11-06 Thread Zhang, Hawking
Fixed and pushed. Thanks.

Regards,
Hawking

-Original Message-
From: kbuild test robot  
Sent: 2018年11月7日 5:20
To: Zhang, Hawking 
Cc: kbuild-...@01.org; dri-devel@lists.freedesktop.org; Deucher, Alexander 
; Liu, Shaoyun 
Subject: [radeon-alex:amd-staging-drm-next 12/15] 
drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:117:1: warning: the frame size of 
1040 bytes is larger than 1024 bytes

tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   3902c0af567d658245ac01f2e33b39b2ff1ddd75
commit: 08dda26796ddd8a83e3b3568dc44e65a3108c56f [12/15] drm/amdgpu/psp: update 
topology info structures
config: i386-randconfig-s2-201844 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 08dda26796ddd8a83e3b3568dc44e65a3108c56f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c: In function 
'amdgpu_xgmi_add_device':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:117:1: warning: the frame size of 
>> 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +117 drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c

230dee18 Shaoyun Liu   2018-06-27   63  
230dee18 Shaoyun Liu   2018-06-27   64  int amdgpu_xgmi_add_device(struct 
amdgpu_device *adev)
230dee18 Shaoyun Liu   2018-06-27   65  {
08dda267 Hawking Zhang 2018-09-29   66  struct psp_xgmi_topology_info 
tmp_topology;
230dee18 Shaoyun Liu   2018-06-27   67  struct amdgpu_hive_info *hive;
230dee18 Shaoyun Liu   2018-06-27   68  struct amdgpu_xgmi  *entry;
230dee18 Shaoyun Liu   2018-06-27   69  struct amdgpu_device
*tmp_adev;
230dee18 Shaoyun Liu   2018-06-27   70  
230dee18 Shaoyun Liu   2018-06-27   71  int count = 0, ret = -EINVAL;
230dee18 Shaoyun Liu   2018-06-27   72  
230dee18 Shaoyun Liu   2018-06-27   73  if ((adev->asic_type < 
CHIP_VEGA20) ||
230dee18 Shaoyun Liu   2018-06-27   74  (adev->flags & 
AMD_IS_APU) )
230dee18 Shaoyun Liu   2018-06-27   75  return 0;
4eb24be0 Hawking Zhang 2018-09-28   76  adev->gmc.xgmi.node_id = 
psp_xgmi_get_node_id(>psp);
230dee18 Shaoyun Liu   2018-06-27   77  adev->gmc.xgmi.hive_id = 
psp_xgmi_get_hive_id(>psp);
230dee18 Shaoyun Liu   2018-06-27   78  
08dda267 Hawking Zhang 2018-09-29   79  memset(_topology, 0, 
sizeof(tmp_topology));
230dee18 Shaoyun Liu   2018-06-27   80  mutex_lock(_mutex);
230dee18 Shaoyun Liu   2018-06-27   81  hive = 
amdgpu_get_xgmi_hive(adev);
230dee18 Shaoyun Liu   2018-06-27   82  if (!hive)
230dee18 Shaoyun Liu   2018-06-27   83  goto exit;
230dee18 Shaoyun Liu   2018-06-27   84  
230dee18 Shaoyun Liu   2018-06-27   85  
list_add_tail(>gmc.xgmi.head, >device_list);
230dee18 Shaoyun Liu   2018-06-27   86  list_for_each_entry(entry, 
>device_list, head)
08dda267 Hawking Zhang 2018-09-29   87  
tmp_topology.nodes[count++].node_id = entry->node_id;
230dee18 Shaoyun Liu   2018-06-27   88  
08dda267 Hawking Zhang 2018-09-29   89  ret = 
psp_xgmi_get_topology_info(>psp, count, _topology);
230dee18 Shaoyun Liu   2018-06-27   90  if (ret) {
230dee18 Shaoyun Liu   2018-06-27   91  dev_err(adev->dev,
230dee18 Shaoyun Liu   2018-06-27   92  "XGMI: Get 
topology failure on device %llx, hive %llx, ret %d",
4eb24be0 Hawking Zhang 2018-09-28   93  
adev->gmc.xgmi.node_id,
230dee18 Shaoyun Liu   2018-06-27   94  
adev->gmc.xgmi.hive_id, ret);
230dee18 Shaoyun Liu   2018-06-27   95  goto exit;
230dee18 Shaoyun Liu   2018-06-27   96  }
230dee18 Shaoyun Liu   2018-06-27   97  /* Each psp need to set the 
latest topology */
230dee18 Shaoyun Liu   2018-06-27   98  list_for_each_entry(tmp_adev, 
>device_list, gmc.xgmi.head) {
08dda267 Hawking Zhang 2018-09-29   99  ret = 
psp_xgmi_set_topology_info(_adev->psp, count, _topology);
230dee18 Shaoyun Liu   2018-06-27  100  if (ret) {
230dee18 Shaoyun Liu   2018-06-27  101  
dev_err(tmp_adev->dev,
230dee18 Shaoyun Liu   2018-06-27  102  "XGMI: 
Set topology failure on device %llx, hive %llx, ret %d",
4eb24be0 Hawking Zhang 2018-09-28  103  
tmp_adev->gmc.xgmi.node_id,
230dee18 Shaoyun Liu   2018-06-27  104  
tmp_adev->gmc.xgmi.hive_id, ret);
230dee18 Shaoyun Liu   2018-06-27  105  /* To do : 
continue with some  node failed or disable the  whole  hive */
230dee18 Shaoyun Liu   2018-06-27  106  break;
230dee18 Shaoyun Liu   2018-06-27  107  }
230dee18 Shaoyun Liu   2018-06-27  108  }
230dee18 Shaoyun Liu   2018-06-27  109  

Re: [v7 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:31:20PM -0800, Anusha Srivatsa wrote:
> If the panel supports FEC, the driver has to
> set the FEC_READY bit in the dpcd register:
> FEC_CONFIGURATION.
> 
> This has to happen before link training.
> 
> v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
>- change commit message. (Gaurav)
> 
> v3: rebased. (r-b Manasi)
> 
> v4: Use fec crtc state, before setting FEC_READY
> bit. (Anusha)
> 
> v5: Move to intel_ddi.c
> - Make the function static (Anusha)
> 
> v6: Dont pass state as a separate argument (Ville)
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Gaurav K Singh 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 

Reviewed-by: Manasi Navare 

Manasi

> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 46c1b9e12fbd..850c16200759 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3051,6 +3051,16 @@ static void icl_program_mg_dp_mode(struct 
> intel_digital_port *intel_dig_port)
>   I915_WRITE(MG_DP_MODE(port, 1), ln1);
>  }
>  
> +static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> + const struct intel_crtc_state 
> *crtc_state)
> +{
> + if (!crtc_state->fec_enable)
> + return;
> +
> + if (drm_dp_dpcd_writeb(_dp->aux, DP_FEC_CONFIGURATION, 
> DP_FEC_READY) <= 0)
> + DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> +}
> +
>  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state 
> *conn_state)
> @@ -3091,6 +3101,7 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> true);
> + intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
>   intel_dp_start_link_train(intel_dp);
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
> -- 
> 2.19.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [v7 1/4] i915/dp/fec: Add fec_enable to the crtc state.

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:31:19PM -0800, Anusha Srivatsa wrote:
> For DP 1.4 and above, Display Stream compression can be
> enabled only if Forward Error Correctin can be performed.
> 
> Add a crtc state for FEC. Currently, the state
> is determined by platform, DP and DSC being
> enabled. Moving forward we can use the state
> to have error correction on other scenarios too
> if needed.
> 
> v2:
> - Control compression_enable with the fec_enable
> parameter in crtc state and with intel_dp_supports_fec()
> (Ville)
> 
> - intel_dp_can_fec()/intel_dp_supports_fec()(manasi)
> 
> v3: Check for FEC support along with setting crtc state.
> 
> v4: add checks to intel_dp_source_supports_dsc.(manasi)
> - Move intel_dp_supports_fec() closer to
> intel_dp_supports_dsc() (Anusha)
> 
> v5: Move fec check to intel_dp_supports_dsc(Ville)
> 
> v6: Remove warning. rebase.
> 
> v7: change crtc state to include DP sink and fec capability
> of source.(Manasi)
> 
> Suggested-by: Ville Syrjala 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Ville Syrjala 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_dp.c  | 31 +--
>  drivers/gpu/drm/i915/intel_drv.h |  3 +++
>  2 files changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 73c00c5acf14..f764c45deaab 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -545,7 +545,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
>   dsc_slice_count =
>   
> drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
>   true);
> - } else {
> + } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
>   dsc_max_output_bpp =
>   intel_dp_dsc_get_output_bpp(max_link_clock,
>   max_lanes,
> @@ -1710,12 +1710,27 @@ struct link_config_limits {
>   int min_bpp, max_bpp;
>  };
>  
> +static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
> +  const struct intel_crtc_state 
> *pipe_config)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> +
> + return INTEL_GEN(dev_priv) >= 11 && pipe_config->cpu_transcoder != 
> TRANSCODER_A;
> +}
> +
> +static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
> +   const struct intel_crtc_state *pipe_config)
> +{
> + return intel_dp_source_supports_fec(intel_dp, pipe_config) &&
> + drm_dp_sink_supports_fec(intel_dp->fec_capable);
> +}
> +
>  static bool intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
>const struct intel_crtc_state 
> *pipe_config)
>  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>  
> - /* FIXME: FEC needed for external DP until then reject DSC on DP */
>   if (!intel_dp_is_edp(intel_dp))
>   return false;

No point in keeping this !edp condition here, thats supposed to go with FEC 
check,
move that to where fec_supports is added.

>  
> @@ -1726,6 +1741,9 @@ static bool intel_dp_source_supports_dsc(struct 
> intel_dp *intel_dp,
>  static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
> const struct intel_crtc_state *pipe_config)
>  {
> + if (!pipe_config->fec_enable)
> + return false;

I think its better to use intel_dp_supports_fec(intel_dp, pipe_config) && !edp 
instead
of pipe_config->fec_enable because pipe_config->fec_enable state will be set 
only in dp_compute_config

> +
>   if (!intel_dp_source_supports_dsc(intel_dp, pipe_config) ||
>   !drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))
>   return false;
> @@ -1886,9 +1904,18 @@ static bool intel_dp_dsc_compute_config(struct 
> intel_dp *intel_dp,
>   u16 dsc_max_output_bpp = 0;
>   u8 dsc_dp_slice_count = 0;
>  
> + pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
> +   intel_dp_supports_fec(intel_dp, pipe_config);

Why is pipe_config->fec_enable set in dsc_compute_config()? This state is 
totally indepenedent of dsc state
and we are treating this as an independent feature. I think the earlier place 
of setting this in intel_dp_compute_link_config()
is correct

Manasi

> +
>   if (!intel_dp_supports_dsc(intel_dp, pipe_config))
>   return false;
>  
> + /* DSC not supported if external DP sink does not support FEC */
> + if (!pipe_config->fec_enable) {
> + DRM_DEBUG_KMS("Sink does not support Forward Error Correction, 
> disabling Display Compression\n");
> + return false;
> + }
> +

[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #8 from drigohighlander (drigos...@gmail.com) ---
Yesterday (05/11/2018 DD/MM/) I upgraded again my system to kernel 4.19.1
and the other packages: xorg-server-1.20.3-x86_64-1, mesa-18.2.4-x86_64-1,
xf86-video-amdgpu-18.1.0-x86_64-1. Still got the very poor performance, almost
unusable. All the packages are official. Please help me to fix this.

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #7 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279365
  --> https://bugzilla.kernel.org/attachment.cgi?id=279365=edit
Glxinfo from the old system (the fast viewport one) > kernel 4.9.50

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

drigohighlander (drigos...@gmail.com) changed:

   What|Removed |Added

 Attachment #279361|Xorg from the old system|Xorg from the old system
description|(the fast viewport one) |(the fast viewport one) >
   |>kernel 4.9.50  |kernel 4.9.50

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #6 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279363
  --> https://bugzilla.kernel.org/attachment.cgi?id=279363=edit
Dmesg from the old system (the fast viewport one) > kernel 4.9.50

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #5 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279361
  --> https://bugzilla.kernel.org/attachment.cgi?id=279361=edit
Xorg from the old system (the fast viewport one) >kernel 4.9.50

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #4 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279359
  --> https://bugzilla.kernel.org/attachment.cgi?id=279359=edit
Glxinfo from the new system > kernel 4.19.1

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

drigohighlander (drigos...@gmail.com) changed:

   What|Removed |Added

 Attachment #279357|Dmesg from the new system   |Dmesg from the new system
description|-> kernel 4.19. |-> kernel 4.19.1

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #3 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279357
  --> https://bugzilla.kernel.org/attachment.cgi?id=279357=edit
Dmesg from the new system -> kernel 4.19.

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

--- Comment #2 from drigohighlander (drigos...@gmail.com) ---
Created attachment 279355
  --> https://bugzilla.kernel.org/attachment.cgi?id=279355=edit
Xorg from the new system -> kernel 4.19.1

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


[PATCH RESEND v3 4/5] drm/nouveau: Use atomic VCPI helpers for MST

2018-11-06 Thread Lyude Paul
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.

So, drop usage of the old helpers and move entirely over to the atomic
helpers.

Signed-off-by: Lyude Paul 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 50 +
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6cbbae3f438b..0469ef9e1a54 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -747,16 +747,22 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
   struct drm_crtc_state *crtc_state,
   struct drm_connector_state *conn_state)
 {
-   struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+   struct drm_atomic_state *state = crtc_state->state;
+   struct drm_connector *connector = conn_state->connector;
+   struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
-   int bpp = conn_state->connector->display_info.bpc * 3;
+   int bpp = connector->display_info.bpc * 3;
int slots;
 
-   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
-
-   slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
-   if (slots < 0)
-   return slots;
+   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
+   /* Zombies don't need VCPI */
+   if (!drm_connector_is_unregistered(connector)) {
+   slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
+ mstc->port, mstc->pbn);
+   if (slots < 0)
+   return slots;
+   }
 
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
   mstc->native);
@@ -920,12 +926,38 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
 }
 
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+  struct drm_connector_state *new_conn_state)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct nv50_mstc *mstc = nv50_mstc(connector);
+   struct drm_dp_mst_topology_mgr *mgr = >mstm->mgr;
+   struct drm_connector_state *old_conn_state;
+   struct drm_crtc *old_crtc;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   old_crtc = old_conn_state->crtc;
+
+   /* We only need to release VCPI here if we're going from having a CRTC
+* on this connector, to not having one
+*/
+   if (!old_crtc || new_conn_state->crtc)
+   return 0;
+
+   /* Release the previous VCPI allocation since the encoder's
+* atomic_check() won't be called
+*/
+   return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
 static const struct drm_connector_helper_funcs
 nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+   .atomic_check = nv50_mstc_atomic_check,
 };
 
 static enum drm_connector_status
@@ -2109,6 +2141,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
return ret;
}
 
+   ret = drm_dp_mst_atomic_check(state);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.19.1

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


[PATCH RESEND v3 2/5] drm/dp_mst: Start tracking per-port VCPI allocations

2018-11-06 Thread Lyude Paul
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:

/* We cannot rely on port->vcpi.num_slots to update
 * topology_state->avail_slots as the port may not exist if the parent
 * branch device was unplugged. This should be fixed by tracking
 * per-port slot allocation in drm_dp_mst_topology_state instead of
 * depending on the caller to tell us how many slots to release.
 */

That's not the only reason we should fix this: forcing the driver to
track the VCPI allocations throughout a state's atomic check is
error prone, because it means that extra care has to be taken with the
order that drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
idempotency. Currently the only driver actually using these helpers,
i915, doesn't even do this correctly: multiple ->best_encoder() checks
with i915's current implementation would not be idempotent and would
over-allocate VCPI slots, something I learned trying to implement
fallback retraining in MST.

So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
each port. This allows us to ensure idempotency without having to rely
on the driver as much. Additionally: the driver doesn't need to do any
kind of VCPI slot tracking anymore if it doesn't need it for it's own
internal state.

Additionally; this adds a new drm_dp_mst_atomic_check() helper which
must be used by atomic drivers to perform validity checks for the new
VCPI allocations incurred by a state.

Also: update the documentation and make it more obvious that these
/must/ be called by /all/ atomic drivers supporting MST.

Changes since v2:
 - Use kmemdup() for duplicating MST state - danvet
 - Move port validation out of duplicate state callback - danvet
 - Handle looping through MST topology states in
   drm_dp_mst_atomic_check() so the driver doesn't have to do it
 - Fix documentation in drm_dp_atomic_find_vcpi_slots()
 - Move the atomic check for each individual topology state into it's
   own function, reduces indenting
 - Don't consider "stale" MST ports when calculating the bandwidth
   requirements. This is needed because originally we relied on the
   state duplication functions to prune any stale ports from the new
   state, which would prevent us from incorrectly considering their
   bandwidth requirements alongside legitimate new payloads.
 - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet
 - Annotate atomic VCPI and atomic check functions with __must_check
   - danvet

Changes since v1:
 - Don't use the now-removed ->atomic_check() for private objects hook,
   just give drivers a function to call themselves

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 222 ++
 drivers/gpu/drm/i915/intel_display.c  |   4 +
 drivers/gpu/drm/i915/intel_dp_mst.c   |  31 ++--
 include/drm/drm_dp_mst_helper.h   |  23 ++-
 4 files changed, 225 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 8c3cfac437f4..74823afb262e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2614,21 +2614,34 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 
 /**
- * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
+ * drm_dp_atomic_find_vcpi_slots() - Find and add VCPI slots to the state
  * @state: global atomic state
  * @mgr: MST topology manager for the port
  * @port: port to find vcpi slots for
  * @pbn: bandwidth required for the mode in PBN
  *
- * RETURNS:
- * Total slots in the atomic state assigned for this port or error
+ * Allocates VCPI slots to @port, replacing any previous VCPI allocations it
+ * may have had. Any atomic drivers which support MST must call this function
+ * in their _encoder_helper_funcs.atomic_check() callback to change the
+ * current VCPI allocation for the new state. The allocations are not checked
+ * against the bandwidth restraints of @mgr until the driver calls
+ * drm_dp_mst_atomic_check().
+ *
+ * See also:
+ * drm_dp_atomic_release_vcpi_slots()
+ * drm_dp_mst_atomic_check()
+ *
+ * Returns:
+ * Total slots in the atomic state assigned for this port, or a negative error
+ * code if the port no longer exists
  */
 int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
  struct drm_dp_mst_topology_mgr *mgr,
  struct drm_dp_mst_port *port, int pbn)
 {
struct drm_dp_mst_topology_state *topology_state;
-   int req_slots;
+   struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
+   int prev_slots, req_slots, ret;
 
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
@@ -2637,20 +2650,41 @@ 

[PATCH RESEND v3 5/5] drm/dp_mst: Stop unsetting mstc->port, check connector registration

2018-11-06 Thread Lyude Paul
Same thing we did in i915, but for nouveau now.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0469ef9e1a54..ff04a56b5949 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -698,8 +698,10 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
 
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
-   if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+   if (!drm_connector_is_unregistered(>connector) &&
+   mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
drm_dp_mst_deallocate_vcpi(>mgr, mstc->port);
+
if (msto->disabled) {
msto->mstc = NULL;
msto->head = NULL;
@@ -725,7 +727,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
 
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
-   if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+   if (!drm_connector_is_unregistered(>connector) &&
+   mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -828,7 +831,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
 
-   if (mstc->port)
+   if (!drm_connector_is_unregistered(>connector))
drm_dp_mst_reset_vcpi_slots(>mgr, mstc->port);
 
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
@@ -967,7 +970,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status conn_status;
int ret;
 
-   if (!mstc->port)
+   if (drm_connector_is_unregistered(>connector))
return connector_status_disconnected;
 
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -1105,10 +1108,6 @@ nv50_mstm_destroy_connector(struct 
drm_dp_mst_topology_mgr *mgr,
 
drm_fb_helper_remove_one_connector(>fbcon->helper, 
>connector);
 
-   drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
-   mstc->port = NULL;
-   drm_modeset_unlock(>dev->mode_config.connection_mutex);
-
drm_connector_put(>connector);
 }
 
-- 
2.19.1

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


[PATCH RESEND v3 1/5] drm/dp_mst: Add some atomic state iterator macros

2018-11-06 Thread Lyude Paul
Signed-off-by: Lyude Paul 
Reviewed-by: Daniel Vetter 
---
 include/drm/drm_dp_mst_helper.h | 77 +
 1 file changed, 77 insertions(+)

diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 59f005b419cf..3faceb66f5cb 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -628,4 +628,81 @@ int drm_dp_atomic_release_vcpi_slots(struct 
drm_atomic_state *state,
 int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr *mgr,
 struct drm_dp_mst_port *port, bool power_up);
 
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr **mgr,
+   struct drm_dp_mst_topology_state **old_state,
+   struct drm_dp_mst_topology_state **new_state,
+   int i)
+{
+   struct __drm_private_objs_state *objs_state = >private_objs[i];
+
+   if (objs_state->ptr->funcs != _dp_mst_topology_state_funcs)
+   return false;
+
+   *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+   if (old_state)
+   *old_state = to_dp_mst_topology_state(objs_state->old_state);
+   if (new_state)
+   *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+   return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @old_state:  drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state:  drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state, 
__i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @old_state:  drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking only the old state. This is useful in disable functions, where we
+ * need the old state the hardware is still in.
+ */
+#define for_each_old_mst_mgr_in_state(__state, mgr, old_state, __i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
&(old_state), NULL, (__i)))
+
+/**
+ * for_each_new_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @new_state:  drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking only the new state. This is useful in enable functions, where we
+ * need the new state the hardware should be in when the atomic commit
+ * operation has completed.
+ */
+#define for_each_new_mst_mgr_in_state(__state, mgr, new_state, __i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
NULL, &(new_state), (__i)))
+
 #endif
-- 
2.19.1

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


[PATCH RESEND v3 3/5] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()

2018-11-06 Thread Lyude Paul
It occurred to me that we never actually check this! So let's start
doing that.

Signed-off-by: Lyude Paul 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 74823afb262e..8ef0c5f5c7cf 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3213,7 +3213,7 @@ drm_dp_mst_atomic_check_topology_state(struct 
drm_dp_mst_topology_mgr *mgr,
 {
struct drm_dp_vcpi_allocation *vcpi;
struct drm_dp_mst_port *port;
-   int avail_slots = 63, ret;
+   int avail_slots = 63, payload_count = 0, ret;
 
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Ports that no longer exist shouldn't be counted towards the
@@ -3238,6 +3238,13 @@ drm_dp_mst_atomic_check_topology_state(struct 
drm_dp_mst_topology_mgr *mgr,
goto port_fail;
}
 
+   if (++payload_count > mgr->max_payloads) {
+   DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many 
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+   ret = -EINVAL;
+   goto port_fail;
+   }
+
drm_dp_put_port(port);
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst_state %p vcpi avail=%d used=%d\n",
-- 
2.19.1

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


[PATCH RESEND v3 0/5] drm/dp_mst: Improve VCPI helpers, use in nouveau

2018-11-06 Thread Lyude Paul
[sorry about the resend-copy pasted the wrong header and I want to make
sure this doesn't get missed!]

This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.

Cc: Daniel Vetter 

Lyude Paul (5):
  drm/dp_mst: Add some atomic state iterator macros
  drm/dp_mst: Start tracking per-port VCPI allocations
  drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
  drm/nouveau: Use atomic VCPI helpers for MST
  drm/dp_mst: Stop unsetting mstc->port, check connector registration

 drivers/gpu/drm/drm_dp_mst_topology.c   | 229 
 drivers/gpu/drm/i915/intel_display.c|   4 +
 drivers/gpu/drm/i915/intel_dp_mst.c |  31 ++--
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  65 +--
 include/drm/drm_dp_mst_helper.h | 100 ++-
 5 files changed, 359 insertions(+), 70 deletions(-)

-- 
2.19.1

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


[PATCH v3 1/5] drm/dp_mst: Add some atomic state iterator macros

2018-11-06 Thread Lyude Paul
Signed-off-by: Lyude Paul 
Reviewed-by: Daniel Vetter 
---
 include/drm/drm_dp_mst_helper.h | 77 +
 1 file changed, 77 insertions(+)

diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 59f005b419cf..3faceb66f5cb 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -628,4 +628,81 @@ int drm_dp_atomic_release_vcpi_slots(struct 
drm_atomic_state *state,
 int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr *mgr,
 struct drm_dp_mst_port *port, bool power_up);
 
+extern const struct drm_private_state_funcs drm_dp_mst_topology_state_funcs;
+
+static inline bool
+__drm_dp_mst_state_iter_get(struct drm_atomic_state *state,
+   struct drm_dp_mst_topology_mgr **mgr,
+   struct drm_dp_mst_topology_state **old_state,
+   struct drm_dp_mst_topology_state **new_state,
+   int i)
+{
+   struct __drm_private_objs_state *objs_state = >private_objs[i];
+
+   if (objs_state->ptr->funcs != _dp_mst_topology_state_funcs)
+   return false;
+
+   *mgr = to_dp_mst_topology_mgr(objs_state->ptr);
+   if (old_state)
+   *old_state = to_dp_mst_topology_state(objs_state->old_state);
+   if (new_state)
+   *new_state = to_dp_mst_topology_state(objs_state->new_state);
+
+   return true;
+}
+
+/**
+ * for_each_oldnew_mst_mgr_in_state - iterate over all DP MST topology
+ * managers in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @old_state:  drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @new_state:  drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking both old and new state. This is useful in places where the state
+ * delta needs to be considered, for example in atomic check functions.
+ */
+#define for_each_oldnew_mst_mgr_in_state(__state, mgr, old_state, new_state, 
__i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
&(old_state), &(new_state), (__i)))
+
+/**
+ * for_each_old_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @old_state:  drm_dp_mst_topology_state iteration cursor for the old
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking only the old state. This is useful in disable functions, where we
+ * need the old state the hardware is still in.
+ */
+#define for_each_old_mst_mgr_in_state(__state, mgr, old_state, __i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
&(old_state), NULL, (__i)))
+
+/**
+ * for_each_new_mst_mgr_in_state - iterate over all DP MST topology managers
+ * in an atomic update
+ * @__state:  drm_atomic_state pointer
+ * @mgr:  drm_dp_mst_topology_mgr iteration cursor
+ * @new_state:  drm_dp_mst_topology_state iteration cursor for the new
+ * state
+ * @__i: int iteration cursor, for macro-internal use
+ *
+ * This iterates over all DRM DP MST topology managers in an atomic update,
+ * tracking only the new state. This is useful in enable functions, where we
+ * need the new state the hardware should be in when the atomic commit
+ * operation has completed.
+ */
+#define for_each_new_mst_mgr_in_state(__state, mgr, new_state, __i) \
+   for ((__i) = 0; (__i) < (__state)->num_private_objs; (__i)++) \
+   for_each_if(__drm_dp_mst_state_iter_get((__state), &(mgr), 
NULL, &(new_state), (__i)))
+
 #endif
-- 
2.19.1

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


[PATCH v3 3/5] drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()

2018-11-06 Thread Lyude Paul
It occurred to me that we never actually check this! So let's start
doing that.

Signed-off-by: Lyude Paul 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 74823afb262e..8ef0c5f5c7cf 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3213,7 +3213,7 @@ drm_dp_mst_atomic_check_topology_state(struct 
drm_dp_mst_topology_mgr *mgr,
 {
struct drm_dp_vcpi_allocation *vcpi;
struct drm_dp_mst_port *port;
-   int avail_slots = 63, ret;
+   int avail_slots = 63, payload_count = 0, ret;
 
list_for_each_entry(vcpi, _state->vcpis, next) {
/* Ports that no longer exist shouldn't be counted towards the
@@ -3238,6 +3238,13 @@ drm_dp_mst_atomic_check_topology_state(struct 
drm_dp_mst_topology_mgr *mgr,
goto port_fail;
}
 
+   if (++payload_count > mgr->max_payloads) {
+   DRM_DEBUG_ATOMIC("[MST MGR:%p] state %p has too many 
payloads (max=%d)\n",
+mgr, mst_state, mgr->max_payloads);
+   ret = -EINVAL;
+   goto port_fail;
+   }
+
drm_dp_put_port(port);
}
DRM_DEBUG_ATOMIC("[MST MGR:%p] mst_state %p vcpi avail=%d used=%d\n",
-- 
2.19.1

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


[PATCH v3 4/5] drm/nouveau: Use atomic VCPI helpers for MST

2018-11-06 Thread Lyude Paul
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actually check whether or not the topology still has
enough bandwidth to provide the VCPI tokens required.

So, drop usage of the old helpers and move entirely over to the atomic
helpers.

Signed-off-by: Lyude Paul 
Acked-by: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 50 +
 1 file changed, 43 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6cbbae3f438b..0469ef9e1a54 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -747,16 +747,22 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
   struct drm_crtc_state *crtc_state,
   struct drm_connector_state *conn_state)
 {
-   struct nv50_mstc *mstc = nv50_mstc(conn_state->connector);
+   struct drm_atomic_state *state = crtc_state->state;
+   struct drm_connector *connector = conn_state->connector;
+   struct nv50_mstc *mstc = nv50_mstc(connector);
struct nv50_mstm *mstm = mstc->mstm;
-   int bpp = conn_state->connector->display_info.bpc * 3;
+   int bpp = connector->display_info.bpc * 3;
int slots;
 
-   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, bpp);
-
-   slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
-   if (slots < 0)
-   return slots;
+   mstc->pbn = drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock,
+bpp);
+   /* Zombies don't need VCPI */
+   if (!drm_connector_is_unregistered(connector)) {
+   slots = drm_dp_atomic_find_vcpi_slots(state, >mgr,
+ mstc->port, mstc->pbn);
+   if (slots < 0)
+   return slots;
+   }
 
return nv50_outp_atomic_check_view(encoder, crtc_state, conn_state,
   mstc->native);
@@ -920,12 +926,38 @@ nv50_mstc_get_modes(struct drm_connector *connector)
return ret;
 }
 
+static int
+nv50_mstc_atomic_check(struct drm_connector *connector,
+  struct drm_connector_state *new_conn_state)
+{
+   struct drm_atomic_state *state = new_conn_state->state;
+   struct nv50_mstc *mstc = nv50_mstc(connector);
+   struct drm_dp_mst_topology_mgr *mgr = >mstm->mgr;
+   struct drm_connector_state *old_conn_state;
+   struct drm_crtc *old_crtc;
+
+   old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+   old_crtc = old_conn_state->crtc;
+
+   /* We only need to release VCPI here if we're going from having a CRTC
+* on this connector, to not having one
+*/
+   if (!old_crtc || new_conn_state->crtc)
+   return 0;
+
+   /* Release the previous VCPI allocation since the encoder's
+* atomic_check() won't be called
+*/
+   return drm_dp_atomic_release_vcpi_slots(state, mgr, mstc->port);
+}
+
 static const struct drm_connector_helper_funcs
 nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
.best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
+   .atomic_check = nv50_mstc_atomic_check,
 };
 
 static enum drm_connector_status
@@ -2109,6 +2141,10 @@ nv50_disp_atomic_check(struct drm_device *dev, struct 
drm_atomic_state *state)
return ret;
}
 
+   ret = drm_dp_mst_atomic_check(state);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.19.1

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


[PATCH v3 5/5] drm/dp_mst: Stop unsetting mstc->port, check connector registration

2018-11-06 Thread Lyude Paul
Same thing we did in i915, but for nouveau now.

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c 
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 0469ef9e1a54..ff04a56b5949 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -698,8 +698,10 @@ nv50_msto_cleanup(struct nv50_msto *msto)
struct nv50_mstm *mstm = mstc->mstm;
 
NV_ATOMIC(drm, "%s: msto cleanup\n", msto->encoder.name);
-   if (mstc->port && mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
+   if (!drm_connector_is_unregistered(>connector) &&
+   mstc->port->vcpi.vcpi > 0 && !nv50_msto_payload(msto))
drm_dp_mst_deallocate_vcpi(>mgr, mstc->port);
+
if (msto->disabled) {
msto->mstc = NULL;
msto->head = NULL;
@@ -725,7 +727,8 @@ nv50_msto_prepare(struct nv50_msto *msto)
};
 
NV_ATOMIC(drm, "%s: msto prepare\n", msto->encoder.name);
-   if (mstc->port && mstc->port->vcpi.vcpi > 0) {
+   if (!drm_connector_is_unregistered(>connector) &&
+   mstc->port->vcpi.vcpi > 0) {
struct drm_dp_payload *payload = nv50_msto_payload(msto);
if (payload) {
args.vcpi.start_slot = payload->start_slot;
@@ -828,7 +831,7 @@ nv50_msto_disable(struct drm_encoder *encoder)
struct nv50_mstc *mstc = msto->mstc;
struct nv50_mstm *mstm = mstc->mstm;
 
-   if (mstc->port)
+   if (!drm_connector_is_unregistered(>connector))
drm_dp_mst_reset_vcpi_slots(>mgr, mstc->port);
 
mstm->outp->update(mstm->outp, msto->head->base.index, NULL, 0, 0);
@@ -967,7 +970,7 @@ nv50_mstc_detect(struct drm_connector *connector, bool 
force)
enum drm_connector_status conn_status;
int ret;
 
-   if (!mstc->port)
+   if (drm_connector_is_unregistered(>connector))
return connector_status_disconnected;
 
ret = pm_runtime_get_sync(connector->dev->dev);
@@ -1105,10 +1108,6 @@ nv50_mstm_destroy_connector(struct 
drm_dp_mst_topology_mgr *mgr,
 
drm_fb_helper_remove_one_connector(>fbcon->helper, 
>connector);
 
-   drm_modeset_lock(>dev->mode_config.connection_mutex, NULL);
-   mstc->port = NULL;
-   drm_modeset_unlock(>dev->mode_config.connection_mutex);
-
drm_connector_put(>connector);
 }
 
-- 
2.19.1

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


[PATCH v3 0/5] drm/dp_mst: Add some atomic state iterator macros

2018-11-06 Thread Lyude Paul
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.

Cc: Daniel Vetter 

Lyude Paul (5):
  drm/dp_mst: Add some atomic state iterator macros
  drm/dp_mst: Start tracking per-port VCPI allocations
  drm/dp_mst: Check payload count in drm_dp_mst_atomic_check()
  drm/nouveau: Use atomic VCPI helpers for MST
  drm/dp_mst: Stop unsetting mstc->port, check connector registration

 drivers/gpu/drm/drm_dp_mst_topology.c   | 229 
 drivers/gpu/drm/i915/intel_display.c|   4 +
 drivers/gpu/drm/i915/intel_dp_mst.c |  31 ++--
 drivers/gpu/drm/nouveau/dispnv50/disp.c |  65 +--
 include/drm/drm_dp_mst_helper.h | 100 ++-
 5 files changed, 359 insertions(+), 70 deletions(-)

-- 
2.19.1

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


[PATCH v3 2/5] drm/dp_mst: Start tracking per-port VCPI allocations

2018-11-06 Thread Lyude Paul
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:

/* We cannot rely on port->vcpi.num_slots to update
 * topology_state->avail_slots as the port may not exist if the parent
 * branch device was unplugged. This should be fixed by tracking
 * per-port slot allocation in drm_dp_mst_topology_state instead of
 * depending on the caller to tell us how many slots to release.
 */

That's not the only reason we should fix this: forcing the driver to
track the VCPI allocations throughout a state's atomic check is
error prone, because it means that extra care has to be taken with the
order that drm_dp_atomic_find_vcpi_slots() and
drm_dp_atomic_release_vcpi_slots() are called in in order to ensure
idempotency. Currently the only driver actually using these helpers,
i915, doesn't even do this correctly: multiple ->best_encoder() checks
with i915's current implementation would not be idempotent and would
over-allocate VCPI slots, something I learned trying to implement
fallback retraining in MST.

So: simplify this whole mess, and teach drm_dp_atomic_find_vcpi_slots()
and drm_dp_atomic_release_vcpi_slots() to track the VCPI allocations for
each port. This allows us to ensure idempotency without having to rely
on the driver as much. Additionally: the driver doesn't need to do any
kind of VCPI slot tracking anymore if it doesn't need it for it's own
internal state.

Additionally; this adds a new drm_dp_mst_atomic_check() helper which
must be used by atomic drivers to perform validity checks for the new
VCPI allocations incurred by a state.

Also: update the documentation and make it more obvious that these
/must/ be called by /all/ atomic drivers supporting MST.

Changes since v2:
 - Use kmemdup() for duplicating MST state - danvet
 - Move port validation out of duplicate state callback - danvet
 - Handle looping through MST topology states in
   drm_dp_mst_atomic_check() so the driver doesn't have to do it
 - Fix documentation in drm_dp_atomic_find_vcpi_slots()
 - Move the atomic check for each individual topology state into it's
   own function, reduces indenting
 - Don't consider "stale" MST ports when calculating the bandwidth
   requirements. This is needed because originally we relied on the
   state duplication functions to prune any stale ports from the new
   state, which would prevent us from incorrectly considering their
   bandwidth requirements alongside legitimate new payloads.
 - Add function references in drm_dp_atomic_release_vcpi_slots() - danvet
 - Annotate atomic VCPI and atomic check functions with __must_check
   - danvet

Changes since v1:
 - Don't use the now-removed ->atomic_check() for private objects hook,
   just give drivers a function to call themselves

Signed-off-by: Lyude Paul 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 222 ++
 drivers/gpu/drm/i915/intel_display.c  |   4 +
 drivers/gpu/drm/i915/intel_dp_mst.c   |  31 ++--
 include/drm/drm_dp_mst_helper.h   |  23 ++-
 4 files changed, 225 insertions(+), 55 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 8c3cfac437f4..74823afb262e 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2614,21 +2614,34 @@ static int drm_dp_init_vcpi(struct 
drm_dp_mst_topology_mgr *mgr,
 }
 
 /**
- * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state
+ * drm_dp_atomic_find_vcpi_slots() - Find and add VCPI slots to the state
  * @state: global atomic state
  * @mgr: MST topology manager for the port
  * @port: port to find vcpi slots for
  * @pbn: bandwidth required for the mode in PBN
  *
- * RETURNS:
- * Total slots in the atomic state assigned for this port or error
+ * Allocates VCPI slots to @port, replacing any previous VCPI allocations it
+ * may have had. Any atomic drivers which support MST must call this function
+ * in their _encoder_helper_funcs.atomic_check() callback to change the
+ * current VCPI allocation for the new state. The allocations are not checked
+ * against the bandwidth restraints of @mgr until the driver calls
+ * drm_dp_mst_atomic_check().
+ *
+ * See also:
+ * drm_dp_atomic_release_vcpi_slots()
+ * drm_dp_mst_atomic_check()
+ *
+ * Returns:
+ * Total slots in the atomic state assigned for this port, or a negative error
+ * code if the port no longer exists
  */
 int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state,
  struct drm_dp_mst_topology_mgr *mgr,
  struct drm_dp_mst_port *port, int pbn)
 {
struct drm_dp_mst_topology_state *topology_state;
-   int req_slots;
+   struct drm_dp_vcpi_allocation *pos, *vcpi = NULL;
+   int prev_slots, req_slots, ret;
 
topology_state = drm_atomic_get_mst_topology_state(state, mgr);
if (IS_ERR(topology_state))
@@ -2637,20 +2650,41 @@ 

[v7 3/4] i915/dp/fec: Configure the Forward Error Correction bits.

2018-11-06 Thread Anusha Srivatsa
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.

The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is already active while enabling FEC.

v2:
- Change commit message. Configure fec state after
  link training (Manasi, Gaurav)
- Remove redundent checks (Manasi)
- Remove the registers that get added automagically (Anusha)

v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)

v4: rebased.

v5:
- Move the code to the proper spot, according to spec.(Ville)
- Use fec state as a check too.

v6: Pass intel_encoder, instead of intel_dp. (Ville)

v7: Remove unwanted comments (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h  |  2 ++
 drivers/gpu/drm/i915/intel_ddi.c | 23 +++
 2 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a84e8f98e66..209b64d2f27a 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -9148,6 +9148,7 @@ enum skl_power_gate {
 #define _DP_TP_CTL_B   0x64140
 #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
 #define  DP_TP_CTL_ENABLE  (1 << 31)
+#define  DP_TP_CTL_FEC_ENABLE  (1 << 30)
 #define  DP_TP_CTL_MODE_SST(0 << 27)
 #define  DP_TP_CTL_MODE_MST(1 << 27)
 #define  DP_TP_CTL_FORCE_ACT   (1 << 25)
@@ -9166,6 +9167,7 @@ enum skl_power_gate {
 #define _DP_TP_STATUS_A0x64044
 #define _DP_TP_STATUS_B0x64144
 #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, _DP_TP_STATUS_B)
+#define  DP_TP_STATUS_FEC_ENABLE_LIVE  (1 << 28)
 #define  DP_TP_STATUS_IDLE_DONE(1 << 25)
 #define  DP_TP_STATUS_ACT_SENT (1 << 24)
 #define  DP_TP_STATUS_MODE_STATUS_MST  (1 << 23)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 850c16200759..3a62e230ae2c 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3061,6 +3061,27 @@ static void intel_dp_sink_set_fec_ready(struct intel_dp 
*intel_dp,
DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
 }
 
+static void intel_ddi_enable_fec(struct intel_encoder *encoder,
+const struct intel_crtc_state *crtc_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum port port = encoder->port;
+   u32 val;
+
+   if (!crtc_state->fec_enable)
+   return;
+
+   val = I915_READ(DP_TP_CTL(port));
+   val |= DP_TP_CTL_FEC_ENABLE;
+   I915_WRITE(DP_TP_CTL(port), val);
+
+   if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
+   DP_TP_STATUS_FEC_ENABLE_LIVE,
+   DP_TP_STATUS_FEC_ENABLE_LIVE,
+   1))
+   DRM_ERROR("Timed out waiting for FEC Enable Status\n");
+}
+
 static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state 
*conn_state)
@@ -3106,6 +3127,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 
+   intel_ddi_enable_fec(encoder, crtc_state);
+
icl_enable_phy_clock_gating(dig_port);
 
if (!is_mst)
-- 
2.19.1

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


[v7 1/4] i915/dp/fec: Add fec_enable to the crtc state.

2018-11-06 Thread Anusha Srivatsa
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.

Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction on other scenarios too
if needed.

v2:
- Control compression_enable with the fec_enable
parameter in crtc state and with intel_dp_supports_fec()
(Ville)

- intel_dp_can_fec()/intel_dp_supports_fec()(manasi)

v3: Check for FEC support along with setting crtc state.

v4: add checks to intel_dp_source_supports_dsc.(manasi)
- Move intel_dp_supports_fec() closer to
intel_dp_supports_dsc() (Anusha)

v5: Move fec check to intel_dp_supports_dsc(Ville)

v6: Remove warning. rebase.

v7: change crtc state to include DP sink and fec capability
of source.(Manasi)

Suggested-by: Ville Syrjala 
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_dp.c  | 31 +--
 drivers/gpu/drm/i915/intel_drv.h |  3 +++
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 73c00c5acf14..f764c45deaab 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -545,7 +545,7 @@ intel_dp_mode_valid(struct drm_connector *connector,
dsc_slice_count =

drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
-   } else {
+   } else if (drm_dp_sink_supports_fec(intel_dp->fec_capable)) {
dsc_max_output_bpp =
intel_dp_dsc_get_output_bpp(max_link_clock,
max_lanes,
@@ -1710,12 +1710,27 @@ struct link_config_limits {
int min_bpp, max_bpp;
 };
 
+static bool intel_dp_source_supports_fec(struct intel_dp *intel_dp,
+const struct intel_crtc_state 
*pipe_config)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
+
+   return INTEL_GEN(dev_priv) >= 11 && pipe_config->cpu_transcoder != 
TRANSCODER_A;
+}
+
+static bool intel_dp_supports_fec(struct intel_dp *intel_dp,
+ const struct intel_crtc_state *pipe_config)
+{
+   return intel_dp_source_supports_fec(intel_dp, pipe_config) &&
+   drm_dp_sink_supports_fec(intel_dp->fec_capable);
+}
+
 static bool intel_dp_source_supports_dsc(struct intel_dp *intel_dp,
 const struct intel_crtc_state 
*pipe_config)
 {
struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
 
-   /* FIXME: FEC needed for external DP until then reject DSC on DP */
if (!intel_dp_is_edp(intel_dp))
return false;
 
@@ -1726,6 +1741,9 @@ static bool intel_dp_source_supports_dsc(struct intel_dp 
*intel_dp,
 static bool intel_dp_supports_dsc(struct intel_dp *intel_dp,
  const struct intel_crtc_state *pipe_config)
 {
+   if (!pipe_config->fec_enable)
+   return false;
+
if (!intel_dp_source_supports_dsc(intel_dp, pipe_config) ||
!drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd))
return false;
@@ -1886,9 +1904,18 @@ static bool intel_dp_dsc_compute_config(struct intel_dp 
*intel_dp,
u16 dsc_max_output_bpp = 0;
u8 dsc_dp_slice_count = 0;
 
+   pipe_config->fec_enable = !intel_dp_is_edp(intel_dp) &&
+ intel_dp_supports_fec(intel_dp, pipe_config);
+
if (!intel_dp_supports_dsc(intel_dp, pipe_config))
return false;
 
+   /* DSC not supported if external DP sink does not support FEC */
+   if (!pipe_config->fec_enable) {
+   DRM_DEBUG_KMS("Sink does not support Forward Error Correction, 
disabling Display Compression\n");
+   return false;
+   }
+
/* DSC not supported for DSC sink BPC < 8 */
if (limits->max_bpp < 3 * DP_DSC_MIN_SUPPORTED_BPC) {
DRM_DEBUG_KMS("No DSC support for less than 8bpc\n");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index dd22cdeaa673..997bea5fdf16 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -945,6 +945,9 @@ struct intel_crtc_state {
u8 slice_count;
} dsc_params;
struct drm_dsc_config dp_dsc_cfg;
+
+   /* Forward Error correction State */
+   bool fec_enable;
 };
 
 struct intel_crtc {
-- 
2.19.1

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


[v7 4/4] drm/i915/fec: Disable FEC state.

2018-11-06 Thread Anusha Srivatsa
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.

v2:
- rebased.
- Add additional check for compression state. (Gaurav)

v3: rebased.

v4:
- Move the code to the proper spot according to spec (Ville)
- Use proper checks (manasi)

v5: Remove unnecessary checks (Ville)

v6: Resolve warnings. Add crtc_state as an argument to
intel_disable_ddi_buf(). (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
Reviewed-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c | 28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 3a62e230ae2c..581f9532d744 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3082,6 +3082,22 @@ static void intel_ddi_enable_fec(struct intel_encoder 
*encoder,
DRM_ERROR("Timed out waiting for FEC Enable Status\n");
 }
 
+static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
+   const struct intel_crtc_state 
*crtc_state)
+{
+   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+   enum port port = encoder->port;
+   u32 val;
+
+   if (!crtc_state->fec_enable)
+   return;
+
+   val = I915_READ(DP_TP_CTL(port));
+   val &= ~DP_TP_CTL_FEC_ENABLE;
+   I915_WRITE(DP_TP_CTL(port), val);
+   POSTING_READ(DP_TP_CTL(port));
+}
+
 static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state 
*conn_state)
@@ -3225,7 +3241,8 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*encoder,
}
 }
 
-static void intel_disable_ddi_buf(struct intel_encoder *encoder)
+static void intel_disable_ddi_buf(struct intel_encoder *encoder,
+ const struct intel_crtc_state *crtc_state)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = encoder->port;
@@ -3244,6 +3261,9 @@ static void intel_disable_ddi_buf(struct intel_encoder 
*encoder)
val |= DP_TP_CTL_LINK_TRAIN_PAT1;
I915_WRITE(DP_TP_CTL(port), val);
 
+   /* Disable FEC in DP Sink */
+   intel_ddi_disable_fec_state(encoder, crtc_state);
+
if (wait)
intel_wait_ddi_buf_idle(dev_priv, port);
 }
@@ -3267,7 +3287,7 @@ static void intel_ddi_post_disable_dp(struct 
intel_encoder *encoder,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
}
 
-   intel_disable_ddi_buf(encoder);
+   intel_disable_ddi_buf(encoder, old_crtc_state);
 
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_off(intel_dp);
@@ -3290,7 +3310,7 @@ static void intel_ddi_post_disable_hdmi(struct 
intel_encoder *encoder,
 
intel_ddi_disable_pipe_clock(old_crtc_state);
 
-   intel_disable_ddi_buf(encoder);
+   intel_disable_ddi_buf(encoder, old_crtc_state);
 
intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
 
@@ -3341,7 +3361,7 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
*encoder,
val &= ~FDI_RX_ENABLE;
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
 
-   intel_disable_ddi_buf(encoder);
+   intel_disable_ddi_buf(encoder, old_crtc_state);
intel_ddi_clk_disable(encoder);
 
val = I915_READ(FDI_RX_MISC(PIPE_A));
-- 
2.19.1

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


[v7 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION

2018-11-06 Thread Anusha Srivatsa
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.

This has to happen before link training.

v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
   - change commit message. (Gaurav)

v3: rebased. (r-b Manasi)

v4: Use fec crtc state, before setting FEC_READY
bit. (Anusha)

v5: Move to intel_ddi.c
- Make the function static (Anusha)

v6: Dont pass state as a separate argument (Ville)

Cc: dri-devel@lists.freedesktop.org
Cc: Gaurav K Singh 
Cc: Jani Nikula 
Cc: Ville Syrjala 
Cc: Manasi Navare 
Signed-off-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/intel_ddi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 46c1b9e12fbd..850c16200759 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3051,6 +3051,16 @@ static void icl_program_mg_dp_mode(struct 
intel_digital_port *intel_dig_port)
I915_WRITE(MG_DP_MODE(port, 1), ln1);
 }
 
+static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
+   const struct intel_crtc_state 
*crtc_state)
+{
+   if (!crtc_state->fec_enable)
+   return;
+
+   if (drm_dp_dpcd_writeb(_dp->aux, DP_FEC_CONFIGURATION, 
DP_FEC_READY) <= 0)
+   DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
+}
+
 static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state 
*conn_state)
@@ -3091,6 +3101,7 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
  true);
+   intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
intel_dp_start_link_train(intel_dp);
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
-- 
2.19.1

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


Re: [PATCH v4 2/3] arm64: dts: sdm845: Add dsi pinctrl nodes

2018-11-06 Thread Doug Anderson
Hi (sending again since I screwed up my previous reply),

On Fri, Nov 2, 2018 at 3:26 PM Jeykumar Sankaran  wrote:
>
> Add dsi active/suspend pinctrl nodes to sdm845 SoC dts.
>
> Changes in v4:
> - patch introduced in the series
>
> Signed-off-by: Jeykumar Sankaran 
> ---
>  arch/arm64/boot/dts/qcom/sdm845.dtsi | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index 5728b4c..35df5d2 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -822,6 +822,20 @@
> interrupt-controller;
> #interrupt-cells = <2>;
>
> +   dpu_dsi_active: dpu-dsi-active {
> +   pinmux {
> +   pins = "gpio6", "gpio52";
> +   function = "gpio";
> +   };
> +   };
> +
> +   dpu_dsi_suspend: dpu-dsi-suspend {
> +   pinmux {
> +   pins = "gpio6", "gpio52";
> +   function = "gpio";
> +   };
> +   };
> +

Ugh, I should have noticed this in my previous reply.  Sorry!

...looking closer I see that these two pins are MTP-specific.  They
belong fully in the MTP device tree file.  Other sdm845 boards won't
necessarily have the same functions on the same pins so they don't
belong here in the SoC file.

Also as a note: once you move them there they should no longer go in
the section "PINCTRL - additions to nodes defined in sdm845.dtsi".
They should go under the tlmm in the section "PINCTRL - board-specific
pinctrl".  Please make sure they are alphabetical there.

Since these are board specific, node names should be based on the
schematic name.  ...and in this case since they are two distinct named
pins I'd probably have a separate node for each one.  So I think you
want something like this in the mtp file: (untested)

disp_mode_sel_active: disp-mode-sel-active {
  pinmux {
pins = "gpio52";
function = "gpio";
  };
  pinconf {
pins = "gpio52";
drive-strength = <8>;
bias-disable;
};

disp_mode_sel_sleep: disp-mode-sel-sleep {
  pinmux {
pins = "gpio52";
function = "gpio";
  };
  pinconf {
pins = "gpio52";
drive-strength = <2>;
bias-pull-down;
};

...and then one for gpio6:

lcd0_reset_n_active: lcd0-reset-n-active {
  ...
};

---

I'm kinda curious if the sleep stuff is all truly necessary though.
Specifically I don't _think_ that the pulls are affected by the drive
strength.  So either we continue driving this pin while we're sleeping
in which case the drive strength matters and the pull doesn't.  ...or
we aren't driving it in sleep and the pull might matter but the drive
strength doesn't.

I definitely see a lot of this cruft coming from the Qualcomm
downstream without anyone who can explain to me that it's useful.  It
seems like everyone just blindly copies it from someone else.  As
further evidence that this isn't currently doing anything, as far as I
can tell the v10 panel driver for this panel doesn't actually even
select the suspend state.

Maybe we can just drop the whole "active" vs. "sleep" for now and we
can introduce it later when we show that it's useful for something.
Then we can confirm if it's the drive strength that's useful or the
pull down and we can also confirm that we don't end up going to sleep
with the pin being driven in the opposite direction of the pull.

Maybe +Bjorn or +Stephen has a different opinion though...

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


Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:00:34PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 07, 2018 at 06:59:29AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Commit
> > 
> >   35b876db4a42 ("drm/i915/dsc: Add slice_row_per_frame in DSC PPS 
> > programming")
> > 
> > is missing a Signed-off-by from its committer.
> 
> It seems the tag "Suggested-by:" tricked out our maintainer tools.

Hmm yea that makes sense since it did have suggested-by: me (committer)
so it skipped adding my sign-off.

Thanks for catching this and fixing it in tools.

Manasi

> 
> from dim:
> 
> # check for committer sign-off
> if ! git show -s $sha1 | grep -qi "S.*-by:.*$committer"  ; then
> 
> -
> 
> I will send a patch to our tools to spell signed-off-by directly.
> 
> Thanks for reporting this out.
> Rodrigo.
> 
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> 
> 
> 
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel tree

2018-11-06 Thread Rodrigo Vivi
On Wed, Nov 07, 2018 at 06:59:29AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Commit
> 
>   35b876db4a42 ("drm/i915/dsc: Add slice_row_per_frame in DSC PPS 
> programming")
> 
> is missing a Signed-off-by from its committer.

It seems the tag "Suggested-by:" tricked out our maintainer tools.

from dim:

# check for committer sign-off
if ! git show -s $sha1 | grep -qi "S.*-by:.*$committer"  ; then

-

I will send a patch to our tools to spell signed-off-by directly.

Thanks for reporting this out.
Rodrigo.

> 
> -- 
> Cheers,
> Stephen Rothwell



> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


RE: [v6 3/4] i915/dp/fec: Configure the Forward Error Correction bits.

2018-11-06 Thread Srivatsa, Anusha


>-Original Message-
>From: Navare, Manasi D
>Sent: Tuesday, November 6, 2018 2:42 PM
>To: Srivatsa, Anusha 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Singh,
>Gaurav K ; Jani Nikula ;
>Ville Syrjala 
>Subject: Re: [v6 3/4] i915/dp/fec: Configure the Forward Error Correction bits.
>
>On Mon, Nov 05, 2018 at 03:31:49PM -0800, Anusha Srivatsa wrote:
>> If FEC is supported, the corresponding DP_TP_CTL register bits have to
>> be configured.
>>
>> The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register and
>> wait till FEC_STATUS in DP_TP_CTL[28] is 1.
>> Also add the warn message to make sure that the control register is
>> already active while enabling FEC.
>>
>> v2:
>> - Change commit message. Configure fec state after
>>   link training (Manasi, Gaurav)
>> - Remove redundent checks (Manasi)
>> - Remove the registers that get added automagically (Anusha)
>>
>> v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
>>
>> v4: rebased.
>>
>> v5:
>> - Move the code to the proper spot, according to spec.(Ville)
>> - Use fec state as a check too.
>>
>> v6: Pass intel_encoder, instead of intel_dp. (Ville)
>>
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: Gaurav K Singh 
>> Cc: Jani Nikula 
>> Cc: Ville Syrjala 
>> Cc: Manasi Navare 
>> Signed-off-by: Anusha Srivatsa 
>> ---
>>  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>> drivers/gpu/drm/i915/intel_ddi.c | 24 
>>  2 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h index 1a84e8f98e66..209b64d2f27a
>> 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -9148,6 +9148,7 @@ enum skl_power_gate {
>>  #define _DP_TP_CTL_B0x64140
>>  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
>>  #define  DP_TP_CTL_ENABLE   (1 << 31)
>> +#define  DP_TP_CTL_FEC_ENABLE   (1 << 30)
>>  #define  DP_TP_CTL_MODE_SST (0 << 27)
>>  #define  DP_TP_CTL_MODE_MST (1 << 27)
>>  #define  DP_TP_CTL_FORCE_ACT(1 << 25)
>> @@ -9166,6 +9167,7 @@ enum skl_power_gate {
>>  #define _DP_TP_STATUS_A 0x64044
>>  #define _DP_TP_STATUS_B 0x64144
>>  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A,
>> _DP_TP_STATUS_B)
>> +#define  DP_TP_STATUS_FEC_ENABLE_LIVE   (1 << 28)
>>  #define  DP_TP_STATUS_IDLE_DONE (1 << 25)
>>  #define  DP_TP_STATUS_ACT_SENT  (1 << 24)
>>  #define  DP_TP_STATUS_MODE_STATUS_MST   (1 << 23)
>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
>> b/drivers/gpu/drm/i915/intel_ddi.c
>> index 53a9b31e66a2..fad7385dbd76 100644
>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>> @@ -3065,6 +3065,28 @@ static void intel_dp_sink_set_fec_ready(struct
>intel_dp *intel_dp,
>>  DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");  }
>>
>> +static void intel_ddi_enable_fec(struct intel_encoder *encoder,
>> + const struct intel_crtc_state *crtc_state) {
>> +struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>> +enum port port = encoder->port;
>> +u32 val;
>> +
>> +/* FEC support exists for DP 1.4 only */
>
>No need for this comment here now since all the platform and sink checks
>already done while setting the the fec state.
Agreed.

>
>> +if (!crtc_state->fec_enable)
>> +return;
>> +
>> +val = I915_READ(DP_TP_CTL(port));
>> +val |= DP_TP_CTL_FEC_ENABLE;
>> +I915_WRITE(DP_TP_CTL(port), val);
>
>Do we need a POSTING_READ() here as well? It's used in case of disable fec in
>DP_TP_CTL.
>May be double check when we need it and when we don't.

I don't think we need POSTING_READ, the spec says "wait for FEC_STATUS in 
DP_TP_CTL[28] is 1. That is why after the i915_WRITE above, I am using 
intel_Wait_for_register().

Anusha 
>Manasi
>
>> +
>> +if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
>> +DP_TP_STATUS_FEC_ENABLE_LIVE,
>> +DP_TP_STATUS_FEC_ENABLE_LIVE,
>> +1))
>> +DRM_ERROR("Timed out waiting for FEC Enable Status\n"); }
>> +
>>  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>>  const struct intel_crtc_state *crtc_state,
>>  const struct drm_connector_state
>*conn_state) @@ -3110,6
>> +3132,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
>*encoder,
>>  if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>>  intel_dp_stop_link_train(intel_dp);
>>
>> +intel_ddi_enable_fec(encoder, crtc_state);
>> +
>>  icl_enable_phy_clock_gating(dig_port);
>>
>>  if (!is_mst)
>> --
>> 2.19.1
>>

Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 02:41:01PM -0800, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, November 6, 2018 6:43 AM
> >To: Navare, Manasi D 
> >Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Jani 
> >Nikula
> >; Srivatsa, Anusha ;
> >Singh, Gaurav K 
> >Subject: Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic
> >check
> >
> >On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote:
> >> On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
> >> > DSC params like the enable, compressed bpp, slice count and
> >> > dsc_split are added to the intel_crtc_state. These parameters are
> >> > set based on the requested mode and available link parameters during
> >> > the pipe configuration in atomic check phase.
> >> > These values are then later used to populate the remaining DSC and
> >> > RC parameters before enbaling DSC in atomic commit.
> >> >
> >> > v11:
> >> > * Const crtc_state, reject DSC on DP without FEC (Ville)
> >> > * Dont set dsc_split to false (Ville)
> >> > v10:
> >> > * Add a helper for dp_dsc support (Ville)
> >> > * Set pipe_config to max bpp, link params for DSC for now (Ville)
> >> > * Compute bpp - use dp dsc support helper (Ville)
> >> > v9:
> >> > * Rebase on top of drm-tip that now uses fast_narrow config for edp
> >> > (Manasi)
> >> > v8:
> >> > * Check for DSC bpc not 0 (manasi)
> >> >
> >> > v7:
> >> > * Fix indentation in compute_m_n (Manasi)
> >> >
> >> > v6 (From Gaurav):
> >> > * Remove function call of intel_dp_compute_dsc_params() and invoke
> >> > intel_dp_compute_dsc_params() in the patch where it is defined to
> >> > fix compilation warning (Gaurav)
> >> >
> >> > v5:
> >> > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> >> >
> >> > v4:
> >> > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> >> > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> >> >
> >> > v3:
> >> > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> >> >
> >> > v2:
> >> > * Add if-else for eDP/DP (Gaurav)
> >> >
> >> > Cc: Jani Nikula 
> >> > Cc: Ville Syrjala 
> >> > Cc: Anusha Srivatsa 
> >> > Cc: Gaurav K Singh 
> >> > Signed-off-by: Manasi Navare 
> >> > Reviewed-by: Anusha Srivatsa 
> >> > Acked-by: Jani Nikula 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_display.c |  20 +++-
> >> >  drivers/gpu/drm/i915/intel_display.h |   3 +-
> >> >  drivers/gpu/drm/i915/intel_dp.c  | 167 ---
> >> >  drivers/gpu/drm/i915/intel_dp_mst.c  |   2 +-
> >> >  4 files changed, 166 insertions(+), 26 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> >> > b/drivers/gpu/drm/i915/intel_display.c
> >> > index b219d5858160..477e53c37353 100644
> >> > --- a/drivers/gpu/drm/i915/intel_display.c
> >> > +++ b/drivers/gpu/drm/i915/intel_display.c
> >> > @@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct
> >> > intel_crtc *intel_crtc,
> >> >
> >> >  pipe_config->fdi_lanes = lane;
> >> >
> >> > -intel_link_compute_m_n(pipe_config->pipe_bpp, lane, 
> >> > fdi_dotclock,
> >> > +intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane,
> >> > +fdi_dotclock,
> >> > link_bw, _config->fdi_m_n, false);
> >> >
> >> >  ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe,
> >> > pipe_config); @@ -6679,17 +6679,25 @@ static void
> >> > compute_m_n(unsigned int m, unsigned int n,  }
> >> >
> >> >  void
> >> > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> >> > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> >> > +   int nlanes,
> >> > int pixel_clock, int link_clock,
> >> > struct intel_link_m_n *m_n,
> >> > bool constant_n)
> >> >  {
> >> >  m_n->tu = 64;
> >> >
> >> > -compute_m_n(bits_per_pixel * pixel_clock,
> >> > -link_clock * nlanes * 8,
> >> > -_n->gmch_m, _n->gmch_n,
> >> > -constant_n);
> >> > +/* For DSC, Data M/N calculation uses compressed BPP */
> >> > +if (compressed_bpp)
> >> > +compute_m_n(compressed_bpp * pixel_clock,
> >> > +link_clock * nlanes * 8,
> >> > +_n->gmch_m, _n->gmch_n,
> >> > +constant_n);
> >> > +else
> >> > +compute_m_n(bits_per_pixel * pixel_clock,
> >> > +link_clock * nlanes * 8,
> >> > +_n->gmch_m, _n->gmch_n,
> >> > +constant_n);
> >> >
> >> >  compute_m_n(pixel_clock, link_clock,
> >> >  _n->link_m, _n->link_n,
> >> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> >> > b/drivers/gpu/drm/i915/intel_display.h
> >> > index 

RE: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check

2018-11-06 Thread Srivatsa, Anusha


>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, November 6, 2018 6:43 AM
>To: Navare, Manasi D 
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Jani 
>Nikula
>; Srivatsa, Anusha ;
>Singh, Gaurav K 
>Subject: Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic
>check
>
>On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote:
>> On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
>> > DSC params like the enable, compressed bpp, slice count and
>> > dsc_split are added to the intel_crtc_state. These parameters are
>> > set based on the requested mode and available link parameters during
>> > the pipe configuration in atomic check phase.
>> > These values are then later used to populate the remaining DSC and
>> > RC parameters before enbaling DSC in atomic commit.
>> >
>> > v11:
>> > * Const crtc_state, reject DSC on DP without FEC (Ville)
>> > * Dont set dsc_split to false (Ville)
>> > v10:
>> > * Add a helper for dp_dsc support (Ville)
>> > * Set pipe_config to max bpp, link params for DSC for now (Ville)
>> > * Compute bpp - use dp dsc support helper (Ville)
>> > v9:
>> > * Rebase on top of drm-tip that now uses fast_narrow config for edp
>> > (Manasi)
>> > v8:
>> > * Check for DSC bpc not 0 (manasi)
>> >
>> > v7:
>> > * Fix indentation in compute_m_n (Manasi)
>> >
>> > v6 (From Gaurav):
>> > * Remove function call of intel_dp_compute_dsc_params() and invoke
>> > intel_dp_compute_dsc_params() in the patch where it is defined to
>> > fix compilation warning (Gaurav)
>> >
>> > v5:
>> > Add drm_dsc_cfg in intel_crtc_state (Manasi)
>> >
>> > v4:
>> > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
>> > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
>> >
>> > v3:
>> > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
>> >
>> > v2:
>> > * Add if-else for eDP/DP (Gaurav)
>> >
>> > Cc: Jani Nikula 
>> > Cc: Ville Syrjala 
>> > Cc: Anusha Srivatsa 
>> > Cc: Gaurav K Singh 
>> > Signed-off-by: Manasi Navare 
>> > Reviewed-by: Anusha Srivatsa 
>> > Acked-by: Jani Nikula 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c |  20 +++-
>> >  drivers/gpu/drm/i915/intel_display.h |   3 +-
>> >  drivers/gpu/drm/i915/intel_dp.c  | 167 ---
>> >  drivers/gpu/drm/i915/intel_dp_mst.c  |   2 +-
>> >  4 files changed, 166 insertions(+), 26 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index b219d5858160..477e53c37353 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct
>> > intel_crtc *intel_crtc,
>> >
>> >pipe_config->fdi_lanes = lane;
>> >
>> > -  intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
>> > +  intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane,
>> > +fdi_dotclock,
>> >   link_bw, _config->fdi_m_n, false);
>> >
>> >ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe,
>> > pipe_config); @@ -6679,17 +6679,25 @@ static void
>> > compute_m_n(unsigned int m, unsigned int n,  }
>> >
>> >  void
>> > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
>> > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
>> > + int nlanes,
>> >   int pixel_clock, int link_clock,
>> >   struct intel_link_m_n *m_n,
>> >   bool constant_n)
>> >  {
>> >m_n->tu = 64;
>> >
>> > -  compute_m_n(bits_per_pixel * pixel_clock,
>> > -  link_clock * nlanes * 8,
>> > -  _n->gmch_m, _n->gmch_n,
>> > -  constant_n);
>> > +  /* For DSC, Data M/N calculation uses compressed BPP */
>> > +  if (compressed_bpp)
>> > +  compute_m_n(compressed_bpp * pixel_clock,
>> > +  link_clock * nlanes * 8,
>> > +  _n->gmch_m, _n->gmch_n,
>> > +  constant_n);
>> > +  else
>> > +  compute_m_n(bits_per_pixel * pixel_clock,
>> > +  link_clock * nlanes * 8,
>> > +  _n->gmch_m, _n->gmch_n,
>> > +  constant_n);
>> >
>> >compute_m_n(pixel_clock, link_clock,
>> >_n->link_m, _n->link_n,
>> > diff --git a/drivers/gpu/drm/i915/intel_display.h
>> > b/drivers/gpu/drm/i915/intel_display.h
>> > index 5d50decbcbb5..b0b23e1e9392 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.h
>> > +++ b/drivers/gpu/drm/i915/intel_display.h
>> > @@ -407,7 +407,8 @@ struct intel_link_m_n {
>> > (__i)++) \
>> >for_each_if(plane)
>> >
>> > -void intel_link_compute_m_n(int bpp, int nlanes,
>> > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
>> > +  int nlanes,
>> >int pixel_clock, int link_clock,
>> >  

Re: [v6 3/4] i915/dp/fec: Configure the Forward Error Correction bits.

2018-11-06 Thread Manasi Navare
On Mon, Nov 05, 2018 at 03:31:49PM -0800, Anusha Srivatsa wrote:
> If FEC is supported, the corresponding
> DP_TP_CTL register bits have to be configured.
> 
> The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
> and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
> Also add the warn message to make sure that the control
> register is already active while enabling FEC.
> 
> v2:
> - Change commit message. Configure fec state after
>   link training (Manasi, Gaurav)
> - Remove redundent checks (Manasi)
> - Remove the registers that get added automagically (Anusha)
> 
> v3: s/intel_dp_set_fec_state()/intel_dp_enable_fec_state() (Gaurav)
> 
> v4: rebased.
> 
> v5:
> - Move the code to the proper spot, according to spec.(Ville)
> - Use fec state as a check too.
> 
> v6: Pass intel_encoder, instead of intel_dp. (Ville)
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Gaurav K Singh 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |  2 ++
>  drivers/gpu/drm/i915/intel_ddi.c | 24 
>  2 files changed, 26 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1a84e8f98e66..209b64d2f27a 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -9148,6 +9148,7 @@ enum skl_power_gate {
>  #define _DP_TP_CTL_B 0x64140
>  #define DP_TP_CTL(port) _MMIO_PORT(port, _DP_TP_CTL_A, _DP_TP_CTL_B)
>  #define  DP_TP_CTL_ENABLE(1 << 31)
> +#define  DP_TP_CTL_FEC_ENABLE(1 << 30)
>  #define  DP_TP_CTL_MODE_SST  (0 << 27)
>  #define  DP_TP_CTL_MODE_MST  (1 << 27)
>  #define  DP_TP_CTL_FORCE_ACT (1 << 25)
> @@ -9166,6 +9167,7 @@ enum skl_power_gate {
>  #define _DP_TP_STATUS_A  0x64044
>  #define _DP_TP_STATUS_B  0x64144
>  #define DP_TP_STATUS(port) _MMIO_PORT(port, _DP_TP_STATUS_A, _DP_TP_STATUS_B)
> +#define  DP_TP_STATUS_FEC_ENABLE_LIVE(1 << 28)
>  #define  DP_TP_STATUS_IDLE_DONE  (1 << 25)
>  #define  DP_TP_STATUS_ACT_SENT   (1 << 24)
>  #define  DP_TP_STATUS_MODE_STATUS_MST(1 << 23)
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 53a9b31e66a2..fad7385dbd76 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3065,6 +3065,28 @@ static void intel_dp_sink_set_fec_ready(struct 
> intel_dp *intel_dp,
>   DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
>  }
>  
> +static void intel_ddi_enable_fec(struct intel_encoder *encoder,
> +  const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum port port = encoder->port;
> + u32 val;
> +
> + /* FEC support exists for DP 1.4 only */

No need for this comment here now since all the platform and sink checks already
done while setting the the fec state.

> + if (!crtc_state->fec_enable)
> + return;
> +
> + val = I915_READ(DP_TP_CTL(port));
> + val |= DP_TP_CTL_FEC_ENABLE;
> + I915_WRITE(DP_TP_CTL(port), val);

Do we need a POSTING_READ() here as well? Its used in case of disable fec in 
DP_TP_CTL.
May be double check when we need it and when we dont.

Manasi

> +
> + if (intel_wait_for_register(dev_priv, DP_TP_STATUS(port),
> + DP_TP_STATUS_FEC_ENABLE_LIVE,
> + DP_TP_STATUS_FEC_ENABLE_LIVE,
> + 1))
> + DRM_ERROR("Timed out waiting for FEC Enable Status\n");
> +}
> +
>  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state 
> *conn_state)
> @@ -3110,6 +3132,8 @@ static void intel_ddi_pre_enable_dp(struct 
> intel_encoder *encoder,
>   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
>   intel_dp_stop_link_train(intel_dp);
>  
> + intel_ddi_enable_fec(encoder, crtc_state);
> +
>   icl_enable_phy_clock_gating(dig_port);
>  
>   if (!is_mst)
> -- 
> 2.19.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH v2 1/5] drm/msm: destroy msm threads after config cleanup

2018-11-06 Thread Jeykumar Sankaran
To avoid any possible work queues to msm threads, clean up
the threads after the CRTC objects are released in
config cleanup.

changes in v2:
- fix race condition before kthread flush and stop (Sean Paul)
- use kthread_destroy_worker for cleaning up kthread (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c9f7ff..e913059 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -278,6 +278,21 @@ static int msm_drm_uninit(struct device *dev)
 * work before drm_irq_uninstall() to avoid work re-enabling an
 * irq after uninstall has disabled it.
 */
+   msm_gem_shrinker_cleanup(ddev);
+
+   drm_kms_helper_poll_fini(ddev);
+
+   drm_dev_unregister(ddev);
+
+   msm_perf_debugfs_cleanup(priv);
+   msm_rd_debugfs_cleanup(priv);
+
+#ifdef CONFIG_DRM_FBDEV_EMULATION
+   if (fbdev && priv->fbdev)
+   msm_fbdev_free(ddev);
+#endif
+   drm_mode_config_cleanup(ddev);
+
kthread_flush_work(_ctrl->work);
list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
list_del(_ev->node);
@@ -287,33 +302,16 @@ static int msm_drm_uninit(struct device *dev)
/* clean up display commit/event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
if (priv->disp_thread[i].thread) {
-   kthread_flush_worker(>disp_thread[i].worker);
-   kthread_stop(priv->disp_thread[i].thread);
+   kthread_destroy_worker(>disp_thread[i].worker);
priv->disp_thread[i].thread = NULL;
}
 
if (priv->event_thread[i].thread) {
-   kthread_flush_worker(>event_thread[i].worker);
-   kthread_stop(priv->event_thread[i].thread);
+   kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
}
}
 
-   msm_gem_shrinker_cleanup(ddev);
-
-   drm_kms_helper_poll_fini(ddev);
-
-   drm_dev_unregister(ddev);
-
-   msm_perf_debugfs_cleanup(priv);
-   msm_rd_debugfs_cleanup(priv);
-
-#ifdef CONFIG_DRM_FBDEV_EMULATION
-   if (fbdev && priv->fbdev)
-   msm_fbdev_free(ddev);
-#endif
-   drm_mode_config_cleanup(ddev);
-
pm_runtime_get_sync(dev);
drm_irq_uninstall(ddev);
pm_runtime_put_sync(dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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


[PATCH v2 5/5] drm/msm: subclass work object for vblank events

2018-11-06 Thread Jeykumar Sankaran
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the workqueue. We can avoid this redundant list
and its protection mechanism, if we subclass the
work object to encapsulate vblank event parameters.

changes in v2:
- subclass optimization on system wq (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 67 +--
 drivers/gpu/drm/msm/msm_drv.h |  7 -
 2 files changed, 20 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 6d6c73b..8da5be2 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -203,61 +203,44 @@ u32 msm_readl(const void __iomem *addr)
return val;
 }
 
-struct vblank_event {
-   struct list_head node;
+struct msm_vblank_work {
+   struct work_struct work;
int crtc_id;
bool enable;
+   struct msm_drm_private *priv;
 };
 
 static void vblank_ctrl_worker(struct work_struct *work)
 {
-   struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
-   struct msm_vblank_ctrl, work);
-   struct msm_drm_private *priv = container_of(vbl_ctrl,
-   struct msm_drm_private, vblank_ctrl);
+   struct msm_vblank_work *vbl_work = container_of(work,
+   struct msm_vblank_work, work);
+   struct msm_drm_private *priv = vbl_work->priv;
struct msm_kms *kms = priv->kms;
-   struct vblank_event *vbl_ev, *tmp;
-   unsigned long flags;
-
-   spin_lock_irqsave(_ctrl->lock, flags);
-   list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
-   list_del(_ev->node);
-   spin_unlock_irqrestore(_ctrl->lock, flags);
-
-   if (vbl_ev->enable)
-   kms->funcs->enable_vblank(kms,
-   priv->crtcs[vbl_ev->crtc_id]);
-   else
-   kms->funcs->disable_vblank(kms,
-   priv->crtcs[vbl_ev->crtc_id]);
 
-   kfree(vbl_ev);
-
-   spin_lock_irqsave(_ctrl->lock, flags);
-   }
+   if (vbl_work->enable)
+   kms->funcs->enable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
+   else
+   kms->funcs->disable_vblank(kms, priv->crtcs[vbl_work->crtc_id]);
 
-   spin_unlock_irqrestore(_ctrl->lock, flags);
+   kfree(vbl_work);
 }
 
 static int vblank_ctrl_queue_work(struct msm_drm_private *priv,
int crtc_id, bool enable)
 {
-   struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
-   struct vblank_event *vbl_ev;
-   unsigned long flags;
+   struct msm_vblank_work *vbl_work;
 
-   vbl_ev = kzalloc(sizeof(*vbl_ev), GFP_ATOMIC);
-   if (!vbl_ev)
+   vbl_work = kzalloc(sizeof(*vbl_work), GFP_ATOMIC);
+   if (!vbl_work)
return -ENOMEM;
 
-   vbl_ev->crtc_id = crtc_id;
-   vbl_ev->enable = enable;
+   INIT_WORK(_work->work, vblank_ctrl_worker);
 
-   spin_lock_irqsave(_ctrl->lock, flags);
-   list_add_tail(_ev->node, _ctrl->event_list);
-   spin_unlock_irqrestore(_ctrl->lock, flags);
+   vbl_work->crtc_id = crtc_id;
+   vbl_work->enable = enable;
+   vbl_work->priv = priv;
 
-   schedule_work(_ctrl->work);
+   schedule_work(_work->work);
 
return 0;
 }
@@ -269,14 +252,13 @@ static int msm_drm_uninit(struct device *dev)
struct msm_drm_private *priv = ddev->dev_private;
struct msm_kms *kms = priv->kms;
struct msm_mdss *mdss = priv->mdss;
-   struct msm_vblank_ctrl *vbl_ctrl = >vblank_ctrl;
-   struct vblank_event *vbl_ev, *tmp;
int i;
 
/* We must cancel and cleanup any pending vblank enable/disable
 * work before drm_irq_uninstall() to avoid work re-enabling an
 * irq after uninstall has disabled it.
 */
+
msm_gem_shrinker_cleanup(ddev);
 
drm_kms_helper_poll_fini(ddev);
@@ -292,12 +274,6 @@ static int msm_drm_uninit(struct device *dev)
 #endif
drm_mode_config_cleanup(ddev);
 
-   flush_work(_ctrl->work);
-   list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
-   list_del(_ev->node);
-   kfree(vbl_ev);
-   }
-
/* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
if (priv->event_thread[i].thread) {
@@ -469,9 +445,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
priv->wq = alloc_ordered_workqueue("msm", 0);
 
INIT_LIST_HEAD(>inactive_list);
-   INIT_LIST_HEAD(>vblank_ctrl.event_list);
-   INIT_WORK(>vblank_ctrl.work, vblank_ctrl_worker);
-   spin_lock_init(>vblank_ctrl.lock);
 
drm_mode_config_init(ddev);
 

[PATCH v2 4/5] drm/msm: clean up display thread

2018-11-06 Thread Jeykumar Sankaran
Since there are no clients using these threads,
cleaning it up.

changes in v2:
- switch all the dependent clients to use system wq
  before removing the disp_threads (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 35 +--
 drivers/gpu/drm/msm/msm_drv.h |  1 -
 2 files changed, 1 insertion(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 7d3ca99..6d6c73b 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -298,13 +298,8 @@ static int msm_drm_uninit(struct device *dev)
kfree(vbl_ev);
}
 
-   /* clean up display commit/event worker threads */
+   /* clean up event worker threads */
for (i = 0; i < priv->num_crtcs; i++) {
-   if (priv->disp_thread[i].thread) {
-   kthread_destroy_worker(>disp_thread[i].worker);
-   priv->disp_thread[i].thread = NULL;
-   }
-
if (priv->event_thread[i].thread) {
kthread_destroy_worker(>event_thread[i].worker);
priv->event_thread[i].thread = NULL;
@@ -541,27 +536,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
 */
param.sched_priority = 16;
for (i = 0; i < priv->num_crtcs; i++) {
-
-   /* initialize display thread */
-   priv->disp_thread[i].crtc_id = priv->crtcs[i]->base.id;
-   kthread_init_worker(>disp_thread[i].worker);
-   priv->disp_thread[i].dev = ddev;
-   priv->disp_thread[i].thread =
-   kthread_run(kthread_worker_fn,
-   >disp_thread[i].worker,
-   "crtc_commit:%d", priv->disp_thread[i].crtc_id);
-   if (IS_ERR(priv->disp_thread[i].thread)) {
-   DRM_DEV_ERROR(dev, "failed to create crtc_commit 
kthread\n");
-   priv->disp_thread[i].thread = NULL;
-   goto err_msm_uninit;
-   }
-
-   ret = sched_setscheduler(priv->disp_thread[i].thread,
-SCHED_FIFO, );
-   if (ret)
-   dev_warn(dev, "disp_thread set priority failed: %d\n",
-ret);
-
/* initialize event thread */
priv->event_thread[i].crtc_id = priv->crtcs[i]->base.id;
kthread_init_worker(>event_thread[i].worker);
@@ -576,13 +550,6 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
goto err_msm_uninit;
}
 
-   /**
-* event thread should also run at same priority as disp_thread
-* because it is handling frame_done events. A lower priority
-* event thread and higher priority disp_thread can causes
-* frame_pending counters beyond 2. This can lead to commit
-* failure at crtc commit level.
-*/
ret = sched_setscheduler(priv->event_thread[i].thread,
 SCHED_FIFO, );
if (ret)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 126345c4..05d33a7 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -197,7 +197,6 @@ struct msm_drm_private {
unsigned int num_crtcs;
struct drm_crtc *crtcs[MAX_CRTCS];
 
-   struct msm_drm_thread disp_thread[MAX_CRTCS];
struct msm_drm_thread event_thread[MAX_CRTCS];
 
unsigned int num_encoders;
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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


[PATCH v2 2/5] drm/msm/dpu: use system wq for vblank events

2018-11-06 Thread Jeykumar Sankaran
DPU was using one thread per display to dispatch async commits and
vblank requests. Since clean up already happened in msm to use the
common thread for all the display commits, display threads are only
used to cater vblank requests. Since a single thread is sufficient
to do the job without any performance hits, use system workqueue
to queue requests. A separate patch is submitted later in this
series to remove the display threads altogether.

changes in v2:
- switch to system wq before removing disp threads (Sean Paul)

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/msm_drv.c | 9 -
 drivers/gpu/drm/msm/msm_drv.h | 2 +-
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index e913059..7d3ca99 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -209,7 +209,7 @@ struct vblank_event {
bool enable;
 };
 
-static void vblank_ctrl_worker(struct kthread_work *work)
+static void vblank_ctrl_worker(struct work_struct *work)
 {
struct msm_vblank_ctrl *vbl_ctrl = container_of(work,
struct msm_vblank_ctrl, work);
@@ -257,8 +257,7 @@ static int vblank_ctrl_queue_work(struct msm_drm_private 
*priv,
list_add_tail(_ev->node, _ctrl->event_list);
spin_unlock_irqrestore(_ctrl->lock, flags);
 
-   kthread_queue_work(>disp_thread[crtc_id].worker,
-   _ctrl->work);
+   schedule_work(_ctrl->work);
 
return 0;
 }
@@ -293,7 +292,7 @@ static int msm_drm_uninit(struct device *dev)
 #endif
drm_mode_config_cleanup(ddev);
 
-   kthread_flush_work(_ctrl->work);
+   flush_work(_ctrl->work);
list_for_each_entry_safe(vbl_ev, tmp, _ctrl->event_list, node) {
list_del(_ev->node);
kfree(vbl_ev);
@@ -476,7 +475,7 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
 
INIT_LIST_HEAD(>inactive_list);
INIT_LIST_HEAD(>vblank_ctrl.event_list);
-   kthread_init_work(>vblank_ctrl.work, vblank_ctrl_worker);
+   INIT_WORK(>vblank_ctrl.work, vblank_ctrl_worker);
spin_lock_init(>vblank_ctrl.lock);
 
drm_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9d11f32..126345c4 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -78,7 +78,7 @@ enum msm_mdp_plane_property {
 };
 
 struct msm_vblank_ctrl {
-   struct kthread_work work;
+   struct work_struct work;
struct list_head event_list;
spinlock_t lock;
 };
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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


[PATCH v2 3/5] drm/msm/dpu: use system wq for idle power collapse

2018-11-06 Thread Jeykumar Sankaran
msm is using system wq for dispatching commit and vblank
events. Switch idle power collapse feature also to use
system wq to handle delayed work handlers so that
msm can get rid of redundant display threads.

changes in v2:
- patch introduced in v2

Signed-off-by: Jeykumar Sankaran 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 26 +++---
 1 file changed, 7 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 82c55ef..9b3d1f2 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -201,7 +201,7 @@ struct dpu_encoder_virt {
bool idle_pc_supported;
struct mutex rc_lock;
enum dpu_enc_rc_states rc_state;
-   struct kthread_delayed_work delayed_off_work;
+   struct delayed_work delayed_off_work;
struct kthread_work vsync_event_work;
struct msm_display_topology topology;
bool mode_set_complete;
@@ -740,7 +740,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
 {
struct dpu_encoder_virt *dpu_enc;
struct msm_drm_private *priv;
-   struct msm_drm_thread *disp_thread;
bool is_vid_mode = false;
 
if (!drm_enc || !drm_enc->dev || !drm_enc->dev->dev_private ||
@@ -753,12 +752,6 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
is_vid_mode = dpu_enc->disp_info.capabilities &
MSM_DISPLAY_CAP_VID_MODE;
 
-   if (drm_enc->crtc->index >= ARRAY_SIZE(priv->disp_thread)) {
-   DPU_ERROR("invalid crtc index\n");
-   return -EINVAL;
-   }
-   disp_thread = >disp_thread[drm_enc->crtc->index];
-
/*
 * when idle_pc is not supported, process only KICKOFF, STOP and MODESET
 * events and return early for other events (ie wb display).
@@ -775,8 +768,7 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
switch (sw_event) {
case DPU_ENC_RC_EVENT_KICKOFF:
/* cancel delayed off work, if any */
-   if (kthread_cancel_delayed_work_sync(
-   _enc->delayed_off_work))
+   if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
 
@@ -835,10 +827,8 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
return 0;
}
 
-   kthread_queue_delayed_work(
-   _thread->worker,
-   _enc->delayed_off_work,
-   msecs_to_jiffies(dpu_enc->idle_timeout));
+   schedule_delayed_work(_enc->delayed_off_work,
+ msecs_to_jiffies(dpu_enc->idle_timeout));
 
trace_dpu_enc_rc(DRMID(drm_enc), sw_event,
 dpu_enc->idle_pc_supported, dpu_enc->rc_state,
@@ -847,8 +837,7 @@ static int dpu_encoder_resource_control(struct drm_encoder 
*drm_enc,
 
case DPU_ENC_RC_EVENT_PRE_STOP:
/* cancel delayed off work, if any */
-   if (kthread_cancel_delayed_work_sync(
-   _enc->delayed_off_work))
+   if (cancel_delayed_work_sync(_enc->delayed_off_work))
DPU_DEBUG_ENC(dpu_enc, "sw_event:%d, work cancelled\n",
sw_event);
 
@@ -1351,7 +1340,7 @@ static void dpu_encoder_frame_done_callback(
}
 }
 
-static void dpu_encoder_off_work(struct kthread_work *work)
+static void dpu_encoder_off_work(struct work_struct *work)
 {
struct dpu_encoder_virt *dpu_enc = container_of(work,
struct dpu_encoder_virt, delayed_off_work.work);
@@ -2191,8 +2180,7 @@ int dpu_encoder_setup(struct drm_device *dev, struct 
drm_encoder *enc,
 
 
mutex_init(_enc->rc_lock);
-   kthread_init_delayed_work(_enc->delayed_off_work,
-   dpu_encoder_off_work);
+   INIT_DELAYED_WORK(_enc->delayed_off_work, dpu_encoder_off_work);
dpu_enc->idle_timeout = IDLE_TIMEOUT;
 
kthread_init_work(_enc->vsync_event_work,
-- 
The Qualcomm Innovation Center, Inc. is a member of the 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: [v6 4/4] drm/i915/fec: Disable FEC state.

2018-11-06 Thread Manasi Navare
On Mon, Nov 05, 2018 at 03:31:50PM -0800, Anusha Srivatsa wrote:
> Set the suitable bits in DP_TP_CTL to stop
> bit correction when DSC is disabled.
> 
> v2:
> - rebased.
> - Add additional check for compression state. (Gaurav)
> 
> v3: rebased.
> 
> v4:
> - Move the code to the proper spot according to spec (Ville)
> - Use proper checks (manasi)
> 
> v5: Remove unnecessary checks (Ville)
> 
> v6: Resolve warnings. Add crtc_state as an argument to
> intel_disable_ddi_buf(). (Manasi)
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc: Gaurav K Singh 
> Cc: Jani Nikula 
> Cc: Ville Syrjala 
> Cc: Manasi Navare 
> Signed-off-by: Anusha Srivatsa 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fad7385dbd76..21af8fe1cf35 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3087,6 +3087,22 @@ static void intel_ddi_enable_fec(struct intel_encoder 
> *encoder,
>   DRM_ERROR("Timed out waiting for FEC Enable Status\n");
>  }
>  
> +static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
> + const struct intel_crtc_state 
> *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum port port = encoder->port;
> + u32 val;
> +
> + if (!crtc_state->fec_enable)
> + return;
> +
> + val = I915_READ(DP_TP_CTL(port));
> + val &= ~DP_TP_CTL_FEC_ENABLE;
> + I915_WRITE(DP_TP_CTL(port), val);
> + POSTING_READ(DP_TP_CTL(port));
> +}
> +
>  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
>   const struct intel_crtc_state *crtc_state,
>   const struct drm_connector_state 
> *conn_state)
> @@ -3230,10 +3246,12 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> *encoder,
>   }
>  }
>  
> -static void intel_disable_ddi_buf(struct intel_encoder *encoder)
> +static void intel_disable_ddi_buf(struct intel_encoder *encoder,
> +   const struct intel_crtc_state *crtc_state)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   enum port port = encoder->port;
> +

unnecessary change , bogus blank line.
With that fix,

Reviewed-by: Manasi Navare 

Manasi


>   bool wait = false;
>   u32 val;
>  
> @@ -3249,6 +3267,9 @@ static void intel_disable_ddi_buf(struct intel_encoder 
> *encoder)
>   val |= DP_TP_CTL_LINK_TRAIN_PAT1;
>   I915_WRITE(DP_TP_CTL(port), val);
>  
> + /* Disable FEC in DP Sink */
> + intel_ddi_disable_fec_state(encoder, crtc_state);
> +
>   if (wait)
>   intel_wait_ddi_buf_idle(dev_priv, port);
>  }
> @@ -3272,7 +3293,7 @@ static void intel_ddi_post_disable_dp(struct 
> intel_encoder *encoder,
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
>   }
>  
> - intel_disable_ddi_buf(encoder);
> + intel_disable_ddi_buf(encoder, old_crtc_state);
>  
>   intel_edp_panel_vdd_on(intel_dp);
>   intel_edp_panel_off(intel_dp);
> @@ -3295,7 +3316,7 @@ static void intel_ddi_post_disable_hdmi(struct 
> intel_encoder *encoder,
>  
>   intel_ddi_disable_pipe_clock(old_crtc_state);
>  
> - intel_disable_ddi_buf(encoder);
> + intel_disable_ddi_buf(encoder, old_crtc_state);
>  
>   intel_display_power_put(dev_priv, dig_port->ddi_io_power_domain);
>  
> @@ -3346,7 +3367,7 @@ void intel_ddi_fdi_post_disable(struct intel_encoder 
> *encoder,
>   val &= ~FDI_RX_ENABLE;
>   I915_WRITE(FDI_RX_CTL(PIPE_A), val);
>  
> - intel_disable_ddi_buf(encoder);
> + intel_disable_ddi_buf(encoder, old_crtc_state);
>   intel_ddi_clk_disable(encoder);
>  
>   val = I915_READ(FDI_RX_MISC(PIPE_A));
> -- 
> 2.19.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm: Convert to using %pOFn instead of device_node.name

2018-11-06 Thread Daniel Vetter
On Tue, Nov 06, 2018 at 03:57:16PM -0600, Rob Herring wrote:
> On Mon, Oct 1, 2018 at 3:17 AM Daniel Vetter  wrote:
> >
> > On Fri, Sep 28, 2018 at 05:50:44PM -0500, Rob Herring wrote:
> > > In preparation to remove the node name pointer from struct device_node,
> > > convert printf users to use the %pOFn format specifier.
> > >
> > > For drm_modes.c, the full node path is already printed out, so printing
> > > just the node name a 2nd time is redundant and can be removed.
> > >
> > > Cc: Gustavo Padovan 
> > > Cc: Maarten Lankhorst 
> > > Cc: Sean Paul 
> > > Cc: David Airlie 
> > > Acked-by: Rob Clark 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: linux-arm-...@vger.kernel.org
> > > Cc: freedr...@lists.freedesktop.org
> > > Signed-off-by: Rob Herring 
> > > ---
> > > v2:
> > > - Add to commit msg that we're dropping redundant printing of node name.
> >
> > Applied, thanks for the patch.
> 
> It appears this hasn't been.

It is, just not yet in linux-next. I'll kick the drm-misc maintainers to
roll the trees forward.
-Daniel

> 
> > Aside, still don't want drm-misc commit rights so you can offload these
> > yourself?
> 
> No thanks.
> 
> Rob
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v2] drm: Convert to using %pOFn instead of device_node.name

2018-11-06 Thread Rob Herring
On Mon, Oct 1, 2018 at 3:17 AM Daniel Vetter  wrote:
>
> On Fri, Sep 28, 2018 at 05:50:44PM -0500, Rob Herring wrote:
> > In preparation to remove the node name pointer from struct device_node,
> > convert printf users to use the %pOFn format specifier.
> >
> > For drm_modes.c, the full node path is already printed out, so printing
> > just the node name a 2nd time is redundant and can be removed.
> >
> > Cc: Gustavo Padovan 
> > Cc: Maarten Lankhorst 
> > Cc: Sean Paul 
> > Cc: David Airlie 
> > Acked-by: Rob Clark 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: linux-arm-...@vger.kernel.org
> > Cc: freedr...@lists.freedesktop.org
> > Signed-off-by: Rob Herring 
> > ---
> > v2:
> > - Add to commit msg that we're dropping redundant printing of node name.
>
> Applied, thanks for the patch.

It appears this hasn't been.

> Aside, still don't want drm-misc commit rights so you can offload these
> yourself?

No thanks.

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


Re: [PATCH] drm/framebuffer: Expose only modifiers that support at least a format

2018-11-06 Thread Dhinakaran Pandiyan
On Tue, 2018-11-06 at 22:21 +0200, Ville Syrjälä wrote:
> On Tue, Nov 06, 2018 at 11:54:45AM -0800, Dhinakaran Pandiyan wrote:
> > On Tue, 2018-11-06 at 16:13 +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 05, 2018 at 06:44:34PM -0800, Dhinakaran Pandiyan
> > > wrote:
> > > > Allows drivers to pass a larger modifier array, thereby
> > > > avoiding
> > > > declarations of static modifier arrays that are only slight
> > > > different
> > > > for each plane.
> > > > 
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Ville Syrjälä 
> > > > Suggested-by: Ville Syrjälä 
> > > > Signed-off-by: Dhinakaran Pandiyan <
> > > > dhinakaran.pandi...@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/drm_plane.c | 35 +++
> > > > 
> > > > 
> > > >  1 file changed, 27 insertions(+), 8 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > > b/drivers/gpu/drm/drm_plane.c
> > > > index 1fa98bd12003..1546ffbf8e36 100644
> > > > --- a/drivers/gpu/drm/drm_plane.c
> > > > +++ b/drivers/gpu/drm/drm_plane.c
> > > > @@ -179,8 +179,8 @@ int drm_universal_plane_init(struct
> > > > drm_device
> > > > *dev, struct drm_plane *plane,
> > > >  const char *name, ...)
> > > >  {
> > > > struct drm_mode_config *config = >mode_config;
> > > > -   unsigned int format_modifier_count = 0;
> > > > -   int ret;
> > > > +   unsigned int format_modifier_count, in_modifier_count =
> > > > 0;
> > > > +   int ret, i;
> > > >  
> > > > /* plane index is used with 32bit bitmasks */
> > > > if (WARN_ON(config->num_total_plane >= 32))
> > > > @@ -216,22 +216,43 @@ int drm_universal_plane_init(struct
> > > > drm_device *dev, struct drm_plane *plane,
> > > >  
> > > > if (format_modifiers) {
> > > > const uint64_t *temp_modifiers =
> > > > format_modifiers;
> > > > +
> > > > while (*temp_modifiers++ !=
> > > > DRM_FORMAT_MOD_INVALID)
> > > > -   format_modifier_count++;
> > > > +   in_modifier_count++;
> > > > }
> > > >  
> > > > -   plane->modifier_count = format_modifier_count;
> > > > -   plane->modifiers = kmalloc_array(format_modifier_count,
> > > > +   plane->modifiers = kmalloc_array(in_modifier_count,
> > > >  sizeof(format_modifier
> > > > s[0]),
> > > >  GFP_KERNEL);
> > > >  
> > > > -   if (format_modifier_count && !plane->modifiers) {
> > > > +   if (in_modifier_count && !plane->modifiers) {
> > > > DRM_DEBUG_KMS("out of memory when allocating
> > > > plane\n");
> > > > kfree(plane->format_types);
> > > > drm_mode_object_unregister(dev, >base);
> > > > return -ENOMEM;
> > > > }
> > > >  
> > > > +   for (i = 0, format_modifier_count = 0; i <
> > > > in_modifier_count;
> > > > i++) {
> > > > +   int j;
> > > > +
> > > > +   for (j = 0; funcs->format_mod_supported && j <
> > > > format_count; j++)
> > > > +   if (funcs->format_mod_supported(plane,
> > > > formats[j],
> > > > +   format_
> > > > modifier
> > > > s[i]))
> > > > +   break;
> > > > +
> > > > +   if (j < format_count)
> > > > +   plane-
> > > > >modifiers[format_modifier_count++] =
> > > > +   format_modifiers[i];
> > > > +   }
> > > > +
> > > > +   if (format_modifier_count < in_modifier_count) {
> > > > +   size_t size;
> > > > +
> > > > +   size = format_modifier_count *
> > > > sizeof(format_modifiers[0]);
> > > > +   plane->modifiers = krealloc(plane->modifiers,
> > > > size,
> > > > GFP_KERNEL);
> > > 
> > > Should check that the realloc actually succeeded.
> > 
> > Didn't see a failure path for new size smaller than old, the return
> > is
> > the same pointer passed to krealloc().
> 
> I don't know if we want to rely on an implementation detail that
> hevily.
Fair enough.

>  But that does raise the interesting point that trying to
> shrink our memory footprint with krealloc() is futile. I suppose
> there is still some kind of debugging benefit from the kasan
> stuff.
> 
> > 
> > > 
> > > And I think we might want to give this same treatment to plane-
> > > > formats[]
> > > 
> > > as well.
> > > 
> > > And perhaps we could even throw out plane->modifiers[] and just
> > > rely
> > > on
> > > the IN_FORMATS blob exclusively? Hmm. Looks like that is not
> > > getting
> > > fully
> > > populated unless the driver has provided .format_mod_supported().
> > > Not
> > > sure why that is, and not sure what userspace is supposed to do
> > > with
> > > a
> > > partially filled blob like that. I'm thinking we shouldn't even
> > > attach
> > > the property to the plane in that case.
> 

Re: [PATCH] drm: rcar-du: Fix external clock error checks

2018-11-06 Thread Kieran Bingham
Hi Laurent,

Thank you for the patch,

On 06/11/2018 15:39, Laurent Pinchart wrote:
> The rcar-du driver supports probe deferral for external clocks, but
> implements it badly by checking the wrong pointer due to a bad copy and
> paste. Fix it.
> 
> While at it, reject invalid clocks outright for DU channels that have a
> display PLL, as the external clock is mandatory in that case. This
> avoids a WARN_ON() at runtime.
> 
> Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
> Reported-by: Kuninori Morimoto 
> Signed-off-by: Laurent Pinchart 

This looks good to me:

Reviewed-by: Kieran Bingham 

> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index d18a342626b5..79021d7aa3ce 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -226,9 +226,6 @@ static void rcar_du_crtc_set_display_timing(struct 
> rcar_du_crtc *rcrtc)
>* system clock, and have no internal clock divider.
>*/
>  
> - if (WARN_ON(!rcrtc->extclock))
> - return;
> -
>   /*
>* The H3 ES1.x exhibits dot clock duty cycle stability issues.
>* We can work around them by configuring the DPLL to twice the
> @@ -1113,9 +1110,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
> unsigned int swindex,
>   clk = devm_clk_get(rcdu->dev, clk_name);
>   if (!IS_ERR(clk)) {
>   rcrtc->extclock = clk;
> - } else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
> - dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
> + } else if (PTR_ERR(clk) == -EPROBE_DEFER) {
>   return -EPROBE_DEFER;
> + } else if (rcdu->info->dpll_mask & BIT(hwindex)) {
> + /*
> +  * DU channels that have a display PLL can't use the internal
> +  * system clock and thus require an external clock.
> +  */
> + ret = PTR_ERR(clk);
> + dev_err(rcdu->dev, "can't get dclkin.%u: %d\n", hwindex, ret);
> + return ret;
>   }
>  
>   init_waitqueue_head(>flip_wait);
> 

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


[Bug 108577] Black X laptop screen with cursor if HDMI not plugged in, bisected

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108577

--- Comment #30 from Alex Deucher  ---
Can you try this patch set?
https://patchwork.freedesktop.org/series/52117/

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


[PATCH] drm/msm: Set dma maximum segment size for mdss

2018-11-06 Thread Sean Paul
From: Sean Paul 

Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:

[   12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device 
claims to support [len=3526656] [max=65536]
[   12.089870] WARNING: CPU: 6 PID: 334 at 
/mnt/host/source/src/third_party/kernel/v4.19/kernel/dma/debug.c:1301 
debug_dma_map_sg+0x1dc/0x318
[   12.102655] Modules linked in: joydev
[   12.106442] CPU: 6 PID: 334 Comm: frecon Not tainted 4.19.0 #2
[   12.112450] Hardware name: Google Cheza (rev3+) (DT)
[   12.117566] pstate: 6049 (nZCv daif +PAN -UAO)
[   12.122506] pc : debug_dma_map_sg+0x1dc/0x318
[   12.126995] lr : debug_dma_map_sg+0x1dc/0x318
[   12.131487] sp : ff800cc3ba80
[   12.134913] x29: ff800cc3ba80 x28: 
[   12.140395] x27: 0004 x26: 0004
[   12.145868] x25: ff8008e55b18 x24: 
[   12.151337] x23:  x22: ff800921c000
[   12.156809] x21: ffc0fa75b080 x20: ffc0f7195090
[   12.162280] x19: ffc0f1c53280 x18: 
[   12.167749] x17:  x16: 
[   12.173218] x15:  x14: 0720072007200720
[   12.178689] x13: 0720072007200720 x12: 0720072007200720
[   12.184161] x11: 0720072007200720 x10: 0720072007200720
[   12.189641] x9 : ffc0f1fc6b60 x8 : 
[   12.195110] x7 : ff8008132ce0 x6 : 
[   12.200585] x5 :  x4 : ff8008134734
[   12.206058] x3 : ff800cc3b830 x2 : ffc0f1fc6240
[   12.211532] x1 : 25045a74f48a7400 x0 : 25045a74f48a7400
[   12.217006] Call trace:
[   12.219535]  debug_dma_map_sg+0x1dc/0x318
[   12.223671]  get_pages+0x19c/0x20c
[   12.227177]  msm_gem_fault+0x64/0xfc
[   12.230874]  __do_fault+0x3c/0x140
[   12.234383]  __handle_mm_fault+0x70c/0xdb8
[   12.238603]  handle_mm_fault+0xac/0xc4
[   12.242473]  do_page_fault+0x1bc/0x3d4
[   12.246342]  do_translation_fault+0x54/0x88
[   12.250652]  do_mem_abort+0x60/0xf0
[   12.254250]  el0_da+0x20/0x24
[   12.257317] irq event stamp: 67260
[   12.260828] hardirqs last  enabled at (67259): [] 
console_unlock+0x214/0x608
[   12.269693] hardirqs last disabled at (67260): [] 
do_debug_exception+0x5c/0x178
[   12.278820] softirqs last  enabled at (67256): [] 
__do_softirq+0x4d4/0x520
[   12.287510] softirqs last disabled at (67249): [] 
irq_exit+0xa8/0x100
[   12.295742] ---[ end trace e63cfc40c313ffab ]---

The root of the problem is that the default segment size for sgt is
(UINT_MAX & PAGE_MASK), and the default segment size for device dma is
64K. As such, if you compare the 2, you would deduce that the sg segment
will overflow the device's capacity. In reality, the hardware can
accommodate the larger sg segments, it's just not initializing its max
segment properly. This patch initializes the max segment size for the
mdss device, which gets rid of that pesky warning.

Reported-by: Stephen Boyd 
Signed-off-by: Sean Paul 
---
 drivers/gpu/drm/msm/msm_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c9f7ff6960b..ea74542d08e4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -492,6 +492,14 @@ static int msm_drm_init(struct device *dev, struct 
drm_driver *drv)
if (ret)
goto err_msm_uninit;
 
+   if (!dev->dma_parms) {
+   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
+ GFP_KERNEL);
+   if (!dev->dma_parms)
+   return -ENOMEM;
+   }
+   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
+
msm_gem_shrinker_init(ddev);
 
switch (get_mdp_ver(pdev)) {
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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


[PATCH v5 3/5] drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()

2018-11-06 Thread Lyude Paul
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the threshold, e.g. an HPD threshold of 5
would not trigger a storm until we reach a total of 7 hotplugs.

So: rework the code a bit so we reset the HPD count when
HPD_STORM_DETECT_DELAY has passed, then increment the count afterwards.
Also, clean things up a bit to make it easier to undertand.

Signed-off-by: Lyude Paul 
Reviewed-by: Ville Syrjälä 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 8326900a311e..c11d73de16f2 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -135,24 +135,27 @@ enum hpd_pin intel_hpd_pin_default(struct 
drm_i915_private *dev_priv,
 static bool intel_hpd_irq_storm_detect(struct drm_i915_private *dev_priv,
   enum hpd_pin pin)
 {
-   unsigned long start = dev_priv->hotplug.stats[pin].last_jiffies;
+   struct i915_hotplug *hpd = _priv->hotplug;
+   unsigned long start = hpd->stats[pin].last_jiffies;
unsigned long end = start + msecs_to_jiffies(HPD_STORM_DETECT_PERIOD);
-   const int threshold = dev_priv->hotplug.hpd_storm_threshold;
+   const int threshold = hpd->hpd_storm_threshold;
bool storm = false;
 
+   if (!threshold)
+   return false;
+
if (!time_in_range(jiffies, start, end)) {
-   dev_priv->hotplug.stats[pin].last_jiffies = jiffies;
-   dev_priv->hotplug.stats[pin].count = 0;
-   DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: 0\n", 
pin);
-   } else if (dev_priv->hotplug.stats[pin].count > threshold &&
-  threshold) {
-   dev_priv->hotplug.stats[pin].state = HPD_MARK_DISABLED;
+   hpd->stats[pin].last_jiffies = jiffies;
+   hpd->stats[pin].count = 0;
+   }
+
+   if (++hpd->stats[pin].count > threshold) {
+   hpd->stats[pin].state = HPD_MARK_DISABLED;
DRM_DEBUG_KMS("HPD interrupt storm detected on PIN %d\n", pin);
storm = true;
} else {
-   dev_priv->hotplug.stats[pin].count++;
DRM_DEBUG_KMS("Received HPD interrupt on PIN %d - cnt: %d\n", 
pin,
- dev_priv->hotplug.stats[pin].count);
+ hpd->stats[pin].count);
}
 
return storm;
-- 
2.19.1

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


[PATCH v5 4/5] drm/i915: Clarify flow for disabling IRQs on storms

2018-11-06 Thread Lyude Paul
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.

Changes since v3:
- Rename i915_hpd_irq_storm_disable() to
  i915_hpd_irq_storm_switch_to_polling() - Rodrigo Vivi

Signed-off-by: Lyude Paul 
Reviewed-by: Ville Syrjälä 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index c11d73de16f2..d642c0795452 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -161,7 +161,8 @@ static bool intel_hpd_irq_storm_detect(struct 
drm_i915_private *dev_priv,
return storm;
 }
 
-static void intel_hpd_irq_storm_disable(struct drm_i915_private *dev_priv)
+static void
+intel_hpd_irq_storm_switch_to_polling(struct drm_i915_private *dev_priv)
 {
struct drm_device *dev = _priv->drm;
struct intel_connector *intel_connector;
@@ -351,8 +352,8 @@ static void i915_hotplug_work_func(struct work_struct *work)
hpd_event_bits = dev_priv->hotplug.event_bits;
dev_priv->hotplug.event_bits = 0;
 
-   /* Disable hotplug on connectors that hit an irq storm. */
-   intel_hpd_irq_storm_disable(dev_priv);
+   /* Enable polling for connectors which had HPD IRQ storms */
+   intel_hpd_irq_storm_switch_to_polling(dev_priv);
 
spin_unlock_irq(_priv->irq_lock);
 
@@ -458,6 +459,10 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
}
}
 
+   /*
+* Disable any IRQs that storms were detected on. Polling enablement
+* happens later in our hotplug work.
+*/
if (storm_detected && dev_priv->display_irqs_enabled)
dev_priv->display.hpd_irq_setup(dev_priv);
spin_unlock(_priv->irq_lock);
-- 
2.19.1

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


[PATCH v5 2/5] drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST

2018-11-06 Thread Lyude Paul
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:

[  332.339041] BUG: unable to handle kernel NULL pointer dereference at 
00ec
[  332.340906] PGD 0 P4D 0
[  332.342750] Oops:  [#1] SMP PTI
[  332.344579] CPU: 2 PID: 25 Comm: kworker/2:0 Kdump: loaded Tainted: G
   O  4.18.0-rc3short-hpd-storm+ #2
[  332.346453] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET71WW (1.35 
) 09/14/2018
[  332.348361] Workqueue: events intel_hpd_irq_storm_reenable_work [i915]
[  332.350301] RIP: 0010:intel_hpd_irq_storm_reenable_work.cold.3+0x2f/0x86 
[i915]
[  332.352213] Code: 00 00 ba e8 00 00 00 48 c7 c6 c0 aa 5f a0 48 c7 c7 d0 73 
62 a0 4c 89 c1 4c 89 04 24 e8 7f f5 af e0 4c 8b 04 24 44 89 f8 29 e8 <41> 39 80 
ec 00 00 00 0f 85 43 13 fc ff 41 0f b6 86 b8 04 00 00 41
[  332.354286] RSP: 0018:c9147e48 EFLAGS: 00010006
[  332.356344] RAX: 0005 RBX: 8802c226c9d4 RCX: 0006
[  332.358404] RDX:  RSI: 0082 RDI: 88032dc95570
[  332.360466] RBP: 0005 R08:  R09: 88031b3dc840
[  332.362528] R10:  R11: 00031a069602 R12: 8802c226ca20
[  332.364575] R13: 8802c2268000 R14: 880310661000 R15: 000a
[  332.366615] FS:  () GS:88032dc8() 
knlGS:
[  332.368658] CS:  0010 DS:  ES:  CR0: 80050033
[  332.370690] CR2: 00ec CR3: 0200a003 CR4: 003606e0
[  332.372724] DR0:  DR1:  DR2: 
[  332.374773] DR3:  DR6: fffe0ff0 DR7: 0400
[  332.376798] Call Trace:
[  332.378809]  process_one_work+0x1a1/0x350
[  332.380806]  worker_thread+0x30/0x380
[  332.382777]  ? wq_update_unbound_numa+0x10/0x10
[  332.384772]  kthread+0x112/0x130
[  332.386740]  ? kthread_create_worker_on_cpu+0x70/0x70
[  332.388706]  ret_from_fork+0x35/0x40
[  332.390651] Modules linked in: i915(O) vfat fat joydev btusb btrtl btbcm 
btintel bluetooth ecdh_generic iTCO_wdt wmi_bmof i2c_algo_bit drm_kms_helper 
intel_rapl syscopyarea sysfillrect x86_pkg_temp_thermal sysimgblt coretemp 
fb_sys_fops crc32_pclmul drm psmouse pcspkr mei_me mei i2c_i801 lpc_ich 
mfd_core i2c_core tpm_tis tpm_tis_core thinkpad_acpi wmi tpm rfkill video 
crc32c_intel serio_raw ehci_pci xhci_pci ehci_hcd xhci_hcd [last unloaded: i915]
[  332.394963] CR2: 00ec

This appears to be due to the fact that with an MST topology, not all
intel_connector structs will have ->encoder set. So, fix this by
skipping connectors without encoders in
intel_hpd_irq_storm_reenable_work().

For those wondering, this bug was found on accident while simulating HPD
storms using a Chamelium connected to a ThinkPad T450s (Broadwell).

Changes since v1:
- Check intel_connector->mst_port instead of intel_connector->encoder

Signed-off-by: Lyude Paul 
Reviewed-by: Ville Syrjälä 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_hotplug.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 648a13c6043c..8326900a311e 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -228,7 +228,9 @@ static void intel_hpd_irq_storm_reenable_work(struct 
work_struct *work)
drm_for_each_connector_iter(connector, _iter) {
struct intel_connector *intel_connector = 
to_intel_connector(connector);
 
-   if (intel_connector->encoder->hpd_pin == pin) {
+   /* Don't check MST ports, they don't have pins */
+   if (!intel_connector->mst_port &&
+   intel_connector->encoder->hpd_pin == pin) {
if (connector->polled != 
intel_connector->polled)
DRM_DEBUG_DRIVER("Reenabling HPD on 
connector %s\n",
 connector->name);
-- 
2.19.1

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


[PATCH v5 0/5] drm/i915: HPD IRQ storm detection fixes

2018-11-06 Thread Lyude Paul
This series contains a fix for a problem which is very difficult to
reproduce under normal circumstances without specialized testing
hardware, along with a fix that seems to be required for some especially
rebellious GM45 laptops.

Lyude Paul (5):
  drm/i915: Fix possible race in intel_dp_add_mst_connector()
  drm/i915: Fix NULL deref when re-enabling HPD IRQs on systems with MST
  drm/i915: Fix threshold check in intel_hpd_irq_storm_detect()
  drm/i915: Clarify flow for disabling IRQs on storms
  drm/i915: Add short HPD IRQ storm detection for non-MST systems

 drivers/gpu/drm/i915/i915_debugfs.c  | 74 
 drivers/gpu/drm/i915/i915_drv.h  |  5 +-
 drivers/gpu/drm/i915/i915_irq.c  |  7 +++
 drivers/gpu/drm/i915/intel_dp_mst.c  |  8 +--
 drivers/gpu/drm/i915/intel_hotplug.c | 84 +---
 5 files changed, 141 insertions(+), 37 deletions(-)

-- 
2.19.1

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


[PATCH v5 5/5] drm/i915: Add short HPD IRQ storm detection for non-MST systems

2018-11-06 Thread Lyude Paul
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having updated. The amount of time it took to boot went
from around 30 seconds, to over 6 minutes consistently.

After some investigation, I discovered that i915 was reporting massive
amounts of short HPD IRQ spam on this system from the DisplayPort port,
despite there not being anything actually connected. The symptoms would
start with one "long" HPD IRQ being detected at boot:

[1.891398] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0044, dig 0x0044, pins 0x00a0
[1.891436] [drm:intel_hpd_irq_handler [i915]] digital hpd port B - long
[1.891472] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 
5 - cnt: 0
[1.891508] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - long
[1.891544] [drm:intel_hpd_irq_handler [i915]] Received HPD interrupt on PIN 
7 - cnt: 0
[1.891592] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port B - long
[1.891628] [drm:intel_dp_hpd_pulse [i915]] got hpd irq on port D - long
…

followed by constant short IRQs afterwards:

[1.895091] [drm:intel_encoder_hotplug [i915]] [CONNECTOR:66:DP-1] status 
updated from unknown to disconnected
[1.895129] [drm:i915_hotplug_work_func [i915]] Connector DP-3 (pin 7) 
received hotplug event.
[1.895165] [drm:intel_dp_detect [i915]] [CONNECTOR:72:DP-3]
[1.895275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x0020, pins 0x0080
[1.895312] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.895762] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x0020, pins 0x0080
[1.895799] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896239] [drm:intel_dp_aux_xfer [i915]] dp_aux_ch timeout status 
0x71450085
[1.896293] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x0020, pins 0x0080
[1.896330] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.896781] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x0020, pins 0x0080
[1.896817] [drm:intel_hpd_irq_handler [i915]] digital hpd port D - short
[1.897275] [drm:intel_get_hpd_pins [i915]] hotplug event received, stat 
0x0020, dig 0x0020, pins 0x0080

The customer's system in question has a GM45 GPU, which is apparently
well known for hotplugging storms.

So, workaround this impressively broken hardware by changing the default
HPD storm threshold from 5 to 50. Then, make long IRQs count for 10, and
short IRQs count for 1. This makes it so that 5 long IRQs will trigger
an HPD storm, and on systems with short HPD storm detection 50 short
IRQs will trigger an HPD storm. 50 short IRQs amounts to 100ms of
constant pulsing, which seems like a good middleground between being too
sensitive and not being sensitive enough (which would cause visible
stutters in userspace every time a storm occurs).

And just to be extra safe: we don't enable this by default on systems
with MST support. There's too high of a chance of MST support triggering
storm detection, and systems that are new enough to support MST are a
lot less likely to have issues with IRQ storms anyway.

As a note: this patch was tested using a ThinkPad T450s and a Chamelium
to simulate the short IRQ storms.

Changes since v1:
- Don't use two separate thresholds, just make long IRQs count for 10
  each and short IRQs count for 1. This simplifies the code a bit
  - Ville Syrjälä
Changes since v2:
- Document @long_hpd in intel_hpd_irq_storm_detect, no functional
  changes
Changes since v4:
- Remove !! in long_hpd assignment - Ville Syrjälä
- queue_hp = true - Ville Syrjälä

Signed-off-by: Lyude Paul 
Cc: Ville Syrjälä 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 74 
 drivers/gpu/drm/i915/i915_drv.h  |  5 +-
 drivers/gpu/drm/i915/i915_irq.c  |  7 +++
 drivers/gpu/drm/i915/intel_hotplug.c | 50 +++
 4 files changed, 115 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f60485906f7e..670db5073d70 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4658,6 +4658,79 @@ static const struct file_operations 
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
 };
 
+static int i915_hpd_short_storm_ctl_show(struct seq_file *m, void *data)
+{
+   struct drm_i915_private *dev_priv = m->private;
+
+   seq_printf(m, "Enabled: %s\n",
+  yesno(dev_priv->hotplug.hpd_short_storm_enabled));
+
+   return 0;
+}
+
+static int

[PATCH v5 1/5] drm/i915: Fix possible race in intel_dp_add_mst_connector()

2018-11-06 Thread Lyude Paul
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering the connector but before
having written it's value.

Signed-off-by: Lyude Paul 
Reviewed-by: Ville Syrjälä 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 8b71d64ebd9d..8cb4093f8bcc 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -441,6 +441,10 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
if (!intel_connector)
return NULL;
 
+   intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
+   intel_connector->mst_port = intel_dp;
+   intel_connector->port = port;
+
connector = _connector->base;
ret = drm_connector_init(dev, connector, _dp_mst_connector_funcs,
 DRM_MODE_CONNECTOR_DisplayPort);
@@ -451,10 +455,6 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
 
drm_connector_helper_add(connector, 
_dp_mst_connector_helper_funcs);
 
-   intel_connector->get_hw_state = intel_dp_mst_get_hw_state;
-   intel_connector->mst_port = intel_dp;
-   intel_connector->port = port;
-
for_each_pipe(dev_priv, pipe) {
struct drm_encoder *enc =
_dp->mst_encoders[pipe]->base.base;
-- 
2.19.1

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


[radeon-alex:amd-staging-drm-next 12/15] drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:117:1: warning: the frame size of 1040 bytes is larger than 1024 bytes

2018-11-06 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head:   3902c0af567d658245ac01f2e33b39b2ff1ddd75
commit: 08dda26796ddd8a83e3b3568dc44e65a3108c56f [12/15] drm/amdgpu/psp: update 
topology info structures
config: i386-randconfig-s2-201844 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 08dda26796ddd8a83e3b3568dc44e65a3108c56f
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c: In function 
'amdgpu_xgmi_add_device':
>> drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c:117:1: warning: the frame size of 
>> 1040 bytes is larger than 1024 bytes [-Wframe-larger-than=]
}
^

vim +117 drivers/gpu//drm/amd/amdgpu/amdgpu_xgmi.c

230dee18 Shaoyun Liu   2018-06-27   63  
230dee18 Shaoyun Liu   2018-06-27   64  int amdgpu_xgmi_add_device(struct 
amdgpu_device *adev)
230dee18 Shaoyun Liu   2018-06-27   65  {
08dda267 Hawking Zhang 2018-09-29   66  struct psp_xgmi_topology_info 
tmp_topology;
230dee18 Shaoyun Liu   2018-06-27   67  struct amdgpu_hive_info *hive;
230dee18 Shaoyun Liu   2018-06-27   68  struct amdgpu_xgmi  *entry;
230dee18 Shaoyun Liu   2018-06-27   69  struct amdgpu_device
*tmp_adev;
230dee18 Shaoyun Liu   2018-06-27   70  
230dee18 Shaoyun Liu   2018-06-27   71  int count = 0, ret = -EINVAL;
230dee18 Shaoyun Liu   2018-06-27   72  
230dee18 Shaoyun Liu   2018-06-27   73  if ((adev->asic_type < 
CHIP_VEGA20) ||
230dee18 Shaoyun Liu   2018-06-27   74  (adev->flags & 
AMD_IS_APU) )
230dee18 Shaoyun Liu   2018-06-27   75  return 0;
4eb24be0 Hawking Zhang 2018-09-28   76  adev->gmc.xgmi.node_id = 
psp_xgmi_get_node_id(>psp);
230dee18 Shaoyun Liu   2018-06-27   77  adev->gmc.xgmi.hive_id = 
psp_xgmi_get_hive_id(>psp);
230dee18 Shaoyun Liu   2018-06-27   78  
08dda267 Hawking Zhang 2018-09-29   79  memset(_topology, 0, 
sizeof(tmp_topology));
230dee18 Shaoyun Liu   2018-06-27   80  mutex_lock(_mutex);
230dee18 Shaoyun Liu   2018-06-27   81  hive = 
amdgpu_get_xgmi_hive(adev);
230dee18 Shaoyun Liu   2018-06-27   82  if (!hive)
230dee18 Shaoyun Liu   2018-06-27   83  goto exit;
230dee18 Shaoyun Liu   2018-06-27   84  
230dee18 Shaoyun Liu   2018-06-27   85  
list_add_tail(>gmc.xgmi.head, >device_list);
230dee18 Shaoyun Liu   2018-06-27   86  list_for_each_entry(entry, 
>device_list, head)
08dda267 Hawking Zhang 2018-09-29   87  
tmp_topology.nodes[count++].node_id = entry->node_id;
230dee18 Shaoyun Liu   2018-06-27   88  
08dda267 Hawking Zhang 2018-09-29   89  ret = 
psp_xgmi_get_topology_info(>psp, count, _topology);
230dee18 Shaoyun Liu   2018-06-27   90  if (ret) {
230dee18 Shaoyun Liu   2018-06-27   91  dev_err(adev->dev,
230dee18 Shaoyun Liu   2018-06-27   92  "XGMI: Get 
topology failure on device %llx, hive %llx, ret %d",
4eb24be0 Hawking Zhang 2018-09-28   93  
adev->gmc.xgmi.node_id,
230dee18 Shaoyun Liu   2018-06-27   94  
adev->gmc.xgmi.hive_id, ret);
230dee18 Shaoyun Liu   2018-06-27   95  goto exit;
230dee18 Shaoyun Liu   2018-06-27   96  }
230dee18 Shaoyun Liu   2018-06-27   97  /* Each psp need to set the 
latest topology */
230dee18 Shaoyun Liu   2018-06-27   98  list_for_each_entry(tmp_adev, 
>device_list, gmc.xgmi.head) {
08dda267 Hawking Zhang 2018-09-29   99  ret = 
psp_xgmi_set_topology_info(_adev->psp, count, _topology);
230dee18 Shaoyun Liu   2018-06-27  100  if (ret) {
230dee18 Shaoyun Liu   2018-06-27  101  
dev_err(tmp_adev->dev,
230dee18 Shaoyun Liu   2018-06-27  102  "XGMI: 
Set topology failure on device %llx, hive %llx, ret %d",
4eb24be0 Hawking Zhang 2018-09-28  103  
tmp_adev->gmc.xgmi.node_id,
230dee18 Shaoyun Liu   2018-06-27  104  
tmp_adev->gmc.xgmi.hive_id, ret);
230dee18 Shaoyun Liu   2018-06-27  105  /* To do : 
continue with some  node failed or disable the  whole  hive */
230dee18 Shaoyun Liu   2018-06-27  106  break;
230dee18 Shaoyun Liu   2018-06-27  107  }
230dee18 Shaoyun Liu   2018-06-27  108  }
230dee18 Shaoyun Liu   2018-06-27  109  if (!ret)
230dee18 Shaoyun Liu   2018-06-27  110  dev_info(adev->dev, 
"XGMI: Add node %d to hive 0x%llx.\n",
230dee18 Shaoyun Liu   2018-06-27  111  
adev->gmc.xgmi.physical_node_id,
230dee18 Shaoyun Liu   2018-06-27  112  
adev->gmc.xgmi.hive_id);
230dee18 Shaoyun Liu   2018-06-27  113  
230dee18 Shaoyun Liu   2018-06-27  114  

Re: [PATCH v2] backlight: pwm_bl: Fix brightness levels for non-DT case.

2018-11-06 Thread Uwe Kleine-König
On Tue, Oct 30, 2018 at 11:34:41AM +0100, Enric Balletbo i Serra wrote:
> Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
> linearly to human eye")' allows the possibility to compute a default
> brightness table when there isn't the brightness-levels property in the
> DT. Unfortunately the changes made broke the pwm backlight for the
> non-DT boards.
> 
> Usually, the non-DT boards don't pass the brightness levels via platform
> data, instead, it sets the max_brightness in their platform data and the
> driver calculates the level without a table. The ofending patch assumed

s/ofending/offending/

> hat when there is no brightness levels table we should create one, but this

s/hat/that/

> is clearly wrong for the non-DT case.
> 
> After this patch the code handles the DT and the non-DT case taking in
> consideration also if max_brightness is set or not.
> 
> Fixes: '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED linearly 
> to human eye")'

These ' are unusual.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 07/19] drm/i915/dp: Compute DSC pipe config in atomic check

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:42:56PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 02, 2018 at 07:09:03PM -0700, Manasi Navare wrote:
> > On Fri, Nov 02, 2018 at 02:31:26PM -0700, Manasi Navare wrote:
> > > DSC params like the enable, compressed bpp, slice count and
> > > dsc_split are added to the intel_crtc_state. These parameters
> > > are set based on the requested mode and available link parameters
> > > during the pipe configuration in atomic check phase.
> > > These values are then later used to populate the remaining DSC
> > > and RC parameters before enbaling DSC in atomic commit.
> > > 
> > > v11:
> > > * Const crtc_state, reject DSC on DP without FEC (Ville)
> > > * Dont set dsc_split to false (Ville)
> > > v10:
> > > * Add a helper for dp_dsc support (Ville)
> > > * Set pipe_config to max bpp, link params for DSC for now (Ville)
> > > * Compute bpp - use dp dsc support helper (Ville)
> > > v9:
> > > * Rebase on top of drm-tip that now uses fast_narrow config
> > > for edp (Manasi)
> > > v8:
> > > * Check for DSC bpc not 0 (manasi)
> > > 
> > > v7:
> > > * Fix indentation in compute_m_n (Manasi)
> > > 
> > > v6 (From Gaurav):
> > > * Remove function call of intel_dp_compute_dsc_params() and
> > > invoke intel_dp_compute_dsc_params() in the patch where
> > > it is defined to fix compilation warning (Gaurav)
> > > 
> > > v5:
> > > Add drm_dsc_cfg in intel_crtc_state (Manasi)
> > > 
> > > v4:
> > > * Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
> > > * Add a comment why we need to check PSR while enabling DSC (Gaurav)
> > > 
> > > v3:
> > > * Check PPR > max_cdclock to use 2 VDSC instances (Ville)
> > > 
> > > v2:
> > > * Add if-else for eDP/DP (Gaurav)
> > > 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjala 
> > > Cc: Anusha Srivatsa 
> > > Cc: Gaurav K Singh 
> > > Signed-off-by: Manasi Navare 
> > > Reviewed-by: Anusha Srivatsa 
> > > Acked-by: Jani Nikula 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c |  20 +++-
> > >  drivers/gpu/drm/i915/intel_display.h |   3 +-
> > >  drivers/gpu/drm/i915/intel_dp.c  | 167 ---
> > >  drivers/gpu/drm/i915/intel_dp_mst.c  |   2 +-
> > >  4 files changed, 166 insertions(+), 26 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index b219d5858160..477e53c37353 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6442,7 +6442,7 @@ static int ironlake_fdi_compute_config(struct 
> > > intel_crtc *intel_crtc,
> > >  
> > >   pipe_config->fdi_lanes = lane;
> > >  
> > > - intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
> > > + intel_link_compute_m_n(pipe_config->pipe_bpp, 0, lane, fdi_dotclock,
> > >  link_bw, _config->fdi_m_n, false);
> > >  
> > >   ret = ironlake_check_fdi_lanes(dev, intel_crtc->pipe, pipe_config);
> > > @@ -6679,17 +6679,25 @@ static void compute_m_n(unsigned int m, unsigned 
> > > int n,
> > >  }
> > >  
> > >  void
> > > -intel_link_compute_m_n(int bits_per_pixel, int nlanes,
> > > +intel_link_compute_m_n(int bits_per_pixel, uint16_t compressed_bpp,
> > > +int nlanes,
> > >  int pixel_clock, int link_clock,
> > >  struct intel_link_m_n *m_n,
> > >  bool constant_n)
> > >  {
> > >   m_n->tu = 64;
> > >  
> > > - compute_m_n(bits_per_pixel * pixel_clock,
> > > - link_clock * nlanes * 8,
> > > - _n->gmch_m, _n->gmch_n,
> > > - constant_n);
> > > + /* For DSC, Data M/N calculation uses compressed BPP */
> > > + if (compressed_bpp)
> > > + compute_m_n(compressed_bpp * pixel_clock,
> > > + link_clock * nlanes * 8,
> > > + _n->gmch_m, _n->gmch_n,
> > > + constant_n);
> > > + else
> > > + compute_m_n(bits_per_pixel * pixel_clock,
> > > + link_clock * nlanes * 8,
> > > + _n->gmch_m, _n->gmch_n,
> > > + constant_n);
> > >  
> > >   compute_m_n(pixel_clock, link_clock,
> > >   _n->link_m, _n->link_n,
> > > diff --git a/drivers/gpu/drm/i915/intel_display.h 
> > > b/drivers/gpu/drm/i915/intel_display.h
> > > index 5d50decbcbb5..b0b23e1e9392 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > @@ -407,7 +407,8 @@ struct intel_link_m_n {
> > >(__i)++) \
> > >   for_each_if(plane)
> > >  
> > > -void intel_link_compute_m_n(int bpp, int nlanes,
> > > +void intel_link_compute_m_n(int bpp, uint16_t compressed_bpp,
> > > + int nlanes,
> > >   int pixel_clock, int link_clock,
> > >   struct intel_link_m_n *m_n,
> > >   bool constant_n);
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 

Re: [PATCH v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC

2018-11-06 Thread Ville Syrjälä
On Tue, Nov 06, 2018 at 12:14:50PM -0800, Manasi Navare wrote:
> On Tue, Nov 06, 2018 at 07:00:50PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 06, 2018 at 08:52:41AM -0800, Manasi Navare wrote:
> > > On Tue, Nov 06, 2018 at 04:33:38PM +0200, Ville Syrjälä wrote:
> > > > On Fri, Nov 02, 2018 at 02:31:29PM -0700, Manasi Navare wrote:
> > > > > From: Gaurav K Singh 
> > > > > 
> > > > > This computation of RC params happens in the atomic commit phase
> > > > > during compute_config() to validate if display stream compression
> > > > > can be enabled for the requested mode.
> > > > > 
> > > > > v7 (From Manasi):
> > > > > * Use DRM_DEBUG instead of DRM_ERROR (Ville)
> > > > > * Use Error numberinstead of -1 (Ville)
> > > > > v6 (From Manasi):
> > > > > * Use 9 instead of 0x9 for consistency (Anusha)
> > > > > 
> > > > > v5 (From Manasi):
> > > > > * Fix dim checkpatch warnings/checks
> > > > > v4(From Gaurav):
> > > > > * No change.Rebase on drm-tip
> > > > > 
> > > > > v3 (From Gaurav):
> > > > > * Rebase on top of Manasi's latest series
> > > > > * Return -ve value in case of failure scenarios (Manasi)
> > > > > 
> > > > > Fix review comments from Ville:
> > > > > * Remove unnecessary comments
> > > > > * Remove unnecessary paranthesis
> > > > > * Add comments for few RC params calculations
> > > > > 
> > > > > v2 (From Manasi):
> > > > > * Rebase Gaurav's patch from intel-gfx to gfx-internal
> > > > > * Use struct drm_dsc_cfg instead of struct intel_dp
> > > > > as a parameter
> > > > > 
> > > > > Cc: Manasi Navare 
> > > > > Cc: Jani Nikula 
> > > > > Cc: Ville Syrjala 
> > > > > Signed-off-by: Gaurav K Singh 
> > > > > Signed-off-by: Manasi Navare 
> > > > > Reviewed-by: Anusha Srivatsa 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_vdsc.c | 127 
> > > > > ++
> > > > >  1 file changed, 127 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > > > > b/drivers/gpu/drm/i915/intel_vdsc.c
> > > > > index 0a1918f2f643..a76f78b9c0ee 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > > > > @@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8 
> > > > > bits_per_component)
> > > > >   }
> > > > >  }
> > > > >  
> > > > > +static int intel_compute_rc_parameters(struct drm_dsc_config 
> > > > > *vdsc_cfg)
> > > > > +{
> > > > > + unsigned long groups_per_line = 0;
> > > > > + unsigned long groups_total = 0;
> > > > > + unsigned long num_extra_mux_bits = 0;
> > > > > + unsigned long slice_bits = 0;
> > > > > + unsigned long hrd_delay = 0;
> > > > > + unsigned long final_scale = 0;
> > > > > + unsigned long rbs_min = 0;
> > > > > +
> > > > > + /* Number of groups used to code each line of a slice */
> > > > > + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> > > > > +DSC_RC_PIXELS_PER_GROUP);
> > > > > +
> > > > > + /* chunksize in Bytes */
> > > > > + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> > > > > *
> > > > > +   
> > > > > vdsc_cfg->bits_per_pixel,
> > > > > +   (8 * 16));
> > > > > +
> > > > > + if (vdsc_cfg->convert_rgb)
> > > > > + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> > > > > +   (4 * 
> > > > > vdsc_cfg->bits_per_component + 4)
> > > > > +   - 2);
> > > > > + else
> > > > > + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> > > > > + (4 * vdsc_cfg->bits_per_component + 4) +
> > > > > + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> > > > > + /* Number of bits in one Slice */
> > > > > + slice_bits = 8 * vdsc_cfg->slice_chunk_size * 
> > > > > vdsc_cfg->slice_height;
> > > > > +
> > > > > + while ((num_extra_mux_bits > 0) &&
> > > > > +((slice_bits - num_extra_mux_bits) % 
> > > > > vdsc_cfg->mux_word_size))
> > > > > + num_extra_mux_bits--;
> > > > > +
> > > > > + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> > > > > + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> > > > > +
> > > > > + /* scale_decrement_interval calculation according to DSC spec 
> > > > > 1.11 */
> > > > > + if (vdsc_cfg->initial_scale_value > 8)
> > > > > + vdsc_cfg->scale_decrement_interval = groups_per_line /
> > > > > + (vdsc_cfg->initial_scale_value - 8);
> > > > > + else
> > > > > + vdsc_cfg->scale_decrement_interval = 
> > > > > DSC_SCALE_DECREMENT_INTERVAL_MAX;
> > > > > +
> > > > > + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> > > > > + (vdsc_cfg->initial_xmit_delay *
> > > > > +  vdsc_cfg->bits_per_pixel + 8) / 16 + 
> > > > > num_extra_mux_bits;
> > > > > +
> > > 

[PATCH v6 1/5] drm: Add vrr_capable property to the drm connector

2018-11-06 Thread Nicholas Kazlauskas
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces the "vrr_capable" property on the connector to
allow userspace to query support for variable refresh rates.

Atomic drivers should attach this property to connectors that are
capable of driving variable refresh rates using
drm_connector_attach_vrr_capable_property().

The value should be updated based on driver and hardware capabiltiy
by using drm_connector_set_vrr_capable_property().

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Manasi Navare 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/drm_connector.c | 49 +
 include/drm/drm_connector.h | 15 ++
 2 files changed, 64 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4943cef178be..49290060ab7b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1255,6 +1255,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_connector_attach_vrr_capable_property - creates the
+ * vrr_capable property
+ * @connector: connector to create the vrr_capable property on.
+ *
+ * This is used by atomic drivers to add support for querying
+ * variable refresh rate capability for a connector.
+ *
+ * Returns:
+ * Zero on success, negative errono on failure.
+ */
+int drm_connector_attach_vrr_capable_property(
+   struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_property *prop;
+
+   if (!connector->vrr_capable_property) {
+   prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE,
+   "vrr_capable");
+   if (!prop)
+   return -ENOMEM;
+
+   connector->vrr_capable_property = prop;
+   drm_object_attach_property(>base, prop, 0);
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_vrr_capable_property);
+
 /**
  * drm_connector_attach_scaling_mode_property - attach atomic scaling mode 
property
  * @connector: connector to attach scaling mode property on.
@@ -1583,6 +1614,24 @@ void drm_connector_set_link_status_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_set_link_status_property);
 
+/**
+ * drm_connector_set_vrr_capable_property - sets the variable refresh rate
+ * capable property for a connector
+ * @connector: drm connector
+ * @capable: True if the connector is variable refresh rate capable
+ *
+ * Should be used by atomic drivers to update the indicated support for
+ * variable refresh rate over a connector.
+ */
+void drm_connector_set_vrr_capable_property(
+   struct drm_connector *connector, bool capable)
+{
+   drm_object_property_set_value(>base,
+ connector->vrr_capable_property,
+ capable);
+}
+EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
+
 /**
  * drm_connector_init_panel_orientation_property -
  * initialize the connecters panel_orientation property
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 9ccad6b062f2..4e6befff153b 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -959,6 +959,17 @@ struct drm_connector {
 */
struct drm_property *scaling_mode_property;
 
+   /**
+* @vrr_capable_property: Optional property to help userspace
+* query hardware support for variable refresh rate on a connector.
+* connector. Drivers can add the property to a connector by
+* calling drm_connector_attach_vrr_capable_property().
+*
+* This should be updated only by calling
+* drm_connector_set_vrr_capable_property().
+*/
+   struct drm_property *vrr_capable_property;
+
/**
 * @content_protection_property: DRM ENUM property for content
 * protection. See drm_connector_attach_content_protection_property().
@@ -1250,6 +1261,8 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev);
 int drm_connector_attach_content_type_property(struct drm_connector *dev);
 int drm_connector_attach_scaling_mode_property(struct drm_connector *connector,
   u32 scaling_mode_mask);
+int drm_connector_attach_vrr_capable_property(
+   struct drm_connector *connector);
 int drm_connector_attach_content_protection_property(
struct drm_connector *connector);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
@@ -1266,6 +1279,8 @@ int drm_connector_update_edid_property(struct 
drm_connector *connector,
   const struct edid *edid);
 void drm_connector_set_link_status_property(struct drm_connector *connector,
uint64_t link_status);
+void 

[PATCH v6 5/5] drm/amdgpu: Set FreeSync state using drm VRR properties

2018-11-06 Thread Nicholas Kazlauskas
Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.

The notify_freesync and set_freesync_property functions are dropped
from amdgpu_display_funcs.

The drm vrr_capable property is now attached to any DP/HDMI connector.
Its value is updated accordingly to the connector's FreeSync capabiltiy.

The freesync_enable logic and ioctl control has has been dropped in
favor of utilizing the vrr_enabled on the drm CRTC. This allows for more
fine grained atomic control over which CRTCs should support variable
refresh rate.

To handle state changes for vrr_enabled it was easiest to drop the
forced modeset on freesync_enabled change. This patch now performs the
required stream updates when planes are flipped.

This is done for a few reasons:

(1) VRR stream updates can be done in the fast update path

(2) amdgpu_dm_atomic_check would need to be hacked apart to check
desired variable refresh state and capability before the CRTC
disable pass.

(3) Performing VRR stream updates on-flip is needed for enabling BTR
support.

VRR packets and timing adjustments are now tracked and compared to
previous values sent to the hardware.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Harry Wentland 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |   7 -
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 255 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |   7 +-
 3 files changed, 138 insertions(+), 131 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index b9e9e8b02fb7..0cbe867ec375 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -295,13 +295,6 @@ struct amdgpu_display_funcs {
  uint16_t connector_object_id,
  struct amdgpu_hpd *hpd,
  struct amdgpu_router *router);
-   /* it is used to enter or exit into free sync mode */
-   int (*notify_freesync)(struct drm_device *dev, void *data,
-  struct drm_file *filp);
-   /* it is used to allow enablement of freesync mode */
-   int (*set_freesync_property)(struct drm_connector *connector,
-struct drm_property *property,
-uint64_t val);
 
 
 };
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index b0df6dc9a775..53eb3d16f75c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -1809,72 +1809,6 @@ static void dm_bandwidth_update(struct amdgpu_device 
*adev)
/* TODO: implement later */
 }
 
-static int amdgpu_notify_freesync(struct drm_device *dev, void *data,
-   struct drm_file *filp)
-{
-   struct drm_atomic_state *state;
-   struct drm_modeset_acquire_ctx ctx;
-   struct drm_crtc *crtc;
-   struct drm_connector *connector;
-   struct drm_connector_state *old_con_state, *new_con_state;
-   int ret = 0;
-   uint8_t i;
-   bool enable = false;
-
-   drm_modeset_acquire_init(, 0);
-
-   state = drm_atomic_state_alloc(dev);
-   if (!state) {
-   ret = -ENOMEM;
-   goto out;
-   }
-   state->acquire_ctx = 
-
-retry:
-   drm_for_each_crtc(crtc, dev) {
-   ret = drm_atomic_add_affected_connectors(state, crtc);
-   if (ret)
-   goto fail;
-
-   /* TODO rework amdgpu_dm_commit_planes so we don't need this */
-   ret = drm_atomic_add_affected_planes(state, crtc);
-   if (ret)
-   goto fail;
-   }
-
-   for_each_oldnew_connector_in_state(state, connector, old_con_state, 
new_con_state, i) {
-   struct dm_connector_state *dm_new_con_state = 
to_dm_connector_state(new_con_state);
-   struct drm_crtc_state *new_crtc_state;
-   struct amdgpu_crtc *acrtc = 
to_amdgpu_crtc(dm_new_con_state->base.crtc);
-   struct dm_crtc_state *dm_new_crtc_state;
-
-   if (!acrtc) {
-   ASSERT(0);
-   continue;
-   }
-
-   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
>base);
-   dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
-
-   dm_new_crtc_state->freesync_enabled = enable;
-   }
-
-   ret = drm_atomic_commit(state);
-
-fail:
-   if (ret == -EDEADLK) {
-   drm_atomic_state_clear(state);
-   drm_modeset_backoff();
-   goto retry;
-   }
-
-   drm_atomic_state_put(state);
-
-out:
-   drm_modeset_drop_locks();
-   drm_modeset_acquire_fini();
-   return ret;
-}
 
 static const struct 

[PATCH v6 4/5] drm/amdgpu: Correct get_crtc_scanoutpos behavior when vpos >= vtotal

2018-11-06 Thread Nicholas Kazlauskas
When variable refresh rate is active the hardware counter can return
a position >= vtotal. This results in a vpos being returned from
amdgpu_display_get_crtc_scanoutpos that's a positive value. The
positive value indicates to the caller that the display is
currently in scanout when the display is actually still in vblank.

This is because the vfront porch duration is unknown with variable
refresh active and will end when either a page flip occurs or the
timeout specified by the driver/display is reached.

The behavior of the amdgpu_display_get_crtc_scanoutpos remains the
same when the position is below vtotal. When the position is above
vtotal the function will return a value that is effectively -vbl_end,
the size of the vback porch.

The only caller affected by this change is the DRM helper for
calculating vblank timestamps. This change corrects behavior for
calculating the page flip timestap from being the previous timestamp
to the calculation to the next timestamp when position >= vtotal.

Signed-off-by: Nicholas Kazlauskas 
Cc: Michel Dänzer 
Cc: Harry Wentland 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 6748cd7fc129..cb331319f225 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -850,7 +850,12 @@ int amdgpu_display_get_crtc_scanoutpos(struct drm_device 
*dev,
/* Inside "upper part" of vblank area? Apply corrective offset if so: */
if (in_vbl && (*vpos >= vbl_start)) {
vtotal = mode->crtc_vtotal;
-   *vpos = *vpos - vtotal;
+
+   /* With variable refresh rate displays the vpos can exceed
+* the vtotal value. Clamp to 0 to return -vbl_end instead
+* of guessing the remaining number of lines until scanout.
+*/
+   *vpos = (*vpos < vtotal) ? (*vpos - vtotal) : 0;
}
 
/* Correct for shifted end of vbl at vbl_end. */
-- 
2.19.1

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


[PATCH v6 3/5] drm: Document variable refresh properties

2018-11-06 Thread Nicholas Kazlauskas
These include the drm_connector 'vrr_capable' and the drm_crtc
'vrr_enabled' properties.

Signed-off-by: Nicholas Kazlauskas 
Cc: Harry Wentland 
Cc: Manasi Navare 
Cc: Pekka Paalanen 
Cc: Ville Syrjälä 
Cc: Michel Dänzer 
---
 Documentation/gpu/drm-kms.rst   |  7 
 drivers/gpu/drm/drm_connector.c | 61 +
 2 files changed, 68 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 4b1501b4835b..8da2a178cf85 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -575,6 +575,13 @@ Explicit Fencing Properties
 .. kernel-doc:: drivers/gpu/drm/drm_atomic_uapi.c
:doc: explicit fencing properties
 
+
+Variable Refresh Properties
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: Variable refresh properties
+
 Existing KMS Properties
 ---
 
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 49290060ab7b..a6adf5450db3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1255,6 +1255,67 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * DOC: Variable refresh properties
+ *
+ * Variable refresh rate capable displays can dynamically adjust their
+ * refresh rate by extending the duration of their vertical porch until
+ * page flip or timeout occurs. This can reduce or remove stuttering
+ * and latency in scenarios where the page flip does not align with the
+ * vblank interval.
+ *
+ * An example scenario would be an application flipping at a constant rate
+ * of 48Hz on a 60Hz display. The page flip will frequently miss the vblank
+ * interval and the same contents will be displayed twice. This can be
+ * observed as stuttering for content with motion.
+ *
+ * If variable refresh rate was active on a display that supported a
+ * variable refresh range from 35Hz to 60Hz no stuttering would be observable
+ * for the example scenario. The minimum supported variable refresh rate of
+ * 35Hz is below the page flip frequency and the vertical front porch can
+ * be extended until the page flip occurs. The vblank interval will be
+ * directly aligned to the page flip rate.
+ *
+ * Userspace control for variable refresh rate is supported via properties
+ * on the _connector and _crtc objects.
+ *
+ * "vrr_capable":
+ * Optional _connector boolean property that drivers should attach
+ * with drm_connector_attach_vrr_capable_property() on connectors that
+ * could support variable refresh rates. Drivers should update the
+ * property value by calling drm_connector_set_vrr_capable_property().
+ *
+ * Absence of the property should indicate absence of support.
+ *
+ * "vrr_enabled":
+ * Default _crtc boolean property that notifies the driver that the
+ * content on the CRTC is suitable for variable refresh rate presentation.
+ * The driver will take this property as a hint to enable variable
+ * refresh rate support if the receiver supports it, ie. if the
+ * "vrr_capable" property is true on the _connector object. The
+ * veritcal front porch duration will be extended until page-flip or
+ * timeout when enabled.
+ *
+ * The minimum vertical front porch duration is defined as the vertical
+ * front porch duration for the current mode.
+ *
+ * The maximum vertical front porch duration is greater than or equal to
+ * the minimum vertical front porch duration. The duration is derived
+ * from the minimum supported variable refresh rate for the connector.
+ *
+ * The driver may place further restrictions within these minimum
+ * and maximum bounds.
+ *
+ * Some displays may exhibit noticeable differences in brightness when
+ * varying vertical front porch duration.
+ *
+ * The semantics for the vertical blank timestamp differ when
+ * variable refresh rate is active. The vertical blank timestamp
+ * is defined to be an estimate using the current mode's fixed
+ * refresh rate timings. The semantics for the page-flip event
+ * timestamp remain the same.
+ */
+
 /**
  * drm_connector_attach_vrr_capable_property - creates the
  * vrr_capable property
-- 
2.19.1

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


[PATCH v6 2/5] drm: Add vrr_enabled property to drm CRTC

2018-11-06 Thread Nicholas Kazlauskas
This patch introduces the 'vrr_enabled' CRTC property to allow
dynamic control over variable refresh rate support for a CRTC.

This property should be treated like a content hint to the driver -
if the hardware or driver is not capable of driving variable refresh
timings then this is not considered an error.

Capability for variable refresh rate support should be determined
by querying the vrr_capable drm connector property.

It is worth noting that while the property is intended for atomic use
it isn't filtered from legacy userspace queries. This allows for Xorg
userspace drivers to implement support.

Signed-off-by: Nicholas Kazlauskas 
Reviewed-by: Harry Wentland 
Cc: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_uapi.c | 4 
 drivers/gpu/drm/drm_crtc.c| 2 ++
 drivers/gpu/drm/drm_mode_config.c | 6 ++
 include/drm/drm_crtc.h| 9 +
 include/drm/drm_mode_config.h | 5 +
 5 files changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..eec396a57b88 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -433,6 +433,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc 
*crtc,
ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
drm_property_blob_put(mode);
return ret;
+   } else if (property == config->prop_vrr_enabled) {
+   state->vrr_enabled = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -491,6 +493,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = state->active;
else if (property == config->prop_mode_id)
*val = (state->mode_blob) ? state->mode_blob->base.id : 0;
+   else if (property == config->prop_vrr_enabled)
+   *val = state->vrr_enabled;
else if (property == config->degamma_lut_property)
*val = (state->degamma_lut) ? state->degamma_lut->base.id : 0;
else if (property == config->ctm_property)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 268a182ae189..6f8ddfcfaba5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -340,6 +340,8 @@ int drm_crtc_init_with_planes(struct drm_device *dev, 
struct drm_crtc *crtc,
drm_object_attach_property(>base, config->prop_mode_id, 
0);
drm_object_attach_property(>base,
   config->prop_out_fence_ptr, 0);
+   drm_object_attach_property(>base,
+  config->prop_vrr_enabled, 0);
}
 
return 0;
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..5670c67f28d4 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -310,6 +310,12 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.prop_mode_id = prop;
 
+   prop = drm_property_create_bool(dev, 0,
+   "VRR_ENABLED");
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.prop_vrr_enabled = prop;
+
prop = drm_property_create(dev,
DRM_MODE_PROP_BLOB,
"DEGAMMA_LUT", 0);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index b21437bc95bf..39c3900aab3c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -290,6 +290,15 @@ struct drm_crtc_state {
 */
u32 pageflip_flags;
 
+   /**
+* @vrr_enabled:
+*
+* Indicates if variable refresh rate should be enabled for the CRTC.
+* Support for the requested vrr state will depend on driver and
+* hardware capabiltiy - lacking support is not treated as failure.
+*/
+   bool vrr_enabled;
+
/**
 * @event:
 *
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..49f2fcfdb5fc 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -639,6 +639,11 @@ struct drm_mode_config {
 * connectors must be of and active must be set to disabled, too.
 */
struct drm_property *prop_mode_id;
+   /**
+* @prop_vrr_enabled: Default atomic CRTC property to indicate
+* whether variable refresh rate should be enabled on the CRTC.
+*/
+   struct drm_property *prop_vrr_enabled;
 
/**
 * @dvi_i_subconnector_property: Optional DVI-I property to
-- 
2.19.1

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


[PATCH v6 0/5] A DRM API for adaptive sync and variable refresh rate support

2018-11-06 Thread Nicholas Kazlauskas
These patches are part of a proposed new interface for supporting variable 
refresh rate via DRM properties.

=== Changes from v5 ===

drm changes:

* Updated documentation to define userspace expectations when variable refresh 
rate is enabled

amd changes:

* Added patch to fix vblank timestamp calculations when vpos > vtotal

=== Changes from v4 ===

amd changes:

* Removed unused FreeSync functions from amdgpu

=== Changes from v3 ===

drm changes:

* Docstring and formatting fixes

amd/display changes:

* Updated commit message and debug statements

=== Changes from v2 ===

The interface has changed substantially from the last revision and the cover 
letter has been updated accordingly.

drm changes:

* Most "variable_refresh" prefixes in code have been shortened to just "vrr". 
This was motivated after changes to the interface had function names close to 
80 characters long. Comments from the mailing list were already shortening 
these in discussion as well.
* Documentation for "Variable Refresh" has been added to the KMS properties 
subsection for DRM driver developers.
* The drm_connector property "variable_refresh_capable" has been renamed to 
"vrr_capable".
* The drm_crtc property "variable_refresh" has been been renamed "vrr_enabled" 
to better reflect its usage.
* The drm_connector "variable_refresh_enabled" property has been removed. 
Managing this is now up to userspace when it sets "vrr_enabled".
* The "vrr_capable" property no longer has any state in drm_connector_state 
associated with it. The value can now be updated with the 
drm_connector_set_vrr_capable_property() function. This better matches the 
immutable flag on the property.
* The "variable_refresh_changed" flag has been removed from atomic helpers 
based on feedback from the mailing list and updated interface usage in the amd 
kernel driver.

amd/display changes:

* Updated interface usage based on the new properties
* Updated VRR infopacket handling based on new xf86-video-amdgpu usage

=== Adaptive sync and variable refresh rate ===

Adaptive sync is part of the DisplayPort specification and allows for graphics 
adapters to drive displays with varying frame timings.

Variable refresh rate (VRR) is essentially the same, but defined for HDMI.

=== Use cases for variable refresh rate ===

Variable frame (flip) timings don't align well with fixed refresh rate 
displays. This results in stuttering, tearing and/or input lag. By adjusting 
the display refresh rate dynamically these issues can be reduced or eliminated.

However, not all content is suitable for dynamic refresh adaptation. The user 
may experience "flickering" from differences in panel luminance at different 
refresh rates. Content that flips at an infrequent rate or demand is more 
likely to cause large changes in refresh rate that result in flickering.

Userland needs a way to let the driver know when the screen content is suitable 
for variable refresh rates.

=== DRM API to support variable refresh rates ===

This patch introduces a new API via atomic properties on the DRM connector and 
CRTC.

The drm_connector has one new optional boolean property:

* bool vrr_capable - set by the driver if the hardware is capable of supporting 
variable refresh rates

The drm_crtc has one new default boolean property:

* bool vrr_enabled - set by userspace indicating that variable refresh rate 
should be enabled

== Overview for DRM driver developers ===

Driver developers can attach the "vrr_capable" property by calling 
drm_connector_attach_vrr_capable_property(). This should be done on connectors 
that could be capable of supporting variable refresh rates (such as DP or HDMI).

The "vrr_capable" can then be updated accordingly by calling 
drm_connector_set_vrr_capable_property().

The "vrr_enabled" property can be checked from the drm_crtc_state object.

=== Overview for Userland developers ==

The "vrr_enabled" property on the CRTC should be set to true when the CRTC is 
suitable for variable refresh rates.

To demonstrate the suitability of the API for variable refresh and dynamic 
adaptation there are additional patches using this API that implement adaptive 
variable refresh across kernel and userland projects:

* DRM (dri-devel)
* amdgpu DRM kernel driver (amd-gfx)
* xf86-video-amdgpu 
(https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu)
* mesa (mesa-dev)

These patches enable adaptive variable refresh on X for AMD hardware. Support 
for variable refresh is disabled by default in xf86-video-amdgpu and will 
require additional user configuration.

The patches have been tested as working on upstream userland with the GNOME 
desktop environment under a single monitor setup. They also work on KDE in a 
single monitor setup with the compositor disabled.

The patches require that suitable applications flip via the Present extension 
to xf86-video-amdgpu for the entire Screen. Some compositors may interfere with 
this if they are unable to unredirect the window.

Full 

Re: [PATCH] drm/framebuffer: Expose only modifiers that support at least a format

2018-11-06 Thread Ville Syrjälä
On Tue, Nov 06, 2018 at 11:54:45AM -0800, Dhinakaran Pandiyan wrote:
> On Tue, 2018-11-06 at 16:13 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 05, 2018 at 06:44:34PM -0800, Dhinakaran Pandiyan wrote:
> > > Allows drivers to pass a larger modifier array, thereby avoiding
> > > declarations of static modifier arrays that are only slight
> > > different
> > > for each plane.
> > > 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Ville Syrjälä 
> > > Suggested-by: Ville Syrjälä 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/drm_plane.c | 35 +++
> > > 
> > >  1 file changed, 27 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_plane.c
> > > b/drivers/gpu/drm/drm_plane.c
> > > index 1fa98bd12003..1546ffbf8e36 100644
> > > --- a/drivers/gpu/drm/drm_plane.c
> > > +++ b/drivers/gpu/drm/drm_plane.c
> > > @@ -179,8 +179,8 @@ int drm_universal_plane_init(struct drm_device
> > > *dev, struct drm_plane *plane,
> > >const char *name, ...)
> > >  {
> > >   struct drm_mode_config *config = >mode_config;
> > > - unsigned int format_modifier_count = 0;
> > > - int ret;
> > > + unsigned int format_modifier_count, in_modifier_count = 0;
> > > + int ret, i;
> > >  
> > >   /* plane index is used with 32bit bitmasks */
> > >   if (WARN_ON(config->num_total_plane >= 32))
> > > @@ -216,22 +216,43 @@ int drm_universal_plane_init(struct
> > > drm_device *dev, struct drm_plane *plane,
> > >  
> > >   if (format_modifiers) {
> > >   const uint64_t *temp_modifiers = format_modifiers;
> > > +
> > >   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> > > - format_modifier_count++;
> > > + in_modifier_count++;
> > >   }
> > >  
> > > - plane->modifier_count = format_modifier_count;
> > > - plane->modifiers = kmalloc_array(format_modifier_count,
> > > + plane->modifiers = kmalloc_array(in_modifier_count,
> > >sizeof(format_modifiers[0]),
> > >GFP_KERNEL);
> > >  
> > > - if (format_modifier_count && !plane->modifiers) {
> > > + if (in_modifier_count && !plane->modifiers) {
> > >   DRM_DEBUG_KMS("out of memory when allocating plane\n");
> > >   kfree(plane->format_types);
> > >   drm_mode_object_unregister(dev, >base);
> > >   return -ENOMEM;
> > >   }
> > >  
> > > + for (i = 0, format_modifier_count = 0; i < in_modifier_count;
> > > i++) {
> > > + int j;
> > > +
> > > + for (j = 0; funcs->format_mod_supported && j <
> > > format_count; j++)
> > > + if (funcs->format_mod_supported(plane,
> > > formats[j],
> > > + format_modifier
> > > s[i]))
> > > + break;
> > > +
> > > + if (j < format_count)
> > > + plane->modifiers[format_modifier_count++] =
> > > + format_modifiers[i];
> > > + }
> > > +
> > > + if (format_modifier_count < in_modifier_count) {
> > > + size_t size;
> > > +
> > > + size = format_modifier_count *
> > > sizeof(format_modifiers[0]);
> > > + plane->modifiers = krealloc(plane->modifiers, size,
> > > GFP_KERNEL);
> > 
> > Should check that the realloc actually succeeded.
> Didn't see a failure path for new size smaller than old, the return is
> the same pointer passed to krealloc().

I don't know if we want to rely on an implementation detail that
hevily. But that does raise the interesting point that trying to
shrink our memory footprint with krealloc() is futile. I suppose
there is still some kind of debugging benefit from the kasan
stuff.

> 
> > 
> > And I think we might want to give this same treatment to plane-
> > >formats[]
> > as well.
> > 
> > And perhaps we could even throw out plane->modifiers[] and just rely
> > on
> > the IN_FORMATS blob exclusively? Hmm. Looks like that is not getting
> > fully
> > populated unless the driver has provided .format_mod_supported(). Not
> > sure why that is, and not sure what userspace is supposed to do with
> > a
> > partially filled blob like that. I'm thinking we shouldn't even
> > attach
> > the property to the plane in that case.
> 
> Shouldn't it copy the modifier array into the blob and mark all formats
> as supported? drm_plane_check_pixel_format() seems to allow any valid
> format for a modifier in this case.

Yeah, I guess that might be the better approach.

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH v8 04/19] drm/dsc: Add helpers for DSC picture parameter set infoframes

2018-11-06 Thread Manasi Navare
On Mon, Nov 05, 2018 at 05:38:19PM -0800, Srivatsa, Anusha wrote:
> 
> 
> >-Original Message-
> >From: Navare, Manasi D
> >Sent: Friday, November 2, 2018 2:31 PM
> >To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> >Cc: Navare, Manasi D ; Jani Nikula
> >; Ville Syrjala ;
> >Srivatsa, Anusha ; Harry Wentland
> >
> >Subject: [PATCH v8 04/19] drm/dsc: Add helpers for DSC picture parameter set
> >infoframes
> >
> >According to Display Stream compression spec 1.2, the picture parameter set
> >metadata is sent from source to sink device using the DP Secondary data 
> >packet.
> >An infoframe is formed for the PPS SDP header and PPS SDP payload bytes.
> >This patch adds helpers to fill the PPS SDP header and PPS SDP payload 
> >according
> >to the DSC 1.2 specification.
> >
> >v7:
> >* Use BUILD_BUG_ON() to protect changing struct size (Ville)
> >* Remove typecaseting (Ville)
> >* Include byteorder.h in drm_dsc.c (Ville)
> >v6:
> >* Use proper sequence points for breaking down the assignments (Chris Wilson)
> >* Use SPDX identifier
> >v5:
> >Do not use bitfields for DRM structs (Jani N)
> >v4:
> >* Use DSC constants for params that dont change across configurations
> >v3:
> >* Add reference to added kernel-docs in
> >Documentation/gpu/drm-kms-helpers.rst (Daniel Vetter)
> >
> >v2:
> >* Add EXPORT_SYMBOL for the drm functions (Manasi)
> >
> >Cc: dri-devel@lists.freedesktop.org
> >Cc: Jani Nikula 
> >Cc: Ville Syrjala 
> >Cc: Anusha Srivatsa 
> >Cc: Harry Wentland 
> >Signed-off-by: Manasi Navare 
> >Acked-by: Harry Wentland 
> >---
> > Documentation/gpu/drm-kms-helpers.rst |  12 ++
> > drivers/gpu/drm/Makefile  |   2 +-
> > drivers/gpu/drm/drm_dsc.c | 228 ++
> > include/drm/drm_dsc.h |  21 +++
> > 4 files changed, 262 insertions(+), 1 deletion(-)  create mode 100644
> >drivers/gpu/drm/drm_dsc.c
> >
> >diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-
> >kms-helpers.rst
> >index 4b4dc236ef6f..b422eb8edf16 100644
> >--- a/Documentation/gpu/drm-kms-helpers.rst
> >+++ b/Documentation/gpu/drm-kms-helpers.rst
> >@@ -232,6 +232,18 @@ MIPI DSI Helper Functions Reference  .. kernel-doc::
> >drivers/gpu/drm/drm_mipi_dsi.c
> >:export:
> >
> >+Display Stream Compression Helper Functions Reference
> >+=
> >+
> >+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> >+   :doc: dsc helpers
> >+
> >+.. kernel-doc:: include/drm/drm_dsc.h
> >+   :internal:
> >+
> >+.. kernel-doc:: drivers/gpu/drm/drm_dsc.c
> >+   :export:
> >+
> > Output Probing Helper Functions Reference
> >=
> >
> >diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index
> >576ba985e138..3a3e6fb6d476 100644
> >--- a/drivers/gpu/drm/Makefile
> >+++ b/drivers/gpu/drm/Makefile
> >@@ -32,7 +32,7 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o
> > drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> > drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> >
> >-drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> >+drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o
> >+drm_probe_helper.o \
> > drm_plane_helper.o drm_dp_mst_topology.o
> >drm_atomic_helper.o \
> > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> > drm_simple_kms_helper.o drm_modeset_helper.o \ diff --git
> >a/drivers/gpu/drm/drm_dsc.c b/drivers/gpu/drm/drm_dsc.c new file mode
> >100644 index ..3a4942c1ae3b
> >--- /dev/null
> >+++ b/drivers/gpu/drm/drm_dsc.c
> >@@ -0,0 +1,228 @@
> >+// SPDX-License-Identifier: MIT
> 
> Nit-
> In some places the License is within /* */ like comment
> Is the right way to Add License Identifier?

Yes /*  */ was giving me checkpatch warning.

> 
> >+/*
> >+ * Copyright © 2018 Intel Corp
> >+ *
> >+ * Author:
> >+ * Manasi Navare   */
> >+
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+#include 
> >+
> >+/**
> >+ * DOC: dsc helpers
> >+ *
> >+ * These functions contain some common logic and helpers to deal with
> >+VESA
> >+ * Display Stream Compression standard required for DSC on Display
> >+Port/eDP or
> >+ * MIPI display interfaces.
> >+ */
> >+
> >+/**
> >+ * drm_dsc_dp_pps_header_init() - Initializes the PPS Header
> >+ * for DisplayPort as per the DP 1.4 spec.
> >+ * @pps_sdp: Secondary data packet for DSC Picture Parameter Set  */
> >+void drm_dsc_dp_pps_header_init(struct drm_dsc_pps_infoframe *pps_sdp)
> >+{
> >+memset(_sdp->pps_header, 0, sizeof(pps_sdp->pps_header));
> >+
> >+pps_sdp->pps_header.HB1 = DP_SDP_PPS;
> >+pps_sdp->pps_header.HB2 =
> >DP_SDP_PPS_HEADER_PAYLOAD_BYTES_MINUS_1;
> >+}
> >+EXPORT_SYMBOL(drm_dsc_dp_pps_header_init);
> >+
> >+/**
> >+ * drm_dsc_pps_infoframe_pack() - Populates the DSC PPS infoframe
> >+ * using the DSC configuration parameters in the order expected
> >+ * by the 

Re: [PATCH v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 07:00:50PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 06, 2018 at 08:52:41AM -0800, Manasi Navare wrote:
> > On Tue, Nov 06, 2018 at 04:33:38PM +0200, Ville Syrjälä wrote:
> > > On Fri, Nov 02, 2018 at 02:31:29PM -0700, Manasi Navare wrote:
> > > > From: Gaurav K Singh 
> > > > 
> > > > This computation of RC params happens in the atomic commit phase
> > > > during compute_config() to validate if display stream compression
> > > > can be enabled for the requested mode.
> > > > 
> > > > v7 (From Manasi):
> > > > * Use DRM_DEBUG instead of DRM_ERROR (Ville)
> > > > * Use Error numberinstead of -1 (Ville)
> > > > v6 (From Manasi):
> > > > * Use 9 instead of 0x9 for consistency (Anusha)
> > > > 
> > > > v5 (From Manasi):
> > > > * Fix dim checkpatch warnings/checks
> > > > v4(From Gaurav):
> > > > * No change.Rebase on drm-tip
> > > > 
> > > > v3 (From Gaurav):
> > > > * Rebase on top of Manasi's latest series
> > > > * Return -ve value in case of failure scenarios (Manasi)
> > > > 
> > > > Fix review comments from Ville:
> > > > * Remove unnecessary comments
> > > > * Remove unnecessary paranthesis
> > > > * Add comments for few RC params calculations
> > > > 
> > > > v2 (From Manasi):
> > > > * Rebase Gaurav's patch from intel-gfx to gfx-internal
> > > > * Use struct drm_dsc_cfg instead of struct intel_dp
> > > > as a parameter
> > > > 
> > > > Cc: Manasi Navare 
> > > > Cc: Jani Nikula 
> > > > Cc: Ville Syrjala 
> > > > Signed-off-by: Gaurav K Singh 
> > > > Signed-off-by: Manasi Navare 
> > > > Reviewed-by: Anusha Srivatsa 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_vdsc.c | 127 ++
> > > >  1 file changed, 127 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > > > b/drivers/gpu/drm/i915/intel_vdsc.c
> > > > index 0a1918f2f643..a76f78b9c0ee 100644
> > > > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > > > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > > > @@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8 
> > > > bits_per_component)
> > > > }
> > > >  }
> > > >  
> > > > +static int intel_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> > > > +{
> > > > +   unsigned long groups_per_line = 0;
> > > > +   unsigned long groups_total = 0;
> > > > +   unsigned long num_extra_mux_bits = 0;
> > > > +   unsigned long slice_bits = 0;
> > > > +   unsigned long hrd_delay = 0;
> > > > +   unsigned long final_scale = 0;
> > > > +   unsigned long rbs_min = 0;
> > > > +
> > > > +   /* Number of groups used to code each line of a slice */
> > > > +   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> > > > +  DSC_RC_PIXELS_PER_GROUP);
> > > > +
> > > > +   /* chunksize in Bytes */
> > > > +   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width 
> > > > *
> > > > + 
> > > > vdsc_cfg->bits_per_pixel,
> > > > + (8 * 16));
> > > > +
> > > > +   if (vdsc_cfg->convert_rgb)
> > > > +   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> > > > + (4 * 
> > > > vdsc_cfg->bits_per_component + 4)
> > > > + - 2);
> > > > +   else
> > > > +   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> > > > +   (4 * vdsc_cfg->bits_per_component + 4) +
> > > > +   2 * (4 * vdsc_cfg->bits_per_component) - 2;
> > > > +   /* Number of bits in one Slice */
> > > > +   slice_bits = 8 * vdsc_cfg->slice_chunk_size * 
> > > > vdsc_cfg->slice_height;
> > > > +
> > > > +   while ((num_extra_mux_bits > 0) &&
> > > > +  ((slice_bits - num_extra_mux_bits) % 
> > > > vdsc_cfg->mux_word_size))
> > > > +   num_extra_mux_bits--;
> > > > +
> > > > +   if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> > > > +   vdsc_cfg->initial_scale_value = groups_per_line + 8;
> > > > +
> > > > +   /* scale_decrement_interval calculation according to DSC spec 
> > > > 1.11 */
> > > > +   if (vdsc_cfg->initial_scale_value > 8)
> > > > +   vdsc_cfg->scale_decrement_interval = groups_per_line /
> > > > +   (vdsc_cfg->initial_scale_value - 8);
> > > > +   else
> > > > +   vdsc_cfg->scale_decrement_interval = 
> > > > DSC_SCALE_DECREMENT_INTERVAL_MAX;
> > > > +
> > > > +   vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> > > > +   (vdsc_cfg->initial_xmit_delay *
> > > > +vdsc_cfg->bits_per_pixel + 8) / 16 + 
> > > > num_extra_mux_bits;
> > > > +
> > > > +   if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> > > > +   DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> > > > InitialXmitDelay\n");
> > > > +   return -EINVAL;
> > > > +   }
> > 

linux-next: Signed-off-by missing for commit in the drm-intel tree

2018-11-06 Thread Stephen Rothwell
Hi all,

Commit

  35b876db4a42 ("drm/i915/dsc: Add slice_row_per_frame in DSC PPS programming")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell


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


Re: [PATCH] drm/framebuffer: Expose only modifiers that support at least a format

2018-11-06 Thread Dhinakaran Pandiyan
On Tue, 2018-11-06 at 16:13 +0200, Ville Syrjälä wrote:
> On Mon, Nov 05, 2018 at 06:44:34PM -0800, Dhinakaran Pandiyan wrote:
> > Allows drivers to pass a larger modifier array, thereby avoiding
> > declarations of static modifier arrays that are only slight
> > different
> > for each plane.
> > 
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Ville Syrjälä 
> > Suggested-by: Ville Syrjälä 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_plane.c | 35 +++
> > 
> >  1 file changed, 27 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_plane.c
> > b/drivers/gpu/drm/drm_plane.c
> > index 1fa98bd12003..1546ffbf8e36 100644
> > --- a/drivers/gpu/drm/drm_plane.c
> > +++ b/drivers/gpu/drm/drm_plane.c
> > @@ -179,8 +179,8 @@ int drm_universal_plane_init(struct drm_device
> > *dev, struct drm_plane *plane,
> >  const char *name, ...)
> >  {
> > struct drm_mode_config *config = >mode_config;
> > -   unsigned int format_modifier_count = 0;
> > -   int ret;
> > +   unsigned int format_modifier_count, in_modifier_count = 0;
> > +   int ret, i;
> >  
> > /* plane index is used with 32bit bitmasks */
> > if (WARN_ON(config->num_total_plane >= 32))
> > @@ -216,22 +216,43 @@ int drm_universal_plane_init(struct
> > drm_device *dev, struct drm_plane *plane,
> >  
> > if (format_modifiers) {
> > const uint64_t *temp_modifiers = format_modifiers;
> > +
> > while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> > -   format_modifier_count++;
> > +   in_modifier_count++;
> > }
> >  
> > -   plane->modifier_count = format_modifier_count;
> > -   plane->modifiers = kmalloc_array(format_modifier_count,
> > +   plane->modifiers = kmalloc_array(in_modifier_count,
> >  sizeof(format_modifiers[0]),
> >  GFP_KERNEL);
> >  
> > -   if (format_modifier_count && !plane->modifiers) {
> > +   if (in_modifier_count && !plane->modifiers) {
> > DRM_DEBUG_KMS("out of memory when allocating plane\n");
> > kfree(plane->format_types);
> > drm_mode_object_unregister(dev, >base);
> > return -ENOMEM;
> > }
> >  
> > +   for (i = 0, format_modifier_count = 0; i < in_modifier_count;
> > i++) {
> > +   int j;
> > +
> > +   for (j = 0; funcs->format_mod_supported && j <
> > format_count; j++)
> > +   if (funcs->format_mod_supported(plane,
> > formats[j],
> > +   format_modifier
> > s[i]))
> > +   break;
> > +
> > +   if (j < format_count)
> > +   plane->modifiers[format_modifier_count++] =
> > +   format_modifiers[i];
> > +   }
> > +
> > +   if (format_modifier_count < in_modifier_count) {
> > +   size_t size;
> > +
> > +   size = format_modifier_count *
> > sizeof(format_modifiers[0]);
> > +   plane->modifiers = krealloc(plane->modifiers, size,
> > GFP_KERNEL);
> 
> Should check that the realloc actually succeeded.
Didn't see a failure path for new size smaller than old, the return is
the same pointer passed to krealloc().

> 
> And I think we might want to give this same treatment to plane-
> >formats[]
> as well.
> 
> And perhaps we could even throw out plane->modifiers[] and just rely
> on
> the IN_FORMATS blob exclusively? Hmm. Looks like that is not getting
> fully
> populated unless the driver has provided .format_mod_supported(). Not
> sure why that is, and not sure what userspace is supposed to do with
> a
> partially filled blob like that. I'm thinking we shouldn't even
> attach
> the property to the plane in that case.

Shouldn't it copy the modifier array into the blob and mark all formats
as supported? drm_plane_check_pixel_format() seems to allow any valid
format for a modifier in this case.


-DK

> 
> > +   }
> > +   plane->modifier_count = format_modifier_count;
> > +
> > if (name) {
> > va_list ap;
> >  
> > @@ -251,8 +272,6 @@ int drm_universal_plane_init(struct drm_device
> > *dev, struct drm_plane *plane,
> >  
> > memcpy(plane->format_types, formats, format_count *
> > sizeof(uint32_t));
> > plane->format_count = format_count;
> > -   memcpy(plane->modifiers, format_modifiers,
> > -  format_modifier_count * sizeof(format_modifiers[0]));
> > plane->possible_crtcs = possible_crtcs;
> > plane->type = type;
> >  
> > -- 
> > 2.14.1
> 
> 

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


[PATCH v2 3/3] drm/atomic: Use explicit old/new state in drm_atomic_plane_check()

2018-11-06 Thread Ville Syrjala
From: Ville Syrjälä 

Convert drm_atomic_plane_check() over to using explicit old vs. new
plane states. Avoids the confusion of "what does plane->state mean
again?".

v2: Stick to the multi-stage logic in plane_switching_crtc() (Daniel)

Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic.c | 85 +++-
 1 file changed, 46 insertions(+), 39 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3a4b6b251971..9ac26437051b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -497,14 +497,13 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
 EXPORT_SYMBOL(drm_atomic_get_plane_state);
 
 static bool
-plane_switching_crtc(struct drm_atomic_state *state,
-struct drm_plane *plane,
-struct drm_plane_state *plane_state)
+plane_switching_crtc(const struct drm_plane_state *old_plane_state,
+const struct drm_plane_state *new_plane_state)
 {
-   if (!plane->state->crtc || !plane_state->crtc)
+   if (!old_plane_state->crtc || !new_plane_state->crtc)
return false;
 
-   if (plane->state->crtc == plane_state->crtc)
+   if (old_plane_state->crtc == new_plane_state->crtc)
return false;
 
/* This could be refined, but currently there's no helper or driver code
@@ -517,88 +516,95 @@ plane_switching_crtc(struct drm_atomic_state *state,
 
 /**
  * drm_atomic_plane_check - check plane state
- * @plane: plane to check
- * @state: plane state to check
+ * @old_plane_state: old plane state to check
+ * @new_plane_state: new plane state to check
  *
  * Provides core sanity checks for plane state.
  *
  * RETURNS:
  * Zero on success, error code on failure
  */
-static int drm_atomic_plane_check(struct drm_plane *plane,
-   struct drm_plane_state *state)
+static int drm_atomic_plane_check(const struct drm_plane_state 
*old_plane_state,
+ const struct drm_plane_state *new_plane_state)
 {
+   struct drm_plane *plane = new_plane_state->plane;
+   struct drm_crtc *crtc = new_plane_state->crtc;
+   const struct drm_framebuffer *fb = new_plane_state->fb;
unsigned int fb_width, fb_height;
int ret;
 
/* either *both* CRTC and FB must be set, or neither */
-   if (state->crtc && !state->fb) {
+   if (crtc && !fb) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] CRTC set but no FB\n",
 plane->base.id, plane->name);
return -EINVAL;
-   } else if (state->fb && !state->crtc) {
+   } else if (fb && !crtc) {
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] FB set but no CRTC\n",
 plane->base.id, plane->name);
return -EINVAL;
}
 
/* if disabled, we don't care about the rest of the state: */
-   if (!state->crtc)
+   if (!crtc)
return 0;
 
/* Check whether this plane is usable on this CRTC */
-   if (!(plane->possible_crtcs & drm_crtc_mask(state->crtc))) {
+   if (!(plane->possible_crtcs & drm_crtc_mask(crtc))) {
DRM_DEBUG_ATOMIC("Invalid [CRTC:%d:%s] for [PLANE:%d:%s]\n",
-state->crtc->base.id, state->crtc->name,
+crtc->base.id, crtc->name,
 plane->base.id, plane->name);
return -EINVAL;
}
 
/* Check whether this plane supports the fb pixel format. */
-   ret = drm_plane_check_pixel_format(plane, state->fb->format->format,
-  state->fb->modifier);
+   ret = drm_plane_check_pixel_format(plane, fb->format->format,
+  fb->modifier);
if (ret) {
struct drm_format_name_buf format_name;
DRM_DEBUG_ATOMIC("[PLANE:%d:%s] invalid pixel format %s, 
modifier 0x%llx\n",
 plane->base.id, plane->name,
-drm_get_format_name(state->fb->format->format,
+drm_get_format_name(fb->format->format,
 _name),
-state->fb->modifier);
+fb->modifier);
return ret;
}
 
/* Give drivers some help against integer overflows */
-   if (state->crtc_w > INT_MAX ||
-   state->crtc_x > INT_MAX - (int32_t) state->crtc_w ||
-   state->crtc_h > INT_MAX ||
-   state->crtc_y > INT_MAX - (int32_t) state->crtc_h) {
+   if (new_plane_state->crtc_w > INT_MAX ||
+   new_plane_state->crtc_x > INT_MAX - (int32_t) 
new_plane_state->crtc_w ||
+   new_plane_state->crtc_h > INT_MAX ||
+   new_plane_state->crtc_y > INT_MAX - (int32_t) 

[Bug 107928] Screen regularly turns black, reboot needed

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=107928

--- Comment #15 from Vik-T  ---
Someone might find this helpful: I managed to reduce the number of driver
crashes considerably by disabling "suspend" and "off" mode in X. 

Section "ServerFlags"
Option "SuspendTime" "0"
Option "OffTime" "0"
EndSection

In the last 5-6 days, the driver crashed only once and I managed to bring X
back without rebooting. For me, that's a huge improvement over the situation
before where I had to reboot 2-3 times a day.

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


Re: [PATCH DRM] drm: msm: disp: dpu1: Use DRM_DEV_* instead of DPU_*

2018-11-06 Thread Sean Paul
On Sat, Oct 20, 2018 at 11:33:54PM +0530, Mamta Shukla wrote:
> Use DRM_DEV_ERROR/DEBUG instead of DPU_ERROR/DEBUG  to generate
> drm-formatted specific log messages in the Kernel log in case of
> multiple instances.
> 
> Signed-off-by: Mamta Shukla 

Hi Mamta,
Thanks for sending this patch, but I don't think it's going to even compile.
DRM_DEV_* takes a struct device * pointer as the first argument, and it's not
being passed in anywhere. Make sure you compile test with CONFIG_DRM_MSM enabled

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c   |  58 +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c  |  60 +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c   | 176 
> ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 134 
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c   |  40 ++---
>  .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c   |  42 ++---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c|  10 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c|   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c  |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c|   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c|   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c |   2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c|   4 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|  90 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c   |  10 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 134 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c |  96 +--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c   |  32 ++--
>  21 files changed, 451 insertions(+), 451 deletions(-)
> 

/snip

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


[Bug 108649] On Vega GPU Project CARS 2 Demo cause broke fonts in gnome-shell

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108649

--- Comment #3 from Hin-Tak Leung  ---
I think I may have a similar problem, though not as bad as the reporter's.
After upgrading to fedora 29 from fedora 28, I found a few gnome applications
are not working correctly. The symptom is that some text/graphics are missing
(not shown).

I first noticed it when the gnome weather extension's configure panel is not
showing the location list (I have two) - but selecting either of the two
entries work, so it is just text not showing.

The other application not working is a custom c# based wrapper around
webkit2gtk4. Some sites are not rendering at all: bugzilla.redhat works, but
google.com does not (nothing shows, but you can mouse over various places, and
actually type some text blindly to get a search - and some search result
quickly flashes by before it goes back to blank again- you can nonetheless
click on some links, and your mouse over shows it is on various things)

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


[Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu polaris11/rx460 only activates on one output/monitor of two

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=200645

--- Comment #15 from postmas...@amd.com ---
Delivery has failed to these recipients or groups:

mikita.lip...@amd.com
The e-mail address you entered couldn't be found. Please check the recipient's
e-mail address and try to resend the message. If the problem continues, please
contact your helpdesk.







Diagnostic information for administrators:

Generating server: amd.com

mikita.lip...@amd.com
#550 5.1.1 RESOLVER.ADR.RecipNotFound; not found ##rfc822;mikita.lip...@amd.com

Original message headers:

Received: from NAM03-BY2-obe.outbound.protection.outlook.com (216.32.180.55)
 by mail.amd.com (10.181.40.71) with Microsoft SMTP Server (TLS) id
 14.3.389.1; Tue, 6 Nov 2018 05:10:05 -0600
Received: from SN1PR12CA0074.namprd12.prod.outlook.com (2603:10b6:802:20::45)
 by BY1PR12MB0422.namprd12.prod.outlook.com (2a01:111:e400:51b2::11) with
 Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.21; Tue, 6 Nov
 2018 11:09:52 +
Received: from BY2NAM03FT061.eop-NAM03.prod.protection.outlook.com
 (2a01:111:f400:7e4a::204) by SN1PR12CA0074.outlook.office365.com
 (2603:10b6:802:20::45) with Microsoft SMTP Server (version=TLS1_2,
 cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.22 via Frontend
 Transport; Tue, 6 Nov 2018 11:09:51 +
Authentication-Results: spf=pass (sender IP is 198.145.29.98)
 smtp.mailfrom=bugzilla.kernel.org; amd.com; dkim=none (message not signed)
 header.d=none;amd.com; dmarc=pass action=none
 header.from=bugzilla.kernel.org;compauth=pass reason=100
Received-SPF: Pass (protection.outlook.com: domain of bugzilla.kernel.org
 designates 198.145.29.98 as permitted sender)
 receiver=protection.outlook.com; client-ip=198.145.29.98;
 helo=mail.wl.linuxfoundation.org;
Received: from mail.wl.linuxfoundation.org (198.145.29.98) by
 BY2NAM03FT061.mail.protection.outlook.com (10.152.85.107) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id
 15.20.1294.14 via Frontend Transport; Tue, 6 Nov 2018 11:09:50 +
Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1])  by
 mail.wl.linuxfoundation.org (Postfix) with ESMTP id 887442A2C3 for
 ; Tue,  6 Nov 2018 11:09:49 + (UTC)
Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id
 78B012A2BE; Tue,  6 Nov 2018 11:09:49 + (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
pdx-wl-mail.web.codeaurora.org
X-Spam-Level:
X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00,NO_RECEIVED,
NO_RELAYS autolearn=unavailable version=3.3.1
From: 
To: 
Subject: [Bug 200645] 4.18-rc regression bisected to e03fd3f30: amdgpu
 polaris11/rx460 only activates on one output/monitor of two
Date: Tue, 6 Nov 2018 11:09:48 +
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: Drivers
X-Bugzilla-Component: Video(DRI - non Intel)
X-Bugzilla-Version: 2.5
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: postmas...@amd.com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: drivers_video-...@kernel-bugs.osdl.org
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: 
In-Reply-To: 
References: 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: https://bugzilla.kernel.org/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-Virus-Scanned: ClamAV using ClamSMTP
Return-Path: bugzilla-dae...@bugzilla.kernel.org
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 3dd8961f-e488-4e60-8e11-a82d994e183d:0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report:
CIP:198.145.29.98;IPV:NLI;CTRY:US;EFV:NLI;SFV:NSPM;SFS:(8156002)(299032)(438002)(199004)(189003)(103686004)(26005)(356004)(50466002)(86152003)(6306002)(61793004)(9686003)(2351001)(16003)(8746002)(311042)(1096003)(42186006)(4744004)(90966002)(66574009)(246002)(6916009)(34756004)(106002)(106466001)(966005)(8676002)(33896004)(582011)(336012)(52956003)(575784001)(86362001)(1005)(2876002)(566031)(76176011)(4508042)(566174002)(23676004)(11346002)(7636002)(6266002)(47776003)(305945005)(7596002)(486006)(446003)(476003)(53546011)(126002)(299355004);DIR:INB;SFP:;SCL:1;SRVR:BY1PR12MB0422;H:mail.wl.linuxfoundation.org;FPR:;SPF:Pass;LANG:en;PTR:mail.wl.linuxfoundation.org;A:1;MX:1;
X-Microsoft-Exchange-Diagnostics:
1;BY2NAM03FT061;1:lQEvMAxtR2JOGGIiXQO7t17eFtbZRyjwdv013Ine395PILRydhCTu6+G7Ih6HA4nUtXbydrZ/4ubSFeLt3/A+740LMooYf4Mf764kE2+w32T0SisrVafMBEpTdPHo78X
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 03481303-c73c-4113-6255-08d643d85f4f
X-Microsoft-Antispam:
BCL:0;PCL:0;RULEID:(7020095)(4652040)(5600074)(711020)(4605076)(4608076)(4614076)(1401272)(1421009)(1402068)(71702078);SRVR:BY1PR12MB0422;
X-Microsoft-Exchange-Diagnostics:

Re: [PATCH] drm/lease: look at ->universal_planes only once

2018-11-06 Thread Daniel Vetter
On Mon, Nov 05, 2018 at 11:12:11AM +0100, Daniel Vetter wrote:
> It's lockless, and userspace might chance it underneath us. That's not
> really a problem, all userspace gets is a slightly dysfunctional
> lease with the current code. But this might change, and gcc might
> decide to reload a few too many times, and then boom. So better safe
> than sorry.
> 
> v2: Remove the now unused lessor_priv argument from validate_lease()
> (Keith).
> 
> v3: Actually add everything ... silly me.
> 
> Cc: Keith Packard 
> Cc: Dave Airlie 
> Signed-off-by: Daniel Vetter 

All pulled in with CI approving and Keith's irc-ack on this one here.
-Daniel

> ---
>  drivers/gpu/drm/drm_lease.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 3b0342a45ae9..3650d3c46718 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -353,9 +353,9 @@ void drm_lease_revoke(struct drm_master *top)
>  }
>  
>  static int validate_lease(struct drm_device *dev,
> -   struct drm_file *lessor_priv,
> int object_count,
> -   struct drm_mode_object **objects)
> +   struct drm_mode_object **objects,
> +   bool universal_planes)
>  {
>   int o;
>   int has_crtc = -1;
> @@ -372,14 +372,14 @@ static int validate_lease(struct drm_device *dev,
>   if (objects[o]->type == DRM_MODE_OBJECT_CONNECTOR && 
> has_connector == -1)
>   has_connector = o;
>  
> - if (lessor_priv->universal_planes) {
> + if (universal_planes) {
>   if (objects[o]->type == DRM_MODE_OBJECT_PLANE && 
> has_plane == -1)
>   has_plane = o;
>   }
>   }
>   if (has_crtc == -1 || has_connector == -1)
>   return -EINVAL;
> - if (lessor_priv->universal_planes && has_plane == -1)
> + if (universal_planes && has_plane == -1)
>   return -EINVAL;
>   return 0;
>  }
> @@ -393,6 +393,8 @@ static int fill_object_idr(struct drm_device *dev,
>   struct drm_mode_object **objects;
>   u32 o;
>   int ret;
> + bool universal_planes = READ_ONCE(lessor_priv->universal_planes);
> +
>   objects = kcalloc(object_count, sizeof(struct drm_mode_object *),
> GFP_KERNEL);
>   if (!objects)
> @@ -421,7 +423,7 @@ static int fill_object_idr(struct drm_device *dev,
>   }
>   }
>  
> - ret = validate_lease(dev, lessor_priv, object_count, objects);
> + ret = validate_lease(dev, object_count, objects, universal_planes);
>   if (ret) {
>   DRM_DEBUG_LEASE("lease validation failed\n");
>   goto out_free_objects;
> @@ -448,7 +450,7 @@ static int fill_object_idr(struct drm_device *dev,
>   object_id, ret);
>   goto out_free_objects;
>   }
> - if (obj->type == DRM_MODE_OBJECT_CRTC && 
> !lessor_priv->universal_planes) {
> + if (obj->type == DRM_MODE_OBJECT_CRTC && !universal_planes) {
>   struct drm_crtc *crtc = obj_to_crtc(obj);
>   ret = idr_alloc(leases, _lease_idr_object, 
> crtc->primary->base.id, crtc->primary->base.id + 1, GFP_KERNEL);
>   if (ret < 0) {
> -- 
> 2.14.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 2/2] drm/msm/a6xx: Fix a typo in a6xx gpu crash state

2018-11-06 Thread Jordan Crouse
On Tue, Nov 06, 2018 at 12:38:29PM +0530, Sharat Masetty wrote:
> This patch simply fixes a typo for the name of an indexed register.
> CP_MEMPOOOL -> CP_MEMPOOL.
> 
> Signed-off-by: Sharat Masetty 

Reviewed by: Jordan Crouse 

> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
> index 68cccfa..bbbec8d 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
> @@ -370,7 +370,7 @@ struct a6xx_registers {
>  };
>  
>  static const struct a6xx_indexed_registers a6xx_cp_mempool_indexed = {
> - "CP_MEMPOOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
> + "CP_MEMPOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
>   REG_A6XX_CP_MEM_POOL_DBG_DATA, 0x2060,
>  };
>  
> -- 
> 1.9.1
> 

-- 
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 1/2] drm/msm/a6xx: Build a6xx_gpu_state under the right conditionals

2018-11-06 Thread Jordan Crouse
On Tue, Nov 06, 2018 at 12:38:28PM +0530, Sharat Masetty wrote:
> Build a6xx_gpu_state.c only if either of CONFIG_DEBUG_FS, CONFIG_DEV_COREDUMP
> is defined.

Can you do the same for the other targets too?  With that,

Reviewed-by: Jordan Crouse 

> Signed-off-by: Sharat Masetty 
> ---
>  drivers/gpu/drm/msm/Makefile  | 5 -
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++--
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
> index bfb0f08..404e3ae 100644
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> @@ -14,7 +14,6 @@ msm-y := \
>   adreno/a6xx_gpu.o \
>   adreno/a6xx_gmu.o \
>   adreno/a6xx_hfi.o \
> - adreno/a6xx_gpu_state.o \
>   hdmi/hdmi.o \
>   hdmi/hdmi_audio.o \
>   hdmi/hdmi_bridge.o \
> @@ -97,6 +96,10 @@ msm-y := \
>  msm-$(CONFIG_DEBUG_FS) += adreno/a5xx_debugfs.o \
> disp/dpu1/dpu_dbg.o
>  
> +ifneq (,$(filter y,$(CONFIG_DEBUG_FS) $(CONFIG_DEV_COREDUMP)))
> +msm-y += adreno/a6xx_gpu_state.o
> +endif
> +
>  msm-$(CONFIG_DRM_FBDEV_EMULATION) += msm_fbdev.o
>  msm-$(CONFIG_COMMON_CLK) += disp/mdp4/mdp4_lvds_pll.o
>  msm-$(CONFIG_COMMON_CLK) += hdmi/hdmi_pll_8960.o
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 2c52b7c..9d1b8c9 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -754,12 +754,12 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu, 
> u64 *prev_cycles)
>   .destroy = a6xx_destroy,
>  #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
>   .show = a6xx_show,
> + .gpu_state_get = a6xx_gpu_state_get,
> + .gpu_state_put = a6xx_gpu_state_put,
>  #endif
>   .gpu_busy = a6xx_gpu_busy,
>   .gpu_get_freq = a6xx_gmu_get_freq,
>   .gpu_set_freq = a6xx_gmu_set_freq,
> - .gpu_state_get = a6xx_gpu_state_get,
> - .gpu_state_put = a6xx_gpu_state_put,
>   },
>   .get_timestamp = a6xx_get_timestamp,
>  };
> -- 
> 1.9.1
> 

-- 
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 3/3] drm/msm: Optimize adreno_show_object()

2018-11-06 Thread Jordan Crouse
On Tue, Nov 06, 2018 at 11:40:06AM +0530, Sharat Masetty wrote:
> When the userspace tries to read the crashstate dump, the read side
> implementation in the driver currently ascii85 encodes all the binary
> buffers and it does this each time the read system call is called.
> A userspace tool like cat typically does a page by page read and the
> number of read calls depends on the size of the data captured by the
> driver. This is certainly not desirable and does not scale well with
> large captures.
> 
> This patch encodes the buffer only once in the read path. With this there
> is an immediate >10X speed improvement in crashstate save time.
> 
> Signed-off-by: Sharat Masetty 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 76 
> -
>  drivers/gpu/drm/msm/msm_gpu.h   |  2 +
>  2 files changed, 58 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index c93702d..e29093e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -475,34 +475,70 @@ int adreno_gpu_state_put(struct msm_gpu_state *state)
>  
>  #if defined(CONFIG_DEBUG_FS) || defined(CONFIG_DEV_COREDUMP)
>  
> -static void adreno_show_object(struct drm_printer *p, u32 *ptr, int len)
> +static char *adreno_gpu_ascii85_encode(u32 *src, size_t len)
>  {
> - char out[ASCII85_BUFSZ];
> - long l, datalen, i;
> + void *buf;
> + size_t buf_itr = 0;
> + long i, l;
>  
> - if (!ptr || !len)
> - return;
> + if (!len)
> + return NULL;
> +
> + l = ascii85_encode_len(len);
>  
>   /*
> -  * Only dump the non-zero part of the buffer - rarely will any data
> -  * completely fill the entire allocated size of the buffer
> +  * ascii85 outputs either a 5 byte string or a 1 byte string. So we
> +  * account for the worst case of 5 bytes per dword plus the 1 for '\0'
>*/
> - for (datalen = 0, i = 0; i < len >> 2; i++) {
> - if (ptr[i])
> - datalen = (i << 2) + 1;
> - }
> + buf = kvmalloc((l * 5) + 1, GFP_KERNEL);
> + if (!buf)
> + return NULL;
>  
> - /* Skip printing the object if it is empty */
> - if (datalen == 0)
> + for (i = 0; i < l; i++)
> + buf_itr += ascii85_encode_to_buf(src[i], buf + buf_itr);

If this is the only use of ascii85_encode_to_buf I don't think we need it in the
common header - the same functionality can just be built in here.

> +
> + return buf;
> +}
> +
> +/* len is expected to be in bytes */
> +static void adreno_show_object(struct drm_printer *p, void **ptr, int len,
> + bool *encoded)
> +{
> + if (!*ptr || !len)
>   return;
>  
> - l = ascii85_encode_len(datalen);
> + if (!*encoded) {

We wouldn't need the encoded bool if you used different pointers for the
non-encoded and encoded objects -

if (!encoded) {
   encoded = adreno_gpu_ascii85_encode(raw);

   kvfree(raw);
   raw = NULL;
}

And then just blindly kvfree() both in the destroy function - I think that
would be a bit clearer than trying to reuse the buffer.
   
> + long datalen, i;
> + u32 *buf = *ptr;
> +
> + /*
> +  * Only dump the non-zero part of the buffer - rarely will
> +  * any data completely fill the entire allocated size of
> +  * the buffer.
> +  */
> + for (datalen = 0, i = 0; i < len >> 2; i++) {
> + if (buf[i])
> + datalen = ((i + 1) << 2);
> + }
> +
> + /*
> +  * If we reach here, then the originally captured binary buffer
> +  * will be replaced with the ascii85 encoded string
> +  */
> + *ptr = adreno_gpu_ascii85_encode(buf, datalen);
> +
> + kvfree(buf);
> +
> + *encoded = true;
> + }
> +
> + if (!*ptr)
> + return;
>  
>   drm_puts(p, "data: !!ascii85 |\n");
>   drm_puts(p, " ");
>  
> - for (i = 0; i < l; i++)
> - drm_puts(p, ascii85_encode(ptr[i], out));
> + drm_puts(p, *ptr);
>  
>   drm_puts(p, "\n");
>  }
> @@ -534,8 +570,8 @@ void adreno_show(struct msm_gpu *gpu, struct 
> msm_gpu_state *state,
>   drm_printf(p, "wptr: %d\n", state->ring[i].wptr);
>   drm_printf(p, "size: %d\n", MSM_GPU_RINGBUFFER_SZ);
>  
> - adreno_show_object(p, state->ring[i].data,
> - state->ring[i].data_size);
> + adreno_show_object(p, >ring[i].data,
> + state->ring[i].data_size, >ring[i].encoded);

This implies we should make a sub struct to store the data / size / state of the
buffers so this can turn into:


adreno_show_object(&(state->ring[i].object))

We could repurpose msm_gpu_state_bo for this task - this 

Re: [PATCH v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC

2018-11-06 Thread Ville Syrjälä
On Tue, Nov 06, 2018 at 08:52:41AM -0800, Manasi Navare wrote:
> On Tue, Nov 06, 2018 at 04:33:38PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 02, 2018 at 02:31:29PM -0700, Manasi Navare wrote:
> > > From: Gaurav K Singh 
> > > 
> > > This computation of RC params happens in the atomic commit phase
> > > during compute_config() to validate if display stream compression
> > > can be enabled for the requested mode.
> > > 
> > > v7 (From Manasi):
> > > * Use DRM_DEBUG instead of DRM_ERROR (Ville)
> > > * Use Error numberinstead of -1 (Ville)
> > > v6 (From Manasi):
> > > * Use 9 instead of 0x9 for consistency (Anusha)
> > > 
> > > v5 (From Manasi):
> > > * Fix dim checkpatch warnings/checks
> > > v4(From Gaurav):
> > > * No change.Rebase on drm-tip
> > > 
> > > v3 (From Gaurav):
> > > * Rebase on top of Manasi's latest series
> > > * Return -ve value in case of failure scenarios (Manasi)
> > > 
> > > Fix review comments from Ville:
> > > * Remove unnecessary comments
> > > * Remove unnecessary paranthesis
> > > * Add comments for few RC params calculations
> > > 
> > > v2 (From Manasi):
> > > * Rebase Gaurav's patch from intel-gfx to gfx-internal
> > > * Use struct drm_dsc_cfg instead of struct intel_dp
> > > as a parameter
> > > 
> > > Cc: Manasi Navare 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjala 
> > > Signed-off-by: Gaurav K Singh 
> > > Signed-off-by: Manasi Navare 
> > > Reviewed-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/intel_vdsc.c | 127 ++
> > >  1 file changed, 127 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > > b/drivers/gpu/drm/i915/intel_vdsc.c
> > > index 0a1918f2f643..a76f78b9c0ee 100644
> > > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > > @@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8 
> > > bits_per_component)
> > >   }
> > >  }
> > >  
> > > +static int intel_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> > > +{
> > > + unsigned long groups_per_line = 0;
> > > + unsigned long groups_total = 0;
> > > + unsigned long num_extra_mux_bits = 0;
> > > + unsigned long slice_bits = 0;
> > > + unsigned long hrd_delay = 0;
> > > + unsigned long final_scale = 0;
> > > + unsigned long rbs_min = 0;
> > > +
> > > + /* Number of groups used to code each line of a slice */
> > > + groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> > > +DSC_RC_PIXELS_PER_GROUP);
> > > +
> > > + /* chunksize in Bytes */
> > > + vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> > > +   vdsc_cfg->bits_per_pixel,
> > > +   (8 * 16));
> > > +
> > > + if (vdsc_cfg->convert_rgb)
> > > + num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> > > +   (4 * vdsc_cfg->bits_per_component + 4)
> > > +   - 2);
> > > + else
> > > + num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> > > + (4 * vdsc_cfg->bits_per_component + 4) +
> > > + 2 * (4 * vdsc_cfg->bits_per_component) - 2;
> > > + /* Number of bits in one Slice */
> > > + slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> > > +
> > > + while ((num_extra_mux_bits > 0) &&
> > > +((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> > > + num_extra_mux_bits--;
> > > +
> > > + if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> > > + vdsc_cfg->initial_scale_value = groups_per_line + 8;
> > > +
> > > + /* scale_decrement_interval calculation according to DSC spec 1.11 */
> > > + if (vdsc_cfg->initial_scale_value > 8)
> > > + vdsc_cfg->scale_decrement_interval = groups_per_line /
> > > + (vdsc_cfg->initial_scale_value - 8);
> > > + else
> > > + vdsc_cfg->scale_decrement_interval = 
> > > DSC_SCALE_DECREMENT_INTERVAL_MAX;
> > > +
> > > + vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> > > + (vdsc_cfg->initial_xmit_delay *
> > > +  vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> > > +
> > > + if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> > > + DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> > > InitialXmitDelay\n");
> > > + return -EINVAL;
> > > + }
> > > +
> > > + final_scale = (vdsc_cfg->rc_model_size * 8) /
> > > + (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> > > + if (vdsc_cfg->slice_height > 1)
> > > + /*
> > > +  * NflBpgOffset is 16 bit value with 11 fractional bits
> > > +  * hence we multiply by 2^11 for preserving the
> > > +  * fractional part
> > > +  */
> > > + vdsc_cfg->nfl_bpg_offset = 
> > > DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> > > + (vdsc_cfg->slice_height 
> > > - 1));
> > > + else
> > > +  

[Bug 108668] drm/amd/display: set backlight level limit to 1: breaks userspace programs assuming 0 is the minimum brightness

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108668

--- Comment #2 from Harry Wentland  ---
This should fix it: https://patchwork.freedesktop.org/patch/260537/

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


Re: [PATCH 1/3] drm/msm: use kvmalloc for ring data in gpu crashstate

2018-11-06 Thread Jordan Crouse
On Tue, Nov 06, 2018 at 11:40:04AM +0530, Sharat Masetty wrote:
> The ringbuffer data to capture at crashtime can end up being large
> sometimes, and the size can vary from being less than a page to the
> full size of 32KB. So use the kvmalloc variant that perfectly fits the bill.
> 
> Signed-off-by: Sharat Masetty 

Reviewed-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 141062f..c93702d 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -406,7 +406,7 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct 
> msm_gpu_state *state)
>   size = j + 1;
>  
>   if (size) {
> - state->ring[i].data = kmalloc(size << 2, GFP_KERNEL);
> + state->ring[i].data = kvmalloc(size << 2, GFP_KERNEL);
>   if (state->ring[i].data) {
>   memcpy(state->ring[i].data, gpu->rb[i]->start, 
> size << 2);
>   state->ring[i].data_size = size << 2;
> @@ -445,7 +445,7 @@ void adreno_gpu_state_destroy(struct msm_gpu_state *state)
>   int i;
>  
>   for (i = 0; i < ARRAY_SIZE(state->ring); i++)
> - kfree(state->ring[i].data);
> + kvfree(state->ring[i].data);
>  
>   for (i = 0; state->bos && i < state->nr_bos; i++)
>   kvfree(state->bos[i].data);
> -- 
> 1.9.1
> 

-- 
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 v8 10/19] drm/i915/dsc: Compute Rate Control parameters for DSC

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:33:38PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 02, 2018 at 02:31:29PM -0700, Manasi Navare wrote:
> > From: Gaurav K Singh 
> > 
> > This computation of RC params happens in the atomic commit phase
> > during compute_config() to validate if display stream compression
> > can be enabled for the requested mode.
> > 
> > v7 (From Manasi):
> > * Use DRM_DEBUG instead of DRM_ERROR (Ville)
> > * Use Error numberinstead of -1 (Ville)
> > v6 (From Manasi):
> > * Use 9 instead of 0x9 for consistency (Anusha)
> > 
> > v5 (From Manasi):
> > * Fix dim checkpatch warnings/checks
> > v4(From Gaurav):
> > * No change.Rebase on drm-tip
> > 
> > v3 (From Gaurav):
> > * Rebase on top of Manasi's latest series
> > * Return -ve value in case of failure scenarios (Manasi)
> > 
> > Fix review comments from Ville:
> > * Remove unnecessary comments
> > * Remove unnecessary paranthesis
> > * Add comments for few RC params calculations
> > 
> > v2 (From Manasi):
> > * Rebase Gaurav's patch from intel-gfx to gfx-internal
> > * Use struct drm_dsc_cfg instead of struct intel_dp
> > as a parameter
> > 
> > Cc: Manasi Navare 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Signed-off-by: Gaurav K Singh 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/intel_vdsc.c | 127 ++
> >  1 file changed, 127 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index 0a1918f2f643..a76f78b9c0ee 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -317,6 +317,130 @@ static int get_column_index_for_rc_params(u8 
> > bits_per_component)
> > }
> >  }
> >  
> > +static int intel_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg)
> > +{
> > +   unsigned long groups_per_line = 0;
> > +   unsigned long groups_total = 0;
> > +   unsigned long num_extra_mux_bits = 0;
> > +   unsigned long slice_bits = 0;
> > +   unsigned long hrd_delay = 0;
> > +   unsigned long final_scale = 0;
> > +   unsigned long rbs_min = 0;
> > +
> > +   /* Number of groups used to code each line of a slice */
> > +   groups_per_line = DIV_ROUND_UP(vdsc_cfg->slice_width,
> > +  DSC_RC_PIXELS_PER_GROUP);
> > +
> > +   /* chunksize in Bytes */
> > +   vdsc_cfg->slice_chunk_size = DIV_ROUND_UP(vdsc_cfg->slice_width *
> > + vdsc_cfg->bits_per_pixel,
> > + (8 * 16));
> > +
> > +   if (vdsc_cfg->convert_rgb)
> > +   num_extra_mux_bits = 3 * (vdsc_cfg->mux_word_size +
> > + (4 * vdsc_cfg->bits_per_component + 4)
> > + - 2);
> > +   else
> > +   num_extra_mux_bits = 3 * vdsc_cfg->mux_word_size +
> > +   (4 * vdsc_cfg->bits_per_component + 4) +
> > +   2 * (4 * vdsc_cfg->bits_per_component) - 2;
> > +   /* Number of bits in one Slice */
> > +   slice_bits = 8 * vdsc_cfg->slice_chunk_size * vdsc_cfg->slice_height;
> > +
> > +   while ((num_extra_mux_bits > 0) &&
> > +  ((slice_bits - num_extra_mux_bits) % vdsc_cfg->mux_word_size))
> > +   num_extra_mux_bits--;
> > +
> > +   if (groups_per_line < vdsc_cfg->initial_scale_value - 8)
> > +   vdsc_cfg->initial_scale_value = groups_per_line + 8;
> > +
> > +   /* scale_decrement_interval calculation according to DSC spec 1.11 */
> > +   if (vdsc_cfg->initial_scale_value > 8)
> > +   vdsc_cfg->scale_decrement_interval = groups_per_line /
> > +   (vdsc_cfg->initial_scale_value - 8);
> > +   else
> > +   vdsc_cfg->scale_decrement_interval = 
> > DSC_SCALE_DECREMENT_INTERVAL_MAX;
> > +
> > +   vdsc_cfg->final_offset = vdsc_cfg->rc_model_size -
> > +   (vdsc_cfg->initial_xmit_delay *
> > +vdsc_cfg->bits_per_pixel + 8) / 16 + num_extra_mux_bits;
> > +
> > +   if (vdsc_cfg->final_offset >= vdsc_cfg->rc_model_size) {
> > +   DRM_DEBUG_KMS("FinalOfs < RcModelSze for this 
> > InitialXmitDelay\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   final_scale = (vdsc_cfg->rc_model_size * 8) /
> > +   (vdsc_cfg->rc_model_size - vdsc_cfg->final_offset);
> > +   if (vdsc_cfg->slice_height > 1)
> > +   /*
> > +* NflBpgOffset is 16 bit value with 11 fractional bits
> > +* hence we multiply by 2^11 for preserving the
> > +* fractional part
> > +*/
> > +   vdsc_cfg->nfl_bpg_offset = 
> > DIV_ROUND_UP((vdsc_cfg->first_line_bpg_offset << 11),
> > +   (vdsc_cfg->slice_height 
> > - 1));
> > +   else
> > +   vdsc_cfg->nfl_bpg_offset = 0;
> > +
> > +   /* 2^16 - 1 */
> > +   if (vdsc_cfg->nfl_bpg_offset > 65535) {
> > +   DRM_DEBUG_KMS("NflBpgOffset is too large for this slice 
> > 

Re: [PATCH v8 13/19] drm/i915/dp: Configure i915 Picture parameter Set registers during DSC enabling

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:36:08PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 02, 2018 at 02:31:32PM -0700, Manasi Navare wrote:
> > After encoder->pre_enable() hook, after link training sequence is
> > completed, PPS registers for DSC encoder are configured using the
> > DSC state parameters in intel_crtc_state as part of DSC enabling
> > routine in the source. DSC enabling routine is called after
> > encoder->pre_enable() before enbaling the pipe and after
> > compression is enabled on the sink.
> > 
> > v6:
> > intel_dsc_enable to be part of pre_enable hook (Ville)
> > v5:
> > * make crtc_state const (Ville)
> > v4:
> > * Use cpu_transcoder instead of encoder->type for using EDP transcoder
> > DSC registers(Ville)
> > * Keep all PSS regs together (Anusha)
> > 
> > v3:
> > * Configure Pic_width/2 for each VDSC engine when two VDSC engines per pipe
> > are used (Manasi)
> > * Add DSC slice_row_per_frame in PPS16 (Manasi)
> > 
> > v2:
> > * Enable PG2 power well for VDSC on eDP
> > 
> > Cc: Jani Nikula 
> > Cc: Ville Syrjala 
> > Cc: Anusha Srivatsa 
> > Signed-off-by: Manasi Navare 
> > Reviewed-by: Anusha Srivatsa 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  |   2 +
> >  drivers/gpu/drm/i915/intel_ddi.c |   6 +
> >  drivers/gpu/drm/i915/intel_display.c |   1 +
> >  drivers/gpu/drm/i915/intel_vdsc.c| 419 +++
> >  4 files changed, 428 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index d7797a41c648..f347d0d7b9eb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3485,6 +3485,8 @@ extern void intel_rps_mark_interactive(struct 
> > drm_i915_private *i915,
> >bool interactive);
> >  extern bool intel_set_memory_cxsr(struct drm_i915_private *dev_priv,
> >   bool enable);
> > +extern void intel_dsc_enable(struct intel_encoder *encoder,
> > +const struct intel_crtc_state *crtc_state);
> >  
> >  int i915_reg_read_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file);
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index af12c15ed94f..bba08322afb7 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2962,6 +2962,12 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> >  
> > if (!is_mst)
> > intel_ddi_enable_pipe_clock(crtc_state);
> > +
> > +   /*
> > +* Enable and Configure Display Stream Compression in the source
> > +* if enabled in intel_crtc_state.
> > +*/
> > +   intel_dsc_enable(encoder, crtc_state);
> >  }
> >  
> >  static void intel_ddi_pre_enable_hdmi(struct intel_encoder *encoder,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 477e53c37353..d3aa77f4d606 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5417,6 +5417,7 @@ static void intel_encoders_pre_enable(struct drm_crtc 
> > *crtc,
> >  
> > if (encoder->pre_enable)
> > encoder->pre_enable(encoder, crtc_state, conn_state);
> > +
> 
> Bogus whitespace leftover. Please try to read through your own patches
> before sending them. That generally helps catch silly things like this.
>

Oh yes, I will fix this, actually I did but the new versions were sent with CI 
tag after this to get the
CI results.

Manasi
 
> > }
> >  }
> >  
> > diff --git a/drivers/gpu/drm/i915/intel_vdsc.c 
> > b/drivers/gpu/drm/i915/intel_vdsc.c
> > index a76f78b9c0ee..0eaa69778160 100644
> > --- a/drivers/gpu/drm/i915/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/intel_vdsc.c
> > @@ -580,3 +580,422 @@ int intel_dp_compute_dsc_params(struct intel_dp 
> > *intel_dp,
> >  
> > return 0;
> >  }
> > +
> > +static void intel_configure_pps_for_dsc_encoder(struct intel_encoder 
> > *encoder,
> > +   const struct intel_crtc_state 
> > *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
> > +   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > +   const struct drm_dsc_config *vdsc_cfg = _state->dp_dsc_cfg;
> > +   enum pipe pipe = crtc->pipe;
> > +   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +   u32 pps_val = 0;
> > +   u32 rc_buf_thresh_dword[4];
> > +   u32 rc_range_params_dword[8];
> > +   u8 num_vdsc_instances = (crtc_state->dsc_params.dsc_split) ? 2 : 1;
> > +   int i = 0;
> > +
> > +   /* Populate PICTURE_PARAMETER_SET_0 registers */
> > +   pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> > +   DSC_VER_MIN_SHIFT |
> > +   vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
> > +   vdsc_cfg->line_buf_depth << DSC_LINE_BUF_DEPTH_SHIFT;
> > +   if 

Re: [v6 2/4] drm/i915/fec: Set FEC_READY in FEC_CONFIGURATION

2018-11-06 Thread Manasi Navare
On Tue, Nov 06, 2018 at 04:51:22PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 05, 2018 at 04:48:57PM -0800, Manasi Navare wrote:
> > On Mon, Nov 05, 2018 at 03:31:48PM -0800, Anusha Srivatsa wrote:
> > > If the panel supports FEC, the driver has to
> > > set the FEC_READY bit in the dpcd register:
> > > FEC_CONFIGURATION.
> > > 
> > > This has to happen before link training.
> > > 
> > > v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
> > >- change commit message. (Gaurav)
> > > 
> > > v3: rebased. (r-b Manasi)
> > > 
> > > v4: Use fec crtc state, before setting FEC_READY
> > > bit. (Anusha)
> > > 
> > > v5: Move to intel_ddi.c
> > > - Make the function static (Anusha)
> > > 
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Gaurav K Singh 
> > > Cc: Jani Nikula 
> > > Cc: Ville Syrjala 
> > > Cc: Manasi Navare 
> > > Signed-off-by: Anusha Srivatsa 
> > > ---
> > >  drivers/gpu/drm/i915/intel_ddi.c | 15 +++
> > >  1 file changed, 15 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > > b/drivers/gpu/drm/i915/intel_ddi.c
> > > index 46c1b9e12fbd..53a9b31e66a2 100644
> > > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > > @@ -3051,6 +3051,20 @@ static void icl_program_mg_dp_mode(struct 
> > > intel_digital_port *intel_dig_port)
> > >   I915_WRITE(MG_DP_MODE(port, 1), ln1);
> > >  }
> > >  
> > > +static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> > > + const struct intel_crtc_state 
> > > *crtc_state,
> > > + int state)
> > 
> > u8 state should be good enough since you are writing only a byte here
> 
> AFAICS this is never called with anything but DP_FEC_READY. So
> there is absolutely benefit in making the caller have to
> pass that in. Just drop the 'state' argument entirely IMO.

Oh yes thats correct, its a constant at DRM level and can be used directly 
since state never really gets set to
DP_FEC_NOT_READy. 

Manasi

> 
> > 
> > > +{
> > > + int ret;
> > > +
> > > + if (!crtc_state->fec_enable)
> > > + return;
> > > +
> > > + ret = drm_dp_dpcd_writeb(_dp->aux, DP_FEC_CONFIGURATION, state);
> > > + if (ret < 0)
> > 
> > This should ret <=0 since even if it writes 0 bytes its an error. Infact 
> > you dont need ret
> > you can just say"
> > if (drm_dp_dpcd_writeb(_dp->aux, DP_FEC_CONFIGURATION, state) <= 0)
> > 
> > After the above changes,
> > 
> > Reviewed-by: Manasi Navare 
> > 
> > Manasi
> > > + DRM_DEBUG_KMS("Failed to get FEC enabled in sink\n");
> 
> This debug msg doesn't make sense.
> 
> > > +}
> > > +
> > >  static void intel_ddi_pre_enable_dp(struct intel_encoder *encoder,
> > >   const struct intel_crtc_state *crtc_state,
> > >   const struct drm_connector_state 
> > > *conn_state)
> > > @@ -3091,6 +3105,7 @@ static void intel_ddi_pre_enable_dp(struct 
> > > intel_encoder *encoder,
> > >   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > >   intel_dp_sink_set_decompression_state(intel_dp, crtc_state,
> > > true);
> > > + intel_dp_sink_set_fec_ready(intel_dp, crtc_state, DP_FEC_READY);
> > >   intel_dp_start_link_train(intel_dp);
> > >   if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > >   intel_dp_stop_link_train(intel_dp);
> > > -- 
> > > 2.19.1
> > > 
> 
> -- 
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/nouveau: tegra: Initialize mode configuration

2018-11-06 Thread Ville Syrjälä
On Tue, Nov 06, 2018 at 05:24:15PM +0100, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Irrespective of whether or not the device has any usable outputs, the
> modesetting helpers will try to register all the resources such as CRTCs
> and planes. Unfortunately, the helpers rely on drm_mode_config_init() to
> properly set up internal data structures. Since the Tegra GPU does not
> have a display engine, the Nouveau driver doesn't set this up for Tegra,
> which results in the following oops on driver probe:

Remove DRIVER_MODESET ?

> 
>   [   18.776221] Unable to handle kernel NULL pointer dereference at 
> virtual address 006c
>   [   18.785401] pgd = 16bb93b7
>   [   18.789331] [006c] *pgd=ad58c003, *pmd=
>   [   18.800757] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
>   [   18.806233] Modules linked in: nouveau(+) ttm tegra_drm
>   [   18.811457] CPU: 1 PID: 245 Comm: systemd-udevd Not tainted 
> 4.20.0-rc1 #36
>   [   18.818324] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
>   [   18.824596] PC is at drm_plane_register_all+0x18/0x50
>   [   18.824601] LR is at drm_modeset_register_all+0xc/0x70
>   [   18.824604] pc : []lr : []psr: a113
>   [   18.824607] sp : ed5dfc70  ip : ed742d40  fp : 
>   [   18.824610] r10: 0018  r9 : ed742d00  r8 : 
>   [   18.824613] r7 : bf26ac80  r6 :   r5 : ed155650  r4 : 
> fffc
>   [   18.824616] r3 : 0002f000  r2 :   r1 : 2df3  r0 : 
> ed155400
>   [   18.824621] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
> Segment user
>   [   18.824624] Control: 30c5387d  Table: aeb18840  DAC: 
>   [   18.824628] Process systemd-udevd (pid: 245, stack limit = 
> 0xc66954c3)
>   [   18.824633] Stack: (0xed5dfc70 to 0xed5e)
>   [   18.824636] fc60: ed155400 
> ed155400  c068e45c
>   [   18.824641] fc80: ed155400   c06751a4 0001 
> 0001  
>   [   18.905936] fca0: ed5dfcc0 c1204c88 ed155400   
>  bf268c5c bf1c5cd4
>   [   18.914108] fcc0: ed710c08 9543847b  eea34810  
> bf268c5c  c06a3f64
>   [   18.923651] fce0: c131dd70 eea34810 c131dd74   
> c06a2084 eea34810 bf268c5c
>   [   18.932934] fd00: eea34844 c06a23e0  c1204c88 bf26a980 
> c06a22d4 eefd093c c06a23e0
>   [   18.941096] fd20:  eea34810 bf268c5c eea34844 c06a23e0 
>  c1204c88 bf26a980
>   [   18.949259] fd40:  c06a24bc eea387b4 c1204c88 bf268c5c 
> c06a038c  ee88335c
>   [   18.957417] fd60: eea387b4 9543847b c1275a88 bf268c5c ed12b800 
> c1275a88  c06a1528
>   [   18.965580] fd80: bf245be8 bf268ac8 e000 bf268c5c bf268ac8 
> e000 bf292000 c06a30d8
>   [   18.973746] fda0: bf26ab80 bf268ac8 e000 bf292170 c12cf160 
> c1204c88 e000 c0202dbc
>   [   18.981913] fdc0: ed667700 006000c0 c02b2844 000c 600d0013 
> bf26a980 0040 c03650f8
>   [   18.990079] fde0: a00d0013 2defd000 ee80 006000c0 006000c0 
> c02b2844 000c c03666f4
>   [   18.998244] fe00: c0358254 a00d0013 bf26a980 9543847b bf26a980 
> 0001 ed667700 0001
>   [   19.006404] fe20: ed1d9ee4 c02b2880 c1204c88 bf26a980  
> ed5dff40 0001 ed1d9ec0
>   [   19.014569] fe40: 0001 c02b48c8 bf26a98c 7fff bf26a980 
> c02b1a00  c02b1214
>   [   19.022735] fe60: bf26a9c8 bf26aa80 bf26ab5c bf26aab0 c0c0387c 
> c0e62374 c0db80fc c0db8108
>   [   19.030901] fe80: c0db8160 c1204c88 bf00 ed1296c0 06c18a20 
>  ed1296c0 c1204c88
>   [   19.039068] fea0:      
>  6e72656b 6c65
>   [   19.047228] fec0:      
>   
>   [   19.055393] fee0:      
> 9543847b 7fff c1204c88
>   [   19.063558] ff00:  000f b6c51c58 c0201204 ed5de000 
> 017b bea73b0c c02b5188
>   [   19.071723] ff20: 7fff  0003 c0334b4c 0002 
> f1bc1000 06c18a20 
>   [   19.079890] ff40: f1d0c3aa f1d24e80 f1bc1000 06c18a20 f87d90c0 
> f87d8e60 f70d7798 0016a000
>   [   19.088056] ff60: 0017e730    00050ba8 
> 0039 003a 0022
>   [   19.096215] ff80:  0013  9543847b 00c0 
>  b6c51c58 000f
>   [   19.104378] ffa0: 017b c02011d4  b6c51c58 000f 
> b6c51c58  00559220
>   [   19.112543] ffc0:  b6c51c58 000f 017b  
>  00546958 bea73b0c
>   [   19.120708] ffe0: bea73af8 bea73ae8 b6c44c14 b6b4b710 600d0010 
> 000f  
>   [   19.128884] [] (drm_plane_register_all) from [] 
> (drm_modeset_register_all+0xc/0x70)
>   [   19.138273] [] 

[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108652

--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 142390
  --> https://bugs.freedesktop.org/attachment.cgi?id=142390=edit
Shadow of the Tomb Raider - screenshot with FPS counter

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


[GIT PULL] etnaviv-fixes for 4.19-rc2

2018-11-06 Thread Lucas Stach
Hi Dave,

a single fix that has been around for a while. Fixes GPU recovery after
job timeout not working in some cases due to a bogus comparison of
fences on different timelines.

Regards,
Lucas

The following changes since commit 84df9525b0c27f3ebc2ebb1864fa62a97fdedb7d:

  Linux 4.19 (2018-10-22 07:37:37 +0100)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/fixes

for you to fetch changes up to 6fce3a406108ee6c8a61e2a33e52e9198a626ea0:

  drm/etnaviv: fix bogus fence complete check in timeout handler (2018-11-05 
18:14:48 +0100)


Lucas Stach (1):
  drm/etnaviv: fix bogus fence complete check in timeout handler

 drivers/gpu/drm/etnaviv/etnaviv_sched.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108652

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 142389
  --> https://bugs.freedesktop.org/attachment.cgi?id=142389=edit
Project CARS 2 - screenshot with FPS counter

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


[Bug 108652] I suspect that in kernel 4.19 power limit decreased in 4 times on Vega GPU

2018-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=108652

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
I would welcome any increase of FPS since I play on a 4K monitor.

1) Project CARS 2

GFX Clocks and Power:
700 MHz (MCLK)
984 MHz (SCLK)
1269 MHz (PSTATE_SCLK)
700 MHz (PSTATE_MCLK)
818 mV (VDDGFX)
62.0 W (average GPU)

GPU Temperature: 74 C
GPU Load: 100 %

7 FPS on medium settings it's FAIL.
I am sure that Vega 64 can do 50FPS on high settings:
Proof: https://youtu.be/tpBubGwj8Fo


2) Shadow of the Tomb Raider

GFX Clocks and Power:
700 MHz (MCLK)
981 MHz (SCLK)
1269 MHz (PSTATE_SCLK)
700 MHz (PSTATE_MCLK)
818 mV (VDDGFX)
76.0 W (average GPU)

GPU Temperature: 74 C
GPU Load: 99 %

15 FPS on high settings it's better that in previous game, but I am sure that
Vega 64 can do 30FPS on more higher settings:
Proof: https://youtu.be/ZIA_GjcB8BQ?t=66


So we see that Vega has 981 MHz instead of possible 1500 MHz and power
consumption 76.0 W instead of 240 W.

I can only guess why GPU consumer qualities were reduced.

# cat /sys/class/drm/card0/device/power_dpm_state
performance

# cat /sys/class/drm/card0/device/power_dpm_force_performance_level
auto

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


[PATCH] drm/nouveau: tegra: Initialize mode configuration

2018-11-06 Thread Thierry Reding
From: Thierry Reding 

Irrespective of whether or not the device has any usable outputs, the
modesetting helpers will try to register all the resources such as CRTCs
and planes. Unfortunately, the helpers rely on drm_mode_config_init() to
properly set up internal data structures. Since the Tegra GPU does not
have a display engine, the Nouveau driver doesn't set this up for Tegra,
which results in the following oops on driver probe:

[   18.776221] Unable to handle kernel NULL pointer dereference at 
virtual address 006c
[   18.785401] pgd = 16bb93b7
[   18.789331] [006c] *pgd=ad58c003, *pmd=
[   18.800757] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
[   18.806233] Modules linked in: nouveau(+) ttm tegra_drm
[   18.811457] CPU: 1 PID: 245 Comm: systemd-udevd Not tainted 
4.20.0-rc1 #36
[   18.818324] Hardware name: NVIDIA Tegra SoC (Flattened Device Tree)
[   18.824596] PC is at drm_plane_register_all+0x18/0x50
[   18.824601] LR is at drm_modeset_register_all+0xc/0x70
[   18.824604] pc : []lr : []psr: a113
[   18.824607] sp : ed5dfc70  ip : ed742d40  fp : 
[   18.824610] r10: 0018  r9 : ed742d00  r8 : 
[   18.824613] r7 : bf26ac80  r6 :   r5 : ed155650  r4 : 
fffc
[   18.824616] r3 : 0002f000  r2 :   r1 : 2df3  r0 : 
ed155400
[   18.824621] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
Segment user
[   18.824624] Control: 30c5387d  Table: aeb18840  DAC: 
[   18.824628] Process systemd-udevd (pid: 245, stack limit = 
0xc66954c3)
[   18.824633] Stack: (0xed5dfc70 to 0xed5e)
[   18.824636] fc60: ed155400 
ed155400  c068e45c
[   18.824641] fc80: ed155400   c06751a4 0001 
0001  
[   18.905936] fca0: ed5dfcc0 c1204c88 ed155400   
 bf268c5c bf1c5cd4
[   18.914108] fcc0: ed710c08 9543847b  eea34810  
bf268c5c  c06a3f64
[   18.923651] fce0: c131dd70 eea34810 c131dd74   
c06a2084 eea34810 bf268c5c
[   18.932934] fd00: eea34844 c06a23e0  c1204c88 bf26a980 
c06a22d4 eefd093c c06a23e0
[   18.941096] fd20:  eea34810 bf268c5c eea34844 c06a23e0 
 c1204c88 bf26a980
[   18.949259] fd40:  c06a24bc eea387b4 c1204c88 bf268c5c 
c06a038c  ee88335c
[   18.957417] fd60: eea387b4 9543847b c1275a88 bf268c5c ed12b800 
c1275a88  c06a1528
[   18.965580] fd80: bf245be8 bf268ac8 e000 bf268c5c bf268ac8 
e000 bf292000 c06a30d8
[   18.973746] fda0: bf26ab80 bf268ac8 e000 bf292170 c12cf160 
c1204c88 e000 c0202dbc
[   18.981913] fdc0: ed667700 006000c0 c02b2844 000c 600d0013 
bf26a980 0040 c03650f8
[   18.990079] fde0: a00d0013 2defd000 ee80 006000c0 006000c0 
c02b2844 000c c03666f4
[   18.998244] fe00: c0358254 a00d0013 bf26a980 9543847b bf26a980 
0001 ed667700 0001
[   19.006404] fe20: ed1d9ee4 c02b2880 c1204c88 bf26a980  
ed5dff40 0001 ed1d9ec0
[   19.014569] fe40: 0001 c02b48c8 bf26a98c 7fff bf26a980 
c02b1a00  c02b1214
[   19.022735] fe60: bf26a9c8 bf26aa80 bf26ab5c bf26aab0 c0c0387c 
c0e62374 c0db80fc c0db8108
[   19.030901] fe80: c0db8160 c1204c88 bf00 ed1296c0 06c18a20 
 ed1296c0 c1204c88
[   19.039068] fea0:      
 6e72656b 6c65
[   19.047228] fec0:      
  
[   19.055393] fee0:      
9543847b 7fff c1204c88
[   19.063558] ff00:  000f b6c51c58 c0201204 ed5de000 
017b bea73b0c c02b5188
[   19.071723] ff20: 7fff  0003 c0334b4c 0002 
f1bc1000 06c18a20 
[   19.079890] ff40: f1d0c3aa f1d24e80 f1bc1000 06c18a20 f87d90c0 
f87d8e60 f70d7798 0016a000
[   19.088056] ff60: 0017e730    00050ba8 
0039 003a 0022
[   19.096215] ff80:  0013  9543847b 00c0 
 b6c51c58 000f
[   19.104378] ffa0: 017b c02011d4  b6c51c58 000f 
b6c51c58  00559220
[   19.112543] ffc0:  b6c51c58 000f 017b  
 00546958 bea73b0c
[   19.120708] ffe0: bea73af8 bea73ae8 b6c44c14 b6b4b710 600d0010 
000f  
[   19.128884] [] (drm_plane_register_all) from [] 
(drm_modeset_register_all+0xc/0x70)
[   19.138273] [] (drm_modeset_register_all) from 
[] (drm_dev_register+0x168/0x1c4)
[   19.147581] [] (drm_dev_register) from [] 
(nouveau_platform_probe+0x6c/0x88 [nouveau])
[   

[PATCH v2] drm: Rename crtc_idr as object_idr to KMS cleanups

2018-11-06 Thread Shayenne da Luz Moura
This patch solves this TODO task:
 drm_mode_config.crtc_idr is misnamed, since it contains all KMS object.
 Should be renamed to drm_mode_config.object_idr.

Signed-off-by: Shayenne da Luz Moura 

---
Changes in v2:
 - Make commit message more clear and change header file

 drivers/gpu/drm/drm_lease.c   | 6 +++---
 drivers/gpu/drm/drm_mode_config.c | 4 ++--
 drivers/gpu/drm/drm_mode_object.c | 8 
 include/drm/drm_mode_config.h | 6 +++---
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 977f069f6d90..b2cbb58834bc 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -218,7 +218,7 @@ static struct drm_master *drm_lease_create(struct 
drm_master *lessor, struct idr
 
idr_for_each_entry(leases, entry, object) {
error = 0;
-   if (!idr_find(>mode_config.crtc_idr, object))
+   if (!idr_find(>mode_config.object_idr, object))
error = -ENOENT;
else if (!_drm_lease_held_master(lessor, object))
error = -EACCES;
@@ -434,7 +434,7 @@ static int fill_object_idr(struct drm_device *dev,
/*
 * We're using an IDR to hold the set of leased
 * objects, but we don't need to point at the object's
-* data structure from the lease as the main crtc_idr
+* data structure from the lease as the main object_idr
 * will be used to actually find that. Instead, all we
 * really want is a 'leased/not-leased' result, for
 * which any non-NULL pointer will work fine.
@@ -675,7 +675,7 @@ int drm_mode_get_lease_ioctl(struct drm_device *dev,
 
if (lessee->lessor == NULL)
/* owner can use all objects */
-   object_idr = >dev->mode_config.crtc_idr;
+   object_idr = >dev->mode_config.object_idr;
else
/* lessee can only use allowed object */
object_idr = >leases;
diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index ee80788f2c40..ab553b6465e2 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -381,7 +381,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(>mode_config.property_list);
INIT_LIST_HEAD(>mode_config.property_blob_list);
INIT_LIST_HEAD(>mode_config.plane_list);
-   idr_init(>mode_config.crtc_idr);
+   idr_init(>mode_config.object_idr);
idr_init(>mode_config.tile_idr);
ida_init(>mode_config.connector_ida);
spin_lock_init(>mode_config.connector_list_lock);
@@ -484,7 +484,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
 
ida_destroy(>mode_config.connector_ida);
idr_destroy(>mode_config.tile_idr);
-   idr_destroy(>mode_config.crtc_idr);
+   idr_destroy(>mode_config.object_idr);
drm_modeset_lock_fini(>mode_config.connection_mutex);
 }
 EXPORT_SYMBOL(drm_mode_config_cleanup);
diff --git a/drivers/gpu/drm/drm_mode_object.c 
b/drivers/gpu/drm/drm_mode_object.c
index cd9bc0ce9be0..bb1dd46496cd 100644
--- a/drivers/gpu/drm/drm_mode_object.c
+++ b/drivers/gpu/drm/drm_mode_object.c
@@ -38,7 +38,7 @@ int __drm_mode_object_add(struct drm_device *dev, struct 
drm_mode_object *obj,
int ret;
 
mutex_lock(>mode_config.idr_mutex);
-   ret = idr_alloc(>mode_config.crtc_idr, register_obj ? obj : NULL,
+   ret = idr_alloc(>mode_config.object_idr, register_obj ? obj : NULL,
1, 0, GFP_KERNEL);
if (ret >= 0) {
/*
@@ -79,7 +79,7 @@ void drm_mode_object_register(struct drm_device *dev,
  struct drm_mode_object *obj)
 {
mutex_lock(>mode_config.idr_mutex);
-   idr_replace(>mode_config.crtc_idr, obj, obj->id);
+   idr_replace(>mode_config.object_idr, obj, obj->id);
mutex_unlock(>mode_config.idr_mutex);
 }
 
@@ -99,7 +99,7 @@ void drm_mode_object_unregister(struct drm_device *dev,
 {
mutex_lock(>mode_config.idr_mutex);
if (object->id) {
-   idr_remove(>mode_config.crtc_idr, object->id);
+   idr_remove(>mode_config.object_idr, object->id);
object->id = 0;
}
mutex_unlock(>mode_config.idr_mutex);
@@ -131,7 +131,7 @@ struct drm_mode_object *__drm_mode_object_find(struct 
drm_device *dev,
struct drm_mode_object *obj = NULL;
 
mutex_lock(>mode_config.idr_mutex);
-   obj = idr_find(>mode_config.crtc_idr, id);
+   obj = idr_find(>mode_config.object_idr, id);
if (obj && type != DRM_MODE_OBJECT_ANY && obj->type != type)
obj = NULL;
if (obj && obj->id != id)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index d643d268693e..4750fccb5b4a 100644
--- 

Re: [PATCH 11/11] drm/msm/dpu: Clean up dpu_media_info.h static inline functions

2018-11-06 Thread Sam Ravnborg
Hi Jordan.

>   case COLOR_FMT_P010_UBWC:
> - alignment = 256;
> - stride = MSM_MEDIA_ALIGN(width * 2, alignment);
> + stride = MSM_MEDIA_ALIGN(width * 2, 256);
>   break;
>   case COLOR_FMT_P010:
> - alignment = 128;
> - stride = MSM_MEDIA_ALIGN(width*2, alignment);
> - break;
> - default:
> + stride = MSM_MEDIA_ALIGN(width*2, 128);

As you touch this line, could you please add spaces around '*'
Same goes for use of '/' in a few places.

I assume checkpatch would have told you to fix this.

With this fixed you can add my:
Acked-by: Sam Ravnborg 

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


[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=200695

Claude Heiland-Allen (cla...@mathr.co.uk) changed:

   What|Removed |Added

 Kernel Version|4.17.19, 4.18.0-rc7,|4.17.19, 4.18.0-rc7,
   |4.18.5, 4.18.6, 4.18.7, |4.18.5, 4.18.6, 4.18.7,
   |4.18.8, 4.18.9, 4.18.10,|4.18.8, 4.18.9, 4.18.10,
   |4.18.11, 4.18.12, 4.18.13,  |4.18.11, 4.18.12, 4.18.13,
   |4.18.14, 4.18.15, 4.18.16,  |4.18.14, 4.18.15, 4.18.16,
   |4.19-rc1, 4.19-rc2, |4.18.17, 4.19-rc1,
   |4.19-rc3, 4.19-rc4, |4.19-rc2, 4.19-rc3,
   |4.19-rc5, 4.19-rc6, |4.19-rc4, 4.19-rc5,
   |4.19-rc7, 4.19-rc8, 4.19|4.19-rc6, 4.19-rc7,
   ||4.19-rc8, 4.19, 4.19.1,
   ||4.20-rc1

--- Comment #18 from Claude Heiland-Allen (cla...@mathr.co.uk) ---
still an issue in 4.18.17
still an issue in 4.19.1
still an issue in 4.20-rc1 (configured with HSA enabled)

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


Re: [PATCH v3 2/2] drm/sun4i: tcon: prevent tcon->panel dereference if NULL

2018-11-06 Thread Maxime Ripard
On Mon, Nov 05, 2018 at 09:23:08PM +0800, Icenowy Zheng wrote:
> 在 2018-10-08一的 11:21 +0200,Maxime Ripard写道:
> > On Fri, Oct 05, 2018 at 11:59:51PM +0200, Giulio Benetti wrote:
> > > If tcon->panel pointer is NULL, trying to dereference from it
> > > (i.e. tcon->panel->connector) will cause a null pointer
> > > dereference.
> > > 
> > > Add tcon->panel null pointer check before calling
> > > sun4i_tcon0_mode_set_dithering().
> > > 
> > > Signed-off-by: Giulio Benetti 
> > > Fixes: f11adcecbd5f ("drm/sun4i: tcon: Add dithering support for
> > >   RGB565/RGB666 LCD panels")
> > > Reviewed-by: Chen-Yu Tsai 
> > 
> > Applied both, thanks!
> 
> Please bring them to 4.20.
> 
> Currently in 4.20-rc1, bridge support of sun4i-drm is broken because of
> this problem.

I've merged them in drm-misc-fixes, thanks!

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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


Re: [PATCH 02/10] drm/sun4i: sun6i_mipi_dsi: Support instruction loop selection

2018-11-06 Thread Maxime Ripard
On Mon, Nov 05, 2018 at 04:56:35PM +0530, Jagan Teki wrote:
> On Mon, Nov 5, 2018 at 4:09 PM Maxime Ripard  
> wrote:
> >
> > On Sat, Nov 03, 2018 at 03:38:52PM +0530, Jagan Teki wrote:
> > > Instruction loop selection would require before writing
> > > loop number registers, so enable idle, LP11 bits on
> > > loop selection register.
> > >
> > > Reference code available in BSP
> > > (in drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > > (dsi_dev[sel]->dsi_inst_loop_sel.dwval = 2<<(4*DSI_INST_ID_LP11) |
> > >   3<<(4*DSI_INST_ID_DLY);
> > >
> > > Signed-off-by: Jagan Teki 
> > > ---
> > >  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 4 
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c 
> > > b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > index da152c21ec62..077b57ec964c 100644
> > > --- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
> > > @@ -397,6 +397,10 @@ static void sun6i_dsi_setup_inst_loop(struct 
> > > sun6i_dsi *dsi,
> > >   struct mipi_dsi_device *device = dsi->device;
> > >   u16 delay;
> > >
> > > + regmap_write(dsi->regs, SUN6I_DSI_INST_LOOP_SEL_REG,
> > > +  DSI_INST_ID_HSC  << (4 * DSI_INST_ID_LP11) |
> > > +  DSI_INST_ID_HSD  << (4 * DSI_INST_ID_DLY));
> > > +
> >
> > Please put this with the other instructions settings below.
> 
> Does that mean after computation delay code?

Yes

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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


[PATCH][drm-next] drm/panel: s6d16d0: fix spelling mistake "enble" -> "enable"

2018-11-06 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in DRM_DEV_ERROR error message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c 
b/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
index fa8bfa7c492d..33c22ee036f8 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6d16d0.c
@@ -96,7 +96,7 @@ static int s6d16d0_prepare(struct drm_panel *panel)
ret = mipi_dsi_dcs_set_tear_on(dsi,
   MIPI_DSI_DCS_TEAR_MODE_VBLANK);
if (ret) {
-   DRM_DEV_ERROR(s6->dev, "failed to enble vblank TE (%d)\n",
+   DRM_DEV_ERROR(s6->dev, "failed to enable vblank TE (%d)\n",
  ret);
return ret;
}
-- 
2.19.1

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


[PATCH] drm: rcar-du: Fix external clock error checks

2018-11-06 Thread Laurent Pinchart
The rcar-du driver supports probe deferral for external clocks, but
implements it badly by checking the wrong pointer due to a bad copy and
paste. Fix it.

While at it, reject invalid clocks outright for DU channels that have a
display PLL, as the external clock is mandatory in that case. This
avoids a WARN_ON() at runtime.

Fixes: 1b30dbde8596 ("drm: rcar-du: Add support for external pixel clock")
Reported-by: Kuninori Morimoto 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index d18a342626b5..79021d7aa3ce 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -226,9 +226,6 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
 * system clock, and have no internal clock divider.
 */
 
-   if (WARN_ON(!rcrtc->extclock))
-   return;
-
/*
 * The H3 ES1.x exhibits dot clock duty cycle stability issues.
 * We can work around them by configuring the DPLL to twice the
@@ -1113,9 +1110,16 @@ int rcar_du_crtc_create(struct rcar_du_group *rgrp, 
unsigned int swindex,
clk = devm_clk_get(rcdu->dev, clk_name);
if (!IS_ERR(clk)) {
rcrtc->extclock = clk;
-   } else if (PTR_ERR(rcrtc->clock) == -EPROBE_DEFER) {
-   dev_info(rcdu->dev, "can't get external clock %u\n", hwindex);
+   } else if (PTR_ERR(clk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
+   } else if (rcdu->info->dpll_mask & BIT(hwindex)) {
+   /*
+* DU channels that have a display PLL can't use the internal
+* system clock and thus require an external clock.
+*/
+   ret = PTR_ERR(clk);
+   dev_err(rcdu->dev, "can't get dclkin.%u: %d\n", hwindex, ret);
+   return ret;
}
 
init_waitqueue_head(>flip_wait);
-- 
Regards,

Laurent Pinchart

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


[Bug 201625] Amd RX560D VERY slow after upgrade.

2018-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=201625

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your dmesg output, xorg log if using X, and glxinfo output.

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


Re: [Freedreno] [PATCH 11/11] drm/msm/dpu: Clean up dpu_media_info.h static inline functions

2018-11-06 Thread Sean Paul
On Mon, Nov 05, 2018 at 04:31:03PM -0700, Jordan Crouse wrote:
> Do some cleanup in the static inline functions defined in
> dpu_media_info.h by cleaning up gotos and unneeded local
> variables.
> 
> Signed-off-by: Jordan Crouse 
> ---
>  .../gpu/drm/msm/disp/dpu1/msm_media_info.h| 164 ++
>  1 file changed, 57 insertions(+), 107 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/msm_media_info.h 
> b/drivers/gpu/drm/msm/disp/dpu1/msm_media_info.h
> index 75470ee5b18f..8b8309f25c1a 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/msm_media_info.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/msm_media_info.h
> @@ -822,36 +822,30 @@ enum color_fmts {
>   */
>  static unsigned int VENUS_Y_STRIDE(int color_fmt, int width)
>  {
> - unsigned int alignment, stride = 0;
> + unsigned int stride = 0;
>  
>   if (!width)
> - goto invalid_input;
> + return 0;
>  
>   switch (color_fmt) {
>   case COLOR_FMT_NV21:
>   case COLOR_FMT_NV12:
>   case COLOR_FMT_NV12_MVTB:
>   case COLOR_FMT_NV12_UBWC:
> - alignment = 128;
> - stride = MSM_MEDIA_ALIGN(width, alignment);
> + stride = MSM_MEDIA_ALIGN(width, 128);
>   break;
>   case COLOR_FMT_NV12_BPP10_UBWC:
> - alignment = 256;
>   stride = MSM_MEDIA_ALIGN(width, 192);
> - stride = MSM_MEDIA_ALIGN(stride * 4/3, alignment);
> + stride = MSM_MEDIA_ALIGN(stride * 4/3, 256);

nit: Can you please surround the binary operators with spaces? This applies
everywhere in the patch.

With that,

Reviewed-by: Sean Paul 


>   break;
>   case COLOR_FMT_P010_UBWC:
> - alignment = 256;
> - stride = MSM_MEDIA_ALIGN(width * 2, alignment);
> + stride = MSM_MEDIA_ALIGN(width * 2, 256);
>   break;
>   case COLOR_FMT_P010:
> - alignment = 128;
> - stride = MSM_MEDIA_ALIGN(width*2, alignment);
> - break;
> - default:
> + stride = MSM_MEDIA_ALIGN(width * 2, 128);
>   break;
>   }
> -invalid_input:
> +
>   return stride;
>  }
>  
> @@ -864,36 +858,30 @@ static unsigned int VENUS_Y_STRIDE(int color_fmt, int 
> width)
>   */
>  static unsigned int VENUS_UV_STRIDE(int color_fmt, int width)
>  {
> - unsigned int alignment, stride = 0;
> + unsigned int stride = 0;
>  
>   if (!width)
> - goto invalid_input;
> + return 0;
>  
>   switch (color_fmt) {
>   case COLOR_FMT_NV21:
>   case COLOR_FMT_NV12:
>   case COLOR_FMT_NV12_MVTB:
>   case COLOR_FMT_NV12_UBWC:
> - alignment = 128;
> - stride = MSM_MEDIA_ALIGN(width, alignment);
> + stride = MSM_MEDIA_ALIGN(width, 128);
>   break;
>   case COLOR_FMT_NV12_BPP10_UBWC:
> - alignment = 256;
>   stride = MSM_MEDIA_ALIGN(width, 192);
> - stride = MSM_MEDIA_ALIGN(stride * 4/3, alignment);
> + stride = MSM_MEDIA_ALIGN(stride * 4/3, 256);
>   break;
>   case COLOR_FMT_P010_UBWC:
> - alignment = 256;
> - stride = MSM_MEDIA_ALIGN(width * 2, alignment);
> + stride = MSM_MEDIA_ALIGN(width * 2, 256);
>   break;
>   case COLOR_FMT_P010:
> - alignment = 128;
> - stride = MSM_MEDIA_ALIGN(width*2, alignment);
> - break;
> - default:
> + stride = MSM_MEDIA_ALIGN(width*2, 128);
>   break;
>   }
> -invalid_input:
> +
>   return stride;
>  }
>  
> @@ -906,10 +894,10 @@ static unsigned int VENUS_UV_STRIDE(int color_fmt, int 
> width)
>   */
>  static unsigned int VENUS_Y_SCANLINES(int color_fmt, int height)
>  {
> - unsigned int alignment, sclines = 0;
> + unsigned int sclines = 0;
>  
>   if (!height)
> - goto invalid_input;
> + return 0;
>  
>   switch (color_fmt) {
>   case COLOR_FMT_NV21:
> @@ -917,17 +905,14 @@ static unsigned int VENUS_Y_SCANLINES(int color_fmt, 
> int height)
>   case COLOR_FMT_NV12_MVTB:
>   case COLOR_FMT_NV12_UBWC:
>   case COLOR_FMT_P010:
> - alignment = 32;
> + sclines = MSM_MEDIA_ALIGN(height, 32);
>   break;
>   case COLOR_FMT_NV12_BPP10_UBWC:
>   case COLOR_FMT_P010_UBWC:
> - alignment = 16;
> + sclines = MSM_MEDIA_ALIGN(height, 16);
>   break;
> - default:
> - return 0;
>   }
> - sclines = MSM_MEDIA_ALIGN(height, alignment);
> -invalid_input:
> +
>   return sclines;
>  }
>  
> @@ -940,10 +925,10 @@ static unsigned int VENUS_Y_SCANLINES(int color_fmt, 
> int height)
>   */
>  static unsigned int VENUS_UV_SCANLINES(int color_fmt, int height)
>  {
> - unsigned int alignment, sclines = 0;
> + unsigned int sclines = 0;
>  
>   if (!height)
> - goto invalid_input;
> +

  1   2   >