Re: [Intel-gfx] [PATCH v6 3/3] drm/i915/hdcp: reuse rx_info for mst stream type1 capability check

2021-09-02 Thread Kandpal, Suraj
Hi ,

I have tested the patch 20856 against ci_drm_10499 and the patch 20921 against 
ci_drm_10537 kernel using the IGT kms_test_protection test on TGL platform with 
the following setups:

- HCDP2.2 Monitor connected to HDCP 2.2 Monitor

- HCDP2.2 Monitor connected to HDCP 1.4 Monitor

- HCDP1.4 Monitor connected to HDCP 1.4 Monitor

- HCDP2.2 Monitor standalone

- HDCP1.4 Monitor standalone
I did not see any delta between the Patchwork and CI_DRM kernel and all DP MST 
Scenarios seem to work fine. We can go ahead and merge this patch.

Tested-by: Suraj K 





-Original Message-
From: Gupta, Anshuman 
Sent: Thursday, September 2, 2021 6:40 PM
To: Li, Juston ; intel-gfx@lists.freedesktop.org; Kandpal, 
Suraj 
Cc: seanp...@chromium.org; C, Ramalingam ; Vivi, 
Rodrigo 
Subject: RE: [Intel-gfx] [PATCH v6 3/3] drm/i915/hdcp: reuse rx_info for mst 
stream type1 capability check







> -Original Message-

> From: Li, Juston mailto:juston...@intel.com>>

> Sent: Friday, August 20, 2021 12:19 AM

> To: intel-gfx@lists.freedesktop.org<mailto:intel-gfx@lists.freedesktop.org>

> Cc: seanp...@chromium.org<mailto:seanp...@chromium.org>; Gupta, Anshuman 
> mailto:anshuman.gu...@intel.com>>;

> C, Ramalingam mailto:ramalinga...@intel.com>>; Vivi, 
> Rodrigo

> mailto:rodrigo.v...@intel.com>>; Li, Juston 
> mailto:juston...@intel.com>>

> Subject: [Intel-gfx] [PATCH v6 3/3] drm/i915/hdcp: reuse rx_info for

> mst stream

> type1 capability check

>

> On some MST docking stations, rx_info can only be read after

> RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set

> otherwise the read will return -EIO.

>

> This behavior causes the mst stream type1 capability test to fail to

> read rx_info and determine if the topology supports type1 and fallback to 
> type0.

>

> To fix this, check for type1 capability when we receive rx_info within

> the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead of

> an explicit read just for type1 capability checking.

>

> This does require moving where we set stream_types to after

> hdcp2_authenticate_sink() when we get rx_info but this occurs before

> we do hdcp2_propagate_stream_management_info.

>

> Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for

> that as well.

>

> Changes since v5:

>  - rename intel_set_stream_types() to intel_hdcp_prepare_streams()

>(Anshuman)

>

> Changes since v4:

>  - move topology_type1_capable to intel_digital_port and rename it as

>hdcp_mst_type1_capable (Anshuman)

>  - make a helper function intel_set_stream_types() to set stream types

>in hdcp2_authenticate_and_encrypt() (Anshuman)

>  - break on failure to set stream types and retry instead of returning

>  - remove no longer used declaration for streams_type1_capable()

>

> Changes since v2:

>  - Remove no longer used variables in _intel_hdcp2_enable()

>

> Signed-off-by: Juston Li mailto:juston...@intel.com>>

> Reviewed-by: Ramalingam C 
> mailto:ramalinga...@intel.com>>

> Reviewed-by: Anshuman Gupta 
> mailto:anshuman.gu...@intel.com>>

Adding Suraj to this thread.

> ---

>  .../drm/i915/display/intel_display_types.h|  6 +-

>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c  | 39 ---

>  drivers/gpu/drm/i915/display/intel_hdcp.c | 64 +++

>  3 files changed, 38 insertions(+), 71 deletions(-)

>

> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h

> b/drivers/gpu/drm/i915/display/intel_display_types.h

> index 6bba1bed..34e90a841280 100644

> --- a/drivers/gpu/drm/i915/display/intel_display_types.h

> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h

> @@ -428,10 +428,6 @@ struct intel_hdcp_shim {  int

> (*hdcp_2_2_capable)(struct intel_digital_port *dig_port,  bool

> *capable);

>

> -/* Detects whether a HDCP 1.4 sink connected in MST topology */ -int

> (*streams_type1_capable)(struct intel_connector *connector,

> - bool *capable);

> -

>  /* Write HDCP2.2 messages */

>  int (*write_2_2_msg)(struct intel_digital_port *dig_port,

>   void *buf, size_t size);

> @@ -1684,6 +1680,8 @@ struct intel_digital_port {  bool

> hdcp_auth_status;

>  /* HDCP port data need to pass to security f/w */  struct

> hdcp_port_data hdcp_port_data;

> +/* Whether the MST topology supports HDCP Type 1 Content */ bool

> +hdcp_mst_type1_capable;

>

>  void (*write_infoframe)(struct intel_encoder *encoder,  const struct

> intel_crtc_state *crtc_state, diff -- git

> a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c

> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c

> index fbfb3c4d16bb..540a669e01dd 100644

> --- a/drivers/gpu/drm/

Re: [Intel-gfx] [PATCH v6 1/3] drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()

2021-09-02 Thread Kandpal, Suraj
Hi ,

I have tested the patch 20856 against ci_drm_10499 and the patch 20921 against 
ci_drm_10537 kernel using the IGT kms_test_protection test on TGL platform with 
the following setups:
- HCDP2.2 Monitor connected to HDCP 2.2 Monitor
- HCDP2.2 Monitor connected to HDCP 1.4 Monitor
- HCDP1.4 Monitor connected to HDCP 1.4 Monitor
- HCDP2.2 Monitor standalone
- HDCP1.4 Monitor standalone 

I did not see any delta between the Patchwork and CI_DRM kernel and all DP MST 
Scenarios seem to work fine. We can go ahead and merge this patch.

 
Tested-by: Suraj K 

-Original Message-
From: Gupta, Anshuman  
Sent: Thursday, September 2, 2021 6:38 PM
To: Li, Juston ; intel-gfx@lists.freedesktop.org; Kandpal, 
Suraj 
Cc: seanp...@chromium.org; C, Ramalingam ; Vivi, 
Rodrigo 
Subject: RE: [Intel-gfx] [PATCH v6 1/3] drm/i915/hdcp: update 
cp_irq_count_cached in intel_dp_hdcp2_read_msg()



> -Original Message-
> From: Li, Juston 
> Sent: Friday, August 20, 2021 12:19 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanp...@chromium.org; Gupta, Anshuman ; 
> C, Ramalingam ; Vivi, Rodrigo 
> ; Li, Juston 
> Subject: [Intel-gfx] [PATCH v6 1/3] drm/i915/hdcp: update 
> cp_irq_count_cached in intel_dp_hdcp2_read_msg()
> 
> Update cp_irq_count_cached when reading messages rather than when 
> writing a message to make sure the value is up to date and not stale 
> from a previously handled CP_IRQ.
> 
> AKE flow  doesn't always respond to a read with a ACK write msg.
> E.g. AKE_Send_Pairing_Info will "timeout" because we received a CP_IRQ 
> for reading AKE_Send_H_Prime but no write occurred between that and 
> reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale causing 
> the wait to return right away rather than waiting for a new CP_IRQ.
> 
> Signed-off-by: Juston Li 
> Acked-by: Anshuman Gupta 
> Reviewed-by: Ramalingam C 
Hi Suraj,
We don't have HDCP coverage in CI
Could you please provide your Tested-By tag after testing this patch series.
Br,
Anshuman 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index d697d169e8c1..1d0096654776 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -446,8 +446,6 @@ static
>  int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
>   void *buf, size_t size)
>  {
> -struct intel_dp *dp = _port->dp;
> -struct intel_hdcp *hdcp = >attached_connector->hdcp;  unsigned 
> int offset;
>  u8 *byte = buf;
>  ssize_t ret, bytes_to_write, len;
> @@ -463,8 +461,6 @@ int intel_dp_hdcp2_write_msg(struct 
> intel_digital_port *dig_port,  bytes_to_write = size - 1;  byte++;
> 
> -hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
> -
>  while (bytes_to_write) {
>  len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
>  DP_AUX_MAX_PAYLOAD_BYTES :
> bytes_to_write; @@ -530,6 +526,8 @@ int intel_dp_hdcp2_read_msg(struct 
> intel_digital_port *dig_port,
>  u8 msg_id, void *buf, size_t size)  {  struct drm_i915_private 
> *i915 = to_i915(dig_port->base.base.dev);
> +struct intel_dp *dp = _port->dp;
> +struct intel_hdcp *hdcp = >attached_connector->hdcp;
>  unsigned int offset;
>  u8 *byte = buf;
>  ssize_t ret, bytes_to_recv, len;
> @@ -546,6 +544,8 @@ int intel_dp_hdcp2_read_msg(struct 
> intel_digital_port *dig_port,  if (ret < 0)  return ret;
> 
> +hdcp->cp_irq_count_cached = atomic_read(>cp_irq_count);
> +
>  if (msg_id == HDCP_2_2_REP_SEND_RECVID_LIST) {  ret = 
> get_receiver_id_list_size(dig_port);
>  if (ret < 0)
> --
> 2.31.1




Re: [Intel-gfx] [PATCH v6 2/3] drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_List

2021-09-02 Thread Kandpal, Suraj
Hi ,

I have tested the patch 20856 against ci_drm_10499 and the patch 20921 against 
ci_drm_10537 kernel using the IGT kms_test_protection test on TGL platform with 
the following setups:
- HCDP2.2 Monitor connected to HDCP 2.2 Monitor
- HCDP2.2 Monitor connected to HDCP 1.4 Monitor
- HCDP1.4 Monitor connected to HDCP 1.4 Monitor
- HCDP2.2 Monitor standalone
- HDCP1.4 Monitor standalone 

I did not see any delta between the Patchwork and CI_DRM kernel and all DP MST 
Scenarios seem to work fine. We can go ahead and merge this patch.

 

Tested-by: Suraj K 

-Original Message-
From: Gupta, Anshuman  
Sent: Thursday, September 2, 2021 6:39 PM
To: Li, Juston ; intel-gfx@lists.freedesktop.org; Kandpal, 
Suraj 
Cc: seanp...@chromium.org; C, Ramalingam ; Vivi, 
Rodrigo 
Subject: RE: [Intel-gfx] [PATCH v6 2/3] drm/i915/hdcp: read RxInfo once when 
reading RepeaterAuth_Send_ReceiverID_List



> -Original Message-
> From: Li, Juston 
> Sent: Friday, August 20, 2021 12:19 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: seanp...@chromium.org; Gupta, Anshuman ; 
> C, Ramalingam ; Vivi, Rodrigo 
> ; Li, Juston 
> Subject: [Intel-gfx] [PATCH v6 2/3] drm/i915/hdcp: read RxInfo once 
> when reading RepeaterAuth_Send_ReceiverID_List
> 
> When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by 
> itself once to retrieve the DEVICE_COUNT to calculate the size of the 
> ReceiverID list then read a second time as a part of reading ReceiverID list.
> 
> On some MST docking stations, RxInfo can only be read after the 
> RxStatus READY bit is set otherwise the read will return -EIO. The 
> spec states that the READY bit should be cleared as soon as RxInfo has been 
> read.
> 
> In this case, the first RxInfo read succeeds but after the READY bit 
> is cleared, the second read fails.
> 
> Fix it by reading RxInfo once and storing it before reading the rest 
> of RepeaterAuth_Send_ReceiverID_List once we know the size.
> 
> Modify get_receiver_id_list_size() to read and store RxInfo in the 
> message buffer and also parse DEVICE_COUNT so we know the size of 
> RepeaterAuth_Send_ReceiverID_List.
> 
> Afterwards, retrieve the rest of the message at the offset for seq_num_V.
> 
> Changes in v5:
> - Don't change the offset define for Send_ReceiverID_List
>   When reading, update message offset to account for RxInfo being read
> 
> Changes in v4:
> - rebase and edit commit message
> 
> Changes in v3:
> - remove comment
> 
> Changes in v2:
> - remove unnecessary moving of drm_i915_private from patch 1
> 
> Signed-off-by: Juston Li 
> Reviewed-by: Ramalingam C 
> Reviewed-by: Anshuman Gupta 
Adding Suraj to this thread.
> ---
>  drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 31 
> ++--
>  1 file changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> index 1d0096654776..fbfb3c4d16bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
> @@ -496,11 +496,10 @@ get_rxinfo_hdcp_1_dev_downstream(struct
> intel_digital_port *dig_port, bool *hdcp  }
> 
>  static
> -ssize_t get_receiver_id_list_size(struct intel_digital_port 
> *dig_port)
> +ssize_t get_receiver_id_list_rx_info(struct intel_digital_port 
> +*dig_port, u32 *dev_cnt, u8 *byte)
>  {
> -u8 rx_info[HDCP_2_2_RXINFO_LEN];
> -u32 dev_cnt;
>  ssize_t ret;
> +u8 *rx_info = byte;
> 
>  ret = drm_dp_dpcd_read(_port->dp.aux,
> DP_HDCP_2_2_REG_RXINFO_OFFSET, @@ -508,15
> +507,11 @@ ssize_t get_receiver_id_list_size(struct intel_digital_port
> *dig_port)
>  if (ret != HDCP_2_2_RXINFO_LEN)
>  return ret >= 0 ? -EIO : ret;
> 
> -dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> +*dev_cnt = (HDCP_2_2_DEV_COUNT_HI(rx_info[0]) << 4 |
> HDCP_2_2_DEV_COUNT_LO(rx_info[1]));
> 
> -if (dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT) -dev_cnt = 
> HDCP_2_2_MAX_DEVICE_COUNT;
> -
> -ret = sizeof(struct hdcp2_rep_send_receiverid_list) - 
> -HDCP_2_2_RECEIVER_IDS_MAX_LEN + -(dev_cnt * 
> HDCP_2_2_RECEIVER_ID_LEN);
> +if (*dev_cnt > HDCP_2_2_MAX_DEVICE_COUNT) *dev_cnt = 
> +HDCP_2_2_MAX_DEVICE_COUNT;
> 
>  return ret;
>  }
> @@ -534,6 +529,7 @@ int intel_dp_hdcp2_read_msg(struct 
> intel_digital_port *dig_port,  const struct hdcp2_dp_msg_data 
> *hdcp2_msg_data;  ktime_t msg_end = ktime_set(0, 0);  bool 
> msg_expired;
> +u32 dev_cnt;
> 
>  hdcp2_msg_data = get_hdcp2_dp_msg_data(msg_id);  if (!hdcp2_msg_data) 
> @@ -546,17 +542,22 @@ int intel_dp_hdcp2_read_msg(struct 
> intel_digital_port *dig_port,
> 
>  hdcp->cp_irq_count_cached = atomic_read(>cp_irq_cou

[Intel-gfx] [PATCH 3/4] drm/i915: Define WD trancoder for i915

2021-12-16 Thread Kandpal, Suraj
From: suraj kandpal 

Adding WD Types, WD transcoder to enum list and WD Transcoder offsets

Signed-off-by: suraj kandpal 
---
 drivers/gpu/drm/i915/display/intel_display.h   | 6 ++
 drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
 drivers/gpu/drm/i915/i915_reg.h| 2 ++
 3 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_display.h 
b/drivers/gpu/drm/i915/display/intel_display.h
index d425ee77aad7..76f999525d43 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -117,6 +117,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+   TRANSCODER_WD_0,
+   TRANSCODER_WD_1,
 
I915_MAX_TRANSCODERS
 };
@@ -138,6 +140,10 @@ static inline const char *transcoder_name(enum transcoder 
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+   case TRANSCODER_WD_0:
+   return "WD 0";
+   case TRANSCODER_WD_1:
+   return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h 
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 9413ebae15f5..f20086280d7e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -69,6 +69,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+   INTEL_OUTPUT_WD = 12,
 };
 
 enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ef594df039db..b8e42c55ff87 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4431,6 +4431,8 @@ enum {
 #define TRANSCODER_EDP_OFFSET 0x6f000
 #define TRANSCODER_DSI0_OFFSET 0x6b000
 #define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET  0x6e000
+#define TRANSCODER_WD1_OFFSET  0x6e800
 
 #define HTOTAL(trans)  _MMIO_TRANS2(trans, _HTOTAL_A)
 #define HBLANK(trans)  _MMIO_TRANS2(trans, _HBLANK_A)
-- 
2.17.1



[Intel-gfx] [PATCH 4/4] drm/i915: Enabling WD Transcoder

2021-12-16 Thread Kandpal, Suraj
From: suraj kandpal 

Adding support for writeback transcoder to start capturing frames using
interrupt mechanism

Signed-off-by: suraj kandpal 
---
 drivers/gpu/drm/i915/Makefile |2 +
 drivers/gpu/drm/i915/display/intel_acpi.c |1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  166 ++-
 drivers/gpu/drm/i915/display/intel_display.h  |5 +
 .../drm/i915/display/intel_display_power.h|1 +
 .../drm/i915/display/intel_display_types.h|8 +
 drivers/gpu/drm/i915/display/intel_dpll.c |6 +
 drivers/gpu/drm/i915/display/intel_opregion.c |3 +
 .../gpu/drm/i915/display/intel_wb_connector.h |   20 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 1139 +
 drivers/gpu/drm/i915/display/intel_wd.h   |   70 +
 .../drm/i915/display/skl_universal_plane.c|1 -
 drivers/gpu/drm/i915/i915_drv.h   |5 +
 drivers/gpu/drm/i915/i915_irq.c   |8 +-
 drivers/gpu/drm/i915/i915_pci.c   |7 +-
 drivers/gpu/drm/i915/i915_reg.h   |  139 +-
 16 files changed, 1527 insertions(+), 54 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 5c8e022a7383..5472bb48196b 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -206,6 +206,7 @@ i915-y += \
display/intel_connector.o \
display/intel_crtc.o \
display/intel_cursor.o \
+   display/intel_wd.o \
display/intel_display.o \
display/intel_display_power.o \
display/intel_dmc.o \
@@ -276,6 +277,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+   display/intel_wd.o \
display/vlv_dsi.o \
display/vlv_dsi_pll.o
 
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c 
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 72cac55c0f0f..98537c7de20c 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -244,6 +244,7 @@ static u32 acpi_display_type(struct intel_connector 
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+   case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index f27c294beb92..4a9e5972f381 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -105,6 +105,7 @@
 #include "intel_tc.h"
 #include "intel_vga.h"
 #include "i9xx_plane.h"
+#include "intel_wd.h"
 #include "skl_scaler.h"
 #include "skl_universal_plane.h"
 
@@ -195,10 +196,13 @@ skl_wa_827(struct drm_i915_private *dev_priv, enum pipe 
pipe, bool enable)
 {
if (enable)
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
DUPS1_GATING_DIS | DUPS2_GATING_DIS);
+   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
+   DUPS1_GATING_DIS |
+   DUPS2_GATING_DIS);
else
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
+   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
+   ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
 }
 
 /* Wa_2006604312:icl,ehl */
@@ -208,10 +212,10 @@ icl_wa_scalerclkgating(struct drm_i915_private *dev_priv, 
enum pipe pipe,
 {
if (enable)
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
DPFR_GATING_DIS);
+  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) | 
DPFR_GATING_DIS);
else
intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
-  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~DPFR_GATING_DIS);
+  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) & 
~DPFR_GATING_DIS);
 }
 
 static bool
@@ -342,6 +346,7 @@ static void assert_fdi_tx(struct drm_i915_private *dev_priv,
cur_state = !!(val & TRANS_DDI_FUNC_ENABLE);
} else {
u32 val = intel_de_read(dev_priv, FDI_TX_CTL(pipe));
+
cur_state = !!(val & FDI_TX_ENABLE);
}
I915_STATE_WARN(cur_state != state,
@@ -469,6 +474,7 @@ void assert_transcoder(struct drm_i915_private *dev_priv,
wakeref = intel_display_power_get_if_enabled(dev_priv, 

[Intel-gfx] [PATCH 0/4] Adding writeback support for i915

2021-12-16 Thread Kandpal, Suraj
The following series of patches add writeback support for i915. This has been 
validated on TGL using IGT.

Note:Only a single instance of WD transcoder is being considered for now, using
multiple WD transcoder may not work. The support for the same will be added in 
next
set of patches.

suraj kandpal (4):
  drm: add writeback pointers to drm_connector
  drm/komeda: change driver to use drm_writeback_connector.base pointer
  drm/i915: Define WD trancoder for i915
  drm/i915: Enabling WD Transcoder

 .../gpu/drm/arm/display/komeda/komeda_crtc.c  |2 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |3 +-
 .../arm/display/komeda/komeda_wb_connector.c  |9 +-
 drivers/gpu/drm/drm_writeback.c   |   19 +-
 drivers/gpu/drm/i915/Makefile |2 +
 drivers/gpu/drm/i915/display/intel_acpi.c |1 +
 drivers/gpu/drm/i915/display/intel_display.c  |  166 ++-
 drivers/gpu/drm/i915/display/intel_display.h  |   11 +
 .../drm/i915/display/intel_display_power.h|1 +
 .../drm/i915/display/intel_display_types.h|9 +
 drivers/gpu/drm/i915/display/intel_dpll.c |6 +
 drivers/gpu/drm/i915/display/intel_opregion.c |3 +
 .../gpu/drm/i915/display/intel_wb_connector.h |   20 +
 drivers/gpu/drm/i915/display/intel_wd.c   | 1139 +
 drivers/gpu/drm/i915/display/intel_wd.h   |   70 +
 .../drm/i915/display/skl_universal_plane.c|1 -
 drivers/gpu/drm/i915/i915_drv.h   |5 +
 drivers/gpu/drm/i915/i915_irq.c   |8 +-
 drivers/gpu/drm/i915/i915_pci.c   |7 +-
 drivers/gpu/drm/i915/i915_reg.h   |  141 +-
 include/drm/drm_connector.h   |3 +
 include/drm/drm_writeback.h   |6 +-
 22 files changed, 1560 insertions(+), 72 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
 create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h

-- 
2.17.1



[Intel-gfx] [PATCH 1/4] drm: add writeback pointers to drm_connector

2021-12-16 Thread Kandpal, Suraj
From: suraj kandpal 

Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector
Adding drm_connector and drm_encoder pointers in drm_writeback_connector

Signed-off-by: suraj kandpal 
---
 drivers/gpu/drm/drm_writeback.c | 19 ++-
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_writeback.h |  6 +++---
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct 
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
 
-   return wb_connector->base.dev->driver->name;
+   return wb_connector->base->dev->driver->name;
 }
 
 static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 const u32 *formats, int n_formats)
 {
struct drm_property_blob *blob;
-   struct drm_connector *connector = _connector->base;
+   struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = >mode_config;
int ret = create_writeback_properties(dev);
 
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
 
-   drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
-   ret = drm_encoder_init(dev, _connector->encoder,
+   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+   ret = drm_encoder_init(dev, wb_connector->encoder,
   _writeback_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
 
connector->interlace_allowed = 0;
+   connector->wb_connector = wb_connector;
 
ret = drm_connector_init(dev, connector, con_funcs,
 DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
 
ret = drm_connector_attach_encoder(connector,
-   _connector->encoder);
+   wb_connector->encoder);
if (ret)
goto attach_fail;
 
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 attach_fail:
drm_connector_cleanup(connector);
 connector_fail:
-   drm_encoder_cleanup(_connector->encoder);
+   drm_encoder_cleanup(wb_connector->encoder);
 fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.helper_private;
+   connector->base->helper_private;
int ret;
 
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job 
*job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.helper_private;
+   connector->base->helper_private;
 
if (job->prepared && funcs->cleanup_writeback_job)
funcs->cleanup_writeback_job(connector, job);
@@ -401,7 +402,7 @@ drm_writeback_get_out_fence(struct drm_writeback_connector 
*wb_connector)
 {
struct dma_fence *fence;
 
-   if (WARN_ON(wb_connector->base.connector_type !=
+   if (WARN_ON(wb_connector->base->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK))
return NULL;
 
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 379746d3266f..ec049b1bc4bb 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -42,6 +42,7 @@ struct drm_property_blob;
 struct drm_printer;
 struct edid;
 struct i2c_adapter;
+struct drm_writeback_connector;
 
 enum drm_connector_force {
DRM_FORCE_UNSPECIFIED,
@@ -1483,6 +1484,8 @@ struct drm_connector {
 */
struct drm_encoder *encoder;
 
+   struct drm_writeback_connector *wb_connector;
+
 #define MAX_ELD_BYTES  128
/** @eld: EDID-like data, if present */
uint8_t eld[MAX_ELD_BYTES];
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 9697d2714d2a..078c9907219c 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -22,7 +22,7 @@ struct drm_writeback_connector {
/**
 * @base: base drm_connector object
 */
-   struct drm_connector base;
+   struct drm_connector *base;
 
 

[Intel-gfx] [PATCH 2/4] drm/komeda: change driver to use drm_writeback_connector.base pointer

2021-12-16 Thread Kandpal, Suraj
From: suraj kandpal 

Changing driver to use drm_writeback_connector.base pointer

Signed-off-by: suraj kandpal 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h  | 3 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 9 +
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
 
-   conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+   conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
  * struct komeda_wb_connector
  */
 struct komeda_wb_connector {
+   struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;
 
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
 static inline bool is_writeback_only(struct drm_crtc_state *st)
 {
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
-   struct drm_connector *conn = wb_conn ? _conn->base.base : NULL;
+   struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
 
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
 }
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..0caaf483276d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
-   wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+   wb_layer = 
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
 
/*
 * No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector 
*connector,
 static void komeda_wb_connector_destroy(struct drm_connector *connector)
 {
drm_connector_cleanup(connector);
-   kfree(to_kconn(to_wb_conn(connector)));
+   kfree(to_kconn(drm_connector_to_writeback(connector)));
 }
 
 static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,6 +155,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
 
wb_conn = _conn->base;
+   wb_conn->base = _conn->conn;
wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(>base));
 
formats = komeda_get_layer_fourcc_list(>fmt_tbl,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
return err;
}
 
-   drm_connector_helper_add(_conn->base, _wb_conn_helper_funcs);
+   drm_connector_helper_add(wb_conn->base, _wb_conn_helper_funcs);
 
-   info = _conn->base.base.display_info;
+   info = _conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
 
-- 
2.17.1



Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enabling WD Transcoder

2022-01-06 Thread Kandpal, Suraj
> > Adding support for writeback transcoder to start capturing frames using
> > interrupt mechanism
> 
> I stopped reviewing this after a while, because there's just way too
> much unrelated noise in the patch to even be able to focus on what's
> actually being done functionally here. There are some comments inline
> before I stopped.
> 
> Please don't do random superfluous whitespace or checkpatch changes in
> the same patch. It's just a distraction.
> 
> Functionally the most questionable thing I spotted is adding the
> intel_crtc and intel_wd pointer members in struct
> drm_i915_private. That's not the kind of design we'll want. It should
> all be in the atomic state.

Will remove the checkpatch changes from this and reduce the noise
> 
> Also, what is this in intel_wd.c:
> 
> > +static const struct drm_display_mode drm_dmt_modes[] = {
> 
> Please no.
> 
This will be removed in the next series of patches
> 
> BR,
> Jani.
> 
> 
> 
> > diff --git a/drivers/gpu/drm/i915/Makefile
> b/drivers/gpu/drm/i915/Makefile
> > index 5c8e022a7383..5472bb48196b 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -206,6 +206,7 @@ i915-y += \
> > display/intel_connector.o \
> > display/intel_crtc.o \
> > display/intel_cursor.o \
> > +   display/intel_wd.o \
> 
> Adding it twice?
Typo will remove it
> 
> > display/intel_display.o \
> > display/intel_display_power.o \
> > display/intel_dmc.o \
> > @@ -276,6 +277,7 @@ i915-y += \
> > display/intel_tv.o \
> > display/intel_vdsc.o \
> > display/intel_vrr.o \
> > +   display/intel_wd.o \
> > display/vlv_dsi.o \
> > display/vlv_dsi_pll.o
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> > index 72cac55c0f0f..98537c7de20c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> > @@ -244,6 +244,7 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
> > case DRM_MODE_CONNECTOR_LVDS:
> > case DRM_MODE_CONNECTOR_eDP:
> > case DRM_MODE_CONNECTOR_DSI:
> > +   case DRM_MODE_CONNECTOR_WRITEBACK:
> > display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
> > break;
> > case DRM_MODE_CONNECTOR_Unknown:
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> > index f27c294beb92..4a9e5972f381 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -105,6 +105,7 @@
> >  #include "intel_tc.h"
> >  #include "intel_vga.h"
> >  #include "i9xx_plane.h"
> > +#include "intel_wd.h"
> 
> Please keep include lists sorted.
Noted will change the order
> 
> >  #include "skl_scaler.h"
> >  #include "skl_universal_plane.h"
> >
> > @@ -195,10 +196,13 @@ skl_wa_827(struct drm_i915_private *dev_priv,
> enum pipe pipe, bool enable)
> >  {
> > if (enable)
> > intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> > -  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> DUPS1_GATING_DIS | DUPS2_GATING_DIS);
> > +   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> > +   DUPS1_GATING_DIS |
> > +   DUPS2_GATING_DIS);
> > else
> > intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> > -  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> > +   intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> > +   ~(DUPS1_GATING_DIS | DUPS2_GATING_DIS));
> >  }
> 
> Superfluous changes that should not be part of this patch.
> 
> >
> >  /* Wa_2006604312:icl,ehl */
> > @@ -208,10 +212,10 @@ icl_wa_scalerclkgating(struct drm_i915_private
> *dev_priv, enum pipe pipe,
> >  {
> > if (enable)
> > intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> > -  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) |
> DPFR_GATING_DIS);
> > +  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe))
> | DPFR_GATING_DIS);
> > else
> > intel_de_write(dev_priv, CLKGATE_DIS_PSL(pipe),
> > -  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe)) &
> ~DPFR_GATING_DIS);
> > +  intel_de_read(dev_priv, CLKGATE_DIS_PSL(pipe))
> & ~DPFR_GATING_DIS);
> >  }
> >
> >  static bool
> > @@ -342,6 +346,7 @@ static void assert_fdi_tx(struct drm_i915_private
> *dev_priv,
> > cur_state = !!(val & TRANS_DDI_FUNC_ENABLE);
> > } else {
> > u32 val = intel_de_read(dev_priv, FDI_TX_CTL(pipe));
> > +
> > cur_state = !!(val & FDI_TX_ENABLE);
> > }
> > I915_STATE_WARN(cur_state != state,
> > @@ -469,6 +474,7 @@ void assert_transcoder(struct drm_i915_private
> *dev_priv,
> > wakeref = intel_display_power_get_if_enabled(dev_priv,
> power_domain);
> > if 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Define WD trancoder for i915

2022-01-06 Thread Kandpal, Suraj
> > Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
> 
> This should be part of the patch that uses them.
Got it will squash this patch with the one using the above

Thanks,
Suraj Kandpal
> 
> BR,
> Jani.



Re: [Intel-gfx] [PATCH 1/4] drm: add writeback pointers to drm_connector

2022-01-06 Thread Kandpal, Suraj
> > Adding drm_connector and drm_encoder pointers in
> > drm_writeback_connector
> 
> Why?

The elements of struct drm_writeback_connector are 
struct drm_writeback_connector {
Struct drm_connector base;
Struct drm_encoder encoder;

Similarly the elements of intel_encoder and intel_connector are
 struct intel_encoder {
Struct drm_encoder base;

Struct intel_connector {
Struct drm_connector base;

The function drm_writeback_connector_init() will initialize the drm_connector 
and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in drm_writeback_connector and 
intel_connector/encoder, one of them should be a pointer, else both will be 
pointing to 2 separate instances.

Usually the struct defined in drm framework pointing to any struct will be 
pointer and allocating them and initialization will be done with the users.
Like struct drm_connector and drm_encoder are part of drm framework and the 
users of these such as i915 have included them in their struct intel_connector 
and intel_encoder. 
Likewise struct drm_writeback_connector is a special connector and hence is not 
a user of drm_connector and hence this should be pointers.
> 
> We can all read the code, the commit message should mostly be about the
> *why*.
> 
> Also, drm changes should Cc: dri-devel mailing list.
Sure we will add this in Cc in the next series of patches

Thanks,
Suraj Kandpal


Re: [Intel-gfx] [PATCH 2/4] drm/komeda: change driver to use drm_writeback_connector.base pointer

2022-01-06 Thread Kandpal, Suraj
> Every commit should build and work on its own, so this makes me believe
> the previous patch breaks the build.
> 
Sure Jani will address this in the next set of patches 

Thanks,
Suraj Kandpal


[Intel-gfx] [PATCH 3/3] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer

2022-01-11 Thread Kandpal, Suraj
Changing vkms driver to accomadate the change of
drm_writeback_connector.base to a pointer the reason for which is
explained in the Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal, Suraj 
---
 drivers/gpu/drm/vkms/vkms_writeback.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c 
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..6de0c4213425 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct drm_connector 
*conn,
struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn->dev);
struct vkms_output *output = >output;
struct drm_writeback_connector *wb_conn = >wb_connector;
-   struct drm_connector_state *conn_state = wb_conn->base.state;
+   struct drm_connector_state *conn_state = wb_conn->base->state;
struct vkms_crtc_state *crtc_state = output->composer_state;
 
if (!conn_state)
@@ -140,8 +140,8 @@ int vkms_enable_writeback_connector(struct vkms_device 
*vkmsdev)
 {
struct drm_writeback_connector *wb = >output.wb_connector;
 
-   vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
-   drm_connector_helper_add(>base, _wb_conn_helper_funcs);
+   vkmsdev->output.wb_connector.encoder->possible_crtcs = 1;
+   drm_connector_helper_add(wb->base, _wb_conn_helper_funcs);
 
return drm_writeback_connector_init(>drm, wb,
_wb_connector_funcs,
-- 
2.17.1



[Intel-gfx] [PATCH 2/3] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer

2022-01-11 Thread Kandpal, Suraj
Making changes to komeda driver because we had to change
drm_writeback_connector.base into a pointer the reason for which is
expained in the Patch (drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal, Suraj 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h  | 3 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c | 9 +
 3 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
 
-   conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+   conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
  * struct komeda_wb_connector
  */
 struct komeda_wb_connector {
+   struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;
 
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
 static inline bool is_writeback_only(struct drm_crtc_state *st)
 {
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
-   struct drm_connector *conn = wb_conn ? _conn->base.base : NULL;
+   struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
 
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
 }
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..0caaf483276d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
-   wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+   wb_layer = 
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
 
/*
 * No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector 
*connector,
 static void komeda_wb_connector_destroy(struct drm_connector *connector)
 {
drm_connector_cleanup(connector);
-   kfree(to_kconn(to_wb_conn(connector)));
+   kfree(to_kconn(drm_connector_to_writeback(connector)));
 }
 
 static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,6 +155,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
 
wb_conn = _conn->base;
+   wb_conn->base = _conn->conn;
wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(>base));
 
formats = komeda_get_layer_fourcc_list(>fmt_tbl,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
return err;
}
 
-   drm_connector_helper_add(_conn->base, _wb_conn_helper_funcs);
+   drm_connector_helper_add(wb_conn->base, _wb_conn_helper_funcs);
 
-   info = _conn->base.base.display_info;
+   info = _conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
 
-- 
2.17.1



[Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector

2022-01-11 Thread Kandpal, Suraj
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;

struct intel_connector {
struct drm_connector base;

The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.

Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.

Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.

Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.

Signed-off-by: Kandpal, Suraj 
---
 drivers/gpu/drm/drm_writeback.c | 19 ++-
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_writeback.h |  6 +++---
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct 
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
 
-   return wb_connector->base.dev->driver->name;
+   return wb_connector->base->dev->driver->name;
 }
 
 static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 const u32 *formats, int n_formats)
 {
struct drm_property_blob *blob;
-   struct drm_connector *connector = _connector->base;
+   struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = >mode_config;
int ret = create_writeback_properties(dev);
 
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
 
-   drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
-   ret = drm_encoder_init(dev, _connector->encoder,
+   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+   ret = drm_encoder_init(dev, wb_connector->encoder,
   _writeback_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
 
connector->interlace_allowed = 0;
+   connector->wb_connector = wb_connector;
 
ret = drm_connector_init(dev, connector, con_funcs,
 DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
 
ret = drm_connector_attach_encoder(connector,
-   _connector->encoder);
+   wb_connector->encoder);
if (ret)
goto attach_fail;
 
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 attach_fail:
drm_connector_cleanup(connector);
 connector_fail:
-   drm_encoder_cleanup(_connector->encoder);
+   drm_encoder_cleanup(wb_connector->encoder);
 fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.helper_private;
+   connector->base->helper_private;
int ret;
 
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job 
*job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   c

Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-03-08 Thread Kandpal, Suraj
Hi Abhinav,
> > Hi,
> >>> Hi,
> > Hi Abhinav,
> >> Hi Laurent
> >>
> >> Ok sure, I can take this up but I need to understand the proposal
> >> a little bit more before proceeding on this. So we will discuss
> >> this in another email where we specifically talk about the
> >> connector changes.
> >>
> >> Also, I am willing to take this up once the encoder part is done
> >> and merged so that atleast we keep moving on that as MSM WB
> >> implementation can proceed with that first.
> >>
> >> Hi Jani and Suraj
> >>
> >> Any concerns with splitting up the series into encoder and
> >> connector OR re- arranging them?
> >>
> >> Let me know if you can do this OR I can also split this up
> >> keeping Suraj's name in the Co-developed by tag.
> > I was actually thinking of floating a new patch series with both
> > encoder and connector pointer changes but with a change in
> > initialization functions wherein we allocate a connector and
> > encoder incase the driver doesn’t have its own this should
> > minimize the effect on other drivers already using current drm
> > writeback framework and also
>  allow i915 to create its own connector.
> 
> 
> I was proposing to split up the encoder and connector because the
> comments from Laurent meant we were in agreement about the encoder
> but not about the connector.
> 
> I am afraid another attempt with the similar idea is only going to stall the
> series again and hence i gave this option.

Seems like this patch series currently won't be able to move forward with the
connector pointer change so I guess you can split the series to encoder pointer
change where we optionally create encoder if required ,keeping my name in 
co-developed tag so that msm can move forward with its implementation and
then we can work to see how the connector issue can be bypassed.

Best Regards,
Suraj Kandpal
> Eventually its upto Laurent and the other maintainers to guide us forward on
> this as this series has been stalled for weeks now.
> 
>  I thought that Laurent was quite strict about the connector. So I'd
>  suggest targeting drm_writeback_connector with an optionally
>  created encoder and the builtin connector
> >>> In that case even if we target that i915 will not be able to move
> >>> forward with its implementation of writeback as builtin connector
> >>> does not work for us right now as explained earlier, optionally
> >>> creating encoder and connector will help everyone move forward and
> >>> once done
> >> we
> >>> can actually sit and work on how to side step this issue using
> >>> Laurent's suggestion
> >>
> >> This is up to Laurent & other DRM maintainers to decide whether this
> >> approach would be accepted or not.
> >> So far unfortunately I have mostly seen the pushback and a strong
> >> suggestion to stop treating each drm_connector as i915_connector.
> >> I haven't checked the exact details, but IMO adding a branch if the
> >> connector's type is DRM_CONNECTOR_VIRTUAL should be doable.
> > Bringing in the change where we don’t treat each drm_connector as an
> > intel_connector or even adding a branch which checks if drm_connector
> > is DRM_CONNECTOR_VIRTUAL and conditionally cast it to intel_connector
> > is quite a lot of work for i915.
> > That's why I was suggesting if for now we could move forward with
> > optionally creating both encoder and connector minimizing affects on
> > other drivers as well as allowing us to move forward.
> > What do you think, Launrent?
> >
> >>
> 
> > We can work on Laurent's suggestion but that would first require
> > the initial RFC patches and then a rework from both of our drivers
> > side to see if they gel well with our current code which will take
> > a considerable amount of time. We can for now however float the
> > patch series up which minimally affects the current drivers and
> > also allows
> > i915 and msm to move forward with its writeback implementation off
> > course with a proper documentation stating new drivers shouldn't
> > try to
>  make their own connectors and encoders and that drm_writeback will
>  do that for them.
> > Once that's done and merged we can work with Laurent on his
> > proposal to improve the drm writeback framework so that this issue
> > can be side
>  stepped entirely in future.
> > For now I would like to keep the encoder and connector pointer
> > changes
>  together.
> >>>
> >>


Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-02-25 Thread Kandpal, Suraj
Hi Abhinav,

> Based on the discussion in this thread [1] , it seems like having drm_encoder
> as a pointer seems to have merits for both of us and also in agreement with
> the folks on this thread and has a better chance of an ack.
> 
> However drm_connector is not.
> 
> I had a brief look at your implementation. Any reason you need to go
> through intel_connector here and not drm_writeback_connector directly?
> 
> The reason I ask is that I see you are not using prepare_writeback_job hook.
> If you use that, you can use the drm_writeback_connector passed on from
> there instead of looping through your list like you are doing in
> intel_find_writeback_connector.
> 
> Also, none of the other entries of struct intel_connector are being used for
> the writeback implementation. So does the drm_writeback_connector in
> your implementation need to be an intel_connector when its anyway not
> using other fields? Why cant it be just stored as a drm_writeback_connector
> itself in your struct intel_wd.

The reason we can't do that is i915 driver always assumes that all connectors
present in device list is an intel connector and since drm_writeback_connector
even though a faux connector in it's initialization calls drm_connector_init()
and gets added to the drm device list and hence the i915 driver also expects 
a corresponding intel connector to go with it. In case I do try to make 
writeback
connector standalone a lot of checks, a lot will have to be added all around 
the 
driver as there could be a chance that one of the drm_connector in the drm 
device
list may not be an intel_connector.
Yes right now not all fields of intel_connector are being used but we will be 
working
on filling them as we add more functionality to writeback for example 
introducing
content protection. 
So even if I do float the patch series with just drm_encoder as pointer it 
won't help
us with our implementation if drm_connector isn't a pointer too.
 
Regards,
Suraj Kandpal


Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-02-22 Thread Kandpal, Suraj
Hey,

> The connector/encoder funcs you do have to pass to
> drm_writeback_connector_init() can't use any of the shared driver
> infrastructure that assume a certain inheritance.
> 
> See also my reply to Laurent [1].
> 
> > It well might be that we all misunderstand your design. Do you have a
> > complete intel drm_writeback implementation based on this patchset? It
> > would be easier to judge if the approach is correct seeing your
> > target.
> 
> That would be up to Suraj Kandpal.
I have floated the intel drm_writeback implementation.
Please refer to [1] to get a better understanding of how we are implementing
writeback functionality.

[1] https://patchwork.freedesktop.org/series/100617/

Thanks,
Suraj Kandpal 


Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-03-04 Thread Kandpal, Suraj
Hi Abhinav,
> Hi Laurent
> 
> Ok sure, I can take this up but I need to understand the proposal a little bit
> more before proceeding on this. So we will discuss this in another email
> where we specifically talk about the connector changes.
> 
> Also, I am willing to take this up once the encoder part is done and merged
> so that atleast we keep moving on that as MSM WB implementation can
> proceed with that first.
> 
> Hi Jani and Suraj
> 
> Any concerns with splitting up the series into encoder and connector OR re-
> arranging them?
> 
> Let me know if you can do this OR I can also split this up keeping Suraj's
> name in the Co-developed by tag.
I was actually thinking of floating a new patch series with both encoder and 
connector pointer changes but with a change in initialization functions wherein
we allocate a connector and encoder incase the driver doesn’t have its own this
should minimize the effect on other drivers already using current drm writeback 
framework and also allow i915 to create its own connector.
We can work on Laurent's suggestion but that would first require the initial RFC
patches and then a rework from both of our drivers side to see if they gel well 
with our current code which will take a considerable amount of time. We can for
now however float the patch series up which minimally affects the current 
drivers
and also allows i915 and msm to move forward with its writeback implementation
off course with a proper documentation stating new drivers shouldn't try to make
their own connectors and encoders and that drm_writeback will do that for them.
Once that's done and merged we can work with Laurent on his proposal to improve 
the drm writeback framework so that this issue can be side stepped entirely in 
future.
For now I would like to keep the encoder and connector pointer changes together.

Best Regards,
Suraj Kandpal


Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-03-04 Thread Kandpal, Suraj
Hi,
> > Hi Abhinav,
> > > Hi Laurent
> > >
> > > Ok sure, I can take this up but I need to understand the proposal a
> > > little bit more before proceeding on this. So we will discuss this
> > > in another email where we specifically talk about the connector changes.
> > >
> > > Also, I am willing to take this up once the encoder part is done and
> > > merged so that atleast we keep moving on that as MSM WB
> > > implementation can proceed with that first.
> > >
> > > Hi Jani and Suraj
> > >
> > > Any concerns with splitting up the series into encoder and connector
> > > OR re- arranging them?
> > >
> > > Let me know if you can do this OR I can also split this up keeping
> > > Suraj's name in the Co-developed by tag.
> > I was actually thinking of floating a new patch series with both
> > encoder and connector pointer changes but with a change in
> > initialization functions wherein we allocate a connector and encoder
> > incase the driver doesn’t have its own this should minimize the effect
> > on other drivers already using current drm writeback framework and also
> allow i915 to create its own connector.
> 
> I thought that Laurent was quite strict about the connector. So I'd suggest
> targeting drm_writeback_connector with an optionally created encoder and
> the builtin connector
In that case even if we target that i915 will not be able to move forward with 
its
implementation of writeback as builtin connector does not work for us right now
as explained earlier, optionally creating encoder and connector will help 
everyone
move forward and once done we can actually sit and work on how to side step 
this 
issue using Laurent's suggestion
> 
> > We can work on Laurent's suggestion but that would first require the
> > initial RFC patches and then a rework from both of our drivers side to
> > see if they gel well with our current code which will take a
> > considerable amount of time. We can for now however float the patch
> > series up which minimally affects the current drivers and also allows
> > i915 and msm to move forward with its writeback implementation off
> > course with a proper documentation stating new drivers shouldn't try to
> make their own connectors and encoders and that drm_writeback will do
> that for them.
> > Once that's done and merged we can work with Laurent on his proposal
> > to improve the drm writeback framework so that this issue can be side
> stepped entirely in future.
> > For now I would like to keep the encoder and connector pointer changes
> together.

Best Regards,
Suraj Kandpal


Re: [Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-03-04 Thread Kandpal, Suraj
Hi, 
> > Hi,
> > > > Hi Abhinav,
> > > > > Hi Laurent
> > > > >
> > > > > Ok sure, I can take this up but I need to understand the
> > > > > proposal a little bit more before proceeding on this. So we will
> > > > > discuss this in another email where we specifically talk about the
> connector changes.
> > > > >
> > > > > Also, I am willing to take this up once the encoder part is done
> > > > > and merged so that atleast we keep moving on that as MSM WB
> > > > > implementation can proceed with that first.
> > > > >
> > > > > Hi Jani and Suraj
> > > > >
> > > > > Any concerns with splitting up the series into encoder and
> > > > > connector OR re- arranging them?
> > > > >
> > > > > Let me know if you can do this OR I can also split this up
> > > > > keeping Suraj's name in the Co-developed by tag.
> > > > I was actually thinking of floating a new patch series with both
> > > > encoder and connector pointer changes but with a change in
> > > > initialization functions wherein we allocate a connector and
> > > > encoder incase the driver doesn’t have its own this should
> > > > minimize the effect on other drivers already using current drm
> > > > writeback framework and also
> > > allow i915 to create its own connector.
> > >
> > > I thought that Laurent was quite strict about the connector. So I'd
> > > suggest targeting drm_writeback_connector with an optionally created
> > > encoder and the builtin connector
> > In that case even if we target that i915 will not be able to move
> > forward with its implementation of writeback as builtin connector does
> > not work for us right now as explained earlier, optionally creating
> > encoder and connector will help everyone move forward and once done
> we
> > can actually sit and work on how to side step this issue using
> > Laurent's suggestion
> 
> This is up to Laurent & other DRM maintainers to decide whether this
> approach would be accepted or not.
> So far unfortunately I have mostly seen the pushback and a strong
> suggestion to stop treating each drm_connector as i915_connector.
> I haven't checked the exact details, but IMO adding a branch if the
> connector's type is DRM_CONNECTOR_VIRTUAL should be doable.
Bringing in the change where we don’t treat each drm_connector as
an intel_connector or even adding a branch which checks if
drm_connector is DRM_CONNECTOR_VIRTUAL and conditionally cast it
to intel_connector is quite a lot of work for i915.
That's why I was suggesting if for now we could move forward with optionally
creating both encoder and connector minimizing affects on other drivers as
well as allowing us to move forward.
What do you think, Launrent?

> 
> > >
> > > > We can work on Laurent's suggestion but that would first require
> > > > the initial RFC patches and then a rework from both of our drivers
> > > > side to see if they gel well with our current code which will take
> > > > a considerable amount of time. We can for now however float the
> > > > patch series up which minimally affects the current drivers and
> > > > also allows
> > > > i915 and msm to move forward with its writeback implementation off
> > > > course with a proper documentation stating new drivers shouldn't
> > > > try to
> > > make their own connectors and encoders and that drm_writeback will
> > > do that for them.
> > > > Once that's done and merged we can work with Laurent on his
> > > > proposal to improve the drm writeback framework so that this issue
> > > > can be side
> > > stepped entirely in future.
> > > > For now I would like to keep the encoder and connector pointer
> > > > changes
> > > together.
> >
> 
> 
> 
> --
> With best wishes
> Dmitry

Best Regards,
Suraj Kandpal


Re: [Intel-gfx] [RFC PATCH v2 3/3] drm/i915: Enabling WD Transcoder

2022-03-24 Thread Kandpal, Suraj
Hi All,
Gentle Reminder

Regards,
Suraj Kandpal
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  89 +-
>  drivers/gpu/drm/i915/display/intel_display.h  |   9 +
>  .../drm/i915/display/intel_display_types.h|  13 +
>  drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
>  drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
>  drivers/gpu/drm/i915/display/intel_wd.c   | 978 ++
>  drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +
>  drivers/gpu/drm/i915/i915_irq.c   |   8 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   7 +-
>  drivers/gpu/drm/i915/i915_reg.h   | 137 +++
>  13 files changed, 1330 insertions(+), 3 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_wd.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 087bd9d1b397..5ee32513a945 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -287,6 +287,7 @@ i915-y += \
>   display/intel_vdsc.o \
>   display/intel_vrr.o \
>   display/intel_wb_connector.o\
> + display/intel_wd.o\
>   display/vlv_dsi.o \
>   display/vlv_dsi_pll.o
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e78430001f07..ae08db164f73 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
>   case DRM_MODE_CONNECTOR_LVDS:
>   case DRM_MODE_CONNECTOR_eDP:
>   case DRM_MODE_CONNECTOR_DSI:
> + case DRM_MODE_CONNECTOR_WRITEBACK:
>   display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
>   break;
>   case DRM_MODE_CONNECTOR_Unknown:
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index eb49973621f0..6dedc7921f54 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -111,6 +111,7 @@
>  #include "intel_sprite.h"
>  #include "intel_tc.h"
>  #include "intel_vga.h"
> +#include "intel_wd.h"
>  #include "i9xx_plane.h"
>  #include "skl_scaler.h"
>  #include "skl_universal_plane.h"
> @@ -1544,6 +1545,72 @@ static void
> intel_encoders_update_complete(struct intel_atomic_state *state)
>   }
>  }
> 
> +static void intel_queue_writeback_job(struct intel_atomic_state *state,
> + struct intel_crtc *intel_crtc, struct intel_crtc_state
> *crtc_state) {
> + struct drm_connector_state *new_conn_state;
> + struct drm_connector *connector;
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_wd *intel_wd;
> + struct intel_connector *intel_connector;
> + struct intel_digital_connector_state *intel_conn_state;
> + struct intel_encoder *encoder;
> + int i;
> +
> + for_each_intel_encoder_with_wd(>drm, encoder) {
> + intel_wd = enc_to_intel_wd(encoder);
> +
> + if (intel_wd->wd_crtc != intel_crtc)
> + return;
> +
> + }
> +
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state,
> + i) {
> + intel_conn_state =
> to_intel_digital_connector_state(new_conn_state);
> + if (!intel_conn_state->job)
> + continue;
> + intel_connector = to_intel_connector(connector);
> + intel_writeback_queue_job(_connector->wb_conn,
> new_conn_state);
> + drm_dbg_kms(>drm, "queueing writeback job\n");
> + }
> +}
> +
> +static void intel_find_writeback_connector(struct intel_atomic_state
> *state,
> + struct intel_crtc *intel_crtc, struct intel_crtc_state
> *crtc_state) {
> + struct drm_connector_state *new_conn_state;
> + struct drm_connector *connector;
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_wd *intel_wd;
> + struct intel_encoder *encoder;
> + int i;
> +
> + for_each_intel_encoder_with_wd(>drm, encoder) {
> + intel_wd = enc_to_intel_wd(encoder);
> +
> + if (intel_wd->wd_crtc != intel_crtc)
> + return;
> +
> + }
> +
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state,
> + i) {
> + struct intel_connector *intel_connector;
> +
> + intel_connector = to_intel_connector(connector);
> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s]: status:
> %s\n",
> + connector->base.id, connector->name,
> +
>   drm_get_connector_status_name(connector->status));
> +

[Intel-gfx] [PATCH v2 1/6] drm: add writeback pointers to drm_connector

2022-02-02 Thread Kandpal Suraj
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;

struct intel_connector {
struct drm_connector base;

The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.

Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.

Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.

Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/drm_writeback.c | 19 ++-
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_writeback.h |  6 +++---
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct 
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
 
-   return wb_connector->base.dev->driver->name;
+   return wb_connector->base->dev->driver->name;
 }
 
 static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 const u32 *formats, int n_formats)
 {
struct drm_property_blob *blob;
-   struct drm_connector *connector = _connector->base;
+   struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = >mode_config;
int ret = create_writeback_properties(dev);
 
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
 
-   drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
-   ret = drm_encoder_init(dev, _connector->encoder,
+   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+   ret = drm_encoder_init(dev, wb_connector->encoder,
   _writeback_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
 
connector->interlace_allowed = 0;
+   connector->wb_connector = wb_connector;
 
ret = drm_connector_init(dev, connector, con_funcs,
 DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
 
ret = drm_connector_attach_encoder(connector,
-   _connector->encoder);
+   wb_connector->encoder);
if (ret)
goto attach_fail;
 
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 attach_fail:
drm_connector_cleanup(connector);
 connector_fail:
-   drm_encoder_cleanup(_connector->encoder);
+   drm_encoder_cleanup(wb_connector->encoder);
 fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.helper_private;
+   connector->base->helper_private;
int ret;
 
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job 
*job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.h

[Intel-gfx] [PATCH v2 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer

2022-02-02 Thread Kandpal Suraj
Making changes to komeda driver because we had to change
drm_writeback_connector.base into a pointer the reason for which is
expained in the Patch (drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c  |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h   |  3 ++-
 .../gpu/drm/arm/display/komeda/komeda_wb_connector.c  | 11 ++-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
 
-   conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+   conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
  * struct komeda_wb_connector
  */
 struct komeda_wb_connector {
+   struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;
 
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
 static inline bool is_writeback_only(struct drm_crtc_state *st)
 {
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
-   struct drm_connector *conn = wb_conn ? _conn->base.base : NULL;
+   struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
 
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
 }
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..2c3dec59fd88 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
-   wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+   wb_layer = 
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
 
/*
 * No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector 
*connector,
 static void komeda_wb_connector_destroy(struct drm_connector *connector)
 {
drm_connector_cleanup(connector);
-   kfree(to_kconn(to_wb_conn(connector)));
+   kfree(to_kconn(drm_connector_to_writeback(connector)));
 }
 
 static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,7 +155,8 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
 
wb_conn = _conn->base;
-   wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(>base));
+   wb_conn->base = _conn->conn;
+   wb_conn->encoder->possible_crtcs = BIT(drm_crtc_index(>base));
 
formats = komeda_get_layer_fourcc_list(>fmt_tbl,
   kwb_conn->wb_layer->layer_type,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
return err;
}
 
-   drm_connector_helper_add(_conn->base, _wb_conn_helper_funcs);
+   drm_connector_helper_add(wb_conn->base, _wb_conn_helper_funcs);
 
-   info = _conn->base.base.display_info;
+   info = _conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
 
-- 
2.17.1



[Intel-gfx] [PATCH v2 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure

2022-02-02 Thread Kandpal Suraj
Changing vc4 driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/vc4/vc4_txp.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 9809ca3e2945..9882569d147c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,10 @@ struct vc4_txp {
 
struct platform_device *pdev;
 
+   struct drm_connector drm_conn;
+
+   struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
 
void __iomem *regs;
@@ -159,12 +163,12 @@ struct vc4_txp {
 
 static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
 {
-   return container_of(encoder, struct vc4_txp, connector.encoder);
+   return container_of(encoder, struct vc4_txp, drm_enc);
 }
 
 static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
 {
-   return container_of(conn, struct vc4_txp, connector.base);
+   return container_of(conn, struct vc4_txp, drm_conn);
 }
 
 static const struct debugfs_reg32 txp_regs[] = {
@@ -467,6 +471,7 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+   struct drm_writeback_connector *wb_conn;
int ret, irq;
 
irq = platform_get_irq(pdev, 0);
@@ -491,10 +496,13 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
txp->regset.base = txp->regs;
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
+   wb_conn = >connector;
+   wb_conn->base = >drm_conn;
+   wb_conn->encoder = >drm_enc;
 
-   drm_connector_helper_add(>connector.base,
+   drm_connector_helper_add(wb_conn->base,
 _txp_connector_helper_funcs);
-   ret = drm_writeback_connector_init(drm, >connector,
+   ret = drm_writeback_connector_init(drm, wb_conn,
   _txp_connector_funcs,
   _txp_encoder_helper_funcs,
   drm_fmts, ARRAY_SIZE(drm_fmts));
@@ -506,7 +514,7 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
-   encoder = >connector.encoder;
+   encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
 
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
@@ -529,7 +537,7 @@ static void vc4_txp_unbind(struct device *dev, struct 
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_txp *txp = dev_get_drvdata(dev);
 
-   vc4_txp_connector_destroy(>connector.base);
+   vc4_txp_connector_destroy(txp->connector.base);
 
vc4->txp = NULL;
 }
-- 
2.17.1



[Intel-gfx] [PATCH v2 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-02-02 Thread Kandpal Suraj
Changing rcar_du driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  | 2 ++
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 66e8839db708..68f387a04502 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -72,6 +72,8 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
 
+   struct drm_connector connector;
+   struct drm_encoder encoder;
struct drm_writeback_connector writeback;
 };
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c 
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d1259e49b..5b1e83380c47 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
 {
struct drm_writeback_connector *wb_conn = >writeback;
 
-   wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(>crtc);
-   drm_connector_helper_add(_conn->base,
+   wb_conn->base = >connector;
+   wb_conn->encoder = >encoder;
+   wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(>crtc);
+   drm_connector_helper_add(wb_conn->base,
 _du_wb_conn_helper_funcs);
 
return drm_writeback_connector_init(>ddev, wb_conn,
@@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
struct drm_framebuffer *fb;
unsigned int i;
 
-   state = rcrtc->writeback.base.state;
+   state = rcrtc->writeback.base->state;
if (!state || !state->writeback_job)
return;
 
-- 
2.17.1



[Intel-gfx] [PATCH v2 6/6] drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes

2022-02-02 Thread Kandpal Suraj
Changing malidp driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/arm/malidp_crtc.c |  2 +-
 drivers/gpu/drm/arm/malidp_drv.h  |  2 ++
 drivers/gpu/drm/arm/malidp_mw.c   | 12 
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..294aacd4beef 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -424,7 +424,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
u32 new_mask = crtc_state->connector_mask;
 
if ((old_mask ^ new_mask) ==
-   (1 << drm_connector_index(>mw_connector.base)))
+   (1 << drm_connector_index(malidp->mw_connector.base)))
crtc_state->connectors_changed = false;
}
 
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index cdfddfabf2d1..971810a685f1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -31,6 +31,8 @@ struct malidp_error_stats {
 struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
struct drm_writeback_connector mw_connector;
wait_queue_head_t wq;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a79dd7e..9bd2e400cd3d 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -206,21 +206,25 @@ static u32 *get_writeback_formats(struct malidp_drm 
*malidp, int *n_formats)
 int malidp_mw_connector_init(struct drm_device *drm)
 {
struct malidp_drm *malidp = drm->dev_private;
+   struct drm_writeback_connector *wb_conn;
u32 *formats;
int ret, n_formats;
 
if (!malidp->dev->hw->enable_memwrite)
return 0;
 
-   malidp->mw_connector.encoder.possible_crtcs = 1 << 
drm_crtc_index(>crtc);
-   drm_connector_helper_add(>mw_connector.base,
+   wb_conn = >mw_connector;
+   wb_conn->base = >connector;
+   wb_conn->encoder = >encoder;
+   malidp->mw_connector.encoder->possible_crtcs = 1 << 
drm_crtc_index(>crtc);
+   drm_connector_helper_add(wb_conn->base,
 _mw_connector_helper_funcs);
 
formats = get_writeback_formats(malidp, _formats);
if (!formats)
return -ENOMEM;
 
-   ret = drm_writeback_connector_init(drm, >mw_connector,
+   ret = drm_writeback_connector_init(drm, wb_conn,
   _mw_connector_funcs,
   _mw_encoder_helper_funcs,
   formats, n_formats);
@@ -236,7 +240,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
 {
struct malidp_drm *malidp = drm->dev_private;
struct drm_writeback_connector *mw_conn = >mw_connector;
-   struct drm_connector_state *conn_state = mw_conn->base.state;
+   struct drm_connector_state *conn_state = mw_conn->base->state;
struct malidp_hw_device *hwdev = malidp->dev;
struct malidp_mw_connector_state *mw_state;
 
-- 
2.17.1



[Intel-gfx] [PATCH v2 3/6] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer

2022-02-02 Thread Kandpal Suraj
Changing vkms driver to accomadate the change of
drm_writeback_connector.base to a pointer the reason for which is
explained in the Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/vkms/vkms_writeback.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c 
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..374431471f49 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct drm_connector 
*conn,
struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn->dev);
struct vkms_output *output = >output;
struct drm_writeback_connector *wb_conn = >wb_connector;
-   struct drm_connector_state *conn_state = wb_conn->base.state;
+   struct drm_connector_state *conn_state = wb_conn->base->state;
struct vkms_crtc_state *crtc_state = output->composer_state;
 
if (!conn_state)
@@ -139,9 +139,12 @@ static const struct drm_connector_helper_funcs 
vkms_wb_conn_helper_funcs = {
 int vkms_enable_writeback_connector(struct vkms_device *vkmsdev)
 {
struct drm_writeback_connector *wb = >output.wb_connector;
+   struct vkms_output *output = >output;
 
-   vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
-   drm_connector_helper_add(>base, _wb_conn_helper_funcs);
+   wb->base = >connector;
+   wb->encoder = >encoder;
+   output->wb_connector.encoder->possible_crtcs = 1;
+   drm_connector_helper_add(wb->base, _wb_conn_helper_funcs);
 
return drm_writeback_connector_init(>drm, wb,
_wb_connector_funcs,
-- 
2.17.1



[Intel-gfx] [PATCH 2/6] drm/arm/komeda : change driver to use drm_writeback_connector.base pointer

2022-02-02 Thread Kandpal Suraj
Making changes to komeda driver because we had to change
drm_writeback_connector.base into a pointer the reason for which is
expained in the Patch (drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 

Reviewed-by: Carsten Haitzler 
---
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c  |  2 +-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h   |  3 ++-
 .../gpu/drm/arm/display/komeda/komeda_wb_connector.c  | 11 ++-
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
 
-   conn_st = wb_conn ? wb_conn->base.base.state : NULL;
+   conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
 
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h 
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
  * struct komeda_wb_connector
  */
 struct komeda_wb_connector {
+   struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;
 
@@ -136,7 +137,7 @@ struct komeda_kms_dev {
 static inline bool is_writeback_only(struct drm_crtc_state *st)
 {
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
-   struct drm_connector *conn = wb_conn ? _conn->base.base : NULL;
+   struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
 
return conn && (st->connector_mask == BIT(drm_connector_index(conn)));
 }
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..2c3dec59fd88 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
-   wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;
+   wb_layer = 
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
 
/*
 * No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector 
*connector,
 static void komeda_wb_connector_destroy(struct drm_connector *connector)
 {
drm_connector_cleanup(connector);
-   kfree(to_kconn(to_wb_conn(connector)));
+   kfree(to_kconn(drm_connector_to_writeback(connector)));
 }
 
 static const struct drm_connector_funcs komeda_wb_connector_funcs = {
@@ -155,7 +155,8 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
 
wb_conn = _conn->base;
-   wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(>base));
+   wb_conn->base = _conn->conn;
+   wb_conn->encoder->possible_crtcs = BIT(drm_crtc_index(>base));
 
formats = komeda_get_layer_fourcc_list(>fmt_tbl,
   kwb_conn->wb_layer->layer_type,
@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
return err;
}
 
-   drm_connector_helper_add(_conn->base, _wb_conn_helper_funcs);
+   drm_connector_helper_add(wb_conn->base, _wb_conn_helper_funcs);
 
-   info = _conn->base.base.display_info;
+   info = _conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
 
-- 
2.17.1



[Intel-gfx] [PATCH 3/6] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer

2022-02-02 Thread Kandpal Suraj
Changing vkms driver to accomadate the change of
drm_writeback_connector.base to a pointer the reason for which is
explained in the Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/vkms/vkms_writeback.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c 
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..374431471f49 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct drm_connector 
*conn,
struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn->dev);
struct vkms_output *output = >output;
struct drm_writeback_connector *wb_conn = >wb_connector;
-   struct drm_connector_state *conn_state = wb_conn->base.state;
+   struct drm_connector_state *conn_state = wb_conn->base->state;
struct vkms_crtc_state *crtc_state = output->composer_state;
 
if (!conn_state)
@@ -139,9 +139,12 @@ static const struct drm_connector_helper_funcs 
vkms_wb_conn_helper_funcs = {
 int vkms_enable_writeback_connector(struct vkms_device *vkmsdev)
 {
struct drm_writeback_connector *wb = >output.wb_connector;
+   struct vkms_output *output = >output;
 
-   vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
-   drm_connector_helper_add(>base, _wb_conn_helper_funcs);
+   wb->base = >connector;
+   wb->encoder = >encoder;
+   output->wb_connector.encoder->possible_crtcs = 1;
+   drm_connector_helper_add(wb->base, _wb_conn_helper_funcs);
 
return drm_writeback_connector_init(>drm, wb,
_wb_connector_funcs,
-- 
2.17.1



[Intel-gfx] [PATCH 4/6] drm/vc4: vc4 driver changes to accommodate changes done in drm_writeback_connector structure

2022-02-02 Thread Kandpal Suraj
Changing vc4 driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/vc4/vc4_txp.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index 9809ca3e2945..9882569d147c 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -151,6 +151,10 @@ struct vc4_txp {
 
struct platform_device *pdev;
 
+   struct drm_connector drm_conn;
+
+   struct drm_encoder drm_enc;
+
struct drm_writeback_connector connector;
 
void __iomem *regs;
@@ -159,12 +163,12 @@ struct vc4_txp {
 
 static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder *encoder)
 {
-   return container_of(encoder, struct vc4_txp, connector.encoder);
+   return container_of(encoder, struct vc4_txp, drm_enc);
 }
 
 static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector *conn)
 {
-   return container_of(conn, struct vc4_txp, connector.base);
+   return container_of(conn, struct vc4_txp, drm_conn);
 }
 
 static const struct debugfs_reg32 txp_regs[] = {
@@ -467,6 +471,7 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
struct vc4_txp *txp;
struct drm_crtc *crtc;
struct drm_encoder *encoder;
+   struct drm_writeback_connector *wb_conn;
int ret, irq;
 
irq = platform_get_irq(pdev, 0);
@@ -491,10 +496,13 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
txp->regset.base = txp->regs;
txp->regset.regs = txp_regs;
txp->regset.nregs = ARRAY_SIZE(txp_regs);
+   wb_conn = >connector;
+   wb_conn->base = >drm_conn;
+   wb_conn->encoder = >drm_enc;
 
-   drm_connector_helper_add(>connector.base,
+   drm_connector_helper_add(wb_conn->base,
 _txp_connector_helper_funcs);
-   ret = drm_writeback_connector_init(drm, >connector,
+   ret = drm_writeback_connector_init(drm, wb_conn,
   _txp_connector_funcs,
   _txp_encoder_helper_funcs,
   drm_fmts, ARRAY_SIZE(drm_fmts));
@@ -506,7 +514,7 @@ static int vc4_txp_bind(struct device *dev, struct device 
*master, void *data)
if (ret)
return ret;
 
-   encoder = >connector.encoder;
+   encoder = txp->connector.encoder;
encoder->possible_crtcs = drm_crtc_mask(crtc);
 
ret = devm_request_irq(dev, irq, vc4_txp_interrupt, 0,
@@ -529,7 +537,7 @@ static void vc4_txp_unbind(struct device *dev, struct 
device *master,
struct vc4_dev *vc4 = to_vc4_dev(drm);
struct vc4_txp *txp = dev_get_drvdata(dev);
 
-   vc4_txp_connector_destroy(>connector.base);
+   vc4_txp_connector_destroy(txp->connector.base);
 
vc4->txp = NULL;
 }
-- 
2.17.1



[Intel-gfx] [PATCH 0/6] drm writeback connector changes

2022-02-02 Thread Kandpal Suraj
This patch series contains drm_writeback_connector structure change i.e 
change of drm_connector and drm_encoder fields to a pointer the reason
for which is explained in patch(1/6) drm: add writeback pointers to
drm_connector and the accompanying changes to the different drivers that
were effected by it.
I had perviously floated a patch series but missed some of the drivers
that were effected by the change hence refloating the patch series 

Kandpal Suraj (6):
  drm: add writeback pointers to drm_connector
  drm/arm/komeda : change driver to use drm_writeback_connector.base
pointer
  drm/vkms: change vkms driver to use drm_writeback_connector.base
pointer
  drm/vc4: vc4 driver changes to accommodate changes done in
drm_writeback_connector structure
  drm/rcar_du: changes to rcar-du driver resulting from
drm_writeback_connector structure changes
  drm/arm: changes to malidp driver resulting from
drm_writeback_connector structure changes

 .../gpu/drm/arm/display/komeda/komeda_crtc.c  |  2 +-
 .../gpu/drm/arm/display/komeda/komeda_kms.h   |  3 ++-
 .../arm/display/komeda/komeda_wb_connector.c  | 11 +-
 drivers/gpu/drm/arm/malidp_crtc.c |  2 +-
 drivers/gpu/drm/arm/malidp_drv.h  |  2 ++
 drivers/gpu/drm/arm/malidp_mw.c   | 12 +++
 drivers/gpu/drm/drm_writeback.c   | 19 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h|  2 ++
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c   |  8 +---
 drivers/gpu/drm/vc4/vc4_txp.c | 20 +--
 drivers/gpu/drm/vkms/vkms_writeback.c |  9 ++---
 include/drm/drm_connector.h   |  3 +++
 include/drm/drm_writeback.h   |  6 +++---
 13 files changed, 63 insertions(+), 36 deletions(-)

-- 
2.17.1



[Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector

2022-02-02 Thread Kandpal Suraj
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;

struct intel_connector {
struct drm_connector base;

The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.

Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.

Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.

Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.

Signed-off-by: Kandpal Suraj 

Reviewed-by: Abhinav Kumar 
---
 drivers/gpu/drm/drm_writeback.c | 19 ++-
 include/drm/drm_connector.h |  3 +++
 include/drm/drm_writeback.h |  6 +++---
 3 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct 
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
 
-   return wb_connector->base.dev->driver->name;
+   return wb_connector->base->dev->driver->name;
 }
 
 static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 const u32 *formats, int n_formats)
 {
struct drm_property_blob *blob;
-   struct drm_connector *connector = _connector->base;
+   struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = >mode_config;
int ret = create_writeback_properties(dev);
 
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
 
-   drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
-   ret = drm_encoder_init(dev, _connector->encoder,
+   drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+   ret = drm_encoder_init(dev, wb_connector->encoder,
   _writeback_encoder_funcs,
   DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
 
connector->interlace_allowed = 0;
+   connector->wb_connector = wb_connector;
 
ret = drm_connector_init(dev, connector, con_funcs,
 DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
 
ret = drm_connector_attach_encoder(connector,
-   _connector->encoder);
+   wb_connector->encoder);
if (ret)
goto attach_fail;
 
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
 attach_fail:
drm_connector_cleanup(connector);
 connector_fail:
-   drm_encoder_cleanup(_connector->encoder);
+   drm_encoder_cleanup(wb_connector->encoder);
 fail:
drm_property_blob_put(blob);
return ret;
@@ -263,7 +264,7 @@ int drm_writeback_prepare_job(struct drm_writeback_job *job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-   connector->base.helper_private;
+   connector->base->helper_private;
int ret;
 
if (funcs->prepare_writeback_job) {
@@ -315,7 +316,7 @@ void drm_writeback_cleanup_job(struct drm_writeback_job 
*job)
 {
struct drm_writeback_connector *connector = job->connector;
const struct drm_connector_helper_funcs *funcs =
-

[Intel-gfx] [PATCH 5/6] drm/rcar_du: changes to rcar-du driver resulting from drm_writeback_connector structure changes

2022-02-02 Thread Kandpal Suraj
Changing rcar_du driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  | 2 ++
 drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 8 +---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 66e8839db708..68f387a04502 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -72,6 +72,8 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
 
+   struct drm_connector connector;
+   struct drm_encoder encoder;
struct drm_writeback_connector writeback;
 };
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c 
b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
index c79d1259e49b..5b1e83380c47 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_writeback.c
@@ -200,8 +200,10 @@ int rcar_du_writeback_init(struct rcar_du_device *rcdu,
 {
struct drm_writeback_connector *wb_conn = >writeback;
 
-   wb_conn->encoder.possible_crtcs = 1 << drm_crtc_index(>crtc);
-   drm_connector_helper_add(_conn->base,
+   wb_conn->base = >connector;
+   wb_conn->encoder = >encoder;
+   wb_conn->encoder->possible_crtcs = 1 << drm_crtc_index(>crtc);
+   drm_connector_helper_add(wb_conn->base,
 _du_wb_conn_helper_funcs);
 
return drm_writeback_connector_init(>ddev, wb_conn,
@@ -220,7 +222,7 @@ void rcar_du_writeback_setup(struct rcar_du_crtc *rcrtc,
struct drm_framebuffer *fb;
unsigned int i;
 
-   state = rcrtc->writeback.base.state;
+   state = rcrtc->writeback.base->state;
if (!state || !state->writeback_job)
return;
 
-- 
2.17.1



[Intel-gfx] [PATCH 6/6] drm/arm: changes to malidp driver resulting from drm_writeback_connector structure changes

2022-02-02 Thread Kandpal Suraj
Changing malidp driver to accomadate the change of
drm_writeback_connector.base and drm_writeback_connector.encoder
to a pointer the reason for which is explained in the
Patch(drm: add writeback pointers to drm_connector).

Signed-off-by: Kandpal Suraj 
---
 drivers/gpu/drm/arm/malidp_crtc.c |  2 +-
 drivers/gpu/drm/arm/malidp_drv.h  |  2 ++
 drivers/gpu/drm/arm/malidp_mw.c   | 12 
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_crtc.c 
b/drivers/gpu/drm/arm/malidp_crtc.c
index 494075ddbef6..294aacd4beef 100644
--- a/drivers/gpu/drm/arm/malidp_crtc.c
+++ b/drivers/gpu/drm/arm/malidp_crtc.c
@@ -424,7 +424,7 @@ static int malidp_crtc_atomic_check(struct drm_crtc *crtc,
u32 new_mask = crtc_state->connector_mask;
 
if ((old_mask ^ new_mask) ==
-   (1 << drm_connector_index(>mw_connector.base)))
+   (1 << drm_connector_index(malidp->mw_connector.base)))
crtc_state->connectors_changed = false;
}
 
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index cdfddfabf2d1..971810a685f1 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -31,6 +31,8 @@ struct malidp_error_stats {
 struct malidp_drm {
struct malidp_hw_device *dev;
struct drm_crtc crtc;
+   struct drm_connector connector;
+   struct drm_encoder encoder;
struct drm_writeback_connector mw_connector;
wait_queue_head_t wq;
struct drm_pending_vblank_event *event;
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index f5847a79dd7e..9bd2e400cd3d 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -206,21 +206,25 @@ static u32 *get_writeback_formats(struct malidp_drm 
*malidp, int *n_formats)
 int malidp_mw_connector_init(struct drm_device *drm)
 {
struct malidp_drm *malidp = drm->dev_private;
+   struct drm_writeback_connector *wb_conn;
u32 *formats;
int ret, n_formats;
 
if (!malidp->dev->hw->enable_memwrite)
return 0;
 
-   malidp->mw_connector.encoder.possible_crtcs = 1 << 
drm_crtc_index(>crtc);
-   drm_connector_helper_add(>mw_connector.base,
+   wb_conn = >mw_connector;
+   wb_conn->base = >connector;
+   wb_conn->encoder = >encoder;
+   malidp->mw_connector.encoder->possible_crtcs = 1 << 
drm_crtc_index(>crtc);
+   drm_connector_helper_add(wb_conn->base,
 _mw_connector_helper_funcs);
 
formats = get_writeback_formats(malidp, _formats);
if (!formats)
return -ENOMEM;
 
-   ret = drm_writeback_connector_init(drm, >mw_connector,
+   ret = drm_writeback_connector_init(drm, wb_conn,
   _mw_connector_funcs,
   _mw_encoder_helper_funcs,
   formats, n_formats);
@@ -236,7 +240,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
 {
struct malidp_drm *malidp = drm->dev_private;
struct drm_writeback_connector *mw_conn = >mw_connector;
-   struct drm_connector_state *conn_state = mw_conn->base.state;
+   struct drm_connector_state *conn_state = mw_conn->base->state;
struct malidp_hw_device *hwdev = malidp->dev;
struct malidp_mw_connector_state *mw_state;
 
-- 
2.17.1



Re: [Intel-gfx] [PATCH 1/6] drm: add writeback pointers to drm_connector

2022-02-03 Thread Kandpal, Suraj


Hi Dmitry,
Thanks for your comments
 
> Could you please clarify, why do you want to use intel_connector for the
> writeback connector?
> I can see a usecase for sharing an encoder between the display and writback
> pipelines (and if I'm not mistaken, this is the case for Abhinav's case).
> However, sharing the hardware-backed connector and writeback connector
> sounds like a sign of a loose abstraction for me.
> 
> Please correct me if I'm wrong and Intel driver would really benefit from
> reusing intel_connector as a base for drm_writeback_connector.
> 

The thing is drm_writeback_connector contains drm_connector and drm_encoder 
fields
which get initialized when we call drm_writeback_connector_init adding the 
connector
to the list of connectors for the drm_device.
Now if I decide not to wrap drm_writeback_connector with intel_connector the 
issue
is I'll have to add a lot of checks all over the driver to see if the 
drm_connector is actually
present inside intel_connector or not. I don’t see the point of not having 
drm_writeback_
connector as even though it’s a faux connector we still treat is as a connector 
and it would
be better for us to use intel_connector for writeback_connector.
Also the current drm_writeback_connector structure kind of restricts drivers 
consequently
dictating how they implement their writeback functionality, as a midlayer I 
don't feel that
would be the right approach as drivers should have the freedom to develop their 
own flow
to implement the functionality and use the midlayer as a helper to get that 
done. 

Best Regards,
Suraj Kandpal



Re: [Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector

2022-01-27 Thread Kandpal, Suraj
> 
> + laurent on this
> 
> Hi Suraj
> Jani pointed me to this thread as i had posted something similar here :
> https://patchwork.freedesktop.org/patch/470296/ but since this thread was
> posted earlier, we can discuss further here.
> 
> Overall, its similar to what I had posted in the RFC and your commit text also
> covers my concerns too.
> 
> One question I have about your change is since you have changed
> wb_connector::encoder to be a pointer, i saw the other changes in the series
> but they do not allocate an encoder. Would this not affect the other drivers
> which are assuming that the encoder in wb_connector is struct drm_encoder
> encoder and not struct drm_encoder* encoder.
> 
> Your changes fix the compilation issue but wouldnt this crash as encoder
> wasnt allocated for other drivers.
> 

Hi Abhinav,
That shouldn't be an issue as normally drivers tend to have their own output
structure which has drm_connector and drm_encoder embedded in it depending 
on the level of binding they have decided to give the connector and encoder in
their respective output and the addresses of these are passed to the 
drm_connector* and drm_encoder* in drm_writeback_connector structure 
which then gets initialized in drm_writeback_connector_init().

In our i915 code we have intel_connector structure with drm_connector base 
field and intel_wd with a intel_encoder base which in turn has drm_encoder
field and both intel_connector and intel_wd are initialized not requiring 
explicit
alloc and dealloc for drm_encoder
intel_wd = kzalloc(sizeof(*intel_wd), GFP_KERNEL);

intel_connector = intel_connector_alloc();
wb_conn = _connector->wb_conn;
wb_conn->base = _connector->base;
wb_conn->encoder = _wd->base.base;

Similary for komeda driver has 
struct komeda_wb_connector {
struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;

/** @wb_layer: represents associated writeback pipeline of komeda */
struct komeda_layer *wb_layer;
};

static int komeda_wb_connector_add(struct komeda_kms_dev *kms,
   struct komeda_crtc *kcrtc)
{
struct komeda_wb_connector *kwb_conn;
struct drm_writeback_connector *wb_conn;

kwb_conn = kzalloc(sizeof(*kwb_conn), GFP_KERNEL);

wb_conn = _conn->base;
wb_conn->base = _conn->conn;
  
and they do not depend on the encoder binding so changes will work for them
Also in vkms driver we have the 
struct vkms_output {
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
struct drm_writeback_connector wb_connector;
struct hrtimer vblank_hrtimer;
ktime_t period_ns;
struct drm_pending_vblank_event *event;
/* ordered wq for composer_work */
struct workqueue_struct *composer_workq;
/* protects concurrent access to composer */
spinlock_t lock;

/* protected by @lock */
bool composer_enabled;
struct vkms_crtc_state *composer_state;

spinlock_t composer_lock;
};

Which gets allocated covering for the drm_encoder alloc and dealloc

Regards,
Suraj Kandpal



Re: [Intel-gfx] [PATCH 1/3] drm: add writeback pointers to drm_connector

2022-01-31 Thread Kandpal, Suraj
Hey,
> I think there are more places affected with this change. I can get below
> compilation issues while trying to compile my branch:
> 
> drivers/gpu/drm/vc4/vc4_txp.c: In function ‘encoder_to_vc4_txp’:
> ./include/linux/build_bug.h:78:41: error: static assertion failed:
> "pointer type mismatch in container_of()"
>   #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>   ^
> ./include/linux/build_bug.h:77:34: note: in expansion of macro
> ‘__static_assert’
>   #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__,
> #expr)
>^
> ./include/linux/container_of.h:19:2: note: in expansion of macro
> ‘static_assert’
>static_assert(__same_type(*(ptr), ((type *)0)->member) || \
>^
> drivers/gpu/drm/vc4/vc4_txp.c:162:9: note: in expansion of macro
> ‘container_of’
>return container_of(encoder, struct vc4_txp, connector.encoder);
>   ^
> drivers/gpu/drm/vc4/vc4_txp.c: In function ‘connector_to_vc4_txp’:
> ./include/linux/build_bug.h:78:41: error: static assertion failed:
> "pointer type mismatch in container_of()"
>   #define __static_assert(expr, msg, ...) _Static_assert(expr, msg)
>   ^
> ./include/linux/build_bug.h:77:34: note: in expansion of macro
> ‘__static_assert’
>   #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__,
> #expr)
>^
> ./include/linux/container_of.h:19:2: note: in expansion of macro
> ‘static_assert’
>static_assert(__same_type(*(ptr), ((type *)0)->member) || \
>^
> drivers/gpu/drm/vc4/vc4_txp.c:167:9: note: in expansion of macro
> ‘container_of’
>return container_of(conn, struct vc4_txp, connector.base);
>   ^
> drivers/gpu/drm/vc4/vc4_txp.c: In function ‘vc4_txp_bind’:
> drivers/gpu/drm/vc4/vc4_txp.c:495:27: error: passing argument 1 of
> ‘drm_connector_helper_add’ from incompatible pointer type [-
> Werror=incompatible-pointer-types]
>drm_connector_helper_add(>connector.base,
> ^
> In file included from ./include/drm/drm_atomic_helper.h:32:0,
>   from drivers/gpu/drm/vc4/vc4_txp.c:17:
> ./include/drm/drm_modeset_helper_vtables.h:1153:20: note: expected
> ‘struct drm_connector *’ but argument is of type ‘struct drm_connector **’
>   static inline void drm_connector_helper_add(struct drm_connector
> *connector,
>  ^
> drivers/gpu/drm/vc4/vc4_txp.c:509:10: error: assignment from incompatible
> pointer type [-Werror=incompatible-pointer-types]
>encoder = >connector.encoder;
>^
> drivers/gpu/drm/vc4/vc4_txp.c: In function ‘vc4_txp_unbind’:
> drivers/gpu/drm/vc4/vc4_txp.c:532:28: error: passing argument 1 of
> ‘vc4_txp_connector_destroy’ from incompatible pointer type [-
> Werror=incompatible-pointer-types]
>vc4_txp_connector_destroy(>connector.base);
>  ^
> drivers/gpu/drm/vc4/vc4_txp.c:333:13: note: expected ‘struct
> drm_connector *’ but argument is of type ‘struct drm_connector **’
>   static void vc4_txp_connector_destroy(struct drm_connector *connector)
> 
I will have a look at this and try to resolve it
> 
> Looks like vc4 doesnt have its own encoder so we might have to move it to
> have its own?

Right seems like we will have to add a drm_connector and drm_encoder in the 
below structure
> 
> struct vc4_txp {
>  struct vc4_crtc base;
> 
>  struct platform_device *pdev;
> 
>  struct drm_writeback_connector connector;
> 
>  void __iomem *regs;
>  struct debugfs_regset32 regset;
> };
> 
> static inline struct vc4_txp *encoder_to_vc4_txp(struct drm_encoder
> *encoder)
> {
>  return container_of(encoder, struct vc4_txp, connector.encoder); }
> 
> static inline struct vc4_txp *connector_to_vc4_txp(struct drm_connector
> *conn)
> {
>  return container_of(conn, struct vc4_txp, connector.base); }
> 

Changes will be required here in both connector_of functions to point to 
The new drm_connector and drm_encoder we add in vc4_txp struct.

> 
> One more thing, it looks like to me, we need to do one more thing.
> 
> Like intel does and what MSM will do, the encoder pointer of the wb
> connector has to point to the encoder struct .
> 
>  >> wb_conn = _connector->wb_conn;
>  >> wb_conn->base = _connector->base;
>  >> wb_conn->encoder = _wd->base.base;
> 
Yes this will need to be done 

Thanks Abhinav for pointing Ill implement this and send it in the next version
of patches 

Regards,
Suraj Kandpal



Re: [Intel-gfx] [PATCH 3/3] drm/vkms: change vkms driver to use drm_writeback_connector.base pointer

2022-01-30 Thread Kandpal, Suraj
Hi All,
Gentle Reminder! Any Review comments?

> Changing vkms driver to accomadate the change of
> drm_writeback_connector.base to a pointer the reason for which is
> explained in the Patch(drm: add writeback pointers to drm_connector).
> 
> Signed-off-by: Kandpal, Suraj 
> ---
>  drivers/gpu/drm/vkms/vkms_writeback.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
> b/drivers/gpu/drm/vkms/vkms_writeback.c
> index 8694227f555f..6de0c4213425 100644
> --- a/drivers/gpu/drm/vkms/vkms_writeback.c
> +++ b/drivers/gpu/drm/vkms/vkms_writeback.c
> @@ -114,7 +114,7 @@ static void vkms_wb_atomic_commit(struct
> drm_connector *conn,
>   struct vkms_device *vkmsdev = drm_device_to_vkms_device(conn-
> >dev);
>   struct vkms_output *output = >output;
>   struct drm_writeback_connector *wb_conn = 
> >wb_connector;
> - struct drm_connector_state *conn_state = wb_conn->base.state;
> + struct drm_connector_state *conn_state = wb_conn->base->state;
>   struct vkms_crtc_state *crtc_state = output->composer_state;
> 
>   if (!conn_state)
> @@ -140,8 +140,8 @@ int vkms_enable_writeback_connector(struct
> vkms_device *vkmsdev)  {
>   struct drm_writeback_connector *wb = 
> >output.wb_connector;
> 
> - vkmsdev->output.wb_connector.encoder.possible_crtcs = 1;
> - drm_connector_helper_add(>base,
> _wb_conn_helper_funcs);
> + vkmsdev->output.wb_connector.encoder->possible_crtcs = 1;
> + drm_connector_helper_add(wb->base,
> _wb_conn_helper_funcs);
> 
>   return drm_writeback_connector_init(>drm, wb,
>   _wb_connector_funcs,
Regards,
Suraj Kandpal


Re: [Intel-gfx] [RFC PATCH v2 0/3] i915 writeback private framework

2022-04-05 Thread Kandpal, Suraj
Hi All,
Gentle Reminder.
++Uma

Regards
Suraj Kandapal

> A patch series was floated in the drm mailing list which aimed to change the
> drm_connector and drm_encoder fields to pointer in the
> drm_connector_writeback structure, this received a huge pushback from the
> community but since i915 expects each connector present in the drm_device
> list to be a intel_connector but drm_writeback framework forces us to use a
> drm_connector which is not embedded in intel_connector the current
> drm_writeback framework becomes very unfeasible to us as it would mean a
> lot of checks at a lot of places to take into account the above issue. One of
> the solutions is to make our own writeback pipeline bypassing one provided
> by drm which is what these patches do.
> 
> -
> Version 2:
> adding fixes to avoid regression in previous gen and some basic checkpatch
> changes.
> 
> Suraj Kandpal (3):
>   drm/i915: Creating writeback pipeline to bypass drm_writeback
> framework
>   drm/i915: Define WD trancoder for i915
>   drm/i915: Enabling WD Transcoder
> 
>  drivers/gpu/drm/i915/Makefile |   2 +
>  drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  89 +-
> drivers/gpu/drm/i915/display/intel_display.h  |  15 +
>  .../drm/i915/display/intel_display_types.h|  18 +
>  drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
>  drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
>  .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
> .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
>  drivers/gpu/drm/i915/display/intel_wd.c   | 978 ++
>  drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   5 +
>  drivers/gpu/drm/i915/i915_irq.c   |   8 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   7 +-
>  drivers/gpu/drm/i915/i915_reg.h   | 139 +++
>  15 files changed, 1742 insertions(+), 3 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_wb_connector.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
> 
> --
> 2.35.1



Re: [Intel-gfx] [RFC PATCH v2 1/3] drm/i915: Creating writeback pipeline to bypass drm_writeback framework

2022-04-05 Thread Kandpal, Suraj
++Uma

Regards,
Suraj Kandpal

> Changes to create a i915 private pipeline to enable the WD transcoder
> without relying on the current drm_writeback framework.
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  .../drm/i915/display/intel_display_types.h|   4 +
>  .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++
> .../gpu/drm/i915/display/intel_wb_connector.h |  99 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   3 +
>  5 files changed, 403 insertions(+)
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1a771ee5b1d0..087bd9d1b397 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -286,6 +286,7 @@ i915-y += \
>   display/intel_tv.o \
>   display/intel_vdsc.o \
>   display/intel_vrr.o \
> + display/intel_wb_connector.o\
>   display/vlv_dsi.o \
>   display/vlv_dsi_pll.o
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index d84e82f3eab9..7a96ecba73c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -52,6 +52,7 @@
>  #include "intel_display_power.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_pm_types.h"
> +#include "intel_wb_connector.h"
> 
>  struct drm_printer;
>  struct __intel_global_objs_state;
> @@ -537,11 +538,14 @@ struct intel_connector {
>   struct work_struct modeset_retry_work;
> 
>   struct intel_hdcp hdcp;
> +
> + struct intel_writeback_connector wb_conn;
>  };
> 
>  struct intel_digital_connector_state {
>   struct drm_connector_state base;
> 
> + struct intel_writeback_job *job;
>   enum hdmi_force_audio force_audio;
>   int broadcast_rgb;
>  };
> diff --git a/drivers/gpu/drm/i915/display/intel_wb_connector.c
> b/drivers/gpu/drm/i915/display/intel_wb_connector.c
> new file mode 100644
> index ..65f4abef53d0
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_wb_connector.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2022 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> +sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> +the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> +next
> + * paragraph) shall be included in all copies or substantial portions
> +of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> +EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> EVENT
> +SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> +OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> +DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *   Suraj Kandpal 
> + *   Arun Murthy 
> + *
> + */
> +
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "i915_drv.h"
> +#include "intel_wb_connector.h"
> +#include "intel_display_types.h"
> +
> +#define fence_to_wb_connector(x) container_of(x->lock, \
> +   struct intel_writeback_connector,
> \
> +   fence_lock)
> +
> +static const char *intel_writeback_fence_get_driver_name(struct
> +dma_fence *fence) {
> + struct intel_writeback_connector *wb_connector =
> + fence_to_wb_connector(fence);
> +
> + return wb_connector->base->dev->driver->name;
> +}
> +
> +static const char *
> +intel_writeback_fence_get_timeline_name(struct dma_fence *fence) {
> + struct intel_writeback_connector *wb_connector =
> + fence_to_wb_connector(fence);
> +
> + return wb_connector->timeline_name;
> +}
> +
> +static bool intel_writeback_fence_enable_signaling(struct dma_fence
> +*fence) {
> + return true;
> +}
> +
> +static const struct dma_fence_ops intel_writeback_fence_ops = {
> + .get_driver_name = intel_writeback_fence_get_driver_name,
> + .get_timeline_name = intel_writeback_fence_get_timeline_name,
> + .enable_signaling = intel_writeback_fence_enable_signaling,
> +};
> +
> +static int 

Re: [Intel-gfx] [RFC PATCH v2 2/3] drm/i915: Define WD trancoder for i915

2022-04-05 Thread Kandpal, Suraj
Hi All,
++Uma

Regards,
Suraj Kandpal

> -Original Message-
> From: Kandpal, Suraj 
> Sent: Thursday, March 17, 2022 2:09 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; ville.syrj...@linux.intel.com;
> Murthy, Arun R ; Kandpal, Suraj
> 
> Subject: [RFC PATCH v2 2/3] drm/i915: Define WD trancoder for i915
> 
> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_display.h   | 6 ++
>  drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
>  drivers/gpu/drm/i915/i915_reg.h| 2 ++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 8513703086b7..8c93a5de8e07 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -119,6 +119,8 @@ enum transcoder {
>   TRANSCODER_DSI_1,
>   TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
>   TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
> + TRANSCODER_WD_0,
> + TRANSCODER_WD_1,
> 
>   I915_MAX_TRANSCODERS
>  };
> @@ -140,6 +142,10 @@ static inline const char *transcoder_name(enum
> transcoder transcoder)
>   return "DSI A";
>   case TRANSCODER_DSI_C:
>   return "DSI C";
> + case TRANSCODER_WD_0:
> + return "WD 0";
> + case TRANSCODER_WD_1:
> + return "WD 1";
>   default:
>   return "";
>   }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 7a96ecba73c0..dcb4ad43cf88 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -79,6 +79,7 @@ enum intel_output_type {
>   INTEL_OUTPUT_DSI = 9,
>   INTEL_OUTPUT_DDI = 10,
>   INTEL_OUTPUT_DP_MST = 11,
> + INTEL_OUTPUT_WD = 12,
>  };
> 
>  enum hdmi_force_audio {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index ddbc7a685a50..6396afd77209
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2023,6 +2023,8 @@
>  #define TRANSCODER_EDP_OFFSET 0x6f000
>  #define TRANSCODER_DSI0_OFFSET   0x6b000
>  #define TRANSCODER_DSI1_OFFSET   0x6b800
> +#define TRANSCODER_WD0_OFFSET0x6e000
> +#define TRANSCODER_WD1_OFFSET0x6e800
> 
>  #define HTOTAL(trans)_MMIO_TRANS2(trans, _HTOTAL_A)
>  #define HBLANK(trans)_MMIO_TRANS2(trans, _HBLANK_A)
> --
> 2.35.1



Re: [Intel-gfx] [RFC PATCH v2 3/3] drm/i915: Enabling WD Transcoder

2022-04-05 Thread Kandpal, Suraj
Hi All,
++Uma

Regards,
Suraj Kandpal
> Adding support for writeback transcoder to start capturing frames using
> interrupt mechanism
> 
> Signed-off-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/Makefile |   1 +
>  drivers/gpu/drm/i915/display/intel_acpi.c |   1 +
>  drivers/gpu/drm/i915/display/intel_display.c  |  89 +-
>  drivers/gpu/drm/i915/display/intel_display.h  |   9 +
>  .../drm/i915/display/intel_display_types.h|  13 +
>  drivers/gpu/drm/i915/display/intel_dpll.c |   3 +
>  drivers/gpu/drm/i915/display/intel_opregion.c |   3 +
>  drivers/gpu/drm/i915/display/intel_wd.c   | 978 ++
>  drivers/gpu/drm/i915/display/intel_wd.h   |  82 ++
>  drivers/gpu/drm/i915/i915_drv.h   |   2 +
>  drivers/gpu/drm/i915/i915_irq.c   |   8 +-
>  drivers/gpu/drm/i915/i915_pci.c   |   7 +-
>  drivers/gpu/drm/i915/i915_reg.h   | 137 +++
>  13 files changed, 1330 insertions(+), 3 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_wd.c
>  create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 087bd9d1b397..5ee32513a945 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -287,6 +287,7 @@ i915-y += \
>   display/intel_vdsc.o \
>   display/intel_vrr.o \
>   display/intel_wb_connector.o\
> + display/intel_wd.o\
>   display/vlv_dsi.o \
>   display/vlv_dsi_pll.o
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index e78430001f07..ae08db164f73 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector
> *connector)
>   case DRM_MODE_CONNECTOR_LVDS:
>   case DRM_MODE_CONNECTOR_eDP:
>   case DRM_MODE_CONNECTOR_DSI:
> + case DRM_MODE_CONNECTOR_WRITEBACK:
>   display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
>   break;
>   case DRM_MODE_CONNECTOR_Unknown:
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index eb49973621f0..6dedc7921f54 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -111,6 +111,7 @@
>  #include "intel_sprite.h"
>  #include "intel_tc.h"
>  #include "intel_vga.h"
> +#include "intel_wd.h"
>  #include "i9xx_plane.h"
>  #include "skl_scaler.h"
>  #include "skl_universal_plane.h"
> @@ -1544,6 +1545,72 @@ static void
> intel_encoders_update_complete(struct intel_atomic_state *state)
>   }
>  }
> 
> +static void intel_queue_writeback_job(struct intel_atomic_state *state,
> + struct intel_crtc *intel_crtc, struct intel_crtc_state 
> *crtc_state)
> {
> + struct drm_connector_state *new_conn_state;
> + struct drm_connector *connector;
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_wd *intel_wd;
> + struct intel_connector *intel_connector;
> + struct intel_digital_connector_state *intel_conn_state;
> + struct intel_encoder *encoder;
> + int i;
> +
> + for_each_intel_encoder_with_wd(>drm, encoder) {
> + intel_wd = enc_to_intel_wd(encoder);
> +
> + if (intel_wd->wd_crtc != intel_crtc)
> + return;
> +
> + }
> +
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state,
> + i) {
> + intel_conn_state =
> to_intel_digital_connector_state(new_conn_state);
> + if (!intel_conn_state->job)
> + continue;
> + intel_connector = to_intel_connector(connector);
> + intel_writeback_queue_job(_connector->wb_conn,
> new_conn_state);
> + drm_dbg_kms(>drm, "queueing writeback job\n");
> + }
> +}
> +
> +static void intel_find_writeback_connector(struct intel_atomic_state *state,
> + struct intel_crtc *intel_crtc, struct intel_crtc_state 
> *crtc_state)
> {
> + struct drm_connector_state *new_conn_state;
> + struct drm_connector *connector;
> + struct drm_i915_private *i915 = to_i915(intel_crtc->base.dev);
> + struct intel_wd *intel_wd;
> + struct intel_encoder *encoder;
> + int i;
> +
> + for_each_intel_encoder_with_wd(>drm, encoder) {
> + intel_wd = enc_to_intel_wd(encoder);
> +
> + if (intel_wd->wd_crtc != intel_crtc)
> + return;
> +
> + }
> +
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state,
> + i) {
> + struct intel_connector *intel_connector;
> +
> + intel_connector = to_intel_connector(connector);
> + drm_dbg_kms(>drm, "[CONNECTOR:%d:%s]: status:
> %s\n",
> + 

Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and initialize HDMI audio capabilities

2023-09-05 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and initialize 
> HDMI
> audio capabilities
> 
> Initialize the source audio capabilities in the crtc_state property, setting 
> them to

Nit: maybe mention the above as intel_crtc_state rather than crtc_state 
property as
property usually refer to as drm_property and it just seems a little weird to
read. I have seen this in some of your previous patches in this series you can 
make the
changes there as well.

> their maximum supported values for max_channel and max_rate. This
> initialization enables the calculation of audio source capabilities 
> concerning the
> available mode bandwidth. These capabilities encompass parameters such as
> supported rate and channel configurations.
> 
> Additionally, introduces a wrapper function for computing Short Audio
> Descriptors (SADs). The wrapper function incorporates logic for determining

Typo * introduce

> supported rates and channels according to the capabilities of the audio 
> source.
> It returns a set of SADs that are compatible with the audio source's 
> capabilities.
> 
> --v1:
> - Refactor max_channel and max_rate to this commit as it is being initialised
> here
> - Remove call for intel_audio_compute_eld to avoid any regression while
> merge. instead call it in different commit when it is defined.
> - Use int instead of unsigned int for max_channel and max_frequecy
> - Update commit message and header
> 
> --v2:
> - Use signed instead of unsigned variables.
> - Avoid using magic numbers and give them proper name.
> 
> --v3:
> - Move defines to intel_audio.c.
> - use consistent naming convention for rate and channel.
> - declare num_of_channel and aud_rate separately.
> - Declare index value outside of for loop.
> - Move Bandwidth calculation to intel_Audio.c as it is common for both DP and
> HDMI. Also use static.
> 
> --v10:
> - Merged patch 2 and 3 to deduplicate function calls.
> - Instead using Calibrate and calculated functions separately, removed code
> duplication and merged functions.[Nikula, Jani]
> - Remove magic value for SAD Channel mask. [Nikula, Jani]
> - Corrected rate values based on HDMI Spec [Nikula, Jani]
> - Update drm function to extract SAD from ELD [Nikula, Jani]
> 
> Signed-off-by: Mitul Golani 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c| 127 ++
>  .../drm/i915/display/intel_display_types.h|   6 +
>  2 files changed, 133 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index e20ffc8e9654..2584096d80a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -64,6 +64,10 @@
>   * struct _audio_component_audio_ops @audio_ops is called from i915
> driver.
>   */
> 
> +#define AUDIO_SAMPLE_CONTAINER_SIZE  32
> +#define MAX_CHANNEL_COUNT8
> +#define ELD_SAD_CHANNELS_MASK0x7

Use REG_GENMASK() to create masks should look cleaner

> +
>  struct intel_audio_funcs {
>   void (*audio_codec_enable)(struct intel_encoder *encoder,
>  const struct intel_crtc_state *crtc_state, @@
> -770,6 +774,127 @@ void intel_audio_sdp_split_update(struct intel_encoder
> *encoder,
>crtc_state->sdp_split_enable ?
> AUD_ENABLE_SDP_SPLIT : 0);  }
> 
> +static int sad_to_channels(const u8 *sad) {
> + return 1 + (sad[0] & 0x7);
 
I think you missed using your defined mask here;

> +}
> +
> +static int calc_audio_bw(int channel_count, int rate) {
> + int bandwidth = channel_count * rate *
> AUDIO_SAMPLE_CONTAINER_SIZE;
> + return bandwidth;

Why introduce a variable here why not just 
return channel_count * rate * AUDIO_SAMPLE_CONTAINER_SIZE;

> +}
> +
> +static void calc_and_calibrate_audio_config_params(struct intel_crtc_state
> *pipe_config,
> +int channel, bool
> calibration_required) {

I think this should have a int type function that returns 0 if max_rate and 
max_channel_count
are non zero else return -EINVAL

> + struct drm_display_mode *adjusted_mode = _config-
> >hw.adjusted_mode;
> + int channel_count;
> + int index, rate[] = { 192000, 176400, 96000, 88200, 48000, 44100,
> 32000 };

Where do we get these rate values from.
What if we kept them at crtc_state so these can be update if required.

> + int audio_req_bandwidth, available_blank_bandwidth, vblank, hblank;
> +
> + hblank = adjusted_mode->htotal - adjusted_mode->hdisplay;
> + vblank = adjusted_mode->vtotal - adjusted_mode->vdisplay;
> + available_blank_bandwidth = hblank * vblank *
> + drm_mode_vrefresh(adjusted_mode) * pipe_config->pipe_bpp;
> +
> + /*
> +  * Expected calibration of channels and respective rates,
> +  * based on MAX_CHANNEL_COUNT. First calculate channel and
> +  * rate based on Maximum that source can compute, letter
> +  * with respect to 

Re: [Intel-gfx] [PATCH 2/3] drm: Add Wrapper Functions for ELD SAD Extraction

2023-09-05 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH 2/3] drm: Add Wrapper Functions for ELD SAD
> Extraction
> 
> Add wrapper functions to facilitate extracting Short Audio Descriptor (SAD)
> information from EDID-Like Data (ELD) pointers with different constness
> requirements.
> 
> 1. `drm_eld_sad`: This function returns a constant `uint8_t` pointer and wraps
> the main extraction function, allowing access to SAD information while
> maintaining const correctness.
> 
> 2. `drm_extract_sad_from_eld`: This function returns a mutable `uint8_t`
> pointer and implements the core logic for extracting SAD from the provided ELD
> pointer. It performs version and maximum channel checks to ensure proper
> extraction.
> 
> These wrapper functions provide flexibility to the codebase, allowing users to
> access SAD information while adhering to const correctness when needed and
> modifying the pointer when required.
> 
> Signed-off-by: Mitul Golani 

This should also be floated in drm-devel mailing list.

> ---
>  include/drm/drm_edid.h | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h index
> 48e93f909ef6..626bc0d542eb 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -418,11 +418,7 @@ static inline int drm_eld_mnl(const uint8_t *eld)
>   return (eld[DRM_ELD_CEA_EDID_VER_MNL] &
> DRM_ELD_MNL_MASK) >> DRM_ELD_MNL_SHIFT;  }
> 
> -/**
> - * drm_eld_sad - Get ELD SAD structures.
> - * @eld: pointer to an eld memory structure with sad_count set
> - */
> -static inline const uint8_t *drm_eld_sad(const uint8_t *eld)
> +static uint8_t *drm_extract_sad_from_eld(uint8_t *eld)
>  {
>   unsigned int ver, mnl;
> 
> @@ -437,6 +433,15 @@ static inline const uint8_t *drm_eld_sad(const uint8_t
> *eld)
>   return eld + DRM_ELD_CEA_SAD(mnl, 0);
>  }
> 
> +/**
> + * drm_eld_sad - Get ELD SAD structures.
> + * @eld: pointer to an eld memory structure with sad_count set  */
> +static inline const uint8_t *drm_eld_sad(const uint8_t *eld) {
> + return drm_extract_sad_from_eld((uint8_t *)eld); }
> +

Not sure about the wrapper here the point of the const variable here was we do 
not want the eld to be changed
but adding a wrapper seems to make it irrelevant
Also why do you want to change pointer data that is a const.

Regards,
Suraj Kandpal
>  /**
>   * drm_eld_sad_count - Get ELD SAD count.
>   * @eld: pointer to an eld memory structure with sad_count set
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 1/8] drm/i915/dsc: improve clarify of the pps reg read/write helpers

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 1/8] drm/i915/dsc: improve clarify of the pps reg read/write
> helpers

Should be clarity here in the commit header

With that fixed
Reviewed-by: Suraj Kandpal 
> 
> Make it clear what's the number of vdsc per pipe, and what's the number of
> registers to grab. Have intel_dsc_get_pps_reg() return the registers it knows
> even if the requested amount is bigger.
> 
> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 40 ---
>  1 file changed, 21 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index b24601d0b2c5..14317bb6d3df 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -372,7 +372,7 @@ int intel_dsc_get_num_vdsc_instances(const struct
> intel_crtc_state *crtc_state)  }
> 
>  static void intel_dsc_get_pps_reg(const struct intel_crtc_state *crtc_state, 
> int
> pps,
> -   i915_reg_t *dsc_reg, int vdsc_per_pipe)
> +   i915_reg_t *dsc_reg, int dsc_reg_num)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder; @@ -
> 381,16 +381,12 @@ static void intel_dsc_get_pps_reg(const struct
> intel_crtc_state *crtc_state, int
> 
>   pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
> 
> - switch (vdsc_per_pipe) {
> - case 2:
> + if (dsc_reg_num >= 3)
> + MISSING_CASE(dsc_reg_num);
> + if (dsc_reg_num >= 2)
>   dsc_reg[1] = pipe_dsc ? ICL_DSC1_PPS(pipe, pps) :
> DSCC_PPS(pps);
> - fallthrough;
> - case 1:
> + if (dsc_reg_num >= 1)
>   dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS(pipe, pps) :
> DSCA_PPS(pps);
> - break;
> - default:
> - MISSING_CASE(vdsc_per_pipe);
> - }
>  }
> 
>  static void intel_dsc_write_pps_reg(const struct intel_crtc_state 
> *crtc_state,
> @@ -399,13 +395,16 @@ static void intel_dsc_write_pps_reg(const struct
> intel_crtc_state *crtc_state,
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   i915_reg_t dsc_reg[2];
> - int i, vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
> + int i, vdsc_per_pipe, dsc_reg_num;
> +
> + vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
> + dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe);
> 
> - drm_WARN_ON_ONCE(>drm, ARRAY_SIZE(dsc_reg) <
> vdsc_per_pipe);
> + drm_WARN_ON_ONCE(>drm, dsc_reg_num < vdsc_per_pipe);
> 
> - intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, vdsc_per_pipe);
> + intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
> 
> - for (i = 0; i < min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe); i++)
> + for (i = 0; i < dsc_reg_num; i++)
>   intel_de_write(i915, dsc_reg[i], pps_val);  }
> 
> @@ -815,16 +814,19 @@ static bool intel_dsc_read_pps_reg(struct
> intel_crtc_state *crtc_state,  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> - const int vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
>   i915_reg_t dsc_reg[2];
> - int i;
> + int i, vdsc_per_pipe, dsc_reg_num;
> 
> - *pps_val = 0;
> - drm_WARN_ON_ONCE(>drm, ARRAY_SIZE(dsc_reg) <
> vdsc_per_pipe);
> + vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
> + dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe);
> 
> - intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, vdsc_per_pipe);
> + drm_WARN_ON_ONCE(>drm, dsc_reg_num < vdsc_per_pipe);
> +
> + intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
> +
> + *pps_val = 0;
> 
> - for (i = 0; i < min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe); i++) {
> + for (i = 0; i < dsc_reg_num; i++) {
>   u32 pps_temp;
> 
>   pps_temp = intel_de_read(i915, dsc_reg[i]);
> --
> 2.39.2



Re: [Intel-gfx] [PATCH 3/8] drm/i915/dsc: have intel_dsc_pps_read() return the value

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 3/8] drm/i915/dsc: have intel_dsc_pps_read() return the value
> 
> Register read functions usually return the value instead of passing via 
> pointer
> parameters. Return the multiple register verification results via a pointer
> parameter, which can also be NULL to skip the extra checks.
> 
> Make the name conform to existing style better while at it.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 32 ++-
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index abb2c4370231..b0be6615a865 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -809,13 +809,14 @@ void intel_dsc_disable(const struct intel_crtc_state
> *old_crtc_state)
>   }
>  }
> 
> -static bool intel_dsc_read_pps_reg(struct intel_crtc_state *crtc_state,
> -int pps, u32 *pps_val)
> +static u32 intel_dsc_pps_read(struct intel_crtc_state *crtc_state, int pps,
> +   bool *check_equal)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   i915_reg_t dsc_reg[2];
>   int i, vdsc_per_pipe, dsc_reg_num;
> + u32 val = 0;
> 
>   vdsc_per_pipe = intel_dsc_get_vdsc_per_pipe(crtc_state);
>   dsc_reg_num = min_t(int, ARRAY_SIZE(dsc_reg), vdsc_per_pipe); @@ -
> 824,20 +825,25 @@ static bool intel_dsc_read_pps_reg(struct intel_crtc_state
> *crtc_state,
> 
>   intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, dsc_reg_num);
> 
> - *pps_val = 0;
> + if (check_equal)
> + *check_equal = true;
> 
>   for (i = 0; i < dsc_reg_num; i++) {
> - u32 pps_temp;
> + u32 tmp;
> 
> - pps_temp = intel_de_read(i915, dsc_reg[i]);
> + tmp = intel_de_read(i915, dsc_reg[i]);
> 
> - if (i == 0)
> - *pps_val = pps_temp;
> - else if (pps_temp != *pps_val)
> - return false;
> + if (i == 0) {
> + val = tmp;
> + } else if (check_equal && tmp != val) {
> + *check_equal = false;
> + break;
> + } else if (!check_equal) {
> + break;
> + }
>   }
> 
> - return true;
> + return val;
>  }
> 
>  static u32 intel_dsc_pps_read_and_verify(struct intel_crtc_state *crtc_state,
> int pps) @@ -845,10 +851,10 @@ static u32
> intel_dsc_pps_read_and_verify(struct intel_crtc_state *crtc_state, in
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
>   u32 val;
> - int ret;
> + bool all_equal;
> 
> - ret = intel_dsc_read_pps_reg(crtc_state, pps, );
> - drm_WARN_ON(>drm, !ret);
> + val = intel_dsc_pps_read(crtc_state, pps, _equal);
> + drm_WARN_ON(>drm, !all_equal);
> 
>   return val;
>  }
> --
> 2.39.2



Re: [Intel-gfx] [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content macros

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content
> macros
> 
> Improve clarity by specifying the PPS number in the register content macros. 
> It's
> easier to notice if macros are being used for the wrong register.

LGTM.

Reviewed-by : Suraj Kandpal 

> 
> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Probably easiest to review by applying and using 'git show --word-diff'
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 146 -
>  .../gpu/drm/i915/display/intel_vdsc_regs.h| 152 +-
>  2 files changed, 149 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 4855514d7b09..126aff804e33 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -423,109 +423,109 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   int vdsc_instances_per_pipe =
> intel_dsc_get_vdsc_per_pipe(crtc_state);
> 
>   /* PPS 0 */
> - 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;
> + pps_val = DSC_PPS0_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> + DSC_PPS0_VER_MIN_SHIFT |
> + vdsc_cfg->bits_per_component << DSC_PPS0_BPC_SHIFT |
> + vdsc_cfg->line_buf_depth <<
> DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
>   if (vdsc_cfg->dsc_version_minor == 2) {
> - pps_val |= DSC_ALT_ICH_SEL;
> + pps_val |= DSC_PPS0_ALT_ICH_SEL;
>   if (vdsc_cfg->native_420)
> - pps_val |= DSC_NATIVE_420_ENABLE;
> + pps_val |= DSC_PPS0_NATIVE_420_ENABLE;
>   if (vdsc_cfg->native_422)
> - pps_val |= DSC_NATIVE_422_ENABLE;
> + pps_val |= DSC_PPS0_NATIVE_422_ENABLE;
>   }
>   if (vdsc_cfg->block_pred_enable)
> - pps_val |= DSC_BLOCK_PREDICTION;
> + pps_val |= DSC_PPS0_BLOCK_PREDICTION;
>   if (vdsc_cfg->convert_rgb)
> - pps_val |= DSC_COLOR_SPACE_CONVERSION;
> + pps_val |= DSC_PPS0_COLOR_SPACE_CONVERSION;
>   if (vdsc_cfg->simple_422)
> - pps_val |= DSC_422_ENABLE;
> + pps_val |= DSC_PPS0_422_ENABLE;
>   if (vdsc_cfg->vbr_enable)
> - pps_val |= DSC_VBR_ENABLE;
> + pps_val |= DSC_PPS0_VBR_ENABLE;
>   drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 0, pps_val);
> 
>   /* PPS 1 */
> - pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel);
> + pps_val = DSC_PPS1_BPP(vdsc_cfg->bits_per_pixel);
>   drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 1, pps_val);
> 
>   /* PPS 2 */
> - pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
> - DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
> + pps_val = DSC_PPS2_PIC_HEIGHT(vdsc_cfg->pic_height) |
> + DSC_PPS2_PIC_WIDTH(vdsc_cfg->pic_width /
> num_vdsc_instances);
>   drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 2, pps_val);
> 
>   /* PPS 3 */
> - pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
> - DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
> + pps_val = DSC_PPS3_SLICE_HEIGHT(vdsc_cfg->slice_height) |
> + DSC_PPS3_SLICE_WIDTH(vdsc_cfg->slice_width);
>   drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 3, pps_val);
> 
>   /* PPS 4 */
> - pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
> - DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
> + pps_val = DSC_PPS4_INITIAL_XMIT_DELAY(vdsc_cfg-
> >initial_xmit_delay) |
> + DSC_PPS4_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
>   drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 4, pps_val);
> 
>   /* PPS 5 */
> - pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
> - DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
> + pps_val = DSC_PPS5_SCALE_INC_INT(vdsc_cfg-
> >scale_increment_interval) |
> + DSC_PPS5_SCALE_DEC_INT(vdsc_cfg-
> >scale_decrement_interval);
>   drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 5, pps_val);
> 
>   /* PPS 6 */
> - pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
> - DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset)
> |
> - DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
> - DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
> + pps_val = 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dsc: have intel_dsc_pps_read_and_verify() return the value

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 2/8] drm/i915/dsc: have intel_dsc_pps_read_and_verify()
> return the value
> 
> Register read functions usually return the value instead of passing via 
> pointer
> parameters. The calling code becomes easier to read.
> 
> Make the name conform to existing style better while at it.
> 
> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 

LGMT.

Reviewed-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 36 ---
>  1 file changed, 19 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 14317bb6d3df..abb2c4370231 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -840,15 +840,17 @@ static bool intel_dsc_read_pps_reg(struct
> intel_crtc_state *crtc_state,
>   return true;
>  }
> 
> -static void intel_dsc_read_and_verify_pps_reg(struct intel_crtc_state
> *crtc_state,
> -   int pps, u32 *pps_val)
> +static u32 intel_dsc_pps_read_and_verify(struct intel_crtc_state
> +*crtc_state, int pps)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + u32 val;
>   int ret;
> 
> - ret = intel_dsc_read_pps_reg(crtc_state, pps, pps_val);
> + ret = intel_dsc_read_pps_reg(crtc_state, pps, );
>   drm_WARN_ON(>drm, !ret);
> +
> + return val;
>  }
> 
>  static void intel_dsc_get_pps_config(struct intel_crtc_state *crtc_state) @@ 
> -
> 860,7 +862,7 @@ static void intel_dsc_get_pps_config(struct intel_crtc_state
> *crtc_state)
>   u32 pps_temp;
> 
>   /* PPS_0 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 0, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 0);
> 
>   vdsc_cfg->bits_per_component = (pps_temp & DSC_BPC_MASK) >>
> DSC_BPC_SHIFT;
>   vdsc_cfg->line_buf_depth =
> @@ -873,7 +875,7 @@ static void intel_dsc_get_pps_config(struct
> intel_crtc_state *crtc_state)
>   vdsc_cfg->vbr_enable = pps_temp & DSC_VBR_ENABLE;
> 
>   /* PPS_1 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 1, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 1);
> 
>   vdsc_cfg->bits_per_pixel = pps_temp;
> 
> @@ -883,31 +885,31 @@ static void intel_dsc_get_pps_config(struct
> intel_crtc_state *crtc_state)
>   crtc_state->dsc.compressed_bpp = vdsc_cfg->bits_per_pixel >> 4;
> 
>   /* PPS_2 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 2, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 2);
> 
>   vdsc_cfg->pic_width = REG_FIELD_GET(DSC_PIC_WIDTH_MASK,
> pps_temp) / num_vdsc_instances;
>   vdsc_cfg->pic_height = REG_FIELD_GET(DSC_PIC_HEIGHT_MASK,
> pps_temp);
> 
>   /* PPS_3 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 3, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 3);
> 
>   vdsc_cfg->slice_width = REG_FIELD_GET(DSC_SLICE_WIDTH_MASK,
> pps_temp);
>   vdsc_cfg->slice_height = REG_FIELD_GET(DSC_SLICE_HEIGHT_MASK,
> pps_temp);
> 
>   /* PPS_4 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 4, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 4);
> 
>   vdsc_cfg->initial_dec_delay =
> REG_FIELD_GET(DSC_INITIAL_DEC_DELAY_MASK, pps_temp);
>   vdsc_cfg->initial_xmit_delay =
> REG_FIELD_GET(DSC_INITIAL_XMIT_DELAY_MASK, pps_temp);
> 
>   /* PPS_5 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 5, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 5);
> 
>   vdsc_cfg->scale_decrement_interval =
> REG_FIELD_GET(DSC_SCALE_DEC_INT_MASK, pps_temp);
>   vdsc_cfg->scale_increment_interval =
> REG_FIELD_GET(DSC_SCALE_INC_INT_MASK, pps_temp);
> 
>   /* PPS_6 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 6, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 6);
> 
>   vdsc_cfg->initial_scale_value =
> REG_FIELD_GET(DSC_INITIAL_SCALE_VALUE_MASK, pps_temp);
>   vdsc_cfg->first_line_bpg_offset =
> REG_FIELD_GET(DSC_FIRST_LINE_BPG_OFFSET_MASK, pps_temp); @@ -
> 915,41 +917,41 @@ static void intel_dsc_get_pps_config(struct intel_crtc_state
> *crtc_state)
>   vdsc_cfg->flatness_max_qp =
> REG_FIELD_GET(DSC_FLATNESS_MAX_QP_MASK, pps_temp);
> 
>   /* PPS_7 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 7, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 7);
> 
>   vdsc_cfg->nfl_bpg_offset =
> REG_FIELD_GET(DSC_NFL_BPG_OFFSET_MASK, pps_temp);
>   vdsc_cfg->slice_bpg_offset =
> REG_FIELD_GET(DSC_SLICE_BPG_OFFSET_MASK, pps_temp);
> 
>   /* PPS_8 */
> - intel_dsc_read_and_verify_pps_reg(crtc_state, 8, _temp);
> + pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 8);
> 
>   vdsc_cfg->initial_offset = REG_FIELD_GET(DSC_INITIAL_OFFSET_MASK,

Re: [Intel-gfx] [PATCH 6/8] drm/i915/dsc: clean up pps comments

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 6/8] drm/i915/dsc: clean up pps comments
> 
> Unify comments to be the simple "PPS n" instead of all sorts of variants.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 56 +--
>  .../gpu/drm/i915/display/intel_vdsc_regs.h| 29 +-
>  2 files changed, 42 insertions(+), 43 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 73bfa4d6633d..4855514d7b09 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -422,7 +422,7 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   int num_vdsc_instances =
> intel_dsc_get_num_vdsc_instances(crtc_state);
>   int vdsc_instances_per_pipe =
> intel_dsc_get_vdsc_per_pipe(crtc_state);
> 
> - /* Populate PICTURE_PARAMETER_SET_0 registers */
> + /* PPS 0 */
>   pps_val = DSC_VER_MAJ | vdsc_cfg->dsc_version_minor <<
>   DSC_VER_MIN_SHIFT |
>   vdsc_cfg->bits_per_component << DSC_BPC_SHIFT | @@ -
> 445,36 +445,36 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 0, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_1 registers */
> + /* PPS 1 */
>   pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel);
>   drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 1, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_2 registers */
> + /* PPS 2 */
>   pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
>   DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
>   drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 2, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_3 registers */
> + /* PPS 3 */
>   pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
>   DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
>   drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 3, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_4 registers */
> + /* PPS 4 */
>   pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
>   DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
>   drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 4, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_5 registers */
> + /* PPS 5 */
>   pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
>   DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
>   drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 5, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_6 registers */
> + /* PPS 6 */
>   pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
>   DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset)
> |
>   DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) | @@ -
> 482,25 +482,25 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   drm_dbg_kms(_priv->drm, "PPS6 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 6, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_7 registers */
> + /* PPS 7 */
>   pps_val = DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) |
>   DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset);
>   drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 7, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_8 registers */
> + /* PPS 8 */
>   pps_val = DSC_FINAL_OFFSET(vdsc_cfg->final_offset) |
>   DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset);
>   drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 8, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_9 registers */
> + /* PPS 9 */
>   pps_val = DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
>   DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
>   drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 9, pps_val);
> 
> - /* Populate PICTURE_PARAMETER_SET_10 registers */
> + /* PPS 10 */
>   pps_val = DSC_RC_QUANT_INC_LIMIT0(vdsc_cfg-
> >rc_quant_incr_limit0) |
>   DSC_RC_QUANT_INC_LIMIT1(vdsc_cfg->rc_quant_incr_limit1)
> |
>   DSC_RC_TARGET_OFF_HIGH(DSC_RC_TGT_OFFSET_HI_CONST)
> | @@ -508,7 +508,7 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   drm_dbg_kms(_priv->drm, "PPS10 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 10, pps_val);
> 
> - 

Re: [Intel-gfx] [PATCH 8/8] drm/i915/dsc: use REG_BIT, REG_GENMASK, and friends for PPS0 and PPS1

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 8/8] drm/i915/dsc: use REG_BIT, REG_GENMASK, and friends
> for PPS0 and PPS1
> 
> Use the register helper macros for PPS0 and PPS1 register contents.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 15 +--
>  .../gpu/drm/i915/display/intel_vdsc_regs.h| 27 ++-
>  2 files changed, 22 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 126aff804e33..5c00f7ccad7f 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -423,10 +423,10 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   int vdsc_instances_per_pipe =
> intel_dsc_get_vdsc_per_pipe(crtc_state);
> 
>   /* PPS 0 */
> - pps_val = DSC_PPS0_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> - DSC_PPS0_VER_MIN_SHIFT |
> - vdsc_cfg->bits_per_component << DSC_PPS0_BPC_SHIFT |
> - vdsc_cfg->line_buf_depth <<
> DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
> + pps_val = DSC_PPS0_VER_MAJOR(1) |
> + DSC_PPS0_VER_MINOR(vdsc_cfg->dsc_version_minor) |
> + DSC_PPS0_BPC(vdsc_cfg->bits_per_component) |
> + DSC_PPS0_LINE_BUF_DEPTH(vdsc_cfg->line_buf_depth);
>   if (vdsc_cfg->dsc_version_minor == 2) {
>   pps_val |= DSC_PPS0_ALT_ICH_SEL;
>   if (vdsc_cfg->native_420)
> @@ -857,9 +857,8 @@ static void intel_dsc_get_pps_config(struct
> intel_crtc_state *crtc_state)
>   /* PPS 0 */
>   pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 0);
> 
> - vdsc_cfg->bits_per_component = (pps_temp & DSC_PPS0_BPC_MASK)
> >> DSC_PPS0_BPC_SHIFT;
> - vdsc_cfg->line_buf_depth =
> - (pps_temp & DSC_PPS0_LINE_BUF_DEPTH_MASK) >>
> DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
> + vdsc_cfg->bits_per_component =
> REG_FIELD_GET(DSC_PPS0_BPC_MASK, pps_temp);
> + vdsc_cfg->line_buf_depth =
> REG_FIELD_GET(DSC_PPS0_LINE_BUF_DEPTH_MASK,
> +pps_temp);
>   vdsc_cfg->block_pred_enable = pps_temp &
> DSC_PPS0_BLOCK_PREDICTION;
>   vdsc_cfg->convert_rgb = pps_temp &
> DSC_PPS0_COLOR_SPACE_CONVERSION;
>   vdsc_cfg->simple_422 = pps_temp & DSC_PPS0_422_ENABLE; @@ -
> 870,7 +869,7 @@ static void intel_dsc_get_pps_config(struct intel_crtc_state
> *crtc_state)
>   /* PPS 1 */
>   pps_temp = intel_dsc_pps_read_and_verify(crtc_state, 1);
> 
> - vdsc_cfg->bits_per_pixel = pps_temp;
> + vdsc_cfg->bits_per_pixel = REG_FIELD_GET(DSC_PPS1_BPP_MASK,
> pps_temp);
> 
>   if (vdsc_cfg->native_420)
>   vdsc_cfg->bits_per_pixel >>= 1;
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
> b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
> index 92782de2b309..64f440fdc22b 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc_regs.h
> @@ -73,22 +73,25 @@
>  #define  ICL_DSC1_PPS(pipe, pps)
>   _MMIO(_ICL_DSC1_PPS_0(pipe) + ((pps) * 4))
> 
>  /* PPS 0 */
> -#define   DSC_PPS0_NATIVE_422_ENABLE BIT(23)
> -#define   DSC_PPS0_NATIVE_420_ENABLE BIT(22)
> -#define   DSC_PPS0_ALT_ICH_SEL   (1 << 20)
> -#define   DSC_PPS0_VBR_ENABLE(1 << 19)
> -#define   DSC_PPS0_422_ENABLE(1 << 18)
> -#define   DSC_PPS0_COLOR_SPACE_CONVERSION(1 << 17)
> -#define   DSC_PPS0_BLOCK_PREDICTION  (1 << 16)
> -#define   DSC_PPS0_LINE_BUF_DEPTH_SHIFT  12
> +#define   DSC_PPS0_NATIVE_422_ENABLE REG_BIT(23)
> +#define   DSC_PPS0_NATIVE_420_ENABLE REG_BIT(22)
> +#define   DSC_PPS0_ALT_ICH_SEL   REG_BIT(20)
> +#define   DSC_PPS0_VBR_ENABLEREG_BIT(19)
> +#define   DSC_PPS0_422_ENABLEREG_BIT(18)
> +#define   DSC_PPS0_COLOR_SPACE_CONVERSIONREG_BIT(17)
> +#define   DSC_PPS0_BLOCK_PREDICTION  REG_BIT(16)
>  #define   DSC_PPS0_LINE_BUF_DEPTH_MASK   REG_GENMASK(15,
> 12)
> -#define   DSC_PPS0_BPC_SHIFT 8
> +#define   DSC_PPS0_LINE_BUF_DEPTH(depth)
>   REG_FIELD_PREP(DSC_PPS0_LINE_BUF_DEPTH_MASK, depth)
>  #define   DSC_PPS0_BPC_MASK  REG_GENMASK(11, 8)
> -#define   DSC_PPS0_VER_MIN_SHIFT 4
> -#define   DSC_PPS0_VER_MAJ   (0x1 << 0)
> +#define   DSC_PPS0_BPC(bpc)
>   REG_FIELD_PREP(DSC_PPS0_BPC_MASK, bpc)
> +#define   DSC_PPS0_VER_MINOR_MASKREG_GENMASK(7, 4)
> +#define   DSC_PPS0_VER_MINOR(minor)
>   REG_FIELD_PREP(DSC_PPS0_VER_MINOR_MASK, minor)
> +#define   DSC_PPS0_VER_MAJOR_MASKREG_GENMASK(3, 0)
> +#define   DSC_PPS0_VER_MAJOR(major)
>   REG_FIELD_PREP(DSC_PPS0_VER_MAJOR_MASK, major)
> 
>  /* PPS 1 */
> -#define   DSC_PPS1_BPP(bpp)  ((bpp) << 0)
> +#define   

Re: [Intel-gfx] [PATCH 4/8] drm/i915/dsc: rename pps write to intel_dsc_pps_write()

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 4/8] drm/i915/dsc: rename pps write to intel_dsc_pps_write()
> 
> Make the function name conform to existing style better.
> 

LGTM. 

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 32 +++
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index b0be6615a865..4086dbb25ca5 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -389,8 +389,8 @@ static void intel_dsc_get_pps_reg(const struct
> intel_crtc_state *crtc_state, int
>   dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS(pipe, pps) :
> DSCA_PPS(pps);  }
> 
> -static void intel_dsc_write_pps_reg(const struct intel_crtc_state 
> *crtc_state,
> - int pps, u32 pps_val)
> +static void intel_dsc_pps_write(const struct intel_crtc_state *crtc_state,
> + int pps, u32 pps_val)
>  {
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *i915 = to_i915(crtc->base.dev); @@ -443,41
> +443,41 @@ static void intel_dsc_pps_configure(const struct intel_crtc_state
> *crtc_state)
>   if (vdsc_cfg->vbr_enable)
>   pps_val |= DSC_VBR_ENABLE;
>   drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 0, pps_val);
> + intel_dsc_pps_write(crtc_state, 0, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_1 registers */
>   pps_val = 0;
>   pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel);
>   drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 1, pps_val);
> + intel_dsc_pps_write(crtc_state, 1, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_2 registers */
>   pps_val = 0;
>   pps_val |= DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
>   DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
>   drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 2, pps_val);
> + intel_dsc_pps_write(crtc_state, 2, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_3 registers */
>   pps_val = 0;
>   pps_val |= DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
>   DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
>   drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 3, pps_val);
> + intel_dsc_pps_write(crtc_state, 3, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_4 registers */
>   pps_val = 0;
>   pps_val |= DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
>   DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
>   drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 4, pps_val);
> + intel_dsc_pps_write(crtc_state, 4, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_5 registers */
>   pps_val = 0;
>   pps_val |= DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
>   DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
>   drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 5, pps_val);
> + intel_dsc_pps_write(crtc_state, 5, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_6 registers */
>   pps_val = 0;
> @@ -486,28 +486,28 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
>   DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
>   drm_dbg_kms(_priv->drm, "PPS6 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 6, pps_val);
> + intel_dsc_pps_write(crtc_state, 6, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_7 registers */
>   pps_val = 0;
>   pps_val |= DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) |
>   DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset);
>   drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 7, pps_val);
> + intel_dsc_pps_write(crtc_state, 7, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_8 registers */
>   pps_val = 0;
>   pps_val |= DSC_FINAL_OFFSET(vdsc_cfg->final_offset) |
>   DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset);
>   drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val);
> - intel_dsc_write_pps_reg(crtc_state, 8, pps_val);
> + intel_dsc_pps_write(crtc_state, 8, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_9 registers */
>   pps_val = 0;
>   pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
>   DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
>   drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val);
> - 

Re: [Intel-gfx] [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content macros

2023-09-06 Thread Kandpal, Suraj
> Subject: [PATCH 7/8] drm/i915/dsc: add the PPS number to the register content
> macros
> 
> Improve clarity by specifying the PPS number in the register content macros. 
> It's
> easier to notice if macros are being used for the wrong register.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> 
> ---
> 
> Probably easiest to review by applying and using 'git show --word-diff'
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 146 -
>  .../gpu/drm/i915/display/intel_vdsc_regs.h| 152 +-
>  2 files changed, 149 insertions(+), 149 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 4855514d7b09..126aff804e33 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -423,109 +423,109 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   int vdsc_instances_per_pipe =
> intel_dsc_get_vdsc_per_pipe(crtc_state);
> 
>   /* PPS 0 */
> - 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;
> + pps_val = DSC_PPS0_VER_MAJ | vdsc_cfg->dsc_version_minor <<
> + DSC_PPS0_VER_MIN_SHIFT |
> + vdsc_cfg->bits_per_component << DSC_PPS0_BPC_SHIFT |
> + vdsc_cfg->line_buf_depth <<
> DSC_PPS0_LINE_BUF_DEPTH_SHIFT;
>   if (vdsc_cfg->dsc_version_minor == 2) {
> - pps_val |= DSC_ALT_ICH_SEL;
> + pps_val |= DSC_PPS0_ALT_ICH_SEL;
>   if (vdsc_cfg->native_420)
> - pps_val |= DSC_NATIVE_420_ENABLE;
> + pps_val |= DSC_PPS0_NATIVE_420_ENABLE;
>   if (vdsc_cfg->native_422)
> - pps_val |= DSC_NATIVE_422_ENABLE;
> + pps_val |= DSC_PPS0_NATIVE_422_ENABLE;
>   }
>   if (vdsc_cfg->block_pred_enable)
> - pps_val |= DSC_BLOCK_PREDICTION;
> + pps_val |= DSC_PPS0_BLOCK_PREDICTION;
>   if (vdsc_cfg->convert_rgb)
> - pps_val |= DSC_COLOR_SPACE_CONVERSION;
> + pps_val |= DSC_PPS0_COLOR_SPACE_CONVERSION;
>   if (vdsc_cfg->simple_422)
> - pps_val |= DSC_422_ENABLE;
> + pps_val |= DSC_PPS0_422_ENABLE;
>   if (vdsc_cfg->vbr_enable)
> - pps_val |= DSC_VBR_ENABLE;
> + pps_val |= DSC_PPS0_VBR_ENABLE;
>   drm_dbg_kms(_priv->drm, "PPS0 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 0, pps_val);
> 
>   /* PPS 1 */
> - pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel);
> + pps_val = DSC_PPS1_BPP(vdsc_cfg->bits_per_pixel);
>   drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 1, pps_val);
> 
>   /* PPS 2 */
> - pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
> - DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
> + pps_val = DSC_PPS2_PIC_HEIGHT(vdsc_cfg->pic_height) |
> + DSC_PPS2_PIC_WIDTH(vdsc_cfg->pic_width /
> num_vdsc_instances);
>   drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 2, pps_val);
> 
>   /* PPS 3 */
> - pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
> - DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
> + pps_val = DSC_PPS3_SLICE_HEIGHT(vdsc_cfg->slice_height) |
> + DSC_PPS3_SLICE_WIDTH(vdsc_cfg->slice_width);
>   drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 3, pps_val);
> 
>   /* PPS 4 */
> - pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
> - DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
> + pps_val = DSC_PPS4_INITIAL_XMIT_DELAY(vdsc_cfg-
> >initial_xmit_delay) |
> + DSC_PPS4_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
>   drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 4, pps_val);
> 
>   /* PPS 5 */
> - pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
> - DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
> + pps_val = DSC_PPS5_SCALE_INC_INT(vdsc_cfg-
> >scale_increment_interval) |
> + DSC_PPS5_SCALE_DEC_INT(vdsc_cfg-
> >scale_decrement_interval);
>   drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 5, pps_val);
> 
>   /* PPS 6 */
> - pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
> - DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset)
> |
> - DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
> - DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
> + pps_val = 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4 format

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4 format
> 
> From: Ankit Nautiyal 
> 
> DSC parameter bits_per_pixel is stored in U6.4 format.
> The 4 bits represent the fractional part of the bpp.
> Currently we use compressed_bpp member of dsc structure to store only the
> integral part of the bits_per_pixel.
> To store the full bits_per_pixel along with the fractional part, 
> compressed_bpp
> is changed to store bpp in U6.4 formats. Intergral part is retrieved by simply
> right shifting the member compressed_bpp by 4.
> 
> v2:
> -Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing  with
> compressed bpp. (Suraj) -Fix comment styling. (Suraj)
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c| 10 
>  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  4 +--
>  drivers/gpu/drm/i915/display/intel_cdclk.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  .../drm/i915/display/intel_display_types.h| 18 -
>  drivers/gpu/drm/i915/display/intel_dp.c   | 25 +++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 18 ++---
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 +--
>  9 files changed, 52 insertions(+), 33 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ad6488e9c2b2..df98f35bbcda 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -330,7 +330,7 @@ static int afe_clk(struct intel_encoder *encoder,
>   int bpp;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> 
> @@ -860,7 +860,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>* compressed and non-compressed bpp.
>*/
>   if (crtc_state->dsc.compression_enable) {
> - mul = crtc_state->dsc.compressed_bpp;
> + mul = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
>   }
> 
> @@ -884,7 +884,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>   int bpp, line_time_us, byte_clk_period_ns;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = to_bpp_int(crtc_state-
> >dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
> @@ -1451,8 +1451,8 @@ static void gen11_dsi_get_timings(struct
> intel_encoder *encoder,
>   struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> 
> - if (pipe_config->dsc.compressed_bpp) {
> - int div = pipe_config->dsc.compressed_bpp;
> + if (pipe_config->dsc.compressed_bpp_x16) {
> + int div = to_bpp_int(pipe_config->dsc.compressed_bpp_x16);
>   int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
>   adjusted_mode->crtc_htotal =
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 19605264a35c..aa93ccd6c2aa 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -528,7 +528,7 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = crtc_state->dsc.compressed_bpp;
> + vdsc_bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 858c959f7bab..7b6d299fbcf2 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -3384,8 +3384,8 @@ static void fill_dsc(struct intel_crtc_state 
> *crtc_state,
> 
>   crtc_state->pipe_bpp = bpc * 3;
> 
> - crtc_state->dsc.compressed_bpp = min(crtc_state->pipe_bpp,
> -  VBT_DSC_MAX_BPP(dsc-
> >max_bpp));
> + crtc_state->dsc.compressed_bpp_x16 = to_bpp_x16(min(crtc_state-
> >pipe_bpp,
> +
> VBT_DSC_MAX_BPP(dsc->max_bpp)));
> 
>   /*
>* FIXME: This is ugly, and slice count should take DSC engine diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_cdclk.c
> 

Re: [Intel-gfx] [PATCH 6/8] drm/i915/dp: Iterate over output bpp with fractional step size

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 6/8] drm/i915/dp: Iterate over output bpp with fractional step
> size
> 
> From: Ankit Nautiyal 
> 
> This patch adds support to iterate over compressed output bpp as per the
> fractional step, supported by DP sink.
> 
> v2:
> -Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
> 

LGTM.
Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 37 +++--
>  1 file changed, 23 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index d13fa2749eaf..90c92f3dc62a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1715,15 +1715,15 @@ static bool intel_dp_dsc_supports_format(struct
> intel_dp *intel_dp,
>   return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> sink_dsc_format);  }
> 
> -static bool is_bw_sufficient_for_dsc_config(u16 compressed_bpp, u32
> link_clock,
> +static bool is_bw_sufficient_for_dsc_config(u16 compressed_bppx16, u32
> +link_clock,
>   u32 lane_count, u32 mode_clock,
>   enum intel_output_format
> output_format,
>   int timeslots)
>  {
>   u32 available_bw, required_bw;
> 
> - available_bw = (link_clock * lane_count * timeslots)  / 8;
> - required_bw = compressed_bpp *
> (intel_dp_mode_to_fec_clock(mode_clock));
> + available_bw = (link_clock * lane_count * timeslots * 16)  / 8;
> + required_bw = compressed_bppx16 *
> +(intel_dp_mode_to_fec_clock(mode_clock));
> 
>   return available_bw > required_bw;
>  }
> @@ -1731,7 +1731,7 @@ static bool is_bw_sufficient_for_dsc_config(u16
> compressed_bpp, u32 link_clock,  static int dsc_compute_link_config(struct
> intel_dp *intel_dp,
>  struct intel_crtc_state *pipe_config,
>  struct link_config_limits *limits,
> -u16 compressed_bpp,
> +u16 compressed_bppx16,
>  int timeslots)
>  {
>   const struct drm_display_mode *adjusted_mode = _config-
> >hw.adjusted_mode; @@ -1746,8 +1746,8 @@ static int
> dsc_compute_link_config(struct intel_dp *intel_dp,
>   for (lane_count = limits->min_lane_count;
>lane_count <= limits->max_lane_count;
>lane_count <<= 1) {
> - if (!is_bw_sufficient_for_dsc_config(compressed_bpp,
> link_rate, lane_count,
> -  adjusted_mode-
> >clock,
> + if
> (!is_bw_sufficient_for_dsc_config(compressed_bppx16, link_rate,
> +  lane_count,
> adjusted_mode->clock,
>pipe_config-
> >output_format,
>timeslots))
>   continue;
> @@ -1860,7 +1860,7 @@ icl_dsc_compute_link_config(struct intel_dp
> *intel_dp,
>   ret = dsc_compute_link_config(intel_dp,
> pipe_config,
> limits,
> -   valid_dsc_bpp[i],
> +   valid_dsc_bpp[i] << 4,
> timeslots);
>   if (ret == 0) {
>   pipe_config->dsc.compressed_bpp_x16 =
> to_bpp_x16(valid_dsc_bpp[i]); @@ -1886,22 +1886,31 @@
> xelpd_dsc_compute_link_config(struct intel_dp *intel_dp,
> int pipe_bpp,
> int timeslots)
>  {
> - u16 compressed_bpp;
> + u8 bppx16_incr = drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u16 compressed_bppx16;
> + u8 bppx16_step;
>   int ret;
> 
> + if (DISPLAY_VER(i915) < 14 || bppx16_incr <= 1)
> + bppx16_step = 16;
> + else
> + bppx16_step = 16 / bppx16_incr;
> +
>   /* Compressed BPP should be less than the Input DSC bpp */
> - dsc_max_bpp = min(dsc_max_bpp, pipe_bpp - 1);
> + dsc_max_bpp = min(dsc_max_bpp << 4, (pipe_bpp << 4) -
> bppx16_step);
> + dsc_min_bpp = dsc_min_bpp << 4;
> 
> - for (compressed_bpp = dsc_max_bpp;
> -  compressed_bpp >= dsc_min_bpp;
> -  compressed_bpp--) {
> + for (compressed_bppx16 = dsc_max_bpp;
> +  compressed_bppx16 >= dsc_min_bpp;
> +  compressed_bppx16 -= bppx16_step) {
>   ret = dsc_compute_link_config(intel_dp,
> pipe_config,
> limits,
> -   

Re: [Intel-gfx] [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp prescision

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp
> prescision
> 
> From: Ankit Nautiyal 
> 
> Add helper to get the DSC bits_per_pixel precision for the DP sink.

I think this should also be floated in drm-devel mailing list.

Regards,
Suraj Kandpal

> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 27 +
>  include/drm/display/drm_dp_helper.h |  1 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 8a1b64c57dfd..5c23d5b8fc50 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> struct drm_dp_desc *desc,  }  EXPORT_SYMBOL(drm_dp_read_desc);
> 
> +/**
> + * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns the bpp precision supported by the DP sink.
> + */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
> +DP_DSC_SUPPORT];
> +
> + switch (bpp_increment_dpcd) {
> + case DP_DSC_BITS_PER_PIXEL_1_16:
> + return 16;
> + case DP_DSC_BITS_PER_PIXEL_1_8:
> + return 8;
> + case DP_DSC_BITS_PER_PIXEL_1_4:
> + return 4;
> + case DP_DSC_BITS_PER_PIXEL_1_2:
> + return 2;
> + case DP_DSC_BITS_PER_PIXEL_1_1:
> + return 1;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
> +
>  /**
>   * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
>   * supported by the DSC sink.
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 3369104e2d25..6968d4d87931 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -164,6 +164,7 @@ drm_dp_is_branch(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])  }
> 
>  /* DP/eDP DSC support */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
>  u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>  bool is_edp);
>  u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 4/8] drm/i915/audio : Consider fractional vdsc bpp while computing tu_data

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 4/8] drm/i915/audio : Consider fractional vdsc bpp while
> computing tu_data
> 
> From: Ankit Nautiyal 
> 
> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate the precision during calculation of transfer unit data for
> hblank_early calculation.
> 
> v2:
> -Fixed tu_data calculation while dealing with U6.4 format. (Stan)
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index aa93ccd6c2aa..cfbaa7006905 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -521,14 +521,14 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   unsigned int link_clks_available, link_clks_required;
>   unsigned int tu_data, tu_line, link_clks_active;
>   unsigned int h_active, h_total, hblank_delta, pixel_clk;
> - unsigned int fec_coeff, cdclk, vdsc_bpp;
> + unsigned int fec_coeff, cdclk, vdsc_bppx16;
>   unsigned int link_clk, lanes;
>   unsigned int hblank_rise;
> 
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
> + vdsc_bppx16 = crtc_state->dsc.compressed_bpp_x16;
>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
> @@ -536,10 +536,10 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   lanes = crtc_state->lane_count;
> 
>   drm_dbg_kms(>drm, "h_active = %u link_clk = %u :"
> - "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> - h_active, link_clk, lanes, vdsc_bpp, cdclk);
> + "lanes = %u vdsc_bppx16 = %u cdclk = %u\n",
> + h_active, link_clk, lanes, vdsc_bppx16, cdclk);
> 
> - if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp || !cdclk))
> + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bppx16 ||
> +!cdclk))
>   return 0;
> 
>   link_clks_available = (h_total - h_active) * link_clk / pixel_clk - 28; 
> @@
> -551,8 +551,8 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 *
> (link_clk + cdclk), pixel_clk),
> mul_u32_u32(link_clk,
> cdclk));
> 
> - tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8, 100),
> - mul_u32_u32(link_clk * lanes, fec_coeff));
> + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bppx16 * 8,
> 100),
> + mul_u32_u32(link_clk * lanes * 16, fec_coeff));
>   tu_line = div64_u64(h_active * mul_u32_u32(link_clk, fec_coeff),
>   mul_u32_u32(64 * pixel_clk, 100));
>   link_clks_active  = (tu_line - 1) * 64 + tu_data;
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 8/8] drm/i915/dsc: Allow DSC only with fractional bpp when forced from debugfs

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 8/8] drm/i915/dsc: Allow DSC only with fractional bpp when
> forced from debugfs
> 
> From: Swati Sharma 
> 
> If force_dsc_fractional_bpp_en is set through debugfs allow DSC iff
> compressed bpp is fractional. Continue if the computed compressed bpp turns
> out to be a integer.
> 
> v2:
> -Use helpers for fractional, integral bits of bits_per_pixel. (Suraj) -Fix 
> comment
> (Suraj)
> 

LGTM.
Reviewed-by: Suraj Kandpal 

> Signed-off-by: Swati Sharma 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 90c92f3dc62a..f6bfbd89bc3f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1904,6 +1904,9 @@ xelpd_dsc_compute_link_config(struct intel_dp
> *intel_dp,
>   for (compressed_bppx16 = dsc_max_bpp;
>compressed_bppx16 >= dsc_min_bpp;
>compressed_bppx16 -= bppx16_step) {
> + if (intel_dp->force_dsc_fractional_bpp_en &&
> + !to_bpp_frac_dec(compressed_bppx16))
> + continue;
>   ret = dsc_compute_link_config(intel_dp,
> pipe_config,
> limits,
> @@ -1911,6 +1914,10 @@ xelpd_dsc_compute_link_config(struct intel_dp
> *intel_dp,
> timeslots);
>   if (ret == 0) {
>   pipe_config->dsc.compressed_bpp_x16 =
> compressed_bppx16;
> + if (intel_dp->force_dsc_fractional_bpp_en &&
> + to_bpp_frac_dec(compressed_bppx16))
> + drm_dbg_kms(>drm, "Forcing DSC
> fractional bpp\n");
> +
>   return 0;
>   }
>   }
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 3/8] drm/i915/display: Consider fractional vdsc bpp while computing m_n values

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 3/8] drm/i915/display: Consider fractional vdsc bpp while
> computing m_n values
> 
> From: Ankit Nautiyal 
> 
> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate this precision while computing m_n values.
> 


LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c  | 5 +++--
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  | 6 --
>  drivers/gpu/drm/i915/display/intel_fdi.c | 2 +-
>  5 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index afcbdd4f105a..b37aeac961f4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2380,10 +2380,14 @@ void
>  intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
>  int pixel_clock, int link_clock,
>  struct intel_link_m_n *m_n,
> -bool fec_enable)
> +bool fec_enable,
> +bool is_dsc_fractional_bpp)
>  {
>   u32 data_clock = bits_per_pixel * pixel_clock;
> 
> + if (is_dsc_fractional_bpp)
> + data_clock = DIV_ROUND_UP(bits_per_pixel * pixel_clock, 16);
> +
>   if (fec_enable)
>   data_clock = intel_dp_mode_to_fec_clock(data_clock);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 49ac8473b988..a4c4ca3cad65 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -398,7 +398,7 @@ u8 intel_calc_active_pipes(struct intel_atomic_state
> *state,  void intel_link_compute_m_n(u16 bpp, int nlanes,
>   int pixel_clock, int link_clock,
>   struct intel_link_m_n *m_n,
> - bool fec_enable);
> + bool fec_enable, bool is_dsc_fractional_bpp);
>  u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
> u32 pixel_format, u64 modifier);  enum
> drm_mode_status diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 9b88ac3a73c7..d13fa2749eaf 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2558,7 +2558,7 @@ intel_dp_drrs_compute_config(struct
> intel_connector *connector,
> 
>   intel_link_compute_m_n(link_bpp, pipe_config->lane_count,
> pixel_clock,
>  pipe_config->port_clock, _config-
> >dp_m2_n2,
> -pipe_config->fec_enable);
> +pipe_config->fec_enable, false);
> 
>   /* FIXME: abstract this better */
>   if (pipe_config->splitter.enable)
> @@ -2737,7 +2737,8 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>  adjusted_mode->crtc_clock,
>  pipe_config->port_clock,
>  _config->dp_m_n,
> -pipe_config->fec_enable);
> +pipe_config->fec_enable,
> +pipe_config->dsc.compression_enable);
> 
>   /* FIXME: abstract this better */
>   if (pipe_config->splitter.enable)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 68a81f10e772..68630925a0b9 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -171,7 +171,8 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
>  adjusted_mode->crtc_clock,
>  crtc_state->port_clock,
>  _state->dp_m_n,
> -crtc_state->fec_enable);
> +crtc_state->fec_enable,
> +false);
>   crtc_state->dp_m_n.tu = slots;
> 
>   return 0;
> @@ -265,7 +266,8 @@ static int intel_dp_dsc_mst_compute_link_config(struct
> intel_encoder *encoder,
>  adjusted_mode->crtc_clock,
>  crtc_state->port_clock,
>  _state->dp_m_n,
> -crtc_state->fec_enable);
> +crtc_state->fec_enable,
> +crtc_state->dsc.compression_enable);
>   crtc_state->dp_m_n.tu = slots;
> 
>   return 0;
> diff --git a/drivers/gpu/drm/i915/display/intel_fdi.c
> b/drivers/gpu/drm/i915/display/intel_fdi.c
> index e12b46a84fa1..15fddabf7c2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_fdi.c

Re: [Intel-gfx] [PATCH 5/8] drm/i915/dsc/mtl: Add support for fractional bpp

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 5/8] drm/i915/dsc/mtl: Add support for fractional bpp
> 
> From: Vandita Kulkarni 
> 
> Consider the fractional bpp while reading the qp values.
> 
> v2: Use helpers for fractional, integral bits of bits_per_pixel. (Suraj)
> 

LGTM.
Reviewed-by: Suraj Kandpal 

> Signed-off-by: Vandita Kulkarni 
> Signed-off-by: Ankit Nautiyal 
> ---
>  .../gpu/drm/i915/display/intel_qp_tables.c|  3 ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 25 +++
>  2 files changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> index 543cdc46aa1d..600c815e37e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_qp_tables.c
> +++ b/drivers/gpu/drm/i915/display/intel_qp_tables.c
> @@ -34,9 +34,6 @@
>   * These qp tables are as per the C model
>   * and it has the rows pointing to bpps which increment
>   * in steps of 0.5
> - * We do not support fractional bpps as of today,
> - * hence we would skip the fractional bpps during
> - * our references for qp calclulations.
>   */
>  static const u8
> rc_range_minqp444_8bpc[DSC_NUM_BUF_RANGES][RC_RANGE_QP444_8BPC
> _MAX_NUM_BPP] = {
>   { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
> diff --git
> a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index bfc41972a0bb..d7cfb2446c13 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -77,8 +77,8 @@ intel_vdsc_set_min_max_qp(struct drm_dsc_config
> *vdsc_cfg, int buf,  static void  calculate_rc_params(struct drm_dsc_config
> *vdsc_cfg)  {
> + int bpp = to_bpp_int(vdsc_cfg->bits_per_pixel);
>   int bpc = vdsc_cfg->bits_per_component;
> - int bpp = vdsc_cfg->bits_per_pixel >> 4;
>   int qp_bpc_modifier = (bpc - 8) * 2;
>   int uncompressed_bpg_rate;
>   int first_line_bpg_offset;
> @@ -148,7 +148,13 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
>   static const s8 ofs_und8[] = {
>   10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12, 
> -12
>   };
> -
> + /*
> +  * For 420 format since bits_per_pixel (bpp) is set to target 
> bpp
> * 2,
> +  * QP table values for target bpp 4.0 to 4.4375 (rounded to 4.0)
> are
> +  * actually for bpp 8 to 8.875 (rounded to 4.0 * 2 i.e 8).
> +  * Similarly values for target bpp 4.5 to 4.8375 (rounded to 
> 4.5)
> +  * are for bpp 9 to 9.875 (rounded to 4.5 * 2 i.e 9), and so on.
> +  */
>   bpp_i  = bpp - 8;
>   for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
>   u8 range_bpg_offset;
> @@ -178,6 +184,9 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
>   range_bpg_offset &
> DSC_RANGE_BPG_OFFSET_MASK;
>   }
>   } else {
> + /* fractional bpp part * 1 (for precision up to 4 decimal
> places) */
> + int fractional_bits = to_bpp_frac_dec(vdsc_cfg-
> >bits_per_pixel);
> +
>   static const s8 ofs_und6[] = {
>   0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, -12, 
> -12, -12
>   };
> @@ -191,7 +200,14 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
>   10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12, 
> -12
>   };
> 
> - bpp_i  = (2 * (bpp - 6));
> + /*
> +  * QP table rows have values in increment of 0.5.
> +  * So 6.0 bpp to 6.4375 will have index 0, 6.5 to 6.9375 will
> have index 1,
> +  * and so on.
> +  * 0.5 fractional part with 4 decimal precision becomes 5000
> +  */
> + bpp_i  = ((bpp - 6) + (fractional_bits < 5000 ? 0 : 1));
> +
>   for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
>   u8 range_bpg_offset;
> 
> @@ -279,8 +295,7 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
>   /* Gen 11 does not support VBR */
>   vdsc_cfg->vbr_enable = false;
> 
> - /* Gen 11 only supports integral values of bpp */
> - vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> + vdsc_cfg->bits_per_pixel = pipe_config->dsc.compressed_bpp_x16;
> 
>   /*
>* According to DSC 1.2 specs in Section 4.1 if native_420 is set
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4 format

2023-09-11 Thread Kandpal, Suraj
> Subject: RE: [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4
> format
> 
> > Subject: [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4
> > format
> >
> > From: Ankit Nautiyal 
> >
> > DSC parameter bits_per_pixel is stored in U6.4 format.
> > The 4 bits represent the fractional part of the bpp.
> > Currently we use compressed_bpp member of dsc structure to store only
> > the integral part of the bits_per_pixel.
> > To store the full bits_per_pixel along with the fractional part,
> > compressed_bpp is changed to store bpp in U6.4 formats. Intergral part
> > is retrieved by simply right shifting the member compressed_bpp by 4.
> >
> > v2:
> > -Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing
> > with compressed bpp. (Suraj) -Fix comment styling. (Suraj)
> >
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c| 10 
> >  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
> >  drivers/gpu/drm/i915/display/intel_bios.c |  4 +--
> >  drivers/gpu/drm/i915/display/intel_cdclk.c|  2 +-
> >  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
> >  .../drm/i915/display/intel_display_types.h| 18 -
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 25 +++
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 18 ++---
> >  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 +--
> >  9 files changed, 52 insertions(+), 33 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index ad6488e9c2b2..df98f35bbcda 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -330,7 +330,7 @@ static int afe_clk(struct intel_encoder *encoder,
> > int bpp;
> >
> > if (crtc_state->dsc.compression_enable)
> > -   bpp = crtc_state->dsc.compressed_bpp;
> > +   bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
> > else
> > bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> >
> > @@ -860,7 +860,7 @@ gen11_dsi_set_transcoder_timings(struct
> > intel_encoder *encoder,
> >  * compressed and non-compressed bpp.
> >  */
> > if (crtc_state->dsc.compression_enable) {
> > -   mul = crtc_state->dsc.compressed_bpp;
> > +   mul = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
> > div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> > }
> >
> > @@ -884,7 +884,7 @@ gen11_dsi_set_transcoder_timings(struct
> > intel_encoder *encoder,
> > int bpp, line_time_us, byte_clk_period_ns;
> >
> > if (crtc_state->dsc.compression_enable)
> > -   bpp = crtc_state->dsc.compressed_bpp;
> > +   bpp = to_bpp_int(crtc_state-
> > >dsc.compressed_bpp_x16);
> > else
> > bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> > >pixel_format);
> >
> > @@ -1451,8 +1451,8 @@ static void gen11_dsi_get_timings(struct
> > intel_encoder *encoder,
> > struct drm_display_mode *adjusted_mode =
> > _config->hw.adjusted_mode;
> >
> > -   if (pipe_config->dsc.compressed_bpp) {
> > -   int div = pipe_config->dsc.compressed_bpp;
> > +   if (pipe_config->dsc.compressed_bpp_x16) {
> > +   int div = to_bpp_int(pipe_config->dsc.compressed_bpp_x16);
> > int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> > >pixel_format);
> >
> > adjusted_mode->crtc_htotal =
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index 19605264a35c..aa93ccd6c2aa 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -528,7 +528,7 @@ static unsigned int calc_hblank_early_prog(struct
> > intel_encoder *encoder,
> > h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
> > pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> > -   vdsc_bpp = crtc_state->dsc.compressed_bpp;
> > +   vdsc_bpp = to_bpp_int(crtc_state->dsc.compressed_bpp_x16);
> > cdclk = i915->display.cdclk.hw.cdclk;
> > /* fec= 0.972261, using rounding multiplier of 100 */
> > fec_coeff = 972261;
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 858c959f7bab..7b6d299fbcf2 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -3384,8 +3384,8 @@ static void fill_dsc(struct intel_crtc_state
> > *crtc_state,
> >
> > crtc_state->pipe_bpp = bpc * 3;
> >
> > -   crtc_state->dsc.compressed_bpp = min(crtc_state->pipe_bpp,
> > -VBT_DSC_MAX_BPP(dsc-
> > >max_bpp));
> > +   crtc_state->dsc.compressed_bpp_x16 = to_bpp_x16(min(crtc_state-
> > >pipe_bpp,
> > +
> > 

Re: [Intel-gfx] [PATCH 7/8] drm/i915/dsc: Add debugfs entry to validate DSC fractional bpp

2023-09-11 Thread Kandpal, Suraj
> Subject: [PATCH 7/8] drm/i915/dsc: Add debugfs entry to validate DSC 
> fractional
> bpp
> 
> From: Swati Sharma 
> 
> DSC_Sink_BPP_Precision entry is added to i915_dsc_fec_support_show to
> depict sink's precision.
> Also, new debugfs entry is created to enforce fractional bpp.
> If Force_DSC_Fractional_BPP_en is set then while iterating over output bpp
> with fractional step size we will continue if output_bpp is computed as 
> integer.
> With this approach, we will be able to validate DSC with fractional bpp.
> 
> Signed-off-by: Swati Sharma 
> Signed-off-by: Ankit Nautiyal 
> ---
>  .../drm/i915/display/intel_display_debugfs.c  | 82 +++
>  .../drm/i915/display/intel_display_types.h|  1 +
>  2 files changed, 83 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index f05b52381a83..d1b202e14e5f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -1244,6 +1244,8 @@ static int i915_dsc_fec_support_show(struct seq_file
> *m, void *data)
> 
> DP_DSC_YCbCr420_Native)),
> 
> str_yes_no(drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> 
> DP_DSC_YCbCr444)));
> + seq_printf(m, "DSC_Sink_BPP_Precision: %d\n",
> +drm_dp_dsc_sink_bpp_incr(intel_dp->dsc_dpcd));
>   seq_printf(m, "Force_DSC_Enable: %s\n",
>  str_yes_no(intel_dp->force_dsc_en));
>   if (!intel_dp_is_edp(intel_dp))
> @@ -1436,6 +1438,83 @@ static const struct file_operations
> i915_dsc_output_format_fops = {
>   .write = i915_dsc_output_format_write
>  };
> 
> +static int i915_dsc_fractional_bpp_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + struct intel_dp *intel_dp;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + int ret;
> +
> + if (!encoder)
> + return -ENODEV;
> +
> + ret = drm_modeset_lock_single_interruptible(
> >mode_config.connection_mutex);
> + if (ret)
> + return ret;
> +
> + crtc = connector->state->crtc;
> + if (connector->status != connector_status_connected || !crtc) {
> + ret = -ENODEV;
> + goto out;
> + }
> +
> + intel_dp = intel_attached_dp(to_intel_connector(connector));
> + seq_printf(m, "Force_DSC_Fractional_BPP_Enable: %s\n",
> +str_yes_no(intel_dp->force_dsc_fractional_bpp_en));
> +
> +out: drm_modeset_unlock(>mode_config.connection_mutex);
> +

The above function should be on a new line and the extra new line can be removed
return and modeset_unlock

With that fixed
LGTM.
Reviewed-by: Suraj Kandpal 

> + return ret;
> +}
> +
> +static ssize_t i915_dsc_fractional_bpp_write(struct file *file,
> +  const char __user *ubuf,
> +  size_t len, loff_t *offp)
> +{
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + bool dsc_fractional_bpp_enable = false;
> + int ret;
> +
> + if (len == 0)
> + return 0;
> +
> + drm_dbg(>drm,
> + "Copied %zu bytes from user to force fractional bpp for
> DSC\n", len);
> +
> + ret = kstrtobool_from_user(ubuf, len, _fractional_bpp_enable);
> + if (ret < 0)
> + return ret;
> +
> + drm_dbg(>drm, "Got %s for DSC Fractional BPP Enable\n",
> + (dsc_fractional_bpp_enable) ? "true" : "false");
> + intel_dp->force_dsc_fractional_bpp_en = dsc_fractional_bpp_enable;
> +
> + *offp += len;
> +
> + return len;
> +}
> +
> +static int i915_dsc_fractional_bpp_open(struct inode *inode,
> + struct file *file)
> +{
> + return single_open(file, i915_dsc_fractional_bpp_show,
> +inode->i_private); }
> +
> +static const struct file_operations i915_dsc_fractional_bpp_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_dsc_fractional_bpp_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_dsc_fractional_bpp_write };
> +
>  /*
>   * Returns the Current CRTC's bpc.
>   * Example usage: cat /sys/kernel/debug/dri/0/crtc-0/i915_current_bpc
> @@ -1513,6 +1592,9 @@ void intel_connector_debugfs_add(struct
> intel_connector *intel_connector)
> 
>   debugfs_create_file("i915_dsc_output_format", 0644, root,
>   connector, _dsc_output_format_fops);
> +
> + 

Re: [Intel-gfx] [Intel-xe] [PATCH 09/42] drm/i915/tc: move legacy code out of the main _max_lane_count() func

2023-08-24 Thread Kandpal, Suraj
> >> Subject: [Intel-gfx] [PATCH 09/42] drm/i915/tc: move legacy code out
> >> of the main _max_lane_count() func
> >>
> >> From: Luca Coelho 
> >>
> >> This makes the code a bit more symmetric and readable, especially
> >> when we start adding more display version-specific alternatives.
> >>
> >> Signed-off-by: Luca Coelho 
> >> Link: https://lore.kernel.org/r/2023072121.369227-4-
> >> luciano.coe...@intel.com
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_tc.c | 32
> >> +++--
> >>  1 file changed, 19 insertions(+), 13 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> >> b/drivers/gpu/drm/i915/display/intel_tc.c
> >> index de848b329f4b..43b8eeba26f8 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> >> @@ -311,23 +311,12 @@ static int
> >> mtl_tc_port_get_max_lane_count(struct
> >> intel_digital_port *dig_port)
> >>}
> >>  }
> >>
> >> -int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> >> *dig_port)
> >> +static int intel_tc_port_get_max_lane_count(struct
> >> +intel_digital_port
> >> +*dig_port)
> >>  {
> >>struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> >> -  struct intel_tc_port *tc = to_tc_port(dig_port);
> >> -  enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> >>intel_wakeref_t wakeref;
> >> -  u32 lane_mask;
> >> -
> >> -  if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> >> -  return 4;
> >> +  u32 lane_mask = 0;
> >>
> >> -  assert_tc_cold_blocked(tc);
> >> -
> >> -  if (DISPLAY_VER(i915) >= 14)
> >> -  return mtl_tc_port_get_max_lane_count(dig_port);
> >> -
> >> -  lane_mask = 0;
> >>with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> >> wakeref)
> >>lane_mask = intel_tc_port_get_lane_mask(dig_port);
> >>
> >> @@ -348,6 +337,23 @@ int intel_tc_port_fia_max_lane_count(struct
> >> intel_digital_port *dig_port)
> >>}
> >>  }
> >
> >Rather than having two functions:
> >mtl_tc_port_get_max_lane_count()
> >& intel_tc_port_get_max_lane_count() that both call:
> >with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> >lane_mask = intel_tc_port_get_lane_mask(dig_port);
> >to get the lane mask the us directly pass the lane_mask to the above
> >two functions and make the call for getting the lane_mask common i.e
> >lets call it in intel_tc_port_fia_max_lane_count().
> 
> Maybe, but I will let this to be decided between you and Luca. Pasting from
> the cover letter:
> 
>  3. Patches 7 through 10 can also be ignored: they are not
> applied yet, but being reviewed in other patch series by its
> author[2].
> 
>  [2] https://patchwork.freedesktop.org/series/120980/
> 
> The only reason I added them here is that since this series will take some 
> time
> to be applied, I figured it would be better not to create unnecessary 
> conflicts. I
> expect these patches to merge soon so I will just drop them in the next
> revision of this series.
> 
> thanks
> Lucas De Marchi
> 

Ohk got it.

Regards,
Suraj Kandpal
> >
> >Regards,
> >Suraj Kandpal
> >>
> >> +int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> >> +*dig_port) {
> >> +  struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> >> +  struct intel_tc_port *tc = to_tc_port(dig_port);
> >> +  enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> >> +
> >> +  if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> >> +  return 4;
> >> +
> >> +  assert_tc_cold_blocked(tc);
> >> +
> >> +  if (DISPLAY_VER(i915) >= 14)
> >> +  return mtl_tc_port_get_max_lane_count(dig_port);
> >> +
> >> +  return intel_tc_port_get_max_lane_count(dig_port);
> >> +}
> >> +
> >>  void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> >>  int required_lanes)
> >>  {
> >> --
> >> 2.40.1
> >


Re: [Intel-gfx] [PATCH 2/9] drm/i915/display: Store compressed bpp in U6.4 format

2023-08-24 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH 2/9] drm/i915/display: Store compressed bpp in
> U6.4 format
> 
> DSC parameter bits_per_pixel is stored in U6.4 format.
> The 4 bits represent the fractional part of the bpp.
> Currently we use compressed_bpp member of dsc structure to store only the
> integral part of the bits_per_pixel.
> To store the full bits_per_pixel along with the fractional part, 
> compressed_bpp
> is changed to store bpp in U6.4 formats. Intergral part is retrieved by simply
> right shifting the member compressed_bpp by 4.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c| 10 -
>  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
>  .../drm/i915/display/intel_display_types.h| 16 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 21 +++
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 ++--
>  6 files changed, 36 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ad6488e9c2b2..81b8e97e9435 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -330,7 +330,7 @@ static int afe_clk(struct intel_encoder *encoder,
>   int bpp;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = dsc_integral_compressed_bpp(crtc_state-
> >dsc.compressed_bpp);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> 
> @@ -860,7 +860,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>* compressed and non-compressed bpp.
>*/
>   if (crtc_state->dsc.compression_enable) {
> - mul = crtc_state->dsc.compressed_bpp;
> + mul = dsc_integral_compressed_bpp(crtc_state-
> >dsc.compressed_bpp);
>   div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
>   }
> 
> @@ -884,7 +884,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>   int bpp, line_time_us, byte_clk_period_ns;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp = dsc_integral_compressed_bpp(crtc_state-
> >dsc.compressed_bpp);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
> @@ -1451,8 +1451,8 @@ static void gen11_dsi_get_timings(struct
> intel_encoder *encoder,
>   struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> 
> - if (pipe_config->dsc.compressed_bpp) {
> - int div = pipe_config->dsc.compressed_bpp;
> + if (dsc_integral_compressed_bpp(pipe_config-
> >dsc.compressed_bpp)) {

Doesn't make sense to have this function to be called here this just
checks if we have compressed_bpp available or not extracting the
integral part should not be necessary

> + int div =
> +dsc_integral_compressed_bpp(pipe_config->dsc.compressed_bpp);
>   int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
>   adjusted_mode->crtc_htotal =
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 3d9c9b4f27f8..93969b63cdd8 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -528,7 +528,7 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = crtc_state->dsc.compressed_bpp;
> + vdsc_bpp =
> +dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 858c959f7bab..fe1e376c4ba7 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -3385,7 +3385,7 @@ static void fill_dsc(struct intel_crtc_state
> *crtc_state,
>   crtc_state->pipe_bpp = bpc * 3;
> 
>   crtc_state->dsc.compressed_bpp = min(crtc_state->pipe_bpp,
> -  VBT_DSC_MAX_BPP(dsc-
> >max_bpp));
> +  VBT_DSC_MAX_BPP(dsc-
> >max_bpp)) << 4;
> 
>   /*
>* FIXME: This is ugly, and slice count should take DSC engine diff 
> --git
> a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 731f2ec04d5c..f749dc4e70df 100644
> --- 

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/tc: move legacy code out of the main _max_lane_count() func

2023-08-24 Thread Kandpal, Suraj

> On Wed, 2023-08-16 at 08:54 +0000, Kandpal, Suraj wrote:
> > > This makes the code a bit more symmetric and readable, especially
> > > when we start adding more display version-specific alternatives.
> > >
> > > Signed-off-by: Luca Coelho 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_tc.c | 32 +++--
> > > 
> > >  1 file changed, 19 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index de848b329f4b..43b8eeba26f8 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -311,23 +311,12 @@ static int
> > > mtl_tc_port_get_max_lane_count(struct
> > > intel_digital_port *dig_port)
> > >   }
> > >  }
> > >
> > > -int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > > *dig_port)
> > > +static int intel_tc_port_get_max_lane_count(struct
> > > intel_digital_port
> > > +*dig_port)
> > >  {
> > >   struct drm_i915_private *i915 = to_i915(dig_port-
> > > >base.base.dev);
> > > - struct intel_tc_port *tc = to_tc_port(dig_port);
> > > - enum phy phy = intel_port_to_phy(i915, dig_port-
> > > >base.port);
> > >   intel_wakeref_t wakeref;
> > > - u32 lane_mask;
> > > -
> > > - if (!intel_phy_is_tc(i915, phy) || tc->mode !=
> > > TC_PORT_DP_ALT)
> > > - return 4;
> > > + u32 lane_mask = 0;
> > >
> > > - assert_tc_cold_blocked(tc);
> > > -
> > > - if (DISPLAY_VER(i915) >= 14)
> > > - return mtl_tc_port_get_max_lane_count(dig_port);
> > > -
> > > - lane_mask = 0;
> > >   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> > > wakeref)
> > >   lane_mask = intel_tc_port_get_lane_mask(dig_port);
> > >
> > > @@ -348,6 +337,23 @@ int intel_tc_port_fia_max_lane_count(struct
> > > intel_digital_port *dig_port)
> > >   }
> > >  }
> > >
> > > +int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > > +*dig_port) {
> > > + struct drm_i915_private *i915 = to_i915(dig_port-
> > > >base.base.dev);
> > > + struct intel_tc_port *tc = to_tc_port(dig_port);
> > > + enum phy phy = intel_port_to_phy(i915, dig_port-
> > > >base.port);
> > > +
> > > + if (!intel_phy_is_tc(i915, phy) || tc->mode !=
> > > TC_PORT_DP_ALT)
> > > + return 4;
> > > +
> > > + assert_tc_cold_blocked(tc);
> > > +
> > > + if (DISPLAY_VER(i915) >= 14)
> > > + return mtl_tc_port_get_max_lane_count(dig_port);
> > > +
> > > + return intel_tc_port_get_max_lane_count(dig_port);
> > > +}
> >
> > Looking at this I think we have more scope of optimization here I
> > think we can go about it in the following way
> >
> > intel_tc_port_fia_max_lane_count
> > already calls
> > with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> > lane_mask = intel_tc_port_get_lane_mask(dig_port);
> >
> > which we also duplicate in  mtl_tc_port_get_pin_assignment_mask
> > (now mtl_tc_port_get_max_lane_count) and the only difference between
> > them Is the switch case what if we have a function or repurpose
> > mtl_tc_port_get_max_lane_count to only have the switch case block with
> > assignment varied by display version and call it after
> > intel_tc_port_get_lane_mask
> >
> > maybe also move the legacy switch case in its own function?
> 
> This would be another option, but I think it's nicer to keep things very 
> isolated
> from each other and this tiny code duplication is not too bad.
> 
> Especially because later, as you can see in my LNL patch that Lucas sent 
> out[1]
> we have another combination in a new function.  So we have:
> 
> intel_tc_port_get_max_lane_count();
>   intel_tc_port_get_lane_mask();
>   switch with lane_mask;
> 
> mlt_tc_port_get_lane_mask(dig_port);
>   intel_tc_port_get_pin_assignment_mask();
>   switch with pin_mask;
> 
> lnl_tc_port_get_lane_mask():
>   intel_uncore_read(uncore, TCSS_DDI_STATUS(tc_port));
>   switch with pin_assignment;
> 
> 
> So now we have 3 different ways to read and two different ways to parse (with
> the switch-case).  I think it's a lot cleaner to keep this all separate than 
> to try
> to reuse these small pieces of code, which would make it a bit harder to read.
> 
> Makes sense?
> 

Yes this actually makes sense I commented the same thing on Lucas's LNL
Display enablement patch

Regards,
Suraj Kandpal

> [1] https://patchwork.kernel.org/project/intel-
> gfx/patch/20230823170740.1180212-28-lucas.demar...@intel.com/
> 
> --
> Cheers,
> Luca.


Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/tc: move legacy code out of the main _max_lane_count() func

2023-08-24 Thread Kandpal, Suraj
> On Wed, 2023-08-16 at 08:54 +0000, Kandpal, Suraj wrote:
> > > This makes the code a bit more symmetric and readable, especially
> > > when we start adding more display version-specific alternatives.
> > >
> > > Signed-off-by: Luca Coelho 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_tc.c | 32 +++--
> > > 
> > >  1 file changed, 19 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > > b/drivers/gpu/drm/i915/display/intel_tc.c
> > > index de848b329f4b..43b8eeba26f8 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > > @@ -311,23 +311,12 @@ static int
> > > mtl_tc_port_get_max_lane_count(struct
> > > intel_digital_port *dig_port)
> > >   }
> > >  }
> > >
> > > -int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > > *dig_port)
> > > +static int intel_tc_port_get_max_lane_count(struct
> > > intel_digital_port
> > > +*dig_port)
> > >  {
> > >   struct drm_i915_private *i915 = to_i915(dig_port-
> > > >base.base.dev);
> > > - struct intel_tc_port *tc = to_tc_port(dig_port);
> > > - enum phy phy = intel_port_to_phy(i915, dig_port-
> > > >base.port);
> > >   intel_wakeref_t wakeref;
> > > - u32 lane_mask;
> > > -
> > > - if (!intel_phy_is_tc(i915, phy) || tc->mode !=
> > > TC_PORT_DP_ALT)
> > > - return 4;
> > > + u32 lane_mask = 0;
> > >
> > > - assert_tc_cold_blocked(tc);
> > > -
> > > - if (DISPLAY_VER(i915) >= 14)
> > > - return mtl_tc_port_get_max_lane_count(dig_port);
> > > -
> > > - lane_mask = 0;
> > >   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> > > wakeref)
> > >   lane_mask = intel_tc_port_get_lane_mask(dig_port);
> > >
> > > @@ -348,6 +337,23 @@ int intel_tc_port_fia_max_lane_count(struct
> > > intel_digital_port *dig_port)
> > >   }
> > >  }
> > >
> > > +int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > > +*dig_port) {
> > > + struct drm_i915_private *i915 = to_i915(dig_port-
> > > >base.base.dev);
> > > + struct intel_tc_port *tc = to_tc_port(dig_port);
> > > + enum phy phy = intel_port_to_phy(i915, dig_port-
> > > >base.port);
> > > +
> > > + if (!intel_phy_is_tc(i915, phy) || tc->mode !=
> > > TC_PORT_DP_ALT)
> > > + return 4;
> > > +
> > > + assert_tc_cold_blocked(tc);
> > > +
> > > + if (DISPLAY_VER(i915) >= 14)
> > > + return mtl_tc_port_get_max_lane_count(dig_port);
> > > +
> > > + return intel_tc_port_get_max_lane_count(dig_port);
> > > +}
> >
> > Looking at this I think we have more scope of optimization here I
> > think we can go about it in the following way
> >
> > intel_tc_port_fia_max_lane_count
> > already calls
> > with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> > lane_mask = intel_tc_port_get_lane_mask(dig_port);
> >
> > which we also duplicate in  mtl_tc_port_get_pin_assignment_mask
> > (now mtl_tc_port_get_max_lane_count) and the only difference between
> > them Is the switch case what if we have a function or repurpose
> > mtl_tc_port_get_max_lane_count to only have the switch case block with
> > assignment varied by display version and call it after
> > intel_tc_port_get_lane_mask
> >
> > maybe also move the legacy switch case in its own function?
> 
> This would be another option, but I think it's nicer to keep things very 
> isolated
> from each other and this tiny code duplication is not too bad.
> 
> Especially because later, as you can see in my LNL patch that Lucas sent 
> out[1]
> we have another combination in a new function.  So we have:
> 
> intel_tc_port_get_max_lane_count();
>   intel_tc_port_get_lane_mask();
>   switch with lane_mask;
> 
> mlt_tc_port_get_lane_mask(dig_port);
>   intel_tc_port_get_pin_assignment_mask();
>   switch with pin_mask;
> 
> lnl_tc_port_get_lane_mask():
>   intel_uncore_read(uncore, TCSS_DDI_STATUS(tc_port));
>   switch with pin_assignment;
> 
> 
> So now we have 3 different ways to read and two different ways to parse (with
> the switch-case).  I think it's a lot cleaner to keep this all separate than 
> to try
> to reuse these small pieces of code, which would make it a bit harder to read.
> 
> Makes sense?

Good with it

Reviewed-by: Suraj Kandpal 
> 
> [1] https://patchwork.kernel.org/project/intel-
> gfx/patch/20230823170740.1180212-28-lucas.demar...@intel.com/
> 
> --
> Cheers,
> Luca.


Re: [Intel-gfx] [PATCH 4/9] drm/i915/audio : Consider fractional vdsc bpp while computing tu_data

2023-08-24 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH 4/9] drm/i915/audio : Consider fractional vdsc bpp
> while computing tu_data
> 
> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate the precision during calculation of transfer unit data for
> hblank_early calculation.
> 
> v2:
> -Fixed tu_data calculation while dealing with U6.4 format. (Stan)
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_audio.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 93969b63cdd8..bbd99e2fb399 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -521,14 +521,14 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   unsigned int link_clks_available, link_clks_required;
>   unsigned int tu_data, tu_line, link_clks_active;
>   unsigned int h_active, h_total, hblank_delta, pixel_clk;
> - unsigned int fec_coeff, cdclk, vdsc_bpp;
> + unsigned int fec_coeff, cdclk, vdsc_bppx16;
>   unsigned int link_clk, lanes;
>   unsigned int hblank_rise;
> 
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = dsc_integral_compressed_bpp(crtc_state-
> >dsc.compressed_bpp);
> + vdsc_bppx16 = crtc_state->dsc.compressed_bpp;

This wouldn't be needed if dsc_integral_compressed_bpp wasn't called
Here in the second patch.
Maybe just a rename of the vdsc_bpp variable name as a part of this patch

Regards,
Suraj Kandpal

>   cdclk = i915->display.cdclk.hw.cdclk;
>   /* fec= 0.972261, using rounding multiplier of 100 */
>   fec_coeff = 972261;
> @@ -536,10 +536,10 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   lanes = crtc_state->lane_count;
> 
>   drm_dbg_kms(>drm, "h_active = %u link_clk = %u :"
> - "lanes = %u vdsc_bpp = %u cdclk = %u\n",
> - h_active, link_clk, lanes, vdsc_bpp, cdclk);
> + "lanes = %u vdsc_bppx16 = %u cdclk = %u\n",
> + h_active, link_clk, lanes, vdsc_bppx16, cdclk);
> 
> - if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bpp || !cdclk))
> + if (WARN_ON(!link_clk || !pixel_clk || !lanes || !vdsc_bppx16 ||
> +!cdclk))
>   return 0;
> 
>   link_clks_available = (h_total - h_active) * link_clk / pixel_clk - 28; 
> @@
> -551,8 +551,8 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   hblank_delta = DIV64_U64_ROUND_UP(mul_u32_u32(5 *
> (link_clk + cdclk), pixel_clk),
> mul_u32_u32(link_clk,
> cdclk));
> 
> - tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bpp * 8,
> 100),
> - mul_u32_u32(link_clk * lanes, fec_coeff));
> + tu_data = div64_u64(mul_u32_u32(pixel_clk * vdsc_bppx16 * 8,
> 100),
> + mul_u32_u32(link_clk * lanes * 16, fec_coeff));
>   tu_line = div64_u64(h_active * mul_u32_u32(link_clk, fec_coeff),
>   mul_u32_u32(64 * pixel_clk, 100));
>   link_clks_active  = (tu_line - 1) * 64 + tu_data;
> --
> 2.40.1



Re: [Intel-gfx] [PATCH 5/9] drm/display/dp: Add helper function to get DSC bpp prescision

2023-08-24 Thread Kandpal, Suraj
> 
> > Add helper to get the DSC bits_per_pixel precision for the DP sink.
> >
> > Signed-off-by: Ankit Nautiyal 

Wouldn't we also need to send this patch to dri-devel

Regards,
Suraj Kandpal
> > ---
> >  drivers/gpu/drm/display/drm_dp_helper.c | 27
> > +
> >  include/drm/display/drm_dp_helper.h |  1 +
> >  2 files changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> > b/drivers/gpu/drm/display/drm_dp_helper.c
> > index e6a78fd32380..aa8ea36211de 100644
> > --- a/drivers/gpu/drm/display/drm_dp_helper.c
> > +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> > @@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> > struct drm_dp_desc *desc,  }  EXPORT_SYMBOL(drm_dp_read_desc);
> >
> > +/**
> > + * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
> > + * @dsc_dpcd: DSC capabilities from DPCD
> > + *
> > + * Returns the bpp precision supported by the DP sink.
> > + */
> > +u8 drm_dp_dsc_sink_bpp_incr(const u8
> > +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> > +{
> > +   u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
> > +DP_DSC_SUPPORT];
> > +
> > +   switch (bpp_increment_dpcd) {
> > +   case DP_DSC_BITS_PER_PIXEL_1_16:
> > +   return 16;
> > +   case DP_DSC_BITS_PER_PIXEL_1_8:
> > +   return 8;
> > +   case DP_DSC_BITS_PER_PIXEL_1_4:
> > +   return 4;
> > +   case DP_DSC_BITS_PER_PIXEL_1_2:
> > +   return 2;
> > +   case DP_DSC_BITS_PER_PIXEL_1_1:
> > +   return 1;
> 
> Shouldn't there be a default MISSING_CASE to throw a warning if its none of 
> the
> above case Occurs in case a addition bit for step is added in dpcd going 
> forward
> 
> Regards,
> Suraj Kandpal
> 
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
> > +
> >  /**
> >   * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
> >   * supported by the DSC sink.
> > diff --git a/include/drm/display/drm_dp_helper.h
> > b/include/drm/display/drm_dp_helper.h
> > index 86f24a759268..ba0514f0b032 100644
> > --- a/include/drm/display/drm_dp_helper.h
> > +++ b/include/drm/display/drm_dp_helper.h
> > @@ -164,6 +164,7 @@ drm_dp_is_branch(const u8
> > dpcd[DP_RECEIVER_CAP_SIZE])  }
> >
> >  /* DP/eDP DSC support */
> > +u8 drm_dp_dsc_sink_bpp_incr(const u8
> > +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> >  u8 drm_dp_dsc_sink_max_slice_count(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
> >bool is_edp);
> >  u8 drm_dp_dsc_sink_line_buf_depth(const u8
> > dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> > --
> > 2.40.1



Re: [Intel-gfx] [PATCH 3/9] drm/i915/display: Consider fractional vdsc bpp while computing m_n values

2023-08-24 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH 3/9] drm/i915/display: Consider fractional vdsc
> bpp while computing m_n values
> 
> MTL+ supports fractional compressed bits_per_pixel, with precision of
> 1/16. This compressed bpp is stored in U6.4 format.
> Accommodate this precision while computing m_n values.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c  | 7 ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c  | 6 --
>  drivers/gpu/drm/i915/display/intel_fdi.c | 2 +-
>  5 files changed, 15 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8c81206ce90d..9af36e600c87 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -2380,10 +2380,14 @@ void
>  intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
>  int pixel_clock, int link_clock,
>  struct intel_link_m_n *m_n,
> -bool fec_enable)
> +bool fec_enable,
> +bool is_dsc_fractional_bpp)
>  {
>   u32 data_clock = bits_per_pixel * pixel_clock;
> 
> + if (is_dsc_fractional_bpp)
> + data_clock = DIV_ROUND_UP(bits_per_pixel * pixel_clock,
> 16);
> +

Is there any mention of this in bspec or dsc spec if so can you add that in 
commit message.

>   if (fec_enable)
>   data_clock = intel_dp_mode_to_fec_clock(data_clock);
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 49ac8473b988..a4c4ca3cad65 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -398,7 +398,7 @@ u8 intel_calc_active_pipes(struct intel_atomic_state
> *state,  void intel_link_compute_m_n(u16 bpp, int nlanes,
>   int pixel_clock, int link_clock,
>   struct intel_link_m_n *m_n,
> - bool fec_enable);
> + bool fec_enable, bool is_dsc_fractional_bpp);
>  u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
> u32 pixel_format, u64 modifier);  enum
> drm_mode_status diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 32d0bee11f53..436889c601b1 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2557,7 +2557,7 @@ intel_dp_drrs_compute_config(struct
> intel_connector *connector,
> 
>   intel_link_compute_m_n(link_bpp, pipe_config->lane_count,
> pixel_clock,
>  pipe_config->port_clock, _config-
> >dp_m2_n2,
> -pipe_config->fec_enable);
> +pipe_config->fec_enable, false);
> 
>   /* FIXME: abstract this better */
>   if (pipe_config->splitter.enable)
> @@ -2703,7 +2703,7 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>   intel_dp_limited_color_range(pipe_config, conn_state);
> 
>   if (pipe_config->dsc.compression_enable)
> - link_bpp = dsc_integral_compressed_bpp(pipe_config-
> >dsc.compressed_bpp);
> + link_bpp = pipe_config->dsc.compressed_bpp;

In the second patch you added this but you end up deleting it here
which I believe is a mistake

Regards,
Suraj Kandpal

>   else
>   link_bpp = intel_dp_output_bpp(pipe_config-
> >output_format,
>  pipe_config->pipe_bpp);
> @@ -2735,7 +2735,8 @@ intel_dp_compute_config(struct intel_encoder
> *encoder,
>  adjusted_mode->crtc_clock,
>  pipe_config->port_clock,
>  _config->dp_m_n,
> -pipe_config->fec_enable);
> +pipe_config->fec_enable,
> +pipe_config->dsc.compression_enable);
> 
>   /* FIXME: abstract this better */
>   if (pipe_config->splitter.enable)
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 3eb085fbc7c8..e224eebe7c17 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -171,7 +171,8 @@ static int intel_dp_mst_compute_link_config(struct
> intel_encoder *encoder,
>  adjusted_mode->crtc_clock,
>  crtc_state->port_clock,
>  _state->dp_m_n,
> -crtc_state->fec_enable);
> +crtc_state->fec_enable,
> +false);
>   crtc_state->dp_m_n.tu = slots;
> 
>   return 0;
> @@ 

Re: [Intel-gfx] [PATCH 5/9] drm/display/dp: Add helper function to get DSC bpp prescision

2023-08-24 Thread Kandpal, Suraj
> Add helper to get the DSC bits_per_pixel precision for the DP sink.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 27
> +
>  include/drm/display/drm_dp_helper.h |  1 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e6a78fd32380..aa8ea36211de 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> struct drm_dp_desc *desc,  }  EXPORT_SYMBOL(drm_dp_read_desc);
> 
> +/**
> + * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns the bpp precision supported by the DP sink.
> + */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
> +DP_DSC_SUPPORT];
> +
> + switch (bpp_increment_dpcd) {
> + case DP_DSC_BITS_PER_PIXEL_1_16:
> + return 16;
> + case DP_DSC_BITS_PER_PIXEL_1_8:
> + return 8;
> + case DP_DSC_BITS_PER_PIXEL_1_4:
> + return 4;
> + case DP_DSC_BITS_PER_PIXEL_1_2:
> + return 2;
> + case DP_DSC_BITS_PER_PIXEL_1_1:
> + return 1;

Shouldn't there be a default MISSING_CASE to throw a warning if its none of the 
above case
Occurs in case a addition bit for step is added in dpcd going forward

Regards,
Suraj Kandpal

> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
> +
>  /**
>   * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
>   * supported by the DSC sink.
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 86f24a759268..ba0514f0b032 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -164,6 +164,7 @@ drm_dp_is_branch(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])  }
> 
>  /* DP/eDP DSC support */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
>  u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>  bool is_edp);
>  u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> --
> 2.40.1



Re: [Intel-gfx] [PATCH 2/9] drm/i915/display: Store compressed bpp in U6.4 format

2023-08-24 Thread Kandpal, Suraj
> Subject: RE: [Intel-gfx] [PATCH 2/9] drm/i915/display: Store compressed bpp in
> U6.4 format
> 
> > Subject: [Intel-gfx] [PATCH 2/9] drm/i915/display: Store compressed
> > bpp in
> > U6.4 format
> >
> > DSC parameter bits_per_pixel is stored in U6.4 format.
> > The 4 bits represent the fractional part of the bpp.
> > Currently we use compressed_bpp member of dsc structure to store only
> > the integral part of the bits_per_pixel.
> > To store the full bits_per_pixel along with the fractional part,
> > compressed_bpp is changed to store bpp in U6.4 formats. Intergral part
> > is retrieved by simply right shifting the member compressed_bpp by 4.
> >
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/icl_dsi.c| 10 -
> >  drivers/gpu/drm/i915/display/intel_audio.c|  2 +-
> >  drivers/gpu/drm/i915/display/intel_bios.c |  2 +-
> >  .../drm/i915/display/intel_display_types.h| 16 +-
> >  drivers/gpu/drm/i915/display/intel_dp.c   | 21 +++
> >  drivers/gpu/drm/i915/display/intel_vdsc.c |  4 ++--
> >  6 files changed, 36 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index ad6488e9c2b2..81b8e97e9435 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -330,7 +330,7 @@ static int afe_clk(struct intel_encoder *encoder,
> > int bpp;
> >
> > if (crtc_state->dsc.compression_enable)
> > -   bpp = crtc_state->dsc.compressed_bpp;
> > +   bpp = dsc_integral_compressed_bpp(crtc_state-
> > >dsc.compressed_bpp);
> > else
> > bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> >
> > @@ -860,7 +860,7 @@ gen11_dsi_set_transcoder_timings(struct
> > intel_encoder *encoder,
> >  * compressed and non-compressed bpp.
> >  */
> > if (crtc_state->dsc.compression_enable) {
> > -   mul = crtc_state->dsc.compressed_bpp;
> > +   mul = dsc_integral_compressed_bpp(crtc_state-
> > >dsc.compressed_bpp);
> > div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> > }
> >
> > @@ -884,7 +884,7 @@ gen11_dsi_set_transcoder_timings(struct
> > intel_encoder *encoder,
> > int bpp, line_time_us, byte_clk_period_ns;
> >
> > if (crtc_state->dsc.compression_enable)
> > -   bpp = crtc_state->dsc.compressed_bpp;
> > +   bpp = dsc_integral_compressed_bpp(crtc_state-
> > >dsc.compressed_bpp);
> > else
> > bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> > >pixel_format);
> >
> > @@ -1451,8 +1451,8 @@ static void gen11_dsi_get_timings(struct
> > intel_encoder *encoder,
> > struct drm_display_mode *adjusted_mode =
> > _config->hw.adjusted_mode;
> >
> > -   if (pipe_config->dsc.compressed_bpp) {
> > -   int div = pipe_config->dsc.compressed_bpp;
> > +   if (dsc_integral_compressed_bpp(pipe_config-
> > >dsc.compressed_bpp)) {
> 
> Doesn't make sense to have this function to be called here this just checks 
> if we
> have compressed_bpp available or not extracting the integral part should not 
> be
> necessary
> 
> > +   int div =
> > +dsc_integral_compressed_bpp(pipe_config->dsc.compressed_bpp);
> > int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> > >pixel_format);
> >
> > adjusted_mode->crtc_htotal =
> > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > b/drivers/gpu/drm/i915/display/intel_audio.c
> > index 3d9c9b4f27f8..93969b63cdd8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > @@ -528,7 +528,7 @@ static unsigned int calc_hblank_early_prog(struct
> > intel_encoder *encoder,
> > h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
> > h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
> > pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> > -   vdsc_bpp = crtc_state->dsc.compressed_bpp;
> > +   vdsc_bpp =
> > +dsc_integral_compressed_bpp(crtc_state->dsc.compressed_bpp);
> > cdclk = i915->display.cdclk.hw.cdclk;
> > /* fec= 0.972261, using rounding multiplier of 100 */
> > fec_coeff = 972261;
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index 858c959f7bab..fe1e376c4ba7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -3385,7 +3385,7 @@ static void fill_dsc(struct intel_crtc_state
> > *crtc_state,
> > crtc_state->pipe_bpp = bpc * 3;
> >
> > crtc_state->dsc.compressed_bpp = min(crtc_state->pipe_bpp,
> > -VBT_DSC_MAX_BPP(dsc-
> > >max_bpp));
> > +VBT_DSC_MAX_BPP(dsc-
> > >max_bpp)) << 4;
> >
> > /*
> >  * FIXME: This is 

Re: [Intel-gfx] [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4 format

2023-09-12 Thread Kandpal, Suraj
> Subject: [PATCH 2/8] drm/i915/display: Store compressed bpp in U6.4 format
> 
> From: Ankit Nautiyal 
> 
> DSC parameter bits_per_pixel is stored in U6.4 format.
> The 4 bits represent the fractional part of the bpp.
> Currently we use compressed_bpp member of dsc structure to store only the
> integral part of the bits_per_pixel.
> To store the full bits_per_pixel along with the fractional part, 
> compressed_bpp
> is changed to store bpp in U6.4 formats. Intergral part is retrieved by simply
> right shifting the member compressed_bpp by 4.
> 
> v2:
> -Use to_bpp_int, to_bpp_frac_dec, to_bpp_x16 helpers while dealing  with
> compressed bpp. (Suraj) -Fix comment styling. (Suraj)
> 
> v3:
> -Add separate file for 6.4 fixed point helper(Jani, Nikula) -Add comment for
> magic values(Suraj)
> 

A lot of checkpatch issues have been created due to the renaming you can fix 
that.
Other than that everything else looks good

Regards,
Suraj Kandpal

> Signed-off-by: Ankit Nautiyal 
> Signed-off-by: Mitul Golani 
> Reviewed-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/icl_dsi.c| 11 +++---
>  drivers/gpu/drm/i915/display/intel_audio.c|  3 +-
>  drivers/gpu/drm/i915/display/intel_bios.c |  6 ++--
>  drivers/gpu/drm/i915/display/intel_cdclk.c|  5 +--
>  drivers/gpu/drm/i915/display/intel_display.c  |  2 +-
>  .../drm/i915/display/intel_display_types.h|  3 +-
>  drivers/gpu/drm/i915/display/intel_dp.c   | 29 ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   | 22 ++--
>  .../i915/display/intel_fractional_helper.h| 36 +++
>  drivers/gpu/drm/i915/display/intel_vdsc.c |  5 +--
>  10 files changed, 85 insertions(+), 37 deletions(-)  create mode 100644
> drivers/gpu/drm/i915/display/intel_fractional_helper.h
> 
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ad6488e9c2b2..0f7594b6aa1f 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -43,6 +43,7 @@
>  #include "intel_de.h"
>  #include "intel_dsi.h"
>  #include "intel_dsi_vbt.h"
> +#include "intel_fractional_helper.h"
>  #include "intel_panel.h"
>  #include "intel_vdsc.h"
>  #include "intel_vdsc_regs.h"
> @@ -330,7 +331,7 @@ static int afe_clk(struct intel_encoder *encoder,
>   int bpp;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp =
> +intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
> 
> @@ -860,7 +861,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>* compressed and non-compressed bpp.
>*/
>   if (crtc_state->dsc.compression_enable) {
> - mul = crtc_state->dsc.compressed_bpp;
> + mul =
> +intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
>   div = mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format);
>   }
> 
> @@ -884,7 +885,7 @@ gen11_dsi_set_transcoder_timings(struct
> intel_encoder *encoder,
>   int bpp, line_time_us, byte_clk_period_ns;
> 
>   if (crtc_state->dsc.compression_enable)
> - bpp = crtc_state->dsc.compressed_bpp;
> + bpp =
> +intel_fractional_bpp_from_x16(crtc_state->dsc.compressed_bpp_x16);
>   else
>   bpp = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
> @@ -1451,8 +1452,8 @@ static void gen11_dsi_get_timings(struct
> intel_encoder *encoder,
>   struct drm_display_mode *adjusted_mode =
>   _config->hw.adjusted_mode;
> 
> - if (pipe_config->dsc.compressed_bpp) {
> - int div = pipe_config->dsc.compressed_bpp;
> + if (pipe_config->dsc.compressed_bpp_x16) {
> + int div =
> +intel_fractional_bpp_from_x16(pipe_config->dsc.compressed_bpp_x16);
>   int mul = mipi_dsi_pixel_format_to_bpp(intel_dsi-
> >pixel_format);
> 
>   adjusted_mode->crtc_htotal =
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 19605264a35c..4f1db1581316 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -35,6 +35,7 @@
>  #include "intel_crtc.h"
>  #include "intel_de.h"
>  #include "intel_display_types.h"
> +#include "intel_fractional_helper.h"
>  #include "intel_lpe_audio.h"
> 
>  /**
> @@ -528,7 +529,7 @@ static unsigned int calc_hblank_early_prog(struct
> intel_encoder *encoder,
>   h_active = crtc_state->hw.adjusted_mode.crtc_hdisplay;
>   h_total = crtc_state->hw.adjusted_mode.crtc_htotal;
>   pixel_clk = crtc_state->hw.adjusted_mode.crtc_clock;
> - vdsc_bpp = crtc_state->dsc.compressed_bpp;
> + vdsc_bpp =
> 

Re: [Intel-gfx] [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp prescision

2023-09-13 Thread Kandpal, Suraj
> Subject: [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp
> prescision
> 
> From: Ankit Nautiyal 
> 
> Add helper to get the DSC bits_per_pixel precision for the DP sink.
> 

I think you forgot to add my reviewed by that I gave in the last revision 
Anyways,

LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 27 +
>  include/drm/display/drm_dp_helper.h |  1 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 8a1b64c57dfd..5c23d5b8fc50 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> struct drm_dp_desc *desc,  }  EXPORT_SYMBOL(drm_dp_read_desc);
> 
> +/**
> + * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns the bpp precision supported by the DP sink.
> + */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
> +DP_DSC_SUPPORT];
> +
> + switch (bpp_increment_dpcd) {
> + case DP_DSC_BITS_PER_PIXEL_1_16:
> + return 16;
> + case DP_DSC_BITS_PER_PIXEL_1_8:
> + return 8;
> + case DP_DSC_BITS_PER_PIXEL_1_4:
> + return 4;
> + case DP_DSC_BITS_PER_PIXEL_1_2:
> + return 2;
> + case DP_DSC_BITS_PER_PIXEL_1_1:
> + return 1;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
> +
>  /**
>   * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
>   * supported by the DSC sink.
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 3369104e2d25..6968d4d87931 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -164,6 +164,7 @@ drm_dp_is_branch(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])  }
> 
>  /* DP/eDP DSC support */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
>  u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>  bool is_edp);
>  u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp prescision

2023-09-12 Thread Kandpal, Suraj
> Subject: [PATCH 1/8] drm/display/dp: Add helper function to get DSC bpp
> prescision
> 
> From: Ankit Nautiyal 
> 
> Add helper to get the DSC bits_per_pixel precision for the DP sink.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/display/drm_dp_helper.c | 27 +
>  include/drm/display/drm_dp_helper.h |  1 +
>  2 files changed, 28 insertions(+)
> 
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index 8a1b64c57dfd..5c23d5b8fc50 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -2323,6 +2323,33 @@ int drm_dp_read_desc(struct drm_dp_aux *aux,
> struct drm_dp_desc *desc,  }  EXPORT_SYMBOL(drm_dp_read_desc);
> 
> +/**
> + * drm_dp_dsc_sink_bpp_incr() - Get bits per pixel increment
> + * @dsc_dpcd: DSC capabilities from DPCD
> + *
> + * Returns the bpp precision supported by the DP sink.
> + */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE])
> +{
> + u8 bpp_increment_dpcd = dsc_dpcd[DP_DSC_BITS_PER_PIXEL_INC -
> +DP_DSC_SUPPORT];
> +
> + switch (bpp_increment_dpcd) {
> + case DP_DSC_BITS_PER_PIXEL_1_16:
> + return 16;
> + case DP_DSC_BITS_PER_PIXEL_1_8:
> + return 8;
> + case DP_DSC_BITS_PER_PIXEL_1_4:
> + return 4;
> + case DP_DSC_BITS_PER_PIXEL_1_2:
> + return 2;
> + case DP_DSC_BITS_PER_PIXEL_1_1:
> + return 1;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_dp_dsc_sink_bpp_incr);
> +
>  /**
>   * drm_dp_dsc_sink_max_slice_count() - Get the max slice count
>   * supported by the DSC sink.
> diff --git a/include/drm/display/drm_dp_helper.h
> b/include/drm/display/drm_dp_helper.h
> index 3369104e2d25..6968d4d87931 100644
> --- a/include/drm/display/drm_dp_helper.h
> +++ b/include/drm/display/drm_dp_helper.h
> @@ -164,6 +164,7 @@ drm_dp_is_branch(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])  }
> 
>  /* DP/eDP DSC support */
> +u8 drm_dp_dsc_sink_bpp_incr(const u8
> +dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
>  u8 drm_dp_dsc_sink_max_slice_count(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE],
>  bool is_edp);
>  u8 drm_dp_dsc_sink_line_buf_depth(const u8
> dsc_dpcd[DP_DSC_RECEIVER_CAP_SIZE]);
> --
> 2.25.1



Re: [Intel-gfx] [PATCH 5/8] drm/i915/dsc: drop redundant = 0 assignments

2023-09-07 Thread Kandpal, Suraj
> Subject: [PATCH 5/8] drm/i915/dsc: drop redundant = 0 assignments
> 
> Directly assign the values instead of first assigning 0 and then |= the 
> values.
> 

LGTM.

Reviewed-by: Suraj Kandpal 

> Cc: Suraj Kandpal 
> Cc: Ankit Nautiyal 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 43 ---
>  1 file changed, 15 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 4086dbb25ca5..73bfa4d6633d 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -415,7 +415,7 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   const struct drm_dsc_config *vdsc_cfg = _state->dsc.config;
>   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
>   enum pipe pipe = crtc->pipe;
> - u32 pps_val = 0;
> + u32 pps_val;
>   u32 rc_buf_thresh_dword[4];
>   u32 rc_range_params_dword[8];
>   int i = 0;
> @@ -446,42 +446,36 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   intel_dsc_pps_write(crtc_state, 0, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_1 registers */
> - pps_val = 0;
> - pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel);
> + pps_val = DSC_BPP(vdsc_cfg->bits_per_pixel);
>   drm_dbg_kms(_priv->drm, "PPS1 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 1, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_2 registers */
> - pps_val = 0;
> - pps_val |= DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
> + pps_val = DSC_PIC_HEIGHT(vdsc_cfg->pic_height) |
>   DSC_PIC_WIDTH(vdsc_cfg->pic_width / num_vdsc_instances);
>   drm_dbg_kms(_priv->drm, "PPS2 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 2, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_3 registers */
> - pps_val = 0;
> - pps_val |= DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
> + pps_val = DSC_SLICE_HEIGHT(vdsc_cfg->slice_height) |
>   DSC_SLICE_WIDTH(vdsc_cfg->slice_width);
>   drm_dbg_kms(_priv->drm, "PPS3 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 3, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_4 registers */
> - pps_val = 0;
> - pps_val |= DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
> + pps_val = DSC_INITIAL_XMIT_DELAY(vdsc_cfg->initial_xmit_delay) |
>   DSC_INITIAL_DEC_DELAY(vdsc_cfg->initial_dec_delay);
>   drm_dbg_kms(_priv->drm, "PPS4 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 4, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_5 registers */
> - pps_val = 0;
> - pps_val |= DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
> + pps_val = DSC_SCALE_INC_INT(vdsc_cfg->scale_increment_interval) |
>   DSC_SCALE_DEC_INT(vdsc_cfg->scale_decrement_interval);
>   drm_dbg_kms(_priv->drm, "PPS5 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 5, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_6 registers */
> - pps_val = 0;
> - pps_val |= DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
> + pps_val = DSC_INITIAL_SCALE_VALUE(vdsc_cfg->initial_scale_value) |
>   DSC_FIRST_LINE_BPG_OFFSET(vdsc_cfg->first_line_bpg_offset)
> |
>   DSC_FLATNESS_MIN_QP(vdsc_cfg->flatness_min_qp) |
>   DSC_FLATNESS_MAX_QP(vdsc_cfg->flatness_max_qp);
> @@ -489,29 +483,25 @@ static void intel_dsc_pps_configure(const struct
> intel_crtc_state *crtc_state)
>   intel_dsc_pps_write(crtc_state, 6, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_7 registers */
> - pps_val = 0;
> - pps_val |= DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) |
> + pps_val = DSC_SLICE_BPG_OFFSET(vdsc_cfg->slice_bpg_offset) |
>   DSC_NFL_BPG_OFFSET(vdsc_cfg->nfl_bpg_offset);
>   drm_dbg_kms(_priv->drm, "PPS7 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 7, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_8 registers */
> - pps_val = 0;
> - pps_val |= DSC_FINAL_OFFSET(vdsc_cfg->final_offset) |
> + pps_val = DSC_FINAL_OFFSET(vdsc_cfg->final_offset) |
>   DSC_INITIAL_OFFSET(vdsc_cfg->initial_offset);
>   drm_dbg_kms(_priv->drm, "PPS8 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 8, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_9 registers */
> - pps_val = 0;
> - pps_val |= DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
> + pps_val = DSC_RC_MODEL_SIZE(vdsc_cfg->rc_model_size) |
>   DSC_RC_EDGE_FACTOR(DSC_RC_EDGE_FACTOR_CONST);
>   drm_dbg_kms(_priv->drm, "PPS9 = 0x%08x\n", pps_val);
>   intel_dsc_pps_write(crtc_state, 9, pps_val);
> 
>   /* Populate PICTURE_PARAMETER_SET_10 registers */
> - pps_val = 0;
> - pps_val |= 

Re: [Intel-gfx] [PATCH v5] drm/i915: Added Wa_18022495364

2023-09-14 Thread Kandpal, Suraj
> Subject: [Intel-gfx] [PATCH v5] drm/i915: Added Wa_18022495364
> 

Commit message style should be imperative so the header becomes something
Around the lines of 
"Add Wa_18022495364"

> Set the instruction and state cache invalidate bit using INDIRECT_CTX on every
> gpu context switch.
> The goal of this workaround is to actually perform an explicit invalidation of
> that cache (by re-writing the register) during every GPU context switch, 
> which is
> accomplished via a "workaround batchbuffer"
> that's attached to the context via INDIRECT_CTX. (Matt)
> BSpec: 11354
> 
> v2:
> - Removed extra parentheses from the condition (Lucas)
> - Fixed spacing and new line (Lucas)
> 
> v3:
> - Fixed commit message.
> 
> v4:
> - Only GEN12 changes are kept  (Matt Ropper)
> - Fixed the commit message for r-b (Matt Ropper)
> - Renamed the register bit in define
> 
> v5:
> - Moved out the  from golden context init (Matt Roper)
> - Use INDIRECT_CTX to set bit on each GPU context switch (Matt Roper)
> 

Same thing applies to the above version fix description
Remove, Fix, Rename, Move

Regards,
Suraj Kandpal
> Cc: Lucas De Marchi 
> Cc: Matt Roper 
> Signed-off-by: Dnyaneshwar Bhadane 
> 
> ---
>  drivers/gpu/drm/i915/gt/intel_gt_regs.h |  2 ++
>  drivers/gpu/drm/i915/gt/intel_lrc.c | 15 +++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 0e4c638fcbbf..38f02ef8ed01 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -164,6 +164,8 @@
>  #define GEN9_CSFE_CHICKEN1_RCS   _MMIO(0x20d4)
>  #define   GEN9_PREEMPT_GPGPU_SYNC_SWITCH_DISABLE (1 << 2)
>  #define   GEN11_ENABLE_32_PLANE_MODE (1 << 7)
> +#define GEN12_CS_DEBUG_MODE2 _MMIO(0x20d8)
> +#define   INSTRUCTION_STATE_CACHE_INVALIDATE REG_BIT(6)
> 
>  #define GEN7_FF_SLICE_CS_CHICKEN1_MMIO(0x20e0)
>  #define   GEN9_FFSC_PERCTX_PREEMPT_CTRL  (1 << 14)
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 967fe4d77a87..fe98039499c5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1332,6 +1332,15 @@ dg2_emit_draw_watermark_setting(u32 *cs)
>   return cs;
>  }
> 
> +static u32 *
> +gen12_set_instruction_state_cache_invalid(u32 *cs) {
> + *cs++ = MI_LOAD_REGISTER_IMM(1);
> + *cs++ = i915_mmio_reg_offset(GEN12_CS_DEBUG_MODE2);
> + *cs++ =
> _MASKED_BIT_ENABLE(INSTRUCTION_STATE_CACHE_INVALIDATE);
> + return cs;
> +}
> +
>  static u32 *
>  gen12_emit_indirect_ctx_rcs(const struct intel_context *ce, u32 *cs)  { @@ -
> 1345,6 +1354,12 @@ gen12_emit_indirect_ctx_rcs(const struct intel_context
> *ce, u32 *cs)
> 
>   cs = gen12_emit_aux_table_inv(ce->engine, cs);
> 
> + /* Wa_18022495364 */
> + if (IS_ALDERLAKE_P(ce->engine->i915) || IS_ALDERLAKE_P_N(ce-
> >engine->i915) ||
> + IS_ALDERLAKE_S(ce->engine->i915) || IS_TIGERLAKE(ce->engine-
> >i915) ||
> + IS_ROCKETLAKE(ce->engine->i915) || IS_DG1(ce->engine-
> >i915))
> + cs = gen12_set_instruction_state_cache_invalid(cs);
> +
>   /* Wa_16014892111 */
>   if (IS_GFX_GT_IP_STEP(ce->engine->gt, IP_VER(12, 70), STEP_A0,
> STEP_B0) ||
>   IS_GFX_GT_IP_STEP(ce->engine->gt, IP_VER(12, 71), STEP_A0,
> STEP_B0) ||
> --
> 2.34.1



Re: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and initialize HDMI audio capabilities

2023-09-08 Thread Kandpal, Suraj
> Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and 
> initialize
> HDMI audio capabilities
> 
> Hi Suraj,
> 
> > -Original Message-
> > From: Kandpal, Suraj 
> > Sent: 05 September 2023 14:47
> > To: Golani, Mitulkumar Ajitkumar
> > ;
> > intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani 
> > Subject: RE: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and
> > initialize HDMI audio capabilities
> >
> > > Subject: [Intel-gfx] [PATCH 3/3] drm/i915/display: Configure and
> > > initialize HDMI audio capabilities
> > >
> > > Initialize the source audio capabilities in the crtc_state property,
> > > setting them to
> >
> > Nit: maybe mention the above as intel_crtc_state rather than
> > crtc_state property as property usually refer to as drm_property and
> > it just seems a little weird to read. I have seen this in some of your
> > previous patches in this series you can make the changes there as well.
> >
> > > their maximum supported values for max_channel and max_rate. This
> > > initialization enables the calculation of audio source capabilities
> > > concerning the available mode bandwidth. These capabilities
> > > encompass parameters such as supported rate and channel configurations.
> > >
> > > Additionally, introduces a wrapper function for computing Short
> > > Audio Descriptors (SADs). The wrapper function incorporates logic
> > > for determining
> >
> > Typo * introduce
> >
> > > supported rates and channels according to the capabilities of the
> > > audio
> > source.
> > > It returns a set of SADs that are compatible with the audio source's
> > capabilities.
> > >
> > > --v1:
> > > - Refactor max_channel and max_rate to this commit as it is being
> > > initialised here
> > > - Remove call for intel_audio_compute_eld to avoid any regression
> > > while merge. instead call it in different commit when it is defined.
> > > - Use int instead of unsigned int for max_channel and max_frequecy
> > > - Update commit message and header
> > >
> > > --v2:
> > > - Use signed instead of unsigned variables.
> > > - Avoid using magic numbers and give them proper name.
> > >
> > > --v3:
> > > - Move defines to intel_audio.c.
> > > - use consistent naming convention for rate and channel.
> > > - declare num_of_channel and aud_rate separately.
> > > - Declare index value outside of for loop.
> > > - Move Bandwidth calculation to intel_Audio.c as it is common for
> > > both DP and HDMI. Also use static.
> > >
> > > --v10:
> > > - Merged patch 2 and 3 to deduplicate function calls.
> > > - Instead using Calibrate and calculated functions separately,
> > > removed code duplication and merged functions.[Nikula, Jani]
> > > - Remove magic value for SAD Channel mask. [Nikula, Jani]
> > > - Corrected rate values based on HDMI Spec [Nikula, Jani]
> > > - Update drm function to extract SAD from ELD [Nikula, Jani]
> > >
> > > Signed-off-by: Mitul Golani 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_audio.c| 127 ++
> > >  .../drm/i915/display/intel_display_types.h|   6 +
> > >  2 files changed, 133 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> > > b/drivers/gpu/drm/i915/display/intel_audio.c
> > > index e20ffc8e9654..2584096d80a4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_audio.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> > > @@ -64,6 +64,10 @@
> > >   * struct _audio_component_audio_ops @audio_ops is called from
> > > i915 driver.
> > >   */
> > >
> > > +#define AUDIO_SAMPLE_CONTAINER_SIZE  32
> > > +#define MAX_CHANNEL_COUNT8
> > > +#define ELD_SAD_CHANNELS_MASK0x7
> >
> > Use REG_GENMASK() to create masks should look cleaner
> 
> you should use REG_GENMASK when you need to create a bitmask that covers
> a specific range of bits within a register or variable.
> I think If you are defining a simple bitmask like in above example, there's no
> need to use REG_GENMASK.
> 

We can still used GENMASK macro or BITMASK do have a look there

> > > +
> > >  struct intel_audio_funcs {
> > >   void (*audio_codec_enable)(struct intel_encoder *encoder,
> > >  const struct intel_c

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vdsc: Remove old comment about DSC 444 support

2023-10-31 Thread Kandpal, Suraj



> -Original Message-
> From: Intel-gfx  On Behalf Of Ankit
> Nautiyal
> Sent: Monday, October 16, 2023 10:51 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915/vdsc: Remove old comment about
> DSC 444 support
> 
> DSC with YCbCr420 is now supported, so remove the comment mentioning
> support for only 444 format.
> 
> Signed-off-by: Ankit Nautiyal 

LGTM.

Reviewed-by: Suraj Kandpal 

> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 708c6d4da0a2..a6f15a51e82c 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -123,7 +123,6 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
>   vdsc_cfg->slice_height
> - 1);
>   }
> 
> - /* Our hw supports only 444 modes as of today */
>   if (bpp >= 12)
>   vdsc_cfg->initial_offset = 2048;
>   else if (bpp >= 10)
> --
> 2.40.1



Re: [Intel-gfx] [PATCH 1/2] drm/i915/dsc: Use helper to calculate range_bpg_offset

2023-10-31 Thread Kandpal, Suraj



> -Original Message-
> From: Intel-gfx  On Behalf Of Ankit
> Nautiyal
> Sent: Monday, October 16, 2023 10:51 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915/dsc: Use helper to calculate
> range_bpg_offset
> 
> We get range_bpg_offset for different bpps based on linear-interpolation from
> values given for nearby bpps.
> Use a helper to get these values.
> 
> Signed-off-by: Ankit Nautiyal 

LGTM. 

Reviewed-by: Suraj Kandpal 

> ---
>  drivers/gpu/drm/i915/display/intel_vdsc.c | 59 ---
>  1 file changed, 30 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index 6757dbae9ee5..708c6d4da0a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -65,6 +65,13 @@ intel_vdsc_set_min_max_qp(struct drm_dsc_config
> *vdsc_cfg, int buf,
>   intel_lookup_range_max_qp(bpc, buf, bpp, vdsc_cfg-
> >native_420);  }
> 
> +static int
> +get_range_bpg_offset(int bpp_low, int offset_low, int bpp_high, int
> +offset_high, int bpp) {
> + return offset_low + DIV_ROUND_UP((offset_high - offset_low) * (bpp -
> bpp_low),
> +  (bpp_low - bpp_high));
> +}
> +
>  /*
>   * We are using the method provided in DSC 1.2a C-Model in codec_main.c
>   * Above method use a common formula to derive values for any combination
> of DSC @@ -82,7 +89,7 @@ calculate_rc_params(struct drm_dsc_config
> *vdsc_cfg)
>   int qp_bpc_modifier = (bpc - 8) * 2;
>   int uncompressed_bpg_rate;
>   int first_line_bpg_offset;
> - u32 res, buf_i, bpp_i;
> + u32 buf_i, bpp_i;
> 
>   if (vdsc_cfg->slice_height >= 8)
>   first_line_bpg_offset =
> @@ -156,23 +163,19 @@ calculate_rc_params(struct drm_dsc_config
> *vdsc_cfg)
>   intel_vdsc_set_min_max_qp(vdsc_cfg, buf_i, bpp_i);
> 
>   /* Calculate range_bpg_offset */
> - if (bpp <= 8) {
> + if (bpp <= 8)
>   range_bpg_offset = ofs_und4[buf_i];
> - } else if (bpp <= 10) {
> - res = DIV_ROUND_UP(((bpp - 8) *
> - (ofs_und5[buf_i] -
> ofs_und4[buf_i])), 2);
> - range_bpg_offset = ofs_und4[buf_i] + res;
> - } else if (bpp <= 12) {
> - res = DIV_ROUND_UP(((bpp - 10) *
> - (ofs_und6[buf_i] -
> ofs_und5[buf_i])), 2);
> - range_bpg_offset = ofs_und5[buf_i] + res;
> - } else if (bpp <= 16) {
> - res = DIV_ROUND_UP(((bpp - 12) *
> - (ofs_und8[buf_i] -
> ofs_und6[buf_i])), 4);
> - range_bpg_offset = ofs_und6[buf_i] + res;
> - } else {
> + else if (bpp <= 10)
> + range_bpg_offset = get_range_bpg_offset(8,
> ofs_und4[buf_i],
> + 10,
> ofs_und5[buf_i], bpp);
> + else if (bpp <= 12)
> + range_bpg_offset = get_range_bpg_offset(10,
> ofs_und5[buf_i],
> + 12,
> ofs_und6[buf_i], bpp);
> + else if (bpp <= 16)
> + range_bpg_offset = get_range_bpg_offset(12,
> ofs_und6[buf_i],
> + 16,
> ofs_und8[buf_i], bpp);
> + else
>   range_bpg_offset = ofs_und8[buf_i];
> - }
> 
>   vdsc_cfg->rc_range_params[buf_i].range_bpg_offset =
>   range_bpg_offset &
> DSC_RANGE_BPG_OFFSET_MASK; @@ -198,21 +201,19 @@
> calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
>   intel_vdsc_set_min_max_qp(vdsc_cfg, buf_i, bpp_i);
> 
>   /* Calculate range_bpg_offset */
> - if (bpp <= 6) {
> + if (bpp <= 6)
>   range_bpg_offset = ofs_und6[buf_i];
> - } else if (bpp <= 8) {
> - res = DIV_ROUND_UP(((bpp - 6) *
> - (ofs_und8[buf_i] -
> ofs_und6[buf_i])), 2);
> - range_bpg_offset = ofs_und6[buf_i] + res;
> - } else if (bpp <= 12) {
> - range_bpg_offset = ofs_und8[buf_i];
> - } else if (bpp <= 15) {
> - res = DIV_ROUND_UP(((bpp - 12) *
> - (ofs_und15[buf_i] -

Re: [Intel-gfx] [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, October 26, 2023 1:02 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: Re: [PATCH 1/2] drm/i915/hdcp: Create a blanket hdcp enable function
> 
> On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> > Let's create a blanket function which just has some conditions which
> > need to be checked before connectors enable hdcp.
> > This cleans up code and avoids code duplication.
> 
> Let's call that function intel_hdcp_enable(), and hide all the details inside
> intel_hdcp.c. These are the only callers outside of intel_hdcp.c.

Maybe the rename current intel_hdcp_enable() to something else as that also is 
called in
Intel_hdcp_update_pipe on which I wouldn't want these conditions to be enforced.
I thought of renaming the current intel_hdcp_enable() to _intel_hdcp_enable() 
but that is already
Being used as a function name to enable hdcp1.4
So any suggestions what I can rename it to?

Regards,
Suraj Kandpal
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
> >  drivers/gpu/drm/i915/display/intel_hdcp.c   | 11 +++
> >  drivers/gpu/drm/i915/display/intel_hdcp.h   |  4 
> >  4 files changed, 17 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9151d5add960..338049b66e9c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> > +   intel_hdcp_try_enable(state, encoder, crtc_state, conn_state);
> >  }
> >
> >  static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 7b4628f4f124..cfcaf54a4a72 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct
> > intel_atomic_state *state,
> >
> > intel_audio_codec_enable(encoder, pipe_config, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> > +   intel_hdcp_try_enable(state, encoder, pipe_config, conn_state);
> >  }
> >
> >  static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder
> > *encoder, diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index c89da3568ebd..9d632a85309d 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2324,6 +2324,17 @@ intel_hdcp_set_streams(struct intel_digital_port
> *dig_port,
> > return 0;
> >  }
> >
> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state) {
> > +   /* Enable hdcp if it's desired */
> > +   if (conn_state->content_protection ==
> > +   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > +   intel_hdcp_enable(state, encoder, crtc_state, conn_state); }
> > +
> >  int intel_hdcp_enable(struct intel_atomic_state *state,
> >   struct intel_encoder *encoder,
> >   const struct intel_crtc_state *pipe_config, diff --git
> > a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > index 5997c52a0958..280eaa4d1010 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.h
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.h
> > @@ -44,5 +44,9 @@ void intel_hdcp_component_init(struct
> > drm_i915_private *i915);  void intel_hdcp_component_fini(struct
> > drm_i915_private *i915);  void intel_hdcp_cleanup(struct
> > intel_connector *connector);  void intel_hdcp_handle_cp_irq(struct
> > intel_connector *connector);
> > +void intel_hdcp_try_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state);
> >
> >  #endif /* __INTEL_HDCP_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function

2023-10-26 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Thursday, October 26, 2023 3:34 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma ; Nautiyal, Ankit K
> ; Kandpal, Suraj 
> Subject: Re: [PATCH 2/3] drm/i915/hdcp: Create a blanket hdcp enable function
> 
> On Thu, 26 Oct 2023, Suraj Kandpal  wrote:
> > Let's create a blanket function which just has some conditions which
> > need to be checked before connectors enable hdcp.
> > This cleans up code and avoids code duplication.
> 
> This series has two 2/3 patches... confused me, probably going to confuse CI
> too...
> 
Weird will send out a new patch series just in case
Though the patchwork seems to catch it properly
https://patchwork.freedesktop.org/series/125550/

Regards,
Suraj Kandpal
> BR,
> Jani.
> 
> 
> >
> > --v3
> > -Keep function name as intel_hdcp_enable() [Jani]
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_ddi.c|  5 +
> >  drivers/gpu/drm/i915/display/intel_dp_mst.c |  5 +
> >  drivers/gpu/drm/i915/display/intel_hdcp.c   | 21 -
> >  drivers/gpu/drm/i915/display/intel_hdcp.h   |  8 
> >  4 files changed, 22 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 9151d5add960..b644cf981846 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -3259,10 +3259,7 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> > +   intel_hdcp_enable(state, encoder, crtc_state, conn_state);
> >  }
> >
> >  static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > index 7b4628f4f124..4366da79fe81 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > @@ -836,10 +836,7 @@ static void intel_mst_enable_dp(struct
> > intel_atomic_state *state,
> >
> > intel_audio_codec_enable(encoder, pipe_config, conn_state);
> >
> > -   /* Enable hdcp if it's desired */
> > -   if (conn_state->content_protection ==
> > -   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > -   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> > +   intel_hdcp_enable(state, encoder, pipe_config, conn_state);
> >  }
> >
> >  static bool intel_dp_mst_enc_get_hw_state(struct intel_encoder
> > *encoder, diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 7c0cfcb48521..44c0a93f3af8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -2324,10 +2324,10 @@ intel_hdcp_set_streams(struct intel_digital_port
> *dig_port,
> > return 0;
> >  }
> >
> > -int intel_hdcp_enable(struct intel_atomic_state *state,
> > - struct intel_encoder *encoder,
> > - const struct intel_crtc_state *pipe_config,
> > - const struct drm_connector_state *conn_state)
> > +static int _intel_hdcp_enable(struct intel_atomic_state *state,
> > + struct intel_encoder *encoder,
> > + const struct intel_crtc_state *pipe_config,
> > + const struct drm_connector_state *conn_state)
> >  {
> > struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > struct intel_connector *connector =
> > @@ -2404,6 +2404,17 @@ int intel_hdcp_enable(struct intel_atomic_state
> *state,
> > return ret;
> >  }
> >
> > +void intel_hdcp_enable(struct intel_atomic_state *state,
> > +  struct intel_encoder *encoder,
> > +  const struct intel_crtc_state *crtc_state,
> > +  const struct drm_connector_state *conn_state) {
> > +   /* Enable hdcp if it's desired */
> > +   if (conn_state->content_protection ==
> > +   DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > +   _intel_hdcp_enable(state, encoder, c

Re: [Intel-gfx] [PATCH 2/2] drm/i915/hdcp: Move common message filling function to its own file

2023-09-20 Thread Kandpal, Suraj
> Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/hdcp: Move common message
> filling function to its own file
> 
> On Wed, 20 Sep 2023, Suraj Kandpal  wrote:
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > index eba2057c5a9e..e53dbe8d9048 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > @@ -9,6 +9,8 @@
> >  #include 
> >  #include 
> >
> > +#include "i915_drv.h"
> > +
> 
> Please don't include i915_drv.h from headers if it can be avoided. This patch 
> for
> sure has no reason to do so.
> 
> >  struct drm_i915_private;
> >
> >  struct intel_hdcp_gsc_message {
> 
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > new file mode 100644
> > index ..8da3c50d759f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > @@ -0,0 +1,56 @@
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * Copyright © 2023 Intel Corporation  */
> > +
> > +#ifndef __INTEL_HDCP_GSC_MESSAGE_H__
> > +#define __INTEL_HDCP_GSC_MESSAGE_H__
> > +
> > +#include 
> > +
> > +#include "intel_hdcp_gsc.h"
> 
> What in this header requires including either of those headers that can't be
> solved with forward declatations?
> 
> *Always* use forward declarations instead of #includes in headers if you can.
> 
> AFAICT this only needs #include  and a bunch of forward
> declarations.
> 

Thanks for the reviews Jani. Will six and send the latest version

Regards,
Suraj Kandpal

> BR,
> Jani.
> 
> > +
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915); int
> > +intel_hdcp_gsc_initiate_session(struct device *dev, struct hdcp_port_data
> *data,
> > +   struct hdcp2_ake_init *ake_data); int
> > +intel_hdcp_gsc_verify_receiver_cert_prepare_km(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ake_send_cert
> *rx_cert,
> > +  bool *km_stored,
> > +  struct hdcp2_ake_no_stored_km
> > +  *ek_pub_km,
> > +  size_t *msg_sz);
> > +int
> > +intel_hdcp_gsc_verify_hprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_ake_send_hprime *rx_hprime); int
> > +intel_hdcp_gsc_store_pairing_info(struct device *dev, struct hdcp_port_data
> *data,
> > + struct hdcp2_ake_send_pairing_info
> *pairing_info); int
> > +intel_hdcp_gsc_initiate_locality_check(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_lc_init *lc_init_data); int
> > +intel_hdcp_gsc_verify_lprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_lc_send_lprime *rx_lprime); int
> > +intel_hdcp_gsc_get_session_key(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ske_send_eks *ske_data); int
> > +intel_hdcp_gsc_repeater_check_flow_prepare_ack(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct
> hdcp2_rep_send_receiverid_list
> > +  *rep_topology,
> > +  struct hdcp2_rep_send_ack
> > +  *rep_send_ack);
> > +int intel_hdcp_gsc_verify_mprime(struct device *dev,
> > +struct hdcp_port_data *data,
> > +struct hdcp2_rep_stream_ready
> *stream_ready); int
> > +intel_hdcp_gsc_enable_authentication(struct device *dev,
> > +struct hdcp_port_data *data);
> > +int
> > +intel_hdcp_gsc_close_session(struct device *dev, struct
> > +hdcp_port_data *data);
> > +
> > +#endif /* __INTEL_HDCP_GSC_MESSAGE_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/hdcp: Move common message filling function to its own file

2023-09-20 Thread Kandpal, Suraj

> Subject: Re: [PATCH v3 2/2] drm/i915/hdcp: Move common message filling
> function to its own file
> 
> On Wed, 20 Sep 2023, Suraj Kandpal  wrote:
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > new file mode 100644
> > index ..1096dd36823f
> > --- /dev/null
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc_message.h
> > @@ -0,0 +1,73 @@
> > +/* SPDX-License-Identifier: MIT */
> > +/*
> > + * Copyright © 2023 Intel Corporation  */
> > +
> > +#ifndef __INTEL_HDCP_GSC_MESSAGE_H__
> > +#define __INTEL_HDCP_GSC_MESSAGE_H__
> > +
> > +#include 
> 
> What does this header need from err.h?
> 

Ahh right this can be moved to intel_hdcp_gsc_message.c
I don’t know where my mind wanders off too :-[

Regards,
Suraj Kandpal

> BR,
> Jani.
> 
> > +#include 
> > +
> > +struct device;
> > +struct drm_i915_private;
> > +struct hdcp_port_data;
> > +struct hdcp2_ake_init;
> > +struct hdcp2_ake_send_cert;
> > +struct hdcp2_ake_no_stored_km;
> > +struct hdcp2_ake_send_hprime;
> > +struct hdcp2_ake_send_pairing_info;
> > +struct hdcp2_lc_init;
> > +struct hdcp2_lc_send_lprime;
> > +struct hdcp2_ske_send_eks;
> > +struct hdcp2_rep_send_receiverid_list; struct hdcp2_rep_send_ack;
> > +struct hdcp2_rep_stream_ready;
> > +
> > +ssize_t intel_hdcp_gsc_msg_send(struct drm_i915_private *i915, u8
> *msg_in,
> > +   size_t msg_in_len, u8 *msg_out,
> > +   size_t msg_out_len);
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915); int
> > +intel_hdcp_gsc_initiate_session(struct device *dev, struct hdcp_port_data
> *data,
> > +   struct hdcp2_ake_init *ake_data); int
> > +intel_hdcp_gsc_verify_receiver_cert_prepare_km(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ake_send_cert
> *rx_cert,
> > +  bool *km_stored,
> > +  struct hdcp2_ake_no_stored_km
> > +  *ek_pub_km,
> > +  size_t *msg_sz);
> > +int
> > +intel_hdcp_gsc_verify_hprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_ake_send_hprime *rx_hprime); int
> > +intel_hdcp_gsc_store_pairing_info(struct device *dev, struct
> hdcp_port_data *data,
> > + struct hdcp2_ake_send_pairing_info
> *pairing_info); int
> > +intel_hdcp_gsc_initiate_locality_check(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_lc_init *lc_init_data); int
> > +intel_hdcp_gsc_verify_lprime(struct device *dev, struct hdcp_port_data
> *data,
> > +struct hdcp2_lc_send_lprime *rx_lprime); int
> > +intel_hdcp_gsc_get_session_key(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct hdcp2_ske_send_eks *ske_data); int
> > +intel_hdcp_gsc_repeater_check_flow_prepare_ack(struct device *dev,
> > +  struct hdcp_port_data *data,
> > +  struct
> hdcp2_rep_send_receiverid_list
> > +  *rep_topology,
> > +  struct hdcp2_rep_send_ack
> > +  *rep_send_ack);
> > +int intel_hdcp_gsc_verify_mprime(struct device *dev,
> > +struct hdcp_port_data *data,
> > +struct hdcp2_rep_stream_ready
> *stream_ready); int
> > +intel_hdcp_gsc_enable_authentication(struct device *dev,
> > +struct hdcp_port_data *data);
> > +int
> > +intel_hdcp_gsc_close_session(struct device *dev, struct
> > +hdcp_port_data *data);
> > +
> > +#endif /* __INTEL_HDCP_GSC_MESSAGE_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915/ddi: Fix i2c_adapter assignment

2023-10-05 Thread Kandpal, Suraj
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/ddi: Fix i2c_adapter assignment
> 
> On Thu, 05 Oct 2023, Ville Syrjälä  wrote:
> > On Thu, Oct 05, 2023 at 12:12:58PM +0530, Suraj Kandpal wrote:
> >> i2c_adapter is being assigned using intel_connector even before the
> >> NULL check occurs and even though it shouldn't be a problem lets just
> >> clean this up as logically it does not make sense to check the
> >> connector for NULL but dereference it before that.
> >>
> >> Fixes: e046d1562491 ("drm/i915/hdmi: Use connector->ddc everwhere")
> >>
> >> Signed-off-by: Suraj Kandpal 
> >> ---
> >>  drivers/gpu/drm/i915/display/intel_ddi.c | 4 +++-
> >>  1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> index 4668de45d6fe..6b658faf1fc3 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> @@ -4326,7 +4326,7 @@ static int intel_hdmi_reset_link(struct
> intel_encoder *encoder,
> >>struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> >>struct intel_hdmi *hdmi = enc_to_intel_hdmi(encoder);
> >>struct intel_connector *connector = hdmi->attached_connector;
> >> -  struct i2c_adapter *ddc = connector->base.ddc;
> >> +  struct i2c_adapter *ddc;
> >>struct drm_connector_state *conn_state;
> >>struct intel_crtc_state *crtc_state;
> >>struct intel_crtc *crtc;
> >> @@ -4336,6 +4336,8 @@ static int intel_hdmi_reset_link(struct
> intel_encoder *encoder,
> >>if (!connector || connector->base.status !=
> connector_status_connected)
> >>return 0;
> >
> > The connector is never NULL here. So the check is just nonsense.
> 
> Yeah I'd rather remove that. Leaving it in makes people (and static analyzers,
> apprently) think it could be NULL, and that leads to more what ifs.
> 
> BR,
> Jani.
> 

Makes sense will remove the connector check instead of moving the assignment 
around

Regards,
Suraj Kandpal

> >
> >>
> >> +  ddc = connector->base.ddc;
> >> +
> >>ret = drm_modeset_lock(_priv-
> >drm.mode_config.connection_mutex,
> >>   ctx);
> >>if (ret)
> >> --
> >> 2.25.1
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915/ddi: Fix i2c_adapter assignment

2023-10-05 Thread Kandpal, Suraj
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/ddi: Fix i2c_adapter assignment
> 
> Hi Suraj,
> 
> On Thu, Oct 05, 2023 at 12:12:58PM +0530, Suraj Kandpal wrote:
> > i2c_adapter is being assigned using intel_connector even before the
> > NULL check occurs and even though it shouldn't be a problem lets just
> > clean this up as logically it does not make sense to check the
> > connector for NULL but dereference it before that.
> >
> > Fixes: e046d1562491 ("drm/i915/hdmi: Use connector->ddc everwhere")
> >
> > Signed-off-by: Suraj Kandpal 
> 
> please don't leave a blank line in the tag section. No need to resend, I guess
> whoever will merge this patch can fix it before pushing.
> 

Hi Andi,
Thanks for the review ! will keep this in mind in future

Regards,
Suraj Kandpal

> Reviewed-by: Andi Shyti 
> 
> Andi


Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

2023-10-09 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Monday, October 9, 2023 4:07 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in
> verify_crtc_state
> 
> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > Free hw_crtc_state in verify_crtc_state after we are done using this
> > or else it's just a resource leak.
> 
> Fixes: ?

Cant really trace when this was introduced as this function was split from
Intel_display.c to intel_modeset_verify.c and then this is the last commit that 
introduces it
df17ff62b626 drm/i915/display: split out modeset verification code

Should I use this commit in the fixes tag?

Regards,
Suraj Kandpal
> 
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > index 303eb68fec11..5e1c2c780412 100644
> > --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
> > }
> >
> > if (!sw_crtc_state->hw.active)
> > -   return;
> > +   goto destroy_state;
> >
> > intel_pipe_config_sanity_check(hw_crtc_state);
> >
> > @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
> > intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
> > intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
> > }
> > +
> > +destroy_state:
> > +   intel_crtc_destroy_state(>base, _crtc_state->uapi);
> >  }
> >
> >  void intel_modeset_verify_crtc(struct intel_atomic_state *state,
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc health status

2023-10-09 Thread Kandpal, Suraj



> -Original Message-
> From: Jani Nikula 
> Sent: Monday, October 9, 2023 3:37 PM
> To: Kandpal, Suraj ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 1/2] drm/i915/hdcp: Move checks for gsc
> health status
> 
> On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > Move checks for gsc components required for HDCP 2.2 to work into
> > intel_hdcp_gsc.c. This will also help with XE refactor on HDCP's side.
> >
> > Signed-off-by: Suraj Kandpal 
> > Reviewed-by: Uma Shankar 
> > ---
> >  drivers/gpu/drm/i915/display/intel_hdcp.c |  8 +---
> >  drivers/gpu/drm/i915/display/intel_hdcp_gsc.c | 14 ++
> > drivers/gpu/drm/i915/display/intel_hdcp_gsc.h |  1 +
> >  3 files changed, 16 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > index 8cca4793cf92..c89da3568ebd 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
> > @@ -173,14 +173,8 @@ bool intel_hdcp2_capable(struct intel_connector
> > *connector)
> >
> > /* If MTL+ make sure gsc is loaded and proxy is setup */
> > if (intel_hdcp_gsc_cs_required(i915)) {
> > -   struct intel_gt *gt = i915->media_gt;
> > -   struct intel_gsc_uc *gsc = gt ? >uc.gsc : NULL;
> > -
> > -   if (!gsc || !intel_uc_fw_is_running(>fw)) {
> > -   drm_dbg_kms(>drm,
> > -   "GSC components required for HDCP2.2 are
> not ready\n");
> > +   if (!intel_hdcp_gsc_check_status(i915))
> 
> Naming nitpick, though not intended to block the patch:
> 
> I always stop at functions named "check" that return a value. What does the
> return value mean? The above code reads, "if not check status".
> 
> So I usually try to name functions so that it's obvious on both sides what it
> means, when you read it aloud. For example, "if not status ok".
> 
> Just something to consider for the future.
> 
> 

Got it Jani will keep this in mind in future

Regards,
Suraj Kandpal
> BR,
> Jani.
> 
> 
> 
> > return false;
> > -   }
> > }
> >
> > /* MEI/GSC interface is solid depending on which is used */ diff
> > --git a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > index d753db3eef15..d355d610bc9f 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.c
> > @@ -17,6 +17,20 @@ bool intel_hdcp_gsc_cs_required(struct
> drm_i915_private *i915)
> > return DISPLAY_VER(i915) >= 14;
> >  }
> >
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915) {
> > +   struct intel_gt *gt = i915->media_gt;
> > +   struct intel_gsc_uc *gsc = gt ? >uc.gsc : NULL;
> > +
> > +   if (!gsc || !intel_uc_fw_is_running(>fw)) {
> > +   drm_dbg_kms(>drm,
> > +   "GSC components required for HDCP2.2 are not
> ready\n");
> > +   return false;
> > +   }
> > +
> > +   return true;
> > +}
> > +
> >  static int
> >  gsc_hdcp_initiate_session(struct device *dev, struct hdcp_port_data *data,
> >   struct hdcp2_ake_init *ake_data) diff --git
> > a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > index cbf96551e534..eba2057c5a9e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > +++ b/drivers/gpu/drm/i915/display/intel_hdcp_gsc.h
> > @@ -23,5 +23,6 @@ ssize_t intel_hdcp_gsc_msg_send(struct
> drm_i915_private *i915, u8 *msg_in,
> > size_t msg_out_len);
> >  int intel_hdcp_gsc_init(struct drm_i915_private *i915);  void
> > intel_hdcp_gsc_fini(struct drm_i915_private *i915);
> > +bool intel_hdcp_gsc_check_status(struct drm_i915_private *i915);
> >
> >  #endif /* __INTEL_HDCP_GCS_H__ */
> 
> --
> Jani Nikula, Intel


Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in verify_crtc_state

2023-10-09 Thread Kandpal, Suraj



> -Original Message-
> From: Ville Syrjälä 
> Sent: Monday, October 9, 2023 6:08 PM
> To: Kandpal, Suraj 
> Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state in
> verify_crtc_state
> 
> On Mon, Oct 09, 2023 at 10:58:22AM +, Kandpal, Suraj wrote:
> >
> >
> > > -Original Message-
> > > From: Jani Nikula 
> > > Sent: Monday, October 9, 2023 4:07 PM
> > > To: Kandpal, Suraj ;
> > > intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Free crtc_state
> > > in verify_crtc_state
> > >
> > > On Mon, 09 Oct 2023, Suraj Kandpal  wrote:
> > > > Free hw_crtc_state in verify_crtc_state after we are done using
> > > > this or else it's just a resource leak.
> > >
> > > Fixes: ?
> >
> > Cant really trace when this was introduced as this function was split
> > from Intel_display.c to intel_modeset_verify.c and then this is the
> > last commit that introduces it
> > df17ff62b626 drm/i915/display: split out modeset verification code
> >
> > Should I use this commit in the fixes tag?
> >
> 
> Mea culpa
> Fixes: 2745bdda2095 ("drm/i915: Stop clobbering old crtc state during state
> check")
> Reviewed-by: Ville Syrjälä 
> 
> BTW looks like intel_encoder_current_mode() can also leak some stuff on
> account of using kfree() instead of intel_crtc_destroy_state().
> Can you cook up a patch to fix that one as well?
> 
> And while vlv_force_pll_on() isn't actually leaking, it'd probably a good 
> idea to
> switch over to intel_crtc_destroy_state() there as well...

Sure will also float patches fixing the above mentioned issue

Regards,
Suraj Kandpal
> 
> > Regards,
> > Suraj Kandpal
> > >
> > > >
> > > > Signed-off-by: Suraj Kandpal 
> > > > ---
> > > >  drivers/gpu/drm/i915/display/intel_modeset_verify.c | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > > b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > > index 303eb68fec11..5e1c2c780412 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
> > > > @@ -214,7 +214,7 @@ verify_crtc_state(struct intel_atomic_state *state,
> > > > }
> > > >
> > > > if (!sw_crtc_state->hw.active)
> > > > -   return;
> > > > +   goto destroy_state;
> > > >
> > > > intel_pipe_config_sanity_check(hw_crtc_state);
> > > >
> > > > @@ -224,6 +224,9 @@ verify_crtc_state(struct intel_atomic_state *state,
> > > > intel_crtc_state_dump(hw_crtc_state, NULL, "hw state");
> > > > intel_crtc_state_dump(sw_crtc_state, NULL, "sw state");
> > > > }
> > > > +
> > > > +destroy_state:
> > > > +   intel_crtc_destroy_state(>base, _crtc_state->uapi);
> > > >  }
> > > >
> > > >  void intel_modeset_verify_crtc(struct intel_atomic_state *state,
> > >
> > > --
> > > Jani Nikula, Intel
> 
> --
> Ville Syrjälä
> Intel


Re: [Intel-gfx] [PATCH v3 0/4] drm/i915/tc: some clean-ups in max lane count handling code

2023-08-21 Thread Kandpal, Suraj
0/4] drm/i915/tc: some clean-ups in max
> lane count handling code
> 
> On Fri, Jul 21, 2023 at 02:11:17PM +0300, Luca Coelho wrote:
> >Hi,
> >
> >Here are four patches with some clean-ups in the code that handles the
> >max lane count of Type-C connections.
> >
> >This is done mostly in preparation for a new way to read the pin
> >assignments and lane count in future devices.
> >
> >In v2:
> >   * Fix some rebasing damage.
> >
> >In v3:
> >   * Fixed "assigment" typo, as reported by checkpatch.
> >
> >Please review.
> 
> what happened to this series? It seems only the last patch is not reviewed.
> Are you going to submit a rebased version?
> 

So I had some review comments on patch 3 was waiting for Luciano to upstream
the latest changes then review the 4th patch

Regards,
Suraj Kandpal

> 
> Lucas De Marchi


Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/tc: make intel_tc_port_get_lane_mask() static

2023-08-16 Thread Kandpal, Suraj
> This function is only used locally, so make it static and remove the 
> definition
> from the header file.
> 
> Signed-off-by: Luca Coelho 

LGTM 

Reviewed-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_tc.h | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 71bbc2b16a0e..de848b329f4b 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -260,7 +260,7 @@ assert_tc_port_power_enabled(struct intel_tc_port
> *tc)
>   !intel_display_power_is_enabled(i915,
> tc_port_power_domain(tc)));  }
> 
> -u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port)
> +static u32 intel_tc_port_get_lane_mask(struct intel_digital_port
> +*dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>   struct intel_tc_port *tc = to_tc_port(dig_port); diff --git
> a/drivers/gpu/drm/i915/display/intel_tc.h
> b/drivers/gpu/drm/i915/display/intel_tc.h
> index 3b16491925fa..ffc0e2a74e43 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.h
> +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> @@ -19,7 +19,6 @@ bool intel_tc_port_in_legacy_mode(struct
> intel_digital_port *dig_port);  bool intel_tc_port_connected(struct
> intel_encoder *encoder);  bool intel_tc_port_connected_locked(struct
> intel_encoder *encoder);
> 
> -u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port);
>  u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port);  int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> *dig_port);  void intel_tc_port_set_fia_lane_count(struct intel_digital_port
> *dig_port,
> --
> 2.39.2



Re: [Intel-gfx] [PATCH] drm/i915/dsi: Explicit first_line_bpg_offset assignment for DSI

2023-08-16 Thread Kandpal, Suraj
Also a small thing I needed to add is we found this patch series
https://patchwork.freedesktop.org/patch/549863/?series=121487=2

where panel sets the slice height to 40 if a value around 30 is given it should
work
not sure how relevant this is here but just an FYI

Regards,
Suraj Kandpal
> >
> > On Wed, 16 Aug 2023, Jani Nikula  wrote:
> > > On Wed, 16 Aug 2023, "Kandpal, Suraj" 
> wrote:
> > >>> On Mon, 07 Aug 2023, Suraj Kandpal 
> wrote:
> > >>> > Assign explicit value of 12 at 8bpp as per Table E2 of DSC 1.1
> > >>> > for DSI panels even though we already use calculations from
> > >>> > CModel for first_line_bpg_offset.
> > >>> > The reason being some DSI monitors may have not have added the
> > >>> > change in errata for the calculation of first_line_bpg_offset.
> > >
> > > We should be using DRM_DSC_1_1_PRE_SCR parameters for this, right?
> > Why
> 
> Sorry I seemed to have missed this comment in my previous reply but from
> how the code is written if display_ver >= 13 we call on calculate_rc_params
> which uses formulas to calculate the params and we don't rely on the dsc
> tables in drm_dsc_helpers so the DRM_DSC_1_1_PRE_SCR scenario does not
> come in picture.
> 
> > > does the array have post-SCR values for first_line_bpg_offset?
> >
> > I'm asking for logs on the gitlab issue, and trying to get at the root
> > of this, because so many times in the past adding a specific fix like
> > this for a specific panel (albeit using generic conditions), it has
> > caused more troule for other panels in the future. What if other panels
> don't work with 12?
> >
> 
> That is true which is why I too was unsure on the fix.
> 
> Maybe Tseng can provide the logs them on the gitlab issue.
> 
> Regards,
> Suraj Kandpal
> 
> > BR,
> > Jani.
> >
> >
> > >
> > >
> > >>> >
> > >>> > Signed-off-by: Suraj Kandpal 
> > >>> > ---
> > >>> >  drivers/gpu/drm/i915/display/icl_dsi.c | 5 +
> > >>> >  1 file changed, 5 insertions(+)
> > >>> >
> > >>> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > >>> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > >>> > index f7ebc146f96d..2376d5000d78 100644
> > >>> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > >>> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > >>> > @@ -1585,6 +1585,11 @@ static int
> > >>> > gen11_dsi_dsc_compute_config(struct
> > >>> intel_encoder *encoder,
> > >>> >   if (ret)
> > >>> >   return ret;
> > >>> >
> > >>> > + /* From Table E-2 in DSC 1.1*/
> > >>> > + if (vdsc_cfg->dsc_version_minor == 1 &&
> > >>> > + vdsc_cfg->bits_per_pixel == 128)
> > >>>
> > >> Hi Jani,
> > >> Thanks for the review
> > >>
> > >>> So, vdsc_cfg->bits_per_pixel has 4 fractional bits, and that's 8
> > >>> bpp compressed?
> > >>>
> > >>> Better describe it that way, instead of as 128.
> > >>>
> > >>
> > >> Yes would be better to right shift (vdsc_cfg->bits_per_pixel)  by 4
> > >> then compare with 8 to avoid confusion.
> > >>
> > >>> But... looking around, in intel_vdsc.c we set:
> > >>>
> > >>> pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel);
> > >>>
> > >>> and we have:
> > >>>
> > >>> #define DSC_BPP(bpp)((bpp) << 4)
> > >>>
> > >>> however, when reading it back in intel_dsc_get_config(), it's just
> > >>> directly:
> > >>>
> > >>> vdsc_cfg->bits_per_pixel = pps1;
> > >>>
> > >>> Are we always sending x16 bpp in PPS?
> > >>
> > >> Yes we are always sending bpp x16 considering the fractional bits
> > >> also in intel_vdsc_regs.h We have
> > >> #define  DSC_BPP(bpp)   ((bpp) << 0)
> > >
> > > This is the part that confused me.
> > >
> > > BR,
> > > Jani.
> > >
> > >> Which in hindsight can be renamed as it has the same name as the
> > >> one in drm_dsc_helper.c But then again the DSC_BPP macro there is
> > >> more
> > local to that file.
> > >>
> > >> Moreover vdsc_cfg->bits_per_pixel is being set in
> > >> intel_dsc_compute_params(among other places but is still being set
> > >> x16
> > the value).
> > >>
> > >> vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> > >>
> > >> Regards,
> > >> Suraj Kandpal
> > >>>
> > >>>
> > >>> BR,
> > >>> Jani.
> > >>>
> > >>>
> > >>>
> > >>> > + vdsc_cfg->first_line_bpg_offset = 12;
> > >>> > +
> > >>> >   /* DSI specific sanity checks on the common code */
> > >>> >   drm_WARN_ON(_priv->drm, vdsc_cfg->vbr_enable);
> > >>> >   drm_WARN_ON(_priv->drm, vdsc_cfg->simple_422);
> > >>>
> > >>> --
> > >>> Jani Nikula, Intel Open Source Graphics Center
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH] drm/i915/dsi: Explicit first_line_bpg_offset assignment for DSI

2023-08-16 Thread Kandpal, Suraj
> 
> On Wed, 16 Aug 2023, Jani Nikula  wrote:
> > On Wed, 16 Aug 2023, "Kandpal, Suraj"  wrote:
> >>> On Mon, 07 Aug 2023, Suraj Kandpal  wrote:
> >>> > Assign explicit value of 12 at 8bpp as per Table E2 of DSC 1.1 for
> >>> > DSI panels even though we already use calculations from CModel for
> >>> > first_line_bpg_offset.
> >>> > The reason being some DSI monitors may have not have added the
> >>> > change in errata for the calculation of first_line_bpg_offset.
> >
> > We should be using DRM_DSC_1_1_PRE_SCR parameters for this, right?
> Why

Sorry I seemed to have missed this comment in my previous reply but
from how the code is written if display_ver >= 13 we call on calculate_rc_params
which uses formulas to calculate the params and we don't rely on the dsc tables
in drm_dsc_helpers so the DRM_DSC_1_1_PRE_SCR scenario does not come in picture.
 
> > does the array have post-SCR values for first_line_bpg_offset?
> 
> I'm asking for logs on the gitlab issue, and trying to get at the root of 
> this,
> because so many times in the past adding a specific fix like this for a 
> specific
> panel (albeit using generic conditions), it has caused more troule for other
> panels in the future. What if other panels don't work with 12?
> 

That is true which is why I too was unsure on the fix.

Maybe Tseng can provide the logs them on the gitlab issue.

Regards,
Suraj Kandpal

> BR,
> Jani.
> 
> 
> >
> >
> >>> >
> >>> > Signed-off-by: Suraj Kandpal 
> >>> > ---
> >>> >  drivers/gpu/drm/i915/display/icl_dsi.c | 5 +
> >>> >  1 file changed, 5 insertions(+)
> >>> >
> >>> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> >>> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> >>> > index f7ebc146f96d..2376d5000d78 100644
> >>> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> >>> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> >>> > @@ -1585,6 +1585,11 @@ static int
> >>> > gen11_dsi_dsc_compute_config(struct
> >>> intel_encoder *encoder,
> >>> > if (ret)
> >>> > return ret;
> >>> >
> >>> > +   /* From Table E-2 in DSC 1.1*/
> >>> > +   if (vdsc_cfg->dsc_version_minor == 1 &&
> >>> > +   vdsc_cfg->bits_per_pixel == 128)
> >>>
> >> Hi Jani,
> >> Thanks for the review
> >>
> >>> So, vdsc_cfg->bits_per_pixel has 4 fractional bits, and that's 8 bpp
> >>> compressed?
> >>>
> >>> Better describe it that way, instead of as 128.
> >>>
> >>
> >> Yes would be better to right shift (vdsc_cfg->bits_per_pixel)  by 4
> >> then compare with 8 to avoid confusion.
> >>
> >>> But... looking around, in intel_vdsc.c we set:
> >>>
> >>>   pps_val |= DSC_BPP(vdsc_cfg->bits_per_pixel);
> >>>
> >>> and we have:
> >>>
> >>>   #define DSC_BPP(bpp)((bpp) << 4)
> >>>
> >>> however, when reading it back in intel_dsc_get_config(), it's just
> >>> directly:
> >>>
> >>>   vdsc_cfg->bits_per_pixel = pps1;
> >>>
> >>> Are we always sending x16 bpp in PPS?
> >>
> >> Yes we are always sending bpp x16 considering the fractional bits
> >> also in intel_vdsc_regs.h We have
> >> #define  DSC_BPP(bpp)   ((bpp) << 0)
> >
> > This is the part that confused me.
> >
> > BR,
> > Jani.
> >
> >> Which in hindsight can be renamed as it has the same name as the one
> >> in drm_dsc_helper.c But then again the DSC_BPP macro there is more
> local to that file.
> >>
> >> Moreover vdsc_cfg->bits_per_pixel is being set in
> >> intel_dsc_compute_params(among other places but is still being set x16
> the value).
> >>
> >> vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> >>
> >> Regards,
> >> Suraj Kandpal
> >>>
> >>>
> >>> BR,
> >>> Jani.
> >>>
> >>>
> >>>
> >>> > +   vdsc_cfg->first_line_bpg_offset = 12;
> >>> > +
> >>> > /* DSI specific sanity checks on the common code */
> >>> > drm_WARN_ON(_priv->drm, vdsc_cfg->vbr_enable);
> >>> > drm_WARN_ON(_priv->drm, vdsc_cfg->simple_422);
> >>>
> >>> --
> >>> Jani Nikula, Intel Open Source Graphics Center
> 
> --
> Jani Nikula, Intel Open Source Graphics Center


Re: [Intel-gfx] [PATCH v3 3/4] drm/i915/tc: move legacy code out of the main _max_lane_count() func

2023-08-16 Thread Kandpal, Suraj
> This makes the code a bit more symmetric and readable, especially when we
> start adding more display version-specific alternatives.
> 
> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 32 +++--
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index de848b329f4b..43b8eeba26f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -311,23 +311,12 @@ static int mtl_tc_port_get_max_lane_count(struct
> intel_digital_port *dig_port)
>   }
>  }
> 
> -int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> +static int intel_tc_port_get_max_lane_count(struct intel_digital_port
> +*dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - struct intel_tc_port *tc = to_tc_port(dig_port);
> - enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
>   intel_wakeref_t wakeref;
> - u32 lane_mask;
> -
> - if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> - return 4;
> + u32 lane_mask = 0;
> 
> - assert_tc_cold_blocked(tc);
> -
> - if (DISPLAY_VER(i915) >= 14)
> - return mtl_tc_port_get_max_lane_count(dig_port);
> -
> - lane_mask = 0;
>   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> wakeref)
>   lane_mask = intel_tc_port_get_lane_mask(dig_port);
> 
> @@ -348,6 +337,23 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
>   }
>  }
> 
> +int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> +*dig_port) {
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct intel_tc_port *tc = to_tc_port(dig_port);
> + enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> +
> + if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> + return 4;
> +
> + assert_tc_cold_blocked(tc);
> +
> + if (DISPLAY_VER(i915) >= 14)
> + return mtl_tc_port_get_max_lane_count(dig_port);
> +
> + return intel_tc_port_get_max_lane_count(dig_port);
> +}

Looking at this I think we have more scope of optimization here I think we can 
go about it in the following way

intel_tc_port_fia_max_lane_count
already calls 
with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
lane_mask = intel_tc_port_get_lane_mask(dig_port);

which we also duplicate in  mtl_tc_port_get_pin_assignment_mask
(now mtl_tc_port_get_max_lane_count) and the only difference between them
Is the switch case what if we have a function or repurpose 
mtl_tc_port_get_max_lane_count to only have the switch case block with 
assignment varied by display version and call it after 
intel_tc_port_get_lane_mask

maybe also move the legacy switch case in its own function?

Regards,
Suraj Kandpal

> +
>  void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> int required_lanes)
>  {
> --
> 2.39.2



Re: [Intel-gfx] [PATCH v7 4/8] drm/i915/vdsc: Add function to read any PPS register

2023-08-16 Thread Kandpal, Suraj
> 
> On Tue, 08 Aug 2023, Suraj Kandpal  wrote:
> > Add function to read any PPS register based on the intel_dsc_pps enum
> > provided. Add a function which will call the new pps read function and
> > place it in crtc state. Only PPS0 and
> > PPS1 are readout the rest of the registers will be read in upcoming
> > patches.
> >
> > --v2
> > -Changes in read function as PPS enum is removed -Initialize pps_val
> > as 0 in pps_read func itself [Jani] -Create a function that gets the
> > required register and call that in the common read function [Jani]
> > -Move the drm_WARN_ON one abstraction layer above [Jani]
> >
> > --v3
> > -Send both reg values regardless of dsc engine no [Jani] -Don't use
> > num_vdsc_instances stick to dsc_split field [Ankit]
> >
> > --v4
> > -Manipulate the reg values instead of creating MACRO to change name of
> > pps [Ankit]
> >
> > --v5
> > -Read dsc reg values using array rather than individual variables
> > [Ankit] -Loop the verification of all dsc engine reads to future proof
> > it [Ankit] -Keep the fix me comment in this patch and remove it in
> > later one where we add other readouts [Ankit] -Add switch statement
> > that fills in the required registers based on no of vdsc engines per
> > pipe.
> >
> > --v7
> > -Pass no of vdsc instances from read_reg function [Ankit] -Fix issue
> > where arrays do not get freed on return for read_and_verify func
> > [Ankit]
> >
> > Signed-off-by: Suraj Kandpal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 129 +-
> >  .../gpu/drm/i915/display/intel_vdsc_regs.h|  12 ++
> >  2 files changed, 105 insertions(+), 36 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index dc86514d9e17..aa93228ca7af 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -365,6 +365,28 @@ int intel_dsc_get_num_vdsc_instances(const
> struct intel_crtc_state *crtc_state)
> > return num_vdsc_instances;
> >  }
> >
> > +static void intel_dsc_get_pps_reg(const struct intel_crtc_state
> *crtc_state, int pps,
> > + i915_reg_t *dsc_reg, int no_vdsc_per_pipe)
> {
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > +   enum pipe pipe = crtc->pipe;
> > +   bool pipe_dsc;
> 
> Matter of taste, but to me that's four local variables too many for small 
> things
> like this.
> 
> > +
> > +   pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
> > +
> > +   switch (no_vdsc_per_pipe) {
> > +   case 2:
> > +   dsc_reg[1] = pipe_dsc ? ICL_DSC1_PPS_REG(pipe, pps) :
> DSCC_PPS_REG(pps);
> > +   fallthrough;
> > +   case 1:
> > +   dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS_REG(pipe, pps) :
> DSCA_PPS_REG(pps);
> > +   break;
> > +   default:
> > +   MISSING_CASE(no_vdsc_per_pipe);
> > +   }
> > +}
> > +
> >  static void intel_dsc_pps_configure(const struct intel_crtc_state
> > *crtc_state)  {
> > struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > @@ -994,17 +1016,83 @@ void intel_dsc_disable(const struct
> intel_crtc_state *old_crtc_state)
> > }
> >  }
> >
> > +static int intel_dsc_read_pps_reg(struct intel_crtc_state *crtc_state,
> > + int pps, u32 *pps_val)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +   const int no_vdsc_per_pipe =
> intel_dsc_get_vdsc_per_pipe(crtc_state);
> > +   i915_reg_t *dsc_reg;
> > +   u32 *pps_temp;
> > +   int i, ret = 0;
> > +
> > +   dsc_reg = kcalloc(no_vdsc_per_pipe, sizeof(dsc_reg), GFP_KERNEL);
> > +   if (!dsc_reg)
> > +   return -ENOMEM;
> > +
> > +   pps_temp = kcalloc(no_vdsc_per_pipe, sizeof(pps_temp),
> GFP_KERNEL);
> > +   if (!pps_temp) {
> > +   kfree(dsc_reg);
> > +   return -ENOMEM;
> > +   }
> 
> no_vdsc_per_pipe is at most 2. Temporary dynamic allocation is way overkill
> here.

Yes but Ankit was of the thought that we can future proof this going forward if 
by any chance we get more dsc engines

> 
> > +
> > +   *pps_val = 0;
> > +   intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, no_vdsc_per_pipe);
> > +   *pps_val = intel_de_read(i915, dsc_reg[0]);
> > +   if (no_vdsc_per_pipe > 1) {
> > +   for (i = 0; i < no_vdsc_per_pipe - 1; i++) {
> > +   pps_temp[i] = intel_de_read(i915, dsc_reg[i]);
> > +   pps_temp[i + 1] = intel_de_read(i915, dsc_reg[i + 1]);
> > +   if (pps_temp[i] != pps_temp[i + 1]) {
> > +   ret = 1;
> > +   break;
> > +   }
> > +   }
> > +   }
> 
> What is going on here? Feels like this has grown way more complicated than
> it needs to be since I last looked at this series. :(

In case of more 

Re: [Intel-gfx] [PATCH v7 4/8] drm/i915/vdsc: Add function to read any PPS register

2023-08-16 Thread Kandpal, Suraj
++ Ankit
> >
> > On Tue, 08 Aug 2023, Suraj Kandpal  wrote:
> > > Add function to read any PPS register based on the intel_dsc_pps
> > > enum provided. Add a function which will call the new pps read
> > > function and place it in crtc state. Only PPS0 and
> > > PPS1 are readout the rest of the registers will be read in upcoming
> > > patches.
> > >
> > > --v2
> > > -Changes in read function as PPS enum is removed -Initialize pps_val
> > > as 0 in pps_read func itself [Jani] -Create a function that gets the
> > > required register and call that in the common read function [Jani]
> > > -Move the drm_WARN_ON one abstraction layer above [Jani]
> > >
> > > --v3
> > > -Send both reg values regardless of dsc engine no [Jani] -Don't use
> > > num_vdsc_instances stick to dsc_split field [Ankit]
> > >
> > > --v4
> > > -Manipulate the reg values instead of creating MACRO to change name
> > > of pps [Ankit]
> > >
> > > --v5
> > > -Read dsc reg values using array rather than individual variables
> > > [Ankit] -Loop the verification of all dsc engine reads to future
> > > proof it [Ankit] -Keep the fix me comment in this patch and remove
> > > it in later one where we add other readouts [Ankit] -Add switch
> > > statement that fills in the required registers based on no of vdsc
> > > engines per pipe.
> > >
> > > --v7
> > > -Pass no of vdsc instances from read_reg function [Ankit] -Fix issue
> > > where arrays do not get freed on return for read_and_verify func
> > > [Ankit]
> > >
> > > Signed-off-by: Suraj Kandpal 
> > > ---
> > >  drivers/gpu/drm/i915/display/intel_vdsc.c | 129 +-
> > >  .../gpu/drm/i915/display/intel_vdsc_regs.h|  12 ++
> > >  2 files changed, 105 insertions(+), 36 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > index dc86514d9e17..aa93228ca7af 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > > @@ -365,6 +365,28 @@ int intel_dsc_get_num_vdsc_instances(const
> > struct intel_crtc_state *crtc_state)
> > >   return num_vdsc_instances;
> > >  }
> > >
> > > +static void intel_dsc_get_pps_reg(const struct intel_crtc_state
> > *crtc_state, int pps,
> > > +   i915_reg_t *dsc_reg, int no_vdsc_per_pipe)
> > {
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > > + enum pipe pipe = crtc->pipe;
> > > + bool pipe_dsc;
> >
> > Matter of taste, but to me that's four local variables too many for
> > small things like this.
> >
> > > +
> > > + pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
> > > +
> > > + switch (no_vdsc_per_pipe) {
> > > + case 2:
> > > + dsc_reg[1] = pipe_dsc ? ICL_DSC1_PPS_REG(pipe, pps) :
> > DSCC_PPS_REG(pps);
> > > + fallthrough;
> > > + case 1:
> > > + dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS_REG(pipe, pps) :
> > DSCA_PPS_REG(pps);
> > > + break;
> > > + default:
> > > + MISSING_CASE(no_vdsc_per_pipe);
> > > + }
> > > +}
> > > +
> > >  static void intel_dsc_pps_configure(const struct intel_crtc_state
> > > *crtc_state)  {
> > >   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > @@ -994,17 +1016,83 @@ void intel_dsc_disable(const struct
> > intel_crtc_state *old_crtc_state)
> > >   }
> > >  }
> > >
> > > +static int intel_dsc_read_pps_reg(struct intel_crtc_state *crtc_state,
> > > +   int pps, u32 *pps_val)
> > > +{
> > > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > > + const int no_vdsc_per_pipe =
> > intel_dsc_get_vdsc_per_pipe(crtc_state);
> > > + i915_reg_t *dsc_reg;
> > > + u32 *pps_temp;
> > > + int i, ret = 0;
> > > +
> > > + dsc_reg = kcalloc(no_vdsc_per_pipe, sizeof(dsc_reg), GFP_KERNEL);
> > > + if (!dsc_reg)
> > > + return -ENOMEM;
> > > +
> > > + pps_temp = kcalloc(no_vdsc_per_pipe, sizeof(pps_temp),
> > GFP_KERNEL);
> > > + if (!pps_temp) {
> > > + kfree(dsc_reg);
> > > + return -ENOMEM;
> > > + }
> >
> > no_vdsc_per_pipe is at most 2. Temporary dynamic allocation is way
> > overkill here.
> 
> Yes but Ankit was of the thought that we can future proof this going forward
> if by any chance we get more dsc engines
> 
> >
> > > +
> > > + *pps_val = 0;
> > > + intel_dsc_get_pps_reg(crtc_state, pps, dsc_reg, no_vdsc_per_pipe);
> > > + *pps_val = intel_de_read(i915, dsc_reg[0]);
> > > + if (no_vdsc_per_pipe > 1) {
> > > + for (i = 0; i < no_vdsc_per_pipe - 1; i++) {
> > > + pps_temp[i] = intel_de_read(i915, dsc_reg[i]);
> > > + pps_temp[i + 1] = intel_de_read(i915, dsc_reg[i + 1]);
> > > + if (pps_temp[i] != pps_temp[i + 1]) {
> > > + ret = 1;
> > > + break;
> > > + }
> > > + 

Re: [Intel-gfx] [PATCH v3 1/4] drm/i915/tc: rename mtl_tc_port_get_pin_assignment_mask()

2023-08-16 Thread Kandpal, Suraj
> This function doesn't really return the pin assignment mask, but the max lane
> count derived from that.  So rename the function to
> mtl_tc_port_get_max_lane_count() to better reflect what it really does.
>
Maybe also add the version changes on commit messages here as cover letter ends 
up getting discarded

With that fixed

Reviewed-by: Suraj Kandpal 
 
> Signed-off-by: Luca Coelho 
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 3ebf41859043..71bbc2b16a0e 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -290,7 +290,7 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
> intel_digital_port *dig_port)
>  DP_PIN_ASSIGNMENT_SHIFT(tc->phy_fia_idx);
>  }
> 
> -static int mtl_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port)
> +static int mtl_tc_port_get_max_lane_count(struct intel_digital_port
> +*dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>   intel_wakeref_t wakeref;
> @@ -325,7 +325,7 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
>   assert_tc_cold_blocked(tc);
> 
>   if (DISPLAY_VER(i915) >= 14)
> - return mtl_tc_port_get_pin_assignment_mask(dig_port);
> + return mtl_tc_port_get_max_lane_count(dig_port);
> 
>   lane_mask = 0;
>   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> wakeref)
> --
> 2.39.2



Re: [Intel-gfx] [PATCH v7 4/8] drm/i915/vdsc: Add function to read any PPS register

2023-08-16 Thread Kandpal, Suraj
> 
> On Wed, 16 Aug 2023, "Kandpal, Suraj"  wrote:
> >>
> >> On Tue, 08 Aug 2023, Suraj Kandpal  wrote:
> >> > Add function to read any PPS register based on the intel_dsc_pps
> >> > enum provided. Add a function which will call the new pps read
> >> > function and place it in crtc state. Only PPS0 and
> >> > PPS1 are readout the rest of the registers will be read in upcoming
> >> > patches.
> >> >
> >> > --v2
> >> > -Changes in read function as PPS enum is removed -Initialize
> >> > pps_val as 0 in pps_read func itself [Jani] -Create a function that
> >> > gets the required register and call that in the common read
> >> > function [Jani] -Move the drm_WARN_ON one abstraction layer above
> >> > [Jani]
> >> >
> >> > --v3
> >> > -Send both reg values regardless of dsc engine no [Jani] -Don't use
> >> > num_vdsc_instances stick to dsc_split field [Ankit]
> >> >
> >> > --v4
> >> > -Manipulate the reg values instead of creating MACRO to change name
> >> > of pps [Ankit]
> >> >
> >> > --v5
> >> > -Read dsc reg values using array rather than individual variables
> >> > [Ankit] -Loop the verification of all dsc engine reads to future
> >> > proof it [Ankit] -Keep the fix me comment in this patch and remove
> >> > it in later one where we add other readouts [Ankit] -Add switch
> >> > statement that fills in the required registers based on no of vdsc
> >> > engines per pipe.
> >> >
> >> > --v7
> >> > -Pass no of vdsc instances from read_reg function [Ankit] -Fix
> >> > issue where arrays do not get freed on return for read_and_verify
> >> > func [Ankit]
> >> >
> >> > Signed-off-by: Suraj Kandpal 
> >> > ---
> >> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 129 +-
> >> >  .../gpu/drm/i915/display/intel_vdsc_regs.h|  12 ++
> >> >  2 files changed, 105 insertions(+), 36 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > index dc86514d9e17..aa93228ca7af 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> > @@ -365,6 +365,28 @@ int intel_dsc_get_num_vdsc_instances(const
> >> struct intel_crtc_state *crtc_state)
> >> >  return num_vdsc_instances;
> >> >  }
> >> >
> >> > +static void intel_dsc_get_pps_reg(const struct intel_crtc_state
> >> *crtc_state, int pps,
> >> > +  i915_reg_t *dsc_reg, int 
> >> > no_vdsc_per_pipe)
> >> {
> >> > +struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >> > +enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> >> > +enum pipe pipe = crtc->pipe;
> >> > +bool pipe_dsc;
> >>
> >> Matter of taste, but to me that's four local variables too many for
> >> small things like this.
> >>
> >> > +
> >> > +pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
> >> > +
> >> > +switch (no_vdsc_per_pipe) {
> >> > +case 2:
> >> > +dsc_reg[1] = pipe_dsc ? ICL_DSC1_PPS_REG(pipe, pps) :
> >> DSCC_PPS_REG(pps);
> >> > +fallthrough;
> >> > +case 1:
> >> > +dsc_reg[0] = pipe_dsc ? ICL_DSC0_PPS_REG(pipe, pps) :
> >> DSCA_PPS_REG(pps);
> >> > +break;
> >> > +default:
> >> > +MISSING_CASE(no_vdsc_per_pipe);
> >> > +}
> >> > +}
> >> > +
> >> >  static void intel_dsc_pps_configure(const struct intel_crtc_state
> >> > *crtc_state)  {
> >> >  struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> >> > @@ -994,17 +1016,83 @@ void intel_dsc_disable(const struct
> >> intel_crtc_state *old_crtc_state)
> >> >  }
> >> >  }
> >> >
> >> > +static int intel_dsc_read_pps_reg(struct intel_crtc_state *crtc_state,
> >> > +  int pps, u32 *pps_val)
> >> > +{
> >> > +struct i

Re: [Intel-gfx] [PATCH 28/42] drm/i915/xe2lpd: enable odd size and panning for planar yuv on xe2lpd

2023-08-23 Thread Kandpal, Suraj
> Subject: [PATCH 28/42] drm/i915/xe2lpd: enable odd size and panning for
> planar yuv on xe2lpd
> 
> From: Juha-Pekka Heikkilä 
> 
> Enable odd size and panning for planar yuv formats.
> 
> Cc: Suraj Kandpal 
> Signed-off-by: Juha-Pekka Heikkilä 
> Signed-off-by: Lucas De Marchi 
Maybe add the Bspec/ HSD reference in here otherwise
LGTM

Reviewed-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_atomic_plane.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index fb13f0bb8c52..da6ee7f0675a 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -986,6 +986,14 @@ int intel_plane_check_src_coordinates(struct
> intel_plane_state *plane_state)
>   if (fb->format->format == DRM_FORMAT_RGB565 && rotated) {
>   hsub = 2;
>   vsub = 2;
> + } else if (DISPLAY_VER(i915) >= 20 &&
> + intel_format_info_is_yuv_semiplanar(fb->format, fb-
> >modifier)) {
> + /*
> +  * This allow NV12 and P0xx formats to have odd size and/or
> odd
> +  * source coordinates on DISPLAY_VER(i915) >= 20
> +  */
> + hsub = 1;
> + vsub = 1;
>   } else {
>   hsub = fb->format->hsub;
>   vsub = fb->format->vsub;
> --
> 2.40.1



Re: [Intel-gfx] [PATCH 09/42] drm/i915/tc: move legacy code out of the main _max_lane_count() func

2023-08-23 Thread Kandpal, Suraj



> -Original Message-
> From: Intel-gfx  On Behalf Of Lucas
> De Marchi
> Sent: Wednesday, August 23, 2023 10:37 PM
> To: intel...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Cc: Coelho, Luciano 
> Subject: [Intel-gfx] [PATCH 09/42] drm/i915/tc: move legacy code out of the
> main _max_lane_count() func
> 
> From: Luca Coelho 
> 
> This makes the code a bit more symmetric and readable, especially when we
> start adding more display version-specific alternatives.
> 
> Signed-off-by: Luca Coelho 
> Link: https://lore.kernel.org/r/2023072121.369227-4-
> luciano.coe...@intel.com
> ---
>  drivers/gpu/drm/i915/display/intel_tc.c | 32 +++--
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index de848b329f4b..43b8eeba26f8 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -311,23 +311,12 @@ static int mtl_tc_port_get_max_lane_count(struct
> intel_digital_port *dig_port)
>   }
>  }
> 
> -int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> +static int intel_tc_port_get_max_lane_count(struct intel_digital_port
> +*dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> - struct intel_tc_port *tc = to_tc_port(dig_port);
> - enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
>   intel_wakeref_t wakeref;
> - u32 lane_mask;
> -
> - if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> - return 4;
> + u32 lane_mask = 0;
> 
> - assert_tc_cold_blocked(tc);
> -
> - if (DISPLAY_VER(i915) >= 14)
> - return mtl_tc_port_get_max_lane_count(dig_port);
> -
> - lane_mask = 0;
>   with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> wakeref)
>   lane_mask = intel_tc_port_get_lane_mask(dig_port);
> 
> @@ -348,6 +337,23 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
>   }
>  }

Rather than having two functions:
mtl_tc_port_get_max_lane_count()
& intel_tc_port_get_max_lane_count() that both call:
with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
lane_mask = intel_tc_port_get_lane_mask(dig_port);
to get the lane mask the us directly pass the lane_mask to the above two 
functions
and make the call for getting the lane_mask common i.e lets call it in 
intel_tc_port_fia_max_lane_count().

Regards,
Suraj Kandpal
> 
> +int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> +*dig_port) {
> + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> + struct intel_tc_port *tc = to_tc_port(dig_port);
> + enum phy phy = intel_port_to_phy(i915, dig_port->base.port);
> +
> + if (!intel_phy_is_tc(i915, phy) || tc->mode != TC_PORT_DP_ALT)
> + return 4;
> +
> + assert_tc_cold_blocked(tc);
> +
> + if (DISPLAY_VER(i915) >= 14)
> + return mtl_tc_port_get_max_lane_count(dig_port);
> +
> + return intel_tc_port_get_max_lane_count(dig_port);
> +}
> +
>  void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> int required_lanes)
>  {
> --
> 2.40.1



Re: [Intel-gfx] [PATCH v3 4/4] drm/i915/tc: remove "fia" from intel_tc_port_fia_max_lane_count()

2023-08-23 Thread Kandpal, Suraj
> It is irrelevant for the caller that the max lane count is being derived from 
> a FIA
> register, so having "fia" in the function name is irrelevant.  Rename the
> function accordingly.
> 
> Signed-off-by: Luca Coelho 

LGTM.

Reviewed-by: Suraj Kandpal 
> ---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c | 2 +-
>  drivers/gpu/drm/i915/display/intel_dp.c  | 4 ++--
>  drivers/gpu/drm/i915/display/intel_tc.c  | 4 ++--
>  drivers/gpu/drm/i915/display/intel_tc.h  | 2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 1b00ef2c6185..6d4f7b20ce85 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -2534,7 +2534,7 @@ static void intel_cx0_phy_lane_reset(struct
> drm_i915_private *i915,  {
>   enum port port = encoder->port;
>   enum phy phy = intel_port_to_phy(i915, port);
> - bool both_lanes =
> intel_tc_port_fia_max_lane_count(enc_to_dig_port(encoder)) > 2;
> + bool both_lanes =
> +intel_tc_port_max_lane_count(enc_to_dig_port(encoder)) > 2;
>   u8 lane_mask = lane_reversal ? INTEL_CX0_LANE1 :
> INTEL_CX0_LANE0;
>   u32 lane_pipe_reset = both_lanes ?
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 03675620e3ea..b974af839acb 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -306,13 +306,13 @@ static int
> intel_dp_max_common_lane_count(struct intel_dp *intel_dp)
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   int source_max = intel_dp_max_source_lane_count(dig_port);
>   int sink_max = intel_dp->max_sink_lane_count;
> - int fia_max = intel_tc_port_fia_max_lane_count(dig_port);
> + int port_max = intel_tc_port_max_lane_count(dig_port);
>   int lttpr_max = drm_dp_lttpr_max_lane_count(intel_dp-
> >lttpr_common_caps);
> 
>   if (lttpr_max)
>   sink_max = min(sink_max, lttpr_max);
> 
> - return min3(source_max, sink_max, fia_max);
> + return min3(source_max, sink_max, port_max);
>  }
> 
>  int intel_dp_max_lane_count(struct intel_dp *intel_dp) diff --git
> a/drivers/gpu/drm/i915/display/intel_tc.c
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 43b8eeba26f8..3c94bbcb5497 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -337,7 +337,7 @@ static int intel_tc_port_get_max_lane_count(struct
> intel_digital_port *dig_port)
>   }
>  }
> 
> -int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> +int intel_tc_port_max_lane_count(struct intel_digital_port *dig_port)
>  {
>   struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
>   struct intel_tc_port *tc = to_tc_port(dig_port); @@ -589,7 +589,7
> @@ static bool tc_phy_verify_legacy_or_dp_alt_mode(struct intel_tc_port
> *tc,
>   struct intel_digital_port *dig_port = tc->dig_port;
>   int max_lanes;
> 
> - max_lanes = intel_tc_port_fia_max_lane_count(dig_port);
> + max_lanes = intel_tc_port_max_lane_count(dig_port);
>   if (tc->mode == TC_PORT_LEGACY) {
>   drm_WARN_ON(>drm, max_lanes != 4);
>   return true;
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.h
> b/drivers/gpu/drm/i915/display/intel_tc.h
> index ffc0e2a74e43..80a61e52850e 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.h
> +++ b/drivers/gpu/drm/i915/display/intel_tc.h
> @@ -20,7 +20,7 @@ bool intel_tc_port_connected(struct intel_encoder
> *encoder);  bool intel_tc_port_connected_locked(struct intel_encoder
> *encoder);
> 
>  u32 intel_tc_port_get_pin_assignment_mask(struct intel_digital_port
> *dig_port); -int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> *dig_port);
> +int intel_tc_port_max_lane_count(struct intel_digital_port *dig_port);
>  void intel_tc_port_set_fia_lane_count(struct intel_digital_port *dig_port,
> int required_lanes);
> 
> --
> 2.39.2



  1   2   3   >