[Intel-gfx] [PATCH] drm/i915/dp: Fix LT debug print in SDP CRC enable
The debug print for enabling SDP CRC16 is applicable only for DP2.0, but this debug print was not within the uhbr check and was always printed. Fis this by adding proper checks and returning. Signed-off-by: Arun R Murthy --- .../gpu/drm/i915/display/intel_dp_link_training.c| 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index a263773f4d68..4485ef4f8ec6 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -1390,11 +1390,13 @@ void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp, * Default value of bit 31 is '0' hence discarding the write * TODO: Corrective actions on SDP corruption yet to be defined */ - if (intel_dp_is_uhbr(crtc_state)) - /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */ - drm_dp_dpcd_writeb(_dp->aux, - DP_SDP_ERROR_DETECTION_CONFIGURATION, - DP_SDP_CRC16_128B132B_EN); + if (!intel_dp_is_uhbr(crtc_state)) + return; + + /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */ + drm_dp_dpcd_writeb(_dp->aux, + DP_SDP_ERROR_DETECTION_CONFIGURATION, + DP_SDP_CRC16_128B132B_EN); lt_dbg(intel_dp, DP_PHY_DPRX, "DP2.0 SDP CRC16 for 128b/132b enabled\n"); } -- 2.25.1
Re: [Intel-gfx] [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc
> From: Tvrtko Ursulin
>
> According to the comment in i915_gem_object_can_bypass_llc the
> purpose of the function is to return false if the platform/object
> has a caching mode where GPU can bypass the LLC.
>
> So far the only platforms which allegedly can do this are Jasperlake
> and Elkhartlake, and that via MOCS (not PAT).
>
> Instead of blindly assuming that objects where userspace has set the
> PAT index can (bypass the LLC), question is is there a such PAT index
> on a platform. Probably starting with Meteorlake since that one is the
> only one where set PAT extension can be currently used. Or if there is
> a MOCS entry which can achieve the same thing on Meteorlake.
>
> If there is such PAT, now that i915 can be made to understand them
> better, we can make the check more fine grained. Or if there is a MOCS
> entry then we probably should apply the blanket IS_METEORLAKE condition.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
> Cc: Chris Wilson
> Cc: Fei Yang
> Cc: Andi Shyti
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 33a1e97d18b3..1e34171c4162 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -229,12 +229,6 @@ bool i915_gem_object_can_bypass_llc(struct
> drm_i915_gem_object *obj)
> if (!(obj->flags & I915_BO_ALLOC_USER))
> return false;
>
> - /*
> - * Always flush cache for UMD objects at creation time.
> - */
> - if (obj->pat_set_by_user)
I'm afraid this is going to break MESA. Can we run MESA tests with this patch?
> /*
>* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
>* possible for userspace to bypass the GTT caching bits set by the
> --
> 2.39.2
Re: [Intel-gfx] [RFC 1/2] drm/i915: Refactor PAT/object cache handling
[snip]
> @@ -326,10 +330,10 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev,
> void *data,
> goto out;
> }
>
> - if (i915_gem_object_has_cache_level(obj, I915_CACHE_LLC) ||
> - i915_gem_object_has_cache_level(obj, I915_CACHE_L3_LLC))
> + if (i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WB) &&
> + i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_COH1W) == 1)
Need to check L3 flag as well? The original code has L3_LLC.
if (i915_gem_object_has_cache_mode(obj, I915_CACHE_MODE_WB) &&
(i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_COH1W) == 1 ||
i915_gem_object_has_cache_flag(obj, I915_CACHE_FLAG_L3) == 1))
> args->caching = I915_CACHING_CACHED;
[snip]
> +int i915_cache_init(struct drm_i915_private *i915)
> +{
> + struct drm_printer p = drm_info_printer(i915->drm.dev);
> + char buf[I915_CACHE_NAME_LEN];
> + int ret;
> +
> + i915->cache = HAS_LLC(i915) ? I915_CACHE_CACHED : I915_CACHE_NONE;
> + i915_cache_print(buf, sizeof(buf), "", i915->cache);
> + drm_printf(, "Coherent cache mode %s", buf);
> +
> + ret = i915_cache_find_pat(i915, I915_CACHE_NONE);
> + if (ret < 0)
> + return -ENODEV;
> + drm_info(>drm, "Using PAT index %u for uncached access\n", ret);
> + i915->pat_uc = ret;
> +
> + ret = i915_cache_find_pat(i915, I915_CACHE_CACHED);
> + if (ret < 0)
> + return -ENODEV;
> + drm_info(>drm, "Using PAT index %u for write-back access\n", ret);
> + i915->pat_wb = ret;
I think i915->pat_wt is needed as well, because display driver has code like
this,
HAS_WT(i915) ? I915_CACHE_WT : I915_CACHE_NONE
How did you handle functions like initial_plane_vma() and
i915_gem_object_pin_to_display_plane()?
> + return 0;
> +}
[snip]
> -#define TGL_CACHELEVEL \
> - .cachelevel_to_pat = { \
> - [I915_CACHE_NONE] = 3, \
> - [I915_CACHE_LLC]= 0, \
> - [I915_CACHE_L3_LLC] = 0, \
> - [I915_CACHE_WT] = 2, \
> +/*
> + * TODO/QQQ
> + *
> + * PAT 0 - is it 1-way or 2-way?
1-way
> + */
> +#define GEN12_CACHE_MODES \
> + .cache_modes = { \
> + [0] = _I915_CACHE(WB, COH1W), \
> + [1] = I915_CACHE(WC), \
> + [2] = I915_CACHE(WT), \
> + [3] = I915_CACHE(UC), \
> }
[snip]
> -#define PVC_CACHELEVEL \
> - .cachelevel_to_pat = { \
> - [I915_CACHE_NONE] = 0, \
> - [I915_CACHE_LLC]= 3, \
> - [I915_CACHE_L3_LLC] = 3, \
> - [I915_CACHE_WT] = 2, \
> +/*
> + * TODO/QQQ
> + *
> + * PAT 3 - is it 1-way or 2-way?
1-way
PVC access is always coherent, it should have 1-way for [5] and [7] as well.
> + */
> +#define PVC_CACHE_MODES \
> + .cache_modes = { \
> + [0] = I915_CACHE(UC), \
> + [1] = I915_CACHE(WC), \
> + [2] = I915_CACHE(WT), \
> + [3] = _I915_CACHE(WB, COH1W), \
> + [4] = _I915_CACHE(WT, CLOS1), \
> + [5] = _I915_CACHE(WB, CLOS1), \
> + [6] = _I915_CACHE(WT, CLOS2), \
> + [7] = _I915_CACHE(WB, CLOS2), \
> }
Re: [Intel-gfx] [PATCH 4/4] drm/i915/panelreplay: enable/disable panel replay
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/4] 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.
>
> Note: Currently enabled full-screen live active frame update mode of panel
> replay. Panel replay also can be enabled in selective update mode which will
> be enabled in a incremental approach.
>
> Cc: Jouni Högander
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 30
> 1 file changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 50394143c798..b6406c334316 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -395,8 +395,14 @@ 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.enabled && IS_PANEL_REPLAY(intel_dp)) {
> + drm_dp_dpcd_writeb(_dp->aux,
> PANEL_REPLAY_CONFIG,
> +DP_PANEL_REPLAY_ENABLE);
> + return;
> + }
> +
> if (intel_dp->psr.psr2_enabled) {
> + /* Enable ALPM at sink for psr2 */
> drm_dp_dpcd_writeb(_dp->aux,
> DP_RECEIVER_ALPM_CONFIG,
> DP_ALPM_ENABLE |
>
> DP_ALPM_LOCK_ERROR_IRQ_HPD_ENABLE);
> @@ -526,6 +532,17 @@ static u32 intel_psr2_get_tp_time(struct intel_dp
> *intel_dp)
> return val;
> }
>
> +static void dg2_activate_panel_replay(struct intel_dp *intel_dp) {
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> +
> + intel_de_write(dev_priv, PSR2_MAN_TRK_CTL(intel_dp-
> >psr.transcoder),
> +
> ADLP_PSR2_MAN_TRK_CTL_SF_PARTIAL_FRAME_UPDATE);
> +
Can intel_de_rmw() be used, just to ensure that no other bits are updated.
Thanks and Regards,
Arun R Murthy
> + 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); @@ -
> 1101,8 +1118,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
> drm_WARN_ON(_priv->drm, intel_dp->psr.active);
> lockdep_assert_held(_dp->psr.lock);
>
> - /* psr1 and psr2 are mutually exclusive.*/
> - if (intel_dp->psr.psr2_enabled)
> + /* psr1, psr2 and panel-replay are mutually exclusive.*/
> + if (intel_dp->psr.enabled && IS_PANEL_REPLAY(intel_dp))
> + dg2_activate_panel_replay(intel_dp);
> + else if (intel_dp->psr.psr2_enabled)
> hsw_activate_psr2(intel_dp);
> else
> hsw_activate_psr1(intel_dp);
> @@ -1300,7 +1319,10 @@ static void intel_psr_exit(struct intel_dp
> *intel_dp)
> return;
> }
>
> - if (intel_dp->psr.psr2_enabled) {
> + if (intel_dp->psr.enabled && !intel_dp_is_edp(intel_dp)) {
> + intel_de_rmw(dev_priv, TRANS_DP2_CTL(intel_dp-
> >psr.transcoder),
> + TRANS_DP2_PANEL_REPLAY_ENABLE, 0);
> + } else if (intel_dp->psr.psr2_enabled) {
> tgl_disallow_dc3co_on_psr2_exit(intel_dp);
> val = intel_de_read(dev_priv,
> EDP_PSR2_CTL(intel_dp->psr.transcoder));
> --
> 2.29.0
Re: [Intel-gfx] [PATCH 3/4] drm/i915/panelreplay: Initializaton and compute config for panel replay
> -Original Message-
> From: Intel-gfx On Behalf Of
> Animesh Manna
> Sent: Thursday, November 10, 2022 8:33 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/4] drm/i915/panelreplay: Initializaton and
> compute config for panel replay
>
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
>
> Cc: Jouni Högander
> Signed-off-by: Animesh Manna
> ---
> .../drm/i915/display/intel_display_types.h| 15 +++
> drivers/gpu/drm/i915/display/intel_dp.c | 44 +++
> drivers/gpu/drm/i915/display/intel_psr.c | 44 ++-
> drivers/gpu/drm/i915/display/intel_psr.h | 1 +
> 4 files changed, 93 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 8da87cbb172b..3c126bf47119 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1623,6 +1623,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;
> @@ -1926,6 +1928,11 @@ dp_to_lspcon(struct intel_dp *intel_dp) #define
> CAN_PSR(intel_dp) ((intel_dp)->psr.sink_support && \
> (intel_dp)->psr.source_support)
>
> +#define CAN_PANEL_REPLAY(intel_dp) ((intel_dp)-
> >psr.sink_panel_replay_support && \
> + (intel_dp)-
> >psr.source_panel_replay_support)
> +
> +#define IS_PANEL_REPLAY(intel_dp) (!intel_dp_is_edp(intel_dp))
> +
> static inline bool intel_encoder_can_psr(struct intel_encoder *encoder) {
> if (!intel_encoder_is_dp(encoder))
> @@ -1934,6 +1941,14 @@ static inline bool intel_encoder_can_psr(struct
> intel_encoder *encoder)
> return CAN_PSR(enc_to_intel_dp(encoder));
> }
>
> +static inline bool intel_encoder_can_panel_replay(struct intel_encoder
> +*encoder) {
> + if (!intel_encoder_is_dp(encoder))
> + return false;
> +
> + return CAN_PANEL_REPLAY(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 7400d6b4c587..25bf18e40b96 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1726,12 +1726,23 @@ 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_psr && conn_state->connector->connector_type
> !=
> + DRM_MODE_CONNECTOR_eDP) {
> + /*
> + * 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
> + * VSC SDP supporting 3D stereo, PSR2, and Pixel Encoding/
> + * Colorimetry Format indication.
> + */
> + vsc->revision = 0x5;
> + }
> +
> vsc->length = 0x13;
>
> /* DP 1.4a spec, Table 2-120 */
> @@ -1840,6 +1851,21 @@ void intel_dp_compute_psr_vsc_sdp(struct
> intel_dp *intel_dp,
> vsc->revision = 0x4;
> vsc->length = 0xe;
> }
> + } else if (intel_dp->psr.enabled && IS_PANEL_REPLAY(intel_dp)) {
> + if (intel_dp->psr.colorimetry_support &&
> + intel_dp_needs_vsc_sdp(crtc_state, conn_state)) {
> + /* [Panel Replay with colorimetry info] */
> + intel_dp_compute_vsc_colorimetry(crtc_state,
> conn_state,
> + vsc);
> + } else {
> + /*
> + * [Panel Replay without colorimetry info]
> + * Prepare VSC Header for SU as per DP 2.0 spec,
> Table 2-223
> + * VSC SDP supporting 3D stereo + Panel Replay.
> + */
> + vsc->revision = 0x6;
> + vsc->length = 0x10;
> + }
> } else {
> /*
>
Re: [Intel-gfx] [PATCH 2/4] drm/i915/panelreplay: Added HAS_PANEL_REPLAY() macro
> -Original Message- > From: Intel-gfx On Behalf Of > Animesh Manna > Sent: Thursday, November 10, 2022 8:33 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 2/4] drm/i915/panelreplay: Added > HAS_PANEL_REPLAY() macro > > Platforms having Display 13 and above will support panel replay feature of > DP 2.0 monitor. Added a HAS_PANEL_REPLAY() macro to check for panel > replay capability. > Should we also check for DP2.0 supported monitor plugged in along with this Display 13 check? Thanks and Regards, Arun R Murthy > Cc: Jouni Högander > Signed-off-by: Animesh Manna > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/i915_drv.h > b/drivers/gpu/drm/i915/i915_drv.h index 05b3300cc4ed..ba47f4409d0b > 100644 > --- a/drivers/gpu/drm/i915/i915_drv.h > +++ b/drivers/gpu/drm/i915/i915_drv.h > @@ -873,6 +873,7 @@ IS_SUBPLATFORM(const struct drm_i915_private > *i915, > #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)- > >display.has_ddi) > #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)- > >display.has_fpga_dbg) > #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)- > >display.has_psr) > +#define HAS_PANEL_REPLAY(dev_priv)(DISPLAY_VER(dev_priv) >= > 13) > #define HAS_PSR_HW_TRACKING(dev_priv) \ > (INTEL_INFO(dev_priv)->display.has_psr_hw_tracking) > #define HAS_PSR2_SEL_FETCH(dev_priv) (DISPLAY_VER(dev_priv) >= > 12) > -- > 2.29.0
Re: [Intel-gfx] [PATCH 1/4] drm/i915/panelreplay: dpcd register definition for panelreplay
> -Original Message- > From: Intel-gfx On Behalf Of > Animesh Manna > Sent: Thursday, November 10, 2022 8:33 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 1/4] drm/i915/panelreplay: dpcd register > definition for panelreplay > > DPCD register definition added to check and enable panel replay capability of > the sink. > > Cc: Jouni Högander > Signed-off-by: Animesh Manna > --- > include/drm/display/drm_dp.h | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h > index e934aab357be..40995f8c2c2f 100644 > --- a/include/drm/display/drm_dp.h > +++ b/include/drm/display/drm_dp.h > @@ -537,6 +537,10 @@ > /* DFP Capability Extension */ > #define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */ > > +#define DP_PANEL_REPLAY_CAP 0x0b0 Per DP2.1 Spec PANEL_REPLAY_CAP_SUPPORTED 0x0b0 PANEL_REPLAY_CAP0x0b1 > +# define DP_PANEL_REPLAY_SUPPORT(1 << 0) > +# define DP_PR_SELECTIVE_UPDATE_SUPPORT (1 << 1) > + Instead can BIT() be used here? Thanks and Regards, Arun R Murthy > /* Link Configuration */ > #define DP_LINK_BW_SET 0x100 > # define DP_LINK_RATE_TABLE 0x00/* eDP 1.4 */ > @@ -706,6 +710,13 @@ > #define DP_BRANCH_DEVICE_CTRL0x1a1 > # define DP_BRANCH_DEVICE_IRQ_HPD(1 << 0) > > +#define PANEL_REPLAY_CONFIG 0x1b0 > +# define DP_PANEL_REPLAY_ENABLE (1 << 0) > +# define DP_PR_UNRECOVERABLE_ERROR (1 << 3) > +# define DP_PR_RFB_STORAGE_ERROR(1 << 4) > +# define DP_PR_ACTIVE_FRAME_CRC_ERROR (1 << 5) > +# define DP_PR_SELECTIVE_UPDATE_ENABLE (1 << 6) > + > #define DP_PAYLOAD_ALLOCATE_SET 0x1c0 > #define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 #define > DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 > -- > 2.29.0
Re: [Intel-gfx] [PATCH 08/19] drm/i915/dp: Remove extra logs for printing DSC info
> -Original Message- > From: Intel-gfx On Behalf Of Ankit > Nautiyal > Sent: Thursday, July 13, 2023 4:04 PM > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 08/19] drm/i915/dp: Remove extra logs for > printing DSC info > > DSC compressed bpp and slice counts are already getting printed at the end > of dsc compute config. Remove extra logs. > > Signed-off-by: Ankit Nautiyal > --- Reviewed-by: Arun R Murthy Thanks and Regards, Arun R Murthy > drivers/gpu/drm/i915/display/intel_dp.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c > b/drivers/gpu/drm/i915/display/intel_dp.c > index c1fd448d80e1..23ede846202c 100644 > --- a/drivers/gpu/drm/i915/display/intel_dp.c > +++ b/drivers/gpu/drm/i915/display/intel_dp.c > @@ -1780,9 +1780,6 @@ int intel_dp_dsc_compute_config(struct intel_dp > *intel_dp, > output_bpp); > } > pipe_config->dsc.slice_count = dsc_dp_slice_count; > - drm_dbg_kms(_priv->drm, "DSC: compressed bpp %d > slice count %d\n", > - pipe_config->dsc.compressed_bpp, > - pipe_config->dsc.slice_count); > } > /* >* VDSC engine operates at 1 Pixel per clock, so if peak pixel rate > -- > 2.40.1
Re: [Intel-gfx] [PATCH 02/19] drm/i915/dp: Move compressed bpp check with 420 format inside the helper
> -Original Message-
> From: Intel-gfx On Behalf Of Ankit
> Nautiyal
> Sent: Thursday, July 13, 2023 4:03 PM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 02/19] drm/i915/dp: Move compressed bpp check
> with 420 format inside the helper
>
> Move the check for limiting compressed bite_per_pixel for 420,422 formats
> in the helper to compute bits_per_pixel.
>
> Signed-off-by: Ankit Nautiyal
> ---
Looks good!
Reviewed-by: Arun R Murthy
Thanks and Regards,
Arun R Murthy
> drivers/gpu/drm/i915/display/intel_dp.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e0d9618fccab..d1db457fb17c 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -773,6 +773,15 @@ u16 intel_dp_dsc_get_output_bpp(struct
> drm_i915_private *i915,
> if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> bits_per_pixel *= 2;
>
> + /*
> + * According to DSC 1.2a Section 4.1.1 Table 4.1 the maximum
> + * supported PPS value can be 63.9375 and with the further
> + * mention that for 420, 422 formats, bpp should be programmed
> double
> + * the target bpp restricting our target bpp to be 31.9375 at max.
> + */
> + if (output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + bits_per_pixel = min_t(u32, bits_per_pixel, 31);
> +
> drm_dbg_kms(>drm, "Max link bpp is %u for %u timeslots "
> "total bw %u pixel clock %u\n",
> bits_per_pixel, timeslots,
> @@ -1738,15 +1747,6 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> pipe_config-
> >output_format,
> pipe_bpp,
> timeslots);
> - /*
> - * According to DSC 1.2a Section 4.1.1 Table 4.1 the
> maximum
> - * supported PPS value can be 63.9375 and with the
> further
> - * mention that bpp should be programmed double
> the target bpp
> - * restricting our target bpp to be 31.9375 at max
> - */
> - if (pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> - dsc_max_output_bpp = min_t(u16,
> dsc_max_output_bpp, 31 << 4);
> -
> if (!dsc_max_output_bpp) {
> drm_dbg_kms(_priv->drm,
> "Compressed BPP not
> supported\n");
> --
> 2.40.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf/dma-resv: Stop leaking on krealloc() failure
== Series Details == Series: dma-buf/dma-resv: Stop leaking on krealloc() failure URL : https://patchwork.freedesktop.org/series/120699/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13384_full -> Patchwork_120699v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_120699v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_120699v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_120699v1_full: ### IGT changes ### Possible regressions * igt@kms_busy@extended-modeset-hang-newfb@pipe-a: - shard-snb: NOTRUN -> [ABORT][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-snb7/igt@kms_busy@extended-modeset-hang-ne...@pipe-a.html Known issues Here are the changes found in Patchwork_120699v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@multigpu-create-close: - shard-dg2: NOTRUN -> [SKIP][2] ([i915#7697]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-1/igt@gem_ba...@multigpu-create-close.html * igt@gem_create@create-ext-set-pat: - shard-snb: NOTRUN -> [FAIL][3] ([i915#8621]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-snb2/igt@gem_cre...@create-ext-set-pat.html * igt@gem_create@hog-create@smem0: - shard-dg2: [PASS][4] -> [FAIL][5] ([i915#5892] / [i915#8758]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-dg2-10/igt@gem_create@hog-cre...@smem0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-11/igt@gem_create@hog-cre...@smem0.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-tglu: [PASS][6] -> [FAIL][7] ([i915#6268]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-tglu-5/igt@gem_ctx_e...@basic-nohangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-tglu-9/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-snb2/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@bcs0: - shard-rkl: [PASS][11] -> [FAIL][12] ([i915#2842]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-rkl-1/igt@gem_exec_fair@basic-n...@bcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-rkl-4/igt@gem_exec_fair@basic-n...@bcs0.html * igt@gem_exec_fair@basic-pace-solo: - shard-mtlp: NOTRUN -> [SKIP][13] ([i915#4473]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-mtlp-8/igt@gem_exec_f...@basic-pace-solo.html * igt@gem_exec_flush@basic-uc-set-default: - shard-dg2: NOTRUN -> [SKIP][14] ([i915#3539]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-1/igt@gem_exec_fl...@basic-uc-set-default.html * igt@gem_exec_suspend@basic-s3@lmem0: - shard-dg2: [PASS][15] -> [FAIL][16] ([fdo#103375]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-dg2-10/igt@gem_exec_suspend@basic...@lmem0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-5/igt@gem_exec_suspend@basic...@lmem0.html * igt@gem_exec_suspend@basic-s4-devices@lmem0: - shard-dg2: NOTRUN -> [ABORT][17] ([i915#7975] / [i915#8213]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-1/igt@gem_exec_suspend@basic-s4-devi...@lmem0.html * igt@gem_lmem_swapping@heavy-verify-random-ccs: - shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-glk4/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html * igt@gem_mmap_wc@read: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#4083]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/shard-dg2-1/igt@gem_mmap...@read.html
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling
== Series Details == Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling URL : https://patchwork.freedesktop.org/series/120686/ State : success == Summary == CI Bug Log - changes from CI_DRM_13384_full -> Patchwork_120686v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 11) -- Additional (1): shard-rkl0 Known issues Here are the changes found in Patchwork_120686v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_fdinfo@most-busy-check-all@rcs0: - shard-rkl: [PASS][1] -> [FAIL][2] ([i915#7742]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-rkl-2/igt@drm_fdinfo@most-busy-check-...@rcs0.html * igt@drm_fdinfo@virtual-busy: - shard-mtlp: NOTRUN -> [SKIP][3] ([i915#8414]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-mtlp-3/igt@drm_fdi...@virtual-busy.html * igt@gem_barrier_race@remote-request@rcs0: - shard-tglu: [PASS][4] -> [ABORT][5] ([i915#8211] / [i915#8234]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-tglu-5/igt@gem_barrier_race@remote-requ...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-tglu-8/igt@gem_barrier_race@remote-requ...@rcs0.html * igt@gem_basic@multigpu-create-close: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#7697]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-dg2-10/igt@gem_ba...@multigpu-create-close.html * igt@gem_create@create-ext-set-pat: - shard-snb: NOTRUN -> [FAIL][7] ([i915#8621]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-snb6/igt@gem_cre...@create-ext-set-pat.html * igt@gem_create@hog-create@smem0: - shard-dg2: [PASS][8] -> [FAIL][9] ([i915#5892] / [i915#8758]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-dg2-10/igt@gem_create@hog-cre...@smem0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-dg2-1/igt@gem_create@hog-cre...@smem0.html * igt@gem_ctx_persistence@engines-mixed: - shard-snb: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1099]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-snb6/igt@gem_ctx_persiste...@engines-mixed.html * igt@gem_exec_fair@basic-deadline: - shard-mtlp: NOTRUN -> [SKIP][11] ([i915#4473] / [i915#4771]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-mtlp-3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fair@basic-none@bcs0: - shard-rkl: [PASS][14] -> [FAIL][15] ([i915#2842]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-rkl-1/igt@gem_exec_fair@basic-n...@bcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-rkl-7/igt@gem_exec_fair@basic-n...@bcs0.html * igt@gem_exec_fair@basic-pace-solo: - shard-mtlp: NOTRUN -> [SKIP][16] ([i915#4473]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-mtlp-8/igt@gem_exec_f...@basic-pace-solo.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/shard-glk1/igt@gem_exec_fair@basic-p...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-glk8/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_flush@basic-uc-set-default: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#3539]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-dg2-10/igt@gem_exec_fl...@basic-uc-set-default.html * igt@gem_exec_reloc@basic-wc: - shard-mtlp: NOTRUN -> [SKIP][20] ([i915#3281]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-mtlp-4/igt@gem_exec_re...@basic-wc.html * igt@gem_exec_suspend@basic-s4-devices@lmem0: - shard-dg2: NOTRUN -> [ABORT][21] ([i915#7975] / [i915#8213]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/shard-dg2-10/igt@gem_exec_suspend@basic-s4-devi...@lmem0.html * igt@gem_exec_suspend@basic-s4-devices@smem: - shard-snb: [PASS][22] -> [SKIP][23] ([fdo#109271]) [22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for eventfd: simplify signal helpers
== Series Details == Series: eventfd: simplify signal helpers URL : https://patchwork.freedesktop.org/series/120668/ State : success == Summary == CI Bug Log - changes from CI_DRM_13383_full -> Patchwork_120668v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 10) -- No changes in participating hosts New tests - New tests have been introduced between CI_DRM_13383_full and Patchwork_120668v1_full: ### New IGT tests (1) ### * igt@kms_invalid_mode@bad-htotal@hdmi-a-2-pipe-d: - Statuses : 1 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_120668v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_fdinfo@busy-hang@bcs0: - shard-dg2: NOTRUN -> [SKIP][1] ([i915#8414]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@drm_fdinfo@busy-h...@bcs0.html * igt@drm_fdinfo@most-busy-idle-check-all@rcs0: - shard-rkl: [PASS][2] -> [FAIL][3] ([i915#7742]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html * igt@gem_basic@multigpu-create-close: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#7697]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_ba...@multigpu-create-close.html * igt@gem_caching@writes: - shard-mtlp: NOTRUN -> [SKIP][5] ([i915#4873]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-mtlp-4/igt@gem_cach...@writes.html * igt@gem_exec_balancer@bonded-sync: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#4771]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_exec_balan...@bonded-sync.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglu: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/shard-tglu-6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-tglu-7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vecs0: - shard-rkl: [PASS][9] -> [FAIL][10] ([i915#2842]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/shard-rkl-6/igt@gem_exec_fair@basic-p...@vecs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-rkl-2/igt@gem_exec_fair@basic-p...@vecs0.html * igt@gem_exec_flush@basic-uc-set-default: - shard-dg2: NOTRUN -> [SKIP][11] ([i915#3539]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_exec_fl...@basic-uc-set-default.html * igt@gem_exec_reloc@basic-gtt-read: - shard-dg2: NOTRUN -> [SKIP][12] ([i915#3281]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_exec_re...@basic-gtt-read.html * igt@gem_exec_schedule@pi-ringfull@ccs0: - shard-mtlp: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/shard-mtlp-7/igt@gem_exec_schedule@pi-ringf...@ccs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-mtlp-6/igt@gem_exec_schedule@pi-ringf...@ccs0.html * igt@gem_exec_whisper@basic-contexts-priority-all: - shard-mtlp: [PASS][15] -> [ABORT][16] ([i915#8131]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/shard-mtlp-5/igt@gem_exec_whis...@basic-contexts-priority-all.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-mtlp-8/igt@gem_exec_whis...@basic-contexts-priority-all.html * igt@gem_media_vme: - shard-dg2: NOTRUN -> [SKIP][17] ([i915#284]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_media_vme.html * igt@gem_mmap_wc@close: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#4083]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_mmap...@close.html * igt@gem_pxp@reject-modify-context-protection-off-1: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#4270]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_...@reject-modify-context-protection-off-1.html * igt@gem_userptr_blits@coherency-unsync: - shard-dg2: NOTRUN -> [SKIP][20] ([i915#3297]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/shard-dg2-11/igt@gem_userptr_bl...@coherency-unsync.html * igt@gem_userptr_blits@forbidden-operations: - shard-dg2:
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/dma-resv: Stop leaking on krealloc() failure
== Series Details == Series: dma-buf/dma-resv: Stop leaking on krealloc() failure URL : https://patchwork.freedesktop.org/series/120699/ State : success == Summary == CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120699v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_120699v1 that come from known issues: ### IGT changes ### Issues hit * igt@dmabuf@all-tests@dma_fence: - bat-atsm-1: [PASS][1] -> [DMESG-FAIL][2] ([i915#8189]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-atsm-1/igt@dmabuf@all-tests@dma_fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-atsm-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-atsm-1: [PASS][3] -> [ABORT][4] ([i915#7699]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-atsm-1/igt@dmabuf@all-te...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-atsm-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_pm_rpm@module-reload: - fi-tgl-1115g4: [PASS][5] -> [FAIL][6] ([i915#7940]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html - fi-skl-guc: [PASS][7] -> [FAIL][8] ([i915#7940]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-skl-guc/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/fi-skl-guc/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][9] -> [DMESG-FAIL][10] ([i915#7269]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-mtlp-8/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-mtlp-6: [PASS][11] -> [DMESG-WARN][12] ([i915#6367]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-mtlp-6/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html - bat-rpls-2: NOTRUN -> [DMESG-WARN][13] ([i915#6367]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][14] ([i915#7828]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-jsl-3: NOTRUN -> [SKIP][15] ([i915#7828]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][16] ([i915#1845] / [i915#5354]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][17] ([i915#1845]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [ABORT][18] ([i915#5122]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-cfl-8700k: [FAIL][20] ([i915#7940]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@basic-rte: - fi-skl-guc: [FAIL][22] ([i915#7940]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-skl-guc/igt@i915_pm_...@basic-rte.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120699v1/fi-skl-guc/igt@i915_pm_...@basic-rte.html - fi-kbl-7567u: [FAIL][24] ([i915#7940]) -> [PASS][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html [25]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG regression (rev2)
== Series Details == Series: fix DRM_USE_DYNAMIC_DEBUG regression (rev2) URL : https://patchwork.freedesktop.org/series/113363/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fix DRM_USE_DYNAMIC_DEBUG regression (rev2)
== Series Details ==
Series: fix DRM_USE_DYNAMIC_DEBUG regression (rev2)
URL : https://patchwork.freedesktop.org/series/113363/
State : warning
== Summary ==
Error: dim checkpatch failed
075f00fa91b5 drm: use correct ccflags-y syntax
da5e4e98a0f2 test-dyndbg: fixup CLASSMAP usage error
bb7f9d768fa1 dyndbg: make ddebug_class_param union members same size
705c022f0043 dyndbg: replace classmap list with a vector
855269370ac5 dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
ecd5ac2c7986 dyndbg: split param_set_dyndbg_classes to module/wrapper fns
-:68: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#68: FILE: lib/dynamic_debug.c:772:
}
+/**
total: 0 errors, 0 warnings, 1 checks, 60 lines checked
fe3ccd116db8 dyndbg: drop NUM_TYPE_ARRAY
e3b9b37549df dyndbg: reduce verbose/debug clutter
-:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#15:
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_CORE
total: 0 errors, 1 warnings, 0 checks, 50 lines checked
bed4c9cf5e20 dyndbg: silence debugs with no-change updates
a799f27373c8 dyndbg: tighten ddebug_class_name() 1st arg type
086e0baab17d dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
78ca67037fd9 dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
-:157: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthrough;' over fallthrough
comment
#157: FILE: lib/dynamic_debug.c:644:
+ /* numeric input, accept and fall-thru */
total: 0 errors, 1 warnings, 0 checks, 179 lines checked
fb5cf263531d dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP &
CONFIG_DRM_USE_DYNAMIC_DEBUG
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:71: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#71:
dynamic_debug.c has changes in 2 areas: ddebug_add_module(), ddebug_change().
-:163: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit
<12+ chars of sha1> ("")' - ie: 'commit bb2ff6c27bc9 ("drm: Disable
dynamic debug as broken")'
#163:
Ref: bb2ff6c27bc9 ("drm: Disable dynamic debug as broken")
-:422: CHECK:LINE_SPACING: Please use a blank line after
function/struct/union/enum declarations
#422: FILE: include/linux/dynamic_debug.h:109:
+};
+/**
-:432: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_var' - possible
side-effects?
#432: FILE: include/linux/dynamic_debug.h:119:
+#define DYNDBG_CLASSMAP_USE_(_var, _uname) \
+ extern struct ddebug_class_map _var;\
+ struct ddebug_class_user __used \
+ __section("__dyndbg_class_users") _uname = {\
+ .user_mod_name = KBUILD_MODNAME,\
+ .map = &_var, \
}
-:486: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#486: FILE: lib/dynamic_debug.c:46:
+extern struct ddebug_class_user __start___dyndbg_class_users[];
-:487: WARNING:AVOID_EXTERNS: externs should be avoided in .c files
#487: FILE: lib/dynamic_debug.c:47:
+extern struct ddebug_class_user __stop___dyndbg_class_users[];
-:504: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dt' - possible side-effects?
#504: FILE: lib/dynamic_debug.c:153:
+#define vpr_dt_info(dt, _msg, ...) \
+ v2pr_info(_msg " module:%s nd:%d nc:%d nu:%d\n", ##__VA_ARGS__, \
+ dt->mod_name, dt->num_ddebugs, dt->num_classes,
dt->num_class_users)
-:504: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'dt' may be better as '(dt)'
to avoid precedence issues
#504: FILE: lib/dynamic_debug.c:153:
+#define vpr_dt_info(dt, _msg, ...) \
+ v2pr_info(_msg " module:%s nd:%d nc:%d nu:%d\n", ##__VA_ARGS__, \
+ dt->mod_name, dt->num_ddebugs, dt->num_classes,
dt->num_class_users)
-:586: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#586: FILE: lib/dynamic_debug.c:1142:
+static const char* ddebug_classmap_typenames[] = {
-:586: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#586: FILE: lib/dynamic_debug.c:1142:
+static const char* ddebug_classmap_typenames[] = {
-:590: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'cm' - possible side-effects?
#590: FILE: lib/dynamic_debug.c:1146:
+#define vpr_cm_info(cm, _msg, ...) \
+ v2pr_info(_msg " module:%s base:%d len:%d type:%s\n", ##__VA_ARGS__, \
+ cm->mod_name, cm->base, cm->length,
ddebug_classmap_typenames[cm->map_type])
-:590: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'cm' may be better as '(cm)'
to avoid precedence issues
#590: FILE: lib/dynamic_debug.c:1146:
+#define vpr_cm_info(cm,
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling
== Series Details == Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling URL : https://patchwork.freedesktop.org/series/120686/ State : success == Summary == CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120686v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/index.html Participating hosts (42 -> 40) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_120686v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-skl-guc: [PASS][1] -> [FAIL][2] ([i915#7940]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/fi-skl-guc/igt@i915_pm_...@basic-pci-d3-state.html - bat-dg1-7: [PASS][3] -> [FAIL][4] ([i915#7691]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@gt_lrc: - bat-rpls-2: [PASS][5] -> [INCOMPLETE][6] ([i915#4983] / [i915#7913]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][7] -> [DMESG-WARN][8] ([i915#7699]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-dg2-11/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-jsl-3: NOTRUN -> [SKIP][9] ([i915#7828]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#1845] / [i915#5354]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [ABORT][11] ([i915#5122]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-rte: - fi-skl-guc: [FAIL][13] ([i915#7940]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-skl-guc/igt@i915_pm_...@basic-rte.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/fi-skl-guc/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-rkl-11600: [FAIL][15] ([i915#7940]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-rkl-11600/igt@i915_pm_...@module-reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html * igt@i915_suspend@basic-s3-without-i915: - bat-jsl-3: [FAIL][17] ([fdo#103375]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-jsl-3/igt@i915_susp...@basic-s3-without-i915.html Warnings * igt@i915_module_load@load: - bat-adlp-11:[DMESG-WARN][19] ([i915#4423]) -> [ABORT][20] ([i915#4423]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-adlp-11/igt@i915_module_l...@load.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-adlp-11/igt@i915_module_l...@load.html * igt@kms_psr@cursor_plane_move: - bat-rplp-1: [SKIP][21] ([i915#1072]) -> [ABORT][22] ([i915#8434] / [i915#8668]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-rplp-1/igt@kms_psr@cursor_plane_move.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120686v1/bat-rplp-1/igt@kms_psr@cursor_plane_move.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4423]: https://gitlab.freedesktop.org/drm/intel/issues/4423 [i915#4983]:
[Intel-gfx] [PATCH] dma-buf/dma-resv: Stop leaking on krealloc() failure
From: Ville Syrjälä
Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.
Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.
Cc: Sumit Semwal
Cc: Christian König
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3")
Signed-off-by: Ville Syrjälä
---
drivers/dma-buf/dma-resv.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index b6f71eb00866..38b4110378de 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -571,6 +571,7 @@ int dma_resv_get_fences(struct dma_resv *obj, enum
dma_resv_usage usage,
dma_resv_for_each_fence_unlocked(, fence) {
if (dma_resv_iter_is_restarted()) {
+ struct dma_fence **new_fences;
unsigned int count;
while (*num_fences)
@@ -579,13 +580,17 @@ int dma_resv_get_fences(struct dma_resv *obj, enum
dma_resv_usage usage,
count = cursor.num_fences + 1;
/* Eventually re-allocate the array */
- *fences = krealloc_array(*fences, count,
-sizeof(void *),
-GFP_KERNEL);
- if (count && !*fences) {
+ new_fences = krealloc_array(*fences, count,
+ sizeof(void *),
+ GFP_KERNEL);
+ if (count && !new_fences) {
+ kfree(*fences);
+ *fences = NULL;
+ *num_fences = 0;
dma_resv_iter_end();
return -ENOMEM;
}
+ *fences = new_fences;
}
(*fences)[(*num_fences)++] = dma_fence_get(fence);
--
2.39.3
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling
== Series Details == Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling URL : https://patchwork.freedesktop.org/series/120686/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache handling
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Refactor PAT/object cache
handling
URL : https://patchwork.freedesktop.org/series/120686/
State : warning
== Summary ==
Error: dim checkpatch failed
49bef4e97877 drm/i915: Refactor PAT/object cache handling
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:734: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#734: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:63:
+i915_ttm_cache_pat(struct drm_i915_private *i915, struct ttm_resource *res,
struct ttm_tt *ttm)
-:1347: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#1347:
new file mode 100644
-:1352: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier
tag in line 1
#1352: FILE: drivers/gpu/drm/i915/i915_cache.c:1:
+/*
-:1353: WARNING:SPDX_LICENSE_TAG: Misplaced SPDX-License-Identifier tag - use
line 1 instead
#1353: FILE: drivers/gpu/drm/i915/i915_cache.c:2:
+ * SPDX-License-Identifier: MIT
-:1406: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#1406: FILE: drivers/gpu/drm/i915/i915_cache.c:55:
+ static const char *mode_str[] = {
-:1412: WARNING:STATIC_CONST_CHAR_ARRAY: static const char * array should
probably be static const char * const
#1412: FILE: drivers/gpu/drm/i915/i915_cache.c:61:
+ static const char *flag_str[] = {
-:1462: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#1462: FILE: drivers/gpu/drm/i915/i915_cache.h:17:
+#define I915_CACHE(mode) \
+ (i915_cache_t)(I915_CACHE_MODE_##mode)
-:1467: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#1467: FILE: drivers/gpu/drm/i915/i915_cache.h:22:
+#define _I915_CACHE(mode, flag) \
+ (i915_cache_t)((I915_CACHE_MODE_##mode) | __I915_CACHE_FLAG(flag))
-:1470: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#1470: FILE: drivers/gpu/drm/i915/i915_cache.h:25:
+#define __I915_CACHE(mode, flags) \
+ (i915_cache_t)((I915_CACHE_MODE_##mode) | ((flags) << 8))
-:1473: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#1473: FILE: drivers/gpu/drm/i915/i915_cache.h:28:
+#define I915_CACHE_MODE(cache) \
+ (enum i915_cache_mode)(((i915_cache_t)(cache)) & 0xff)
-:1475: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#1475: FILE: drivers/gpu/drm/i915/i915_cache.h:30:
+#define I915_CACHE_FLAGS(cache) \
+ (unsigned int)i915_cache_t)(cache) & 0xff00)) >> 8)
-:2081: WARNING:LINE_CONTINUATIONS: Avoid unnecessary line continuations
#2081: FILE: drivers/gpu/drm/i915/selftests/mock_gem_device.c:134:
+ [2] = __I915_CACHE(WB, BIT(I915_CACHE_FLAG_COH1W) |
BIT(I915_CACHE_FLAG_L3)), \
total: 5 errors, 6 warnings, 1 checks, 1729 lines checked
df03c572f382 drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc
-:14: WARNING:REPEATED_WORD: Possible repeated word: 'is'
#14:
index can (bypass the LLC), question is is there a such PAT index on a
total: 0 errors, 1 warnings, 0 checks, 12 lines checked
Re: [Intel-gfx] [PATCH v4 21/21] dyndbg-doc: add classmap info to howto
On 7/13/23 09:36, Jim Cromie wrote: > Add some basic info on classmap usage and api > > Signed-off-by: Jim Cromie > --- > .../admin-guide/dynamic-debug-howto.rst | 64 ++- > 1 file changed, 63 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst > b/Documentation/admin-guide/dynamic-debug-howto.rst > index 8dc668cc1216..878750ce8c1d 100644 > --- a/Documentation/admin-guide/dynamic-debug-howto.rst > +++ b/Documentation/admin-guide/dynamic-debug-howto.rst > @@ -374,3 +373,66 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``. > For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is > its ``prefix_str`` argument, if it is constant string; or ``hexdump`` > in case ``prefix_str`` is built dynamically. > + > +Dynamic Debug classmaps > +=== > + > +Dyndbg generally selects *prdbg* callsites using structural info: > +module, file, function, line. Using classmaps, user modules can > +organize/select pr_debug()s as they like. > + > +- classes coordinates/spans multiple modules > +- complements the mod,file,func attrs > +- keeps pr_debug's 0-off-cost JUMP_LABEL goodness > +- isolates from other class'd and un-class'd pr_debugs() > + (one doesnt mix 2 clients bank accounts) doesn't > + > + # IOW this doesn't change DRM.debug settings > + #> echo -p > /proc/dynamic_debug/control > + > + # change the classes by naming them explicitly (no wildcard here) > + #> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control > + > +To support DRM.debug (/sys/module/drm/parameters/debug), dyndbg > +provides DYNDBG_CLASSMAP_PARAM*. It maps the categories/classes: > +DRM_UT_CORE.. to bits 0..N, allowing to set all classes at once. > + > +Dynamic Debug Classmap API > +== > + > +DYNDBG_CLASSMAP_DEFINE - modules create CLASSMAPs, naming the classes > +and type, and mapping the class-names to consecutive _class_ids. By > +doing so, they tell dyndbg that they are using those class_ids, and > +authorize dyndbg to manipulate the callsites by their class-names. > + > +Its expected that client modules will follow the DRM.debug model: > +1. define their debug-classes using an enum type, where the enum > +symbol and its integer value define both the classnames and class-ids. > +2. use or macro-wrap __pr_debug_cls(ENUM_VAL, "hello world\n") > + > +There are 2 types of classmaps: > + > + DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, ala DRM.debug a la or just like > + DD_CLASS_TYPE_LEVEL_NUM: classes are relative (Verbose3 > Verbose2) > + > +Both these classmap-types use the class-names/ENUM_VALs to validate > +commands into >control. > + > +DYNDBG_CLASSMAP_PARAM - refs a DEFINEd classmap, exposing the set of Is this: refers to a ? > +defined classes to manipulation as a group. This interface enforces > +the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed classmaps; > +all classes are independent in the >control parser itself. > + > +DYNDBG_CLASSMAP_USE - drm drivers use the CLASSMAP that drm DEFINEs. > +This shares the classmap defn, and authorizes coordinated changes definition, > +amongst the CLASSMAP DEFINEr and multiple USErs. > + > +Modules or module-groups (drm & drivers) can define multiple > +classmaps, as long as they share the limited 0..62 per-module-group > +_class_id range, without overlap. > + > +``#define DEBUG`` will enable all pr_debugs in scope, including any > +class'd ones (__pr_debug_cls(id,fmt..)). This won't be reflected in > +the PARAM readback value, but the pr_debug callsites can be toggled > +into agreement with the param. > + thanks. -- ~Randy
Re: [Intel-gfx] [PATCH v4 20/21] config TEST_DYNAMIC_DEBUG default m
Hi Jim, On 7/13/23 09:36, Jim Cromie wrote: > Signed-off-by: Jim Cromie > --- > lib/Kconfig.debug | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index d4fbbcc395d2..82d11ac63758 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -2696,13 +2696,14 @@ config TEST_STATIC_KEYS > > config TEST_DYNAMIC_DEBUG > tristate "Build test-dynamic-debug module" > + default m You need to justify such a change, and since it's not required for running the system, I don't think it should be 'm'. > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE > help > This module works/demo's the dyndbg's classmap API, by > creating 2 classes: a DISJOINT classmap (like DRM.debug) > and a LEVELS/VERBOSE classmap (where 2>1). > > - If unsure, say N. > + If unsure, say N. If bored/curious, say M > > config TEST_KMOD > tristate "kmod stress tester" -- ~Randy
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gt: Do not use stolen on MTL
== Series Details == Series: series starting with [1/2] drm/i915/gt: Do not use stolen on MTL URL : https://patchwork.freedesktop.org/series/120683/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13384 -> Patchwork_120683v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_120683v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_120683v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_120683v1: ### IGT changes ### Possible regressions * igt@i915_pciid: - fi-kbl-soraka: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-kbl-soraka/igt@i915_pciid.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/fi-kbl-soraka/igt@i915_pciid.html Known issues Here are the changes found in Patchwork_120683v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - bat-dg1-7: [PASS][3] -> [FAIL][4] ([i915#7691]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-dg1-7/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@basic-rte: - fi-tgl-1115g4: [PASS][5] -> [FAIL][6] ([i915#7940]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-skl-guc: [PASS][7] -> [FAIL][8] ([i915#7940]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/fi-skl-guc/igt@i915_pm_...@module-reload.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/fi-skl-guc/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][9] -> [DMESG-FAIL][10] ([i915#8497]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-mtlp-8/igt@i915_selftest@l...@requests.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-mtlp-6: [PASS][11] -> [DMESG-WARN][12] ([i915#6367]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-mtlp-6/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html - bat-rpls-2: NOTRUN -> [DMESG-WARN][13] ([i915#6367]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html - bat-mtlp-8: [PASS][14] -> [DMESG-WARN][15] ([i915#6367]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-mtlp-8/igt@i915_selftest@l...@slpc.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][16] ([i915#7828]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-jsl-3: NOTRUN -> [SKIP][17] ([i915#7828]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-jsl-3/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][18] ([i915#1845] / [i915#5354]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#1845]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-jsl-3: [ABORT][20] ([i915#5122]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13384/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120683v1/bat-jsl-3/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-cfl-8700k:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/gt: Do not use stolen on MTL
== Series Details == Series: series starting with [1/2] drm/i915/gt: Do not use stolen on MTL URL : https://patchwork.freedesktop.org/series/120683/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +drivers/gpu/drm/i915/gt/intel_gt.h:112:16: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:346:1: warning: trying to copy expression type 31 +./drivers/gpu/drm/i915/intel_uncore.h:351:1: warning: trying to copy expression type 31 +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p'
Re: [Intel-gfx] [PATCH] drm/i915: Introduce Wa_14011274333
On Wed, Jul 12, 2023 at 04:34:15PM -0700, Matt Atwood wrote:
> Wa_14011274333 applies to RKL, ADL-S, ADL-P and TGL. ALlocate buffer
> pinned to GGTT and add WA to restore impacted registers.
You should explain the approach you're taking to implement this
workaround since someone reading the workaround description isn't really
going to understand how your code here addresses it.
>
> v2: use correct lineage number, more generically apply workarounds for
> all registers impacted, move workaround to gt/intel_workarounds.c
> (MattR)
>
> Based off patch by Tilak Tangudu.
>
> Signed-off-by: Matt Atwood
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 5 ++
> drivers/gpu/drm/i915/gt/intel_rc6.c | 63 +
> drivers/gpu/drm/i915/gt/intel_rc6_types.h | 3 +
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 40 +
> 4 files changed, 111 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 718cb2c80f79e..eaee35ecbc8d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -83,6 +83,11 @@
> #define MTL_MCR_GROUPIDREG_GENMASK(11, 8)
> #define MTL_MCR_INSTANCEID REG_GENMASK(3, 0)
>
> +#define CTX_WA_PTR _MMIO(0x2058)
CTX_WA_PTR is a register that exists for every engine, not just the RCS
engine. This should be a parameterized definition in the engine reg
file, not here.
> +#define CTX_WA_PTR_ADDR_MASKREG_GENMASK(31,12)
> +#define CTX_WA_TYPE_MASKREG_GENMASK(4,3)
> +#define CTX_WA_VALIDREG_BIT(0)
> +
> #define IPEIR_I965 _MMIO(0x2064)
> #define IPEHR_I965 _MMIO(0x2068)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
> b/drivers/gpu/drm/i915/gt/intel_rc6.c
> index 58bb1c55294c9..6baa341814da7 100644
> --- a/drivers/gpu/drm/i915/gt/intel_rc6.c
> +++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
> @@ -14,6 +14,7 @@
> #include "intel_gt.h"
> #include "intel_gt_pm.h"
> #include "intel_gt_regs.h"
> +#include "intel_gpu_commands.h"
> #include "intel_pcode.h"
> #include "intel_rc6.h"
>
> @@ -53,6 +54,65 @@ static struct drm_i915_private *rc6_to_i915(struct
> intel_rc6 *rc)
> return rc6_to_gt(rc)->i915;
> }
>
> +static int rc6_wa_bb_ctx_init(struct intel_rc6 *rc6)
> +{
> + struct drm_i915_private *i915 = rc6_to_i915(rc6);
> + struct intel_gt *gt = rc6_to_gt(rc6);
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + void *batch;
> + struct i915_gem_ww_ctx ww;
> + int err;
> +
> + obj = i915_gem_object_create_shmem(i915, PAGE_SIZE);
Should we be using i915_gem_object_create_internal() here? This is
something that's permanently pinned and we don't really need a swappable
storage, right?
> + if (IS_ERR(obj))
> + return PTR_ERR(obj);
> +
> + vma = i915_vma_instance(obj, >ggtt->vm, NULL);
> + if (IS_ERR(vma)){
> + err = PTR_ERR(vma);
> + goto err;
> + }
> + rc6->vma=vma;
Coding style isn't correct on this line.
> + i915_gem_ww_ctx_init(, true);
> +retry:
> + err = i915_gem_object_lock(obj, );
> + if (!err)
> + err = i915_ggtt_pin(rc6->vma, , 0, PIN_HIGH);
> + if (err)
> + goto err_ww_fini;
> +
> + batch = i915_gem_object_pin_map(obj, I915_MAP_WB);
> + if (IS_ERR(batch)) {
> + err = PTR_ERR(batch);
> + goto err_unpin;
> + }
> + rc6->rc6_wa_bb = batch;
> + return 0;
> +err_unpin:
> + if (err)
Isn't this redundant?
> + i915_vma_unpin(rc6->vma);
> +err_ww_fini:
> + if (err == -EDEADLK) {
> + err = i915_gem_ww_ctx_backoff();
> + if (!err)
> + goto retry;
> + }
> + i915_gem_ww_ctx_fini();
> +
> + if (err)
And isn't this redundant too?
> + i915_vma_put(rc6->vma);
> +err:
> + i915_gem_object_put(obj);
> + return err;
> +}
> +
> +void rc6_wa_bb_ctx_wa_fini(struct intel_rc6 *rc6)
> +{
> + i915_vma_unpin(rc6->vma);
> + i915_vma_put(rc6->vma);
Don't we need to put the object here too? Actually, can we use
i915_vma_unpin_and_release here?
Also, is this function ever called anywhere?
> +}
> +
> static void gen11_rc6_enable(struct intel_rc6 *rc6)
> {
> struct intel_gt *gt = rc6_to_gt(rc6);
> @@ -616,6 +676,9 @@ void intel_rc6_init(struct intel_rc6 *rc6)
> err = chv_rc6_init(rc6);
> else if (IS_VALLEYVIEW(i915))
> err = vlv_rc6_init(rc6);
> + else if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 0)) &&
> + (GRAPHICS_VER_FULL(i915) <= IP_VER(12, 70)))
This doesn't match the platforms that the commit message said it should
apply to.
Also, if we have complicated version checks for a workaround that's
spread
Re: [Intel-gfx] [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
Hi Jim
On Thu, Jul 13, 2023 at 10:36:23AM -0600, Jim Cromie wrote:
> We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
> __COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
> fail on this (and harder to avoid situations):
>
> DECLARE_FOO(); DECLARE_FOO();
>
> Its 2023, can we haz a no-fallback __UNIQUE_ID ?
Yeah, I fail to see how this fallback definition can actually be used
after commit 95207db8166a ("Remove Intel compiler support"); even before
that, it would be pretty unlikely since icc usage has not been visible
for a long time. The kernel only officially supports clang or GCC now,
so the definitions of __UNIQUE_ID() in include/linux/compiler-clang.h
and include/linux/compiler-gcc.h should always be used because of the
include in include/linux/compiler_types.h, right?
I think the correct clean up is to just hoist the definition of
__UNIQUE_ID() out of the individual compiler headers into the common one
here but...
> NOTE:
>
> This also changes __UNIQUE_ID_ to _kaUID_. Ive been getting
> lkp-reports of collisions on names which should be unique; this
> shouldnt happen on gcc & clang, but does on some older ones, on some
> platforms, on some allyes & rand-configs. Like this:
>
> mips64-linux-ld:
> drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
> multiple definition of `__UNIQUE_ID_ddebug_class_user405';
> drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
> first defined here
This problem cannot be addressed with this patch given the above
information, no? Seems like that might mean that __COUNTER__ has issues
in earlier compilers?
Cheers,
Nathan
> Like above, the collision reports appear to always be 3-digit
> counters, which look like line-numbers. Changing to _kaUID_ in this
> defn should make it more obvious (in *.i file) when a fallback has
> happened. To be clear, I havent seen it yet. Nor have I seen the
> multiple-defn problem above since adding this patch.
>
> Lets see what lkp-robot says about this.
>
> CC: Luc Van Oostenryck (maintainer:SPARSE
> CHECKER)
> CC: Nathan Chancellor (supporter:CLANG/LLVM BUILD SUPPORT)
> CC: Nick Desaulniers (supporter:CLANG/LLVM BUILD
> SUPPORT)
> CC: Tom Rix (reviewer:CLANG/LLVM BUILD SUPPORT)
> CC: linux-spa...@vger.kernel.org (open list:SPARSE CHECKER)
> CC: linux-ker...@vger.kernel.org (open list)
> CC: l...@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
> Signed-off-by: Jim Cromie
> ---
> include/linux/compiler.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index d7779a18b24f..677d6c47cd9e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f,
> int val,
> __asm__ ("" : "=r" (var) : "0" (var))
> #endif
>
> -/* Not-quite-unique ID. */
> +/* JFTI: to fix Not-quite-unique ID */
> #ifndef __UNIQUE_ID
> -# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
> +# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
> #endif
>
> /**
> --
> 2.41.0
>
Re: [Intel-gfx] [PATCH 0/2] eventfd: simplify signal helpers
On Thu, 13 Jul 2023 12:05:36 +0200 Christian Brauner wrote: > Hey everyone, > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > by removing the count argument which is effectively unused. We have a patch under review which does in fact make use of the signaling value: https://lore.kernel.org/all/20230630155936.3015595-1-...@semihalf.com/ Thanks, Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for eventfd: simplify signal helpers
== Series Details == Series: eventfd: simplify signal helpers URL : https://patchwork.freedesktop.org/series/120668/ State : success == Summary == CI Bug Log - changes from CI_DRM_13383 -> Patchwork_120668v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_120668v1 that come from known issues: ### IGT changes ### Issues hit * igt@core_auth@basic-auth: - bat-adlp-11:NOTRUN -> [ABORT][1] ([i915#4423] / [i915#8011]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-adlp-11/igt@core_a...@basic-auth.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-cfl-8700k: [PASS][2] -> [FAIL][3] ([i915#7940]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/fi-cfl-8700k/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@basic-rte: - fi-kbl-x1275: [PASS][4] -> [FAIL][5] ([i915#8843]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html - bat-adlp-9: [PASS][6] -> [ABORT][7] ([i915#7977] / [i915#8668]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-adlp-9/igt@i915_pm_...@basic-rte.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-adlp-9/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@requests: - bat-mtlp-6: [PASS][8] -> [DMESG-FAIL][9] ([i915#7269]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-mtlp-6/igt@i915_selftest@l...@requests.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][10] -> [ABORT][11] ([i915#4983] / [i915#7461] / [i915#8347] / [i915#8384]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-rpls-1/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-rpls-1/igt@i915_selftest@l...@reset.html - bat-rpls-2: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#8347]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-rpls-2/igt@i915_selftest@l...@reset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#7828]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-adlm-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#1845]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-adlm-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_pm_rpm@module-reload: - fi-skl-guc: [FAIL][16] ([i915#7940]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/fi-skl-guc/igt@i915_pm_...@module-reload.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/fi-skl-guc/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@execlists: - fi-kbl-soraka: [INCOMPLETE][18] ([i915#7156] / [i915#7913]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-6: [DMESG-FAIL][20] ([i915#7059]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@migrate: - bat-atsm-1: [DMESG-FAIL][22] ([i915#7699] / [i915#7913]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-atsm-1/igt@i915_selftest@l...@migrate.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120668v1/bat-atsm-1/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@workarounds: - bat-adlm-1: [INCOMPLETE][24] ([i915#4983] / [i915#7677]) -> [PASS][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13383/bat-adlm-1/igt@i915_selftest@l...@workarounds.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for eventfd: simplify signal helpers
== Series Details == Series: eventfd: simplify signal helpers URL : https://patchwork.freedesktop.org/series/120668/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for eventfd: simplify signal helpers
== Series Details == Series: eventfd: simplify signal helpers URL : https://patchwork.freedesktop.org/series/120668/ State : warning == Summary == Error: dim checkpatch failed aae8a1d97489 eventfd: simplify eventfd_signal() -:436: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (16, 32) #436: FILE: drivers/vhost/vhost.h:251: if ((vq)->error_ctx) \ + eventfd_signal((vq)->error_ctx);\ total: 0 errors, 1 warnings, 0 checks, 439 lines checked 6b3c28be92b7 eventfd: simplify eventfd_signal_mask() -:89: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #89: FILE: include/linux/eventfd.h:66: +static inline bool eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask) total: 0 errors, 1 warnings, 0 checks, 79 lines checked
Re: [Intel-gfx] [PATCH] Revert "drm/i915: use localized __diag_ignore_all() instead of per file"
On Tue, 11 Jul 2023, Gustavo Sousa wrote:
> Quoting Jani Nikula (2023-07-11 08:02:14-03:00)
>>This reverts commit 88e9664434c994e97a9f6f8cdd1535495c660cea.
>>
>>__diag_ignore_all() only works for GCC 8 or later.
>>
>>-Woverride-init (from -Wextra, enabled in i915 Makefile) combined with
>>CONFIG_WERROR=y or W=e breaks the build for older GCC.
>>
>>With i386_defconfig and x86_64_defconfig enabling CONFIG_WERROR=y by
>>default, we really need to roll back the change.
>>
>>An alternative would be to disable -Woverride-init in the Makefile for
>>GCC <8, but the revert seems like the safest bet now.
>
> Sounds good. We would keep it compatible with older compilers and still have
> the
> warning enabled on newer environments.
>
> Another alternative I thought about was to have separate files only for
> initializations of that type (i.e. that would need the warning disabled), but
> I
> guess we would need to expose a lot of symbols for that to work...
>
> Reviewed-by: Gustavo Sousa
Thanks, pushed to drm-intel-next.
BR,
Jani.
>
>>
>>Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8768
>>Reported-by: John Garry
>>References:
>>https://lore.kernel.org/r/ad2601c0-84bb-c574-3702-a83ff8faf...@oracle.com
>>References: https://lore.kernel.org/r/87wmzezns4@intel.com
>>Fixes: 88e9664434c9 ("drm/i915: use localized __diag_ignore_all() instead of
>>per file")
>>Cc: Gustavo Sousa
>>Cc: Joonas Lahtinen
>>Cc: Rodrigo Vivi
>>Cc: Tvrtko Ursulin
>>Signed-off-by: Jani Nikula
>>---
>> drivers/gpu/drm/i915/Makefile | 5 +
>> drivers/gpu/drm/i915/display/intel_display_device.c | 5 -
>> drivers/gpu/drm/i915/display/intel_fbdev.c | 5 -
>> drivers/gpu/drm/i915/i915_pci.c | 5 -
>> 4 files changed, 5 insertions(+), 15 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>>index 2be9dd960540..c5fc91cd58e7 100644
>>--- a/drivers/gpu/drm/i915/Makefile
>>+++ b/drivers/gpu/drm/i915/Makefile
>>@@ -23,6 +23,11 @@ subdir-ccflags-y += $(call cc-option,
>>-Wunused-but-set-variable)
>> subdir-ccflags-y += $(call cc-disable-warning, frame-address)
>> subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror
>>
>>+# Fine grained warnings disable
>>+CFLAGS_i915_pci.o = $(call cc-disable-warning, override-init)
>>+CFLAGS_display/intel_display_device.o = $(call cc-disable-warning,
>>override-init)
>>+CFLAGS_display/intel_fbdev.o = $(call cc-disable-warning, override-init)
>>+
>> subdir-ccflags-y += -I$(srctree)/$(src)
>>
>> # Please keep these build lists sorted!
>>diff --git a/drivers/gpu/drm/i915/display/intel_display_device.c
>>b/drivers/gpu/drm/i915/display/intel_display_device.c
>>index e4afa7334c82..8286e79522d1 100644
>>--- a/drivers/gpu/drm/i915/display/intel_display_device.c
>>+++ b/drivers/gpu/drm/i915/display/intel_display_device.c
>>@@ -16,9 +16,6 @@
>> #include "intel_display_reg_defs.h"
>> #include "intel_fbc.h"
>>
>>-__diag_push();
>>-__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
>>-
>> static const struct intel_display_device_info no_display = {};
>>
>> #define PIPE_A_OFFSET0x7
>>@@ -727,8 +724,6 @@ static const struct intel_display_device_info
>>xe_lpdp_display = {
>> BIT(PORT_TC1) | BIT(PORT_TC2) | BIT(PORT_TC3) |
>> BIT(PORT_TC4),
>> };
>>
>>-__diag_pop();
>>-
>> #undef INTEL_VGA_DEVICE
>> #undef INTEL_QUANTA_VGA_DEVICE
>> #define INTEL_VGA_DEVICE(id, info) { id, info }
>>diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
>>b/drivers/gpu/drm/i915/display/intel_fbdev.c
>>index 1cc0ddc6a310..80c3f88310db 100644
>>--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
>>+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
>>@@ -135,9 +135,6 @@ static int intel_fbdev_mmap(struct fb_info *info, struct
>>vm_area_struct *vma)
>> return i915_gem_fb_mmap(obj, vma);
>> }
>>
>>-__diag_push();
>>-__diag_ignore_all("-Woverride-init", "Allow overriding the default ops");
>>-
>> static const struct fb_ops intelfb_ops = {
>> .owner = THIS_MODULE,
>> __FB_DEFAULT_DEFERRED_OPS_RDWR(intel_fbdev),
>>@@ -149,8 +146,6 @@ static const struct fb_ops intelfb_ops = {
>> .fb_mmap = intel_fbdev_mmap,
>> };
>>
>>-__diag_pop();
>>-
>> static int intelfb_alloc(struct drm_fb_helper *helper,
>> struct drm_fb_helper_surface_size *sizes)
>> {
>>diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
>>index dea3609fc496..fcacdc21643c 100644
>>--- a/drivers/gpu/drm/i915/i915_pci.c
>>+++ b/drivers/gpu/drm/i915/i915_pci.c
>>@@ -38,9 +38,6 @@
>> #include "i915_reg.h"
>> #include "intel_pci_config.h"
>>
>>-__diag_push();
>>-__diag_ignore_all("-Woverride-init", "Allow overriding inherited members");
>>-
>> #define PLATFORM(x) .platform = (x)
>> #define GEN(x) \
>> .__runtime.graphics.ip.ver = (x), \
>>@@ -846,8 +843,6 @@ static const struct intel_device_info mtl_info = {
>>
>> #undef
[Intel-gfx] [PATCH v4 20/21] config TEST_DYNAMIC_DEBUG default m
Signed-off-by: Jim Cromie --- lib/Kconfig.debug | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index d4fbbcc395d2..82d11ac63758 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2696,13 +2696,14 @@ config TEST_STATIC_KEYS config TEST_DYNAMIC_DEBUG tristate "Build test-dynamic-debug module" + default m depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE help This module works/demo's the dyndbg's classmap API, by creating 2 classes: a DISJOINT classmap (like DRM.debug) and a LEVELS/VERBOSE classmap (where 2>1). - If unsure, say N. + If unsure, say N. If bored/curious, say M config TEST_KMOD tristate "kmod stress tester" -- 2.41.0
[Intel-gfx] [PATCH v4 19/21] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c
files. For drivers, add the decl just above the module's PARAMs,
since it identifies the "inherited" drm.debug param.
Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring
DRM_CLASSMAP_USE will have its class'd prdbgs stuck in the initial
(disabled, but for DEBUG) state.
The stuck sites are evident in /proc/dynamic_debug/control as:
class unknown, _id:N # control's last column
rather than a proper "enumeration":
class:DRM_UT_CORE
This set of updates was found by choosing M for all DRM-config items I
found (not allmodconfig), building & modprobing them, and grepping
"class unknown," control. There may yet be others.
NOTE:
As HEAD~1 describes then hacks out, __UNIQUE_ID macro in compiler.h is
still stuck using __LINE__ fallback instead of actual unique
__COUNTER__.
Without HEAD~1, the placement of the DRM_CLASSMAP_USE decls was prone
to this collision, as reported by @lkp-robot in several allyes configs
(s390,arm-mumble) for both gcc & clang.
Moving decls around fixed each, and more popped up, it felt like
whack-a-mole. Time to just test the toolchain everywhere.
Reported-by: kernel test robot
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 ++
drivers/gpu/drm/gud/gud_drv.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 ++
drivers/gpu/drm/qxl/qxl_drv.c | 2 ++
drivers/gpu/drm/radeon/radeon_drv.c| 2 ++
drivers/gpu/drm/udl/udl_main.c | 2 ++
drivers/gpu/drm/vkms/vkms_drv.c| 2 ++
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 2 ++
8 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 4ea6507a77e5..5e02df98327b 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -23,6 +23,8 @@
#include
#include
+DRM_CLASSMAP_USE(drm_debug_classes);
+
MODULE_IMPORT_NS(DMA_BUF);
/**
diff --git a/drivers/gpu/drm/gud/gud_drv.c b/drivers/gpu/drm/gud/gud_drv.c
index 9d7bf8ee45f1..5b555045fce4 100644
--- a/drivers/gpu/drm/gud/gud_drv.c
+++ b/drivers/gpu/drm/gud/gud_drv.c
@@ -31,6 +31,8 @@
#include "gud_internal.h"
+DRM_CLASSMAP_USE(drm_debug_classes);
+
/* Only used internally */
static const struct drm_format_info gud_drm_format_r1 = {
.format = GUD_DRM_FORMAT_R1,
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 976f0ab2006b..a1b2be1c27f6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -24,6 +24,8 @@ int mgag200_modeset = -1;
MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
module_param_named(modeset, mgag200_modeset, int, 0400);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
int mgag200_init_pci_options(struct pci_dev *pdev, u32 option, u32 option2)
{
struct device *dev = >dev;
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index a3b83f89e061..12600f557c23 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -65,6 +65,8 @@ module_param_named(modeset, qxl_modeset, int, 0400);
MODULE_PARM_DESC(num_heads, "Number of virtual crtcs to expose (default 4)");
module_param_named(num_heads, qxl_num_crtc, int, 0400);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static struct drm_driver qxl_driver;
static struct pci_driver qxl_pci_driver;
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index e4374814f0ef..4219276ade6a 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -274,6 +274,8 @@ int radeon_cik_support = 1;
MODULE_PARM_DESC(cik_support, "CIK support (1 = enabled (default), 0 =
disabled)");
module_param_named(cik_support, radeon_cik_support, int, 0444);
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static struct pci_device_id pciidlist[] = {
radeon_PCI_IDS
};
diff --git a/drivers/gpu/drm/udl/udl_main.c b/drivers/gpu/drm/udl/udl_main.c
index 061cb88c08a2..8f9dfe89f64a 100644
--- a/drivers/gpu/drm/udl/udl_main.c
+++ b/drivers/gpu/drm/udl/udl_main.c
@@ -19,6 +19,8 @@
#define NR_USB_REQUEST_CHANNEL 0x12
+DRM_CLASSMAP_USE(drm_debug_classes);
+
#define MAX_TRANSFER (PAGE_SIZE*16 - BULK_SIZE)
#define WRITES_IN_FLIGHT (20)
#define MAX_VENDOR_DESCRIPTOR_SIZE 256
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 6d3a2d57d992..086a9933fcdf 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -39,6 +39,8 @@
static struct vkms_config *default_config;
+DRM_CLASSMAP_USE(drm_debug_classes);
+
static bool enable_cursor = true;
module_param_named(enable_cursor, enable_cursor, bool, 0444);
MODULE_PARM_DESC(enable_cursor, "Enable/Disable cursor support");
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8b24ecf60e3e..9cb6be422621 100644
---
[Intel-gfx] [PATCH v4 21/21] dyndbg-doc: add classmap info to howto
Add some basic info on classmap usage and api Signed-off-by: Jim Cromie --- .../admin-guide/dynamic-debug-howto.rst | 64 ++- 1 file changed, 63 insertions(+), 1 deletion(-) diff --git a/Documentation/admin-guide/dynamic-debug-howto.rst b/Documentation/admin-guide/dynamic-debug-howto.rst index 8dc668cc1216..878750ce8c1d 100644 --- a/Documentation/admin-guide/dynamic-debug-howto.rst +++ b/Documentation/admin-guide/dynamic-debug-howto.rst @@ -224,7 +224,6 @@ the ``p`` flag has meaning, other flags are ignored. Note the regexp ``^[-+=][flmpt_]+$`` matches a flags specification. To clear all flags at once, use ``=_`` or ``-flmpt``. - Debug messages during Boot Process == @@ -374,3 +373,66 @@ just a shortcut for ``print_hex_dump(KERN_DEBUG)``. For ``print_hex_dump_debug()``/``print_hex_dump_bytes()``, format string is its ``prefix_str`` argument, if it is constant string; or ``hexdump`` in case ``prefix_str`` is built dynamically. + +Dynamic Debug classmaps +=== + +Dyndbg generally selects *prdbg* callsites using structural info: +module, file, function, line. Using classmaps, user modules can +organize/select pr_debug()s as they like. + +- classes coordinates/spans multiple modules +- complements the mod,file,func attrs +- keeps pr_debug's 0-off-cost JUMP_LABEL goodness +- isolates from other class'd and un-class'd pr_debugs() + (one doesnt mix 2 clients bank accounts) + + # IOW this doesn't change DRM.debug settings + #> echo -p > /proc/dynamic_debug/control + + # change the classes by naming them explicitly (no wildcard here) + #> echo class DRM_UT_CORE +p > /proc/dynamic_debug/control + +To support DRM.debug (/sys/module/drm/parameters/debug), dyndbg +provides DYNDBG_CLASSMAP_PARAM*. It maps the categories/classes: +DRM_UT_CORE.. to bits 0..N, allowing to set all classes at once. + +Dynamic Debug Classmap API +== + +DYNDBG_CLASSMAP_DEFINE - modules create CLASSMAPs, naming the classes +and type, and mapping the class-names to consecutive _class_ids. By +doing so, they tell dyndbg that they are using those class_ids, and +authorize dyndbg to manipulate the callsites by their class-names. + +Its expected that client modules will follow the DRM.debug model: +1. define their debug-classes using an enum type, where the enum +symbol and its integer value define both the classnames and class-ids. +2. use or macro-wrap __pr_debug_cls(ENUM_VAL, "hello world\n") + +There are 2 types of classmaps: + + DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, ala DRM.debug + DD_CLASS_TYPE_LEVEL_NUM: classes are relative (Verbose3 > Verbose2) + +Both these classmap-types use the class-names/ENUM_VALs to validate +commands into >control. + +DYNDBG_CLASSMAP_PARAM - refs a DEFINEd classmap, exposing the set of +defined classes to manipulation as a group. This interface enforces +the relatedness of classes of DD_CLASS_TYPE_LEVEL_NUM typed classmaps; +all classes are independent in the >control parser itself. + +DYNDBG_CLASSMAP_USE - drm drivers use the CLASSMAP that drm DEFINEs. +This shares the classmap defn, and authorizes coordinated changes +amongst the CLASSMAP DEFINEr and multiple USErs. + +Modules or module-groups (drm & drivers) can define multiple +classmaps, as long as they share the limited 0..62 per-module-group +_class_id range, without overlap. + +``#define DEBUG`` will enable all pr_debugs in scope, including any +class'd ones (__pr_debug_cls(id,fmt..)). This won't be reflected in +the PARAM readback value, but the pr_debug callsites can be toggled +into agreement with the param. + -- 2.41.0
[Intel-gfx] [PATCH v4 18/21] compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
We currently have 3 defns for __UNIQUE_ID(); gcc and clang are using
__COUNTER__ for real uniqueness, 3rd just uses __LINE__, which should
fail on this (and harder to avoid situations):
DECLARE_FOO(); DECLARE_FOO();
Its 2023, can we haz a no-fallback __UNIQUE_ID ?
NOTE:
This also changes __UNIQUE_ID_ to _kaUID_. Ive been getting
lkp-reports of collisions on names which should be unique; this
shouldnt happen on gcc & clang, but does on some older ones, on some
platforms, on some allyes & rand-configs. Like this:
mips64-linux-ld:
drivers/gpu/drm/display/drm_dp_helper.o:(__dyndbg_class_users+0x0):
multiple definition of `__UNIQUE_ID_ddebug_class_user405';
drivers/gpu/drm/drm_gem_shmem_helper.o:(__dyndbg_class_users+0x0):
first defined here
Like above, the collision reports appear to always be 3-digit
counters, which look like line-numbers. Changing to _kaUID_ in this
defn should make it more obvious (in *.i file) when a fallback has
happened. To be clear, I havent seen it yet. Nor have I seen the
multiple-defn problem above since adding this patch.
Lets see what lkp-robot says about this.
CC: Luc Van Oostenryck (maintainer:SPARSE CHECKER)
CC: Nathan Chancellor (supporter:CLANG/LLVM BUILD SUPPORT)
CC: Nick Desaulniers (supporter:CLANG/LLVM BUILD
SUPPORT)
CC: Tom Rix (reviewer:CLANG/LLVM BUILD SUPPORT)
CC: linux-spa...@vger.kernel.org (open list:SPARSE CHECKER)
CC: linux-ker...@vger.kernel.org (open list)
CC: l...@lists.linux.dev (open list:CLANG/LLVM BUILD SUPPORT)
Signed-off-by: Jim Cromie
---
include/linux/compiler.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index d7779a18b24f..677d6c47cd9e 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -177,9 +177,9 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int
val,
__asm__ ("" : "=r" (var) : "0" (var))
#endif
-/* Not-quite-unique ID. */
+/* JFTI: to fix Not-quite-unique ID */
#ifndef __UNIQUE_ID
-# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__)
+# define __UNIQUE_ID(prefix) __PASTE(__PASTE(_kaUID_, prefix), __COUNTER__)
#endif
/**
--
2.41.0
[Intel-gfx] [PATCH v4 17/21] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
Lots of burn-in testing needed before signing, upstreaming. I set default Y to maximize testing by default. NOTE: without __UNIQUE_ID fix in HEAD~1, this population of DRM_CLASSMAP_USE()rs experienced name collisions in several different @lkp-robot allyes and randconfigs, probably because the macro is always a file-scope declarator, and is always near the top of fhe file. Moving declarations around tended to fix one collision, only to create another collision elsewhere. Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ba3fb04bb691..ff478fcba67e 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -52,8 +52,7 @@ config DRM_DEBUG_MM config DRM_USE_DYNAMIC_DEBUG bool "use dynamic debug to implement drm.debug" - default n - depends on BROKEN + default y depends on DRM depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE depends on JUMP_LABEL -- 2.41.0
[Intel-gfx] [PATCH v4 16/21] dyndbg-test: make it build with just CONFIG_DYNAMIC_DEBUG_CORE
To make the 2 test modules buildable with CONFIG_DYNAMIC_DEBUG_CORE, add CFLAGS_$ofile defns to supply -DDYNAMIC_DEBUG_MODULE to cc. And change the Kconfig entry to allow building with just _CORE. Signed-off-by: Jim Cromie --- lib/Kconfig.debug | 10 +- lib/Makefile | 2 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index ce51d4dc6803..d4fbbcc395d2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -2695,12 +2695,12 @@ config TEST_STATIC_KEYS If unsure, say N. config TEST_DYNAMIC_DEBUG - tristate "Test DYNAMIC_DEBUG" - depends on DYNAMIC_DEBUG + tristate "Build test-dynamic-debug module" + depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE help - This module registers a tracer callback to count enabled - pr_debugs in a 'do_debugging' function, then alters their - enablements, calls the function, and compares counts. + This module works/demo's the dyndbg's classmap API, by + creating 2 classes: a DISJOINT classmap (like DRM.debug) + and a LEVELS/VERBOSE classmap (where 2>1). If unsure, say N. diff --git a/lib/Makefile b/lib/Makefile index f36048371dd2..8411015a57c1 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -233,6 +233,8 @@ obj-$(CONFIG_HAVE_ARCH_TRACEHOOK) += syscall.o obj-$(CONFIG_DYNAMIC_DEBUG_CORE) += dynamic_debug.o #ensure exported functions have prototypes CFLAGS_dynamic_debug.o := -DDYNAMIC_DEBUG_MODULE +CFLAGS_test_dynamic_debug.o := -DDYNAMIC_DEBUG_MODULE +CFLAGS_test_dynamic_debug_submod.o := -DDYNAMIC_DEBUG_MODULE obj-$(CONFIG_SYMBOLIC_ERRNAME) += errname.o -- 2.41.0
[Intel-gfx] [PATCH v4 15/21] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
move macro from test-dynamic-debug.c into header, and refine it.
Distinguish the 2 use cases of DYNDBG_CLASSMAP_PARAM*
1.DYNDBG_CLASSMAP_PARAM_REF
for DRM, to pass in extern __drm_debug by name.
dyndbg keeps bits in it, so drm can still use it as before/remaining.
2.DYNDBG_CLASSMAP_PARAM
new user (test_dynamic_debug) doesnt need to share state,
decls,inits a static long unsigned int to store the bitvec.
__DYNDBG_CLASSMAP_PARAM
bottom layer - allocate,init a ddebug-class-param, module-param-cb.
1. doesnt initialize bits properly.
macro seems to lose type of previously decl'd extern,
then whines about type mistmatch
punt now - following commit trys to fix it, draws warning.
2. init seems to work
maybe masked by sync-bits
not validated
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/drm_print.c | 8 ++-
include/drm/drm_print.h | 6 --
include/linux/dynamic_debug.h | 39 +--
lib/test_dynamic_debug.c | 22 +++-
4 files changed, 46 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index dabcfa0dd279..8f4b609353a5 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -69,12 +69,8 @@ DRM_CLASSMAP_DEFINE(drm_debug_classes,
DD_CLASS_TYPE_DISJOINT_BITS,
"DRM_UT_DP",
"DRM_UT_DRMRES");
-static struct ddebug_class_param drm_debug_bitmap = {
- .bits = &__drm_debug,
- .flags = "p",
- .map = _debug_classes,
-};
-module_param_cb(debug, _ops_dyndbg_classes, _debug_bitmap, 0600);
+DRM_CLASSMAP_PARAM_REF(debug, __drm_debug, drm_debug_classes, p);
+
#endif
void __drm_puts_coredump(struct drm_printer *p, const char *str)
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 706afc97c79c..94d4f5500030 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -322,11 +322,13 @@ enum drm_debug_category {
};
#ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG
-#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
-#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_DEFINE(...) DYNDBG_CLASSMAP_DEFINE(__VA_ARGS__)
+#define DRM_CLASSMAP_USE(name) DYNDBG_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)DYNDBG_CLASSMAP_PARAM_REF(__VA_ARGS__)
#else
#define DRM_CLASSMAP_DEFINE(...)
#define DRM_CLASSMAP_USE(name)
+#define DRM_CLASSMAP_PARAM_REF(...)
#endif
static inline bool drm_debug_enabled_raw(enum drm_debug_category category)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 2604fda3abe3..95a6b3882b76 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -90,7 +90,7 @@ struct ddebug_class_map {
* module, and to validate inputs to DD_CLASS_TYPE_*_NAMES typed params.
*/
#define DYNDBG_CLASSMAP_DEFINE(_var, _maptype, _base, ...) \
- const char *_var##_classnames[] = { __VA_ARGS__ }; \
+ static const char *_var##_classnames[] = { __VA_ARGS__ }; \
struct ddebug_class_map __aligned(8) __used \
__section("__dyndbg_classes") _var = { \
.mod = THIS_MODULE, \
@@ -118,7 +118,7 @@ struct ddebug_class_user {
DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user))
#define DYNDBG_CLASSMAP_USE_(_var, _uname) \
extern struct ddebug_class_map _var;\
- struct ddebug_class_user __used \
+ static struct ddebug_class_user __used \
__section("__dyndbg_class_users") _uname = {\
.user_mod_name = KBUILD_MODNAME,\
.map = &_var, \
@@ -143,6 +143,41 @@ struct ddebug_class_param {
const struct ddebug_class_map *map;
};
+/**
+ * DYNDBG_CLASSMAP_PARAM - wrap a dyndbg-classmap with a controlling sys-param
+ * @_name sysfs node name
+ * @_var name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to control the classes defined by the
+ * classmap. Keeps bits in a private/static
+ */
+#define DYNDBG_CLASSMAP_PARAM(_name, _var, _flags) \
+ static unsigned long _name##_bvec; \
+ __DYNDBG_CLASSMAP_PARAM(_name, _name##_bvec, _var, _flags)
+
+/**
+ * DYNDBG_CLASSMAP_PARAM_REF - wrap a dyndbg-classmap with a controlling
sys-param
+ * @_name sysfs node name
+ * @_bits name of the module's unsigned long bit-vector, ex: __drm_debug
+ * @_var name of the struct classmap var defining the controlled classes
+ * @_flags flags to be toggled, typically just 'p'
+ *
+ * Creates a sysfs-param to
[Intel-gfx] [PATCH v4 14/21] dyndbg: refactor ddebug_classparam_clamp_input
Extract input validation code, from param_set_dyndbg_module_classes()
(the sys-node >handler) to new: ddebug_classparam_clamp_input(kp),
call it from former. It takes kernel-param arg, so it can complain
about "foo: bad input".
Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(),
to validate inputs from parent's params, just like our own.
To support that reuse, alter ddebug_sync_classbits() and caller to
pass kp instead of kp->arg.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 66 ++---
1 file changed, 45 insertions(+), 21 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 8e7bf5e9388b..4743ac2972b1 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -649,6 +649,30 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
#define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
+static void ddebug_class_param_clamp_input(unsigned long *inrep, const struct
kernel_param *kp)
+{
+ const struct ddebug_class_param *dcp = kp->arg;
+ const struct ddebug_class_map *map = dcp->map;
+
+ switch (map->map_type) {
+ case DD_CLASS_TYPE_DISJOINT_BITS:
+ /* expect bits. mask and warn if too many */
+ if (*inrep & ~CLASSMAP_BITMASK(map->length)) {
+ pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx,
masking\n",
+ KP_NAME(kp), *inrep,
CLASSMAP_BITMASK(map->length));
+ *inrep &= CLASSMAP_BITMASK(map->length);
+ }
+ break;
+ case DD_CLASS_TYPE_LEVEL_NUM:
+ /* input is bitpos, of highest verbosity to be enabled */
+ if (*inrep > map->length) {
+ pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
+ KP_NAME(kp), *inrep, map->length);
+ *inrep = map->length;
+ }
+ break;
+ }
+}
static int param_set_dyndbg_module_classes(const char *instr,
const struct kernel_param *kp,
const char *modnm)
@@ -668,26 +692,15 @@ static int param_set_dyndbg_module_classes(const char
*instr,
pr_err("expecting numeric input, not: %s > %s\n", instr,
KP_NAME(kp));
return -EINVAL;
}
+ ddebug_class_param_clamp_input(, kp);
switch (map->map_type) {
case DD_CLASS_TYPE_DISJOINT_BITS:
- /* expect bits. mask and warn if too many */
- if (inrep & ~CLASSMAP_BITMASK(map->length)) {
- pr_warn("%s: input: 0x%lx exceeds mask: 0x%lx,
masking\n",
- KP_NAME(kp), inrep,
CLASSMAP_BITMASK(map->length));
- inrep &= CLASSMAP_BITMASK(map->length);
- }
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
- /* input is bitpos, of highest verbosity to be enabled */
- if (inrep > map->length) {
- pr_warn("%s: level:%ld exceeds max:%d, clamping\n",
- KP_NAME(kp), inrep, map->length);
- inrep = map->length;
- }
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
@@ -1147,16 +1160,27 @@ static const char* ddebug_classmap_typenames[] = {
v2pr_info(_msg " module:%s base:%d len:%d type:%s\n", ##__VA_ARGS__, \
cm->mod_name, cm->base, cm->length,
ddebug_classmap_typenames[cm->map_type])
-static void ddebug_sync_classbits(const struct ddebug_class_param *dcp, const
char *modname)
+static void ddebug_sync_classbits(const struct kernel_param *kp, const char
*modname)
{
- /* clamp initial bitvec, mask off hi-bits */
- if (*dcp->bits & ~CLASSMAP_BITMASK(dcp->map->length)) {
- *dcp->bits &= CLASSMAP_BITMASK(dcp->map->length);
- v2pr_info("preset classbits: %lx\n", *dcp->bits);
+ struct ddebug_class_param *dcp = kp->arg;
+ unsigned long new_bits;
+
+ ddebug_class_param_clamp_input(dcp->bits, kp);
+
+ switch (dcp->map->map_type) {
+ case DD_CLASS_TYPE_DISJOINT_BITS:
+ v2pr_info("%s: classbits: 0x%lx\n", KP_NAME(kp), *dcp->bits);
+ ddebug_apply_class_bitmap(dcp, dcp->bits, 0UL, modname);
+ break;
+ case DD_CLASS_TYPE_LEVEL_NUM:
+ new_bits = CLASSMAP_BITMASK(*dcp->lvl);
+ v2pr_info("%s: lvl:%ld bits:0x%lx \n", KP_NAME(kp), *dcp->lvl,
new_bits);
+ ddebug_apply_class_bitmap(dcp,
[Intel-gfx] [PATCH v4 13/21] dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP & CONFIG_DRM_USE_DYNAMIC_DEBUG
DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K
rule: "define once, refer many times".
When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across
DRM core & drivers; they all repeat the same classmap-defn args, which
must match for the modules to respond together when DRM.debug
categories are enabled.
Worse, it causes the CONFIG_DRM_USE_DYNAMIC_DEBUG=Y regression;
1st drm.ko loads, and dyndbg initializes its DRM.debug callsites, then
a drm-driver loads, but too late - it missed the DRM.debug enablement.
So replace it with 2 macros that make the distinction:
DYNDBG_CLASSMAP_DEFINE - invoked once from core - drm.ko
DYNDBG_CLASSMAP_USE- from all drm drivers and helpers.
DYNDBG_CLASSMAP_DEFINE: based on DECLARE_DYNDBG_CLASSMAP, but now it
drops the static on the constructed classmap variable, and exports it
instead.
DYNDBG_CLASSMAP_USE: then refers to the exported var by name:
* used from drivers, helper-mods
* lets us drop the repetitive "classname" args
* fixes 2nd-defn problem
* creates a ddebug_class_user record in new __dyndbg_class_refs section
this allows ddebug_add_module(etal) to handle them per-module.
The distinction, and the usage record, allows dyndbg to initialize the
driver's DRM.debug callsites separately after it is modprobed.
Since DRM now needs updates to use the new macros, it also gets 2
wrappers: DRM_CLASSMAP_DEFINE, DRM_CLASSMAP_USE which declutter the
users by hiding the ifdef CONFIG_DRM_USE_DYNAMIC_DEBUG.
To review, dyndbg's existing __dyndbg_classes[] section does:
. catalogs the classmaps defined by the module (or builtin modules)
. authorizes dyndbg to >control those class'd prdbgs for the module.
. DYNDBG_CLASSMAP_DEFINE(and old one) creates classmaps in this section.
This patch adds __dyndbg_class_users[] section:
. catalogs uses/references to the classmap definitions.
. authorizes dyndbg to >control those class'd prdbgs in ref'g module.
. DYNDBG_CLASSMAP_USE() creates classmap-user records in this section.
Now ddebug_add_module(etal) can handle classmap-uses like (and after)
classmaps; when a dependent module is loaded, its parent's kernel
params are scanned to find the param wired to dyndbg-param-ops, whose
classmap matches the one ref'd by the client.
To support this, a few data/header changes:
. new struct ddebug_class_user
contains: user-module-name,
it records drm-driver's use of a classmap in the section, allowing lookup
struct ddebug_info gets 2 new fields to encapsulate the new section:
class_users, num_class_users.
set by dynamic_debug_init() for builtins.
or by kernel/module/main:load_info() for loadable modules.
vmlinux.lds.h: new BOUNDED_SECTION for __dyndbg_class_users
dynamic_debug.c has changes in 2 areas: ddebug_add_module(), ddebug_change().
ddebug_add_module() previously called ddebug_attach_module_classes()
to handle classmap DEFINEd by a module, now it also calls
ddebug_attach_client_module_classes() to handle USEd classmaps.
ddebug_attach_client_module_classes() scans the client module's
class_users section, follows the refs to the parent's classmap,
and calls ddebug_apply_params() on each.
ddebug_apply_params(new fn):
It scans module's/builtin kernel-params, calls ddebug_match_attach_kparam
for each to find the params/sysfs-nodes which may be wired to a classmap.
ddebug_match_apply_kparam(new fn):
1st, it tests the kernel-param.ops is dyndbg's; this guarantees that
the attached arg is a struct ddebug_class_param, which has a ref to
the param's state, and to the classmap defining the param's handling.
2nd, it requires that the classmap ref'd by the kparam is the one
we're called for; modules can use many separate classmaps (as
test_dynamic_debug does).
Then apply the "parent" kparam's setting to the dependent module,
using ddebug_apply_class_bitmap().
ddebug_change(and callees) also gets adjustments:
ddebug_find_valid_class(): This does a search over the module's
classmaps, looking for the class FOO echo'd to >control. So now it
searches over __dyndbg_class_users[] after __dyndbg_classes[].
ddebug_class_name(): return class-names for defined AND used classes.
test_dynamic_debug.c, test_dynamic_debug_submod.c:
This (already) demonstrates the 2 types of classmaps & sysfs-params,
following the 4-part recipe:
1. define an enum for the classmap: DRM.debug has DRM_UT_{CORE,KMS,...}
multiple classes must share 0-62 classid space.
2. DYNDBG_CLASSMAP_DEFINE(.. DRM_UT_{CORE,KMS,...})
3. DYNDBG_CLASSMAP_PARAM* (classmap)
4. DYNDBG_CLASSMAP_USE()
by _submod only, skipping 2,3
Move all the enum declarations together, to better explain how they
share the 0..62 class-id space available to a module (non-overlapping
subranges).
reorg macros 2,3 by name. This gives a tabular format, making it easy
to see the pattern of repetition, and the points of change.
And extend the test to replicate the 2-module (parent & dependent)
scenario which caused the CONFIG_DRM_USE_DYNAMIC_DEBUG=y
[Intel-gfx] [PATCH v4 12/21] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
Remove the NAMED class types; these 2 classmap types accept class
names at the PARAM interface, for example:
echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names
The code works, but its only used by test-dynamic-debug, and wasn't
asked for by anyone else, so simplify things for now.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 19 ++-
lib/dynamic_debug.c | 104 +++---
lib/test_dynamic_debug.c | 12
3 files changed, 13 insertions(+), 122 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 719c5b6ad0f9..b927dfacc429 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -59,24 +59,13 @@ struct _ddebug {
enum class_map_type {
DD_CLASS_TYPE_DISJOINT_BITS,
/**
-* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, one per bit.
-* expecting hex input. Built for drm.debug, basis for other types.
+* DD_CLASS_TYPE_DISJOINT_BITS: classes are independent, mapped to
bits[0..N].
+* Expects hex input. Built for drm.debug, basis for other types.
*/
DD_CLASS_TYPE_LEVEL_NUM,
/**
-* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0-N.
-* N turns on just bits N-1 .. 0, so N=0 turns all bits off.
-*/
- DD_CLASS_TYPE_DISJOINT_NAMES,
- /**
-* DD_CLASS_TYPE_DISJOINT_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* classes are independent, like _DISJOINT_BITS.
-*/
- DD_CLASS_TYPE_LEVEL_NAMES,
- /**
-* DD_CLASS_TYPE_LEVEL_NAMES: input is a CSV of [+-]CLASS_NAMES,
-* intended for names like: INFO,DEBUG,TRACE, with a module prefix
-* avoid EMERG,ALERT,CRIT,ERR,WARNING: they're not debug
+* DD_CLASS_TYPE_LEVEL_NUM: input is numeric level, 0..N.
+* Input N turns on bits 0..N-1
*/
};
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index abdb54e3ddfa..7c7a87fada74 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -631,77 +631,6 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
#define CLASSMAP_BITMASK(width) ((1UL << (width)) - 1)
-/* accept comma-separated-list of [+-] classnames */
-static int param_set_dyndbg_classnames(const char *instr, const struct
kernel_param *kp)
-{
- const struct ddebug_class_param *dcp = kp->arg;
- const struct ddebug_class_map *map = dcp->map;
- unsigned long curr_bits, old_bits;
- char *cl_str, *p, *tmp;
- int cls_id, totct = 0;
- bool wanted;
-
- cl_str = tmp = kstrdup(instr, GFP_KERNEL);
- p = strchr(cl_str, '\n');
- if (p)
- *p = '\0';
-
- /* start with previously set state-bits, then modify */
- curr_bits = old_bits = *dcp->bits;
- vpr_info("\"%s\" > %s:0x%lx\n", cl_str, KP_NAME(kp), curr_bits);
-
- for (; cl_str; cl_str = p) {
- p = strchr(cl_str, ',');
- if (p)
- *p++ = '\0';
-
- if (*cl_str == '-') {
- wanted = false;
- cl_str++;
- } else {
- wanted = true;
- if (*cl_str == '+')
- cl_str++;
- }
- cls_id = match_string(map->class_names, map->length, cl_str);
- if (cls_id < 0) {
- pr_err("%s unknown to %s\n", cl_str, KP_NAME(kp));
- continue;
- }
-
- /* have one or more valid class_ids of one *_NAMES type */
- switch (map->map_type) {
- case DD_CLASS_TYPE_DISJOINT_NAMES:
- /* the +/- pertains to a single bit */
- if (test_bit(cls_id, _bits) == wanted) {
- v3pr_info("no change on %s\n", cl_str);
- continue;
- }
- curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
*dcp->bits, NULL);
- *dcp->bits = curr_bits;
- v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
- map->class_names[cls_id]);
- break;
- case DD_CLASS_TYPE_LEVEL_NAMES:
- /* cls_id = N in 0..max. wanted +/- determines N or N-1
*/
- old_bits = CLASSMAP_BITMASK(*dcp->lvl);
- curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
-
- totct += ddebug_apply_class_bitmap(dcp, _bits,
old_bits, NULL);
- *dcp->lvl = (cls_id + (wanted ? 1 : 0));
- v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
-
[Intel-gfx] [PATCH v4 11/21] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
old_bits arg is currently a pointer to the input bits, but this could
allow inadvertent changes to the input by the fn. Disallow this.
And constify new_bits while here.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index f392f692b452..abdb54e3ddfa 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -592,7 +592,8 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new class-param setting */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits,
+const unsigned long *new_bits,
+const unsigned long old_bits,
const char *query_modname)
{
#define QUERY_SIZE 128
@@ -601,12 +602,12 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- if (*new_bits != *old_bits)
+ if (*new_bits != old_bits)
v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
for (bi = 0; bi < map->length; bi++) {
- if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
+ if (test_bit(bi, new_bits) == test_bit(bi, _bits))
continue;
snprintf(query, QUERY_SIZE, "class %s %c%s",
map->class_names[bi],
@@ -618,9 +619,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
- if (*new_bits != *old_bits)
+ if (*new_bits != old_bits)
v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
- *old_bits, query_modname ?: "'*'");
+ old_bits, query_modname ?: "'*'");
return matches;
}
@@ -677,7 +678,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits, NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
*dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
map->class_names[cls_id]);
@@ -687,7 +688,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
- totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits, NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
old_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
map->class_names[cls_id], old_bits,
curr_bits);
@@ -741,7 +742,7 @@ static int param_set_dyndbg_module_classes(const char
*instr,
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
modnm);
+ totct += ddebug_apply_class_bitmap(dcp, , *dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -754,7 +755,7 @@ static int param_set_dyndbg_module_classes(const char
*instr,
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
modnm);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, old_bits,
modnm);
*dcp->lvl = inrep;
break;
default:
--
2.41.0
[Intel-gfx] [PATCH v4 09/21] dyndbg: silence debugs with no-change updates
check for actual changes before announcing them, declutter logs.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 2a5cbb68d88d..a8973d1a6896 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -590,7 +590,7 @@ static int ddebug_exec_queries(char *query, const char
*modname)
return nfound;
}
-/* apply a new bitmap to the sys-knob's current bit-state */
+/* apply a new class-param setting */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
unsigned long *new_bits, unsigned long
*old_bits,
const char *query_modname)
@@ -601,8 +601,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
- query_modname ?: "");
+ if (*new_bits != *old_bits)
+ v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -617,8 +618,9 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
- v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
- query_modname ?: "");
+ if (*new_bits != *old_bits)
+ v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
+ *old_bits, query_modname ?: "'*'");
return matches;
}
--
2.41.0
[Intel-gfx] [PATCH v4 10/21] dyndbg: tighten ddebug_class_name() 1st arg type
Change function's 1st arg-type, and deref in the caller.
The fn doesn't need any other fields in the struct.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index a8973d1a6896..f392f692b452 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -1112,12 +1112,12 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
#define class_in_range(class_id, map) \
(class_id >= map->base && class_id < map->base + map->length)
-static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
+static const char *ddebug_class_name(struct ddebug_table *dt, struct _ddebug
*dp)
{
- struct ddebug_class_map *map = iter->table->classes;
- int i, nc = iter->table->num_classes;
+ struct ddebug_class_map *map = dt->classes;
+ int i;
- for (i = 0; i < nc; i++, map++)
+ for (i = 0; i < dt->num_classes; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1151,7 +1151,7 @@ static int ddebug_proc_show(struct seq_file *m, void *p)
seq_puts(m, "\"");
if (dp->class_id != _DPRINTK_CLASS_DFLT) {
- class = ddebug_class_name(iter, dp);
+ class = ddebug_class_name(iter->table, dp);
if (class)
seq_printf(m, " class:%s", class);
else
--
2.41.0
[Intel-gfx] [PATCH v4 08/21] dyndbg: reduce verbose/debug clutter
currently, for verbose=3, these are logged (blank lines for clarity):
dyndbg: query 0: "class DRM_UT_CORE +p" mod:*
dyndbg: split into words: "class" "DRM_UT_CORE" "+p"
dyndbg: op='+'
dyndbg: flags=0x1
dyndbg: *flagsp=0x1 *maskp=0x
dyndbg: parsed: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_CORE
dyndbg: no matches for query
dyndbg: no-match: func="" file="" module="" format="" lineno=0-0
class=DRM_UT_CORE
dyndbg: processed 1 queries, with 0 matches, 0 errs
That is excessive, so this patch:
- shrinks 3 lines of 2nd stanza to single line
- drops 1st 2 lines of 3rd stanza
3rd is like 1st, with result, not procedure.
2nd is just status, retold in 4th, with more info.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 6070d37c24ac..2a5cbb68d88d 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -265,9 +265,6 @@ static int ddebug_change(const struct ddebug_query *query,
}
mutex_unlock(_lock);
- if (!nfound && verbose)
- pr_info("no matches for query\n");
-
return nfound;
}
@@ -496,7 +493,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
pr_err("bad flag-op %c, at start of %s\n", *str, str);
return -EINVAL;
}
- v3pr_info("op='%c'\n", op);
for (; *str ; ++str) {
for (i = ARRAY_SIZE(opt_array) - 1; i >= 0; i--) {
@@ -510,7 +506,6 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
return -EINVAL;
}
}
- v3pr_info("flags=0x%x\n", modifiers->flags);
/* calculate final flags, mask based upon op */
switch (op) {
@@ -526,7 +521,7 @@ static int ddebug_parse_flags(const char *str, struct
flag_settings *modifiers)
modifiers->flags = 0;
break;
}
- v3pr_info("*flagsp=0x%x *maskp=0x%x\n", modifiers->flags,
modifiers->mask);
+ v3pr_info("op='%c' flags=0x%x maskp=0x%x\n", op, modifiers->flags,
modifiers->mask);
return 0;
}
@@ -536,7 +531,7 @@ static int ddebug_exec_query(char *query_string, const char
*modname)
struct flag_settings modifiers = {};
struct ddebug_query query = {};
#define MAXWORDS 9
- int nwords, nfound;
+ int nwords;
char *words[MAXWORDS];
nwords = ddebug_tokenize(query_string, words, MAXWORDS);
@@ -554,10 +549,7 @@ static int ddebug_exec_query(char *query_string, const
char *modname)
return -EINVAL;
}
/* actually go and implement the change */
- nfound = ddebug_change(, );
- vpr_info_dq(, nfound ? "applied" : "no-match");
-
- return nfound;
+ return ddebug_change(, );
}
/* handle multiple queries in query string, continue on error, return
--
2.41.0
[Intel-gfx] [PATCH v4 07/21] dyndbg: drop NUM_TYPE_ARRAY
ARRAY_SIZE works here, since array decl is complete.
no functional change
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 596d0664c29f..719c5b6ad0f9 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -104,11 +104,9 @@ struct ddebug_class_map {
.mod_name = KBUILD_MODNAME, \
.base = _base, \
.map_type = _maptype, \
- .length = NUM_TYPE_ARGS(char*, __VA_ARGS__),\
+ .length = ARRAY_SIZE(_var##_classnames),\
.class_names = _var##_classnames, \
}
-#define NUM_TYPE_ARGS(eltype, ...) \
-(sizeof((eltype[]){__VA_ARGS__}) / sizeof(eltype))
/* encapsulate linker provided built-in (or module) dyndbg data */
struct _ddebug_info {
--
2.41.0
[Intel-gfx] [PATCH v4 05/21] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
Add query_module param to ddebug_apply_class_bitmap(). This allows
its caller to update just one module, or all (as currently). We'll
use this later to propagate drm.debug to each USEr as they're
modprobed.
No functional change.
Signed-off-by: Jim Cromie
---
after `modprobe i915`, heres the module dependencies,
though not all on drm.debug.
bash-5.2# lsmod
Module Size Used by
i915 3133440 0
drm_buddy 20480 1 i915
ttm90112 1 i915
i2c_algo_bit 16384 1 i915
video 61440 1 i915
wmi32768 1 video
drm_display_helper200704 1 i915
drm_kms_helper208896 2 drm_display_helper,i915
drm 606208 5
drm_kms_helper,drm_display_helper,drm_buddy,i915,ttm
cec57344 2 drm_display_helper,i915
---
lib/dynamic_debug.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index b4b6c5111315..d875c4fa5335 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -600,7 +600,8 @@ static int ddebug_exec_queries(char *query, const char
*modname)
/* apply a new bitmap to the sys-knob's current bit-state */
static int ddebug_apply_class_bitmap(const struct ddebug_class_param *dcp,
-unsigned long *new_bits, unsigned long
*old_bits)
+unsigned long *new_bits, unsigned long
*old_bits,
+const char *query_modname)
{
#define QUERY_SIZE 128
char query[QUERY_SIZE];
@@ -608,7 +609,8 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
int matches = 0;
int bi, ct;
- v2pr_info("apply: 0x%lx to: 0x%lx\n", *new_bits, *old_bits);
+ v2pr_info("apply bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
for (bi = 0; bi < map->length; bi++) {
if (test_bit(bi, new_bits) == test_bit(bi, old_bits))
@@ -617,12 +619,15 @@ static int ddebug_apply_class_bitmap(const struct
ddebug_class_param *dcp,
snprintf(query, QUERY_SIZE, "class %s %c%s",
map->class_names[bi],
test_bit(bi, new_bits) ? '+' : '-', dcp->flags);
- ct = ddebug_exec_queries(query, NULL);
+ ct = ddebug_exec_queries(query, query_modname);
matches += ct;
v2pr_info("bit_%d: %d matches on class: %s -> 0x%lx\n", bi,
ct, map->class_names[bi], *new_bits);
}
+ v2pr_info("applied bitmap: 0x%lx to: 0x%lx for %s\n", *new_bits,
*old_bits,
+ query_modname ?: "");
+
return matches;
}
@@ -678,7 +683,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
continue;
}
curr_bits ^= BIT(cls_id);
- totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
dcp->bits, NULL);
*dcp->bits = curr_bits;
v2pr_info("%s: changed bit %d:%s\n", KP_NAME(kp),
cls_id,
map->class_names[cls_id]);
@@ -688,7 +693,7 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
curr_bits = CLASSMAP_BITMASK(cls_id + (wanted ? 1 : 0
));
- totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits,
_bits, NULL);
*dcp->lvl = (cls_id + (wanted ? 1 : 0));
v2pr_info("%s: changed bit-%d: \"%s\" %lx->%lx\n",
KP_NAME(kp), cls_id,
map->class_names[cls_id], old_bits,
curr_bits);
@@ -751,7 +756,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
inrep &= CLASSMAP_BITMASK(map->length);
}
v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits);
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -764,7 +769,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
[Intel-gfx] [PATCH v4 06/21] dyndbg: split param_set_dyndbg_classes to module/wrapper fns
rename param_set_dyndbg_classes: add _module_ name & arg, old name is
wrapper to new. New arg allows caller to specify that only one module
is affected by a prdbgs update.
Outer fn preserves kernel_param interface, passing NULL to inner fn.
This selectivity will be used later to narrow the scope of changes
made.
no functional change.
Signed-off-by: Jim Cromie
---
lib/dynamic_debug.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index d875c4fa5335..6070d37c24ac 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -707,18 +707,9 @@ static int param_set_dyndbg_classnames(const char *instr,
const struct kernel_pa
return 0;
}
-/**
- * param_set_dyndbg_classes - class FOO >control
- * @instr: string echo>d to sysfs, input depends on map_type
- * @kp:kp->arg has state: bits/lvl, map, map_type
- *
- * Enable/disable prdbgs by their class, as given in the arguments to
- * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
- * levels by bitpos.
- *
- * Returns: 0 or <0 if error.
- */
-int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+static int param_set_dyndbg_module_classes(const char *instr,
+ const struct kernel_param *kp,
+ const char *modnm)
{
const struct ddebug_class_param *dcp = kp->arg;
const struct ddebug_class_map *map = dcp->map;
@@ -755,8 +746,8 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
KP_NAME(kp), inrep,
CLASSMAP_BITMASK(map->length));
inrep &= CLASSMAP_BITMASK(map->length);
}
- v2pr_info("bits:%lx > %s\n", inrep, KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
NULL);
+ v2pr_info("bits:0x%lx > %s.%s\n", inrep, modnm ?: "*",
KP_NAME(kp));
+ totct += ddebug_apply_class_bitmap(dcp, , dcp->bits,
modnm);
*dcp->bits = inrep;
break;
case DD_CLASS_TYPE_LEVEL_NUM:
@@ -769,7 +760,7 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
old_bits = CLASSMAP_BITMASK(*dcp->lvl);
new_bits = CLASSMAP_BITMASK(inrep);
v2pr_info("lvl:%ld bits:0x%lx > %s\n", inrep, new_bits,
KP_NAME(kp));
- totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
NULL);
+ totct += ddebug_apply_class_bitmap(dcp, _bits, _bits,
modnm);
*dcp->lvl = inrep;
break;
default:
@@ -778,6 +769,21 @@ int param_set_dyndbg_classes(const char *instr, const
struct kernel_param *kp)
vpr_info("%s: total matches: %d\n", KP_NAME(kp), totct);
return 0;
}
+/**
+ * param_set_dyndbg_classes - class FOO >control
+ * @instr: string echo>d to sysfs, input depends on map_type
+ * @kp:kp->arg has state: bits/lvl, map, map_type
+ *
+ * Enable/disable prdbgs by their class, as given in the arguments to
+ * DECLARE_DYNDBG_CLASSMAP. For LEVEL map-types, enforce relative
+ * levels by bitpos.
+ *
+ * Returns: 0 or <0 if error.
+ */
+int param_set_dyndbg_classes(const char *instr, const struct kernel_param *kp)
+{
+ return param_set_dyndbg_module_classes(instr, kp, NULL);
+}
EXPORT_SYMBOL(param_set_dyndbg_classes);
/**
--
2.41.0
[Intel-gfx] [PATCH v4 04/21] dyndbg: replace classmap list with a vector
Classmaps are stored/linked in a section/array, but are each added to
the module's ddebug_table.maps list-head.
This is unnecessary; even when ddebug_attach_classmap() is handling
the builtin section (with classmaps for multiple builtin modules), its
contents are ordered, so a module's possibly multiple classmaps will
be consecutive in the section, and could be treated as a vector/block,
since both start-addy and subrange length are in the ddebug_info arg.
So this changes:
struct ddebug_class_map drops list-head link.
struct ddebug_table drops the list-head maps, and gets: classes &
num_classes for the start-addy and num_classes, placed to improve
struct packing.
The loading: in ddebug_attach_module_classes(), replace the
for-the-modname list-add loop, with a forloop that finds the module's
subrange (start,length) of matching classmaps within the possibly
builtin classmaps vector, and saves those to the ddebug_table.
The reading/using: change list-foreach loops in ddebug_class_name() &
ddebug_find_valid_class() to walk the array from start to length.
Also:
Move #define __outvar up, above an added use in a fn-prototype.
Simplify ddebug_attach_module_classes args, ref has both addy,len.
no functional changes
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 1 -
lib/dynamic_debug.c | 61 ++-
2 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index dc41e70dc2e1..596d0664c29f 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -81,7 +81,6 @@ enum class_map_type {
};
struct ddebug_class_map {
- struct list_head link;
struct module *mod;
const char *mod_name; /* needed for builtins */
const char **class_names;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index 22a3182bf89f..b4b6c5111315 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -45,10 +45,11 @@ extern struct ddebug_class_map __start___dyndbg_classes[];
extern struct ddebug_class_map __stop___dyndbg_classes[];
struct ddebug_table {
- struct list_head link, maps;
+ struct list_head link;
const char *mod_name;
- unsigned int num_ddebugs;
struct _ddebug *ddebugs;
+ struct ddebug_class_map *classes;
+ unsigned int num_ddebugs, num_classes;
};
struct ddebug_query {
@@ -146,13 +147,15 @@ static void vpr_info_dq(const struct ddebug_query *query,
const char *msg)
query->first_lineno, query->last_lineno, query->class_string);
}
+#define __outvar /* filled by callee */
static struct ddebug_class_map *ddebug_find_valid_class(struct ddebug_table
const *dt,
- const char
*class_string, int *class_id)
+ const char
*class_string,
+ __outvar int *class_id)
{
struct ddebug_class_map *map;
- int idx;
+ int i, idx;
- list_for_each_entry(map, >maps, link) {
+ for (map = dt->classes, i = 0; i < dt->num_classes; i++, map++) {
idx = match_string(map->class_names, map->length, class_string);
if (idx >= 0) {
*class_id = idx + map->base;
@@ -163,7 +166,6 @@ static struct ddebug_class_map
*ddebug_find_valid_class(struct ddebug_table cons
return NULL;
}
-#define __outvar /* filled by callee */
/*
* Search the tables for _ddebug's which match the given `query' and
* apply the `flags' and `mask' to them. Returns number of matching
@@ -1107,9 +1109,10 @@ static void *ddebug_proc_next(struct seq_file *m, void
*p, loff_t *pos)
static const char *ddebug_class_name(struct ddebug_iter *iter, struct _ddebug
*dp)
{
- struct ddebug_class_map *map;
+ struct ddebug_class_map *map = iter->table->classes;
+ int i, nc = iter->table->num_classes;
- list_for_each_entry(map, >table->maps, link)
+ for (i = 0; i < nc; i++, map++)
if (class_in_range(dp->class_id, map))
return map->class_names[dp->class_id - map->base];
@@ -1193,30 +1196,31 @@ static const struct proc_ops proc_fops = {
.proc_write = ddebug_proc_write
};
-static void ddebug_attach_module_classes(struct ddebug_table *dt,
-struct ddebug_class_map *classes,
-int num_classes)
+static void ddebug_attach_module_classes(struct ddebug_table *dt, struct
_ddebug_info *di)
{
struct ddebug_class_map *cm;
- int i, j, ct = 0;
+ int i, nc = 0;
- for (cm = classes, i = 0; i < num_classes; i++, cm++) {
+ /*
+* Find this module's classmaps in a subrange/wholerange of
+* the builtin/modular classmap vector/section. Save the start
+* and length of the subrange
[Intel-gfx] [PATCH v4 01/21] drm: use correct ccflags-y syntax
Incorrect CFLAGS- usage failed to add -DDYNAMIC_DEBUG_MODULE,
which broke builds with:
CONFIG_DRM_USE_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
but without DYNAMIC_DEBUG
Nobody noticed because a larger regression emerged.
Also add subdir-ccflags so that all drivers pick up the addition.
Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in dyndbg descriptor factory
macro")
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index a33257d2bc7f..670bf046019e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -3,7 +3,8 @@
# Makefile for the drm device driver. This driver provides support for the
# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
-CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
+ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG)+=
-DDYNAMIC_DEBUG_MODULE
+subdir-ccflags-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
drm-y := \
drm_aperture.o \
--
2.41.0
[Intel-gfx] [PATCH v4 03/21] dyndbg: make ddebug_class_param union members same size
struct ddebug_class_param keeps a ref to the state-storage of the
param, make both flavors use the same unsigned long under-type.
ISTM this is simpler and safer.
Signed-off-by: Jim Cromie
---
include/linux/dynamic_debug.h | 2 +-
lib/dynamic_debug.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
index 061dd84d09f3..dc41e70dc2e1 100644
--- a/include/linux/dynamic_debug.h
+++ b/include/linux/dynamic_debug.h
@@ -122,7 +122,7 @@ struct _ddebug_info {
struct ddebug_class_param {
union {
unsigned long *bits;
- unsigned int *lvl;
+ unsigned long *lvl;
};
char flags[8];
const struct ddebug_class_map *map;
diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
index fdd6d9800a70..22a3182bf89f 100644
--- a/lib/dynamic_debug.c
+++ b/lib/dynamic_debug.c
@@ -795,7 +795,7 @@ int param_get_dyndbg_classes(char *buffer, const struct
kernel_param *kp)
case DD_CLASS_TYPE_LEVEL_NAMES:
case DD_CLASS_TYPE_LEVEL_NUM:
- return scnprintf(buffer, PAGE_SIZE, "%d\n", *dcp->lvl);
+ return scnprintf(buffer, PAGE_SIZE, "%ld\n", *dcp->lvl);
default:
return -1;
}
--
2.41.0
[Intel-gfx] [PATCH v4 02/21] test-dyndbg: fixup CLASSMAP usage error
more careful reading of test output reveals:
lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing
categories\n"
lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n"
class:MID
lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI
lib/test_dynamic_debug.c:107 [test_dynamic_debug]do_cats =_ "HI msg\n" class
unknown, _id:13
That last line is wrong, the HI class is declared.
But the enum's 1st val (explicitly initialized) was wrong; it must be
_base, not _base+1 (a DECLARE_DYNDBG_CLASSMAP[1] param). So the last
enumeration exceeded the range of mapped class-id's, which triggered
the "class unknown" report. I intentionally coded in an error, but
forgot to verify its detection and remove it.
RFC:
This patch fixes a bad usage of DECLARE_DYNDBG_CLASSMAP(), showing
that it is too error-prone. As noted in test-mod comments:
* Using the CLASSMAP api:
* - classmaps must have corresponding enum
* - enum symbols must match/correlate with class-name strings in the map.
* - base must equal enum's 1st value
* - multiple maps must set their base to share the 0-62 class_id space !!
* (build-bug-on tips welcome)
Those shortcomings could largely be fixed with a __stringify_list
(which doesn't exist,) used in DECLARE_DYNDBG_CLASSMAP to stringify
__VA_ARGS__. Then, API would accept DRM_UT_* values literally; all
the categories, in order, and not their stringifications, which
created all the usage complications above.
[1] name changes later to DYNDBG_CLASSMAP_DEFINE
Signed-off-by: Jim Cromie
---
lib/test_dynamic_debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_dynamic_debug.c b/lib/test_dynamic_debug.c
index 8dd250ad022b..a01f0193a419 100644
--- a/lib/test_dynamic_debug.c
+++ b/lib/test_dynamic_debug.c
@@ -75,7 +75,7 @@ DD_SYS_WRAP(disjoint_bits, p);
DD_SYS_WRAP(disjoint_bits, T);
/* symbolic input, independent bits */
-enum cat_disjoint_names { LOW = 11, MID, HI };
+enum cat_disjoint_names { LOW = 10, MID, HI };
DECLARE_DYNDBG_CLASSMAP(map_disjoint_names, DD_CLASS_TYPE_DISJOINT_NAMES, 10,
"LOW", "MID", "HI");
DD_SYS_WRAP(disjoint_names, p);
--
2.41.0
[Intel-gfx] [PATCH v4 00/21] fix DRM_USE_DYNAMIC_DEBUG regression
hi Jason, Daniel, Greg, etal
Heres another run at the regression, adequately explained in V3 here:
https://lore.kernel.org/lkml/20230125203743.564009-1-jim.cro...@gmail.com/
https://patchwork.freedesktop.org/series/113363/
V3 exposed an init-ordering issue with jump-label, fixed by Jason with
7deabd674988 ("dyndbg: use the module notifier callbacks")
These patches are against v6.4, they apply cleanly to drm-next-2023-07-07
Also at https://github.com/jimc/linux.git (dd-fix-2k2, dd-fix-2k-on-drm)
The bulk of the work is in the 2nd of the dyndbg-API commits, it
probably requires the most scrutiny. It splits the confused
double-duty job of DECLARE_DYNDBG_CLASSMAP into DYNDBG_CLASSMAP_DEFINE
and DYNDBG_CLASSMAP_USE.
The other dyndbg-API patches could stand a wider review, since they
make new API. Bikeshed on names, now while its easy. Fresh eyes see
inconsistencies better.
I considered s/class_map/classmap/, since theres also CLASSMAP, and
also PeterZ's new CLASS macros (which I should generally stay away from).
Or is that just churn ? catmap ?? And maybe *param* fn-names too.
I yanked the NAME class-types, since there are no users except the
test-module, we could have it back later if anyone wants it.
theres also an RFC s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback.
Jim Cromie (21):
drm: use correct ccflags-y syntax
test-dyndbg: fixup CLASSMAP usage error
dyndbg: make ddebug_class_param union members same size
dyndbg: replace classmap list with a vector
dyndbg: ddebug_apply_class_bitmap - add module arg, select on it
dyndbg: split param_set_dyndbg_classes to module/wrapper fns
dyndbg: drop NUM_TYPE_ARRAY
dyndbg: reduce verbose/debug clutter
dyndbg: silence debugs with no-change updates
dyndbg: tighten ddebug_class_name() 1st arg type
dyndbg: tighten fn-sig of ddebug_apply_class_bitmap
dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code
dyndbg-API: fix DECLARE_DYNDBG_CLASSMAP & CONFIG_DRM_USE_DYNAMIC_DEBUG
dyndbg: refactor ddebug_classparam_clamp_input
dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API
dyndbg-test: make it build with just CONFIG_DYNAMIC_DEBUG_CORE
drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN
compiler.h: RFC - s/__LINE__/__COUNTER__/ in __UNIQUE_ID fallback
drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
config TEST_DYNAMIC_DEBUG default m
dyndbg-doc: add classmap info to howto
.../admin-guide/dynamic-debug-howto.rst | 60 +++
drivers/gpu/drm/Kconfig | 3 +-
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +-
drivers/gpu/drm/display/drm_dp_helper.c | 12 +-
drivers/gpu/drm/drm_crtc_helper.c | 12 +-
drivers/gpu/drm/drm_gem_shmem_helper.c| 2 +
drivers/gpu/drm/drm_print.c | 35 +-
drivers/gpu/drm/gud/gud_drv.c | 2 +
drivers/gpu/drm/i915/i915_params.c| 12 +-
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +
drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +-
drivers/gpu/drm/qxl/qxl_drv.c | 2 +
drivers/gpu/drm/radeon/radeon_drv.c | 2 +
drivers/gpu/drm/udl/udl_main.c| 2 +
drivers/gpu/drm/vkms/vkms_drv.c | 2 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +
include/asm-generic/vmlinux.lds.h | 1 +
include/drm/drm_print.h | 12 +-
include/linux/compiler.h | 4 +-
include/linux/dynamic_debug.h | 112 +++--
kernel/module/main.c | 3 +
lib/Kconfig.debug | 13 +-
lib/Makefile | 4 +-
lib/dynamic_debug.c | 399 +++---
lib/test_dynamic_debug.c | 127 +++---
lib/test_dynamic_debug_submod.c | 10 +
27 files changed, 522 insertions(+), 340 deletions(-)
create mode 100644 lib/test_dynamic_debug_submod.c
--
2.41.0
Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, July 13, 2023 6:39 PM
> To: Srinivas, Vidya ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
> differing sync polarities
>
> On Wed, 12 Jul 2023, "Srinivas, Vidya" wrote:
> >> -Original Message-
> >> From: Nikula, Jani
> >> Sent: Wednesday, July 12, 2023 1:44 PM
> >> To: Srinivas, Vidya ; intel-
> >> g...@lists.freedesktop.org
> >> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to
> >> have differing sync polarities
> >>
> >> On Tue, 11 Jul 2023, Jani Nikula wrote:
> >> > On Tue, 11 Jul 2023, Vidya Srinivas wrote:
> >> >> v2: Add Jani Nikula's change for quirk for sync polarity
> >> >
> >> > This was a quick hack suggestion to try. If it works, I think it
> >> > works by concidence, because a fastset won't update the sync flags
> >> > in TRANS_DDI_FUNC_CTL register. Did not check whether they can even
> >> > be updated while the transcoder is enabled.
> >>
> >> Bspec 49198 seems to indicate TRANS_DDI_FUNC_CTL can be changed
> >> without a full mode set.
> >>
> >> The sync polarity still needs to be modified in the ->update_pipe() hooks.
> >
> > Hello Jani,
> >
> > Thank you very much. Apart from sync polarity, VRR panel is doing full
> > modeset between refresh rates 165 to 60Hz due to vrr.vmin, vrr.vmax,
> vrr.flipline and vrr.guardband mismatch.
> > Can VRR panel do seamless fastset between 165Hz and 60Hz? Kindly let me
> know.
> > Thank you.
>
> I think it should be possible, even if the driver does not handle it properly
> atm.
>
> Not sure if it can be combined with VRR itself. I guess typically you'd change
> the refresh rate instead of fastset when you're using VRR, but if you're not
> using VRR, would be great to be able to have DRRS and fastsets between the
> modes.
Hello Jani,
Thank you very much for the inputs.
Regards
Vidya
>
> BR,
> Jani.
>
> >
> > Regards
> > Vidya
> >>
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> >
> >> >> CC: Jani Nikula
> >> >> Credits-to: Jani Nikula
> >> >> Signed-off-by: Vidya Srinivas
> >> >
> >> > It would be useful to have a bug report at fdo gitlab with the EDID
> >> > attached.
> >> >
> >> > BR,
> >> > Jani.
> >> >
> >> >
> >> >> ---
> >> >> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> >> >> drivers/gpu/drm/i915/display/intel_panel.c | 10 ++
> >> >> 2 files changed, 7 insertions(+), 5 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> index 43cba98f7753..088b45e032aa 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> >> >> @@ -5234,7 +5234,7 @@ intel_pipe_config_compare(const struct
> >> intel_crtc_state *current_config,
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >> DRM_MODE_FLAG_INTERLACE);
> >> >>
> >> >> - if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)) {
> >> >> + if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)
> >> &&
> >> >> +!fastset) {
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >> DRM_MODE_FLAG_PHSYNC);
> >> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
> >> >> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> b/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> index 9232a305b1e6..b9eeaedabd22 100644
> >> >> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> >> >> @@ -112,10 +112,12 @@ intel_panel_fixed_mode(struct
> >> >> intel_connector *connector, static bool is_alt_drrs_mode(const
> >> >> struct drm_display_mode
> >> *mode,
> >> >> const struct drm_display_mode
> >> >> *preferred_mode)
> >> {
> >> >> - return drm_mode_match(mode, preferred_mode,
> >> >> -DRM_MODE_MATCH_TIMINGS |
> >> >> -DRM_MODE_MATCH_FLAGS |
> >> >> -DRM_MODE_MATCH_3D_FLAGS) &&
> >> >> + u32 sync_flags = DRM_MODE_FLAG_PHSYNC |
> >> DRM_MODE_FLAG_NHSYNC |
> >> >> + DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC;
> >> >> +
> >> >> + return (mode->flags & ~sync_flags) == (preferred_mode->flags &
> >> ~sync_flags) &&
> >> >> + mode->hdisplay == preferred_mode->hdisplay &&
> >> >> + mode->vdisplay == preferred_mode->vdisplay &&
> >> >>mode->clock != preferred_mode->clock; }
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [RFC 1/2] drm/i915: Refactor PAT/object cache handling
From: Tvrtko Ursulin
Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") has
introduced PAT indices to i915 internal APIs, partially replacing the
usage of driver internal cache_level, but has also added a few
questionable design decisions which this patch tries to improve upon.
Principal change is to invert the per platform cache level to PAT index
table which was added by the referenced commit, and by doing so enable
i915 to understand the cache mode between PAT indices, changing them from
opaque to transparent.
Once we have the inverted table we are able to remove the hidden false
"return true" from i915_gem_object_has_cache_level.
We also replace the enum i915_cache_level with i915_cache_t, composed of
a more detailed representation of each cache mode (base mode plus flags).
For instance this way we are able to express the difference between WB and
1-way coherent WB on Meteorlake. Which in turn enables us to map the i915
"cached" mode to the correct Meteorlake PAT index.
We also cache PAT indices of the caching modes used by the driver itself
in struct drm_i915_private, which eliminates the runtime calls to
i915_gem_get_pat_index from both high- and low-level i915 components.
We also remove the incorrect references to enum i915_cache_level from low
level PTE encode vfuncs, since those are actually given PAT indices by
their callers.
Finally we are able to replace the platform dependent cache mode to string
code in debugfs and elsewhere by the single implementation based on
i915_cache_t.
The opens are around correctness of the inverted tables added in
i915_pci.c in terms of whether the "flavour" (coherency) of WB modes is
correct for different platforms.
And second one probably if I haven't over-complicated something that could
actually be expressed or implemented in a simpler way.
Signed-off-by: Tvrtko Ursulin
Reference: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Cc: Chris Wilson
Cc: Fei Yang
Cc: Andi Shyti
Cc: Matt Roper
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 54
drivers/gpu/drm/i915/gem/i915_gem_domain.h| 5 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 +-
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_object.c| 129 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 11 +-
.../gpu/drm/i915/gem/i915_gem_object_types.h | 116 +---
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 8 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 11 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 44 +++---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
.../drm/i915/gem/selftests/huge_gem_object.c | 4 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 6 +-
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +-
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 19 +--
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ggtt.c | 33 ++---
drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gtt.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +-
drivers/gpu/drm/i915/gt/intel_migrate.c | 11 +-
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 6 +-
.../gpu/drm/i915/gt/intel_ring_submission.c | 4 +-
drivers/gpu/drm/i915/gt/intel_timeline.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_migrate.c| 9 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 14 +-
drivers/gpu/drm/i915/gt/selftest_tlb.c| 5 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 2 +-
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 8 +-
drivers/gpu/drm/i915/i915_cache.c | 88
drivers/gpu/drm/i915/i915_cache.h | 61 +
drivers/gpu/drm/i915/i915_debugfs.c | 53 +--
drivers/gpu/drm/i915/i915_driver.c| 5 +
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_gem.c | 21 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 7 +-
drivers/gpu/drm/i915/i915_pci.c | 92 +++--
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/intel_device_info.h | 6 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 5 +-
.../gpu/drm/i915/selftests/i915_gem_evict.c | 8 +-
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 13 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
.../drm/i915/selftests/intel_memory_region.c | 4 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 14 +-
48 files changed, 457 insertions(+), 478 deletions(-)
create mode 100644 drivers/gpu/drm/i915/i915_cache.c
create mode 100644 drivers/gpu/drm/i915/i915_cache.h
diff --git a/drivers/gpu/drm/i915/Makefile
[Intel-gfx] [RFC 2/2] drm/i915: Remove PAT hack from i915_gem_object_can_bypass_llc
From: Tvrtko Ursulin
According to the comment in i915_gem_object_can_bypass_llc the purpose of
the function is to return false if the platform/object has a caching mode
where GPU can bypass the LLC.
So far the only platforms which allegedly can do this are Jasperlake and
Elkhartlake, and that via MOCS (not PAT).
Instead of blindly assuming that objects where userspace has set the PAT
index can (bypass the LLC), question is is there a such PAT index on a
platform. Probably starting with Meteorlake since that one is the only one
where set PAT extension can be currently used. Or if there is a MOCS entry
which can achieve the same thing on Meteorlake.
If there is such PAT, now that i915 can be made to understand them better,
we can make the check more fine grained. Or if there is a MOCS entry then
we probably should apply the blanket IS_METEORLAKE condition.
Signed-off-by: Tvrtko Ursulin
Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")
Cc: Chris Wilson
Cc: Fei Yang
Cc: Andi Shyti
Cc: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 33a1e97d18b3..1e34171c4162 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -229,12 +229,6 @@ bool i915_gem_object_can_bypass_llc(struct
drm_i915_gem_object *obj)
if (!(obj->flags & I915_BO_ALLOC_USER))
return false;
- /*
-* Always flush cache for UMD objects at creation time.
-*/
- if (obj->pat_set_by_user)
- return true;
-
/*
* EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
* possible for userspace to bypass the GTT caching bits set by the
--
2.39.2
[Intel-gfx] ✗ Fi.CI.IGT: failure for DSC misc fixes (rev4)
== Series Details == Series: DSC misc fixes (rev4) URL : https://patchwork.freedesktop.org/series/117662/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13380_full -> Patchwork_117662v4_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_117662v4_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_117662v4_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- Additional (1): pig-kbl-iris Missing(1): shard-rkl0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_117662v4_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a3: - shard-dg2: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13380/shard-dg2-7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-dg2-6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@b-hdmi-a3.html Known issues Here are the changes found in Patchwork_117662v4_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-purge-cache: - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8411]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-dg2-11/igt@api_intel...@object-reloc-purge-cache.html * igt@device_reset@cold-reset-bound: - shard-rkl: NOTRUN -> [SKIP][4] ([i915#7701]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-rkl-2/igt@device_re...@cold-reset-bound.html * igt@drm_fdinfo@all-busy-check-all: - shard-dg2: NOTRUN -> [SKIP][5] ([i915#8414]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-dg2-11/igt@drm_fdi...@all-busy-check-all.html * igt@drm_fdinfo@most-busy-check-all@rcs0: - shard-rkl: [PASS][6] -> [FAIL][7] ([i915#7742]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13380/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html * igt@drm_fdinfo@virtual-busy-all: - shard-mtlp: NOTRUN -> [SKIP][8] ([i915#8414]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-mtlp-5/igt@drm_fdi...@virtual-busy-all.html * igt@feature_discovery@display-4x: - shard-mtlp: NOTRUN -> [SKIP][9] ([i915#1839]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-mtlp-5/igt@feature_discov...@display-4x.html * igt@gem_ccs@ctrl-surf-copy: - shard-mtlp: NOTRUN -> [SKIP][10] ([i915#5325]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-mtlp-5/igt@gem_...@ctrl-surf-copy.html * igt@gem_create@create-ext-set-pat: - shard-snb: NOTRUN -> [FAIL][11] ([i915#8621]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-snb4/igt@gem_cre...@create-ext-set-pat.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][12] -> [FAIL][13] ([i915#6268]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13380/shard-rkl-2/igt@gem_ctx_e...@basic-nohangcheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-rkl-7/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_persistence@engines-queued: - shard-snb: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#1099]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-snb4/igt@gem_ctx_persiste...@engines-queued.html * igt@gem_ctx_persistence@heartbeat-close: - shard-mtlp: NOTRUN -> [SKIP][15] ([i915#8555]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-mtlp-5/igt@gem_ctx_persiste...@heartbeat-close.html * igt@gem_eio@in-flight-suspend: - shard-dg2: [PASS][16] -> [FAIL][17] ([fdo#103375] / [i915#6121]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13380/shard-dg2-10/igt@gem_...@in-flight-suspend.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-dg2-5/igt@gem_...@in-flight-suspend.html * igt@gem_eio@kms: - shard-dg2: [PASS][18] -> [FAIL][19] ([i915#5784]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13380/shard-dg2-11/igt@gem_...@kms.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_117662v4/shard-dg2-12/igt@gem_...@kms.html * igt@gem_exec_balancer@bonded-true-hang: - shard-dg2: NOTRUN ->
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/display: Do not use stolen on MTL
On 7/13/2023 4:56 PM, Andrzej Hajda wrote:
On 13.07.2023 16:45, Nirmoy Das wrote:
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 5 -
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 1cc0ddc6a310..e019bbcd474e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -187,8 +187,11 @@ static int intelfb_alloc(struct drm_fb_helper
*helper,
* If the FB is too big, just don't use it since fbdev is
not very
* important and we should probably use that space with
FBC or other
* features.
+ *
+ * Also skip stolen on MTL as Wa_22018444074 mitigation.
*/
- if (size * 2 < dev_priv->dsm.usable_size)
+ if (size * 2 < dev_priv->dsm.usable_size ||
+ !(IS_METEORLAKE(dev_priv)))
Just realized this is wrong, stolen will be picked on non-mtl even
if the stolen usable size is < 2*size which is not expected.
if (!(IS_METEORLAKE(dev_priv)) && size * 2 < dev_priv->dsm.usable_size) ?
that should work, resent with that.
Thanks,
Nirmoy
Regards
Andrzej
I will keep this as v1
Regards,
Nirmoy
obj = i915_gem_object_create_stolen(dev_priv, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(dev_priv, size);
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index d6fe2bbabe55..09c1aa1427ad 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1348,11 +1348,12 @@ int intel_overlay_attrs_ioctl(struct
drm_device *dev, void *data,
static int get_registers(struct intel_overlay *overlay, bool
use_phys)
{
struct drm_i915_private *i915 = overlay->i915;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = ERR_PTR(-ENODEV);
struct i915_vma *vma;
int err;
- obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
+ if (!IS_METEORLAKE(i915)) /* Wa_22018444074 */
+ obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj))
[Intel-gfx] [PATCH 1/2] drm/i915/gt: Do not use stolen on MTL
Use smem on MTL due to a HW bug in MTL that prevents reading from stolen memory using LMEM BAR. Cc: Oak Zeng Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Andi Shyti Cc: Andrzej Hajda Signed-off-by: Nirmoy Das Reviewed-by: Oak Zeng Reviewed-by: Andrzej Hajda Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gt/intel_gt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 33a61046ba58..9f64d61dd5fc 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -466,7 +466,7 @@ static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size) obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE | I915_BO_ALLOC_GPU_ONLY); - if (IS_ERR(obj)) + if (IS_ERR(obj) && !IS_METEORLAKE(i915)) /* Wa_22018444074 */ obj = i915_gem_object_create_stolen(i915, size); if (IS_ERR(obj)) obj = i915_gem_object_create_internal(i915, size); -- 2.39.0
[Intel-gfx] [PATCH v3 2/2] drm/i915/display: Do not use stolen on MTL
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2 and v3: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 4 +++-
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 1cc0ddc6a310..491b6e22edad 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -187,8 +187,10 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
* If the FB is too big, just don't use it since fbdev is not
very
* important and we should probably use that space with FBC or
other
* features.
+*
+* Also skip stolen on MTL as Wa_22018444074 mitigation.
*/
- if (size * 2 < dev_priv->dsm.usable_size)
+ if (!(IS_METEORLAKE(dev_priv)) && size * 2 <
dev_priv->dsm.usable_size)
obj = i915_gem_object_create_stolen(dev_priv, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(dev_priv, size);
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index d6fe2bbabe55..09c1aa1427ad 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1348,11 +1348,12 @@ int intel_overlay_attrs_ioctl(struct drm_device *dev,
void *data,
static int get_registers(struct intel_overlay *overlay, bool use_phys)
{
struct drm_i915_private *i915 = overlay->i915;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = ERR_PTR(-ENODEV);
struct i915_vma *vma;
int err;
- obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
+ if (!IS_METEORLAKE(i915)) /* Wa_22018444074 */
+ obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj))
--
2.39.0
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/display: Do not use stolen on MTL
On 13.07.2023 16:45, Nirmoy Das wrote:
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 5 -
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 1cc0ddc6a310..e019bbcd474e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -187,8 +187,11 @@ static int intelfb_alloc(struct drm_fb_helper
*helper,
* If the FB is too big, just don't use it since fbdev is
not very
* important and we should probably use that space with FBC
or other
* features.
+ *
+ * Also skip stolen on MTL as Wa_22018444074 mitigation.
*/
- if (size * 2 < dev_priv->dsm.usable_size)
+ if (size * 2 < dev_priv->dsm.usable_size ||
+ !(IS_METEORLAKE(dev_priv)))
Just realized this is wrong, stolen will be picked on non-mtl even if
the stolen usable size is < 2*size which is not expected.
if (!(IS_METEORLAKE(dev_priv)) && size * 2 < dev_priv->dsm.usable_size) ?
Regards
Andrzej
I will keep this as v1
Regards,
Nirmoy
obj = i915_gem_object_create_stolen(dev_priv, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(dev_priv, size);
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index d6fe2bbabe55..09c1aa1427ad 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1348,11 +1348,12 @@ int intel_overlay_attrs_ioctl(struct
drm_device *dev, void *data,
static int get_registers(struct intel_overlay *overlay, bool use_phys)
{
struct drm_i915_private *i915 = overlay->i915;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = ERR_PTR(-ENODEV);
struct i915_vma *vma;
int err;
- obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
+ if (!IS_METEORLAKE(i915)) /* Wa_22018444074 */
+ obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj))
Re: [Intel-gfx] [PATCH 2/2] eventfd: simplify eventfd_signal_mask()
On Thu, Jul 13, 2023 at 07:33:05AM -0700, Sean Christopherson wrote:
> On Thu, Jul 13, 2023, Christian Brauner wrote:
> > diff --git a/fs/eventfd.c b/fs/eventfd.c
> > index dc9e01053235..077be5da72bd 100644
> > --- a/fs/eventfd.c
> > +++ b/fs/eventfd.c
> > @@ -43,9 +43,10 @@ struct eventfd_ctx {
> > int id;
> > };
> >
> > -__u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask)
> > +bool eventfd_signal_mask(struct eventfd_ctx *ctx, __poll_t mask)
> > {
> > unsigned long flags;
> > + __u64 n = 1;
> >
> > /*
> > * Deadlock or stack overflow issues can happen if we recurse here
> > @@ -68,7 +69,7 @@ __u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64
> > n, __poll_t mask)
> > current->in_eventfd = 0;
> > spin_unlock_irqrestore(>wqh.lock, flags);
> >
> > - return n;
> > + return n == 1;
> > }
>
> ...
>
> > @@ -58,13 +58,12 @@ static inline struct eventfd_ctx *eventfd_ctx_fdget(int
> > fd)
> > return ERR_PTR(-ENOSYS);
> > }
> >
> > -static inline int eventfd_signal(struct eventfd_ctx *ctx)
> > +static inline bool eventfd_signal(struct eventfd_ctx *ctx)
> > {
> > return -ENOSYS;
> > }
> >
> > -static inline int eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
> > - unsigned mask)
> > +static inline bool eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned
> > mask)
> > {
> > return -ENOSYS;
>
> This will morph to "true" for what should be an error case. One option would
> be
Ewww, that means it did return -ENOSYS before any of this.
> to have eventfd_signal_mask() return 0/-errno instead of the count, but
> looking
> at all the callers, nothing ever actually consumes the result.
>
> KVMGT morphs failure into -EFAULT
>
> if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1)
> return -EFAULT;
>
> but the only caller of that user ignores the return value.
>
> if (vgpu_vreg(vgpu, i915_mmio_reg_offset(GEN8_MASTER_IRQ))
> & ~GEN8_MASTER_IRQ_CONTROL)
> inject_virtual_interrupt(vgpu);
>
> The sample driver in samples/vfio-mdev/mtty.c uses a similar pattern: prints
> an
> error but otherwise ignores the result.
>
> So why not return nothing? That will simplify eventfd_signal_mask() a wee bit
> more, and eliminate that bizarre return value confusion for the ugly stubs,
> e.g.
Yeah, it used to return an int in the non-eventfd and a __u64 in the
eventfd case.
>
> void eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask)
> {
> unsigned long flags;
>
> /*
>* Deadlock or stack overflow issues can happen if we recurse here
>* through waitqueue wakeup handlers. If the caller users potentially
>* nested waitqueues with custom wakeup handlers, then it should
>* check eventfd_signal_allowed() before calling this function. If
>* it returns false, the eventfd_signal() call should be deferred to a
>* safe context.
>*/
> if (WARN_ON_ONCE(current->in_eventfd))
> return;
>
> spin_lock_irqsave(>wqh.lock, flags);
> current->in_eventfd = 1;
> if (ctx->count < ULLONG_MAX)
> ctx->count++;
> if (waitqueue_active(>wqh))
> wake_up_locked_poll(>wqh, EPOLLIN | mask);
> current->in_eventfd = 0;
> spin_unlock_irqrestore(>wqh.lock, flags);
> }
>
> You could even go further and unify the real and stub versions of
> eventfd_signal().
The reason I didn't make eventfd_signal_mask() return void was that it
was called from eventfd_signal() which did, I didn't realize the caller
didn't actually consume the return value.
If we can let both return void it gets simpler.
Thanks for that.
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/display: Do not use stolen on MTL
On 7/12/2023 12:06 AM, Nirmoy Das wrote:
Use smem on MTL due to a HW bug in MTL that prevents
reading from stolen memory using LMEM BAR.
v2: improve stolen skip detection(Andrzej)
Cc: Oak Zeng
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Andi Shyti
Cc: Andrzej Hajda
Signed-off-by: Nirmoy Das
Reviewed-by: Oak Zeng
Reviewed-by: Andrzej Hajda
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 5 -
drivers/gpu/drm/i915/display/intel_overlay.c | 5 +++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 1cc0ddc6a310..e019bbcd474e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -187,8 +187,11 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
* If the FB is too big, just don't use it since fbdev is not
very
* important and we should probably use that space with FBC or
other
* features.
+*
+* Also skip stolen on MTL as Wa_22018444074 mitigation.
*/
- if (size * 2 < dev_priv->dsm.usable_size)
+ if (size * 2 < dev_priv->dsm.usable_size ||
+ !(IS_METEORLAKE(dev_priv)))
Just realized this is wrong, stolen will be picked on non-mtl even if
the stolen usable size is < 2*size which is not expected.
I will keep this as v1
Regards,
Nirmoy
obj = i915_gem_object_create_stolen(dev_priv, size);
if (IS_ERR(obj))
obj = i915_gem_object_create_shmem(dev_priv, size);
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index d6fe2bbabe55..09c1aa1427ad 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -1348,11 +1348,12 @@ int intel_overlay_attrs_ioctl(struct drm_device *dev,
void *data,
static int get_registers(struct intel_overlay *overlay, bool use_phys)
{
struct drm_i915_private *i915 = overlay->i915;
- struct drm_i915_gem_object *obj;
+ struct drm_i915_gem_object *obj = ERR_PTR(-ENODEV);
struct i915_vma *vma;
int err;
- obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
+ if (!IS_METEORLAKE(i915)) /* Wa_22018444074 */
+ obj = i915_gem_object_create_stolen(i915, PAGE_SIZE);
if (IS_ERR(obj))
obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
if (IS_ERR(obj))
Re: [Intel-gfx] [PATCH 2/2] eventfd: simplify eventfd_signal_mask()
On Thu, Jul 13, 2023, Christian Brauner wrote:
> diff --git a/fs/eventfd.c b/fs/eventfd.c
> index dc9e01053235..077be5da72bd 100644
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@ -43,9 +43,10 @@ struct eventfd_ctx {
> int id;
> };
>
> -__u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask)
> +bool eventfd_signal_mask(struct eventfd_ctx *ctx, __poll_t mask)
> {
> unsigned long flags;
> + __u64 n = 1;
>
> /*
>* Deadlock or stack overflow issues can happen if we recurse here
> @@ -68,7 +69,7 @@ __u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
> __poll_t mask)
> current->in_eventfd = 0;
> spin_unlock_irqrestore(>wqh.lock, flags);
>
> - return n;
> + return n == 1;
> }
...
> @@ -58,13 +58,12 @@ static inline struct eventfd_ctx *eventfd_ctx_fdget(int
> fd)
> return ERR_PTR(-ENOSYS);
> }
>
> -static inline int eventfd_signal(struct eventfd_ctx *ctx)
> +static inline bool eventfd_signal(struct eventfd_ctx *ctx)
> {
> return -ENOSYS;
> }
>
> -static inline int eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
> - unsigned mask)
> +static inline bool eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned
> mask)
> {
> return -ENOSYS;
This will morph to "true" for what should be an error case. One option would be
to have eventfd_signal_mask() return 0/-errno instead of the count, but looking
at all the callers, nothing ever actually consumes the result.
KVMGT morphs failure into -EFAULT
if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1)
return -EFAULT;
but the only caller of that user ignores the return value.
if (vgpu_vreg(vgpu, i915_mmio_reg_offset(GEN8_MASTER_IRQ))
& ~GEN8_MASTER_IRQ_CONTROL)
inject_virtual_interrupt(vgpu);
The sample driver in samples/vfio-mdev/mtty.c uses a similar pattern: prints an
error but otherwise ignores the result.
So why not return nothing? That will simplify eventfd_signal_mask() a wee bit
more, and eliminate that bizarre return value confusion for the ugly stubs, e.g.
void eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask)
{
unsigned long flags;
/*
* Deadlock or stack overflow issues can happen if we recurse here
* through waitqueue wakeup handlers. If the caller users potentially
* nested waitqueues with custom wakeup handlers, then it should
* check eventfd_signal_allowed() before calling this function. If
* it returns false, the eventfd_signal() call should be deferred to a
* safe context.
*/
if (WARN_ON_ONCE(current->in_eventfd))
return;
spin_lock_irqsave(>wqh.lock, flags);
current->in_eventfd = 1;
if (ctx->count < ULLONG_MAX)
ctx->count++;
if (waitqueue_active(>wqh))
wake_up_locked_poll(>wqh, EPOLLIN | mask);
current->in_eventfd = 0;
spin_unlock_irqrestore(>wqh.lock, flags);
}
You could even go further and unify the real and stub versions of
eventfd_signal().
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Ensure memory quiesced before invalidation
Hi Andi,
On 7/13/2023 2:31 PM, Andi Shyti wrote:
Hi Nirmoy and Jonathan,
@@ -202,6 +202,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq, u32 mode)
{
struct intel_engine_cs *engine = rq->engine;
+ /*
+* Aux invalidations on Aux CCS platforms require
+* memory traffic is quiesced prior.
I see that we are doing aux inval on EMIT_INVALIDATE so it make sense to
do if ((mode & EMIT_INVALIDATE) && !HAS_FLAT_CCS(engine->i915) )
This is agreeable, though I don't think there's any instances of us calling
gen12_emit_flush_rcs with a blank mode,
since that wouldn't accomplish anything. So I don't think the additional
check/safety net is necessary, but it doesn't
hurt to have.
so... do we agree here that we don't add anything? I don't really
mind...
Not a blocking objection but if you are sending another revision of this
then why not.
Or, I can queue up a patch 5 adding this "pedantic" check and we
can discuss it separately.
+*/
+ if (!HAS_FLAT_CCS(engine->i915))
+ mode |= EMIT_FLUSH;
I think this generic EMIT_FLUSH is not enough. I seeing some missing
flags for PIPE_CONTROL
As per https://gfxspecs.intel.com/Predator/Home/Index/43904. It makes
sense to move this to a
new function given the complexity of PIPE_CONTROL flags requires for this.
I'm assuming when you're talking about the missing flags for PIPE_CONTROL,
you're
referring to CCS Flush, correct? Because every other flag is already covered
in the
EMIT_FLUSH path.
Yes, CCS Flush and I don't see a L3 fabric flush as well.
I feel like I had this conversation with Matt while the internal version was
developed back in February, and the consensus was that the CCS Flush
requirement was already covered.
Wasn't aware of this, would be nice to have a confirmation and a comment so
we
don't get confused in future.
On the other hand, it looks like the CCS Flush
requirement was only recently added back in May, so it might be worth
double-checking at the very least.
Although... if CCS Flush is a missing flag, I wonder how we're supposed to set
it,
as there doesn’t appear to be a definition for such a flag in
intel_gpu_commands.h...
Yes, not yet but we should add a flag for that.
Is it OK if I add in the comment that EMIT_FLUSH covers the CCS
flushing?
is it though ? I don't see that in the bspec, may be I am missing
something ?
Regards,
Nirmoy
Andi
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Ensure memory quiesced before invalidation
-Original Message-
From: Nirmoy Das
Sent: Thursday, July 13, 2023 7:12 AM
To: Andi Shyti
Cc: Cavitt, Jonathan ; Intel GFX
; Roper, Matthew D
; Chris Wilson ; Mika
Kuoppala
Subject: Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/gt: Ensure memory quiesced
before invalidation
>
>Hi Andi,
>
>On 7/13/2023 2:31 PM, Andi Shyti wrote:
>> Hi Nirmoy and Jonathan,
>>
>> @@ -202,6 +202,13 @@ int gen12_emit_flush_rcs(struct i915_request *rq,
>> u32 mode)
>> {
>> struct intel_engine_cs *engine = rq->engine;
>> +/*
>> + * Aux invalidations on Aux CCS platforms require
>> + * memory traffic is quiesced prior.
> I see that we are doing aux inval on EMIT_INVALIDATE so it make sense to
>
> do if ((mode & EMIT_INVALIDATE) && !HAS_FLAT_CCS(engine->i915) )
>
This is agreeable, though I don't think there's any instances of us
calling gen12_emit_flush_rcs with a blank mode,
since that wouldn't accomplish anything. So I don't think the additional
check/safety net is necessary, but it doesn't
hurt to have.
>> so... do we agree here that we don't add anything? I don't really
>> mind...
>
>Not a blocking objection but if you are sending another revision of this
>then why not.
That's about my stance on it as well. I'd defer the decision to Nirmoy here.
>
>
>> Or, I can queue up a patch 5 adding this "pedantic" check and we
>> can discuss it separately.
I wouldn't offer much in terms of the discussion, unfortunately, so I'm fairly
certain the
only thing that would come from that is a series of questions asking why the
patch
wasn't squashed with this one to begin with.
>>
>> + */
>> +if (!HAS_FLAT_CCS(engine->i915))
>> +mode |= EMIT_FLUSH;
> I think this generic EMIT_FLUSH is not enough. I seeing some missing
> flags for PIPE_CONTROL
>
> As per https://gfxspecs.intel.com/Predator/Home/Index/43904. It makes
> sense to move this to a
>
> new function given the complexity of PIPE_CONTROL flags requires for this.
>
I'm assuming when you're talking about the missing flags for PIPE_CONTROL,
you're
referring to CCS Flush, correct? Because every other flag is already
covered in the
EMIT_FLUSH path.
>>> Yes, CCS Flush and I don't see a L3 fabric flush as well.
Does PIPE_CONTROL_FLUSH_L3 not do this?
>>>
>>>
I feel like I had this conversation with Matt while the internal version
was
developed back in February, and the consensus was that the CCS Flush
requirement was already covered.
>>> Wasn't aware of this, would be nice to have a confirmation and a comment so
>>> we
>>>
>>> don't get confused in future.
>>>
On the other hand, it looks like the CCS Flush
requirement was only recently added back in May, so it might be worth
double-checking at the very least.
Although... if CCS Flush is a missing flag, I wonder how we're supposed to
set it,
as there doesn't appear to be a definition for such a flag in
intel_gpu_commands.h...
>>>
>>> Yes, not yet but we should add a flag for that.
>> Is it OK if I add in the comment that EMIT_FLUSH covers the CCS
>> flushing?
>
>
>is it though ? I don't see that in the bspec, may be I am missing
>something ?
That would certainly explain why there's no flag for it, if performing the CCS
Flush
is a part of the EMIT_FLUSH pipeline by default.
-Jonathan Cavitt
>
>
>Regards,
>
>Nirmoy
>
>>
>> Andi
>
Re: [Intel-gfx] [PATCH 1/2] eventfd: simplify eventfd_signal()
On Thu, Jul 13, 2023 at 1:06 PM Christian Brauner wrote:
>
> Ever since the evenfd type was introduced back in 2007 in commit
> e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
> function only ever passed 1 as a value for @n. There's no point in
> keeping that additional argument.
>
> Signed-off-by: Christian Brauner
> ---
> arch/x86/kvm/hyperv.c | 2 +-
> arch/x86/kvm/xen.c| 2 +-
> drivers/accel/habanalabs/common/device.c | 2 +-
> drivers/fpga/dfl.c| 2 +-
> drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
> drivers/infiniband/hw/mlx5/devx.c | 2 +-
> drivers/misc/ocxl/file.c | 2 +-
> drivers/s390/cio/vfio_ccw_chp.c | 2 +-
> drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
> drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
> drivers/s390/crypto/vfio_ap_ops.c | 2 +-
> drivers/usb/gadget/function/f_fs.c| 4 ++--
> drivers/vdpa/vdpa_user/vduse_dev.c| 6 +++---
> drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 2 +-
> drivers/vfio/pci/vfio_pci_core.c | 6 +++---
> drivers/vfio/pci/vfio_pci_intrs.c | 12 ++--
> drivers/vfio/platform/vfio_platform_irq.c | 4 ++--
> drivers/vhost/vdpa.c | 4 ++--
> drivers/vhost/vhost.c | 10 +-
> drivers/vhost/vhost.h | 2 +-
> drivers/virt/acrn/ioeventfd.c | 2 +-
> fs/aio.c | 2 +-
> fs/eventfd.c | 9 +++--
> include/linux/eventfd.h | 4 ++--
> mm/memcontrol.c | 10 +-
> mm/vmpressure.c | 2 +-
> samples/vfio-mdev/mtty.c | 4 ++--
> virt/kvm/eventfd.c| 4 ++--
> 28 files changed, 56 insertions(+), 59 deletions(-)
>
> diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
> index b28fd020066f..2f4bd74b482c 100644
> --- a/arch/x86/kvm/hyperv.c
> +++ b/arch/x86/kvm/hyperv.c
> @@ -2387,7 +2387,7 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu
> *vcpu, struct kvm_hv_hcall *h
> if (!eventfd)
> return HV_STATUS_INVALID_PORT_ID;
>
> - eventfd_signal(eventfd, 1);
> + eventfd_signal(eventfd);
> return HV_STATUS_SUCCESS;
> }
>
> diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> index 40edf4d1974c..a7b62bafd57b 100644
> --- a/arch/x86/kvm/xen.c
> +++ b/arch/x86/kvm/xen.c
> @@ -2043,7 +2043,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu
> *vcpu, u64 param, u64 *r)
> if (ret < 0 && ret != -ENOTCONN)
> return false;
> } else {
> - eventfd_signal(evtchnfd->deliver.eventfd.ctx, 1);
> + eventfd_signal(evtchnfd->deliver.eventfd.ctx);
> }
>
> *r = 0;
> diff --git a/drivers/accel/habanalabs/common/device.c
> b/drivers/accel/habanalabs/common/device.c
> index b97339d1f7c6..30357b371d61 100644
> --- a/drivers/accel/habanalabs/common/device.c
> +++ b/drivers/accel/habanalabs/common/device.c
> @@ -1963,7 +1963,7 @@ static void hl_notifier_event_send(struct
> hl_notifier_event *notifier_event, u64
> notifier_event->events_mask |= event_mask;
>
> if (notifier_event->eventfd)
> - eventfd_signal(notifier_event->eventfd, 1);
> + eventfd_signal(notifier_event->eventfd);
>
> mutex_unlock(_event->lock);
> }
> diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
> index dd7a783d53b5..e73f88050f08 100644
> --- a/drivers/fpga/dfl.c
> +++ b/drivers/fpga/dfl.c
> @@ -1872,7 +1872,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
> {
> struct eventfd_ctx *trigger = arg;
>
> - eventfd_signal(trigger, 1);
> + eventfd_signal(trigger);
> return IRQ_HANDLED;
> }
>
> diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
> b/drivers/gpu/drm/i915/gvt/interrupt.c
> index 68eca023bbc6..3d9e09c2add4 100644
> --- a/drivers/gpu/drm/i915/gvt/interrupt.c
> +++ b/drivers/gpu/drm/i915/gvt/interrupt.c
> @@ -435,7 +435,7 @@ static int inject_virtual_interrupt(struct intel_vgpu
> *vgpu)
> */
> if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
> return -ESRCH;
> - if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1)
> + if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger) != 1)
> return -EFAULT;
> return 0;
> }
> diff --git a/drivers/infiniband/hw/mlx5/devx.c
> b/drivers/infiniband/hw/mlx5/devx.c
> index db5fb196c728..ad50487790ff 100644
> --- a/drivers/infiniband/hw/mlx5/devx.c
> +++ b/drivers/infiniband/hw/mlx5/devx.c
> @@ -2498,7 +2498,7 @@ static void dispatch_event_fd(struct list_head *fd_list,
>
> list_for_each_entry_rcu(item, fd_list, xa_list) {
> if (item->eventfd)
> -
Re: [Intel-gfx] [PATCH 1/2] eventfd: simplify eventfd_signal()
For vfio_ap_ops.c:
Reviewed-by: Tony Krowiak
On 7/13/23 6:05 AM, Christian Brauner wrote:
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kvm/hyperv.c | 2 +-
arch/x86/kvm/xen.c| 2 +-
drivers/accel/habanalabs/common/device.c | 2 +-
drivers/fpga/dfl.c| 2 +-
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
drivers/infiniband/hw/mlx5/devx.c | 2 +-
drivers/misc/ocxl/file.c | 2 +-
drivers/s390/cio/vfio_ccw_chp.c | 2 +-
drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/usb/gadget/function/f_fs.c| 4 ++--
drivers/vdpa/vdpa_user/vduse_dev.c| 6 +++---
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 2 +-
drivers/vfio/pci/vfio_pci_core.c | 6 +++---
drivers/vfio/pci/vfio_pci_intrs.c | 12 ++--
drivers/vfio/platform/vfio_platform_irq.c | 4 ++--
drivers/vhost/vdpa.c | 4 ++--
drivers/vhost/vhost.c | 10 +-
drivers/vhost/vhost.h | 2 +-
drivers/virt/acrn/ioeventfd.c | 2 +-
fs/aio.c | 2 +-
fs/eventfd.c | 9 +++--
include/linux/eventfd.h | 4 ++--
mm/memcontrol.c | 10 +-
mm/vmpressure.c | 2 +-
samples/vfio-mdev/mtty.c | 4 ++--
virt/kvm/eventfd.c| 4 ++--
28 files changed, 56 insertions(+), 59 deletions(-)
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index b28fd020066f..2f4bd74b482c 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -2387,7 +2387,7 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu *vcpu,
struct kvm_hv_hcall *h
if (!eventfd)
return HV_STATUS_INVALID_PORT_ID;
- eventfd_signal(eventfd, 1);
+ eventfd_signal(eventfd);
return HV_STATUS_SUCCESS;
}
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 40edf4d1974c..a7b62bafd57b 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -2043,7 +2043,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu
*vcpu, u64 param, u64 *r)
if (ret < 0 && ret != -ENOTCONN)
return false;
} else {
- eventfd_signal(evtchnfd->deliver.eventfd.ctx, 1);
+ eventfd_signal(evtchnfd->deliver.eventfd.ctx);
}
*r = 0;
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index b97339d1f7c6..30357b371d61 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1963,7 +1963,7 @@ static void hl_notifier_event_send(struct
hl_notifier_event *notifier_event, u64
notifier_event->events_mask |= event_mask;
if (notifier_event->eventfd)
- eventfd_signal(notifier_event->eventfd, 1);
+ eventfd_signal(notifier_event->eventfd);
mutex_unlock(_event->lock);
}
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index dd7a783d53b5..e73f88050f08 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -1872,7 +1872,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
{
struct eventfd_ctx *trigger = arg;
- eventfd_signal(trigger, 1);
+ eventfd_signal(trigger);
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c b/drivers/gpu/drm/i915/gvt/interrupt.c
index 68eca023bbc6..3d9e09c2add4 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -435,7 +435,7 @@ static int inject_virtual_interrupt(struct intel_vgpu *vgpu)
*/
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
return -ESRCH;
- if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1)
+ if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger) != 1)
return -EFAULT;
return 0;
}
diff --git a/drivers/infiniband/hw/mlx5/devx.c
b/drivers/infiniband/hw/mlx5/devx.c
index db5fb196c728..ad50487790ff 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -2498,7 +2498,7 @@ static void dispatch_event_fd(struct list_head *fd_list,
list_for_each_entry_rcu(item, fd_list, xa_list) {
if (item->eventfd)
- eventfd_signal(item->eventfd, 1);
+ eventfd_signal(item->eventfd);
else
deliver_event(item,
Re: [Intel-gfx] [PATCH v2 0/6] Add DSC PPS readout
On Thu, 13 Jul 2023, Suraj Kandpal wrote: > Up until now we only verified one or two of the dsc pps > params like bits_per_component and bits_per_pixel this > patch series aim to readout almost all PPS param and get > them compared. > Along with that some work on making a common function to > read and write PPS param regiters is also done. There are some issues that I noted, and I'm sure some things could be done differently, but overall I think this makes nice improvements, and it's definitely better than the first version. The further versions will still require detailed review, but the overall approach is now Acked-by: Jani Nikula > > --v2 > -Remove duplicated code and create function that fetches register > and reuse that [Jani] > -move WARN_ON one abstraction layer up [Jani] > -Split patch so that refactor and a new functionality is not added > in the same patch [Jani] > -Add a new refactor patch so that bit shifting can be done in a > clean way [Jani] > > Signed-off-by: Suraj Kandpal > > Suraj Kandpal (6): > drm/i915/vdsc: Refactor dsc register field macro > drm/i915/vdsc: Add a check for dsc split cases > drm/i915/vdsc: Add function to read any PPS register > drm/i915/vdsc: Add function to write in PPS register > drm/i915/vdsc: Fill the intel_dsc_get_pps_config function > drm/i915/display: Compare the readout dsc pps params > > drivers/gpu/drm/i915/display/intel_display.c | 31 + > drivers/gpu/drm/i915/display/intel_vdsc.c | 622 ++ > .../gpu/drm/i915/display/intel_vdsc_regs.h| 101 ++- > 3 files changed, 463 insertions(+), 291 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/vdsc: Add function to read any PPS register
On 7/13/2023 6:17 PM, Jani Nikula wrote:
On Thu, 13 Jul 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]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 276 +++---
1 file changed, 242 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d48b8306bfc3..48273a3618c5 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -303,6 +303,196 @@ 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(struct intel_crtc_state *crtc_state, int pps,
+ int dsc_eng_no, i915_reg_t *dsc_reg)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ bool pipe_dsc;
+
+ pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
+
+ switch (pps) {
+ case 0:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_0(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_0;
+ else
+ *dsc_reg = DSCC_PICTURE_PARAMETER_SET_0;
+ }
+ break;
+ case 1:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_1(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_1(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_1;
+ else
+ *dsc_reg = DSCC_PICTURE_PARAMETER_SET_1;
+ }
+ break;
+ case 2:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_2(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_2(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_2;
+ else
+ *dsc_reg = DSCC_PICTURE_PARAMETER_SET_2;
+ }
+ break;
+ case 3:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_3(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_3(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_3;
+ else
+ *dsc_reg = DSCC_PICTURE_PARAMETER_SET_3;
+ }
+ break;
+ case 4:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_4(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_4(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_4;
+ else
+ *dsc_reg = DSCC_PICTURE_PARAMETER_SET_4;
+ }
+ break;
+ case 5:
+ if (pipe_dsc) {
+ if (dsc_eng_no == 2)
+ *dsc_reg =
ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe);
+ else
+ *dsc_reg =
ICL_DSC0_PICTURE_PARAMETER_SET_5(pipe);
+ } else {
+ if (dsc_eng_no == 2)
+ *dsc_reg = DSCA_PICTURE_PARAMETER_SET_5;
+
Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities
On Wed, 12 Jul 2023, "Srinivas, Vidya" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Wednesday, July 12, 2023 1:44 PM
>> To: Srinivas, Vidya ; intel-
>> g...@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have
>> differing sync polarities
>>
>> On Tue, 11 Jul 2023, Jani Nikula wrote:
>> > On Tue, 11 Jul 2023, Vidya Srinivas wrote:
>> >> v2: Add Jani Nikula's change for quirk for sync polarity
>> >
>> > This was a quick hack suggestion to try. If it works, I think it works
>> > by concidence, because a fastset won't update the sync flags in
>> > TRANS_DDI_FUNC_CTL register. Did not check whether they can even be
>> > updated while the transcoder is enabled.
>>
>> Bspec 49198 seems to indicate TRANS_DDI_FUNC_CTL can be changed
>> without a full mode set.
>>
>> The sync polarity still needs to be modified in the ->update_pipe() hooks.
>
> Hello Jani,
>
> Thank you very much. Apart from sync polarity, VRR panel is doing full
> modeset between
> refresh rates 165 to 60Hz due to vrr.vmin, vrr.vmax, vrr.flipline and
> vrr.guardband mismatch.
> Can VRR panel do seamless fastset between 165Hz and 60Hz? Kindly let me know.
> Thank you.
I think it should be possible, even if the driver does not handle it
properly atm.
Not sure if it can be combined with VRR itself. I guess typically you'd
change the refresh rate instead of fastset when you're using VRR, but if
you're not using VRR, would be great to be able to have DRRS and
fastsets between the modes.
BR,
Jani.
>
> Regards
> Vidya
>>
>>
>> BR,
>> Jani.
>>
>>
>> >
>> >> CC: Jani Nikula
>> >> Credits-to: Jani Nikula
>> >> Signed-off-by: Vidya Srinivas
>> >
>> > It would be useful to have a bug report at fdo gitlab with the EDID
>> > attached.
>> >
>> > BR,
>> > Jani.
>> >
>> >
>> >> ---
>> >> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
>> >> drivers/gpu/drm/i915/display/intel_panel.c | 10 ++
>> >> 2 files changed, 7 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> >> b/drivers/gpu/drm/i915/display/intel_display.c
>> >> index 43cba98f7753..088b45e032aa 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> >> @@ -5234,7 +5234,7 @@ intel_pipe_config_compare(const struct
>> intel_crtc_state *current_config,
>> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
>> >> DRM_MODE_FLAG_INTERLACE);
>> >>
>> >> - if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)) {
>> >> + if (!PIPE_CONF_QUIRK(PIPE_CONFIG_QUIRK_MODE_SYNC_FLAGS)
>> &&
>> >> +!fastset) {
>> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
>> >> DRM_MODE_FLAG_PHSYNC);
>> >>PIPE_CONF_CHECK_FLAGS(hw.adjusted_mode.flags,
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
>> >> b/drivers/gpu/drm/i915/display/intel_panel.c
>> >> index 9232a305b1e6..b9eeaedabd22 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_panel.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
>> >> @@ -112,10 +112,12 @@ intel_panel_fixed_mode(struct intel_connector
>> >> *connector, static bool is_alt_drrs_mode(const struct drm_display_mode
>> *mode,
>> >> const struct drm_display_mode *preferred_mode)
>> {
>> >> - return drm_mode_match(mode, preferred_mode,
>> >> -DRM_MODE_MATCH_TIMINGS |
>> >> -DRM_MODE_MATCH_FLAGS |
>> >> -DRM_MODE_MATCH_3D_FLAGS) &&
>> >> + u32 sync_flags = DRM_MODE_FLAG_PHSYNC |
>> DRM_MODE_FLAG_NHSYNC |
>> >> + DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC;
>> >> +
>> >> + return (mode->flags & ~sync_flags) == (preferred_mode->flags &
>> ~sync_flags) &&
>> >> + mode->hdisplay == preferred_mode->hdisplay &&
>> >> + mode->vdisplay == preferred_mode->vdisplay &&
>> >>mode->clock != preferred_mode->clock; }
>>
>> --
>> Jani Nikula, Intel Open Source Graphics Center
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/vdsc: Add function to read any PPS register
> On Thu, 13 Jul 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]
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 276
> > +++---
> > 1 file changed, 242 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index d48b8306bfc3..48273a3618c5 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -303,6 +303,196 @@ 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(struct intel_crtc_state *crtc_state, int
> pps,
> > + int dsc_eng_no, i915_reg_t *dsc_reg) {
> > + struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > + enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
> > + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > + enum pipe pipe = crtc->pipe;
> > + bool pipe_dsc;
> > +
> > + pipe_dsc = is_pipe_dsc(crtc, cpu_transcoder);
> > +
> > + switch (pps) {
> > + case 0:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_0(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_0(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> DSCA_PICTURE_PARAMETER_SET_0;
> > + else
> > + *dsc_reg =
> DSCC_PICTURE_PARAMETER_SET_0;
> > + }
> > + break;
> > + case 1:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_1(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_1(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> DSCA_PICTURE_PARAMETER_SET_1;
> > + else
> > + *dsc_reg =
> DSCC_PICTURE_PARAMETER_SET_1;
> > + }
> > + break;
> > + case 2:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_2(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_2(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> DSCA_PICTURE_PARAMETER_SET_2;
> > + else
> > + *dsc_reg =
> DSCC_PICTURE_PARAMETER_SET_2;
> > + }
> > + break;
> > + case 3:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_3(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_3(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> DSCA_PICTURE_PARAMETER_SET_3;
> > + else
> > + *dsc_reg =
> DSCC_PICTURE_PARAMETER_SET_3;
> > + }
> > + break;
> > + case 4:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_4(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_4(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> DSCA_PICTURE_PARAMETER_SET_4;
> > + else
> > + *dsc_reg =
> DSCC_PICTURE_PARAMETER_SET_4;
> > + }
> > + break;
> > + case 5:
> > + if (pipe_dsc) {
> > + if (dsc_eng_no == 2)
> > + *dsc_reg =
> ICL_DSC1_PICTURE_PARAMETER_SET_5(pipe);
> > + else
> > + *dsc_reg =
> ICL_DSC0_PICTURE_PARAMETER_SET_5(pipe);
> > + } else {
> > + if (dsc_eng_no == 2)
>
Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/vdsc: Add a check for dsc split cases
> On Thu, 13 Jul 2023, Suraj Kandpal wrote:
> > In intel_vdsc_get_config we only read the primary dsc engine register
> > and not take into account if the other dsc engine is in use and if
> > both registers have the same value or not this patche fixes that by
> > adding a check.
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 15 ++-
> > 1 file changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index 530f3c08a172..d48b8306bfc3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -939,7 +939,7 @@ void intel_dsc_get_config(struct intel_crtc_state
> *crtc_state)
> > enum pipe pipe = crtc->pipe;
> > enum intel_display_power_domain power_domain;
> > intel_wakeref_t wakeref;
> > - u32 dss_ctl1, dss_ctl2, pps0 = 0, pps1 = 0;
> > + u32 dss_ctl1, dss_ctl2, pps0 = 0, pps1 = 0, pps_temp0 = 0, pps_temp1
> > += 1;
> >
> > if (!intel_dsc_source_support(crtc_state))
> > return;
> > @@ -965,11 +965,24 @@ void intel_dsc_get_config(struct intel_crtc_state
> *crtc_state)
> > /* PPS0 & PPS1 */
> > if (!is_pipe_dsc(crtc, cpu_transcoder)) {
> > pps1 = intel_de_read(dev_priv,
> DSCA_PICTURE_PARAMETER_SET_1);
> > + if (crtc_state->dsc.dsc_split) {
> > + pps_temp1 = intel_de_read(dev_priv,
> DSCC_PICTURE_PARAMETER_SET_1);
> > + drm_WARN_ON(_priv->drm, pps1 !=
> pps_temp1);
> > + }
> > +
>
> Superfluous newline.
>
Thanks for the review will fix that
> > } else {
> > pps0 = intel_de_read(dev_priv,
> >
> ICL_DSC0_PICTURE_PARAMETER_SET_0(pipe));
> > pps1 = intel_de_read(dev_priv,
> >
> ICL_DSC0_PICTURE_PARAMETER_SET_1(pipe));
> > + if (crtc_state->dsc.dsc_split) {
> > + pps_temp0 = intel_de_read(dev_priv,
> > +
> ICL_DSC0_PICTURE_PARAMETER_SET_0(pipe));
> > + pps_temp1 = intel_de_read(dev_priv,
> > +
> ICL_DSC0_PICTURE_PARAMETER_SET_1(pipe));
>
> Those are the same two registers as above?
>
Yes they are should have been _DSC1_instead
Regards,
Suraj Kandpal
> BR,
> Jani.
>
> > + drm_WARN_ON(_priv->drm, pps0 !=
> pps_temp0);
> > + drm_WARN_ON(_priv->drm, pps1 !=
> pps_temp1);
> > + }
> > }
> >
> > vdsc_cfg->bits_per_pixel = pps1;
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines
On Thu, 13 Jul 2023, Jani Nikula wrote: > On Thu, 13 Jul 2023, "Bhadane, Dnyaneshwar" > wrote: >>> -Original Message- >>> From: Tvrtko Ursulin >>> Sent: Thursday, July 13, 2023 5:55 PM >>> To: Bhadane, Dnyaneshwar ; Jani Nikula >>> ; intel-gfx@lists.freedesktop.org; Ursulin, >>> Tvrtko >>> Cc: Srivatsa, Anusha ; Shankar, Uma >>> >>> Subject: Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for >>> platform/subplatform defines >>> >>> >>> On 13/07/2023 13:12, Bhadane, Dnyaneshwar wrote: >>> > >>> > >>> >> -Original Message- >>> >> From: Tvrtko Ursulin >>> >> Sent: Thursday, July 13, 2023 5:26 PM >>> >> To: Jani Nikula ; Bhadane, Dnyaneshwar >>> >> ; intel-gfx@lists.freedesktop.org; >>> >> Ursulin, Tvrtko >>> >> Subject: Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for >>> >> platform/subplatform defines >>> >> >>> >> >>> >> On 13/07/2023 10:39, Jani Nikula wrote: >>> >>> On Thu, 13 Jul 2023, Tvrtko Ursulin >>> wrote: >>> On 10/07/2023 14:44, Bhadane, Dnyaneshwar wrote: >>> >> -Original Message- >>> >> From: Bhadane, Dnyaneshwar >>> >> Sent: Monday, July 10, 2023 4:28 PM >>> >> To: intel-gfx@lists.freedesktop.org >>> >> Cc: Ursulin, Tvrtko ; >>> >> jani.nik...@linux.intel.com; Srivatsa, Anusha >>> >> ; Bhadane, Dnyaneshwar >>> >> >>> >> Subject: [v3] drm/i915/mtl: s/MTL/METEORLAKE for >>> >> platform/subplatform defines >>> >> >>> >> Follow consistent naming convention. Replace MTL with >>> METEORLAKE. >>> >> Added defines that are replacing IS_MTL_GRAPHICS_STEP with >>> >> IS_METEORLAKE_P_GRAPHICS_STEP and >>> >> IS_METEORLAKE_M_GRAPHICS_STEP. >>> >> Also replaced IS_METEORLAKE_MEDIA_STEP instead of >>> >> IS_MTL_MEDIA_STEP >>> >> and IS_METEORLAKE_DISPLAY_STEP instead of >>> IS_MTL_DISPLAY_STEP. >>> >> >>> > Hi Tvrtko, >>> > Could you please give the feedback on this ? or suggestion >>> > regarding the >>> >> approach. >>> >>> It's a step in the right direction I just wish we could do all >>> churning in one go. >>> >>> Have you captured IS_CFL and IS_CML in the series? ICL? HSW? Any >>> other I am missing? >>> >>> What have we concluded on Jani's suggestion to split it all to >>> IS_ && IS_? >>> >>> >>> >>> IS_ && IS_ is what I was after. >>> >> >>> >> Yeah I mistyped. I liked that to so would get my ack. >>> >> >>> If you have a) captured all IS_ and b) Jani acks the series >>> too, I guess go ahead. >>> >>> Hm.. what have we concluded to do with IS_JASPERLAKE_EHL? >>> >>> >>> >>> For sure it can't be *that*. It's JSL *or* EHL. Not subplatform. >>> >> >>> >> IS_ELKHARTLAKE would indeed work and platform/subplatform can be >>> >> hidden implementation detail. >>> >> >>> P.S. >>> I still think these suck though: >>> >>> if (IS_METEORLAKE_M_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) || >>> IS_METEORLAKE_P_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) >>> >>> >>> >>> I still find it appealing to a) go towards shorter acronyms instead >>> >>> of long names, and b) to separate platform and stepping checks >>> >>> because they're orthogonal. They're only bundled together for >>> >>> historical reasons, and to keep the conditions shorter. >>> >>> >>> >>> The above could be: >>> >>> >>> >>> if (IS_MTL(i915) && IS_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) >>> >> >>> >> I'd be super pleased with that. >>> > >>> > Could we use the above suggestion for MTL variants for P/M? also >>> replacing MTL with METEORLAKE. >>> > >>> > Using the format: IS_FULL_PLATFORM_NAME && >>> IS_GRAPHICS_STEP(i915, STEP_A0, STEP_B0). >>> > >>> > It will change to : >>> > For M: IS_METEORLAKE_M(i915) && IS_GRAPHICS_STEP(i915, >>> STEP_A0, STEP_B0) >>> > For P: IS_METEORLAKE_P(i915) && IS_GRAPHICS_STEP(i915, >>> STEP_A0, STEP_B0) >>> >>> You could, but you'd only get a meh from me. :) Why you'd insist to keep the >>> two checks? Are we expecting IS_METEROLAKE_ at some point? >> >> For example FILE PATH: drivers/gpu/drm/i915/gt/intel_workarounds.c >> >> Multiple occurrences of IS_MTL_GRAPHICS_STEP(i915, M/P, STEP_B0, >> STEP_FOREVER) >> Where P and M are passed explicitly. That why we can not check >> IS_METEORLAKE() >> as single check. >> IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) || >> IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER)) >> >> The IS_GRAPHICS_STEP is generic macro and used by other platforms also. >> On changing the IS_GRAPHICS_STEP only for MTL variants is lead to affect >> the other >> platform. The IS_METEORLAKE_P(i915) or IS_METEORLAKE_M(i915) solves the >> problem. >> to differentiate the MTL platform variant. > > I've been trying to say all along that we've abstracted the stepping > checks, and we no longer need macros that capture *both* the platform > and the step ranges. They're orthogonal. > > If the stepping ranges to check are the same, you
Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines
On Thu, 13 Jul 2023, "Bhadane, Dnyaneshwar" wrote: >> -Original Message- >> From: Tvrtko Ursulin >> Sent: Thursday, July 13, 2023 5:55 PM >> To: Bhadane, Dnyaneshwar ; Jani Nikula >> ; intel-gfx@lists.freedesktop.org; Ursulin, >> Tvrtko >> Cc: Srivatsa, Anusha ; Shankar, Uma >> >> Subject: Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for >> platform/subplatform defines >> >> >> On 13/07/2023 13:12, Bhadane, Dnyaneshwar wrote: >> > >> > >> >> -Original Message- >> >> From: Tvrtko Ursulin >> >> Sent: Thursday, July 13, 2023 5:26 PM >> >> To: Jani Nikula ; Bhadane, Dnyaneshwar >> >> ; intel-gfx@lists.freedesktop.org; >> >> Ursulin, Tvrtko >> >> Subject: Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for >> >> platform/subplatform defines >> >> >> >> >> >> On 13/07/2023 10:39, Jani Nikula wrote: >> >>> On Thu, 13 Jul 2023, Tvrtko Ursulin >> wrote: >> On 10/07/2023 14:44, Bhadane, Dnyaneshwar wrote: >> >> -Original Message- >> >> From: Bhadane, Dnyaneshwar >> >> Sent: Monday, July 10, 2023 4:28 PM >> >> To: intel-gfx@lists.freedesktop.org >> >> Cc: Ursulin, Tvrtko ; >> >> jani.nik...@linux.intel.com; Srivatsa, Anusha >> >> ; Bhadane, Dnyaneshwar >> >> >> >> Subject: [v3] drm/i915/mtl: s/MTL/METEORLAKE for >> >> platform/subplatform defines >> >> >> >> Follow consistent naming convention. Replace MTL with >> METEORLAKE. >> >> Added defines that are replacing IS_MTL_GRAPHICS_STEP with >> >> IS_METEORLAKE_P_GRAPHICS_STEP and >> >> IS_METEORLAKE_M_GRAPHICS_STEP. >> >> Also replaced IS_METEORLAKE_MEDIA_STEP instead of >> >> IS_MTL_MEDIA_STEP >> >> and IS_METEORLAKE_DISPLAY_STEP instead of >> IS_MTL_DISPLAY_STEP. >> >> >> > Hi Tvrtko, >> > Could you please give the feedback on this ? or suggestion >> > regarding the >> >> approach. >> >> It's a step in the right direction I just wish we could do all >> churning in one go. >> >> Have you captured IS_CFL and IS_CML in the series? ICL? HSW? Any >> other I am missing? >> >> What have we concluded on Jani's suggestion to split it all to >> IS_ && IS_? >> >>> >> >>> IS_ && IS_ is what I was after. >> >> >> >> Yeah I mistyped. I liked that to so would get my ack. >> >> >> If you have a) captured all IS_ and b) Jani acks the series >> too, I guess go ahead. >> >> Hm.. what have we concluded to do with IS_JASPERLAKE_EHL? >> >>> >> >>> For sure it can't be *that*. It's JSL *or* EHL. Not subplatform. >> >> >> >> IS_ELKHARTLAKE would indeed work and platform/subplatform can be >> >> hidden implementation detail. >> >> >> P.S. >> I still think these suck though: >> >> if (IS_METEORLAKE_M_GRAPHICS_STEP(i915, STEP_A0, STEP_B0) || >> IS_METEORLAKE_P_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) >> >>> >> >>> I still find it appealing to a) go towards shorter acronyms instead >> >>> of long names, and b) to separate platform and stepping checks >> >>> because they're orthogonal. They're only bundled together for >> >>> historical reasons, and to keep the conditions shorter. >> >>> >> >>> The above could be: >> >>> >> >>> if (IS_MTL(i915) && IS_GRAPHICS_STEP(i915, STEP_A0, STEP_B0)) >> >> >> >> I'd be super pleased with that. >> > >> > Could we use the above suggestion for MTL variants for P/M? also >> replacing MTL with METEORLAKE. >> > >> > Using the format: IS_FULL_PLATFORM_NAME && >> IS_GRAPHICS_STEP(i915, STEP_A0, STEP_B0). >> > >> > It will change to : >> >For M: IS_METEORLAKE_M(i915) && IS_GRAPHICS_STEP(i915, >> STEP_A0, STEP_B0) >> >For P: IS_METEORLAKE_P(i915) && IS_GRAPHICS_STEP(i915, >> STEP_A0, STEP_B0) >> >> You could, but you'd only get a meh from me. :) Why you'd insist to keep the >> two checks? Are we expecting IS_METEROLAKE_ at some point? > > For example FILE PATH: drivers/gpu/drm/i915/gt/intel_workarounds.c > > Multiple occurrences of IS_MTL_GRAPHICS_STEP(i915, M/P, STEP_B0, STEP_FOREVER) > Where P and M are passed explicitly. That why we can not check IS_METEORLAKE() > as single check. > IS_MTL_GRAPHICS_STEP(i915, M, STEP_B0, STEP_FOREVER) || > IS_MTL_GRAPHICS_STEP(i915, P, STEP_B0, STEP_FOREVER)) > > The IS_GRAPHICS_STEP is generic macro and used by other platforms also. > On changing the IS_GRAPHICS_STEP only for MTL variants is lead to affect > the other > platform. The IS_METEORLAKE_P(i915) or IS_METEORLAKE_M(i915) solves the > problem. > to differentiate the MTL platform variant. I've been trying to say all along that we've abstracted the stepping checks, and we no longer need macros that capture *both* the platform and the step ranges. They're orthogonal. If the stepping ranges to check are the same, you don't need to separate between MTL subplatforms. They'll both match MTL. They'll both match the stepping ranges, and you can use the generic stepping check. You'll need to do if
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Uwe,
Let's add some fuel to keep the thread alive ;-)
On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
wrote:
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > On Wed, 12 Jul 2023, Uwe Kleine-König
> > wrote:
> > > Hello,
> > >
> > > while I debugged an issue in the imx-lcdc driver I was constantly
> > > irritated about struct drm_device pointer variables being named "dev"
> > > because with that name I usually expect a struct device pointer.
> > >
> > > I think there is a big benefit when these are all renamed to "drm_dev".
> > > I have no strong preference here though, so "drmdev" or "drm" are fine
> > > for me, too. Let the bikesheding begin!
> > >
> > > Some statistics:
> > >
> > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq
> > > -c | sort -n
> > > 1 struct drm_device *adev_to_drm
> > > 1 struct drm_device *drm_
> > > 1 struct drm_device *drm_dev
> > > 1 struct drm_device*drm_dev
> > > 1 struct drm_device *pdev
> > > 1 struct drm_device *rdev
> > > 1 struct drm_device *vdev
> > > 2 struct drm_device *dcss_drv_dev_to_drm
> > > 2 struct drm_device **ddev
> > > 2 struct drm_device *drm_dev_alloc
> > > 2 struct drm_device *mock
> > > 2 struct drm_device *p_ddev
> > > 5 struct drm_device *device
> > > 9 struct drm_device * dev
> > > 25 struct drm_device *d
> > > 95 struct drm_device *
> > > 216 struct drm_device *ddev
> > > 234 struct drm_device *drm_dev
> > > 611 struct drm_device *drm
> > >4190 struct drm_device *dev
> > >
> > > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > > it's not only me and others like the result of this effort it should be
> > > followed up by adapting the other structs and the individual usages in
> > > the different drivers.
> >
> > I think this is an unnecessary change. In drm, a dev is usually a drm
> > device, i.e. struct drm_device *.
>
> Well, unless it's not. Prominently there is
>
> struct drm_device {
> ...
> struct device *dev;
> ...
> };
>
> which yields quite a few code locations using dev->dev which is
> IMHO unnecessary irritating:
>
> $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
> 1633
I find that irritating as well...
Same for e.g. crtc->crtc.
Hence that's why I had sent patches to rename the base members in the
shmob_drm-specific subclasses of drm_{crtc,connector,plane} to "base".
https://lore.kernel.org/dri-devel/b3daca80f82625ba14e3aeaf2fca6dcefa056e47.1687423204.git.geert+rene...@glider.be
> Also the functions that deal with both a struct device and a struct
> drm_device often use "dev" for the struct device and then "ddev" for
> the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
I guess you considered "drm_dev", because it is still a short name?
Code dealing with platform devices usually uses "pdev" and "dev".
Same for PCI drivers (despite "pci_dev" being a short name).
So my personal preference goes to "ddev".
EOF (End-of-Fuel ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On 2023-07-12 09:53, Christian König wrote: > Am 12.07.23 um 15:38 schrieb Uwe Kleine-König: >> Hello Maxime, >> >> On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: >>> On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > Background is that this makes merge conflicts easier to handle and detect. Really? >>> FWIW, I agree with Christian here. >>> Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. >>> Not really, because the last patch removed the union anyway. So you have >>> to revert both the last patch, plus that driver one. And then you need >>> to add a TODO to remove that union eventually. >> Yes, with a single patch you have only one revert (but 194 files changed, >> 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 >> file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit >> bigger). (And maybe you get away with just reverting the last patch.) >> >> With a single patch the TODO after a revert is "redo it all again (and >> prepare for a different set of conflicts)" while with the split series >> it's only "fix that one driver that was forgotten/borked" + reapply that >> 10 line patch. > > Yeah, but for a maintainer the size of the patches doesn't matter. > That's only interesting if you need to manually review the patch, which > you hopefully doesn't do in case of something auto-generated. > > In other words if the patch is auto-generated re-applying it completely > is less work than fixing things up individually. > >> As the one who gets that TODO, I prefer the latter. > > Yeah, but your personal preferences are not a technical relevant > argument to a maintainer. > > At the end of the day Dave or Daniel need to decide, because they need > to live with it. > > Regards, > Christian. > >> >> So in sum: If your metric is "small count of reverted commits", you're >> right. If however your metric is: Better get 95% of this series' change >> in than maybe 0%, the split series is the way to do it. >> >> With me having spend ~3h on this series' changes, it's maybe >> understandable that I did it the way I did. >> >> FTR: This series was created on top of v6.5-rc1. If you apply it to >> drm-misc-next you get a (trivial) conflict in patch #2. If I consider to >> be the responsible maintainer who applies this series, I like being able >> to just do git am --skip then. >> >> FTR#2: In drm-misc-next is a new driver >> (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for >> now might indeed be a good idea. >> So I still like the split version better, but I'm open to a more verbose reasoning from your side. >>> You're doing only one thing here, really: you change the name of a >>> structure field. If it was shared between multiple maintainers, then >>> sure, splitting that up is easier for everyone, but this will go through >>> drm-misc, so I can't see the benefit it brings. >> I see your argument, but I think mine weights more. I'm with Maxime and Christian on this--a single action necessitates a single patch. One single movement. As Maxime said "either 0 or 100." As to the name, perhaps "drm_dev" is more descriptive than just "drm". What is "drm"? Ah it's a "dev", as in "drm dev"... Then why not rename it to "drm_dev"? You are renaming it from "dev" to something more descriptive after all. "dev" --> "drm" is no better, but "dev" --> "drm_dev" is just right. -- Regards, Luben
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote: > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > > > Some statistics: > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > -c | sort -n > >1 struct drm_device *adev_to_drm > >1 struct drm_device *drm_ > >1 struct drm_device *drm_dev > >1 struct drm_device*drm_dev > >1 struct drm_device *pdev > >1 struct drm_device *rdev > >1 struct drm_device *vdev > >2 struct drm_device *dcss_drv_dev_to_drm > >2 struct drm_device **ddev > >2 struct drm_device *drm_dev_alloc > >2 struct drm_device *mock > >2 struct drm_device *p_ddev > >5 struct drm_device *device > >9 struct drm_device * dev > > 25 struct drm_device *d > > 95 struct drm_device * > > 216 struct drm_device *ddev > > 234 struct drm_device *drm_dev > > 611 struct drm_device *drm > > 4190 struct drm_device *dev > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > it's not only me and others like the result of this effort it should be > > followed up by adapting the other structs and the individual usages in > > the different drivers. > > > > To make this series a bit easier handleable, I first added an alias for > > drm_crtc::dev, then converted the drivers one after another and the last > > patch drops the "dev" name. This has the advantage of being easier to > > review, and if I should have missed an instance only the last patch must > > be dropped/reverted. Also this series might conflict with other patches, > > in this case the remaining patches can still go in (apart from the last > > one of course). Maybe it also makes sense to delay applying the last > > patch by one development cycle? > > When you automatically generate the patch (with cocci for example) I usually > prefer a single patch instead. Maybe I'm too stupid, but only parts of this patch were created by coccinelle. I failed to convert code like - spin_lock_irq(>dev->event_lock); + spin_lock_irq(>drm_dev->event_lock); Added Julia to Cc, maybe she has a hint?! (Up to now it's only @@ struct drm_crtc *crtc; @@ -crtc->dev +crtc->drm_dev ) > Background is that this makes merge conflicts easier to handle and detect. Really? Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. So I still like the split version better, but I'm open to a more verbose reasoning from your side. > When you have multiple patches and a merge conflict because of some added > lines using the old field the build breaks only on the last patch which > removes the old field. Then you can revert/drop the last patch without having to respin the whole single patch and thus caring for still more conflicts that arise until the new version is sent. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi
Am 12.07.23 um 18:10 schrieb Uwe Kleine-König:
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
Hello,
while I debugged an issue in the imx-lcdc driver I was constantly
irritated about struct drm_device pointer variables being named "dev"
because with that name I usually expect a struct device pointer.
I think there is a big benefit when these are all renamed to "drm_dev".
I have no strong preference here though, so "drmdev" or "drm" are fine
for me, too. Let the bikesheding begin!
Some statistics:
$ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c |
sort -n
1 struct drm_device *adev_to_drm
1 struct drm_device *drm_
1 struct drm_device *drm_dev
1 struct drm_device*drm_dev
1 struct drm_device *pdev
1 struct drm_device *rdev
1 struct drm_device *vdev
2 struct drm_device *dcss_drv_dev_to_drm
2 struct drm_device **ddev
2 struct drm_device *drm_dev_alloc
2 struct drm_device *mock
2 struct drm_device *p_ddev
5 struct drm_device *device
9 struct drm_device * dev
25 struct drm_device *d
95 struct drm_device *
216 struct drm_device *ddev
234 struct drm_device *drm_dev
611 struct drm_device *drm
4190 struct drm_device *dev
This series starts with renaming struct drm_crtc::dev to drm_dev. If
it's not only me and others like the result of this effort it should be
followed up by adapting the other structs and the individual usages in
the different drivers.
I think this is an unnecessary change. In drm, a dev is usually a drm
device, i.e. struct drm_device *.
Well, unless it's not. Prominently there is
struct drm_device {
...
struct device *dev;
...
};
Jani's point is that it's only inconvenient at the first time. Everyone
gets use to it.
Best regards
Thomas
which yields quite a few code locations using dev->dev which is
IMHO unnecessary irritating:
$ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
1633
Also the functions that deal with both a struct device and a struct
drm_device often use "dev" for the struct device and then "ddev" for
the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
If folks insist on following through with this anyway, I'm firmly in the
camp the name should be "drm" and nothing else.
Up to now positive feedback is in the majority.
Best regards
Uwe
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Jani,
On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello,
> >
> > while I debugged an issue in the imx-lcdc driver I was constantly
> > irritated about struct drm_device pointer variables being named "dev"
> > because with that name I usually expect a struct device pointer.
> >
> > I think there is a big benefit when these are all renamed to "drm_dev".
> > I have no strong preference here though, so "drmdev" or "drm" are fine
> > for me, too. Let the bikesheding begin!
> >
> > Some statistics:
> >
> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq
> > -c | sort -n
> > 1 struct drm_device *adev_to_drm
> > 1 struct drm_device *drm_
> > 1 struct drm_device *drm_dev
> > 1 struct drm_device*drm_dev
> > 1 struct drm_device *pdev
> > 1 struct drm_device *rdev
> > 1 struct drm_device *vdev
> > 2 struct drm_device *dcss_drv_dev_to_drm
> > 2 struct drm_device **ddev
> > 2 struct drm_device *drm_dev_alloc
> > 2 struct drm_device *mock
> > 2 struct drm_device *p_ddev
> > 5 struct drm_device *device
> > 9 struct drm_device * dev
> > 25 struct drm_device *d
> > 95 struct drm_device *
> > 216 struct drm_device *ddev
> > 234 struct drm_device *drm_dev
> > 611 struct drm_device *drm
> >4190 struct drm_device *dev
> >
> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> > it's not only me and others like the result of this effort it should be
> > followed up by adapting the other structs and the individual usages in
> > the different drivers.
>
> I think this is an unnecessary change. In drm, a dev is usually a drm
> device, i.e. struct drm_device *.
Well, unless it's not. Prominently there is
struct drm_device {
...
struct device *dev;
...
};
which yields quite a few code locations using dev->dev which is
IMHO unnecessary irritating:
$ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
1633
Also the functions that deal with both a struct device and a struct
drm_device often use "dev" for the struct device and then "ddev" for
the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
> If folks insist on following through with this anyway, I'm firmly in the
> camp the name should be "drm" and nothing else.
Up to now positive feedback is in the majority.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> Hello Jani,
>
> On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
>> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
>> > Hello,
>> >
>> > while I debugged an issue in the imx-lcdc driver I was constantly
>> > irritated about struct drm_device pointer variables being named "dev"
>> > because with that name I usually expect a struct device pointer.
>> >
>> > I think there is a big benefit when these are all renamed to "drm_dev".
>> > I have no strong preference here though, so "drmdev" or "drm" are fine
>> > for me, too. Let the bikesheding begin!
>> >
>> > Some statistics:
>> >
>> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq
>> > -c | sort -n
>> > 1 struct drm_device *adev_to_drm
>> > 1 struct drm_device *drm_
>> > 1 struct drm_device *drm_dev
>> > 1 struct drm_device*drm_dev
>> > 1 struct drm_device *pdev
>> > 1 struct drm_device *rdev
>> > 1 struct drm_device *vdev
>> > 2 struct drm_device *dcss_drv_dev_to_drm
>> > 2 struct drm_device **ddev
>> > 2 struct drm_device *drm_dev_alloc
>> > 2 struct drm_device *mock
>> > 2 struct drm_device *p_ddev
>> > 5 struct drm_device *device
>> > 9 struct drm_device * dev
>> > 25 struct drm_device *d
>> > 95 struct drm_device *
>> > 216 struct drm_device *ddev
>> > 234 struct drm_device *drm_dev
>> > 611 struct drm_device *drm
>> >4190 struct drm_device *dev
>> >
>> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
>> > it's not only me and others like the result of this effort it should be
>> > followed up by adapting the other structs and the individual usages in
>> > the different drivers.
>>
>> I think this is an unnecessary change. In drm, a dev is usually a drm
>> device, i.e. struct drm_device *.
>
> Well, unless it's not. Prominently there is
>
> struct drm_device {
> ...
> struct device *dev;
> ...
> };
>
> which yields quite a few code locations using dev->dev which is
> IMHO unnecessary irritating:
>
> $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
> 1633
>
> Also the functions that deal with both a struct device and a struct
> drm_device often use "dev" for the struct device and then "ddev" for
> the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
Why is specifically struct drm_device *dev so irritating to you?
You lead us to believe it's an outlier in kernel, something that goes
against common kernel style, but it's really not:
$ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn |
head -20
38494 struct device *dev
16388 struct net_device *dev
4184 struct drm_device *dev
2780 struct pci_dev *dev
1916 struct comedi_device *dev
1510 struct mlx5_core_dev *dev
1057 struct mlx4_dev *dev
894 struct b43_wldev *dev
762 struct input_dev *dev
623 struct usbnet *dev
561 struct mlx5_ib_dev *dev
525 struct mt76_dev *dev
465 struct mt76x02_dev *dev
435 struct platform_device *dev
431 struct usb_device *dev
411 struct mt7915_dev *dev
398 struct cx231xx *dev
378 struct mei_device *dev
363 struct ksz_device *dev
359 struct mthca_dev *dev
A good portion of the above also have a dev member.
Are you planning on changing all of the above too, or are you only
annoyed by drm?
I'm really not convinced at all.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Am 12.07.23 um 15:38 schrieb Uwe Kleine-König: Hello Maxime, On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: Background is that this makes merge conflicts easier to handle and detect. Really? FWIW, I agree with Christian here. Each file (apart from include/drm/drm_crtc.h) is only touched once. So unless I'm missing something you don't get less or easier conflicts by doing it all in a single patch. But you gain the freedom to drop a patch for one driver without having to drop the rest with it. Not really, because the last patch removed the union anyway. So you have to revert both the last patch, plus that driver one. And then you need to add a TODO to remove that union eventually. Yes, with a single patch you have only one revert (but 194 files changed, 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit bigger). (And maybe you get away with just reverting the last patch.) With a single patch the TODO after a revert is "redo it all again (and prepare for a different set of conflicts)" while with the split series it's only "fix that one driver that was forgotten/borked" + reapply that 10 line patch. Yeah, but for a maintainer the size of the patches doesn't matter. That's only interesting if you need to manually review the patch, which you hopefully doesn't do in case of something auto-generated. In other words if the patch is auto-generated re-applying it completely is less work than fixing things up individually. As the one who gets that TODO, I prefer the latter. Yeah, but your personal preferences are not a technical relevant argument to a maintainer. At the end of the day Dave or Daniel need to decide, because they need to live with it. Regards, Christian. So in sum: If your metric is "small count of reverted commits", you're right. If however your metric is: Better get 95% of this series' change in than maybe 0%, the split series is the way to do it. With me having spend ~3h on this series' changes, it's maybe understandable that I did it the way I did. FTR: This series was created on top of v6.5-rc1. If you apply it to drm-misc-next you get a (trivial) conflict in patch #2. If I consider to be the responsible maintainer who applies this series, I like being able to just do git am --skip then. FTR#2: In drm-misc-next is a new driver (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for now might indeed be a good idea. So I still like the split version better, but I'm open to a more verbose reasoning from your side. You're doing only one thing here, really: you change the name of a structure field. If it was shared between multiple maintainers, then sure, splitting that up is easier for everyone, but this will go through drm-misc, so I can't see the benefit it brings. I see your argument, but I think mine weights more. Best regards Uwe
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? When you automatically generate the patch (with cocci for example) I usually prefer a single patch instead. Background is that this makes merge conflicts easier to handle and detect. When you have multiple patches and a merge conflict because of some added lines using the old field the build breaks only on the last patch which removes the old field. In such cases reviewing the patch just means automatically re-generating it and double checking that you don't see anything funky. Apart from that I honestly absolutely don't care what the name is. Cheers, Christian. The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. Rather than renaming dev in all the DRM structs, did you consider renaming struct drm_device.dev instead? Everyone in DRM-land knows that 'dev' is the DRM device. But for struct drm_device.dev a more expressive name would be helpful. Maybe 'parent'. (It's also much less churn.) Best regards Thomas I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/renesas: Use struct drm_crtc::drm_dev instead of struct
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! > > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c > | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device*drm_dev > 1 struct drm_device *pdev > 1 struct drm_device *rdev > 1 struct drm_device *vdev > 2 struct drm_device *dcss_drv_dev_to_drm > 2 struct drm_device **ddev > 2 struct drm_device *drm_dev_alloc > 2 struct drm_device *mock > 2 struct drm_device *p_ddev > 5 struct drm_device *device > 9 struct drm_device * dev > 25 struct drm_device *d > 95 struct drm_device * > 216 struct drm_device *ddev > 234 struct drm_device *drm_dev > 611 struct drm_device *drm >4190 struct drm_device *dev > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > it's not only me and others like the result of this effort it should be > followed up by adapting the other structs and the individual usages in > the different drivers. I think this is an unnecessary change. In drm, a dev is usually a drm device, i.e. struct drm_device *. As shown by the numbers above. If folks insist on following through with this anyway, I'm firmly in the camp the name should be "drm" and nothing else. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] (subset) [PATCH v2 00/24] use vmalloc_array and vcalloc
On Tue, 27 Jun 2023 16:43:15 +0200, Julia Lawall wrote:
> The functions vmalloc_array and vcalloc were introduced in
>
> commit a8749a35c399 ("mm: vmalloc: introduce array allocation functions")
>
> but are not used much yet. This series introduces uses of
> these functions, to protect against multiplication overflows.
>
> [...]
Applied to 6.5/scsi-fixes, thanks!
[07/24] scsi: fnic: use vmalloc_array and vcalloc
https://git.kernel.org/mkp/scsi/c/b34c7dcaf311
[24/24] scsi: qla2xxx: use vmalloc_array and vcalloc
https://git.kernel.org/mkp/scsi/c/04d91b783acf
--
Martin K. Petersen Oracle Linux Engineering
[Intel-gfx] [PATCH 1/2] eventfd: simplify eventfd_signal()
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kvm/hyperv.c | 2 +-
arch/x86/kvm/xen.c| 2 +-
drivers/accel/habanalabs/common/device.c | 2 +-
drivers/fpga/dfl.c| 2 +-
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
drivers/infiniband/hw/mlx5/devx.c | 2 +-
drivers/misc/ocxl/file.c | 2 +-
drivers/s390/cio/vfio_ccw_chp.c | 2 +-
drivers/s390/cio/vfio_ccw_drv.c | 4 ++--
drivers/s390/cio/vfio_ccw_ops.c | 6 +++---
drivers/s390/crypto/vfio_ap_ops.c | 2 +-
drivers/usb/gadget/function/f_fs.c| 4 ++--
drivers/vdpa/vdpa_user/vduse_dev.c| 6 +++---
drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c| 2 +-
drivers/vfio/pci/vfio_pci_core.c | 6 +++---
drivers/vfio/pci/vfio_pci_intrs.c | 12 ++--
drivers/vfio/platform/vfio_platform_irq.c | 4 ++--
drivers/vhost/vdpa.c | 4 ++--
drivers/vhost/vhost.c | 10 +-
drivers/vhost/vhost.h | 2 +-
drivers/virt/acrn/ioeventfd.c | 2 +-
fs/aio.c | 2 +-
fs/eventfd.c | 9 +++--
include/linux/eventfd.h | 4 ++--
mm/memcontrol.c | 10 +-
mm/vmpressure.c | 2 +-
samples/vfio-mdev/mtty.c | 4 ++--
virt/kvm/eventfd.c| 4 ++--
28 files changed, 56 insertions(+), 59 deletions(-)
diff --git a/arch/x86/kvm/hyperv.c b/arch/x86/kvm/hyperv.c
index b28fd020066f..2f4bd74b482c 100644
--- a/arch/x86/kvm/hyperv.c
+++ b/arch/x86/kvm/hyperv.c
@@ -2387,7 +2387,7 @@ static u16 kvm_hvcall_signal_event(struct kvm_vcpu *vcpu,
struct kvm_hv_hcall *h
if (!eventfd)
return HV_STATUS_INVALID_PORT_ID;
- eventfd_signal(eventfd, 1);
+ eventfd_signal(eventfd);
return HV_STATUS_SUCCESS;
}
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 40edf4d1974c..a7b62bafd57b 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -2043,7 +2043,7 @@ static bool kvm_xen_hcall_evtchn_send(struct kvm_vcpu
*vcpu, u64 param, u64 *r)
if (ret < 0 && ret != -ENOTCONN)
return false;
} else {
- eventfd_signal(evtchnfd->deliver.eventfd.ctx, 1);
+ eventfd_signal(evtchnfd->deliver.eventfd.ctx);
}
*r = 0;
diff --git a/drivers/accel/habanalabs/common/device.c
b/drivers/accel/habanalabs/common/device.c
index b97339d1f7c6..30357b371d61 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1963,7 +1963,7 @@ static void hl_notifier_event_send(struct
hl_notifier_event *notifier_event, u64
notifier_event->events_mask |= event_mask;
if (notifier_event->eventfd)
- eventfd_signal(notifier_event->eventfd, 1);
+ eventfd_signal(notifier_event->eventfd);
mutex_unlock(_event->lock);
}
diff --git a/drivers/fpga/dfl.c b/drivers/fpga/dfl.c
index dd7a783d53b5..e73f88050f08 100644
--- a/drivers/fpga/dfl.c
+++ b/drivers/fpga/dfl.c
@@ -1872,7 +1872,7 @@ static irqreturn_t dfl_irq_handler(int irq, void *arg)
{
struct eventfd_ctx *trigger = arg;
- eventfd_signal(trigger, 1);
+ eventfd_signal(trigger);
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
b/drivers/gpu/drm/i915/gvt/interrupt.c
index 68eca023bbc6..3d9e09c2add4 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -435,7 +435,7 @@ static int inject_virtual_interrupt(struct intel_vgpu *vgpu)
*/
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
return -ESRCH;
- if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger, 1) != 1)
+ if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger) != 1)
return -EFAULT;
return 0;
}
diff --git a/drivers/infiniband/hw/mlx5/devx.c
b/drivers/infiniband/hw/mlx5/devx.c
index db5fb196c728..ad50487790ff 100644
--- a/drivers/infiniband/hw/mlx5/devx.c
+++ b/drivers/infiniband/hw/mlx5/devx.c
@@ -2498,7 +2498,7 @@ static void dispatch_event_fd(struct list_head *fd_list,
list_for_each_entry_rcu(item, fd_list, xa_list) {
if (item->eventfd)
- eventfd_signal(item->eventfd, 1);
+ eventfd_signal(item->eventfd);
else
deliver_event(item, data);
}
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 6e63f060e4cc..51766db296ab
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > On Wed, Jul 12, 2023 at 12:46:33PM +0200, Christian König wrote: > > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > > Hello, > > > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > > irritated about struct drm_device pointer variables being named "dev" > > > because with that name I usually expect a struct device pointer. > > > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > > I have no strong preference here though, so "drmdev" or "drm" are fine > > > for me, too. Let the bikesheding begin! > > > > > > Some statistics: > > > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > > -c | sort -n > > >1 struct drm_device *adev_to_drm > > >1 struct drm_device *drm_ > > >1 struct drm_device *drm_dev > > >1 struct drm_device*drm_dev > > >1 struct drm_device *pdev > > >1 struct drm_device *rdev > > >1 struct drm_device *vdev > > >2 struct drm_device *dcss_drv_dev_to_drm > > >2 struct drm_device **ddev > > >2 struct drm_device *drm_dev_alloc > > >2 struct drm_device *mock > > >2 struct drm_device *p_ddev > > >5 struct drm_device *device > > >9 struct drm_device * dev > > > 25 struct drm_device *d > > > 95 struct drm_device * > > > 216 struct drm_device *ddev > > > 234 struct drm_device *drm_dev > > > 611 struct drm_device *drm > > > 4190 struct drm_device *dev > > > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > > it's not only me and others like the result of this effort it should be > > > followed up by adapting the other structs and the individual usages in > > > the different drivers. > > > > > > To make this series a bit easier handleable, I first added an alias for > > > drm_crtc::dev, then converted the drivers one after another and the last > > > patch drops the "dev" name. This has the advantage of being easier to > > > review, and if I should have missed an instance only the last patch must > > > be dropped/reverted. Also this series might conflict with other patches, > > > in this case the remaining patches can still go in (apart from the last > > > one of course). Maybe it also makes sense to delay applying the last > > > patch by one development cycle? > > > > When you automatically generate the patch (with cocci for example) I usually > > prefer a single patch instead. > > Maybe I'm too stupid, but only parts of this patch were created by > coccinelle. I failed to convert code like > > - spin_lock_irq(>dev->event_lock); > + spin_lock_irq(>drm_dev->event_lock); > > Added Julia to Cc, maybe she has a hint?! A priori, I see no reason why the rule below should not apply to the above code. Is there a parsing problem in the containing function? You can run spatch --parse-c file.c If there is a paring problem, please let me know and i will try to fix it so the while thing can be done automatically. julia > > (Up to now it's only > > @@ > struct drm_crtc *crtc; > @@ > -crtc->dev > +crtc->drm_dev > > ) > > > Background is that this makes merge conflicts easier to handle and detect. > > Really? Each file (apart from include/drm/drm_crtc.h) is only touched > once. So unless I'm missing something you don't get less or easier > conflicts by doing it all in a single patch. But you gain the freedom to > drop a patch for one driver without having to drop the rest with it. So > I still like the split version better, but I'm open to a more verbose > reasoning from your side. > > > When you have multiple patches and a merge conflict because of some added > > lines using the old field the build breaks only on the last patch which > > removes the old field. > > Then you can revert/drop the last patch without having to respin the > whole single patch and thus caring for still more conflicts that arise > until the new version is sent. > > Best regards > Uwe > > -- > Pengutronix e.K. | Uwe Kleine-König| > Industrial Linux Solutions | https://www.pengutronix.de/ | >
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Maxime, On Wed, Jul 12, 2023 at 02:52:38PM +0200, Maxime Ripard wrote: > On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > > > Background is that this makes merge conflicts easier to handle and detect. > > > > Really? > > FWIW, I agree with Christian here. > > > Each file (apart from include/drm/drm_crtc.h) is only touched once. So > > unless I'm missing something you don't get less or easier conflicts by > > doing it all in a single patch. But you gain the freedom to drop a > > patch for one driver without having to drop the rest with it. > > Not really, because the last patch removed the union anyway. So you have > to revert both the last patch, plus that driver one. And then you need > to add a TODO to remove that union eventually. Yes, with a single patch you have only one revert (but 194 files changed, 1264 insertions(+), 1296 deletions(-)) instead of two (one of them: 1 file changed, 9 insertions(+), 1 deletion(-); the other maybe a bit bigger). (And maybe you get away with just reverting the last patch.) With a single patch the TODO after a revert is "redo it all again (and prepare for a different set of conflicts)" while with the split series it's only "fix that one driver that was forgotten/borked" + reapply that 10 line patch. As the one who gets that TODO, I prefer the latter. So in sum: If your metric is "small count of reverted commits", you're right. If however your metric is: Better get 95% of this series' change in than maybe 0%, the split series is the way to do it. With me having spend ~3h on this series' changes, it's maybe understandable that I did it the way I did. FTR: This series was created on top of v6.5-rc1. If you apply it to drm-misc-next you get a (trivial) conflict in patch #2. If I consider to be the responsible maintainer who applies this series, I like being able to just do git am --skip then. FTR#2: In drm-misc-next is a new driver (drivers/gpu/drm/loongson/lsdc_crtc.c) so skipping the last patch for now might indeed be a good idea. > > So I still like the split version better, but I'm open to a more > > verbose reasoning from your side. > > You're doing only one thing here, really: you change the name of a > structure field. If it was shared between multiple maintainers, then > sure, splitting that up is easier for everyone, but this will go through > drm-misc, so I can't see the benefit it brings. I see your argument, but I think mine weights more. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [Intel-gfx] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 10:52 AM Jani Nikula wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-König wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > > > Some statistics: > > > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq > > -c | sort -n > > 1 struct drm_device *adev_to_drm > > 1 struct drm_device *drm_ > > 1 struct drm_device *drm_dev > > 1 struct drm_device*drm_dev > > 1 struct drm_device *pdev > > 1 struct drm_device *rdev > > 1 struct drm_device *vdev > > 2 struct drm_device *dcss_drv_dev_to_drm > > 2 struct drm_device **ddev > > 2 struct drm_device *drm_dev_alloc > > 2 struct drm_device *mock > > 2 struct drm_device *p_ddev > > 5 struct drm_device *device > > 9 struct drm_device * dev > > 25 struct drm_device *d > > 95 struct drm_device * > > 216 struct drm_device *ddev > > 234 struct drm_device *drm_dev > > 611 struct drm_device *drm > >4190 struct drm_device *dev > > > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > > it's not only me and others like the result of this effort it should be > > followed up by adapting the other structs and the individual usages in > > the different drivers. > > I think this is an unnecessary change. In drm, a dev is usually a drm > device, i.e. struct drm_device *. As shown by the numbers above. > I'd really prefer this patch (series or single) is not accepted. This will cause problems for everyone cherry-picking patches to a downstream kernel (LTS or distro tree). I usually wouldn't expect sympathy here, but the questionable benefit does not outweigh the cost IM[biased]O. Sean > If folks insist on following through with this anyway, I'm firmly in the > camp the name should be "drm" and nothing else. > > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello Thomas, On Wed, Jul 12, 2023 at 12:19:37PM +0200, Thomas Zimmermann wrote: > Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with that name I usually expect a struct device pointer. > > > > I think there is a big benefit when these are all renamed to "drm_dev". > > If you rename drm_crtc.dev, you should also address *all* other data > structures. Yes. Changing drm_crtc::dev was some effort, so I thought to send that one out before doing the same to drm_dp_mst_topology_mgr drm_atomic_state drm_master drm_bridge drm_client_dev drm_connector drm_debugfs_entry drm_encoder drm_fb_helper drm_minor drm_framebuffer drm_gem_object drm_plane drm_property drm_property_blob drm_vblank_crtc when in the end the intention isn't welcome. > > I have no strong preference here though, so "drmdev" or "drm" are fine > > for me, too. Let the bikesheding begin! > > We've discussed this to death. IIRC 'drm' would be the prefered choice. "drm" at least has the advantage to be the 2nd most common name. With Paul Kocialkowski prefering "drm_dev" there is no clear favourite yet. Maybe all the other people with strong opinions are dead if this was "discussed to death" before? :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Am 12.07.23 um 11:46 schrieb Uwe Kleine-König: Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". If you rename drm_crtc.dev, you should also address *all* other data structures. I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! We've discussed this to death. IIRC 'drm' would be the prefered choice. Best regards Thomas Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/renesas: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/rockchip: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/solomon: Use
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Wed, Jul 12, 2023 at 01:02:53PM +0200, Uwe Kleine-König wrote: > > Background is that this makes merge conflicts easier to handle and detect. > > Really? FWIW, I agree with Christian here. > Each file (apart from include/drm/drm_crtc.h) is only touched once. So > unless I'm missing something you don't get less or easier conflicts by > doing it all in a single patch. But you gain the freedom to drop a > patch for one driver without having to drop the rest with it. Not really, because the last patch removed the union anyway. So you have to revert both the last patch, plus that driver one. And then you need to add a TODO to remove that union eventually. > So I still like the split version better, but I'm open to a more > verbose reasoning from your side. You're doing only one thing here, really: you change the name of a structure field. If it was shared between multiple maintainers, then sure, splitting that up is easier for everyone, but this will go through drm-misc, so I can't see the benefit it brings. Maxime signature.asc Description: PGP signature
[Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hello, while I debugged an issue in the imx-lcdc driver I was constantly irritated about struct drm_device pointer variables being named "dev" because with that name I usually expect a struct device pointer. I think there is a big benefit when these are all renamed to "drm_dev". I have no strong preference here though, so "drmdev" or "drm" are fine for me, too. Let the bikesheding begin! Some statistics: $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c | sort -n 1 struct drm_device *adev_to_drm 1 struct drm_device *drm_ 1 struct drm_device *drm_dev 1 struct drm_device*drm_dev 1 struct drm_device *pdev 1 struct drm_device *rdev 1 struct drm_device *vdev 2 struct drm_device *dcss_drv_dev_to_drm 2 struct drm_device **ddev 2 struct drm_device *drm_dev_alloc 2 struct drm_device *mock 2 struct drm_device *p_ddev 5 struct drm_device *device 9 struct drm_device * dev 25 struct drm_device *d 95 struct drm_device * 216 struct drm_device *ddev 234 struct drm_device *drm_dev 611 struct drm_device *drm 4190 struct drm_device *dev This series starts with renaming struct drm_crtc::dev to drm_dev. If it's not only me and others like the result of this effort it should be followed up by adapting the other structs and the individual usages in the different drivers. To make this series a bit easier handleable, I first added an alias for drm_crtc::dev, then converted the drivers one after another and the last patch drops the "dev" name. This has the advantage of being easier to review, and if I should have missed an instance only the last patch must be dropped/reverted. Also this series might conflict with other patches, in this case the remaining patches can still go in (apart from the last one of course). Maybe it also makes sense to delay applying the last patch by one development cycle? The series was compile tested for arm, arm64, powerpc and amd64 using an allmodconfig (though I only build drivers/gpu/). Best regards Uwe Uwe Kleine-König (52): drm/crtc: Start renaming struct drm_crtc::dev to drm_dev drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/armada: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/aspeed: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/exynos: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gma500: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/hyperv: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/ingenic: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/logicvc: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mediatek: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/meson: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mgag200: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/nouveau: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/omapdrm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/panel-ili9341: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/pl111: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/qxl: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/radeon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/renesas: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/rockchip: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/solomon: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sprd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sti: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/stm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev drm/sun4i: Use struct
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Thu, Jul 13, 2023 at 08:52:12AM +0200, Geert Uytterhoeven wrote:
> Hi Uwe,
>
> Let's add some fuel to keep the thread alive ;-)
>
> On Wed, Jul 12, 2023 at 6:13 PM Uwe Kleine-König
> wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> > > I think this is an unnecessary change. In drm, a dev is usually a drm
> > > device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
>
> I find that irritating as well...
>
> Same for e.g. crtc->crtc.
>
> Hence that's why I had sent patches to rename the base members in the
> shmob_drm-specific subclasses of drm_{crtc,connector,plane} to "base".
> https://lore.kernel.org/dri-devel/b3daca80f82625ba14e3aeaf2fca6dcefa056e47.1687423204.git.geert+rene...@glider.be
>
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> I guess you considered "drm_dev", because it is still a short name?
I considered drm_dev because it is still moderately short and a good
approximation of "drm_device". Other than that the main driving force to
pick "drm_dev" was that it's unique enough that I could have done
s/\/$nameofchoice/ on the initial patch and get it mostly
right.
> Code dealing with platform devices usually uses "pdev" and "dev".
> Same for PCI drivers (despite "pci_dev" being a short name).
pci_dev and platform_device both typlically using pdev already annoyed
me in the past. However less than drm_device *dev because for pci_dev +
platform_device there is little overlap.
> So my personal preference goes to "ddev".
I sticked to "drm" for the new series. I think this provides less fuel.
Best regards and thanks for your thoughts,
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |
signature.asc
Description: PGP signature
[Intel-gfx] [PATCH 2/2] eventfd: simplify eventfd_signal_mask()
The eventfd_signal_mask() helper was introduced for io_uring and similar
to eventfd_signal() it always passed 1 for @n. So don't bother with that
argument at all.
Signed-off-by: Christian Brauner
---
drivers/gpu/drm/i915/gvt/interrupt.c | 2 +-
fs/eventfd.c | 9 +
include/linux/eventfd.h | 9 -
io_uring/io_uring.c | 4 ++--
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/interrupt.c
b/drivers/gpu/drm/i915/gvt/interrupt.c
index 3d9e09c2add4..31aff6f733d4 100644
--- a/drivers/gpu/drm/i915/gvt/interrupt.c
+++ b/drivers/gpu/drm/i915/gvt/interrupt.c
@@ -435,7 +435,7 @@ static int inject_virtual_interrupt(struct intel_vgpu *vgpu)
*/
if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
return -ESRCH;
- if (vgpu->msi_trigger && eventfd_signal(vgpu->msi_trigger) != 1)
+ if (vgpu->msi_trigger && !eventfd_signal(vgpu->msi_trigger))
return -EFAULT;
return 0;
}
diff --git a/fs/eventfd.c b/fs/eventfd.c
index dc9e01053235..077be5da72bd 100644
--- a/fs/eventfd.c
+++ b/fs/eventfd.c
@@ -43,9 +43,10 @@ struct eventfd_ctx {
int id;
};
-__u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask)
+bool eventfd_signal_mask(struct eventfd_ctx *ctx, __poll_t mask)
{
unsigned long flags;
+ __u64 n = 1;
/*
* Deadlock or stack overflow issues can happen if we recurse here
@@ -68,7 +69,7 @@ __u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
__poll_t mask)
current->in_eventfd = 0;
spin_unlock_irqrestore(>wqh.lock, flags);
- return n;
+ return n == 1;
}
/**
@@ -82,9 +83,9 @@ __u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
__poll_t mask)
*
* Returns the amount by which the counter was incremented.
*/
-__u64 eventfd_signal(struct eventfd_ctx *ctx)
+bool eventfd_signal(struct eventfd_ctx *ctx)
{
- return eventfd_signal_mask(ctx, 1, 0);
+ return eventfd_signal_mask(ctx, 0);
}
EXPORT_SYMBOL_GPL(eventfd_signal);
diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
index 562089431551..0155ee25f7c8 100644
--- a/include/linux/eventfd.h
+++ b/include/linux/eventfd.h
@@ -35,8 +35,8 @@ void eventfd_ctx_put(struct eventfd_ctx *ctx);
struct file *eventfd_fget(int fd);
struct eventfd_ctx *eventfd_ctx_fdget(int fd);
struct eventfd_ctx *eventfd_ctx_fileget(struct file *file);
-__u64 eventfd_signal(struct eventfd_ctx *ctx);
-__u64 eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n, __poll_t mask);
+bool eventfd_signal(struct eventfd_ctx *ctx);
+bool eventfd_signal_mask(struct eventfd_ctx *ctx, __poll_t mask);
int eventfd_ctx_remove_wait_queue(struct eventfd_ctx *ctx, wait_queue_entry_t
*wait,
__u64 *cnt);
void eventfd_ctx_do_read(struct eventfd_ctx *ctx, __u64 *cnt);
@@ -58,13 +58,12 @@ static inline struct eventfd_ctx *eventfd_ctx_fdget(int fd)
return ERR_PTR(-ENOSYS);
}
-static inline int eventfd_signal(struct eventfd_ctx *ctx)
+static inline bool eventfd_signal(struct eventfd_ctx *ctx)
{
return -ENOSYS;
}
-static inline int eventfd_signal_mask(struct eventfd_ctx *ctx, __u64 n,
- unsigned mask)
+static inline bool eventfd_signal_mask(struct eventfd_ctx *ctx, unsigned mask)
{
return -ENOSYS;
}
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index e8096d502a7c..a9359ef73935 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -537,7 +537,7 @@ static void io_eventfd_ops(struct rcu_head *rcu)
int ops = atomic_xchg(_fd->ops, 0);
if (ops & BIT(IO_EVENTFD_OP_SIGNAL_BIT))
- eventfd_signal_mask(ev_fd->cq_ev_fd, 1, EPOLL_URING_WAKE);
+ eventfd_signal_mask(ev_fd->cq_ev_fd, EPOLL_URING_WAKE);
/* IO_EVENTFD_OP_FREE_BIT may not be set here depending on callback
* ordering in a race but if references are 0 we know we have to free
@@ -573,7 +573,7 @@ static void io_eventfd_signal(struct io_ring_ctx *ctx)
goto out;
if (likely(eventfd_signal_allowed())) {
- eventfd_signal_mask(ev_fd->cq_ev_fd, 1, EPOLL_URING_WAKE);
+ eventfd_signal_mask(ev_fd->cq_ev_fd, EPOLL_URING_WAKE);
} else {
atomic_inc(_fd->refs);
if (!atomic_fetch_or(BIT(IO_EVENTFD_OP_SIGNAL_BIT),
_fd->ops))
--
2.34.1
Re: [Intel-gfx] [Freedreno] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On 12/07/2023 20:31, Sean Paul wrote: >>> 216 struct drm_device *ddev >>> 234 struct drm_device *drm_dev >>> 611 struct drm_device *drm >>>4190 struct drm_device *dev >>> >>> This series starts with renaming struct drm_crtc::dev to drm_dev. If >>> it's not only me and others like the result of this effort it should be >>> followed up by adapting the other structs and the individual usages in >>> the different drivers. >> >> I think this is an unnecessary change. In drm, a dev is usually a drm >> device, i.e. struct drm_device *. As shown by the numbers above. >> > > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. You know, every code cleanup and style adjustment is interfering with backporting. The only argument for a fast-pacing kernel should be whether the developers of this code find it more readable with such cleanup. Best regards, Krzysztof
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
On Thu, Jul 13, 2023 at 12:03:05PM +0300, Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > Hello Jani,
> >
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > Hello,
> >> >
> >> > while I debugged an issue in the imx-lcdc driver I was constantly
> >> > irritated about struct drm_device pointer variables being named "dev"
> >> > because with that name I usually expect a struct device pointer.
> >> >
> >> > I think there is a big benefit when these are all renamed to "drm_dev".
> >> > I have no strong preference here though, so "drmdev" or "drm" are fine
> >> > for me, too. Let the bikesheding begin!
> >> >
> >> > Some statistics:
> >> >
> >> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort |
> >> > uniq -c | sort -n
> >> > 1 struct drm_device *adev_to_drm
> >> > 1 struct drm_device *drm_
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device*drm_dev
> >> > 1 struct drm_device *pdev
> >> > 1 struct drm_device *rdev
> >> > 1 struct drm_device *vdev
> >> > 2 struct drm_device *dcss_drv_dev_to_drm
> >> > 2 struct drm_device **ddev
> >> > 2 struct drm_device *drm_dev_alloc
> >> > 2 struct drm_device *mock
> >> > 2 struct drm_device *p_ddev
> >> > 5 struct drm_device *device
> >> > 9 struct drm_device * dev
> >> > 25 struct drm_device *d
> >> > 95 struct drm_device *
> >> > 216 struct drm_device *ddev
> >> > 234 struct drm_device *drm_dev
> >> > 611 struct drm_device *drm
> >> >4190 struct drm_device *dev
> >> >
> >> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> >> > it's not only me and others like the result of this effort it should be
> >> > followed up by adapting the other structs and the individual usages in
> >> > the different drivers.
> >>
> >> I think this is an unnecessary change. In drm, a dev is usually a drm
> >> device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
> >
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> Why is specifically struct drm_device *dev so irritating to you?
>
> You lead us to believe it's an outlier in kernel, something that goes
> against common kernel style, but it's really not:
>
> $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn |
> head -20
> 38494 struct device *dev
> 16388 struct net_device *dev
>4184 struct drm_device *dev
>2780 struct pci_dev *dev
>1916 struct comedi_device *dev
>1510 struct mlx5_core_dev *dev
>1057 struct mlx4_dev *dev
> 894 struct b43_wldev *dev
> 762 struct input_dev *dev
> 623 struct usbnet *dev
> 561 struct mlx5_ib_dev *dev
> 525 struct mt76_dev *dev
> 465 struct mt76x02_dev *dev
> 435 struct platform_device *dev
> 431 struct usb_device *dev
> 411 struct mt7915_dev *dev
> 398 struct cx231xx *dev
> 378 struct mei_device *dev
> 363 struct ksz_device *dev
> 359 struct mthca_dev *dev
>
> A good portion of the above also have a dev member.
Yeah, other subsystems and drivers have the same problem. You're lucky
that I noticed drm first and invested some effort to improve it. IMHO
other subsystems being bad shouldn't stop drm to improve here.
And note that for example for pci_dev there are 5794 instances that are
named "pdev" and there are 9971 struct platform_device that are called
"pdev", too. So the majority for these does it better. And agreed,
net_device and others are also inconsistent. If you want an area that is
better, look at the naming of i2c_client or spi_device. (And take into
account that these are spread all over the tree and so are not in
control of a single maintainer team.)
> Are you planning on changing all of the above too, or are you only
> annoyed by drm?
Would you be more welcoming if I promised to tackle some of the above,
too? If so: I might. I hesitate a bit because I didn't suffer from the
others. (Apart from asking ctags for "dev" is a nightmare.)
And regarding the second part of your question: I was annoyed by drm
because that was the one that offended me while researching a problem in
a drm driver. And the variable/struct member name irritated me enough to
believe that with consistent naming I would have found it quicker.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Uwe, On Wed 12 Jul 23, 11:46, Uwe Kleine-König wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. Well personally I usually expect that the "dev" member of a subsystem-specific struct refers to a device of that subsystem, so for me having "dev" refer to a drm_device for e.g. drm_crtc makes good sense. I would only expect dev to refer to a struct device in the subsystem-specific device structure (drm_device). I don't think it makes much sense to carry the struct device in any other subsystem-specific structure anyway. So IMO things are fine as-is but this is not a very strong opinion either. > I think there is a big benefit when these are all renamed to "drm_dev". > I have no strong preference here though, so "drmdev" or "drm" are fine > for me, too. Let the bikesheding begin! I would definitely prefer "drm_dev" over "drmdev" (hard to read, feels like aborted camelcase, pretty ugly) or "drm" (too vague). Cheers, Paul > Some statistics: > > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort | uniq -c > | sort -n > 1 struct drm_device *adev_to_drm > 1 struct drm_device *drm_ > 1 struct drm_device *drm_dev > 1 struct drm_device*drm_dev > 1 struct drm_device *pdev > 1 struct drm_device *rdev > 1 struct drm_device *vdev > 2 struct drm_device *dcss_drv_dev_to_drm > 2 struct drm_device **ddev > 2 struct drm_device *drm_dev_alloc > 2 struct drm_device *mock > 2 struct drm_device *p_ddev > 5 struct drm_device *device > 9 struct drm_device * dev > 25 struct drm_device *d > 95 struct drm_device * > 216 struct drm_device *ddev > 234 struct drm_device *drm_dev > 611 struct drm_device *drm >4190 struct drm_device *dev > > This series starts with renaming struct drm_crtc::dev to drm_dev. If > it's not only me and others like the result of this effort it should be > followed up by adapting the other structs and the individual usages in > the different drivers. > > To make this series a bit easier handleable, I first added an alias for > drm_crtc::dev, then converted the drivers one after another and the last > patch drops the "dev" name. This has the advantage of being easier to > review, and if I should have missed an instance only the last patch must > be dropped/reverted. Also this series might conflict with other patches, > in this case the remaining patches can still go in (apart from the last > one of course). Maybe it also makes sense to delay applying the last > patch by one development cycle? > > The series was compile tested for arm, arm64, powerpc and amd64 using an > allmodconfig (though I only build drivers/gpu/). > > Best regards > Uwe > > Uwe Kleine-König (52): > drm/crtc: Start renaming struct drm_crtc::dev to drm_dev > drm/core: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/amd: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/armada: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/arm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/aspeed: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/ast: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/atmel-hlcdc: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/exynos: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/fsl-dcu: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/gma500: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/gud: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/hisilicon: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/hyperv: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/i915: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/imx: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/ingenic: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/kmb: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/logicvc: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/mcde: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/mediatek: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/meson: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/mgag200: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/msm: Use struct drm_crtc::drm_dev instead of struct drm_crtc::dev > drm/mxsfb: Use struct drm_crtc::drm_dev instead of struct > drm_crtc::dev > drm/nouveau: Use struct drm_crtc::drm_dev instead of struct >
[Intel-gfx] [PATCH 0/2] eventfd: simplify signal helpers
Hey everyone, This simplifies the eventfd_signal() and eventfd_signal_mask() helpers by removing the count argument which is effectively unused. --- --- base-commit: 6be357f00aad4189130147fdc6f568cf776a4909 change-id: 20230713-vfs-eventfd-signal-0b0d167ad6ec
Re: [Intel-gfx] [PATCH RFC v1 00/52] drm/crtc: Rename struct drm_crtc::dev to drm_dev
Hi Jani,
On Thu, Jul 13, 2023 at 11:03 AM Jani Nikula wrote:
> On Wed, 12 Jul 2023, Uwe Kleine-König wrote:
> > On Wed, Jul 12, 2023 at 05:34:28PM +0300, Jani Nikula wrote:
> >> On Wed, 12 Jul 2023, Uwe Kleine-König
> >> wrote:
> >> > while I debugged an issue in the imx-lcdc driver I was constantly
> >> > irritated about struct drm_device pointer variables being named "dev"
> >> > because with that name I usually expect a struct device pointer.
> >> >
> >> > I think there is a big benefit when these are all renamed to "drm_dev".
> >> > I have no strong preference here though, so "drmdev" or "drm" are fine
> >> > for me, too. Let the bikesheding begin!
> >> >
> >> > Some statistics:
> >> >
> >> > $ git grep -ohE 'struct drm_device *\* *[^ (),;]*' v6.5-rc1 | sort |
> >> > uniq -c | sort -n
> >> > 1 struct drm_device *adev_to_drm
> >> > 1 struct drm_device *drm_
> >> > 1 struct drm_device *drm_dev
> >> > 1 struct drm_device*drm_dev
> >> > 1 struct drm_device *pdev
> >> > 1 struct drm_device *rdev
> >> > 1 struct drm_device *vdev
> >> > 2 struct drm_device *dcss_drv_dev_to_drm
> >> > 2 struct drm_device **ddev
> >> > 2 struct drm_device *drm_dev_alloc
> >> > 2 struct drm_device *mock
> >> > 2 struct drm_device *p_ddev
> >> > 5 struct drm_device *device
> >> > 9 struct drm_device * dev
> >> > 25 struct drm_device *d
> >> > 95 struct drm_device *
> >> > 216 struct drm_device *ddev
> >> > 234 struct drm_device *drm_dev
> >> > 611 struct drm_device *drm
> >> >4190 struct drm_device *dev
> >> >
> >> > This series starts with renaming struct drm_crtc::dev to drm_dev. If
> >> > it's not only me and others like the result of this effort it should be
> >> > followed up by adapting the other structs and the individual usages in
> >> > the different drivers.
> >>
> >> I think this is an unnecessary change. In drm, a dev is usually a drm
> >> device, i.e. struct drm_device *.
> >
> > Well, unless it's not. Prominently there is
> >
> > struct drm_device {
> > ...
> > struct device *dev;
> > ...
> > };
> >
> > which yields quite a few code locations using dev->dev which is
> > IMHO unnecessary irritating:
> >
> > $ git grep '\dev' v6.5-rc1 drivers/gpu/drm | wc -l
> > 1633
> >
> > Also the functions that deal with both a struct device and a struct
> > drm_device often use "dev" for the struct device and then "ddev" for
> > the drm_device (see for example amdgpu_device_get_pcie_replay_count()).
>
> Why is specifically struct drm_device *dev so irritating to you?
>
> You lead us to believe it's an outlier in kernel, something that goes
> against common kernel style, but it's really not:
>
> $ git grep -how "struct [A-Za-z0-9_]\+ \*dev" | sort | uniq -c | sort -rn |
> head -20
> 38494 struct device *dev
> 16388 struct net_device *dev
>4184 struct drm_device *dev
>2780 struct pci_dev *dev
>1916 struct comedi_device *dev
>1510 struct mlx5_core_dev *dev
>1057 struct mlx4_dev *dev
> 894 struct b43_wldev *dev
> 762 struct input_dev *dev
> 623 struct usbnet *dev
> 561 struct mlx5_ib_dev *dev
> 525 struct mt76_dev *dev
> 465 struct mt76x02_dev *dev
> 435 struct platform_device *dev
> 431 struct usb_device *dev
> 411 struct mt7915_dev *dev
> 398 struct cx231xx *dev
> 378 struct mei_device *dev
> 363 struct ksz_device *dev
> 359 struct mthca_dev *dev
>
> A good portion of the above also have a dev member.
Not all of them access both the foo_device and the device pointers.
Let's put the number of 435 platform_device pointers named "dev"
into perspective:
10095 struct platform_device *pdev
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
