RE: [PATCH v7 6/6] drm/i915/panelreplay: Debugfs support for panel replay

2023-10-15 Thread Murthy, Arun R


> -Original Message-
> From: Manna, Animesh 
> Sent: Wednesday, October 11, 2023 4:40 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; Hogander, Jouni ;
> Murthy, Arun R ; Nikula, Jani
> 
> Subject: [PATCH v7 6/6] drm/i915/panelreplay: Debugfs support for panel
> replay
> 
> Add debugfs support which will print source and sink status per connector
> basis.
> 
> v1: Initial version. [rb-ed by Arun]
> v2: Added check for DP 2.0 and connector type in connector_debugfs_add().
> 
> Cc: Jouni Högander 
> Cc: Arun R Murthy 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---

Reviewed-:by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy
---
>  drivers/gpu/drm/i915/display/intel_psr.c | 136 +--
>  1 file changed, 102 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 80de831c2f60..399fc0a8e636 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2823,6 +2823,25 @@ static int psr_get_status_and_error_status(struct
> intel_dp *intel_dp,
>   return 0;
>  }
> 
> +static int panel_replay_get_status_and_error_status(struct intel_dp 
> *intel_dp,
> + u8 *status, u8
> *error_status) {
> + struct drm_dp_aux *aux = _dp->aux;
> + int ret;
> +
> + ret = drm_dp_dpcd_readb(aux,
> DP_SINK_DEVICE_PR_AND_FRAME_LOCK_STATUS, status);
> + if (ret != 1)
> + return ret;
> +
> + ret = drm_dp_dpcd_readb(aux, DP_PANEL_REPLAY_ERROR_STATUS,
> error_status);
> + if (ret != 1)
> + return ret;
> +
> + *status = *status & DP_PSR_SINK_STATE_MASK;
> +
> + return 0;
> +}
> +
>  static void psr_alpm_check(struct intel_dp *intel_dp)  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); @@ -
> 3035,7 +3054,7 @@ psr_source_status(struct intel_dp *intel_dp, struct seq_file
> *m)
>   status = live_status[status_val];
>   }
> 
> - seq_printf(m, "Source PSR status: %s [0x%08x]\n", status, val);
> + seq_printf(m, "Source PSR/PanelReplay status: %s [0x%08x]\n", status,
> +val);
>  }
> 
>  static int intel_psr_status(struct seq_file *m, struct intel_dp *intel_dp) 
> @@ -
> 3048,18 +3067,23 @@ static int intel_psr_status(struct seq_file *m, struct
> intel_dp *intel_dp)
>   bool enabled;
>   u32 val;
> 
> - seq_printf(m, "Sink support: %s", str_yes_no(psr->sink_support));
> - if (psr->sink_support)
> + seq_printf(m, "Sink support: PSR = %s, Panel Replay = %s",
> +str_yes_no(psr->sink_support),
> +str_yes_no(psr->sink_panel_replay_support));
> +
> + if (psr->sink_support || psr->sink_panel_replay_support)
>   seq_printf(m, " [0x%02x]", intel_dp->psr_dpcd[0]);
>   seq_puts(m, "\n");
> 
> - if (!psr->sink_support)
> + if (!(psr->sink_support || psr->sink_panel_replay_support))
>   return 0;
> 
>   wakeref = intel_runtime_pm_get(_priv->runtime_pm);
>   mutex_lock(>lock);
> 
> - if (psr->enabled)
> + if (psr->panel_replay_enabled)
> + status = "Panel Replay Enabled";
> + else if (psr->enabled)
>   status = psr->psr2_enabled ? "PSR2 enabled" : "PSR1 enabled";
>   else
>   status = "disabled";
> @@ -3072,14 +3096,17 @@ static int intel_psr_status(struct seq_file *m,
> struct intel_dp *intel_dp)
>   goto unlock;
>   }
> 
> - if (psr->psr2_enabled) {
> + if (psr->panel_replay_enabled) {
> + val = intel_de_read(dev_priv,
> TRANS_DP2_CTL(cpu_transcoder));
> + enabled = val & TRANS_DP2_PANEL_REPLAY_ENABLE;
> + } else if (psr->psr2_enabled) {
>   val = intel_de_read(dev_priv, EDP_PSR2_CTL(cpu_transcoder));
>   enabled = val & EDP_PSR2_ENABLE;
>   } else {
>   val = intel_de_read(dev_priv, psr_ctl_reg(dev_priv,
> cpu_transcoder));
>   enabled = val & EDP_PSR_ENABLE;
>   }
> - seq_printf(m, "Source PSR ctl: %s [0x%08x]\n",
> + seq_printf(m, "Source PSR/PanelReplay ctl: %s [0x%08x]\n",
>  str_enabled_disabled(enabled), val);
>   psr_source_status(intel_dp, m);
>   seq_printf(m, "Busy frontbuffer bits: 0x%08x\n", @@ -3221,6 +3248,7
> @@ static int i915_psr_sink_status_show(struct seq_file *m, void *data)  {
>   struct intel_connector *connector = m->private;
>   struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct intel_psr *psr = _dp->psr;
>   static const char * const sink_status[] = {
>   "inactive",
>   "transition to active, capture and display", @@ -3231,45
> +3259,82 @@ static int i915_psr_sink_status_show(struct seq_file *m, void
> *data)
>   "reserved",
>   "sink internal error",
>   };
> + 

RE: [PATCH v7 5/6] drm/i915/panelreplay: enable/disable panel replay

2023-10-15 Thread Murthy, Arun R


> -Original Message-
> From: Manna, Animesh 
> Sent: Wednesday, October 11, 2023 4:40 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; Hogander, Jouni ;
> Murthy, Arun R ; Nikula, Jani
> 
> Subject: [PATCH v7 5/6] drm/i915/panelreplay: enable/disable panel replay
> 
> TRANS_DP2_CTL register is programmed to enable panel replay from source
> and sink is enabled through panel replay dpcd configuration address.
> 
> Bspec: 1407940617
> 
> v1: Initial version.
> v2:
> - Use pr_* flags instead psr_* flags. [Jouni]
> - Remove intel_dp_is_edp check as edp1.5 also has panel replay. [Jouni]
> 
> v3: Cover letter updated and selective fetch condition check is added before
> updating its bit in PSR2_MAN_TRK_CTL register. [Jouni]
> 
> v4: Selective fetch related PSR2_MAN_TRK_CTL programmming dropped.
> [Jouni]
> 
> v5: Added PSR2_MAN_TRK_CTL programming as needed for Continuous Full
> Frame (CFF) update.
> 
> v6: Rebased on latest.
> 
> Note: Initial plan is to enable panel replay in  full-screen live active frame
> update mode. In a incremental approach panel replay will be enabled in 
> selctive
> update mode if there is any gap in curent implementation.
> 
> Cc: Jouni Högander 
> Cc: Arun R Murthy 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/display/intel_ddi.c  |  7 ++-
>  .../drm/i915/display/intel_display_types.h|  1 +
>  drivers/gpu/drm/i915/display/intel_psr.c  | 63 ++-
>  3 files changed, 55 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9151d5add960..16f98a7a5f20 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2717,10 +2717,15 @@ static void intel_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>   const struct drm_connector_state
> *conn_state)  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> 
> - if (HAS_DP20(dev_priv))
> + if (HAS_DP20(dev_priv)) {
>   intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
>   crtc_state);
> + if (crtc_state->has_panel_replay)
> + drm_dp_dpcd_writeb(_dp->aux,
> PANEL_REPLAY_CONFIG,
> +DP_PANEL_REPLAY_ENABLE);
> + }
> 
>   if (DISPLAY_VER(dev_priv) >= 14)
>   mtl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 95b318f7b2b8..d8f35054bc11 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1704,6 +1704,7 @@ struct intel_psr {
>   u16 su_y_granularity;
>   bool source_panel_replay_support;
>   bool sink_panel_replay_support;
> + bool panel_replay_enabled;
>   u32 dc3co_exitline;
>   u32 dc3co_exit_delay;
>   struct delayed_work dc3co_work;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index a2e0637c53fb..80de831c2f60 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -608,8 +608,11 @@ static void intel_psr_enable_sink(struct intel_dp
> *intel_dp)
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>   u8 dpcd_val = DP_PSR_ENABLE;
> 
> - /* Enable ALPM at sink for psr2 */
> + if (intel_dp->psr.panel_replay_enabled)
> + return;
> +
>   if (intel_dp->psr.psr2_enabled) {
> + /* Enable ALPM at sink for psr2 */
Unrelated change

Upon removing this
Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy
---
>   drm_dp_dpcd_writeb(_dp->aux,
> DP_RECEIVER_ALPM_CONFIG,
>  DP_ALPM_ENABLE |
>  DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
> @@ -759,6 +762,17 @@ static int psr2_block_count(struct intel_dp *intel_dp)
>   return psr2_block_count_lines(intel_dp) / 4;  }
> 
> +static void dg2_activate_panel_replay(struct intel_dp *intel_dp) {
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + intel_de_rmw(dev_priv, PSR2_MAN_TRK_CTL(intel_dp->psr.transcoder),
> +  0,
> ADLP_PSR2_MAN_TRK_CTL_SF_CONTINUOS_FULL_FRAME);
> +
> + intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp->psr.transcoder), 0,
> +  TRANS_DP2_PANEL_REPLAY_ENABLE);
> +}
> +
>  static void hsw_activate_psr2(struct intel_dp *intel_dp)  {
>   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp); @@ -
> 1323,18 +1337,23 @@ void intel_psr_get_config(struct intel_encoder
> *encoder,
>   return;
> 
>  

RE: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dpcd initialization for DP

2023-10-15 Thread Murthy, Arun R

> -Original Message-
> From: Manna, Animesh 
> Sent: Wednesday, October 11, 2023 4:40 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; Hogander, Jouni ;
> Murthy, Arun R ; Nikula, Jani
> 
> Subject: [PATCH v7 4/6] drm/i915/panelreplay: Enable panel replay dpcd
> initialization for DP
> 
> Due to similarity panel replay dpcd initialization got added in psr function 
> which
> is specific for edp panel. This patch enables panel replay initialization for 
> dp
> connector.
> 
If panelreplay initialization then why is the function name psr_init_dpcd() ?
Also it its similar to PSR then these dpcd should already be available.

Thanks and Regards,
Arun R Murthy


> Cc: Jouni Högander 
> Cc: Arun R Murthy 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---
>  drivers/gpu/drm/i915/display/intel_psr.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index f9837001aa5f..a2e0637c53fb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -2738,6 +2738,9 @@ void intel_psr_init(struct intel_dp *intel_dp)
>   if (!(HAS_PSR(dev_priv) || HAS_DP20(dev_priv)))
>   return;
> 
> + if (!intel_dp_is_edp(intel_dp))
> + intel_psr_init_dpcd(intel_dp);
> +
>   /*
>* HSW spec explicitly says PSR is tied to port A.
>* BDW+ platforms have a instance of PSR registers per transcoder but
> --
> 2.29.0



Request for information on generating DisplayPort error packets for testing

2023-10-15 Thread chalil jitesh
Hi,

For testing we wanted to generate and send some error DisplayPort frames
packets (send some invalid DisplayPort video stream data packets) to the
DisplayPort sink device to check if the sink device is behaving correctly
to DisplayPort error stream data frames received.
Could you please suggest any drm/kms tools in linux which can be used for
creating DisplayPort error packets for testing.
Could you also please tell us we can modify the drm driver apis to corrupt
the DisplayPort stream data packets which are sent by drm driver to the
Displayport Sink Device.
Kindly please suggest how we can generate error Displayport stream data
packets for testing from DRM drivers.

With Thanks and Regards
Jitesh


Re: [PATCH v7 04/23] dt-bindings: display: mediatek: padding: Add MT8188

2023-10-15 Thread 宋孝謙


RE: [PATCH v7 3/6] drm/i915/panelreplay: Initializaton and compute config for panel replay

2023-10-15 Thread Murthy, Arun R


> -Original Message-
> From: Manna, Animesh 
> Sent: Wednesday, October 11, 2023 4:40 PM
> To: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org; Manna, Animesh
> ; Hogander, Jouni ;
> Murthy, Arun R ; Nikula, Jani
> 
> Subject: [PATCH v7 3/6] drm/i915/panelreplay: Initializaton and compute config
> for panel replay
> 
> Modify existing PSR implementation to enable panel replay feature of DP 2.0
> which is similar to PSR feature of EDP panel. There is different DPCD address 
> to
> check panel capability compare to PSR and vsc sdp header is different.
> 
> v1: Initial version.
> v2:
> - Set source_panel_replay_support flag under HAS_PANEL_REPLAY() condition
> check. [Jouni]
> - Code restructured around intel_panel_replay_init and renamed to
> intel_panel_replay_init_dpcd. [Jouni]
> - Remove the initial code modification around has_psr2 flag. [Jouni]
> - Add CAN_PANEL_REPLAY() in intel_encoder_can_psr which is used to enable in
> intel_psr_post_plane_update. [Jouni]
> v3:
> - Initialize both psr and panel-replay. [Jouni]
> - Initialize both panel replay and psr if detected. [Jouni]
> - Refactoring psr function by introducing _psr_compute_config(). [Jouni]
> - Add check for !is_edp while deriving source_panel_replay_support. [Jouni]
> - Enable panel replay dpcd initialization in a separate patch. [Jouni]
> 
> v4:
> - HAS_PANEL_REPLAY() check not needed during sink capability check. [Jouni]
> - Set either panel replay source support or psr. [Jouni]
> 
> v5:
> - HAS_PANEL_REPLAY() removed and use HAS_DP20() instead. [Jouni]
> - Move psr related code to intel_psr.c. [Jani]
> - Reset sink_panel_replay_support flag during disconnection. [Jani]
> 
> v6: return statement restored which is removed by misatke. [Jouni]
> v7: cosmetic changes. [Arun]
> 
> Cc: Jouni Högander 
> Cc: Arun R Murthy 
> Cc: Jani Nikula 
> Signed-off-by: Animesh Manna 
> ---

Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy
---

>  .../drm/i915/display/intel_display_types.h| 14 +--
>  drivers/gpu/drm/i915/display/intel_dp.c   | 49 --
>  drivers/gpu/drm/i915/display/intel_dp_mst.c   |  3 +
>  drivers/gpu/drm/i915/display/intel_psr.c  | 96 ++-
>  drivers/gpu/drm/i915/display/intel_psr.h  |  7 ++
>  5 files changed, 123 insertions(+), 46 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8d8b2f8d37a9..95b318f7b2b8 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1204,6 +1204,7 @@ struct intel_crtc_state {
>   bool has_psr2;
>   bool enable_psr2_sel_fetch;
>   bool req_psr2_sdp_prior_scanline;
> + bool has_panel_replay;
>   bool wm_level_disabled;
>   u32 dc3co_exitline;
>   u16 su_y_granularity;
> @@ -1701,6 +1702,8 @@ struct intel_psr {
>   bool irq_aux_error;
>   u16 su_w_granularity;
>   u16 su_y_granularity;
> + bool source_panel_replay_support;
> + bool sink_panel_replay_support;
>   u32 dc3co_exitline;
>   u32 dc3co_exit_delay;
>   struct delayed_work dc3co_work;
> @@ -1988,17 +1991,6 @@ dp_to_lspcon(struct intel_dp *intel_dp)
> 
>  #define dp_to_i915(__intel_dp) to_i915(dp_to_dig_port(__intel_dp)-
> >base.base.dev)
> 
> -#define CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
> -(intel_dp)->psr.source_support)
> -
> -static inline bool intel_encoder_can_psr(struct intel_encoder *encoder) -{
> - if (!intel_encoder_is_dp(encoder))
> - return false;
> -
> - return CAN_PSR(enc_to_intel_dp(encoder));
> -}
> -
>  static inline struct intel_digital_port *  hdmi_to_dig_port(struct intel_hdmi
> *intel_hdmi)  { diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0ef7cb8134b6..b038f1d2a7ad 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -2432,12 +2432,22 @@ static void
> intel_dp_compute_vsc_colorimetry(const struct intel_crtc_state *crtc
>   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
>   struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> 
> - /*
> -  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> -  * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> -  * Colorimetry Format indication.
> -  */
> - vsc->revision = 0x5;
> + if (crtc_state->has_panel_replay) {
> + /*
> +  * Prepare VSC Header for SU as per DP 2.0 spec, Table 2-223
> +  * VSC SDP supporting 3D stereo, Panel Replay, and Pixel
> +  * Encoding/Colorimetry Format indication.
> +  */
> + vsc->revision = 0x7;
> + } else {
> + /*
> +  * Prepare VSC Header for SU as per DP 1.4 spec, Table 2-118
> +  * 

RE: [EXT] Re: [PATCH v10 4/7] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver

2023-10-15 Thread Sandor Yu
Hi Alexander,

Thanks your comments,

> 
> 
> Hi Sandor,
> 
> thanks for the updated series.
> 
> Am Freitag, 13. Oktober 2023, 05:24:23 CEST schrieb Sandor Yu:
> > Add a new DRM DisplayPort and HDMI bridge driver for Candence
> MHDP8501
> > used in i.MX8MQ SOC. MHDP8501 could support HDMI or DisplayPort
> > standards according embedded Firmware running in the uCPU.
> >
> > For iMX8MQ SOC, the DisplayPort/HDMI FW was loaded and activated by
> > SOC's ROM code. Bootload binary included respective specific firmware
> > is required.
> >
> > Driver will check display connector type and then load the
> > corresponding driver.
> >
> > Signed-off-by: Sandor Yu 
> > Tested-by: Alexander Stein 
> > ---
> > v9->v10:
> >  - struct cdns_mhdp_device is renamed to cdns_mhdp8501_device.
> >  - update for mhdp helper driver is introduced.
> > Remove head file cdns-mhdp-mailbox.h and add cdns-mhdp-helper.h Add
> > struct cdns_mhdp_base base to struct cdns_mhdp8501_device.
> > Init struct cdns_mhdp_base base when driver probe.
> >
> >  drivers/gpu/drm/bridge/cadence/Kconfig|  16 +
> >  drivers/gpu/drm/bridge/cadence/Makefile   |   2 +
> >  .../drm/bridge/cadence/cdns-mhdp8501-core.c   | 316 
> >  .../drm/bridge/cadence/cdns-mhdp8501-core.h   | 365 +
> >  .../gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c | 708
> ++
> >  .../drm/bridge/cadence/cdns-mhdp8501-hdmi.c   | 673
> +
> >  6 files changed, 2080 insertions(+)
> >  create mode 100644
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.c
> >  create mode 100644
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-core.h
> >  create mode 100644
> drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-dp.c
> >  create mode 100644
> > drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> >
> > [...]
> > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c new file mode
> > 100644 index 0..73d1c35a74599
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8501-hdmi.c
> > @@ -0,0 +1,673 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Cadence MHDP8501 HDMI bridge driver
> > + *
> > + * Copyright (C) 2019-2023 NXP Semiconductor, Inc.
> > + *
> > + */
> > +#include  #include
> > + #include 
> > +#include  #include  #include
> > + #include 
> > +
> > +#include "cdns-mhdp8501-core.h"
> > +
> > +/**
> > + * cdns_hdmi_infoframe_set() - fill the HDMI AVI infoframe
> > + * @mhdp: phandle to mhdp device.
> > + * @entry_id: The packet memory address in which the data is written.
> > + * @packet_len: 32, only 32 bytes now.
> > + * @packet: point to InfoFrame Packet.
> > + *  packet[0] = 0
> > + *  packet[1-3] = HB[0-2]  InfoFrame Packet Header
> > + *  packet[4-31 = PB[0-27] InfoFrame Packet Contents
> > + * @packet_type: Packet Type of InfoFrame in HDMI Specification.
> > + *
> > + */
> > +static void cdns_hdmi_infoframe_set(struct cdns_mhdp8501_device
> *mhdp,
> > + u8 entry_id, u8 packet_len,
> > + u8 *packet, u8 packet_type) {
> > + u32 packet32, len32;
> > + u32 val, i;
> > +
> > + /* only support 32 bytes now */
> > + if (packet_len != 32)
> > + return;
> > +
> > + /* invalidate entry */
> > + val = F_ACTIVE_IDLE_TYPE(1) | F_PKT_ALLOC_ADDRESS(entry_id);
> > + writel(val, mhdp->regs + SOURCE_PIF_PKT_ALLOC_REG);
> > + writel(F_PKT_ALLOC_WR_EN(1), mhdp->regs +
> SOURCE_PIF_PKT_ALLOC_WR_EN);
> > +
> > + /* flush fifo 1 */
> > + writel(F_FIFO1_FLUSH(1), mhdp->regs +
> SOURCE_PIF_FIFO1_FLUSH);
> > +
> > + /* write packet into memory */
> > + len32 = packet_len / 4;
> > + for (i = 0; i < len32; i++) {
> > + packet32 = get_unaligned_le32(packet + 4 * i);
> > + writel(F_DATA_WR(packet32), mhdp->regs +
> SOURCE_PIF_DATA_WR);
> > + }
> > +
> > + /* write entry id */
> > + writel(F_WR_ADDR(entry_id), mhdp->regs +
> SOURCE_PIF_WR_ADDR);
> > +
> > + /* write request */
> > + writel(F_HOST_WR(1), mhdp->regs + SOURCE_PIF_WR_REQ);
> > +
> > + /* update entry */
> > + val = F_ACTIVE_IDLE_TYPE(1) | F_TYPE_VALID(1) |
> > + F_PACKET_TYPE(packet_type) |
> F_PKT_ALLOC_ADDRESS(entry_id);
> > + writel(val, mhdp->regs + SOURCE_PIF_PKT_ALLOC_REG);
> > +
> > + writel(F_PKT_ALLOC_WR_EN(1), mhdp->regs +
> SOURCE_PIF_PKT_ALLOC_WR_EN);
> > +}
> > +
> > +static int cdns_hdmi_get_edid_block(void *data, u8 *edid,
> > + u32 block, size_t length) {
> > + struct cdns_mhdp8501_device *mhdp = data;
> > + u8 msg[2], reg[5], i;
> > + int ret;
> > +
> > + mutex_lock(>mbox_mutex);
> > +
> > + for (i = 0; i < 4; i++) {
> > + msg[0] = block / 2;
> > + msg[1] = block % 2;
> > +
> > + ret = cdns_mhdp_mailbox_send(>base,
> MB_MODULE_ID_HDMI_TX,
> > HDMI_TX_EDID, +
> 

RE: [EXT] Re: [PATCH v10 1/7] drm: bridge: Cadence: Creat mhdp helper driver

2023-10-15 Thread Sandor Yu
Hi Alexander,

Thanks your comments,

> 
> Hi Sandor,
> 
> thanks for the updated series.
> 
> Am Freitag, 13. Oktober 2023, 05:24:20 CEST schrieb Sandor Yu:
> > MHDP8546 mailbox access functions will be share to other mhdp driver
> > and Cadence HDP-TX HDMI/DP PHY drivers.
> > Create a new mhdp helper driver and move all those functions into.
> >
> > cdns_mhdp_reg_write() is renamed to cdns_mhdp_dp_reg_write(), because
> > it use the DPTX command ID DPTX_WRITE_REGISTER.
> >
> > New cdns_mhdp_reg_write() is created with the general command ID
> > GENERAL_REGISTER_WRITE.
> >
> > Signed-off-by: Sandor Yu 
> > ---
> > v9->v10:
> >  *use mhdp helper driver to replace macro functions,  move maibox
> > access function and mhdp hdmi/dp common API  functions into the
> > driver.
> >
> >  drivers/gpu/drm/bridge/cadence/Kconfig|   4
> >  drivers/gpu/drm/bridge/cadence/Makefile   |   1 +
> >  .../gpu/drm/bridge/cadence/cdns-mhdp-helper.c | 306 ++
> >  .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 383 +++---
> >  .../drm/bridge/cadence/cdns-mhdp8546-core.h   |  44 +-
> >  include/drm/bridge/cdns-mhdp-helper.h |  96 +
> >  6 files changed, 473 insertions(+), 361 deletions(-)  create mode
> > 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
> >  create mode 100644 include/drm/bridge/cdns-mhdp-helper.h
> >
> > diff --git a/drivers/gpu/drm/bridge/cadence/Kconfig
> > b/drivers/gpu/drm/bridge/cadence/Kconfig index
> > ec35215a20034..0b7b4626a7af0
> > 100644
> > --- a/drivers/gpu/drm/bridge/cadence/Kconfig
> > +++ b/drivers/gpu/drm/bridge/cadence/Kconfig
> > @@ -20,6 +20,9 @@ config DRM_CDNS_DSI_J721E
> > the routing of the DSS DPI signal to the Cadence DSI.
> >  endif
> >
> > +config CDNS_MHDP_HELPER
> > + tristate
> > +
> >  config DRM_CDNS_MHDP8546
> >   tristate "Cadence DPI/DP bridge"
> >   select DRM_DISPLAY_DP_HELPER
> > @@ -27,6 +30,7 @@ config DRM_CDNS_MHDP8546
> >   select DRM_DISPLAY_HELPER
> >   select DRM_KMS_HELPER
> >   select DRM_PANEL_BRIDGE
> > + select CDNS_MHDP_HELPER
> >   depends on OF
> >   help
> > Support Cadence DPI to DP bridge. This is an internal diff
> > --git a/drivers/gpu/drm/bridge/cadence/Makefile
> > b/drivers/gpu/drm/bridge/cadence/Makefile index
> > c95fd5b81d137..087dc074820d7 100644
> > --- a/drivers/gpu/drm/bridge/cadence/Makefile
> > +++ b/drivers/gpu/drm/bridge/cadence/Makefile
> > @@ -2,6 +2,7 @@
> >  obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o  cdns-dsi-y :=
> > cdns-dsi-core.o
> >  cdns-dsi-$(CONFIG_DRM_CDNS_DSI_J721E) += cdns-dsi-j721e.o
> > +obj-$(CONFIG_CDNS_MHDP_HELPER) += cdns-mhdp-helper.o
> >  obj-$(CONFIG_DRM_CDNS_MHDP8546) += cdns-mhdp8546.o
> cdns-mhdp8546-y
> > := cdns-mhdp8546-core.o cdns-mhdp8546-hdcp.o
> >  cdns-mhdp8546-$(CONFIG_DRM_CDNS_MHDP8546_J721E) +=
> > cdns-mhdp8546-j721e.o diff --git
> > a/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
> > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c new file mode
> > 100644 index 0..2e3eee40494f0
> > --- /dev/null
> > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp-helper.c
> > @@ -0,0 +1,306 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2023 NXP Semiconductor, Inc.
> > + *
> > + */
> > +#include  #include
> > + #include 
> > +
> > +/* Mailbox helper functions */
> > +int cdns_mhdp_mailbox_read(struct cdns_mhdp_base *base) {
> > + int ret, empty;
> > +
> > + WARN_ON(!mutex_is_locked(base->mbox_mutex));
> > +
> > + ret = readx_poll_timeout(readl, base->regs +
> CDNS_MAILBOX_EMPTY,
> > +  empty, !empty, MAILBOX_RETRY_US,
> > +  MAILBOX_TIMEOUT_US);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return readl(base->regs + CDNS_MAILBOX_RX_DATA) & 0xff; }
> > +EXPORT_SYMBOL_GPL(cdns_mhdp_mailbox_read);
> 
> No need to export this. You can make this function actually static.

OK, I will change it to static in the next version.

> 
> > +
> > +int cdns_mhdp_mailbox_write(struct cdns_mhdp_base *base, u8 val) {
> > + int ret, full;
> > +
> > + WARN_ON(!mutex_is_locked(base->mbox_mutex));
> > +
> > + ret = readx_poll_timeout(readl, base->regs + CDNS_MAILBOX_FULL,
> > +  full, !full, MAILBOX_RETRY_US,
> > +  MAILBOX_TIMEOUT_US);
> > + if (ret < 0)
> > + return ret;
> > +
> > + writel(val, base->regs + CDNS_MAILBOX_TX_DATA);
> > +
> > + return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(cdns_mhdp_mailbox_write);
> 
> No need to export that one as well. You can make this function actually static
> as these two functions are only called from the helper itself.

mhdp8546 driver need this function. 

> 
> > +
> > +int cdns_mhdp_mailbox_recv_header(struct cdns_mhdp_base *base,
> > +   u8 module_id, u8 opcode,
> > +   u16 req_size) {
> > + u32 mbox_size, i;

[PATCH] drm: bridge: adv7511: get edid in hpd_work to update CEC phys address

2023-10-15 Thread Alvin Šipraga
From: Alvin Šipraga 

The adv7511 driver is solely responsible for setting the physical
address of its CEC adapter. To do this, it must read the EDID. However,
EDID is only read when either the drm_bridge_funcs :: get_edid or
drm_connector_helper_funcs :: get_modes ops are called. Without loss of
generality, it cannot be assumed that these ops are called when a sink
gets attached. Therefore there exist scenarios in which the CEC physical
address will be invalid (f.f.f.f), rendering the CEC adapter inoperable.

Address this problem by always fetching the EDID in the HPD work when we
detect a connection. The CEC physical address is set in the process.

Signed-off-by: Alvin Šipraga 
---
Pardon the insertion of the ugly adv7511_get_edid() prototype, but I did
not want to clobber git history by rearranging a bunch of functions. If
this is the preferred approach I will happily re-spin the patch.
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 2611afd2c1c1..3d32c109963c 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -424,6 +424,9 @@ static bool adv7511_hpd(struct adv7511 *adv7511)
return false;
 }
 
+static struct edid *adv7511_get_edid(struct adv7511 *adv7511,
+struct drm_connector *connector);
+
 static void adv7511_hpd_work(struct work_struct *work)
 {
struct adv7511 *adv7511 = container_of(work, struct adv7511, hpd_work);
@@ -457,6 +460,9 @@ static void adv7511_hpd_work(struct work_struct *work)
if (adv7511->connector.dev) {
if (status == connector_status_disconnected)
cec_phys_addr_invalidate(adv7511->cec_adap);
+   else
+   adv7511_get_edid(adv7511, >connector);
+
drm_kms_helper_hotplug_event(adv7511->connector.dev);
} else {
drm_bridge_hpd_notify(>bridge, status);

---
base-commit: 4366faf43308bd91c59a20c43a9f853a9c3bb6e4
change-id: 20231014-adv7511-cec-edid-ff75bd3ac929



[PATCH] drm/bridge: adv7511: fix crash on irq during probe

2023-10-15 Thread Alvin Šipraga
From: Mads Bligaard Nielsen 

Moved IRQ registration down to end of adv7511_probe().

If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:

Unable to handle kernel read from unreadable memory at virtual address 
03d5
Internal error: Oops: 9604 [#1] PREEMPT_RT SMP
Call trace:
 cec_received_msg_ts+0x48/0x990 [cec]
 adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
 adv7511_irq_process+0xd8/0x120 [adv7511]
 adv7511_irq_handler+0x1c/0x30 [adv7511]
 irq_thread_fn+0x30/0xa0
 irq_thread+0x14c/0x238
 kthread+0x190/0x1a8

Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Mads Bligaard Nielsen 
Signed-off-by: Alvin Šipraga 
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index d518de88b5c3..71022cb8abe4 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1291,17 +1291,6 @@ static int adv7511_probe(struct i2c_client *i2c)
 
INIT_WORK(>hpd_work, adv7511_hpd_work);
 
-   if (i2c->irq) {
-   init_waitqueue_head(>wq);
-
-   ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
-   adv7511_irq_handler,
-   IRQF_ONESHOT, dev_name(dev),
-   adv7511);
-   if (ret)
-   goto err_unregister_cec;
-   }
-
adv7511_power_off(adv7511);
 
i2c_set_clientdata(i2c, adv7511);
@@ -1325,6 +1314,17 @@ static int adv7511_probe(struct i2c_client *i2c)
 
adv7511_audio_init(dev, adv7511);
 
+   if (i2c->irq) {
+   init_waitqueue_head(>wq);
+
+   ret = devm_request_threaded_irq(dev, i2c->irq, NULL,
+   adv7511_irq_handler,
+   IRQF_ONESHOT, dev_name(dev),
+   adv7511);
+   if (ret)
+   goto err_unregister_audio;
+   }
+
if (adv7511->type == ADV7533 || adv7511->type == ADV7535) {
ret = adv7533_attach_dsi(adv7511);
if (ret)

---
base-commit: a48e2cc92835fa1d9b373b804b2173c779387b8e
change-id: 20231014-adv7511-cec-irq-crash-fix-6fdd9093dc7a



[PATCH] drm/tiny: print 'struct resource *' correctly

2023-10-15 Thread Yussef Dalton
Since format specifier %pr refers to a 'struct resource *', there is no
need to take the address of the 'res' variable since it is already of
type 'struct resource *'.

Signed-off-by: Yussef Dalton 
---
 drivers/gpu/drm/tiny/ofdrm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
index 2d999a0facde..6372ab383747 100644
--- a/drivers/gpu/drm/tiny/ofdrm.c
+++ b/drivers/gpu/drm/tiny/ofdrm.c
@@ -1208,13 +1208,13 @@ static struct ofdrm_device *ofdrm_device_create(struct 
drm_driver *drv,
 
ret = devm_aperture_acquire_from_firmware(dev, fb_pgbase, fb_pgsize);
if (ret) {
-   drm_err(dev, "could not acquire memory range %pr: error %d\n", 
, ret);
+   drm_err(dev, "could not acquire memory range %pr: error %d\n", 
res, ret);
return ERR_PTR(ret);
}
 
mem = devm_request_mem_region(>dev, fb_pgbase, fb_pgsize, 
drv->name);
if (!mem) {
-   drm_warn(dev, "could not acquire memory region %pr\n", );
+   drm_warn(dev, "could not acquire memory region %pr\n", res);
return ERR_PTR(-ENOMEM);
}
 
-- 
2.41.0



Patch "drm/tiny: correctly print `struct resource *` on error" has been added to the 6.5-stable tree

2023-10-15 Thread gregkh


This is a note to let you know that I've just added the patch titled

drm/tiny: correctly print `struct resource *` on error

to the 6.5-stable tree which can be found at:

http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
 drm-tiny-correctly-print-struct-resource-on-error.patch
and it can be found in the queue-6.5 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let  know about it.


>From c1165df2be2fffe3adeeaa68f4ee4325108c5e4e Mon Sep 17 00:00:00 2001
From: Joey Gouly 
Date: Tue, 10 Oct 2023 18:46:52 +0100
Subject: drm/tiny: correctly print `struct resource *` on error

From: Joey Gouly 

commit c1165df2be2fffe3adeeaa68f4ee4325108c5e4e upstream.

The `res` variable is already a `struct resource *`, don't take the address of 
it.

Fixes incorrect output:

simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not 
acquire memory range [??? 0x4be88a387d00-0xfefffde0a240 flags 0x0]: -16

To be correct:

simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not 
acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16

Signed-off-by: Joey Gouly 
Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory 
framebuffers")
Cc: Thomas Zimmermann 
Cc: Thierry Reding 
Cc: Javier Martinez Canillas 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v6.3+
Reviewed-by: Thomas Zimmermann 
Signed-off-by: Thomas Zimmermann 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20231010174652.2439513-1-joey.go...@arm.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index ff86ba1ae1b8..8ea120eb8674 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -745,7 +745,7 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
 
ret = devm_aperture_acquire_from_firmware(dev, res->start, 
resource_size(res));
if (ret) {
-   drm_err(dev, "could not acquire memory range %pr: 
%d\n", , ret);
+   drm_err(dev, "could not acquire memory range %pr: 
%d\n", res, ret);
return ERR_PTR(ret);
}
 
-- 
2.42.0



Patches currently in stable-queue which might be from joey.go...@arm.com are

queue-6.5/drm-tiny-correctly-print-struct-resource-on-error.patch


Re: [PATCH v6 5/6] drm: Refuse to async flip with atomic prop changes

2023-10-15 Thread Simon Ser
On Tuesday, August 15th, 2023 at 20:57, André Almeida  
wrote:

> Given that prop changes may lead to modesetting, which would defeat the
> fast path of the async flip, refuse any atomic prop change for async
> flips in atomic API. The only exceptions are the framebuffer ID to flip
> to and the mode ID, that could be referring to an identical mode.
> 
> Signed-off-by: André Almeida 
> ---
> v4: new patch
> ---
>  drivers/gpu/drm/drm_atomic_helper.c |  5 +++
>  drivers/gpu/drm/drm_atomic_uapi.c   | 52 +++--
>  drivers/gpu/drm/drm_crtc_internal.h |  2 +-
>  drivers/gpu/drm/drm_mode_object.c   |  2 +-
>  4 files changed, 56 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 2c2c9caf0be5..1e2973f0e1f6 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -629,6 +629,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   WARN_ON(!drm_modeset_is_locked(>mutex));
> 
>   if (!drm_mode_equal(_crtc_state->mode, 
> _crtc_state->mode)) {
> + if (new_crtc_state->async_flip) {
> + drm_dbg_atomic(dev, "[CRTC:%d:%s] no mode 
> changes allowed during async flip\n",
> +crtc->base.id, crtc->name);
> + return -EINVAL;
> + }

Hmm, so, I've been going back and forth about this for a loong time. Each
time I convince myself that one of the options we have is a good solution, I
think of the drawbacks and change my mind. To sum up:

- Forbid non-FB_ID props from being included in the atomic commit: makes it
  painful for compositors, they need to have a special tearing codepath for no
  real reason and the tearing API doesn't work the same as the non-tearing API
  as Pekka said.
- Check any non-FB_ID props in the atomic commit, forbid changes here: we need
  to use get_property(), which is a bit weird back-and-forth between u64s used
  in the uAPI and actual underlying values stored in DRM structs. And the
  MODE_ID check is a bit split between the set_property() function and the
  check_modeset() one. Ideally we'd have a something_changed bool like we have
  for modesets (mode_changed) but that would be a massive pain to plumb through
  all of the props. Also get_property() is lightweight, it just casts whatever
  struct field is being used to u64 and that's it.

All in all, I think I'd settle on the approach in this patch, but I'd prefer to
leave the MODE_ID stuff out. It would result in a less convoluted check, and I
can't think of any current compositor which re-creates the mode blob each
page-flip. That's not 100% consistent with the sync page-flip API, but I'm
worried about accumulating more special cases like this in the future.

Does that make sense?

>   drm_dbg_atomic(dev, "[CRTC:%d:%s] mode changed\n",
>  crtc->base.id, crtc->name);
>   new_crtc_state->mode_changed = true;
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index dfd4cf7169df..536c21f53b5f 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -972,13 +972,28 @@ int drm_atomic_connector_commit_dpms(struct 
> drm_atomic_state *state,
>   return ret;
>  }
> 
> +static int drm_atomic_check_prop_changes(int ret, uint64_t old_val, uint64_t 
> prop_value,
> +  struct drm_property *prop)
> +{
> + if (ret != 0 || old_val != prop_value) {
> + drm_dbg_atomic(prop->dev,
> +"[PROP:%d:%s] No prop can be changed during 
> async flip\n",
> +prop->base.id, prop->name);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
>  int drm_atomic_set_property(struct drm_atomic_state *state,
>   struct drm_file *file_priv,
>   struct drm_mode_object *obj,
>   struct drm_property *prop,
> - uint64_t prop_value)
> + uint64_t prop_value,
> + bool async_flip)
>  {
>   struct drm_mode_object *ref;
> + uint64_t old_val;
>   int ret;
> 
>   if (!drm_property_change_valid_get(prop, prop_value, ))
> @@ -995,6 +1010,13 @@ int drm_atomic_set_property(struct drm_atomic_state 
> *state,
>   break;
>   }
> 
> + if (async_flip) {
> + ret = drm_atomic_connector_get_property(connector, 
> connector_state,
> + prop, _val);
> + ret = drm_atomic_check_prop_changes(ret, old_val, 
> prop_value, prop);

Note to self: I was worried here to pass the "next" state to get_property(),
but it's before 

Re: [PATCH] drm/tiny: print 'struct resource *' correctly

2023-10-15 Thread Randy Dunlap



On 10/15/23 06:11, Yussef Dalton wrote:
> Since format specifier %pr refers to a 'struct resource *', there is no
> need to take the address of the 'res' variable since it is already of
> type 'struct resource *'.
> 
> Signed-off-by: Yussef Dalton 

Reviewed-by: Randy Dunlap 

Thanks.

> ---
>  drivers/gpu/drm/tiny/ofdrm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/tiny/ofdrm.c b/drivers/gpu/drm/tiny/ofdrm.c
> index 2d999a0facde..6372ab383747 100644
> --- a/drivers/gpu/drm/tiny/ofdrm.c
> +++ b/drivers/gpu/drm/tiny/ofdrm.c
> @@ -1208,13 +1208,13 @@ static struct ofdrm_device 
> *ofdrm_device_create(struct drm_driver *drv,
>  
>   ret = devm_aperture_acquire_from_firmware(dev, fb_pgbase, fb_pgsize);
>   if (ret) {
> - drm_err(dev, "could not acquire memory range %pr: error %d\n", 
> , ret);
> + drm_err(dev, "could not acquire memory range %pr: error %d\n", 
> res, ret);
>   return ERR_PTR(ret);
>   }
>  
>   mem = devm_request_mem_region(>dev, fb_pgbase, fb_pgsize, 
> drv->name);
>   if (!mem) {
> - drm_warn(dev, "could not acquire memory region %pr\n", );
> + drm_warn(dev, "could not acquire memory region %pr\n", res);
>   return ERR_PTR(-ENOMEM);
>   }
>  

-- 
~Randy


[PATCH v3] drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()

2023-10-15 Thread Geert Uytterhoeven
Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(),
which uses bpp and depth to guess the wanted buffer format.
However, drm_client_buffer_addfb() already knows the exact buffer
format, so there is no need to convert back and forth between buffer
format and bpp/depth, and the function can just call drm_mode_addfb2()
directly instead.

Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
v3:
  - Extract from series "[PATCH v2 0/8] drm: fb-helper/ssd130x: Add
support for DRM_FORMAT_R1"
(https://lore.kernel.org/all/cover.1692888745.git.ge...@linux-m68k.org),
as this patch has merits on its own,
v2:
  - Add Reviewed-by, Tested-by,
  - s/drm_mode_create_dumb/drm_client_buffer_addfb/ in one-line summary.
---
 drivers/gpu/drm/drm_client.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index d4296440f297fc5a..a780832a0963fe38 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -395,19 +395,16 @@ static int drm_client_buffer_addfb(struct 
drm_client_buffer *buffer,
   u32 handle)
 {
struct drm_client_dev *client = buffer->client;
-   struct drm_mode_fb_cmd fb_req = { };
-   const struct drm_format_info *info;
+   struct drm_mode_fb_cmd2 fb_req = { };
int ret;
 
-   info = drm_format_info(format);
-   fb_req.bpp = drm_format_info_bpp(info, 0);
-   fb_req.depth = info->depth;
fb_req.width = width;
fb_req.height = height;
-   fb_req.handle = handle;
-   fb_req.pitch = buffer->pitch;
+   fb_req.pixel_format = format;
+   fb_req.handles[0] = handle;
+   fb_req.pitches[0] = buffer->pitch;
 
-   ret = drm_mode_addfb(client->dev, _req, client->file);
+   ret = drm_mode_addfb2(client->dev, _req, client->file);
if (ret)
return ret;
 
-- 
2.34.1



Re: [PATCH v2 1/1] drm/panel: st7703: Fix timings when entering/exiting sleep

2023-10-15 Thread Guido Günther
Hi,
On Mon, Feb 13, 2023 at 01:32:38PM +0100, Frank Oltmanns wrote:
> Fix flickering of the pinephone's XDB599 panel that happens after
> resume.
> 
> Extend the delay after issuing the command to exit sleep mode from 60 to
> 120 msec as per the controller's specification.
> 
> Introduce a 120 msec delay after issuing the command to enter sleep
> mode. This is needed in order for the controller to reliably finalize
> the sleep in sequence before switching of power supply.
> 
> In contrast to the JH057N panel, the XBD599 panel does not require a 20
> msec delay after initialization and exiting sleep mode. Therefore, move
> the delay into the already existing device specific initialization
> function.
> 
> The XDB599 does not require a 20 msec delay between the SETBGP and
> SETVCOM commands. Therefore, remove the delay from the device specific
> initialization function.

Thanks. Applied to drm-misc-next.
Cheers,
 -- Guido

> Signed-off-by: Frank Oltmanns 
> Cc: Ondrej Jirman 
> Reported-by: Samuel Holland 
> ---
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..c49f4ef883fc 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -126,6 +126,7 @@ static int jh057n_init_sequence(struct st7703 *ctx)
>  0x18, 0x00, 0x09, 0x0E, 0x29, 0x2D, 0x3C, 
> 0x41,
>  0x37, 0x07, 0x0B, 0x0D, 0x10, 0x11, 0x0F, 
> 0x10,
>  0x11, 0x18);
> + msleep(20);
>  
>   return 0;
>  }
> @@ -273,7 +274,6 @@ static int xbd599_init_sequence(struct st7703 *ctx)
>   mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETBGP,
>  0x07, /* VREF_SEL = 4.2V */
>  0x07  /* NVREF_SEL = 4.2V */);
> - msleep(20);
>  
>   mipi_dsi_dcs_write_seq(dsi, ST7703_CMD_SETVCOM,
>  0x2C, /* VCOMDC_F = -0.67V */
> @@ -350,16 +350,14 @@ static int st7703_enable(struct drm_panel *panel)
>   return ret;
>   }
>  
> - msleep(20);
> -
>   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
>   if (ret < 0) {
>   dev_err(ctx->dev, "Failed to exit sleep mode: %d\n", ret);
>   return ret;
>   }
>  
> - /* Panel is operational 120 msec after reset */
> - msleep(60);
> + /* It takes the controller 120 msec to wake up after sleep. */
> + msleep(120);
>  
>   ret = mipi_dsi_dcs_set_display_on(dsi);
>   if (ret)
> @@ -384,6 +382,9 @@ static int st7703_disable(struct drm_panel *panel)
>   if (ret < 0)
>   dev_err(ctx->dev, "Failed to enter sleep mode: %d\n", ret);
>  
> + /* It takes the controller 120 msec to enter sleep mode. */
> + msleep(120);
> +
>   return 0;
>  }
>  
> -- 
> 2.39.1
> 


Re: [PATCH 1/1] drm/panel: st7703: Pick different reset sequence

2023-10-15 Thread Guido Günther
Hi,
On Sat, Feb 11, 2023 at 06:17:48PM +0100, Frank Oltmanns wrote:
> From: Ondrej Jirman 
> 
> Switching to a different reset sequence, enabling IOVCC before enabling
> VCC.
> 
> There also needs to be a delay after enabling the supplies and before
> deasserting the reset. The datasheet specifies 1ms after the supplies
> reach the required voltage. Use 10-20ms to also give the power supplies
> some time to reach the required voltage, too.
> 
> This fixes intermittent panel initialization failures and screen
> corruption during resume from sleep on panel xingbangda,xbd599 (e.g.
> used in PinePhone).

Thanks, applied to drm-misc-next.
Cheers,
 -- Guido

> 
> Signed-off-by: Ondrej Jirman 
> Signed-off-by: Frank Oltmanns 
> Reported-by: Samuel Holland 
> ---
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 25 ++-
>  1 file changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..45695aa51f62 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -411,29 +411,30 @@ static int st7703_prepare(struct drm_panel *panel)
>   return 0;
>  
>   dev_dbg(ctx->dev, "Resetting the panel\n");
> - ret = regulator_enable(ctx->vcc);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + ret = regulator_enable(ctx->iovcc);
>   if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
>   return ret;
>   }
> - ret = regulator_enable(ctx->iovcc);
> +
> + ret = regulator_enable(ctx->vcc);
>   if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> - goto disable_vcc;
> + dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + regulator_disable(ctx->iovcc);
> + return ret;
>   }
>  
> - gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> - usleep_range(20, 40);
> + /* Give power supplies time to stabilize before deasserting reset. */
> + usleep_range(1, 2);
> +
>   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> - msleep(20);
> + usleep_range(15000, 2);
>  
>   ctx->prepared = true;
>  
>   return 0;
> -
> -disable_vcc:
> - regulator_disable(ctx->vcc);
> - return ret;
>  }
>  
>  static const u32 mantix_bus_formats[] = {
> -- 
> 2.39.1
> 


[Bug 205089] amdgpu : drm:amdgpu_cs_ioctl : Failed to initialize parser -125

2023-10-15 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=205089

--- Comment #60 from nintyfa...@gmail.com (nintyfa...@gmail.com) ---

Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 512 MB
Total available memory: 8210 MB
Currently available dedicated video memory: 19 MB

This makes me nervous long ago. It always allocate near 512 MB. No matter if It
displays only blank desktop or I use many applications with games. Maybe there
is problem?

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH 1/1] drm/panel: st7703: Pick different reset sequence

2023-10-15 Thread Guido Günther
Hi,
On Sat, Feb 11, 2023 at 06:17:48PM +0100, Frank Oltmanns wrote:
> From: Ondrej Jirman 
> 
> Switching to a different reset sequence, enabling IOVCC before enabling
> VCC.
> 
> There also needs to be a delay after enabling the supplies and before
> deasserting the reset. The datasheet specifies 1ms after the supplies
> reach the required voltage. Use 10-20ms to also give the power supplies
> some time to reach the required voltage, too.
> 
> This fixes intermittent panel initialization failures and screen
> corruption during resume from sleep on panel xingbangda,xbd599 (e.g.
> used in PinePhone).
> 
> Signed-off-by: Ondrej Jirman 
> Signed-off-by: Frank Oltmanns 
> Reported-by: Samuel Holland 
> ---
>  drivers/gpu/drm/panel/panel-sitronix-st7703.c | 25 ++-
>  1 file changed, 13 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c 
> b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> index 6747ca237ced..45695aa51f62 100644
> --- a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> +++ b/drivers/gpu/drm/panel/panel-sitronix-st7703.c
> @@ -411,29 +411,30 @@ static int st7703_prepare(struct drm_panel *panel)
>   return 0;
>  
>   dev_dbg(ctx->dev, "Resetting the panel\n");
> - ret = regulator_enable(ctx->vcc);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + ret = regulator_enable(ctx->iovcc);
>   if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
>   return ret;
>   }
> - ret = regulator_enable(ctx->iovcc);
> +
> + ret = regulator_enable(ctx->vcc);
>   if (ret < 0) {
> - dev_err(ctx->dev, "Failed to enable iovcc supply: %d\n", ret);
> - goto disable_vcc;
> + dev_err(ctx->dev, "Failed to enable vcc supply: %d\n", ret);
> + regulator_disable(ctx->iovcc);
> + return ret;
>   }
>  
> - gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> - usleep_range(20, 40);
> + /* Give power supplies time to stabilize before deasserting reset. */
> + usleep_range(1, 2);
> +
>   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> - msleep(20);
> + usleep_range(15000, 2);
>  
>   ctx->prepared = true;
>  
>   return 0;
> -
> -disable_vcc:
> - regulator_disable(ctx->vcc);
> - return ret;
>  }
>  
>  static const u32 mantix_bus_formats[] = {

Reviewed-by: Guido Günther 

Cheers,
 -- Guido

> -- 
> 2.39.1
> 


Re: [PATCH v3 09/16] platform/x86/amd/pmf: Add facility to dump TA inputs

2023-10-15 Thread kernel test robot
Hi Shyam,

kernel test robot noticed the following build errors:

[auto build test ERROR on hid/for-next]
[also build test ERROR on drm-misc/drm-misc-next linus/master v6.6-rc5 
next-20231013]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Shyam-Sundar-S-K/platform-x86-amd-pmf-Add-PMF-TEE-interface/20231010-210347
base:   https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git for-next
patch link:
https://lore.kernel.org/r/20231010125917.138225-10-Shyam-sundar.S-k%40amd.com
patch subject: [PATCH v3 09/16] platform/x86/amd/pmf: Add facility to dump TA 
inputs
config: x86_64-allyesconfig 
(https://download.01.org/0day-ci/archive/20231015/202310151704.ofb4hsxk-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231015/202310151704.ofb4hsxk-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202310151704.ofb4hsxk-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from include/linux/printk.h:564,
from include/linux/kernel.h:30,
from arch/x86/include/asm/percpu.h:27,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:79,
from include/linux/spinlock.h:56,
from include/linux/mmzone.h:8,
from include/linux/gfp.h:7,
from include/linux/slab.h:16,
from include/linux/resource_ext.h:11,
from include/linux/acpi.h:13,
from drivers/platform/x86/amd/pmf/pmf.h:14,
from drivers/platform/x86/amd/pmf/sps.c:11:
   drivers/platform/x86/amd/pmf/sps.c: In function 'amd_pmf_dump_sps_defaults':
>> drivers/platform/x86/amd/pmf/sps.c:50:65: error: implicit declaration of 
>> function 'source_as_str' [-Werror=implicit-function-declaration]
  50 | pr_debug("--- Source:%s Mode:%s ---\n", 
source_as_str(i), slider_as_str(j));
 | 
^
   include/linux/dynamic_debug.h:224:29: note: in definition of macro 
'__dynamic_func_call_cls'
 224 | func(, ##__VA_ARGS__);   \
 | ^~~
   include/linux/dynamic_debug.h:250:9: note: in expansion of macro 
'_dynamic_func_call_cls'
 250 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, 
##__VA_ARGS__)
 | ^~
   include/linux/dynamic_debug.h:269:9: note: in expansion of macro 
'_dynamic_func_call'
 269 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
 | ^~
   include/linux/printk.h:579:9: note: in expansion of macro 'dynamic_pr_debug'
 579 | dynamic_pr_debug(fmt, ##__VA_ARGS__)
 | ^~~~
   drivers/platform/x86/amd/pmf/sps.c:50:25: note: in expansion of macro 
'pr_debug'
  50 | pr_debug("--- Source:%s Mode:%s ---\n", 
source_as_str(i), slider_as_str(j));
 | ^~~~
   drivers/platform/x86/amd/pmf/sps.c:50:34: warning: format '%s' expects 
argument of type 'char *', but argument 3 has type 'int' [-Wformat=]
  50 | pr_debug("--- Source:%s Mode:%s ---\n", 
source_as_str(i), slider_as_str(j));
 |  ^
   include/linux/printk.h:345:21: note: in definition of macro 'pr_fmt'
 345 | #define pr_fmt(fmt) fmt
 | ^~~
   include/linux/dynamic_debug.h:248:9: note: in expansion of macro 
'__dynamic_func_call_cls'
 248 | __dynamic_func_call_cls(__UNIQUE_ID(ddebug), cls, fmt, func, 
##__VA_ARGS__)
 | ^~~
   include/linux/dynamic_debug.h:250:9: note: in expansion of macro 
'_dynamic_func_call_cls'
 250 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func, 
##__VA_ARGS__)
 | ^~
   include/linux/dynamic_debug.h:269:9: note: in expansion of macro 
'_dynamic_func_call'
 269 | _dynamic_func_call(fmt, __dynamic_pr_debug, \
 | ^~
   include/linux/printk.h:579:9: note: in expansion of macro 'dynamic_pr_debug'
 579 | dynamic_pr_debug(fmt, ##__VA_ARGS__)
 | ^~~~
   drivers/platform/x86/amd/pmf/sps.c:50:25: