date:20230516

From: Sui Jingfeng <15330273...@189.cn>

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index e0ab555aad2c..41b8066f61ff 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3154,7 +3154,7 @@ int drm_atomic_helper_update_plane(struct drm_plane 
*plane,
 EXPORT_SYMBOL(drm_atomic_helper_update_plane);
 
 /**
- * drm_atomic_helper_disable_plane - Helper for primary plane disable using * 
atomic
+ * drm_atomic_helper_disable_plane - Helper for primary plane disable using 
atomic
  * @plane: plane to disable
  * @ctx: lock acquire context
  *
-- 
2.25.1

RE: [Freedreno] [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters



> -Original Message-
> From: Dmitry Baryshkov 
> Sent: Wednesday, May 17, 2023 5:33 AM
> To: Kandpal, Suraj ; David Airlie
> ; Daniel Vetter ; Jani Nikula
> ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; Rob Clark
> ; Abhinav Kumar ;
> Sean Paul ; Marijn Suijten
> 
> Cc: linux-arm-...@vger.kernel.org; intel-...@lists.freedesktop.org;
> freedr...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Ville
> Syrjälä 
> Subject: Re: [Freedreno] [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and
> DSC 1.1 (pre-SCR) parameters
> 
> On 16/05/2023 21:46, Kandpal, Suraj wrote:
> >>
> >> The array of rc_parameters contains a mixture of parameters from DSC
> >> 1.1 and DSC 1.2 standards. Split these tow configuration arrays in
> >> preparation to adding more configuration data.
> >>
> >
> > Hi ,
> > Needed to add some more comments apart from the previous ones
> already
> > given
> >
> 
> [skipped]
> 
> 
> >> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> index d4340b18c18d..bd9116d2cd76 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> >> @@ -226,7 +226,15 @@ int intel_dsc_compute_params(struct
> >> intel_crtc_state *pipe_config)
> >>if (DISPLAY_VER(dev_priv) >= 13) {
> >>calculate_rc_params(vdsc_cfg);
> >>} else {
> >> -  ret = drm_dsc_setup_rc_params(vdsc_cfg);
> >> +  if ((compressed_bpp == 8 ||
> >> +   compressed_bpp == 12) &&
> >> +  (vdsc_cfg->bits_per_component == 8 ||
> >> +   vdsc_cfg->bits_per_component == 10 ||
> >> +   vdsc_cfg->bits_per_component == 12))
> >> +  ret = drm_dsc_setup_rc_params(vdsc_cfg,
> >> DRM_DSC_1_1_PRE_SCR);
> >> +  else
> >> +  ret = drm_dsc_setup_rc_params(vdsc_cfg,
> >> DRM_DSC_1_2_444);
> >> +
> >
> > I do not think this kind of assignment works as you will also be
> > adding
> > DRM_DSC_1_2_422 and DRM_DSC_1_2_420 in further patches and AFAICS
> > There is no where in patch 8 that you have accounted for when 422 or 420
> will be used.
> > Maybe you can add an if case inside the else block to check
> > pipe_config->output_format to pass the rc_param_data in patch 8
> 
> I don't think this is necessary for now. The driver doesn't support YUV 422.
> The YUV 420 is supported only for DISPLAY_VER(dev_priv) >= 14, however
> these helpers are only used for DISPLAY_VER(dev_priv) < 13.
> 
> I did not move RC calculation to drm_dsc_helpers.c (yet ?), which is used for
> DISPLAY_VER >= 13.

Hmm. I see I'll work on it once this patch series is merged

Regards,
Suraj Kandpal
> 
> >
> > Regards,
> > Suraj Kandpal
> >>if (ret)
> >>return ret;
> >>
> >> diff --git a/include/drm/display/drm_dsc_helper.h
> >> b/include/drm/display/drm_dsc_helper.h
> >> index 1681791f65a5..c634bb2935d3 100644
> >> --- a/include/drm/display/drm_dsc_helper.h
> >> +++ b/include/drm/display/drm_dsc_helper.h
> >> @@ -10,12 +10,17 @@
> >>
> >>   #include 
> >>
> >> +enum drm_dsc_params_kind {
> >> +  DRM_DSC_1_2_444,
> >> +  DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */ };
> >> +
> >>   void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);
> >> int
> >> drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8
> >> rc_buffer_size); void drm_dsc_pps_payload_pack(struct
> >> drm_dsc_picture_parameter_set *pps_sdp,
> >>  const struct drm_dsc_config *dsc_cfg);  void
> >> drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg); -int
> >> drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
> >> +int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
> >> +drm_dsc_params_kind kind);
> >>   int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
> >>
> >>   #endif /* _DRM_DSC_HELPER_H_ */
> >> --
> >> 2.39.2
> >
> 
> --
> With best wishes
> Dmitry

RE: [PATCH v6 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

> 
> The array of rc_parameters contains a mixture of parameters from DSC 1.1
> and DSC 1.2 standards. Split these tow configuration arrays in preparation to
> adding more configuration data.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/gpu/drm/display/drm_dsc_helper.c  | 139 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
>  include/drm/display/drm_dsc_helper.h  |   7 +-
>  3 files changed, 129 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index acb93d4116e0..f9d01d72c1ff 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -325,10 +325,88 @@ struct rc_parameters_data {
>  #define DSC_BPP(bpp) ((bpp) << 4)
> 
>  /*
> - * Selected Rate Control Related Parameter Recommended Values
> - * from DSC_v1.11 spec & C Model release: DSC_model_20161212
> + * Rate Control Related Parameter Recommended Values from DSC_v1.1
> spec
> + prior
> + * to DSC 1.1 fractional bpp underflow SCR (DSC_v1.1_E1.pdf)
> + *
> + * Cross-checked against C Model releases: DSC_model_20161212 and
> + 20210623
>   */
> -static const struct rc_parameters_data rc_parameters[] = {
> +static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> + {
> + .bpp = DSC_BPP(8), .bpc = 8,
> + { 512, 12, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
> -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 10,
> + { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> +  * DSC model/pre-SCR-cfg has 8 for
> range_max_qp[0], however
> +  * VESA DSC 1.1 Table E-5 sets it to 4.
> +  */
> + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
> -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 12,
> + { 512, 12, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 8,
> + { 341, 15, 2048, 3, 12, 11, 11, {
> + { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
> + { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
> 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 10,
> + { 341, 15, 2048, 7, 16, 15, 15, {
> + { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
> + { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
> },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 12,
> + { 341, 15, 2048, 11, 20, 19, 19, {
> + { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
> + { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + { /* sentinel */ }
> +};
> +
> +/*
> + * Selected Rate Control Related Parameter Recommended Values from DSC
> +v1.2, v1.2a, v1.2b and
> + * DSC_v1.1_E1 specs.
> + *
> + * Cross-checked against C Model releases: DSC_model_20161212 and
> +20210623  */ static const struct rc_parameters_data
> +rc_parameters_1_2_444[] = {
>   {
>   .bpp = DSC_BPP(6), .bpc = 8,
>   { 768, 15, 6144, 3, 13, 11, 11, {
> @@ -388,22 +466,18 @@ static const struct

Re: [PATCH V6 0/6] drm: bridge: samsung-dsim: Support variable clocking

2023-05-16 Thread Adam Ford

On Tue, May 16, 2023 at 5:57 PM Marek Szyprowski
 wrote:
>
> On 16.05.2023 01:57, Adam Ford wrote:
> > This series fixes the blanking pack size and the PMS calculation.  It then
> > adds support to allows the DSIM to dynamically DPHY clocks, and support
> > non-burst mode while allowing the removal of the hard-coded clock values
> > for the PLL for imx8m mini/nano/plus, and it allows the removal of the
> > burst-clock device tree entry when burst-mode isn't supported by connected
> > devices like an HDMI brige.  In that event, the HS clock is set to the
> > value requested by the bridge chip.
> >
> > This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should
> > work on i.MX8M Mini as well. Marek Szyprowski has tested it on various
> > Exynos boards.
> >
> > Adam Ford (5):
> >drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
> >drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
> >drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY
> >drm: bridge: samsung-dsim: Dynamically configure DPHY timing
> >drm: bridge: samsung-dsim: Support non-burst mode
> >
> > Lucas Stach (1):
> >drm: bridge: samsung-dsim: fix blanking packet size calculation
> >
> >   drivers/gpu/drm/bridge/Kconfig|   1 +
> >   drivers/gpu/drm/bridge/samsung-dsim.c | 143 +-
> >   include/drm/bridge/samsung-dsim.h |   4 +
> >   3 files changed, 125 insertions(+), 23 deletions(-)
>
> Feel free to add to all patches:
>
> Tested-by: Marek Szyprowski 

Thanks for all your help testing.  I hope the V7 will be the last
attempt.  I've fixed the repeated declaration in patch 6, and added
your t-b statements to each of the patches with code changes.

I'm hoping to push V7 in a day or two pending any more feedback.

adam
>
>
> > V6:  Squash-in an additional error fix from Lucas Stach regarding the
> >   DPHY calcuations.  Remove the dynamic_dphy variable and let
> >   everyone use the new calculations.  Move the hs_clock caching
> >   from patch 6 to patch 5 to go along with the DPHY calcuations
> >   since they are now based on the recorded hs_clock rate.
> >
> > V5:  Update error message to dev_info and change them to indicate
> >   what is happening without sounding like an error when optional
> >   device tree entries are missing.
> >
> > V4:  Undo some accidental whitespace changes, rename PS_TO_CYCLE
> >   variables to ps and hz from PS and MHz. Remove if check
> >   before the samsung_dsim_set_phy_ctrl call since it's
> >   unnecessary.
> >   Added additional tested-by and reviewed-by comments.
> >   Squash patches 6 and 7 together since the supporting
> >   non-burst (patch 6) mode doesn't really work until
> >   patch 7 was applied.
> >
> > V3:  When checking if the bust-clock is present, only check for it
> >   in the device tree, and don't check the presence of the
> >   MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos
> >   board.
> >
> >   Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in
> >   Kconfig otherwise the build breaks on the 32-bit Exynos.
> >
> >   Change vco_min variable name to min_freq
> >
> >   Added tested-by from Chen-Yu Tsai
> >
> > V2:  Instead of using my packet blanking calculation, this integrates
> >   on from Lucas Stach which gets modified later in the series to
> >   cache the value of the HS-clock instead of having to do the
> >   calucations again.
> >
> >   Instead of completely eliminating the PLL clock frequency from
> >   the device tree, this makes it optional to avoid breaking some
> >   Samsung devices.  When the samsung,pll-clock-frequency is not
> >   found, it reads the value of the clock named "sclk_mipi"
> >   This also maintains backwards compatibility with older device
> >   trees.
> >
> >   This also changes the DPHY calcuation from a Look-up table,
> >   a reverse engineered algorithm which uses
> >   phy_mipi_dphy_get_default_config to determine the standard
> >   nominal values and calculates the cycles necessary to update
> >   the DPHY timings accordingly.
> >
>
> Best regards
> --
> Marek Szyprowski, PhD
> Samsung R Institute Poland
>

Re: [PATCH V6 5/6] drm: bridge: samsung-dsim: Dynamically configure DPHY timing

2023-05-16 Thread Adam Ford

On Mon, May 15, 2023 at 6:57 PM Adam Ford  wrote:
>
> The DPHY timings are currently hard coded. Since the input
> clock can be variable, the phy timings need to be variable
> too.  To facilitate this, we need to cache the hs_clock
> based on what is generated from the PLL.
>
> The phy_mipi_dphy_get_default_config_for_hsclk function
> configures the DPHY timings in pico-seconds, and a small macro
> converts those timings into clock cycles based on the hs_clk.
>
> Signed-off-by: Adam Ford 
> Signed-off-by: Lucas Stach 
> Tested-by: Chen-Yu Tsai 
> Tested-by: Frieder Schrempf 
> Reviewed-by: Frieder Schrempf 
> Tested-by: Michael Walle 
> ---
>  drivers/gpu/drm/bridge/samsung-dsim.c | 57 +++
>  include/drm/bridge/samsung-dsim.h |  1 +
>  2 files changed, 51 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> b/drivers/gpu/drm/bridge/samsung-dsim.c
> index 08266303c261..3944b7cfbbdf 100644
> --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> @@ -218,6 +218,8 @@
>
>  #define OLD_SCLK_MIPI_CLK_NAME "pll_clk"
>
> +#define PS_TO_CYCLE(ps, hz) DIV64_U64_ROUND_CLOSEST(((ps) * (hz)), 
> 1ULL)
> +
>  static const char *const clk_names[5] = {
> "bus_clk",
> "sclk_mipi",
> @@ -651,6 +653,8 @@ static unsigned long samsung_dsim_set_pll(struct 
> samsung_dsim *dsi,
> reg = samsung_dsim_read(dsi, DSIM_STATUS_REG);
> } while ((reg & DSIM_PLL_STABLE) == 0);
>
> +   dsi->hs_clock = fout;
> +
> return fout;
>  }
>
> @@ -698,13 +702,46 @@ static void samsung_dsim_set_phy_ctrl(struct 
> samsung_dsim *dsi)
> const struct samsung_dsim_driver_data *driver_data = dsi->driver_data;
> const unsigned int *reg_values = driver_data->reg_values;
> u32 reg;
> +   struct phy_configure_opts_mipi_dphy cfg;
> +   int clk_prepare, lpx, clk_zero, clk_post, clk_trail;
> +   int hs_exit, hs_prepare, hs_zero, hs_trail;
> +   unsigned long long byte_clock = dsi->hs_clock / 8;
>
> if (driver_data->has_freqband)
> return;
>
> +   phy_mipi_dphy_get_default_config_for_hsclk(dsi->hs_clock,
> +  dsi->lanes, );
> +
> +   /*
> +* TODO:
> +* The tech reference manual for i.MX8M Mini/Nano/Plus
> +* doesn't state what the definition of the PHYTIMING
> +* bits are beyond their address and bit position.
> +* After reviewing NXP's downstream code, it appears
> +* that the various PHYTIMING registers take the number
> +* of cycles and use various dividers on them.  This
> +* calculation does not result in an exact match to the
> +* downstream code, but it is very close, and it appears
> +* to sync at a variety of resolutions. If someone
> +* can get a more accurate mathematical equation needed
> +* for these registers, this should be updated.
> +*/

Marek Szyprowski -

I was curious to know if you have any opinion on this TODO note and/or
if you have any stuff you can share about how the values of the
following variables are configured?
> +
> +   lpx = PS_TO_CYCLE(cfg.lpx, byte_clock);
> +   hs_exit = PS_TO_CYCLE(cfg.hs_exit, byte_clock);
> +   clk_prepare = PS_TO_CYCLE(cfg.clk_prepare, byte_clock);
> +   clk_zero = PS_TO_CYCLE(cfg.clk_zero, byte_clock);
> +   clk_post = PS_TO_CYCLE(cfg.clk_post, byte_clock);
> +   clk_trail = PS_TO_CYCLE(cfg.clk_trail, byte_clock);
> +   hs_prepare = PS_TO_CYCLE(cfg.hs_prepare, byte_clock);
> +   hs_zero = PS_TO_CYCLE(cfg.hs_zero, byte_clock);
> +   hs_trail = PS_TO_CYCLE(cfg.hs_trail, byte_clock);
> +

These 'work' but they don't exactly match the NXP reference code, but
they're not significantly different.  The NXP reference manual doesn't
describe how these registers are set, they only publish the register
and bits used.  Since you work for Samsung, I was hoping you might
have inside information to know if this is a reasonable approach.

thanks

adam

> /* B D-PHY: D-PHY Master & Slave Analog Block control */
> reg = reg_values[PHYCTRL_ULPS_EXIT] | reg_values[PHYCTRL_VREG_LP] |
> reg_values[PHYCTRL_SLEW_UP];
> +
> samsung_dsim_write(dsi, DSIM_PHYCTRL_REG, reg);
>
> /*
> @@ -712,7 +749,9 @@ static void samsung_dsim_set_phy_ctrl(struct samsung_dsim 
> *dsi)
>  * T HS-EXIT: Time that the transmitter drives LP-11 following a HS
>  *  burst
>  */
> -   reg = reg_values[PHYTIMING_LPX] | reg_values[PHYTIMING_HS_EXIT];
> +
> +   reg  = DSIM_PHYTIMING_LPX(lpx) | DSIM_PHYTIMING_HS_EXIT(hs_exit);
> +
> samsung_dsim_write(dsi, DSIM_PHYTIMING_REG, reg);
>
> /*
> @@ -728,10 +767,11 @@ static void samsung_dsim_set_phy_ctrl(struct 
> samsung_dsim *dsi)
>  * T CLK-TRAIL: Time that the transmitter drives the

Re: [v2,11/12] drm/fbdev-generic: Implement dedicated fbdev I/O helpers


Hi, Thomas


After apply your patch set, the kernel with 
arch/loongarch/configs/loongson3_defconfig


can not finish compile anymore.  gcc complains:


  AR  drivers/gpu/built-in.a
  AR  drivers/built-in.a
  AR  built-in.a
  AR  vmlinux.a
  LD  vmlinux.o
  OBJCOPY modules.builtin.modinfo
  GEN modules.builtin
  GEN .vmlinux.objs
  MODPOST Module.symvers
ERROR: modpost: "fb_sys_write" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!
ERROR: modpost: "sys_imageblit" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!
ERROR: modpost: "sys_fillrect" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!
ERROR: modpost: "sys_copyarea" [drivers/gpu/drm/drm_kms_helper.ko] 
undefined!

ERROR: modpost: "fb_sys_read" [drivers/gpu/drm/drm_kms_helper.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2


On 2023/5/15 17:40, Thomas Zimmermann wrote:

Implement dedicated fbdev helpers for framebuffer I/O instead
of using DRM's helpers. Fbdev-generic was the only caller of the
DRM helpers, so remove them from the helper module.

v2:
* use FB_SYS_HELPERS_DEFERRED option

Signed-off-by: Thomas Zimmermann 
---
  drivers/gpu/drm/Kconfig |   6 +-
  drivers/gpu/drm/drm_fb_helper.c | 107 
  drivers/gpu/drm/drm_fbdev_generic.c |  47 ++--
  include/drm/drm_fb_helper.h |  41 ---
  4 files changed, 43 insertions(+), 158 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 77fb10ddd8a2..92a782827b7b 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -95,6 +95,7 @@ config DRM_KUNIT_TEST
  config DRM_KMS_HELPER
tristate
depends on DRM
+   select FB_SYS_HELPERS_DEFERRED if DRM_FBDEV_EMULATION


Here, select FB_SYS_HELPERS helps resolve the above issue mentioned.


help
  CRTC helpers for KMS drivers.
  
@@ -135,11 +136,6 @@ config DRM_FBDEV_EMULATION

select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-   select FB_DEFERRED_IO
-   select FB_SYS_FOPS
-   select FB_SYS_FILLRECT
-   select FB_SYS_COPYAREA
-   select FB_SYS_IMAGEBLIT
select FRAMEBUFFER_CONSOLE if !EXPERT
select FRAMEBUFFER_CONSOLE_DETECT_PRIMARY if FRAMEBUFFER_CONSOLE
default y
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8724e08c518b..ba0a808f14ee 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -729,113 +729,6 @@ void drm_fb_helper_deferred_io(struct fb_info *info, 
struct list_head *pagerefli
  }
  EXPORT_SYMBOL(drm_fb_helper_deferred_io);
  
-/**

- * drm_fb_helper_sys_read - Implements struct _ops.fb_read for system memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to read from framebuffer memory
- * @count: number of bytes to read from framebuffer memory
- * @ppos: read offset within framebuffer memory
- *
- * Returns:
- * The number of bytes read on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_read(struct fb_info *info, char __user *buf,
-  size_t count, loff_t *ppos)
-{
-   return fb_sys_read(info, buf, count, ppos);
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_read);
-
-/**
- * drm_fb_helper_sys_write - Implements struct _ops.fb_write for system 
memory
- * @info: fb_info struct pointer
- * @buf: userspace buffer to write to framebuffer memory
- * @count: number of bytes to write to framebuffer memory
- * @ppos: write offset within framebuffer memory
- *
- * Returns:
- * The number of bytes written on success, or an error code otherwise.
- */
-ssize_t drm_fb_helper_sys_write(struct fb_info *info, const char __user *buf,
-   size_t count, loff_t *ppos)
-{
-   struct drm_fb_helper *helper = info->par;
-   loff_t pos = *ppos;
-   ssize_t ret;
-   struct drm_rect damage_area;
-
-   ret = fb_sys_write(info, buf, count, ppos);
-   if (ret <= 0)
-   return ret;
-
-   if (helper->funcs->fb_dirty) {
-   drm_fb_helper_memory_range_to_clip(info, pos, ret, 
_area);
-   drm_fb_helper_damage(helper, damage_area.x1, damage_area.y1,
-drm_rect_width(_area),
-drm_rect_height(_area));
-   }
-
-   return ret;
-}
-EXPORT_SYMBOL(drm_fb_helper_sys_write);
-
-/**
- * drm_fb_helper_sys_fillrect - wrapper around sys_fillrect
- * @info: fbdev registered by the helper
- * @rect: info about rectangle to fill
- *
- * A wrapper around sys_fillrect implemented by fbdev core
- */
-void drm_fb_helper_sys_fillrect(struct fb_info *info,
-   const struct fb_fillrect *rect)
-{
-   struct drm_fb_helper *helper = info->par;
-
-   sys_fillrect(info, rect);
-
-   if (helper->funcs->fb_dirty)
-

Re: [PATCH v10 4/8] drm/msm: Add MSM-specific DSC helper methods





On 5/16/2023 3:49 PM, Marijn Suijten wrote:

On 2023-05-16 01:07:05, Dmitry Baryshkov wrote:


On 16/05/2023 01:01, Marijn Suijten wrote:

On 2023-05-15 13:29:21, Jessica Zhang wrote:


Const, as requested elsewhere.  But this function is not used anywhere
in any of the series (because we replaced the usages with more sensible
member accesses like slice_chunk_size).


Acked.

I would prefer to keep this helper so that we have a way to easily get
BPP information from the DRM DSC config in the future, but if you'd
prefer we add this helper then, I'm also ok with that.


The inverse helper is available ad DSC_BPP in drm_dsc_helper.c.  Perhaps
we can move the two variants to the header and define them uniformly?
This isn't MSM-specific it seems (i.e. the format supports fractional
bpp but no RC parameters appear to be defined for such a format yet).


I think DSC_BPP was removed (around v2 or v3 if I read changelog correctly).


Seems like it was removed at some point indeed, and now the helper file
picked up an identically named DSC_BPP macro but with the inverse
implementation :) - at least it's a *.c file.

Perhaps we can make it more consistent by defining both ways with
concise macros in a header.


The changes in this series don't touch DSC_BPP so I think moving that 
might be a change for another time, but I can at least move 
msm_dsc_get_bpp_int to drm_dsc_helper.h.


Thanks,

Jessica Zhang




As for the fraction-point BPP, I think AMD supports .5 bpp granularity,
see drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h


That won't use the helper then.


With best wishes
Dmitry


- Marijn

[PATCH v6 5/8] drm/display/dsc: use flat array for rc_parameters lookup

Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 228 +++
 1 file changed, 108 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 122a292bbc8f..acb93d4116e0 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,24 +305,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
-enum ROW_INDEX_BPP {
-   ROW_INDEX_6BPP = 0,
-   ROW_INDEX_8BPP,
-   ROW_INDEX_10BPP,
-   ROW_INDEX_12BPP,
-   ROW_INDEX_15BPP,
-   MAX_ROW_INDEX
-};
-
-enum COLUMN_INDEX_BPC {
-   COLUMN_INDEX_8BPC = 0,
-   COLUMN_INDEX_10BPC,
-   COLUMN_INDEX_12BPC,
-   COLUMN_INDEX_14BPC,
-   COLUMN_INDEX_16BPC,
-   MAX_COLUMN_INDEX
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -334,21 +316,31 @@ struct rc_parameters {
struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
 };
 
+struct rc_parameters_data {
+   u8 bpp;
+   u8 bpc;
+   struct rc_parameters params;
+};
+
+#define DSC_BPP(bpp)   ((bpp) << 4)
+
 /*
  * Selected Rate Control Related Parameter Recommended Values
  * from DSC_v1.11 spec & C Model release: DSC_model_20161212
  */
-static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters_data rc_parameters[] = {
{
-   /* 6BPP/8BPC */
+   .bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
{ 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
{ 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
{ 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
{ 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
}
-   },
-   /* 6BPP/10BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
{ 768, 15, 6144, 7, 17, 15, 15, {
{ 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
{ 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
@@ -356,8 +348,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
{ 17, 18, -12 }
}
-   },
-   /* 6BPP/12BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
{ 768, 15, 6144, 11, 21, 19, 19, {
{ 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
{ 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
@@ -365,8 +359,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
{ 21, 22, -12 }
}
-   },
-   /* 6BPP/14BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
{ 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
@@ -374,8 +370,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
{ 25, 26, -12 }
}
-   },
-   /* 6BPP/16BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
{ 768, 15, 6144, 19, 29, 27, 27, {
{ 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
{ 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
@@ -383,18 +381,20 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
{ 29, 30, -12 }
}
-   },
+   }
},
{
-   /* 8BPP/8BPC */
+   .bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3,

[PATCH v6 3/8] drm/i915/dsc: move DSC tables to DRM DSC helper

Move DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 372 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
 include/drm/display/drm_dsc_helper.h  |   1 +
 3 files changed, 380 insertions(+), 312 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index be91abe2cfb2..122a292bbc8f 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,6 +305,378 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
+enum ROW_INDEX_BPP {
+   ROW_INDEX_6BPP = 0,
+   ROW_INDEX_8BPP,
+   ROW_INDEX_10BPP,
+   ROW_INDEX_12BPP,
+   ROW_INDEX_15BPP,
+   MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+   COLUMN_INDEX_8BPC = 0,
+   COLUMN_INDEX_10BPC,
+   COLUMN_INDEX_12BPC,
+   COLUMN_INDEX_14BPC,
+   COLUMN_INDEX_16BPC,
+   MAX_COLUMN_INDEX
+};
+
+struct rc_parameters {
+   u16 initial_xmit_delay;
+   u8 first_line_bpg_offset;
+   u16 initial_offset;
+   u8 flatness_min_qp;
+   u8 flatness_max_qp;
+   u8 rc_quant_incr_limit0;
+   u8 rc_quant_incr_limit1;
+   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values
+ * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ */
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+   {
+   /* 6BPP/8BPC */
+   { 768, 15, 6144, 3, 13, 11, 11, {
+   { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
+   { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
+   { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
+   { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
+   }
+   },
+   /* 6BPP/10BPC */
+   { 768, 15, 6144, 7, 17, 15, 15, {
+   { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
+   { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
+   { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
+   { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
+   { 17, 18, -12 }
+   }
+   },
+   /* 6BPP/12BPC */
+   { 768, 15, 6144, 11, 21, 19, 19, {
+   { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
+   { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
+   { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
+   { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
+   { 21, 22, -12 }
+   }
+   },
+   /* 6BPP/14BPC */
+   { 768, 15, 6144, 15, 25, 23, 23, {
+   { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
+   { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
+   { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
+   { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
+   { 25, 26, -12 }
+   }
+   },
+   /* 6BPP/16BPC */
+   { 768, 15, 6144, 19, 29, 27, 27, {
+   { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
+   { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
+   { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
+   { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
+   { 29, 30, -12 }
+   }
+   },
+   },
+   {
+   /* 8BPP/8BPC */
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   },
+   /* 8BPP/10BPC */
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+

[PATCH v6 4/8] drm/i915/dsc: stop using interim structure for calculated params

Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 100 ++
 1 file changed, 26 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d0536582e4b9..d4340b18c18d 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -19,17 +19,6 @@
 #include "intel_vdsc.h"
 #include "intel_vdsc_regs.h"
 
-struct rc_parameters {
-   u16 initial_xmit_delay;
-   u8 first_line_bpg_offset;
-   u16 initial_offset;
-   u8 flatness_min_qp;
-   u8 flatness_max_qp;
-   u8 rc_quant_incr_limit0;
-   u8 rc_quant_incr_limit1;
-   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
-};
-
 bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
 {
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -64,8 +53,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum 
transcoder cpu_transcoder)
 }
 
 static void
-calculate_rc_params(struct rc_parameters *rc,
-   struct drm_dsc_config *vdsc_cfg)
+calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
 {
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
@@ -85,56 +73,57 @@ calculate_rc_params(struct rc_parameters *rc,
u32 res, buf_i, bpp_i;
 
if (vdsc_cfg->slice_height >= 8)
-   rc->first_line_bpg_offset =
+   vdsc_cfg->first_line_bpg_offset =
12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height - 
8)), 100);
else
-   rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+   vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 
1);
 
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
-   rc->initial_offset = 2048;
+   vdsc_cfg->initial_offset = 2048;
else if (bpp >= 10)
-   rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584), 
2);
+   vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 
3584), 2);
else if (bpp >= 8)
-   rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+   vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 
512), 2);
else
-   rc->initial_offset = 6144;
+   vdsc_cfg->initial_offset = 6144;
 
/* initial_xmit_delay = rc_model_size/2/compression_bpp */
-   rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+   vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 
* bpp);
 
-   rc->flatness_min_qp = 3 + qp_bpc_modifier;
-   rc->flatness_max_qp = 12 + qp_bpc_modifier;
+   vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
+   vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
 
-   rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
-   rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
 
bpp_i  = (2 * (bpp - 6));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+   u8 range_bpg_offset;
+
/* Read range_minqp and range_max_qp from qp tables */
-   rc->rc_range_params[buf_i].range_min_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_min_qp =
intel_lookup_range_min_qp(bpc, buf_i, bpp_i, 
vdsc_cfg->native_420);
-   rc->rc_range_params[buf_i].range_max_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_max_qp =
intel_lookup_range_max_qp(bpc, buf_i, bpp_i, 
vdsc_cfg->native_420);
 
-   /* Calculate range_bgp_offset */
+   /* Calculate range_bpg_offset */
if (bpp <= 6) {
-   rc->rc_range_params[buf_i].range_bpg_offset = 
ofs_und6[buf_i];
+   range_bpg_offset = ofs_und6[buf_i];
} else if (bpp <= 8) {
res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
ofs_und6[buf_i])), 2);
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und6[buf_i] 
+ res;
+   range_bpg_offset = ofs_und6[buf_i] + res;
} else if (bpp <= 12) {
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und8[buf_i];
+   range_bpg_offset = ofs_und8[buf_i];
} else if (bpp <= 15)

[PATCH v6 8/8] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters

Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.

Reviewed-by: Suraj Kandpal 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 450 +++
 include/drm/display/drm_dsc_helper.h |   2 +
 2 files changed, 452 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 6d9bf9ce543b..44876a715e5a 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -748,6 +748,450 @@ static const struct rc_parameters_data 
rc_parameters_1_2_444[] = {
{ /* sentinel */ }
 };
 
+/*
+ * Selected Rate Control Related Parameter Recommended Values for 4:2:2 from
+ * DSC v1.2, v1.2a, v1.2b
+ *
+ * Cross-checked against C Model releases: DSC_model_20161212 and 20210623
+ */
+static const struct rc_parameters_data rc_parameters_1_2_422[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 512, 15, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, 
-12 },
+   { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
+   { 512, 15, 6144, 7, 16, 15, 15, {
+   { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15, 
-12 },
+   { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
+   { 512, 15, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
+   { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
+   { 20, 21, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
+   { 512, 15, 6144, 15, 24, 23, 23, {
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 
},
+   { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 
20, -8 },
+   { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
+   { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
+   { 24, 25, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
+   { 512, 15, 6144, 19, 28, 27, 27, {
+   { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2 
},
+   { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19, 
24, -8 },
+   { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
+   { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
+   { 28, 29, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 8,
+   { 410, 15, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10, 
-10 },
+   { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 10,
+   { 410, 15, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14, 
-10 },
+   { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 12,
+   { 410, 15, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
+   { 19, 20, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 14,
+   { 410,

[PATCH v6 7/8] drm/display/dsc: include the rest of pre-SCR parameters

DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness. The values were generated from the
'pre_scr_cfg_files_for_reference' files found in DSC models 20210623.
The same fileset is a part of DSC model 20161212.

Reviewed-by: Jessica Zhang 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 72 
 1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index f9d01d72c1ff..6d9bf9ce543b 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -331,6 +331,16 @@ struct rc_parameters_data {
  * Cross-checked against C Model releases: DSC_model_20161212 and 20210623
  */
 static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 683, 15, 6144, 3, 13, 11, 11, {
+   { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
+   { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
+   { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12, 
-12 },
+   { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
@@ -366,6 +376,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(10), .bpc = 8,
+   { 410, 12, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11, 
-10 },
+   { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 10,
+   { 410, 12, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15, 
-10 },
+   { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 12,
+   { 410, 12, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(12), .bpc = 8,
{ 341, 15, 2048, 3, 12, 11, 11, {
@@ -397,6 +438,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(15), .bpc = 8,
+   { 273, 15, 2048, 3, 12, 11, 11, {
+   { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
+   { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
+   { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10 
},
+   { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 10,
+   { 273, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
+   { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
+   { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, 
-10 },
+   { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 12,
+   { 273, 15, 2048, 11, 20, 19, 19, {
+   { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
+   { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 
},
+   { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
+   { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{ /* sentinel */ }
 };
 
-- 
2.39.2

[PATCH v6 2/8] drm/i915/dsc: move rc_buf_thresh values to common helper

The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagate them to
the drm_dsc_config.

Reviewed-by: Jani Nikula 
Reviewed-by: Marijn Suijten 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 35 +++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +---
 include/drm/display/drm_dsc_helper.h  |  1 +
 3 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..be91abe2cfb2 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,41 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+static const u16 drm_dsc_rc_buf_thresh[] = {
+   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+   7744, 7872, 8000, 8064
+};
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+   int i;
+
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+DSC_NUM_BUF_RANGES - 1);
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+ARRAY_SIZE(vdsc_cfg->rc_buf_thresh));
+
+   for (i = 0; i < ARRAY_SIZE(drm_dsc_rc_buf_thresh); i++)
+   vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+
+   /*
+* For 6bpp, RC Buffer threshold 12 and 13 need a different value
+* as per C Model
+*/
+   if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+   vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+   vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+   }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
 /**
  * drm_dsc_compute_rc_parameters() - Write rate control
  * parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 7003ae9f683a..2fd08375bbe3 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -37,12 +37,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
 };
 
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
-   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
-   7744, 7872, 8000, 8064
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -543,23 +537,7 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
 
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
-   /*
-* six 0s are appended to the lsb of each threshold value
-* internally in h/w.
-* Only 8 bits are allowed for programming RcBufThreshold
-*/
-   vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
-   }
-
-   /*
-* For 6bpp, RC Buffer threshold 12 and 13 need a different value
-* as per C Model
-*/
-   if (compressed_bpp == 6) {
-   vdsc_cfg->rc_buf_thresh[12] = 0x7C;
-   vdsc_cfg->rc_buf_thresh[13] = 0x7D;
-   }
+   drm_dsc_set_rc_buf_thresh(vdsc_cfg);
 
/*
 * From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 8b41edbbabab..706ba1d34742 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 
 #endif /* _DRM_DSC_HELPER_H_ */
-- 
2.39.2

[PATCH v6 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 139 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
 include/drm/display/drm_dsc_helper.h  |   7 +-
 3 files changed, 129 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index acb93d4116e0..f9d01d72c1ff 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -325,10 +325,88 @@ struct rc_parameters_data {
 #define DSC_BPP(bpp)   ((bpp) << 4)
 
 /*
- * Selected Rate Control Related Parameter Recommended Values
- * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ * Rate Control Related Parameter Recommended Values from DSC_v1.1 spec prior
+ * to DSC 1.1 fractional bpp underflow SCR (DSC_v1.1_E1.pdf)
+ *
+ * Cross-checked against C Model releases: DSC_model_20161212 and 20210623
  */
-static const struct rc_parameters_data rc_parameters[] = {
+static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(8), .bpc = 8,
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 10,
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 12,
+   { 512, 12, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 8,
+   { 341, 15, 2048, 3, 12, 11, 11, {
+   { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
+   { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 10,
+   { 341, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
+   { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
},
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 12,
+   { 341, 15, 2048, 11, 20, 19, 19, {
+   { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
+   { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   { /* sentinel */ }
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values from DSC v1.2, 
v1.2a, v1.2b and
+ * DSC_v1.1_E1 specs.
+ *
+ * Cross-checked against C Model releases: DSC_model_20161212 and 20210623
+ */
+static const struct rc_parameters_data rc_parameters_1_2_444[] = {
{
.bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -388,22 +466,18 @@ static const struct rc_parameters_data rc_parameters[] = {
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4,

[PATCH v6 1/8] drm/i915/dsc: change DSC param tables to follow the DSC model

After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.

Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 8e787c13d26d..7003ae9f683a 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -87,7 +87,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
-   { 768, 15, 6144, 15, 25, 23, 27, {
+   { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -116,6 +116,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -133,7 +137,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
-   { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -598,6 +602,20 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
 
+   if (DISPLAY_VER(dev_priv) < 13) {
+   /*
+* FIXME: verify that the hardware actually needs these
+* modifications rather than them being simple typos.
+*/
+   if (compressed_bpp == 6 &&
+   vdsc_cfg->bits_per_component == 8)
+   vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+   if (compressed_bpp == 8 &&
+   vdsc_cfg->bits_per_component == 14)
+   vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+   }
+
/*
 * BitsPerComponent value determines mux_word_size:
 * When BitsPerComponent is less than or 10bpc, muxWordSize will be 
equal to
-- 
2.39.2

[PATCH v6 0/8] drm/i915: move DSC RC tables to drm_dsc_helper.c

Other platforms (msm) will benefit from sharing the DSC config setup
functions. This series moves parts of static DSC config data from the
i915 driver to the common helpers to be used by other drivers.

Note: the RC parameters were cross-checked against config files found in
DSC model 2021062, 20161212 (and 20150914). The first patch modifies
tables according to those config files, while preserving parameter
values using the code. I have not changed one of the values in the
pre-SCR config file as it clearly looks like a typo in the config file,
considering the table E in DSC 1.1 and in the DSC 1.1 SCR.

Chances since v5:
- Fixed typo in patch #2 commit message (Marijn)
- Reworded/fixed RC table comments to mention DSC standards and C model
  versions (Suraj)
- Renamed enum drm_dsc_param_kind to drm_dsc_param_type (Suraj).

Chances since v4:
- Rebased on top of drm-intel-next
- Cut the first 8 patches of the series to ease merging. The rest of the
  patches will go afterwards.

Chances since v3:
- Rebased on top of drm-intel-next
- Dropped the msm patch to make patchset fully mergeable through
  drm-intel
- Made drm_dsc_set_const_params() ignore rc_model_size, picked up
  drm_dsc_set_initial_scale_value() patch by Jessica and switched
  intel_vdsc.c to use those two helpers.
- Added a patch to make i915 actually use rc_tgt_offset_high,
  rc_tgt_offset_low and rc_edge_factor from struct drm_dsc_config.

Chances since v2:
- Rebased on top of drm-intel-next

Dmitry Baryshkov (8):
  drm/i915/dsc: change DSC param tables to follow the DSC model
  drm/i915/dsc: move rc_buf_thresh values to common helper
  drm/i915/dsc: move DSC tables to DRM DSC helper
  drm/i915/dsc: stop using interim structure for calculated params
  drm/display/dsc: use flat array for rc_parameters lookup
  drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
  drm/display/dsc: include the rest of pre-SCR parameters
  drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters

 drivers/gpu/drm/display/drm_dsc_helper.c  | 1006 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |  443 +
 include/drm/display/drm_dsc_helper.h  |9 +
 3 files changed, 1062 insertions(+), 396 deletions(-)

-- 
2.39.2

Re: [Freedreno] [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters


On 16/05/2023 21:46, Kandpal, Suraj wrote:


The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in preparation to
adding more configuration data.



Hi ,
Needed to add some more comments apart from the previous ones already given



[skipped]



diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index d4340b18c18d..bd9116d2cd76 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -226,7 +226,15 @@ int intel_dsc_compute_params(struct
intel_crtc_state *pipe_config)
if (DISPLAY_VER(dev_priv) >= 13) {
calculate_rc_params(vdsc_cfg);
} else {
-   ret = drm_dsc_setup_rc_params(vdsc_cfg);
+   if ((compressed_bpp == 8 ||
+compressed_bpp == 12) &&
+   (vdsc_cfg->bits_per_component == 8 ||
+vdsc_cfg->bits_per_component == 10 ||
+vdsc_cfg->bits_per_component == 12))
+   ret = drm_dsc_setup_rc_params(vdsc_cfg,
DRM_DSC_1_1_PRE_SCR);
+   else
+   ret = drm_dsc_setup_rc_params(vdsc_cfg,
DRM_DSC_1_2_444);
+


I do not think this kind of assignment works as you will also be adding
DRM_DSC_1_2_422 and DRM_DSC_1_2_420 in further patches and AFAICS
There is no where in patch 8 that you have accounted for when 422 or 420 will 
be used.
Maybe you can add an if case inside the else block to check 
pipe_config->output_format
to pass the rc_param_data in patch 8


I don't think this is necessary for now. The driver doesn't support YUV 
422. The YUV 420 is supported only for DISPLAY_VER(dev_priv) >= 14, 
however these helpers are only used for DISPLAY_VER(dev_priv) < 13.


I did not move RC calculation to drm_dsc_helpers.c (yet ?), which is 
used for DISPLAY_VER >= 13.




Regards,
Suraj Kandpal

if (ret)
return ret;

diff --git a/include/drm/display/drm_dsc_helper.h
b/include/drm/display/drm_dsc_helper.h
index 1681791f65a5..c634bb2935d3 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -10,12 +10,17 @@

  #include 

+enum drm_dsc_params_kind {
+   DRM_DSC_1_2_444,
+   DRM_DSC_1_1_PRE_SCR, /* legacy params from DSC 1.1 */ };
+
  void drm_dsc_dp_pps_header_init(struct dp_sdp_header *pps_header);  int
drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set
*pps_sdp,
  const struct drm_dsc_config *dsc_cfg);  void
drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg); -int
drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg);
+int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum
+drm_dsc_params_kind kind);
  int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);

  #endif /* _DRM_DSC_HELPER_H_ */
--
2.39.2




--
With best wishes
Dmitry

Re: [PATCH] drm/i915/pmu: Change bitmask of enabled events to u32

2023-05-16 Thread Umesh Nerlige Ramappa


On Tue, May 16, 2023 at 03:13:01PM -0700, Umesh Nerlige Ramappa wrote:

On Tue, May 16, 2023 at 10:24:45AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Having it as u64 was a confusing (but harmless) mistake.

Also add some asserts to make sure the internal field does not overflow
in the future.

Signed-off-by: Tvrtko Ursulin 
Cc: Ashutosh Dixit 
Cc: Umesh Nerlige Ramappa 
---
I am not entirely sure the __builtin_constant_p->BUILD_BUG_ON branch will
work with all compilers. Lets see...

Compile tested only.
---
drivers/gpu/drm/i915/i915_pmu.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ece883a7d95..8736b3418f88 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event *event)
return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
}

-static bool is_engine_config(u64 config)
+static bool is_engine_config(const u64 config)
{
return config < __I915_PMU_OTHER(0);
}
@@ -82,15 +82,28 @@ static unsigned int other_bit(const u64 config)

static unsigned int config_bit(const u64 config)
{
+   unsigned int bit;
+
if (is_engine_config(config))
-   return engine_config_sample(config);
+   bit = engine_config_sample(config);
else
-   return other_bit(config);
+   bit = other_bit(config);
+
+   if (__builtin_constant_p(config))
+   BUILD_BUG_ON(bit >
+BITS_PER_TYPE(typeof_member(struct i915_pmu,
+enable)) - 1);
+   else
+   WARN_ON_ONCE(bit >
+BITS_PER_TYPE(typeof_member(struct i915_pmu,
+enable)) - 1);


The else is firing for the INTERRUPT event because event_bit() also 
calls config_bit(). It would be best to move this check to 
config_mask() and leave this function as is.


I posted the modified version here - 
https://patchwork.freedesktop.org/patch/537361/?series=117843=1 as 
part of the MTL PMU series so that it Tests out with IGT patches.


Thanks,
Umesh



Thanks,
Umesh


+
+   return bit;
}

-static u64 config_mask(u64 config)
+static u32 config_mask(const u64 config)
{
-   return BIT_ULL(config_bit(config));
+   return BIT(config_bit(config));
}

static bool is_engine_event(struct perf_event *event)
@@ -633,11 +646,10 @@ static void i915_pmu_enable(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
+   const unsigned int bit = event_bit(event);
struct i915_pmu *pmu = >pmu;
unsigned long flags;
-   unsigned int bit;

-   bit = event_bit(event);
if (bit == -1)
goto update;

@@ -651,7 +663,7 @@ static void i915_pmu_enable(struct perf_event *event)
GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
GEM_BUG_ON(pmu->enable_count[bit] == ~0);

-   pmu->enable |= BIT_ULL(bit);
+   pmu->enable |= BIT(bit);
pmu->enable_count[bit]++;

/*
@@ -698,7 +710,7 @@ static void i915_pmu_disable(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
-   unsigned int bit = event_bit(event);
+   const unsigned int bit = event_bit(event);
struct i915_pmu *pmu = >pmu;
unsigned long flags;

@@ -734,7 +746,7 @@ static void i915_pmu_disable(struct perf_event *event)
 * bitmask when the last listener on an event goes away.
 */
if (--pmu->enable_count[bit] == 0) {
-   pmu->enable &= ~BIT_ULL(bit);
+   pmu->enable &= ~BIT(bit);
pmu->timer_enabled &= pmu_needs_timer(pmu, true);
}

--
2.39.2

Re: [PATCH v4 2/2] drm/msm: Be more shouty if per-process pgtables aren't working


On 17/05/2023 01:20, Rob Clark wrote:

From: Rob Clark 

Otherwise it is not always obvious if a dt or iommu change is causing us
to fall back to global pgtable.

Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/msm/msm_iommu.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v4 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's


On 17/05/2023 01:20, Rob Clark wrote:

From: Rob Clark 

When the special handling of qcom,adreno-smmu was moved into
qcom_smmu_create(), it was overlooked that we didn't have all the
required entries in qcom_smmu_impl_of_match.  So we stopped getting
adreno_smmu_priv on sc7180, breaking per-process pgtables.

Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check into 
qcom_smmu_create")
Cc: 
Suggested-by: Lepton Wu 
Signed-off-by: Rob Clark 
Reviewed-by: Konrad Dybcio 
---
  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 10 ++
  1 file changed, 10 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [Freedreno] [PATCH v10 8/8] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup

On 5/16/2023 3:45 PM, Marijn Suijten wrote:

On 2023-05-16 11:18:17, Jessica Zhang wrote:

On 5/14/2023 2:29 PM, Marijn Suijten wrote:

On 2023-05-12 14:32:18, Jessica Zhang wrote:

hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.

As mentioned in review on an earlier revision, is there any sort of
clarification you can provide here to explain the cases where
hdisplay!=bytes_per_line? That goes a long way towards justifying this
change. Thanks!

Hi Marijn,

Sorry for not responding to this in the earlier revision, I think I
missed the original comment.

Please correct me if I'm wrong, but I'm guessing the question here is
why we can't keep the hdisplay adjustment as `hdisplay /= 3` and have to
go out of our way to recalculate hdisplay before doing the `/ 3`.

This is because the original adjustment only works for BPP = 8. By using
the msm_dsc_get_bytes_per_line() here, we can generalize this adjustment
to work for cases where BPP != 8.

I am fully aware that the original computation only works for BPP=8 and
even mentioned so in v7 review [1]. The question / request is instead
to include such context in your commit message, rather than the
nondescriptive "should be calculated as" -> who says that and why?
Stating that the current approach was only working for BPP=8 (hence why
currently tested panels are working fine) but that this isn't a
long-term solution if we starts upporting other BPP is a proper
justification to make this change.

Sounds good, will add this to the commit message.

Thanks,

Jessica Zhang

[1]:
https://lore.kernel.org/linux-arm-msm/ju7647tlogo25fnhswgp7zn67syvsjy2ldjugvygh3z4rxtdrx@kb76evjvulgw/

Thanks,

Thanks for looking into improving this!

- Marijn

Re: [PATCH V6 0/6] drm: bridge: samsung-dsim: Support variable clocking

2023-05-16 Thread Marek Szyprowski

On 16.05.2023 01:57, Adam Ford wrote:
> This series fixes the blanking pack size and the PMS calculation.  It then
> adds support to allows the DSIM to dynamically DPHY clocks, and support
> non-burst mode while allowing the removal of the hard-coded clock values
> for the PLL for imx8m mini/nano/plus, and it allows the removal of the
> burst-clock device tree entry when burst-mode isn't supported by connected
> devices like an HDMI brige.  In that event, the HS clock is set to the
> value requested by the bridge chip.
>
> This has been tested on both an i.MX8M Nano and i.MX8M Plus, and should
> work on i.MX8M Mini as well. Marek Szyprowski has tested it on various
> Exynos boards.
>
> Adam Ford (5):
>drm: bridge: samsung-dsim: Fix PMS Calculator on imx8m[mnp]
>drm: bridge: samsung-dsim: Fetch pll-clock-frequency automatically
>drm: bridge: samsung-dsim: Select GENERIC_PHY_MIPI_DPHY
>drm: bridge: samsung-dsim: Dynamically configure DPHY timing
>drm: bridge: samsung-dsim: Support non-burst mode
>
> Lucas Stach (1):
>drm: bridge: samsung-dsim: fix blanking packet size calculation
>
>   drivers/gpu/drm/bridge/Kconfig|   1 +
>   drivers/gpu/drm/bridge/samsung-dsim.c | 143 +-
>   include/drm/bridge/samsung-dsim.h |   4 +
>   3 files changed, 125 insertions(+), 23 deletions(-)

Feel free to add to all patches:

Tested-by: Marek Szyprowski 


> V6:  Squash-in an additional error fix from Lucas Stach regarding the
>   DPHY calcuations.  Remove the dynamic_dphy variable and let
>   everyone use the new calculations.  Move the hs_clock caching
>   from patch 6 to patch 5 to go along with the DPHY calcuations
>   since they are now based on the recorded hs_clock rate.
>   
> V5:  Update error message to dev_info and change them to indicate
>   what is happening without sounding like an error when optional
>   device tree entries are missing.
>
> V4:  Undo some accidental whitespace changes, rename PS_TO_CYCLE
>   variables to ps and hz from PS and MHz. Remove if check
>   before the samsung_dsim_set_phy_ctrl call since it's
>   unnecessary.
>   Added additional tested-by and reviewed-by comments.
>   Squash patches 6 and 7 together since the supporting
>   non-burst (patch 6) mode doesn't really work until
>   patch 7 was applied.
>
> V3:  When checking if the bust-clock is present, only check for it
>   in the device tree, and don't check the presence of the
>   MIPI_DSI_MODE_VIDEO_BURST flag as it breaks an existing Exynos
>   board.
>
>   Add a new patch to the series to select GENERIC_PHY_MIPI_DPHY in
>   Kconfig otherwise the build breaks on the 32-bit Exynos.
>
>   Change vco_min variable name to min_freq
>
>   Added tested-by from Chen-Yu Tsai
>
> V2:  Instead of using my packet blanking calculation, this integrates
>   on from Lucas Stach which gets modified later in the series to
>   cache the value of the HS-clock instead of having to do the
>   calucations again.
>
>   Instead of completely eliminating the PLL clock frequency from
>   the device tree, this makes it optional to avoid breaking some
>   Samsung devices.  When the samsung,pll-clock-frequency is not
>   found, it reads the value of the clock named "sclk_mipi"
>   This also maintains backwards compatibility with older device
>   trees.
>
>   This also changes the DPHY calcuation from a Look-up table,
>   a reverse engineered algorithm which uses
>   phy_mipi_dphy_get_default_config to determine the standard
>   nominal values and calculates the cycles necessary to update
>   the DPHY timings accordingly.
>   

Best regards
-- 
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH v10 4/8] drm/msm: Add MSM-specific DSC helper methods

2023-05-16 Thread Marijn Suijten

On 2023-05-15 17:59:14, Jessica Zhang wrote:

> > The name is good, I'm just not too keen on it hiding the multiplication
> > with msm_dsc_get_slice_per_intf() which is already also computed and
> > available in DSI, and I assume DP too?
> 
> Got it, I see why you want to make that change now. DP only uses 
> get_slice_per_intf() to get eol_byte_num similarly to DSI, so I can just 
> do that then.

Thanks, the function is indeed only called once to calculate
bytes_per_intf() for eol_byte_num, and the value for slice_per_intf is
already available in-line.

- Marijn

Re: [PATCH v10 4/8] drm/msm: Add MSM-specific DSC helper methods

2023-05-16 Thread Marijn Suijten

On 2023-05-16 01:07:05, Dmitry Baryshkov wrote:
> 
> On 16/05/2023 01:01, Marijn Suijten wrote:
> > On 2023-05-15 13:29:21, Jessica Zhang wrote:
> > 
> >>> Const, as requested elsewhere.  But this function is not used anywhere
> >>> in any of the series (because we replaced the usages with more sensible
> >>> member accesses like slice_chunk_size).
> >>
> >> Acked.
> >>
> >> I would prefer to keep this helper so that we have a way to easily get
> >> BPP information from the DRM DSC config in the future, but if you'd
> >> prefer we add this helper then, I'm also ok with that.
> > 
> > The inverse helper is available ad DSC_BPP in drm_dsc_helper.c.  Perhaps
> > we can move the two variants to the header and define them uniformly?
> > This isn't MSM-specific it seems (i.e. the format supports fractional
> > bpp but no RC parameters appear to be defined for such a format yet).
> 
> I think DSC_BPP was removed (around v2 or v3 if I read changelog correctly).

Seems like it was removed at some point indeed, and now the helper file
picked up an identically named DSC_BPP macro but with the inverse
implementation :) - at least it's a *.c file.

Perhaps we can make it more consistent by defining both ways with
concise macros in a header.

> As for the fraction-point BPP, I think AMD supports .5 bpp granularity, 
> see drivers/gpu/drm/amd/display/dc/dml/dsc/qp_tables.h

That won't use the helper then.

> With best wishes
> Dmitry

- Marijn

Re: [Freedreno] [PATCH v10 8/8] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup

2023-05-16 Thread Marijn Suijten

On 2023-05-16 11:18:17, Jessica Zhang wrote:
> On 5/14/2023 2:29 PM, Marijn Suijten wrote:
> > On 2023-05-12 14:32:18, Jessica Zhang wrote:
> >>
> >> hdisplay for compressed images should be calculated as bytes_per_slice *
> >> slice_count. Thus, use MSM DSC helper to calculate hdisplay for
> >> dsi_timing_setup instead of directly using mode->hdisplay.
> > 
> > As mentioned in review on an earlier revision, is there any sort of
> > clarification you can provide here to explain the cases where
> > hdisplay!=bytes_per_line?  That goes a long way towards justifying this
> > change.  Thanks!
> 
> Hi Marijn,
> 
> Sorry for not responding to this in the earlier revision, I think I 
> missed the original comment.
> 
> Please correct me if I'm wrong, but I'm guessing the question here is 
> why we can't keep the hdisplay adjustment as `hdisplay /= 3` and have to 
> go out of our way to recalculate hdisplay before doing the `/ 3`.
> 
> This is because the original adjustment only works for BPP = 8. By using 
> the msm_dsc_get_bytes_per_line() here, we can generalize this adjustment 
> to work for cases where BPP != 8.

I am fully aware that the original computation only works for BPP=8 and
even mentioned so in v7 review [1].  The question / request is instead
to include such context in your commit message, rather than the
nondescriptive "should be calculated as" -> who says that and why?
Stating that the current approach was only working for BPP=8 (hence why
currently tested panels are working fine) but that this isn't a
long-term solution if we starts upporting other BPP is a proper
justification to make this change.

[1]: 
https://lore.kernel.org/linux-arm-msm/ju7647tlogo25fnhswgp7zn67syvsjy2ldjugvygh3z4rxtdrx@kb76evjvulgw/

> Thanks,

Thanks for looking into improving this!

- Marijn

Re: [PATCH v2 2/2] drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet spec

2023-05-16 Thread Fabio Estevam

On Thu, May 4, 2023 at 6:12 AM Alexander Stein
 wrote:
>
> Am Mittwoch, 3. Mai 2023, 18:33:07 CEST schrieb Frieder Schrempf:
> > From: Frieder Schrempf 
> >
> > The datasheet describes the following initialization flow including
> > minimum delay times between each step:
> >
> > 1. DSI data lanes need to be in LP-11 and the clock lane in HS mode
> > 2. toggle EN signal
> > 3. initialize registers
> > 4. enable PLL
> > 5. soft reset
> > 6. enable DSI stream
> > 7. check error status register
> >
> > To meet this requirement we need to make sure the host bridge's
> > pre_enable() is called first by using the pre_enable_prev_first
> > flag.
> >
> > Furthermore we need to split enable() into pre_enable() which covers
> > steps 2-5 from above and enable() which covers step 7 and is called
> > after the host bridge's enable().
> >
> > Signed-off-by: Frieder Schrempf 
>
> Tested-by: Alexander Stein  #TQMa8MxML/MBa8Mx

Should this have a Fixes tag so that it could be backported to stable kernels?

[PATCH v4 2/2] drm/msm: Be more shouty if per-process pgtables aren't working

2023-05-16 Thread Rob Clark

From: Rob Clark 

Otherwise it is not always obvious if a dt or iommu change is causing us
to fall back to global pgtable.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/msm_iommu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index 418e1e06cdde..9b19124c9bd0 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -227,21 +227,26 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu 
*parent)
struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(parent->dev);
struct msm_iommu *iommu = to_msm_iommu(parent);
struct msm_iommu_pagetable *pagetable;
const struct io_pgtable_cfg *ttbr1_cfg = NULL;
struct io_pgtable_cfg ttbr0_cfg;
int ret;
 
/* Get the pagetable configuration from the domain */
if (adreno_smmu->cookie)
ttbr1_cfg = adreno_smmu->get_ttbr1_cfg(adreno_smmu->cookie);
-   if (!ttbr1_cfg)
+
+   /*
+* If you hit this WARN_ONCE() you are probably missing an entry in
+* qcom_smmu_impl_of_match[] in arm-smmu-qcom.c
+*/
+   if (WARN_ONCE(!ttbr1_cfg, "No per-process page tables"))
return ERR_PTR(-ENODEV);
 
pagetable = kzalloc(sizeof(*pagetable), GFP_KERNEL);
if (!pagetable)
return ERR_PTR(-ENOMEM);
 
msm_mmu_init(>base, parent->dev, _funcs,
MSM_MMU_IOMMU_PAGETABLE);
 
/* Clone the TTBR1 cfg as starting point for TTBR0 cfg: */
-- 
2.40.1

[PATCH v4 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's

2023-05-16 Thread Rob Clark

From: Rob Clark 

When the special handling of qcom,adreno-smmu was moved into
qcom_smmu_create(), it was overlooked that we didn't have all the
required entries in qcom_smmu_impl_of_match.  So we stopped getting
adreno_smmu_priv on sc7180, breaking per-process pgtables.

Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check into 
qcom_smmu_create")
Cc: 
Suggested-by: Lepton Wu 
Signed-off-by: Rob Clark 
Reviewed-by: Konrad Dybcio 
---
 drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index d1b296b95c86..ec743a9ec67a 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -496,20 +496,21 @@ static const struct qcom_smmu_match_data 
qcom_smmu_500_impl0_data = {
 /*
  * Do not add any more qcom,SOC-smmu-500 entries to this list, unless they need
  * special handling and can not be covered by the qcom,smmu-500 entry.
  */
 static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
{ .compatible = "qcom,msm8996-smmu-v2", .data = _smmu_data },
{ .compatible = "qcom,msm8998-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,qcm2290-smmu-500", .data = 
_smmu_500_impl0_data },
{ .compatible = "qcom,qdu1000-smmu-500", .data = 
_smmu_500_impl0_data  },
{ .compatible = "qcom,sc7180-smmu-500", .data = 
_smmu_500_impl0_data },
+   { .compatible = "qcom,sc7180-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,sc7280-smmu-500", .data = 
_smmu_500_impl0_data },
{ .compatible = "qcom,sc8180x-smmu-500", .data = 
_smmu_500_impl0_data },
{ .compatible = "qcom,sc8280xp-smmu-500", .data = 
_smmu_500_impl0_data },
{ .compatible = "qcom,sdm630-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,sdm845-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,sdm845-smmu-500", .data = _smmu_500_data },
{ .compatible = "qcom,sm6115-smmu-500", .data = 
_smmu_500_impl0_data},
{ .compatible = "qcom,sm6125-smmu-500", .data = 
_smmu_500_impl0_data },
{ .compatible = "qcom,sm6350-smmu-v2", .data = _smmu_v2_data },
{ .compatible = "qcom,sm6350-smmu-500", .data = 
_smmu_500_impl0_data },
@@ -540,12 +541,21 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct 
arm_smmu_device *smmu)
/* Match platform for ACPI boot */
if (acpi_match_platform_list(qcom_acpi_platlist) >= 0)
return qcom_smmu_create(smmu, 
_smmu_500_impl0_data);
}
 #endif
 
match = of_match_node(qcom_smmu_impl_of_match, np);
if (match)
return qcom_smmu_create(smmu, match->data);
 
+   /*
+* If you hit this WARN_ON() you are missing an entry in the
+* qcom_smmu_impl_of_match[] table, and GPU per-process page-
+* tables will be broken.
+*/
+   WARN(of_device_is_compatible(np, "qcom,adreno-smmu"),
+"Missing qcom_smmu_impl_of_match entry for: %s",
+dev_name(smmu->dev));
+
return smmu;
 }
-- 
2.40.1

Re: [PATCH] drm/i915/pmu: Change bitmask of enabled events to u32

2023-05-16 Thread Umesh Nerlige Ramappa


On Tue, May 16, 2023 at 10:24:45AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Having it as u64 was a confusing (but harmless) mistake.

Also add some asserts to make sure the internal field does not overflow
in the future.

Signed-off-by: Tvrtko Ursulin 
Cc: Ashutosh Dixit 
Cc: Umesh Nerlige Ramappa 
---
I am not entirely sure the __builtin_constant_p->BUILD_BUG_ON branch will
work with all compilers. Lets see...

Compile tested only.
---
drivers/gpu/drm/i915/i915_pmu.c | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 7ece883a7d95..8736b3418f88 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event *event)
return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
}

-static bool is_engine_config(u64 config)
+static bool is_engine_config(const u64 config)
{
return config < __I915_PMU_OTHER(0);
}
@@ -82,15 +82,28 @@ static unsigned int other_bit(const u64 config)

static unsigned int config_bit(const u64 config)
{
+   unsigned int bit;
+
if (is_engine_config(config))
-   return engine_config_sample(config);
+   bit = engine_config_sample(config);
else
-   return other_bit(config);
+   bit = other_bit(config);
+
+   if (__builtin_constant_p(config))
+   BUILD_BUG_ON(bit >
+BITS_PER_TYPE(typeof_member(struct i915_pmu,
+enable)) - 1);
+   else
+   WARN_ON_ONCE(bit >
+BITS_PER_TYPE(typeof_member(struct i915_pmu,
+enable)) - 1);


The else is firing for the INTERRUPT event because event_bit() also 
calls config_bit(). It would be best to move this check to config_mask() 
and leave this function as is.


Thanks,
Umesh 


+
+   return bit;
}

-static u64 config_mask(u64 config)
+static u32 config_mask(const u64 config)
{
-   return BIT_ULL(config_bit(config));
+   return BIT(config_bit(config));
}

static bool is_engine_event(struct perf_event *event)
@@ -633,11 +646,10 @@ static void i915_pmu_enable(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
+   const unsigned int bit = event_bit(event);
struct i915_pmu *pmu = >pmu;
unsigned long flags;
-   unsigned int bit;

-   bit = event_bit(event);
if (bit == -1)
goto update;

@@ -651,7 +663,7 @@ static void i915_pmu_enable(struct perf_event *event)
GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
GEM_BUG_ON(pmu->enable_count[bit] == ~0);

-   pmu->enable |= BIT_ULL(bit);
+   pmu->enable |= BIT(bit);
pmu->enable_count[bit]++;

/*
@@ -698,7 +710,7 @@ static void i915_pmu_disable(struct perf_event *event)
{
struct drm_i915_private *i915 =
container_of(event->pmu, typeof(*i915), pmu.base);
-   unsigned int bit = event_bit(event);
+   const unsigned int bit = event_bit(event);
struct i915_pmu *pmu = >pmu;
unsigned long flags;

@@ -734,7 +746,7 @@ static void i915_pmu_disable(struct perf_event *event)
 * bitmask when the last listener on an event goes away.
 */
if (--pmu->enable_count[bit] == 0) {
-   pmu->enable &= ~BIT_ULL(bit);
+   pmu->enable &= ~BIT(bit);
pmu->timer_enabled &= pmu_needs_timer(pmu, true);
}

--
2.39.2

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Dump error capture to kernel log

2023-05-16 Thread John Harrison

On 5/16/2023 13:52, Rodrigo Vivi wrote:

On Tue, May 16, 2023 at 12:21:05PM -0700, John Harrison wrote:

On 5/16/2023 12:17, Belgaumkar, Vinay wrote:

> On 4/18/2023 11:17 AM, [1]john.c.harri...@intel.com wrote:

>> From: John Harrison [2]

>> This is useful for getting debug information out in certain

>> situations, such as failing kernel selftests and CI runs that don't
>> log error captures. It is especially useful for things like retrieving
>> GuC logs as GuC operation can't be tracked by adding printk or ftrace
>> entries.

>> v2: Add CONFIG_DRM_I915_DEBUG_GEM wrapper (review feedback by Rodrigo).

Thanks

> Do the CI sparse warnings hold water? With that looked at,

You mean this one totally fatal and absolutely must be fixed error?

Fast mode used, each commit won't be checked separately.

You should never rely on this assumption. There are bisects and autobisects
out there. Also every patch needs to be independently available for backport.

So, if there's any issue it needs to be fix before we merge.
What assumption? That sparse claims failure even when there are no 
errors at all, just a notice about 'fast mode used'?  If there are 
errors, please point out where I can find them. AFAICT, the sparse email 
is actually saying the patch set is clean despite the fact it has a big 
red cross on it.

John.

Does anyone even know what that means or why it (apparently totally

randomly) hits some patch sets and not others?

If you mean the checkpatch warnings. One is about not reporting out of

memory errors (because you are supposed to return -ENOMEM and let the user
handle it instead), but that doesn't apply for an internal kernel only
thing which is already just a debug print. The other is about macro
argument re-use, which is not an issue in this case and not worth
re-writing the code to avoid.

John.

> LGTM,

> Reviewed-by: Vinay Belgaumkar [3]

>> Signed-off-by: John Harrison [4]

>> ---
>>   drivers/gpu/drm/i915/i915_gpu_error.c | 132
>> ++
>>   drivers/gpu/drm/i915/i915_gpu_error.h |  10 ++
>>   2 files changed, 142 insertions(+)

>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c

>> b/drivers/gpu/drm/i915/i915_gpu_error.c
>> index f020c0086fbcd..03d62c250c465 100644
>> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
>> @@ -2219,3 +2219,135 @@ void i915_disable_error_state(struct
>> drm_i915_private *i915, int err)
>>   i915->gpu_error.first_error = ERR_PTR(err);
>>   spin_unlock_irq(>gpu_error.lock);
>>   }
>> +
>> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
>> +void intel_klog_error_capture(struct intel_gt *gt,
>> +  intel_engine_mask_t engine_mask)
>> +{
>> +    static int g_count;
>> +    struct drm_i915_private *i915 = gt->i915;
>> +    struct i915_gpu_coredump *error;
>> +    intel_wakeref_t wakeref;
>> +    size_t buf_size = PAGE_SIZE * 128;
>> +    size_t pos_err;
>> +    char *buf, *ptr, *next;
>> +    int l_count = g_count++;
>> +    int line = 0;
>> +
>> +    /* Can't allocate memory during a reset */
>> +    if (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
>> +    drm_err(>i915->drm, "[Capture/%d.%d] Inside GT reset,
>> skipping error capture :(\n",
>> +    l_count, line++);
>> +    return;
>> +    }
>> +
>> +    error = READ_ONCE(i915->gpu_error.first_error);
>> +    if (error) {
>> +    drm_err(>drm, "[Capture/%d.%d] Clearing existing error
>> capture first...\n",
>> +    l_count, line++);
>> +    i915_reset_error_state(i915);
>> +    }
>> +
>> +

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Dump error capture to kernel log

2023-05-16 Thread Rodrigo Vivi

On Tue, May 16, 2023 at 12:21:05PM -0700, John Harrison wrote:
>On 5/16/2023 12:17, Belgaumkar, Vinay wrote:   
>   
>   
>   
>> On 4/18/2023 11:17 AM, [1]john.c.harri...@intel.com wrote:   
>   
>   
>   
>>> From: John Harrison [2]  
>   
>   
>   
>>> This is useful for getting debug information out in certain 
>   
>>> situations, such as failing kernel selftests and CI runs that don't 
>   
>>> log error captures. It is especially useful for things like retrieving  
>   
>>> GuC logs as GuC operation can't be tracked by adding printk or ftrace   
>   
>>> entries.
>   
>   
>   
>>> v2: Add CONFIG_DRM_I915_DEBUG_GEM wrapper (review feedback by Rodrigo). 
>   

Thanks

>   
>   
>> Do the CI sparse warnings hold water? With that looked at,   
>   
>   
>   
>You mean this one totally fatal and absolutely must be fixed error?
>   
>   
>   
>Fast mode used, each commit won't be checked separately.   
>   

You should never rely on this assumption. There are bisects and autobisects
out there. Also every patch needs to be independently available for backport.

So, if there's any issue it needs to be fix before we merge.

>   
>   
>Does anyone even know what that means or why it (apparently totally
>   
>randomly) hits some patch sets and not others? 
>   
>   
>   
>If you mean the checkpatch warnings. One is about not reporting out of 
>   
>memory errors (because you are supposed to return -ENOMEM and let the user 
>   
>handle it instead), but that doesn't apply for an internal kernel only 
>   
>thing which is already just a debug print. The other is about macro
>   
>argument re-use, which is not an issue in this case and not worth  
>   
>re-writing the code to avoid.  
>   
>   
>   
>John.  
>   
>   
>   
>> LGTM,
>   
>   
>   
>> Reviewed-by: Vinay Belgaumkar [3]
>   
>   
>   
>>> Signed-off-by: John Harrison [4] 
>   
>>> --- 
>   
>>>   drivers/gpu/drm/i915/i915_gpu_error.c | 132   
>   
>>> ++  
>   
>>>   drivers/gpu/drm/i915/i915_gpu_error.h |  10 ++
>   
>>>   2 files changed, 142 insertions(+)
>   
>   
>   
>>> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c  
>   
>>> b/drivers/gpu/drm/i915/i915_gpu_error.c 
>   
>>> index f020c0086fbcd..03d62c250c465 100644   
>   
>>> --- a/drivers/gpu/drm/i915/i915_gpu_error.c 
>   
>>> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c 
>   
>>> @@ -2219,3 +2219,135 @@ void i915_disable_error_state(struct
>   
>>> drm_i915_private *i915, int err)
>   
>>>   i915->gpu_error.first_error = ERR_PTR(err);   
>   
>>>   spin_unlock_irq(>gpu_error.lock);   
>   
>>>   } 
>   
>>> +   
>   
>>> +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)  
>   
>>> +void intel_klog_error_capture(struct intel_gt *gt,

[PATCH] fbdev: i810: include i810_main.h in i810_dvt.c

2023-05-16 Thread Arnd Bergmann

From: Arnd Bergmann 

Building with W=1 shows that a header needs to be included to
make the prototypes visible:

drivers/video/fbdev/i810/i810_dvt.c:194:6: error: no previous prototype for 
'round_off_xres' [-Werror=missing-prototypes]
drivers/video/fbdev/i810/i810_dvt.c:233:6: error: no previous prototype for 
'i810fb_encode_registers' [-Werror=missing-prototypes]
drivers/video/fbdev/i810/i810_dvt.c:245:6: error: no previous prototype for 
'i810fb_fill_var_timings' [-Werror=missing-prototypes]
drivers/video/fbdev/i810/i810_dvt.c:279:5: error: no previous prototype for 
'i810_get_watermark' [-Werror=missing-prototypes]

Adding the header leads to another warning from a mismatched
prototype, so fix this as well:

drivers/video/fbdev/i810/i810_dvt.c:280:5: error: conflicting types for 
'i810_get_watermark'; have 'u32(struct fb_var_screeninfo *,

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/i810/i810_dvt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/i810/i810_dvt.c 
b/drivers/video/fbdev/i810/i810_dvt.c
index b4b3670667ab..2082b5c92e8f 100644
--- a/drivers/video/fbdev/i810/i810_dvt.c
+++ b/drivers/video/fbdev/i810/i810_dvt.c
@@ -14,6 +14,7 @@
 
 #include "i810_regs.h"
 #include "i810.h"
+#include "i810_main.h"
 
 struct mode_registers std_modes[] = {
/* 640x480 @ 60Hz */
@@ -276,7 +277,7 @@ void i810fb_fill_var_timings(struct fb_var_screeninfo *var)
var->upper_margin = total - (yres + var->lower_margin + var->vsync_len);
 }
 
-u32 i810_get_watermark(struct fb_var_screeninfo *var,
+u32 i810_get_watermark(const struct fb_var_screeninfo *var,
   struct i810fb_par *par)
 {
struct mode_registers *params = >regs;
-- 
2.39.2

[PATCH] fbdev: fbmem: mark get_fb_unmapped_area() static

2023-05-16 Thread Arnd Bergmann

From: Arnd Bergmann 

There is a global function with this name on sparc, but no
global declaration:

drivers/video/fbdev/core/fbmem.c:1469:15: error: no previous prototype for 
'get_fb_unmapped_area'

Make the generic definition static to avoid this warning. On
sparc, this is never seen.

Signed-off-by: Arnd Bergmann 
---
 drivers/video/fbdev/core/fbmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index e808dc86001c..28739f1cb5e7 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1468,7 +1468,7 @@ __releases(>lock)
 }
 
 #if defined(CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA) && !defined(CONFIG_MMU)
-unsigned long get_fb_unmapped_area(struct file *filp,
+static unsigned long get_fb_unmapped_area(struct file *filp,
   unsigned long addr, unsigned long len,
   unsigned long pgoff, unsigned long flags)
 {
-- 
2.39.2

[PATCH 1/2] dt-bindings: display: panel: Add Visionox R66451 AMOLED DSI panel bindings

Document the 1080x2340 Visionox R66451 AMOLED DSI panel bindings

Signed-off-by: Jessica Zhang 
---
 .../bindings/display/panel/visionox,r66451.yaml| 59 ++
 1 file changed, 59 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml 
b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
new file mode 100644
index ..6ba323683921
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/visionox,r66451.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/visionox,r66451.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Visionox R66451 AMOLED DSI Panel
+
+maintainers:
+  - Jessica Zhang 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+const: visionox,r66451
+
+  reg:
+maxItems: 1
+description: DSI virtual channel
+
+  vddio-supply: true
+  vdd-supply: true
+  port: true
+  reset-gpios: true
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - vddio-supply
+  - vdd-supply
+  - reset-gpios
+  - port
+
+examples:
+  - |
+#include 
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "visionox,r66451";
+reg = <0>;
+vddio-supply = <_l12c_1p8>;
+vdd-supply = <_l13c_3p0>;
+
+reset-gpios = < 24 GPIO_ACTIVE_LOW>;
+
+port {
+panel0_in: endpoint {
+remote-endpoint = <_out>;
+};
+};
+};
+};
+...

-- 
2.40.1

[PATCH 2/2] drm/panel: Add driver for Visionox r66451 panel

Add support for the 1080x2340 Visionox R66451 AMOLED DSI panel that
comes with the Qualcomm HDK8350 display expansion pack.

The panel enables display compression (DSC v1.2) by default.

Signed-off-by: Jessica Zhang 
---
 drivers/gpu/drm/panel/Kconfig |   8 +
 drivers/gpu/drm/panel/Makefile|   1 +
 drivers/gpu/drm/panel/panel-visionox-r66451.c | 395 ++
 3 files changed, 404 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 29cf5fa39ff2..9c2c36dbddf3 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -766,6 +766,14 @@ config DRM_PANEL_VISIONOX_VTDR6130
  Say Y here if you want to enable support for Visionox
  VTDR6130 1080x2400 AMOLED DSI panel.
 
+config DRM_PANEL_VISIONOX_R66451
+   tristate "Visionox R66451"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   help
+ Say Y here if you want to enable support for Visionox
+ R66451 1080x2340 AMOLED DSI panel.
+
 config DRM_PANEL_WIDECHIPS_WS2401
tristate "Widechips WS2401 DPI panel driver"
depends on SPI && GPIOLIB
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index b3e8ba29edd3..e043a92ee676 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -78,5 +78,6 @@ obj-$(CONFIG_DRM_PANEL_TPO_TPG110) += panel-tpo-tpg110.o
 obj-$(CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA) += panel-truly-nt35597.o
 obj-$(CONFIG_DRM_PANEL_VISIONOX_RM69299) += panel-visionox-rm69299.o
 obj-$(CONFIG_DRM_PANEL_VISIONOX_VTDR6130) += panel-visionox-vtdr6130.o
+obj-$(CONFIG_DRM_PANEL_VISIONOX_R66451) += panel-visionox-r66451.o
 obj-$(CONFIG_DRM_PANEL_WIDECHIPS_WS2401) += panel-widechips-ws2401.o
 obj-$(CONFIG_DRM_PANEL_XINPENG_XPP055C272) += panel-xinpeng-xpp055c272.o
diff --git a/drivers/gpu/drm/panel/panel-visionox-r66451.c 
b/drivers/gpu/drm/panel/panel-visionox-r66451.c
new file mode 100644
index ..e3648ead3e84
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-visionox-r66451.c
@@ -0,0 +1,395 @@
+//SPDX-License-Identifier: GPL-2.0-only
+//Copyright (c) 2023 Qualcomm Innovation Center, Inc. All rights reserved.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct visionox_r66451 {
+   struct drm_panel panel;
+   struct mipi_dsi_device *dsi;
+   struct gpio_desc *reset_gpio;
+   struct regulator_bulk_data supplies[2];
+   bool prepared, enabled;
+};
+
+static inline struct visionox_r66451 *to_visionox_r66451(struct drm_panel 
*panel)
+{
+   return container_of(panel, struct visionox_r66451, panel);
+}
+
+static void visionox_r66451_reset(struct visionox_r66451 *ctx)
+{
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(1, 10100);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+   usleep_range(1, 10100);
+   gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+   usleep_range(1, 10100);
+}
+
+static int visionox_r66451_on(struct visionox_r66451 *ctx)
+{
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = >dev;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xc2,
+  0x09, 0x24, 0x0c, 0x00, 0x00, 0x0c, 0x00, 0x00, 
0x00,
+  0x09, 0x3c);
+   mipi_dsi_dcs_write_seq(dsi, 0xd7,
+  0x00, 0xb9, 0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0, 
0x0a,
+  0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x19,
+  0x3c, 0x00, 0x40, 0x04, 0x00, 0xa0, 0x0a);
+   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x80);
+   mipi_dsi_dcs_write_seq(dsi, 0xde,
+  0x40, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x00, 
0x18,
+  0x10, 0x00, 0x18, 0x00, 0x18, 0x00, 0x18, 0x02, 
0x00, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x04);
+   mipi_dsi_dcs_write_seq(dsi, 0xe8, 0x00, 0x02);
+   mipi_dsi_dcs_write_seq(dsi, 0xe4, 0x00, 0x08);
+   mipi_dsi_dcs_write_seq(dsi, 0xb0, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xc4,
+  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00,
+  0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x32);
+   mipi_dsi_dcs_write_seq(dsi, 0xcf,
+  0x64, 0x0b, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x08,
+  0x00, 0x0b, 0x77, 0x01, 0x01, 0x01, 0x01, 0x01, 
0x01,
+  0x02, 0x02, 0x02, 0x02, 0x02, 0x03);
+   mipi_dsi_dcs_write_seq(dsi, 0xd3,
+  0x45, 0x00, 0x00, 0x01, 0x13, 0x15, 0x00, 0x15, 
0x07,
+  0x0f, 0x77, 0x77, 0x77, 0x37, 0xb2, 0x11, 0x00, 
0xa0,
+

[PATCH 0/2] Add support for Visionox R66451 AMOLED DSI panel

Add support for the 1080x2340 Visionox R66451 AMOLED DSI panel that
comes with the Qualcomm HDK8350 display expansion pack.

The driver will come with display compression (DSC v1.2) enabled by
default.

Signed-off-by: Jessica Zhang 
---
Jessica Zhang (2):
  dt-bindings: display: panel: Add Visionox R66451 AMOLED DSI panel bindings
  drm/panel: Add driver for Visionox r66451 panel

 .../bindings/display/panel/visionox,r66451.yaml|  59 +++
 drivers/gpu/drm/panel/Kconfig  |   8 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-visionox-r66451.c  | 395 +
 4 files changed, 463 insertions(+)
---
base-commit: a5abc0900af0cfb1b8093200a265d2791864f26b
change-id: 20230516-b4-r66451-panel-driver-bf04b5fb3d52

Best regards,
-- 
Jessica Zhang

Re: [PATCH 0/3] drm/vkms: Minor Improvements

2023-05-16 Thread Arthur Grillo Queiroz Cabral




On 15/05/23 10:52, Maíra Canal wrote:
> This series addresses some minor improvements to the writeback
> functionality. The first patch intends to reduce the critical section
> of a spinlock by removing assignments that don't need to be protected
> by a lock. The second patch enables the support for ARGB on the
> writeback. Finally, the third patch refactors the pixel conversion
> functions of the writeback functionality. This patch is a follow-up of
> a previous patchset [1], in which Melissa suggested to apply the same
> refactor to the writeback pixel conversion functions.
> 
> [1] 
> https://lore.kernel.org/dri-devel/20230418130525.128733-1-mca...@igalia.com/T/
> 
> Best Regards,
> - Maíra

On the entire patchset,

Reviewed-by: Arthur Grillo 

Best Regards,
~Arthur Grillo

> 
> Maíra Canal (3):
>   drm/vkms: Reduce critical section
>   drm/vkms: Enable ARGB support for writeback
>   drm/vkms: Isolate writeback pixel conversion functions
> 
>  drivers/gpu/drm/vkms/vkms_composer.c  |   4 +-
>  drivers/gpu/drm/vkms/vkms_drv.h   |   4 +-
>  drivers/gpu/drm/vkms/vkms_formats.c   | 140 +++---
>  drivers/gpu/drm/vkms/vkms_formats.h   |   2 +-
>  drivers/gpu/drm/vkms/vkms_writeback.c |   9 +-
>  5 files changed, 68 insertions(+), 91 deletions(-)
>

Re: [PATCH] accel/qaic: silence some uninitialized variable warnings

2023-05-16 Thread Jeffrey Hugo


On 5/10/2023 10:48 AM, Dan Carpenter wrote:

On Wed, May 10, 2023 at 08:57:03AM -0600, Jeffrey Hugo wrote:

On 5/3/2023 4:41 AM, Dan Carpenter wrote:

Smatch complains that these are not initialized if get_cntl_version()
fails but we still print them in the debug message.  Not the end of
the world, but true enough.  Let's just initialize them to a dummy value
to make the checker happy.

Signed-off-by: Dan Carpenter 


Thanks for the cleanup.

Reviewed-by: Jeffrey Hugo 

Could use a fixes tag


The fixes tag thing could have gone either way.  It's really minor.


and also I'd prefer to maintain the style of sorting
the variable declaration lines by line length.  Given the minor nature of
these nits, I plan to address them.


Thanks!


Pushed to drm-misc-fixes

-Jeff

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Dump error capture to kernel log

2023-05-16 Thread John Harrison


On 5/16/2023 12:17, Belgaumkar, Vinay wrote:

On 4/18/2023 11:17 AM, john.c.harri...@intel.com wrote:

From: John Harrison 

This is useful for getting debug information out in certain
situations, such as failing kernel selftests and CI runs that don't
log error captures. It is especially useful for things like retrieving
GuC logs as GuC operation can't be tracked by adding printk or ftrace
entries.

v2: Add CONFIG_DRM_I915_DEBUG_GEM wrapper (review feedback by Rodrigo).


Do the CI sparse warnings hold water? With that looked at,

You mean this one totally fatal and absolutely must be fixed error?

   Fast mode used, each commit won't be checked separately.


Does anyone even know what that means or why it (apparently totally 
randomly) hits some patch sets and not others?


If you mean the checkpatch warnings. One is about not reporting out of 
memory errors (because you are supposed to return -ENOMEM and let the 
user handle it instead), but that doesn't apply for an internal kernel 
only thing which is already just a debug print. The other is about macro 
argument re-use, which is not an issue in this case and not worth 
re-writing the code to avoid.


John.




LGTM,

Reviewed-by: Vinay Belgaumkar 



Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 132 ++
  drivers/gpu/drm/i915/i915_gpu_error.h |  10 ++
  2 files changed, 142 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c

index f020c0086fbcd..03d62c250c465 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -2219,3 +2219,135 @@ void i915_disable_error_state(struct 
drm_i915_private *i915, int err)

  i915->gpu_error.first_error = ERR_PTR(err);
  spin_unlock_irq(>gpu_error.lock);
  }
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+void intel_klog_error_capture(struct intel_gt *gt,
+  intel_engine_mask_t engine_mask)
+{
+    static int g_count;
+    struct drm_i915_private *i915 = gt->i915;
+    struct i915_gpu_coredump *error;
+    intel_wakeref_t wakeref;
+    size_t buf_size = PAGE_SIZE * 128;
+    size_t pos_err;
+    char *buf, *ptr, *next;
+    int l_count = g_count++;
+    int line = 0;
+
+    /* Can't allocate memory during a reset */
+    if (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
+    drm_err(>i915->drm, "[Capture/%d.%d] Inside GT reset, 
skipping error capture :(\n",

+    l_count, line++);
+    return;
+    }
+
+    error = READ_ONCE(i915->gpu_error.first_error);
+    if (error) {
+    drm_err(>drm, "[Capture/%d.%d] Clearing existing error 
capture first...\n",

+    l_count, line++);
+    i915_reset_error_state(i915);
+    }
+
+    with_intel_runtime_pm(>runtime_pm, wakeref)
+    error = i915_gpu_coredump(gt, engine_mask, 
CORE_DUMP_FLAG_NONE);

+
+    if (IS_ERR(error)) {
+    drm_err(>drm, "[Capture/%d.%d] Failed to capture error 
capture: %ld!\n",

+    l_count, line++, PTR_ERR(error));
+    return;
+    }
+
+    buf = kvmalloc(buf_size, GFP_KERNEL);
+    if (!buf) {
+    drm_err(>drm, "[Capture/%d.%d] Failed to allocate 
buffer for error capture!\n",

+    l_count, line++);
+    i915_gpu_coredump_put(error);
+    return;
+    }
+
+    drm_info(>drm, "[Capture/%d.%d] Dumping i915 error capture 
for %ps...\n",

+ l_count, line++, __builtin_return_address(0));
+
+    /* Largest string length safe to print via dmesg */
+#    define MAX_CHUNK    800
+
+    pos_err = 0;
+    while (1) {
+    ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf, 
pos_err, buf_size - 1);

+
+    if (got <= 0)
+    break;
+
+    buf[got] = 0;
+    pos_err += got;
+
+    ptr = buf;
+    while (got > 0) {
+    size_t count;
+    char tag[2];
+
+    next = strnchr(ptr, got, '\n');
+    if (next) {
+    count = next - ptr;
+    *next = 0;
+    tag[0] = '>';
+    tag[1] = '<';
+    } else {
+    count = got;
+    tag[0] = '}';
+    tag[1] = '{';
+    }
+
+    if (count > MAX_CHUNK) {
+    size_t pos;
+    char *ptr2 = ptr;
+
+    for (pos = MAX_CHUNK; pos < count; pos += MAX_CHUNK) {
+    char chr = ptr[pos];
+
+    ptr[pos] = 0;
+    drm_info(>drm, "[Capture/%d.%d] }%s{\n",
+ l_count, line++, ptr2);
+    ptr[pos] = chr;
+    ptr2 = ptr + pos;
+
+    /*
+ * If spewing large amounts of data via a serial 
console,
+ * this can be a very slow process. So be 
friendly and try

+ * not to cause 'softlockup on CPU' problems.
+ */
+    cond_resched();
+    }
+
+

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Dump error capture to dmesg on CTB error

2023-05-16 Thread Belgaumkar, Vinay




On 4/18/2023 11:17 AM, john.c.harri...@intel.com wrote:

From: John Harrison 

In the past, There have been sporadic CTB failures which proved hard
to reproduce manually. The most effective solution was to dump the GuC
log at the point of failure and let the CI system do the repro. It is
preferable not to dump the GuC log via dmesg for all issues as it is
not always necessary and is not helpful for end users. But rather than
trying to re-invent the code to do this each time it is wanted, commit
the code but for DEBUG_GUC builds only.

v2: Use IS_ENABLED for testing config options.


LGTM,

Reviewed-by: Vinay Belgaumkar 



Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |  6 +++
  2 files changed, 59 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 1803a633ed648..dc5cd712f1ff5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -13,6 +13,30 @@
  #include "intel_guc_ct.h"
  #include "intel_guc_print.h"
  
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)

+enum {
+   CT_DEAD_ALIVE = 0,
+   CT_DEAD_SETUP,
+   CT_DEAD_WRITE,
+   CT_DEAD_DEADLOCK,
+   CT_DEAD_H2G_HAS_ROOM,
+   CT_DEAD_READ,
+   CT_DEAD_PROCESS_FAILED,
+};
+
+static void ct_dead_ct_worker_func(struct work_struct *w);
+
+#define CT_DEAD(ct, reason)\
+   do { \
+   if (!(ct)->dead_ct_reported) { \
+   (ct)->dead_ct_reason |= 1 << CT_DEAD_##reason; \
+   queue_work(system_unbound_wq, &(ct)->dead_ct_worker); \
+   } \
+   } while (0)
+#else
+#define CT_DEAD(ct, reason)do { } while (0)
+#endif
+
  static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
  {
return container_of(ct, struct intel_guc, ct);
@@ -93,6 +117,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
spin_lock_init(>requests.lock);
INIT_LIST_HEAD(>requests.pending);
INIT_LIST_HEAD(>requests.incoming);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+   INIT_WORK(>dead_ct_worker, ct_dead_ct_worker_func);
+#endif
INIT_WORK(>requests.worker, ct_incoming_request_worker_func);
tasklet_setup(>receive_tasklet, ct_receive_tasklet_func);
init_waitqueue_head(>wq);
@@ -319,11 +346,16 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
  
  	ct->enabled = true;

ct->stall_time = KTIME_MAX;
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+   ct->dead_ct_reported = false;
+   ct->dead_ct_reason = CT_DEAD_ALIVE;
+#endif
  
  	return 0;
  
  err_out:

CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
+   CT_DEAD(ct, SETUP);
return err;
  }
  
@@ -434,6 +466,7 @@ static int ct_write(struct intel_guc_ct *ct,

  corrupted:
CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
 desc->head, desc->tail, desc->status);
+   CT_DEAD(ct, WRITE);
ctb->broken = true;
return -EPIPE;
  }
@@ -504,6 +537,7 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
CT_ERROR(ct, "Head: %u\n (Dwords)", ct->ctbs.recv.desc->head);
CT_ERROR(ct, "Tail: %u\n (Dwords)", ct->ctbs.recv.desc->tail);
  
+		CT_DEAD(ct, DEADLOCK);

ct->ctbs.send.broken = true;
}
  
@@ -552,6 +586,7 @@ static inline bool h2g_has_room(struct intel_guc_ct *ct, u32 len_dw)

 head, ctb->size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
ctb->broken = true;
+   CT_DEAD(ct, H2G_HAS_ROOM);
return false;
}
  
@@ -908,6 +943,7 @@ static int ct_read(struct intel_guc_ct *ct, struct ct_incoming_msg **msg)

CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
 desc->head, desc->tail, desc->status);
ctb->broken = true;
+   CT_DEAD(ct, READ);
return -EPIPE;
  }
  
@@ -1057,6 +1093,7 @@ static bool ct_process_incoming_requests(struct intel_guc_ct *ct)

if (unlikely(err)) {
CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
 ERR_PTR(err), 4 * request->size, request->msg);
+   CT_DEAD(ct, PROCESS_FAILED);
ct_free_msg(request);
}
  
@@ -1233,3 +1270,19 @@ void intel_guc_ct_print_info(struct intel_guc_ct *ct,

drm_printf(p, "Tail: %u\n",
   ct->ctbs.recv.desc->tail);
  }
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+static void ct_dead_ct_worker_func(struct work_struct *w)
+{
+   struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct, 
dead_ct_worker);
+   struct intel_guc *guc = ct_to_guc(ct);
+
+   if (ct->dead_ct_reported)
+   return;
+
+   ct->dead_ct_reported = true;
+
+   guc_info(guc, "CTB is dead -

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Dump error capture to kernel log

2023-05-16 Thread Belgaumkar, Vinay




On 4/18/2023 11:17 AM, john.c.harri...@intel.com wrote:

From: John Harrison 

This is useful for getting debug information out in certain
situations, such as failing kernel selftests and CI runs that don't
log error captures. It is especially useful for things like retrieving
GuC logs as GuC operation can't be tracked by adding printk or ftrace
entries.

v2: Add CONFIG_DRM_I915_DEBUG_GEM wrapper (review feedback by Rodrigo).


Do the CI sparse warnings hold water? With that looked at,

LGTM,

Reviewed-by: Vinay Belgaumkar 



Signed-off-by: John Harrison 
---
  drivers/gpu/drm/i915/i915_gpu_error.c | 132 ++
  drivers/gpu/drm/i915/i915_gpu_error.h |  10 ++
  2 files changed, 142 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f020c0086fbcd..03d62c250c465 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -2219,3 +2219,135 @@ void i915_disable_error_state(struct drm_i915_private 
*i915, int err)
i915->gpu_error.first_error = ERR_PTR(err);
spin_unlock_irq(>gpu_error.lock);
  }
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+void intel_klog_error_capture(struct intel_gt *gt,
+ intel_engine_mask_t engine_mask)
+{
+   static int g_count;
+   struct drm_i915_private *i915 = gt->i915;
+   struct i915_gpu_coredump *error;
+   intel_wakeref_t wakeref;
+   size_t buf_size = PAGE_SIZE * 128;
+   size_t pos_err;
+   char *buf, *ptr, *next;
+   int l_count = g_count++;
+   int line = 0;
+
+   /* Can't allocate memory during a reset */
+   if (test_bit(I915_RESET_BACKOFF, >reset.flags)) {
+   drm_err(>i915->drm, "[Capture/%d.%d] Inside GT reset, skipping 
error capture :(\n",
+   l_count, line++);
+   return;
+   }
+
+   error = READ_ONCE(i915->gpu_error.first_error);
+   if (error) {
+   drm_err(>drm, "[Capture/%d.%d] Clearing existing error capture 
first...\n",
+   l_count, line++);
+   i915_reset_error_state(i915);
+   }
+
+   with_intel_runtime_pm(>runtime_pm, wakeref)
+   error = i915_gpu_coredump(gt, engine_mask, CORE_DUMP_FLAG_NONE);
+
+   if (IS_ERR(error)) {
+   drm_err(>drm, "[Capture/%d.%d] Failed to capture error 
capture: %ld!\n",
+   l_count, line++, PTR_ERR(error));
+   return;
+   }
+
+   buf = kvmalloc(buf_size, GFP_KERNEL);
+   if (!buf) {
+   drm_err(>drm, "[Capture/%d.%d] Failed to allocate buffer for 
error capture!\n",
+   l_count, line++);
+   i915_gpu_coredump_put(error);
+   return;
+   }
+
+   drm_info(>drm, "[Capture/%d.%d] Dumping i915 error capture for 
%ps...\n",
+l_count, line++, __builtin_return_address(0));
+
+   /* Largest string length safe to print via dmesg */
+#  define MAX_CHUNK800
+
+   pos_err = 0;
+   while (1) {
+   ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf, 
pos_err, buf_size - 1);
+
+   if (got <= 0)
+   break;
+
+   buf[got] = 0;
+   pos_err += got;
+
+   ptr = buf;
+   while (got > 0) {
+   size_t count;
+   char tag[2];
+
+   next = strnchr(ptr, got, '\n');
+   if (next) {
+   count = next - ptr;
+   *next = 0;
+   tag[0] = '>';
+   tag[1] = '<';
+   } else {
+   count = got;
+   tag[0] = '}';
+   tag[1] = '{';
+   }
+
+   if (count > MAX_CHUNK) {
+   size_t pos;
+   char *ptr2 = ptr;
+
+   for (pos = MAX_CHUNK; pos < count; pos += 
MAX_CHUNK) {
+   char chr = ptr[pos];
+
+   ptr[pos] = 0;
+   drm_info(>drm, "[Capture/%d.%d] 
}%s{\n",
+l_count, line++, ptr2);
+   ptr[pos] = chr;
+   ptr2 = ptr + pos;
+
+   /*
+* If spewing large amounts of data via 
a serial console,
+* this can be a very slow process. So 
be friendly and try
+* not to cause 'softlockup on CPU' 
problems.
+*/
+   cond_resched();

Re: [Intel-gfx] [PATCH v2 0/2] Add support for dumping error captures via kernel logging

2023-05-16 Thread Belgaumkar, Vinay




On 4/18/2023 11:17 AM, john.c.harri...@intel.com wrote:

From: John Harrison 

Sometimes, the only effective way to debug an issue is to dump all the
interesting information at the point of failure. So add support for
doing that.

v2: Extra CONFIG wrapping (review feedback from Rodrigo)

Signed-off-by: John Harrison 


series LGTM,

Reviewed-by: Vinay Belgaumkar 




John Harrison (2):
   drm/i915: Dump error capture to kernel log
   drm/i915/guc: Dump error capture to dmesg on CTB error

  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  53 +
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h |   6 +
  drivers/gpu/drm/i915/i915_gpu_error.c | 132 ++
  drivers/gpu/drm/i915/i915_gpu_error.h |  10 ++
  4 files changed, 201 insertions(+)

RE: [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

> 
> The array of rc_parameters contains a mixture of parameters from DSC 1.1
> and DSC 1.2 standards. Split these tow configuration arrays in preparation to
> adding more configuration data.
> 

Hi ,
Needed to add some more comments apart from the previous ones already given

> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/gpu/drm/display/drm_dsc_helper.c  | 127 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
>  include/drm/display/drm_dsc_helper.h  |   7 +-
>  3 files changed, 119 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index acb93d4116e0..35b39f3109c4 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -324,11 +324,81 @@ struct rc_parameters_data {
> 
>  #define DSC_BPP(bpp) ((bpp) << 4)
> 
> +static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> + {
> + .bpp = DSC_BPP(8), .bpc = 8,
> + { 512, 12, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
> -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 10,
> + { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> +  * DSC model/pre-SCR-cfg has 8 for
> range_max_qp[0], however
> +  * VESA DSC 1.1 Table E-5 sets it to 4.
> +  */
> + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
> -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 12,
> + { 512, 12, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 8,
> + { 341, 15, 2048, 3, 12, 11, 11, {
> + { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
> + { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
> 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 10,
> + { 341, 15, 2048, 7, 16, 15, 15, {
> + { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
> + { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
> },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 12,
> + { 341, 15, 2048, 11, 20, 19, 19, {
> + { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
> + { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + { /* sentinel */ }
> +};
> +
>  /*
>   * Selected Rate Control Related Parameter Recommended Values
>   * from DSC_v1.11 spec & C Model release: DSC_model_20161212
>   */
> -static const struct rc_parameters_data rc_parameters[] = {
> +static const struct rc_parameters_data rc_parameters_1_2_444[] = {
>   {
>   .bpp = DSC_BPP(6), .bpc = 8,
>   { 768, 15, 6144, 3, 13, 11, 11, {
> @@ -388,22 +458,18 @@ static const struct rc_parameters_data
> rc_parameters[] = {
>   { 512, 12, 6144, 3, 12, 11, 11, {
>   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
>   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> - { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
> -12 },
> - { 5, 13, -12 }, { 7, 13, -12

Re: [Freedreno] [PATCH v10 8/8] drm/msm/dsi: update hdisplay calculation for dsi_timing_setup





On 5/14/2023 2:29 PM, Marijn Suijten wrote:

On 2023-05-12 14:32:18, Jessica Zhang wrote:


hdisplay for compressed images should be calculated as bytes_per_slice *
slice_count. Thus, use MSM DSC helper to calculate hdisplay for
dsi_timing_setup instead of directly using mode->hdisplay.


As mentioned in review on an earlier revision, is there any sort of
clarification you can provide here to explain the cases where
hdisplay!=bytes_per_line?  That goes a long way towards justifying this
change.  Thanks!


Hi Marijn,

Sorry for not responding to this in the earlier revision, I think I 
missed the original comment.


Please correct me if I'm wrong, but I'm guessing the question here is 
why we can't keep the hdisplay adjustment as `hdisplay /= 3` and have to 
go out of our way to recalculate hdisplay before doing the `/ 3`.


This is because the original adjustment only works for BPP = 8. By using 
the msm_dsc_get_bytes_per_line() here, we can generalize this adjustment 
to work for cases where BPP != 8.


Thanks,

Jessica Zhang




- Marijn


Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Marijn Suijten 
Signed-off-by: Jessica Zhang 
---
  drivers/gpu/drm/msm/dsi/dsi_host.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 9eeda018774e..739f62643cc5 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -952,7 +952,7 @@ static void dsi_timing_setup(struct msm_dsi_host *msm_host, 
bool is_bonded_dsi)
 * pulse width same
 */
h_total -= hdisplay;
-   hdisplay /= 3;
+   hdisplay = msm_dsc_get_bytes_per_line(msm_host->dsc) / 3;
h_total += hdisplay;
ha_end = ha_start + hdisplay;
}

--
2.40.1

[PATCH v9 2/2] drm/i915: Allow user to set cache at BO creation

2023-05-16 Thread fei . yang

From: Fei Yang 

To comply with the design that buffer objects shall have immutable
cache setting through out their life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a default (platform dependent) cache setting for all objects.
However this is not optimal for performance tuning. The patch extends
the existing gem_create uAPI to let user set PAT index for the object
at creation time.
The new extension is platform independent, so UMD's can switch to using
this extension for older platforms as well, while {set, get}_caching are
still supported on these legacy paltforms for compatibility reason.

Test igt@gem_create@create_ext_set_pat posted at
https://patchwork.freedesktop.org/series/117695/

Tested with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878

Signed-off-by: Fei Yang 
Cc: Chris Wilson 
Cc: Matt Roper 
Cc: Andi Shyti 
Reviewed-by: Andi Shyti 
Tested-by: Jordan Justen 
---
 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 include/uapi/drm/i915_drm.h| 42 ++
 tools/include/uapi/drm/i915_drm.h  | 42 ++
 4 files changed, 126 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c 
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index bfe1dbda4cb7..644a936248ad 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -245,6 +245,7 @@ struct create_ext {
unsigned int n_placements;
unsigned int placement_mask;
unsigned long flags;
+   unsigned int pat_index;
 };
 
 static void repr_placements(char *buf, size_t size,
@@ -394,11 +395,39 @@ static int ext_set_protected(struct i915_user_extension 
__user *base, void *data
return 0;
 }
 
+static int ext_set_pat(struct i915_user_extension __user *base, void *data)
+{
+   struct create_ext *ext_data = data;
+   struct drm_i915_private *i915 = ext_data->i915;
+   struct drm_i915_gem_create_ext_set_pat ext;
+   unsigned int max_pat_index;
+
+   BUILD_BUG_ON(sizeof(struct drm_i915_gem_create_ext_set_pat) !=
+offsetofend(struct drm_i915_gem_create_ext_set_pat, rsvd));
+
+   if (copy_from_user(, base, sizeof(ext)))
+   return -EFAULT;
+
+   max_pat_index = INTEL_INFO(i915)->max_pat_index;
+
+   if (ext.pat_index > max_pat_index) {
+   drm_dbg(>drm, "PAT index is invalid: %u\n",
+   ext.pat_index);
+   return -EINVAL;
+   }
+
+   ext_data->pat_index = ext.pat_index;
+
+   return 0;
+}
+
 static const i915_user_extension_fn create_extensions[] = {
[I915_GEM_CREATE_EXT_MEMORY_REGIONS] = ext_set_placements,
[I915_GEM_CREATE_EXT_PROTECTED_CONTENT] = ext_set_protected,
+   [I915_GEM_CREATE_EXT_SET_PAT] = ext_set_pat,
 };
 
+#define PAT_INDEX_NOT_SET  0x
 /**
  * i915_gem_create_ext_ioctl - Creates a new mm object and returns a handle to 
it.
  * @dev: drm device pointer
@@ -418,6 +447,7 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (args->flags & ~I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS)
return -EINVAL;
 
+   ext_data.pat_index = PAT_INDEX_NOT_SET;
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
   create_extensions,
   ARRAY_SIZE(create_extensions),
@@ -454,5 +484,11 @@ i915_gem_create_ext_ioctl(struct drm_device *dev, void 
*data,
if (IS_ERR(obj))
return PTR_ERR(obj);
 
+   if (ext_data.pat_index != PAT_INDEX_NOT_SET) {
+   i915_gem_object_set_pat_index(obj, ext_data.pat_index);
+   /* Mark pat_index is set by UMD */
+   obj->pat_set_by_user = true;
+   }
+
return i915_gem_publish(obj, file, >size, >handle);
 }
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 46a19b099ec8..97ac6fb37958 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -208,6 +208,12 @@ 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
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ba40855dbc93..4f3fd650e5e1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3664,9 +3664,13 @@ struct

[PATCH v9 1/2] drm/i915/mtl: end support for set caching ioctl

2023-05-16 Thread fei . yang

From: Fei Yang 

The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
cache. For userspace components needing to fine tune the caching policy
for BO's, a follow up patch will extend the GEM_CREATE uAPI to allow
them specify caching mode at BO creation time.

Signed-off-by: Fei Yang 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  | 9 -
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 05107a6efe45..dfaaa8b66ac3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -350,6 +350,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev, void 
*data,
if (IS_DGFX(i915))
return -ENODEV;
 
+   if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70))
+   return -EOPNOTSUPP;
+
switch (args->caching) {
case I915_CACHING_NONE:
level = I915_CACHE_NONE;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c 
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index 37d1efcd3ca6..cad4a6017f4b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -601,7 +601,14 @@ static int shmem_object_init(struct intel_memory_region 
*mem,
obj->write_domain = I915_GEM_DOMAIN_CPU;
obj->read_domains = I915_GEM_DOMAIN_CPU;
 
-   if (HAS_LLC(i915))
+   /*
+* MTL doesn't snoop CPU cache by default for GPU access (namely
+* 1-way coherency). However some UMD's are currently depending on
+* that. Make 1-way coherent the default setting for MTL. A follow
+* up patch will extend the GEM_CREATE uAPI to allow UMD's specify
+* caching mode at BO creation time
+*/
+   if (HAS_LLC(i915) || (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)))
/* On some devices, we can have the GPU use the LLC (the CPU
 * cache) for about a 10% performance improvement
 * compared to uncached.  Graphics requests other than
-- 
2.25.1

[PATCH v9 0/2] drm/i915: Allow user to set cache at BO creation

2023-05-16 Thread fei . yang

From: Fei Yang 

This series introduce a new extension for GEM_CREATE,
1. end support for set caching ioctl [PATCH 4/5]
2. add set_pat extension for gem_create [PATCH 5/5]

v2: drop one patch that was merged separately
commit 341ad0e8e254 ("drm/i915/mtl: Add PTE encode function")
v3: rebased on https://patchwork.freedesktop.org/series/117082/
v4: fix missing unlock introduced in v3, and
solve a rebase conflict
v5: replace obj->cache_level with pat_set_by_user,
fix i915_cache_level_str() for legacy platforms.
v6: rebased on https://patchwork.freedesktop.org/series/117480/
v7: rebased on https://patchwork.freedesktop.org/series/117528/
v8: dropped the two dependent patches that has been merged
separately. Add IGT link and Tested-by (MESA).
v9: addressing comments (Andi)

Fei Yang (2):
  drm/i915/mtl: end support for set caching ioctl
  drm/i915: Allow user to set cache at BO creation

 drivers/gpu/drm/i915/gem/i915_gem_create.c | 36 +++
 drivers/gpu/drm/i915/gem/i915_gem_domain.c |  3 ++
 drivers/gpu/drm/i915/gem/i915_gem_object.c |  6 
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c  |  9 -
 include/uapi/drm/i915_drm.h| 42 ++
 tools/include/uapi/drm/i915_drm.h  | 42 ++
 6 files changed, 137 insertions(+), 1 deletion(-)

-- 
2.25.1

Re: [PATCH v4 07/41] drm: handle HAS_IOPORT dependencies

2023-05-16 Thread Arnd Bergmann

On Tue, May 16, 2023, at 19:13, Thomas Zimmermann wrote:
>
> Am 16.05.23 um 13:00 schrieb Niklas Schnelle:
>> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
>> not being declared. We thus need to add HAS_IOPORT as dependency for
>> those drivers using them. In the bochs driver there is optional MMIO
>> support detected at runtime, warn if this isn't taken when
>> HAS_IOPORT is not defined.
>> 
>> There is also a direct and hard coded use in cirrus.c which according to
>> the comment is only necessary during resume.  Let's just skip this as
>> for example s390 which doesn't have I/O port support also doesen't
>> support suspend/resume.
>> 
>> Co-developed-by: Arnd Bergmann 
>> Signed-off-by: Arnd Bergmann 
>> Signed-off-by: Niklas Schnelle 
>> ---
>> Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
>>per-subsystem patches may be applied independently
>> 
>>   drivers/gpu/drm/qxl/Kconfig   |  1 +
>>   drivers/gpu/drm/tiny/bochs.c  | 17 +
>>   drivers/gpu/drm/tiny/cirrus.c |  2 ++
>
> There are more invocations in gma500. See[1]
>
> [1] 
> https://elixir.bootlin.com/linux/v6.3/source/drivers/gpu/drm/gma500/cdv_device.c#L30

GMA500 already has "depends on X86", so I don't think
any changes are needed there -- x86 is already highly dependent
on I/O ports for a number of reasons.

 Arnd

Re: [PATCH v7 1/7] fbdev/hitfb: Cast I/O offset to address

2023-05-16 Thread Helge Deller


On 5/12/23 12:24, Thomas Zimmermann wrote:

Cast I/O offsets to pointers to use them with I/O functions. The I/O
functions expect pointers of type 'volatile void __iomem *', but the
offsets are plain integers. Build warnings are

   ../drivers/video/fbdev/hitfb.c: In function 'hitfb_accel_wait':
   ../arch/x86/include/asm/hd64461.h:18:33: warning: passing argument 1 of 
'fb_readw' makes pointer from integer without a cast [-Wint-conversion]
18 | #define HD64461_IO_OFFSET(x)(HD64461_IOBASE + (x))
   | ^~
   | |
   | unsigned int
   ../arch/x86/include/asm/hd64461.h:93:33: note: in expansion of macro 
'HD64461_IO_OFFSET'
93 | #define HD64461_GRCFGR  HD64461_IO_OFFSET(0x1044)   /* 
Accelerator Configuration Register */
   | ^
   ../drivers/video/fbdev/hitfb.c:47:25: note: in expansion of macro 
'HD64461_GRCFGR'
47 | while (fb_readw(HD64461_GRCFGR) & HD64461_GRCFGR_ACCSTATUS) ;
   | ^~
   In file included from ../arch/x86/include/asm/fb.h:15,
   from ../include/linux/fb.h:19,
   from ../drivers/video/fbdev/hitfb.c:22:
   ../include/asm-generic/fb.h:52:57: note: expected 'const volatile void *' 
but argument is of type 'unsigned int'
52 | static inline u16 fb_readw(const volatile void __iomem *addr)
   |~^~~~

This patch only fixes the build warnings. It's not clear if the I/O
offsets can legally be passed to the I/O helpers. It was apparently
broken in 2007 when custom inw()/outw() helpers got removed by
commit 34a780a0afeb ("sh: hp6xx pata_platform support."). Fixing the
driver would require setting the I/O base address.


I think your patch is the best you can do for now... So...

Acked-by: Helge Deller 

Thanks!
Helge



Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202305102136.emjtspwh-...@intel.com/
Signed-off-by: Thomas Zimmermann 
Cc: Artur Rojek 
---
  drivers/video/fbdev/hitfb.c | 122 
  1 file changed, 69 insertions(+), 53 deletions(-)

diff --git a/drivers/video/fbdev/hitfb.c b/drivers/video/fbdev/hitfb.c
index 3033f5056976..7737923b7a0a 100644
--- a/drivers/video/fbdev/hitfb.c
+++ b/drivers/video/fbdev/hitfb.c
@@ -42,17 +42,33 @@ static struct fb_fix_screeninfo hitfb_fix = {
.accel  = FB_ACCEL_NONE,
  };

+static volatile void __iomem *hitfb_offset_to_addr(unsigned int offset)
+{
+   return (__force volatile void __iomem *)(uintptr_t)offset;
+}
+
+static u16 hitfb_readw(unsigned int offset)
+{
+   return fb_readw(hitfb_offset_to_addr(offset));
+}
+
+static void hitfb_writew(u16 value, unsigned int offset)
+{
+   fb_writew(value, hitfb_offset_to_addr(offset));
+}
+
  static inline void hitfb_accel_wait(void)
  {
-   while (fb_readw(HD64461_GRCFGR) & HD64461_GRCFGR_ACCSTATUS) ;
+   while (hitfb_readw(HD64461_GRCFGR) & HD64461_GRCFGR_ACCSTATUS)
+   ;
  }

  static inline void hitfb_accel_start(int truecolor)
  {
if (truecolor) {
-   fb_writew(6, HD64461_GRCFGR);
+   hitfb_writew(6, HD64461_GRCFGR);
} else {
-   fb_writew(7, HD64461_GRCFGR);
+   hitfb_writew(7, HD64461_GRCFGR);
}
  }

@@ -63,11 +79,11 @@ static inline void hitfb_accel_set_dest(int truecolor, u16 
dx, u16 dy,
if (truecolor)
saddr <<= 1;

-   fb_writew(width-1, HD64461_BBTDWR);
-   fb_writew(height-1, HD64461_BBTDHR);
+   hitfb_writew(width-1, HD64461_BBTDWR);
+   hitfb_writew(height-1, HD64461_BBTDHR);

-   fb_writew(saddr & 0x, HD64461_BBTDSARL);
-   fb_writew(saddr >> 16, HD64461_BBTDSARH);
+   hitfb_writew(saddr & 0x, HD64461_BBTDSARL);
+   hitfb_writew(saddr >> 16, HD64461_BBTDSARH);

  }

@@ -80,7 +96,7 @@ static inline void hitfb_accel_bitblt(int truecolor, u16 sx, 
u16 sy, u16 dx,

height--;
width--;
-   fb_writew(rop, HD64461_BBTROPR);
+   hitfb_writew(rop, HD64461_BBTROPR);
if ((sy < dy) || ((sy == dy) && (sx <= dx))) {
saddr = WIDTH * (sy + height) + sx + width;
daddr = WIDTH * (dy + height) + dx + width;
@@ -91,32 +107,32 @@ static inline void hitfb_accel_bitblt(int truecolor, u16 
sx, u16 sy, u16 dx,
maddr =
(((width >> 4) + 1) * (height + 1) - 1) * 2;

-   fb_writew((1 << 5) | 1, HD64461_BBTMDR);
+   hitfb_writew((1 << 5) | 1, HD64461_BBTMDR);
} else
-   fb_writew(1, HD64461_BBTMDR);
+   hitfb_writew(1, HD64461_BBTMDR);
} else {
saddr = WIDTH * sy + sx;
daddr = WIDTH * dy + dx;
if

[linux-next:master] BUILD SUCCESS WITH WARNING 885df05bf634d589fbf030c3751614eaa453fb5d

2023-05-16 Thread kernel test robot

tree/branch: INFO setup_repo_specs: 
/db/releases/20230516180935/lkp-src/repo/*/linux-next
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 885df05bf634d589fbf030c3751614eaa453fb5d  Add linux-next specific 
files for 20230516

Warning reports:

https://lore.kernel.org/oe-kbuild-all/202304200812.6uqndvzy-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305152341.oisjrpv6-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202305162245.wtalixf3-...@intel.com

Warning: (recently discovered and may have been fixed)

Documentation/output/frontend.h.rst:6: WARNING: undefined label: fec-11-45 (if 
the link has no caption the label must precede a section header)
drivers/base/regmap/regcache-maple.c:113:23: warning: 'lower_index' is used 
uninitialized [-Wuninitialized]
drivers/base/regmap/regcache-maple.c:113:36: warning: 'lower_last' is used 
uninitialized [-Wuninitialized]
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6396:21: warning: 
variable 'count' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/dmub_abm.c:138:15: warning: 
variable 'feature_support' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/amdgpu_gfx.c:499:13: warning: variable 'j' set but 
not used [-Wunused-but-set-variable]

Unverified Warning (likely false positive, please contact us if interested):

fs/ext4/verity.c:316 ext4_get_verity_descriptor_location() error: uninitialized 
symbol 'desc_size_disk'.
fs/xfs/scrub/fscounters.c:459 xchk_fscounters() warn: ignoring unreachable code.
kernel/events/uprobes.c:478 uprobe_write_opcode() warn: passing zero to 
'PTR_ERR'

Warning ids grouped by kconfigs:

gcc_recent_errors
|-- alpha-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- alpha-randconfig-r021-20230515
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- alpha-randconfig-r033-20230516
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arc-allyesconfig
|   |-- 
drivers-base-regmap-regcache-maple.c:warning:lower_index-is-used-uninitialized
|   |-- 
drivers-base-regmap-regcache-maple.c:warning:lower_last-is-used-uninitialized
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arc-randconfig-r025-20230515
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arc-randconfig-r043-20230515
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arm-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arm-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- arm-randconfig-c034-20230515
|   `-- drivers-gpu-drm-bridge-tc358768.c:Unneeded-semicolon
|-- arm-randconfig-m041-20230516
|   `-- 
fs-ext4-verity.c-ext4_get_verity_descriptor_location()-error:uninitialized-symbol-desc_size_disk-.
|-- arm64-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- csky-randconfig-r014-20230515
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- i386-allyesconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- i386-randconfig-m041-20230515
|   |-- 
fs-ext4-verity.c-ext4_get_verity_descriptor_location()-error:uninitialized-symbol-desc_size_disk-.
|   `-- 
fs-xfs-scrub-fscounters.c-xchk_fscounters()-warn:ignoring-unreachable-code.
|-- ia64-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display-amdgpu_dm-amdgpu_dm.c:warning:variable-count-set-but-not-used
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- ia64-randconfig-s041-20230515
|   `-- 
drivers-gpu-drm-amd-amdgpu-amdgpu_gfx.c:warning:variable-j-set-but-not-used
|-- loongarch-allmodconfig
|   |-- 
drivers-gpu-drm-amd-amdgpu-..-display

[PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast

From: Sui Jingfeng 

Both mode->crtc_htotal and mode->crtc_vtotal are u16 type,
mode->crtc_htotal * mode->crtc_vtotal will results a unsigned type.
Using a u32 is enough to store the result, but considering that the
result will be casted to u64 soon after. We use a u64 type directly.
So there no need to cast it to signed type and cast back then.

Signed-off-by: Sui Jingfeng 
Reviewed-by: Thomas Zimmermann 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: loongson-ker...@lists.loongnix.cn
---
 drivers/gpu/drm/drm_vblank.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 877e2067534f..d99c404b181b 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -622,7 +622,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
 
/* Valid dotclock? */
if (dotclock > 0) {
-   int frame_size = mode->crtc_htotal * mode->crtc_vtotal;
+   u64 frame_size = mode->crtc_htotal * mode->crtc_vtotal;
 
/*
 * Convert scanline length in pixels and video
@@ -630,7 +630,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
 * in nanoseconds:
 */
linedur_ns  = div_u64((u64) mode->crtc_htotal * 100, 
dotclock);
-   framedur_ns = div_u64((u64) frame_size * 100, dotclock);
+   framedur_ns = div_u64(frame_size * 100, dotclock);
 
/*
 * Fields of interlaced scanout modes are only half a frame 
duration.
-- 
2.25.1

Re: [PATCH v4 38/41] video: handle HAS_IOPORT dependencies


Hi

Am 16.05.23 um 13:00 schrieb Niklas Schnelle:

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
   per-subsystem patches may be applied independently

  drivers/video/console/Kconfig |  1 +
  drivers/video/fbdev/Kconfig   | 21 +++--
  include/video/vga.h   |  8 


Those are 3 different things. It might be preferable to not handle them 
under the video/ umbrella.



  3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 22cea5082ac4..64974eaa3ac5 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -10,6 +10,7 @@ config VGA_CONSOLE
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC &&  !SUPERH 
&& \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
&& \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390 && !UML
+   depends on HAS_IOPORT
select APERTURE_HELPERS if (DRM || FB || VFIO_PCI_CORE)
default y
help
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 96e91570cdd3..a56c57dd839b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -335,7 +335,7 @@ config FB_IMX
  
  config FB_CYBER2000

tristate "CyberPro 2000/2010/5000 support"
-   depends on FB && PCI && (BROKEN || !SPARC64)
+   depends on FB && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -429,6 +429,7 @@ config FB_FM2
  config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+   depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -1332,7 +1333,7 @@ config FB_ATY_BACKLIGHT
  
  config FB_S3

tristate "S3 Trio/Virge support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1393,7 +1394,7 @@ config FB_SAVAGE_ACCEL
  
  config FB_SIS

tristate "SiS/XGI display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1424,7 +1425,7 @@ config FB_SIS_315
  
  config FB_VIA

tristate "VIA UniChrome (Pro) and Chrome9 display support"
-   depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+   depends on FB && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || 
COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1463,7 +1464,7 @@ endif
  
  config FB_NEOMAGIC

tristate "NeoMagic display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1493,7 +1494,7 @@ config FB_KYRO
  
  config FB_3DFX

tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1543,7 +1544,7 @@ config FB_VOODOO1
  
  config FB_VT8623

tristate "VIA VT8623 support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1558,7 +1559,7 @@ config FB_VT8623
  
  config FB_TRIDENT

tristate "Trident/CyberXXX/CyberBlade support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1581,7 +1582,7 @@ config FB_TRIDENT
  
  config FB_ARK

tristate "ARK 2000PV support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2195,7 +2196,7 @@ config FB_SSD1307
  
  config FB_SM712

tristate "Silicon Motion SM712 framebuffer support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index 947c0abd04ef..f4b806b85c86 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -203,18 +203,26 @@ extern int restore_vga(struct vgastate *state);
  
  static inline unsigned char vga_io_r (unsigned short

Re: [PATCH v4 07/41] drm: handle HAS_IOPORT dependencies


Hi

Am 16.05.23 um 13:00 schrieb Niklas Schnelle:

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. In the bochs driver there is optional MMIO
support detected at runtime, warn if this isn't taken when
HAS_IOPORT is not defined.

There is also a direct and hard coded use in cirrus.c which according to
the comment is only necessary during resume.  Let's just skip this as
for example s390 which doesn't have I/O port support also doesen't
support suspend/resume.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
   per-subsystem patches may be applied independently

  drivers/gpu/drm/qxl/Kconfig   |  1 +
  drivers/gpu/drm/tiny/bochs.c  | 17 +
  drivers/gpu/drm/tiny/cirrus.c |  2 ++


There are more invocations in gma500. See[1]

[1] 
https://elixir.bootlin.com/linux/v6.3/source/drivers/gpu/drm/gma500/cdv_device.c#L30



  3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
  config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+   depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index d254679a136e..3710339407cc 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -2,6 +2,7 @@
  
  #include 

  #include 
+#include 


 please.

Best regards
Thomas

  
  #include 

  #include 
@@ -105,7 +106,9 @@ static void bochs_vga_writeb(struct bochs_device *bochs, 
u16 ioport, u8 val)
  
  		writeb(val, bochs->mmio + offset);

} else {
+#ifdef CONFIG_HAS_IOPORT
outb(val, ioport);
+#endif
}
  }
  
@@ -119,7 +122,11 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16 ioport)
  
  		return readb(bochs->mmio + offset);

} else {
+#ifdef CONFIG_HAS_IOPORT
return inb(ioport);
+#else
+   return 0xff;
+#endif
}
  }
  
@@ -132,8 +139,12 @@ static u16 bochs_dispi_read(struct bochs_device *bochs, u16 reg)
  
  		ret = readw(bochs->mmio + offset);

} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
ret = inw(VBE_DISPI_IOPORT_DATA);
+#else
+   ret = 0x;
+#endif
}
return ret;
  }
@@ -145,8 +156,10 @@ static void bochs_dispi_write(struct bochs_device *bochs, 
u16 reg, u16 val)
  
  		writew(val, bochs->mmio + offset);

} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
outw(val, VBE_DISPI_IOPORT_DATA);
+#endif
}
  }
  
@@ -229,6 +242,10 @@ static int bochs_hw_init(struct drm_device *dev)

return -ENOMEM;
}
} else {
+   if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+   DRM_ERROR("I/O ports are not supported\n");
+   return -EIO;
+   }
ioaddr = VBE_DISPI_IOPORT_INDEX;
iosize = 2;
if (!request_region(ioaddr, iosize, "bochs-drm")) {
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 594bc472862f..c65fea049bc7 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -508,8 +508,10 @@ static void cirrus_crtc_helper_atomic_enable(struct 
drm_crtc *crtc,
  
  	cirrus_mode_set(cirrus, _state->mode);
  
+#ifdef CONFIG_HAS_IOPORT

/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(VGA_AR_ENABLE_DISPLAY, VGA_ATT_W);
+#endif
  
  	drm_dev_exit(idx);

  }


--
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: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast


Hi,

On 2023/5/17 01:06, Thomas Zimmermann wrote:



Am 16.05.23 um 18:59 schrieb Sui Jingfeng:

Both mode->crtc_htotal and mode->crtc_vtotal are u16 type,
mode->crtc_htotal * mode->crtc_vtotal will results a unsigned type.
Using a u32 is enough to store the result, but considering that the
result will be casted to u64 soon after. We use a u64 type directly.

So there no need to cast it to signed type and cast back then.

Signed-off-by: Sui Jingfeng 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org


Reviewed-by: Thomas Zimmermann 


Thanks a lot,  thanks for the response time also.


---
  drivers/gpu/drm/drm_vblank.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 877e2067534f..d99c404b181b 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -622,7 +622,7 @@ void drm_calc_timestamping_constants(struct 
drm_crtc *crtc,

    /* Valid dotclock? */
  if (dotclock > 0) {
-    int frame_size = mode->crtc_htotal * mode->crtc_vtotal;
+    u64 frame_size = mode->crtc_htotal * mode->crtc_vtotal;
    /*
   * Convert scanline length in pixels and video
@@ -630,7 +630,7 @@ void drm_calc_timestamping_constants(struct 
drm_crtc *crtc,

   * in nanoseconds:
   */
  linedur_ns  = div_u64((u64) mode->crtc_htotal * 100, 
dotclock);

-    framedur_ns = div_u64((u64) frame_size * 100, dotclock);
+    framedur_ns = div_u64(frame_size * 100, dotclock);
    /*
   * Fields of interlaced scanout modes are only half a frame 
duration.

Re: [PATCH] drm/drm_vblank.c: avoid unsigned int to signed int cast




Am 16.05.23 um 18:59 schrieb Sui Jingfeng:

Both mode->crtc_htotal and mode->crtc_vtotal are u16 type,
mode->crtc_htotal * mode->crtc_vtotal will results a unsigned type.
Using a u32 is enough to store the result, but considering that the
result will be casted to u64 soon after. We use a u64 type directly.

So there no need to cast it to signed type and cast back then.

Signed-off-by: Sui Jingfeng 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org


Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/drm_vblank.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 877e2067534f..d99c404b181b 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -622,7 +622,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
  
  	/* Valid dotclock? */

if (dotclock > 0) {
-   int frame_size = mode->crtc_htotal * mode->crtc_vtotal;
+   u64 frame_size = mode->crtc_htotal * mode->crtc_vtotal;
  
  		/*

 * Convert scanline length in pixels and video
@@ -630,7 +630,7 @@ void drm_calc_timestamping_constants(struct drm_crtc *crtc,
 * in nanoseconds:
 */
linedur_ns  = div_u64((u64) mode->crtc_htotal * 100, 
dotclock);
-   framedur_ns = div_u64((u64) frame_size * 100, dotclock);
+   framedur_ns = div_u64(frame_size * 100, dotclock);
  
  		/*

 * Fields of interlaced scanout modes are only half a frame 
duration.


--
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: [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

> Subject: [PATCH v5 6/8] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR)
> parameters
> 
> The array of rc_parameters contains a mixture of parameters from DSC 1.1
> and DSC 1.2 standards. Split these tow configuration arrays in preparation to
> adding more configuration data.
> 
> Signed-off-by: Dmitry Baryshkov 
> ---
>  drivers/gpu/drm/display/drm_dsc_helper.c  | 127 ++
> drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
>  include/drm/display/drm_dsc_helper.h  |   7 +-
>  3 files changed, 119 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index acb93d4116e0..35b39f3109c4 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -324,11 +324,81 @@ struct rc_parameters_data {
> 
>  #define DSC_BPP(bpp) ((bpp) << 4)
> 

Maybe  comment here mentioning the DSC version and the C Model
we follow would be useful

> +static const struct rc_parameters_data rc_parameters_pre_scr[] = {
> + {
> + .bpp = DSC_BPP(8), .bpc = 8,
> + { 512, 12, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
> -12 },
> + { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 10,
> + { 512, 12, 6144, 7, 16, 15, 15, {
> + /*
> +  * DSC model/pre-SCR-cfg has 8 for
> range_max_qp[0], however
> +  * VESA DSC 1.1 Table E-5 sets it to 4.
> +  */
> + { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
> -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(8), .bpc = 12,
> + { 512, 12, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 8,
> + { 341, 15, 2048, 3, 12, 11, 11, {
> + { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
> + { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
> 15, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 10,
> + { 341, 15, 2048, 7, 16, 15, 15, {
> + { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
> + { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
> },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
> -12 },
> + { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(12), .bpc = 12,
> + { 341, 15, 2048, 11, 20, 19, 19, {
> + { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
> + { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
> + { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
> + { 21, 23, -12 }
> + }
> + }
> + },
> + { /* sentinel */ }
> +};
> +
>  /*
>   * Selected Rate Control Related Parameter Recommended Values
>   * from DSC_v1.11 spec & C Model release: DSC_model_20161212
>   */

The above comment shouldn't be above this function anymore since
This represent dsc_v1.2 I presume maybe move this comment above
and add a new comment for this function.

> -static const struct rc_parameters_data rc_parameters[] = {
> +static const struct rc_parameters_data rc_parameters_1_2_444[] = {
>   {
>   .bpp = DSC_BPP(6), .bpc = 8,
>   { 768, 15, 6144, 3, 13, 11, 11, {
> @@ -388,22 +458,18 @@ static const struct rc_parameters_data
> rc_parameters[] = {
>   { 512, 12, 6144, 3, 12, 11, 11, {
>   {

Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages()

2023-05-16 Thread John Hubbard

On 5/16/23 07:35, David Hildenbrand wrote:
...
>>> When passing NULL as "pages" to get_user_pages(), __get_user_pages_locked()
>>> won't set FOLL_GET. As FOLL_PIN is also not set, we won't be messing with
>>> the mapcount of the page.
> 
> For completeness: s/mapcount/refcount/ :)

whew, you had me going there! Now it all adds up. :) 

thanks,
-- 
John Hubbard
NVIDIA

[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390

2023-05-16 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=216119

Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #53 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
> I believe my last issue regarding hibernation after this rewrite has been
> fixed somewhere in linux-stable 6.2.13: The desktop no longer freezes when
> VT-switching after resuming from hibernation. Seems to work fine for some
> days now.

That's great thanks!

> It could have been this commit as there has not been much else, but I have
> not investigated nor verified it:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.2.y=56a03f64fedf49a4f81c5605167b6e7bb0300a59

This seems plausible to me because the GPU does reset on the way down for
hibernate and if it's poorly timed it could manifest similarly.

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

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

Re: [PATCH] drm/i915/pmu: Change bitmask of enabled events to u32

2023-05-16 Thread Dixit, Ashutosh

On Tue, 16 May 2023 02:24:45 -0700, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin 
>
> Having it as u64 was a confusing (but harmless) mistake.
>
> Also add some asserts to make sure the internal field does not overflow
> in the future.
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: Ashutosh Dixit 
> Cc: Umesh Nerlige Ramappa 
> ---
> I am not entirely sure the __builtin_constant_p->BUILD_BUG_ON branch will
> work with all compilers. Lets see...
>
> Compile tested only.
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 32 ++--
>  1 file changed, 22 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 7ece883a7d95..8736b3418f88 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -50,7 +50,7 @@ static u8 engine_event_instance(struct perf_event *event)
>   return (event->attr.config >> I915_PMU_SAMPLE_BITS) & 0xff;
>  }
>
> -static bool is_engine_config(u64 config)
> +static bool is_engine_config(const u64 config)
>  {
>   return config < __I915_PMU_OTHER(0);
>  }
> @@ -82,15 +82,28 @@ static unsigned int other_bit(const u64 config)
>
>  static unsigned int config_bit(const u64 config)
>  {
> + unsigned int bit;
> +
>   if (is_engine_config(config))
> - return engine_config_sample(config);
> + bit = engine_config_sample(config);
>   else
> - return other_bit(config);
> + bit = other_bit(config);
> +
> + if (__builtin_constant_p(config))
> + BUILD_BUG_ON(bit >
> +  BITS_PER_TYPE(typeof_member(struct i915_pmu,
> +  enable)) - 1);

Given that config comes from the event (it is event->attr.config), can this
ever be a builtin constant?

> + else
> + WARN_ON_ONCE(bit >
> +  BITS_PER_TYPE(typeof_member(struct i915_pmu,
> +  enable)) - 1);

There is really an even stricter limit on what the bit can be, which is the
total number of possible events but anyway this is good enough. So this
patch is:

Reviewed-by: Ashutosh Dixit 

> +
> + return bit;
>  }
>
> -static u64 config_mask(u64 config)
> +static u32 config_mask(const u64 config)
>  {
> - return BIT_ULL(config_bit(config));
> + return BIT(config_bit(config));
>  }
>
>  static bool is_engine_event(struct perf_event *event)
> @@ -633,11 +646,10 @@ static void i915_pmu_enable(struct perf_event *event)
>  {
>   struct drm_i915_private *i915 =
>   container_of(event->pmu, typeof(*i915), pmu.base);
> + const unsigned int bit = event_bit(event);
>   struct i915_pmu *pmu = >pmu;
>   unsigned long flags;
> - unsigned int bit;
>
> - bit = event_bit(event);
>   if (bit == -1)
>   goto update;
>
> @@ -651,7 +663,7 @@ static void i915_pmu_enable(struct perf_event *event)
>   GEM_BUG_ON(bit >= ARRAY_SIZE(pmu->enable_count));
>   GEM_BUG_ON(pmu->enable_count[bit] == ~0);
>
> - pmu->enable |= BIT_ULL(bit);
> + pmu->enable |= BIT(bit);
>   pmu->enable_count[bit]++;
>
>   /*
> @@ -698,7 +710,7 @@ static void i915_pmu_disable(struct perf_event *event)
>  {
>   struct drm_i915_private *i915 =
>   container_of(event->pmu, typeof(*i915), pmu.base);
> - unsigned int bit = event_bit(event);
> + const unsigned int bit = event_bit(event);
>   struct i915_pmu *pmu = >pmu;
>   unsigned long flags;
>
> @@ -734,7 +746,7 @@ static void i915_pmu_disable(struct perf_event *event)
>* bitmask when the last listener on an event goes away.
>*/
>   if (--pmu->enable_count[bit] == 0) {
> - pmu->enable &= ~BIT_ULL(bit);
> + pmu->enable &= ~BIT(bit);
>   pmu->timer_enabled &= pmu_needs_timer(pmu, true);
>   }
>
> --
> 2.39.2
>

Re: [PATCH 2/5] drm/amd/display: Move three variable assignments behind condition checks in trigger_hotplug()

2023-05-16 Thread Markus Elfring

>> The address of a data structure member was determined before
>> a corresponding null pointer check in the implementation of
>> the function “trigger_hotplug”.
>>
>> Thus avoid the risk for undefined behaviour by moving the assignment
>> for three local variables behind some condition checks.
>
> It might be that the NULL check doesn't make sense in the first place, but 
> since I'm not an expert for this code I can't fully judge.

Will the source code and patch review evolve any more?


> On the other hand the patches clearly look like nice cleanups to me, so feel 
> free to add an Acked-by: Christian König  to the 
> series.

Will such a positive feedback trigger any further collateral evolution?

Regards,
Markus

[Bug 216119] 087451f372bf76d breaks hibernation on amdgpu Radeon R9 390

2023-05-16 Thread bugzilla-daemon

https://bugzilla.kernel.org/show_bug.cgi?id=216119

--- Comment #52 from Harald Judt (h.j...@gmx.at) ---
I believe my last issue regarding hibernation after this rewrite has been fixed
somewhere in linux-stable 6.2.13: The desktop no longer freezes when
VT-switching after resuming from hibernation. Seems to work fine for some days
now.

It could have been this commit as there has not been much else, but I have not
investigated nor verified it:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-6.2.y=56a03f64fedf49a4f81c5605167b6e7bb0300a59

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

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

Re: [PATCH] drm/ttm: let struct ttm_device_funcs be placed in rodata

2023-05-16 Thread Alex Deucher

On Tue, May 16, 2023 at 4:05 AM Jani Nikula  wrote:
>
> On Thu, 09 Mar 2023, Jani Nikula  wrote:
> > On Thu, 09 Mar 2023, Christian König  wrote:
> >> Am 09.03.23 um 13:37 schrieb Jani Nikula:
> >>> Make the struct ttm_device_funcs pointers const so the data can be placed 
> >>> in rodata.
> >>>
> >>> Cc: Christian Koenig 
> >>> Cc: Huang Rui 
> >>> Signed-off-by: Jani Nikula 
> >>
> >> Good idea, Reviewed-by: Christian König 
> >
> > Thanks!
> >
> >> Should I push it to drm-misc-next or do you need it on some other branch?
> >
> > Go ahead, I'm not urgently depending on it.
>
> Christian, I guess this fell between the cracks? Can I just push it to
> drm-misc-next?

Go ahead.  Christian is out of the office this week.

Alex

>
> BR,
> Jani.
>
>
> >
> > BR,
> > Jani.
> >
> >>
> >> Christian.
> >>
> >>> ---
> >>>   drivers/gpu/drm/ttm/ttm_device.c | 2 +-
> >>>   include/drm/ttm/ttm_device.h | 4 ++--
> >>>   2 files changed, 3 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/ttm/ttm_device.c 
> >>> b/drivers/gpu/drm/ttm/ttm_device.c
> >>> index ae2f19dc9f81..a71bb1362de4 100644
> >>> --- a/drivers/gpu/drm/ttm/ttm_device.c
> >>> +++ b/drivers/gpu/drm/ttm/ttm_device.c
> >>> @@ -190,7 +190,7 @@ EXPORT_SYMBOL(ttm_device_swapout);
> >>>* Returns:
> >>>* !0: Failure.
> >>>*/
> >>> -int ttm_device_init(struct ttm_device *bdev, struct ttm_device_funcs 
> >>> *funcs,
> >>> +int ttm_device_init(struct ttm_device *bdev, const struct 
> >>> ttm_device_funcs *funcs,
> >>> struct device *dev, struct address_space *mapping,
> >>> struct drm_vma_offset_manager *vma_manager,
> >>> bool use_dma_alloc, bool use_dma32)
> >>> diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
> >>> index 56e82ba2d046..c22f30535c84 100644
> >>> --- a/include/drm/ttm/ttm_device.h
> >>> +++ b/include/drm/ttm/ttm_device.h
> >>> @@ -223,7 +223,7 @@ struct ttm_device {
> >>>  * @funcs: Function table for the device.
> >>>  * Constant after bo device init
> >>>  */
> >>> -   struct ttm_device_funcs *funcs;
> >>> +   const struct ttm_device_funcs *funcs;
> >>>
> >>> /**
> >>>  * @sysman: Resource manager for the system domain.
> >>> @@ -287,7 +287,7 @@ static inline void ttm_set_driver_manager(struct 
> >>> ttm_device *bdev, int type,
> >>> bdev->man_drv[type] = manager;
> >>>   }
> >>>
> >>> -int ttm_device_init(struct ttm_device *bdev, struct ttm_device_funcs 
> >>> *funcs,
> >>> +int ttm_device_init(struct ttm_device *bdev, const struct 
> >>> ttm_device_funcs *funcs,
> >>> struct device *dev, struct address_space *mapping,
> >>> struct drm_vma_offset_manager *vma_manager,
> >>> bool use_dma_alloc, bool use_dma32);
> >>
>
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH] drm/ttm: let struct ttm_device_funcs be placed in rodata




Am 09.03.23 um 13:37 schrieb Jani Nikula:

Make the struct ttm_device_funcs pointers const so the data can be placed in 
rodata.

Cc: Christian Koenig 
Cc: Huang Rui 
Signed-off-by: Jani Nikula 


Reviewed-by: Thomas Zimmermann 


---
  drivers/gpu/drm/ttm/ttm_device.c | 2 +-
  include/drm/ttm/ttm_device.h | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index ae2f19dc9f81..a71bb1362de4 100644
--- a/drivers/gpu/drm/ttm/ttm_device.c
+++ b/drivers/gpu/drm/ttm/ttm_device.c
@@ -190,7 +190,7 @@ EXPORT_SYMBOL(ttm_device_swapout);
   * Returns:
   * !0: Failure.
   */
-int ttm_device_init(struct ttm_device *bdev, struct ttm_device_funcs *funcs,
+int ttm_device_init(struct ttm_device *bdev, const struct ttm_device_funcs 
*funcs,
struct device *dev, struct address_space *mapping,
struct drm_vma_offset_manager *vma_manager,
bool use_dma_alloc, bool use_dma32)
diff --git a/include/drm/ttm/ttm_device.h b/include/drm/ttm/ttm_device.h
index 56e82ba2d046..c22f30535c84 100644
--- a/include/drm/ttm/ttm_device.h
+++ b/include/drm/ttm/ttm_device.h
@@ -223,7 +223,7 @@ struct ttm_device {
 * @funcs: Function table for the device.
 * Constant after bo device init
 */
-   struct ttm_device_funcs *funcs;
+   const struct ttm_device_funcs *funcs;
  
  	/**

 * @sysman: Resource manager for the system domain.
@@ -287,7 +287,7 @@ static inline void ttm_set_driver_manager(struct ttm_device 
*bdev, int type,
bdev->man_drv[type] = manager;
  }
  
-int ttm_device_init(struct ttm_device *bdev, struct ttm_device_funcs *funcs,

+int ttm_device_init(struct ttm_device *bdev, const struct ttm_device_funcs 
*funcs,
struct device *dev, struct address_space *mapping,
struct drm_vma_offset_manager *vma_manager,
bool use_dma_alloc, bool use_dma32);


--
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: [PATCH v2] dt-bindings: display: panel: add panel-mipi-dsi-bringup

2023-05-16 Thread Krzysztof Kozlowski

On 16/05/2023 15:09, Paulo Pavačić wrote:
> Add dt-bindings documentation for panel-mipi-dsi-bringup which currently
> supports fannal,c3004 panel. Also added fannal to vendor-prefixes.

Thank you for your patch. There is something to discuss/improve.

> 
> v2 changelog:

Please put changelog after ---

Missing user of the bindings - driver or DTS. Please sent patches
together as patchset.



>   - revised driver title, now describes purpose
>   - revised description, now describes hw
>   - revised maintainers, now has only 1 mail
>   - removed diacritics from commit/commit author
>   - properties/compatible is now enum
>   - compatible using only lowercase
>   - revised dts example
>   - modified MAINTAINERS in this commit (instead of driver commit)
>   - dt_bindings_check checked yml
>   - checkpatch warning fixed
> 
> Signed-off-by: Paulo Pavacic 
> ---
>  .../display/panel/panel-mipi-dsi-bringup.yaml | 54 +++
>  .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
>  MAINTAINERS   |  6 +++
>  3 files changed, 62 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml

Still wrong filename. You did not respond to my previous comments, so I
don't really understand what's this.

Judging by compatible, this should be fannal,c3004.yaml

If not, explain please.

> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
> new file mode 100644
> index ..c9e2b545657e
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
> @@ -0,0 +1,54 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dsi-bringup.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPI DSI Bringup Panel Porting Bindings

Drop Bindings. I don't understand what is "Porting" in the terms of
hardware. If it these are bindings for Panel, please write here proper
hardware.

> +
> +description: |
> +  MIPI DSI Bringup Panel porting bindings to be used for a collection of 
> panels

I have no clue what is "Bringup panel". Is it technical term for some
type of panels?

> +  from different manufacturers which don't require backlight control from the
> +  driver and have a single reset pin which is required to be passed as an
> +  argument.

Drop "driver"

> +
> +maintainers:
> +  - Paulo Pavacic 
> +
> +allOf:
> +  - $ref: panel-common.yaml#
> +
> +properties:
> +

Drop blank line.

> +  compatible:
> +enum:
> +  # compatible must be listed in alphabetical order, ordered by 
> compatible.
> +  # The description in the comment is mandatory for each compatible.

Drop above comment.

> +
> +# Fannal 480x800 panel
> +  - fannal,c3004
> +
> +  reg: true
> +  reset-gpios: true
> +
> +required:
> +  - compatible
> +  - reg
> +  - reset-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +//example on IMX8MM where GPIO pin 9 is used as a reset pin

This is a friendly reminder during the review process.

It seems my previous comments were not fully addressed. Maybe my
feedback got lost between the quotes, maybe you just forgot to apply it.
Please go back to the previous discussion and either implement all
requested changes or keep discussing them.

Thank you.

I asked to drop the comment.

> +mipi_dsi@32e1 {

dsi {

There is no way it was correct in current form.

It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.

> +panel@0 {
> +compatible = "fannal,c3004";
> +reg = <0>;
> +pinctrl-0 = <_mipi_dsi_rst>;
> +pinctrl-names = "default";
> +reset-gpios = < 9 GPIO_ACTIVE_LOW>;
> +};
> +};
> +...
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 82d39ab0231b..f962750f630a 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -462,6 +462,8 @@ patternProperties:
>  description: Facebook
>"^fairphone,.*":
>  description: Fairphone B.V.
> +  "^fannal,.*":
> +description: Fannal Electronics Co., Ltd
>"^faraday,.*":
>  description: Faraday Technology Corporation
>"^fastrax,.*":
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e0ad886d3163..46f988ee60bd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6566,6 +6566,12 @@ T:git git://anongit.freedesktop.org/drm/drm-misc
>  F:

Re: [v2] drm/panel: Modify innolux hj110iz panel inital code

2023-05-16 Thread Doug Anderson

Hi,

On Tue, May 9, 2023 at 8:42 AM Doug Anderson  wrote:
>
> Hi,
>
> On Mon, May 8, 2023 at 7:52 PM Cong Yang
>  wrote:
> >
> > There is a problem of screen shake on the old panel. So increase the
> > panel GOP component pull-down circuit size in hardware, and update the
> > initialization code at the same time. The new initialization code mainly
> > modifles the following.
> >
> > a)adjusted for GOP timing. When Display sleep in, raise all GOP signals
> > to VGHO and then drop to GND.
> > b)Increased the Vertical back Porch and Vertical pulse width, so need to
> > update vsync_end and vtotal and CLK in drm_display_mode.
> >
> > Signed-off-by: Cong Yang 
> > ---
> > v2: Modify commit message
> >
> >  .../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 397 +++---
> >  1 file changed, 235 insertions(+), 162 deletions(-)
>
> Every time I see the opaque changes to the pile of "DCS_CMD" arrays I
> feel obliged to grumble a bit, but as I've said before I guess it's
> OK-ish...
>
> Thus, this patch seems fine to me:
>
> Reviewed-by: Douglas Anderson 
>
> Just to make sure there are no objections, I'll give this ~1 week and
> then I'll land it to drm-misc-next.

Pushed to drm-misc-next:

519ce291168a drm/panel: Modify innolux hj110iz panel initial code

[PATCH] drm/i915/guc/slpc: Disable rps_boost debugfs

2023-05-16 Thread Vinay Belgaumkar

rps_boost debugfs shows host turbo related info. This is not valid
when SLPC is enabled. guc_slpc_info already shows the number of boosts.
Add num_waiters there as well and disable rps_boost when SLPC is
enabled.

v2: Replace Bug with Link to resolve checkpatch warning

Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7632
Reviewed-by: Ashutosh Dixit 
Signed-off-by: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 5 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   | 2 ++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 80dbbef86b1d..357e2f865727 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -539,7 +539,10 @@ static bool rps_eval(void *data)
 {
struct intel_gt *gt = data;
 
-   return HAS_RPS(gt->i915);
+   if (intel_guc_slpc_is_used(>uc.guc))
+   return false;
+   else
+   return HAS_RPS(gt->i915);
 }
 
 DEFINE_INTEL_GT_DEBUGFS_ATTRIBUTE(rps_boost);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index 56dbba1ef668..01b75529311c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -837,6 +837,8 @@ int intel_guc_slpc_print_info(struct intel_guc_slpc *slpc, 
struct drm_printer *p
   slpc_decode_min_freq(slpc));
drm_printf(p, "\twaitboosts: %u\n",
   slpc->num_boosts);
+   drm_printf(p, "\tBoosts outstanding: %u\n",
+  atomic_read(>num_waiters));
}
}
 
-- 
2.38.1

Re: [PATCH v2 2/2] phy: mtk-mipi-csi: add driver for CSI phy

2023-05-16 Thread AngeloGioacchino Del Regno


Il 16/05/23 11:30, Julien Stephan ha scritto:

On Mon, May 15, 2023 at 04:32:42PM +0200, AngeloGioacchino Del Regno wrote:

Il 15/05/23 16:07, Julien Stephan ha scritto:

On Mon, May 15, 2023 at 02:22:52PM +0200, AngeloGioacchino Del Regno wrote:

+#define CSIxB_OFFSET   0x1000


What if we grab two (or three?) iospaces from devicetree?

- base (global)
- csi_a
- csi_b

That would make it possible to maybe eventually extend this driver to more
versions (older or newer) of the CSI PHY IP without putting fixes offsets
inside of platform data structures and such.


Hi Angelo,
The register bank of the CSI port is divided into 2:
* from base address to base + 0x1000 (port A)
* from base + 0x1000 to base +0x2000 (port B)
Some CSI port can be configured in 4D1C mode (4 data + 1 clock) using
the whole register bank from base to base + 0x2000 or in 2D1C mode (2 data +
1 clock) and use either port A or port B.

For example  mt8365 has CSI0 that can be used either in 4D1C mode or in
2 * 2D1C and CSI1 which can use only 4D1C mode

2D1C mode can not be tested and is not implemented in the driver so
I guess adding csi_a and csi_b reg value may be confusing?

What do you think?


Ok so we're talking about two data lanes per CSI port... it may still be
beneficial to split the two register regions as

reg-names = "csi-a", "csi-b"; (whoops, I actually used underscores before,
and that was a mistake, sorry!)

but that would be actually good only if we are expecting to get a CSI
PHY in the future with four data lanes per port.

If you do *not* expect at all such a CSI PHY, or you do *not* expect such
a PHY to ever be compatible with this driver (read as: if you expect such
a PHY to be literally completely different from this one), then it would
not change much to have the registers split in two.

Another case in which it would make sense is if we were to get a PHY that
provides more than two CSI ports: in that case, we'd avoid platform data
machinery to check the number of actual ports in the IP, as we would be
just checking how many register regions we were given from the devicetree,
meaning that if we got "csi-a", "csi-b", "csi-c", "csi-d", we have four
ports.

Besides, another thing to think about is... yes you cannot test nor implement
2D1C mode in your submission, but this doesn't mean that others won't ever be
interested in this and that other people won't be actually implementing that;
Providing them with the right initial driver structure will surely make things
easier, encouraging other people from the community to spend their precious
time on the topic.


Hi Angelo,
Ok, I see your point, but for future potential upgrade to support A/B
ports I was thinking of something else: adding independent nodes for csixA
and csixB such as:

csi0_rx: phy@11c1 {
   reg = <0 0x11C1 0 0x2000>;
   mediatek,mode = <4D1c>;
   ...
};

csi0a_rx: phy@11c1 {
   reg = <0 0x11C1 0 0x1000>;
   mediatek,mode = <2D1c>;
   ...
};
csi0b_rx: phy@11c11000 {
   reg = <0 0x11C11000 0 0x1000>;
   mediatek,mode = <2D1c>;
   ...
};

giving the correct register range. One thing I did not mention is that if
csi0_rx is used csi0a_rx and csi0b_rx cannot be used (they share same
physical lanes as csio_rx), but csi0a_rx and csi0b_rx can be used 
simultaneously.
So platform device will enable only the node(s) it needs and enabling
csi0_rx and csioa/b_rx will fail because they share the same register
region and map will fail and it does not have any sense because you
either have a camera using the whole port or sub port but you cannot have
both plugged in. What do you think about it?



Your description of the hardware makes me even more confident in pushing for
having one single node with multiple iospaces.

You could have a node such as:

csi0_rx: phy@11c1 {
compatible = 
reg = <0 0x11c1 0 0x1000>, <0 0x11c2 0 0x1000>;
reg-names = "csi-a", "csi-b";
/* 4 means 4D1C */
num-lanes = <4>;
or
/* 2 means 2D1C */
num-lanes = <2>;
};

You would then reference the csi0_rx node as:

/* PHY is configured as 4 lanes (4D1C) */
something = <_rx 0>;

or

/* First two lanes (CSI0 PORT-A) */
something = <_rx 0>;
/* Second two lanes (CSI0 PORT-B) */
something = <_rx 1>;

Preferrably, you should (or shall?) use a graph to describe such connections,
anyway.

This is because overriding the number of lanes on a per-board basis becomes
*otherwise* difficult, in the sense of human readability issues, other than
duplicated nodes being a real issue.

Regards,
Angelo

Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages()

2023-05-16 Thread David Hildenbrand


On 16.05.23 16:30, Sean Christopherson wrote:

On Tue, May 16, 2023, David Hildenbrand wrote:

On 15.05.23 21:07, Sean Christopherson wrote:

On Sun, May 14, 2023, Lorenzo Stoakes wrote:

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cb5c13eee193..eaa5bb8dbadc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2477,7 +2477,7 @@ static inline int check_user_page_hwpoison(unsigned long 
addr)
   {
int rc, flags = FOLL_HWPOISON | FOLL_WRITE;
-   rc = get_user_pages(addr, 1, flags, NULL, NULL);
+   rc = get_user_pages(addr, 1, flags, NULL);
return rc == -EHWPOISON;


Unrelated to this patch, I think there's a pre-existing bug here.  If gup() 
returns
a valid page, KVM will leak the refcount and unintentionally pin the page.  
That's


When passing NULL as "pages" to get_user_pages(), __get_user_pages_locked()
won't set FOLL_GET. As FOLL_PIN is also not set, we won't be messing with
the mapcount of the page.


For completeness: s/mapcount/refcount/ :)



Ah, that's what I'm missing.




--
Thanks,

David / dhildenb

Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages()

2023-05-16 Thread Sean Christopherson

On Tue, May 16, 2023, David Hildenbrand wrote:
> On 15.05.23 21:07, Sean Christopherson wrote:
> > On Sun, May 14, 2023, Lorenzo Stoakes wrote:
> > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> > > index cb5c13eee193..eaa5bb8dbadc 100644
> > > --- a/virt/kvm/kvm_main.c
> > > +++ b/virt/kvm/kvm_main.c
> > > @@ -2477,7 +2477,7 @@ static inline int check_user_page_hwpoison(unsigned 
> > > long addr)
> > >   {
> > >   int rc, flags = FOLL_HWPOISON | FOLL_WRITE;
> > > - rc = get_user_pages(addr, 1, flags, NULL, NULL);
> > > + rc = get_user_pages(addr, 1, flags, NULL);
> > >   return rc == -EHWPOISON;
> > 
> > Unrelated to this patch, I think there's a pre-existing bug here.  If gup() 
> > returns
> > a valid page, KVM will leak the refcount and unintentionally pin the page.  
> > That's
> 
> When passing NULL as "pages" to get_user_pages(), __get_user_pages_locked()
> won't set FOLL_GET. As FOLL_PIN is also not set, we won't be messing with
> the mapcount of the page.

Ah, that's what I'm missing.

> So even if get_user_pages() returns "1", we should be fine.
> 
> 
> Or am I misunderstanding your concern?

Nope, you covered everything.  I do think we can drop the extra gup() though,
AFAICT it's 100% redundant.  But it's not a bug.

Thanks!

Re: [PATCH v6 2/8] drm/bridge: tfp410: Set input_bus_flags in atomic_check

2023-05-16 Thread Aradhya Bhatia

Hi Neil,

On 16-May-23 12:55, Neil Armstrong wrote:
> On 09/05/2023 11:30, Aradhya Bhatia wrote:
>> From: Nikhil Devshatwar 
>>
>> input_bus_flags are specified in drm_bridge_timings (legacy) as well
>> as drm_bridge_state->input_bus_cfg.flags
>>
>> The flags from the timings will be deprecated. Bridges are supposed
>> to validate and set the bridge state flags from atomic_check.
>>
>> Implement atomic_check hook for the same.
>>
>> Signed-off-by: Nikhil Devshatwar 
>> ---
>>
>> Notes:
>>  changes from v4:
>>  * fix a warning Reported-by: kernel test robot 
>>
>>  changes from v5:
>>  * Moved the return statement here from patch 4 (where it was added
>>    by mistake).
>>
>>   drivers/gpu/drm/bridge/ti-tfp410.c | 16 
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c
>> b/drivers/gpu/drm/bridge/ti-tfp410.c
>> index 7dacc7e03eee..631ae8f11a77 100644
>> --- a/drivers/gpu/drm/bridge/ti-tfp410.c
>> +++ b/drivers/gpu/drm/bridge/ti-tfp410.c
>> @@ -228,6 +228,21 @@ static u32 *tfp410_get_input_bus_fmts(struct
>> drm_bridge *bridge,
>>   return input_fmts;
>>   }
>>   +static int tfp410_atomic_check(struct drm_bridge *bridge,
>> +   struct drm_bridge_state *bridge_state,
>> +   struct drm_crtc_state *crtc_state,
>> +   struct drm_connector_state *conn_state)
>> +{
>> +    struct tfp410 *dvi = drm_bridge_to_tfp410(bridge);
>> +
>> +    /*
>> + * There might be flags negotiation supported in future.
>> + * Set the bus flags in atomic_check statically for now.
>> + */
>> +    bridge_state->input_bus_cfg.flags = dvi->timings.input_bus_flags;
> 
> A newline here before return would look better
Yup! Will add one.

> 
>> +    return 0;
>> +}
>> +
>>   static const struct drm_bridge_funcs tfp410_bridge_funcs = {
>>   .attach    = tfp410_attach,
>>   .detach    = tfp410_detach,
>> @@ -238,6 +253,7 @@ static const struct drm_bridge_funcs
>> tfp410_bridge_funcs = {
>>   .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
>>   .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
>>   .atomic_get_input_bus_fmts = tfp410_get_input_bus_fmts,
>> +    .atomic_check = tfp410_atomic_check,
>>   };
>>     static const struct drm_bridge_timings tfp410_default_timings = {
> 
> With that fixed:
> 
> Reviewed-by: Neil Armstrong 

Thank you!


Regards
Aradhya

Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation

2023-05-16 Thread Aradhya Bhatia

Hi Neil,

Thank you for reviewing the patch.

On 16-May-23 12:51, Neil Armstrong wrote:
> On 15/05/2023 17:59, Aradhya Bhatia wrote:
>> Hi Tomi,
>>
>> On 12-May-23 14:45, Tomi Valkeinen wrote:
>>> On 09/05/2023 12:30, Aradhya Bhatia wrote:
 From: Nikhil Devshatwar 

 With new connector model, mhdp bridge will not create the connector and
 SoC driver will rely on format negotiation to setup the encoder format.

 Support minimal format negotiations hooks in the drm_bridge_funcs.
 Complete format negotiation can be added based on EDID data.
 This patch adds the minimal required support to avoid failure
 after moving to new connector model.

 Signed-off-by: Nikhil Devshatwar 
 Reviewed-by: Tomi Valkeinen 
>>>
>>> You need to add your SoB to this and the other patches.
>>
>> Okay!
>>
>>>
 ---

 Notes:

   changes from v1:
   * cosmetic fixes, commit message update.

   changes from v5:
   * dropped the default_bus_format variable and directly assigned
     MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts.

    .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 25
 +++
    1 file changed, 25 insertions(+)

 diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
 b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
 index f6822dfa3805..623e4235c94f 100644
 --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
 +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c
 @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge
 *bridge)
    return _mhdp_state->base;
    }
    +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge,
 + struct drm_bridge_state *bridge_state,
 + struct drm_crtc_state *crtc_state,
 + struct drm_connector_state *conn_state,
 + u32 output_fmt,
 + unsigned int *num_input_fmts)
 +{
 +    u32 *input_fmts;
 +
 +    *num_input_fmts = 0;
 +
 +    if (output_fmt != MEDIA_BUS_FMT_FIXED)
 +    return NULL;
>>>
>>> The tfp410 and sii902x drivers don't have the above check. Why does mhdp
>>> need it? Or the other way, why don't tfp410 and sii902x need it?
>>
>> I had removed this condition in order to follow status quo, from the
>> ITE-66121 HDMI bridge driver.
>>
>> The idea would have been to drop this for MHDP as well, but I guess I
>> overlooked this one.
>>
>> However...
>>
>>> I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out
>>> fmt (in all three bridge drivers), don't we?
>>
>> ... I tested again to ensure that the above is indeed the case. And
>> ended up catching some odd behavior.
>>
>> It turns out that for all the HDMI bridges (TFP410, SII902X, ITE-66121),
>> the format negotiation doesn't stop at output_fmt = MEDIA_BUS_FMT_FIXED.
>> The {bridge}_get_input_format API gets called again with the output_fmt
>> = MEDIA_BUS_FMT_RGB24_1X24.
>>
>> This doesn't happen with the MHDP driver. Format negotiation with MHDP
>> bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED.
> 
> This is because the bridge negociation logic will test with all possible
> output formats from the chain, and won't stop at first working test.
> 
Okay..

> If your bridge only supports a single input format, it should return the
> same format whatever output_fmt is tried.
> 
> So indeed remove this test on mhdp aswell, or filter out invalid output
> formats.
Agreed.

I have been looking into the code deeper and trying to understand the
logic flow around the format negotiation in the framework. Here are the
2 points that I want to mention. Please let me know if I have missed
something with my understanding.

Firstly, the mhdp-8546 output connects to the display-connector (with
the compatible, "dp-connector") in the devicetree.

When the negotiation begins at 'drm_atomic_bridge_chain_select_bus_fmts'
the display-connector bridge *should* act as the 'last_bridge', and the
atomic_get_output_bus_fmts hook of the display-connector should get
called. However, for some reason I am not yet sure of, the condition

:: if (last_bridge->funcs->atomic_get_output_bus_fmts)

fails and the 'select_bus_fmt_recursive' function gets called instead,
(with MEDIA_BUS_FMT_FIXED as output_fmt), which in turn calls the
atomic_get_input_bus_fmts hook of the mhdp-8546. This entirely skips the
display-connector out of the format negotiation.

This doesn't happen when the HDMI bridges are in concern, even though,
they too are connected with display-connector (with compatible
"hdmi-connector").

I looked into the display-connector driver hoping to find if the 2 types
of connectors are being treated differently wrt format negotiation, but
I did not find any clue.

Please let me know if you have any idea about this.

Secondly, as mentioned in the

Re: [PATCH v2] phy: mediatek: rework the floating point comparisons to fixed point

2023-05-16 Thread Vinod Koul

On 02-05-23, 10:50, Tom Rix wrote:
> gcc on aarch64 reports
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c: In function 
> ‘mtk_hdmi_pll_set_rate’:
> drivers/phy/mediatek/phy-mtk-hdmi-mt8195.c:240:52: error: 
> ‘-mgeneral-regs-only’
>   is incompatible with the use of floating-point types
>   240 | else if (tmds_clk >= 54 * MEGA && tmds_clk < 148.35 * MEGA)
> 
> Floating point should not be used, so rework the floating point comparisons
> to fixed point.

Applied, thanks

-- 
~Vinod

KUnit tests for TTM subsystem

2023-05-16 Thread Karolina Stolarek




Hi all,

I'm working on KUnit tests for TTM subsystem (nothing RFC-worthy yet), 
with an aim to provide better test coverage for the code used by i915 
and Xe. Before digging deeper, I wanted to check if the priorities 
outlined here make sense and clarify a couple of things.


My plan is to focus on testing the higher layer structs to cover what's 
below, e.g. test ttm_pool functions by testing ttm_device_init() and 
ttm_tt_populate(). I want to split the work into a couple of batches:


1. Basic testing of structs (init/fini and reserve/unreserve), with an 
introduction of fake VRAM resource manager to test ttm_resource_manager 
init. Add some ttm_bo_validate() test stubs.


2. Eviction-specific testing with ttm_bo_validate() to trigger 
ttm_mem_evict_first(), possibly with a separate testing of 
ttm_resource_*_bulk_move() and ttm_bo(un)pin(). Add tests for 
ttm_resource_manager struct, including ttm_sys_man.


3. ttm_tt_(un)populate() testing, adding more coverage to what was 
implemented in (1) and (2).


4. Testing of ttm_bo_vm_ops and mmap/kmap/other features offered by 
ttm_bo_util (not quite clear on how to approach it; suggestions are 
welcome).


Is there something else I should pay attention to here? I can share more 
detailed plan listing specific functions and what tests could cover 
what, if needed.


Also, I have a question on how should I treat drm_gem_object when 
testing ttm_buffer_object. From what I understand, the majority of 
drivers initialize and use the object, but the TTM BO can work without 
it. Should I write the tests against TTM-backed gem objects or use TTM 
BOs with a dummy gem object embedded?


Many thanks,
Karolina

Re: [PATCH v3 1/2] iommu/arm-smmu-qcom: Fix missing adreno_smmu's

2023-05-16 Thread Will Deacon

On Thu, May 11, 2023 at 07:59:05AM -0700, Rob Clark wrote:
> From: Rob Clark 
> 
> When the special handling of qcom,adreno-smmu was moved into
> qcom_smmu_create(), it was overlooked that we didn't have all the
> required entries in qcom_smmu_impl_of_match.  So we stopped getting
> adreno_smmu_priv on sc7180, breaking per-process pgtables.
> 
> Fixes: 30b912a03d91 ("iommu/arm-smmu-qcom: Move the qcom,adreno-smmu check 
> into qcom_smmu_create")
> Suggested-by: Lepton Wu 
> Signed-off-by: Rob Clark 
> ---
>  drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c 
> b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> index d1b296b95c86..66e191773099 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
> @@ -496,20 +496,21 @@ static const struct qcom_smmu_match_data 
> qcom_smmu_500_impl0_data = {
>  /*
>   * Do not add any more qcom,SOC-smmu-500 entries to this list, unless they 
> need
>   * special handling and can not be covered by the qcom,smmu-500 entry.
>   */
>  static const struct of_device_id __maybe_unused qcom_smmu_impl_of_match[] = {
>   { .compatible = "qcom,msm8996-smmu-v2", .data = _smmu_data },
>   { .compatible = "qcom,msm8998-smmu-v2", .data = _smmu_v2_data },
>   { .compatible = "qcom,qcm2290-smmu-500", .data = 
> _smmu_500_impl0_data },
>   { .compatible = "qcom,qdu1000-smmu-500", .data = 
> _smmu_500_impl0_data  },
>   { .compatible = "qcom,sc7180-smmu-500", .data = 
> _smmu_500_impl0_data },
> + { .compatible = "qcom,sc7180-smmu-v2", .data = _smmu_v2_data },
>   { .compatible = "qcom,sc7280-smmu-500", .data = 
> _smmu_500_impl0_data },
>   { .compatible = "qcom,sc8180x-smmu-500", .data = 
> _smmu_500_impl0_data },
>   { .compatible = "qcom,sc8280xp-smmu-500", .data = 
> _smmu_500_impl0_data },
>   { .compatible = "qcom,sdm630-smmu-v2", .data = _smmu_v2_data },
>   { .compatible = "qcom,sdm845-smmu-v2", .data = _smmu_v2_data },
>   { .compatible = "qcom,sdm845-smmu-500", .data = _smmu_500_data },
>   { .compatible = "qcom,sm6115-smmu-500", .data = 
> _smmu_500_impl0_data},
>   { .compatible = "qcom,sm6125-smmu-500", .data = 
> _smmu_500_impl0_data },
>   { .compatible = "qcom,sm6350-smmu-v2", .data = _smmu_v2_data },
>   { .compatible = "qcom,sm6350-smmu-500", .data = 
> _smmu_500_impl0_data },
> @@ -540,12 +541,18 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct 
> arm_smmu_device *smmu)
>   /* Match platform for ACPI boot */
>   if (acpi_match_platform_list(qcom_acpi_platlist) >= 0)
>   return qcom_smmu_create(smmu, 
> _smmu_500_impl0_data);
>   }
>  #endif
>  
>   match = of_match_node(qcom_smmu_impl_of_match, np);
>   if (match)
>   return qcom_smmu_create(smmu, match->data);
>  
> + /* If you hit this WARN_ON() you are missing an entry in the
> +  * qcom_smmu_impl_of_match[] table, and GPU per-process page-
> +  * tables will be broken.
> +  */
> + WARN_ON(of_device_is_compatible(np, "qcom,adreno-smmu"));

Wouldn't it be better to print the information from the comment, rather
than force the user to diagnose a WARN_ON() back to the source?

Will

Re: [PATCH] drm:amd:amdgpu: Fix missing buffer object unlock in failure path

2023-05-16 Thread Alex Deucher

Applied.  Thanks!

Alex

On Mon, May 15, 2023 at 6:27 PM Sukrut Bellary  wrote:
>
>
> On 5/3/23 16:15, Sukrut Bellary wrote:
> > smatch warning -
> > 1) drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3615 gfx_v9_0_kiq_resume()
> > warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'.
> >
> > 2) drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:6901 gfx_v10_0_kiq_resume()
> > warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'.
> >
> > Signed-off-by: Sukrut Bellary 
> > ---
> >  drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 4 +++-
> >  drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c  | 4 +++-
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> > index 8bd07ff59671..66d5c5d68454 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> > @@ -6891,8 +6891,10 @@ static int gfx_v10_0_kiq_resume(struct amdgpu_device 
> > *adev)
> >   return r;
> >
> >   r = amdgpu_bo_kmap(ring->mqd_obj, (void **)>mqd_ptr);
> > - if (unlikely(r != 0))
> > + if (unlikely(r != 0)) {
> > + amdgpu_bo_unreserve(ring->mqd_obj);
> >   return r;
> > + }
> >
> >   gfx_v10_0_kiq_init_queue(ring);
> >   amdgpu_bo_kunmap(ring->mqd_obj);
> > diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c 
> > b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > index bce6919d666a..d5715d8a4128 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> > @@ -3617,8 +3617,10 @@ static int gfx_v9_0_kiq_resume(struct amdgpu_device 
> > *adev)
> >   return r;
> >
> >   r = amdgpu_bo_kmap(ring->mqd_obj, (void **)>mqd_ptr);
> > - if (unlikely(r != 0))
> > + if (unlikely(r != 0)) {
> > + amdgpu_bo_unreserve(ring->mqd_obj);
> >   return r;
> > + }
> >
> >   gfx_v9_0_kiq_init_queue(ring);
> >   amdgpu_bo_kunmap(ring->mqd_obj);
>
> Follow-up.
> Could you please review this patch?
>
>
> --
> Regards,
> Sukrut

Re: [PATCH v2 03/12] drm/exynos: Use regular fbdev I/O helpers


Hi Sam

Am 15.05.23 um 19:43 schrieb Sam Ravnborg:

Hi Thomas,

On Mon, May 15, 2023 at 11:40:24AM +0200, Thomas Zimmermann wrote:

Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Exynos does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.

By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.

v2:
* use FB_IO_HELPERS option

Signed-off-by: Thomas Zimmermann 
Cc: Inki Dae 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Krzysztof Kozlowski 
Cc: Alim Akhtar 
---
  drivers/gpu/drm/exynos/Kconfig|  1 +
  drivers/gpu/drm/exynos/Makefile   |  2 +-
  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 10 +-
  3 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 0cb92d651ff1..7ca7e1dab52c 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -7,6 +7,7 @@ config DRM_EXYNOS
select DRM_DISPLAY_HELPER if DRM_EXYNOS_DP
select DRM_KMS_HELPER
select VIDEOMODE_HELPERS
+   select FB_IO_HELPERS if DRM_FBDEV_EMULATION
select SND_SOC_HDMI_CODEC if SND_SOC
help
  Choose this option if you have a Samsung SoC Exynos chipset.
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 2fd2f3ee4fcf..233a66036584 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -6,7 +6,6 @@
  exynosdrm-y := exynos_drm_drv.o exynos_drm_crtc.o exynos_drm_fb.o \
exynos_drm_gem.o exynos_drm_plane.o exynos_drm_dma.o
  
-exynosdrm-$(CONFIG_DRM_FBDEV_EMULATION) += exynos_drm_fbdev.o

  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMD)   += exynos_drm_fimd.o
  exynosdrm-$(CONFIG_DRM_EXYNOS5433_DECON)  += exynos5433_drm_decon.o
  exynosdrm-$(CONFIG_DRM_EXYNOS7_DECON) += exynos7_drm_decon.o
@@ -23,5 +22,6 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= 
exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_SCALER) += exynos_drm_scaler.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_MIC) += exynos_drm_mic.o
+exynosdrm-$(CONFIG_DRM_FBDEV_EMULATION)+= exynos_drm_fbdev.o

What does this change do?
Maybe something that was left by accident?


It reorders the statements alphabetically. I can remove this, if unwanted.

Best regards
Thomas



Sam

  
  obj-$(CONFIG_DRM_EXYNOS)		+= exynosdrm.o

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index ea4b3d248aac..bdd1d087 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -8,6 +8,8 @@
   *Seung-Woo Kim 
   */
  
+#include 

+
  #include 
  #include 
  #include 
@@ -49,11 +51,9 @@ static const struct fb_ops exynos_drm_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
.fb_mmap= exynos_drm_fb_mmap,
-   .fb_read= drm_fb_helper_cfb_read,
-   .fb_write   = drm_fb_helper_cfb_write,
-   .fb_fillrect= drm_fb_helper_cfb_fillrect,
-   .fb_copyarea= drm_fb_helper_cfb_copyarea,
-   .fb_imageblit   = drm_fb_helper_cfb_imageblit,
+   .fb_fillrect= cfb_fillrect,
+   .fb_copyarea= cfb_copyarea,
+   .fb_imageblit   = cfb_imageblit,
.fb_destroy = exynos_drm_fb_destroy,
  };
  
--

2.40.1


--
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: [PATCH v2 02/12] drm/armada: Use regular fbdev I/O helpers


Hi

Am 15.05.23 um 20:04 schrieb Russell King (Oracle):

On Mon, May 15, 2023 at 07:55:44PM +0200, Sam Ravnborg wrote:

Hi Thomas,

On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:

Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.

By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.

v2:
* use FB_IO_HELPERS option

Signed-off-by: Thomas Zimmermann 
Cc: Russell King 
---
  drivers/gpu/drm/armada/Kconfig| 1 +
  drivers/gpu/drm/armada/armada_fbdev.c | 9 -
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index f5c66d89ba99..5afade25e217 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -3,6 +3,7 @@ config DRM_ARMADA
tristate "DRM support for Marvell Armada SoCs"
depends on DRM && HAVE_CLK && ARM && MMU
select DRM_KMS_HELPER
+   select FB_IO_HELPERS if DRM_FBDEV_EMULATION
help
  Support the "LCD" controllers found on the Marvell Armada 510
  devices.  There are two controllers on the device, each controller
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 0a5fd1aa86eb..6c3bbaf53569 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -5,6 +5,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -34,11 +35,9 @@ static void armada_fbdev_fb_destroy(struct fb_info *info)

  static const struct fb_ops armada_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_read= drm_fb_helper_cfb_read,
-   .fb_write   = drm_fb_helper_cfb_write,

I had expected to see
.fb_read = fb_io_read,

But maybe this only used when using damage handling?

Likewise for drm_fb_helper_cfb_write.

??


-   .fb_fillrect= drm_fb_helper_cfb_fillrect,
-   .fb_copyarea= drm_fb_helper_cfb_copyarea,
-   .fb_imageblit   = drm_fb_helper_cfb_imageblit,
+   .fb_fillrect= cfb_fillrect,
+   .fb_copyarea= cfb_copyarea,
+   .fb_imageblit   = cfb_imageblit,


This part is as expected.


Well, to me it looks like this has gone through an entire circular set
of revisions:

commit e8b70e4dd7b5dad7c2379de6e0851587bf86bfd6
Author: Archit Taneja 
Date:   Wed Jul 22 14:58:04 2015 +0530

 drm/armada: Use new drm_fb_helper functions

-   .fb_fillrect= cfb_fillrect,
-   .fb_copyarea= cfb_copyarea,
-   .fb_imageblit   = cfb_imageblit,
+   .fb_fillrect= drm_fb_helper_cfb_fillrect,
+   .fb_copyarea= drm_fb_helper_cfb_copyarea,
+   .fb_imageblit   = drm_fb_helper_cfb_imageblit,

commit 983780918c759fdbbf0bf033e701bbff75d2af23
Author: Thomas Zimmermann 
Date:   Thu Nov 3 16:14:40 2022 +0100

 drm/fb-helper: Perform all fbdev I/O with the same implementation

+   .fb_read= drm_fb_helper_cfb_read,
+   .fb_write   = drm_fb_helper_cfb_write,

and now effectively those two changes are being reverted, so we'd
now be back to the pre-July 2015 state of affairs. As I believe
the fbdev layer has been stable, this change merely reverts the
driver back to what it once was.


Not quite. One long-standing problem has been that fbdev does not 
protect its public interfaces with CONFIG_FB. If fbdev had been 
disabled, DRM drivers could no longer be linked/loaded. DRM wrappers 
solved this. The issue has recently been fixed for all of DRM. DRM does 
not build it's fbdev emulation if CONFIG_FB has been disabled.


Another thing was that the original DRM wrappers might have been 
different from fbdev's I/O helpers in subtle ways. But now they are 
simple wrappers around their fbdev counterparts; plus the option of 
additional damage handling.  But such damage handling is better 
implemented by the driver itself. The two cases that require it, i915 
and fbdev-generic, are different enough that each should probably have 
it's own code.


Best regards
Thomas





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

[PATCH v2] dt-bindings: display: panel: add panel-mipi-dsi-bringup

2023-05-16 Thread Paulo Pavačić

Add dt-bindings documentation for panel-mipi-dsi-bringup which currently
supports fannal,c3004 panel. Also added fannal to vendor-prefixes.

v2 changelog:
  - revised driver title, now describes purpose
  - revised description, now describes hw
  - revised maintainers, now has only 1 mail
  - removed diacritics from commit/commit author
  - properties/compatible is now enum
  - compatible using only lowercase
  - revised dts example
  - modified MAINTAINERS in this commit (instead of driver commit)
  - dt_bindings_check checked yml
  - checkpatch warning fixed

Signed-off-by: Paulo Pavacic 
---
 .../display/panel/panel-mipi-dsi-bringup.yaml | 54 +++
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
 MAINTAINERS   |  6 +++
 3 files changed, 62 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
new file mode 100644
index ..c9e2b545657e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
@@ -0,0 +1,54 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/panel-mipi-dsi-bringup.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MIPI DSI Bringup Panel Porting Bindings
+
+description: |
+  MIPI DSI Bringup Panel porting bindings to be used for a collection of panels
+  from different manufacturers which don't require backlight control from the
+  driver and have a single reset pin which is required to be passed as an
+  argument.
+
+maintainers:
+  - Paulo Pavacic 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+
+  compatible:
+enum:
+  # compatible must be listed in alphabetical order, ordered by compatible.
+  # The description in the comment is mandatory for each compatible.
+
+# Fannal 480x800 panel
+  - fannal,c3004
+
+  reg: true
+  reset-gpios: true
+
+required:
+  - compatible
+  - reg
+  - reset-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+//example on IMX8MM where GPIO pin 9 is used as a reset pin
+mipi_dsi@32e1 {
+panel@0 {
+compatible = "fannal,c3004";
+reg = <0>;
+pinctrl-0 = <_mipi_dsi_rst>;
+pinctrl-names = "default";
+reset-gpios = < 9 GPIO_ACTIVE_LOW>;
+};
+};
+...
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 82d39ab0231b..f962750f630a 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -462,6 +462,8 @@ patternProperties:
 description: Facebook
   "^fairphone,.*":
 description: Fairphone B.V.
+  "^fannal,.*":
+description: Fannal Electronics Co., Ltd
   "^faraday,.*":
 description: Faraday Technology Corporation
   "^fastrax,.*":
diff --git a/MAINTAINERS b/MAINTAINERS
index e0ad886d3163..46f988ee60bd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6566,6 +6566,12 @@ T:git git://anongit.freedesktop.org/drm/drm-misc
 F:Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
 F:drivers/gpu/drm/tiny/panel-mipi-dbi.c

+DRM DRIVER FOR MIPI DSI BRINGUP
+M:Paulo Pavacic 
+S:Maintained
+C:mipi-dsi-bringup:matrix.org
+F:
Documentation/devicetree/bindings/display/panel/panel-mipi-dsi-bringup.yaml
+
 DRM DRIVER FOR MSM ADRENO GPU
 M:Rob Clark 
 M:Abhinav Kumar 
-- 
2.40.1

Re: [PATCH v4 10/13] phy: amlogic: phy-meson-g12a-mipi-dphy-analog: fix CNTL2_DIF_TX_CTL0 value

2023-05-16 Thread Vinod Koul

On 12-05-23, 15:11, Neil Armstrong wrote:
> Use the same CNTL2_DIF_TX_CTL0 value used by the vendor, it was reported
> fixing timings issues.

Applied to phy/fixes, thanks

-- 
~Vinod

Re: [PATCH v2 02/12] drm/armada: Use regular fbdev I/O helpers


Hi

Am 15.05.23 um 19:55 schrieb Sam Ravnborg:

Hi Thomas,

On Mon, May 15, 2023 at 11:40:23AM +0200, Thomas Zimmermann wrote:

Use the regular fbdev helpers for framebuffer I/O instead of DRM's
helpers. Armada does not use damage handling, so DRM's fbdev helpers
are mere wrappers around the fbdev code.

By using fbdev helpers directly within each DRM fbdev emulation,
we can eventually remove DRM's wrapper functions entirely.

v2:
* use FB_IO_HELPERS option

Signed-off-by: Thomas Zimmermann 
Cc: Russell King 
---
  drivers/gpu/drm/armada/Kconfig| 1 +
  drivers/gpu/drm/armada/armada_fbdev.c | 9 -
  2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/armada/Kconfig b/drivers/gpu/drm/armada/Kconfig
index f5c66d89ba99..5afade25e217 100644
--- a/drivers/gpu/drm/armada/Kconfig
+++ b/drivers/gpu/drm/armada/Kconfig
@@ -3,6 +3,7 @@ config DRM_ARMADA
tristate "DRM support for Marvell Armada SoCs"
depends on DRM && HAVE_CLK && ARM && MMU
select DRM_KMS_HELPER
+   select FB_IO_HELPERS if DRM_FBDEV_EMULATION
help
  Support the "LCD" controllers found on the Marvell Armada 510
  devices.  There are two controllers on the device, each controller
diff --git a/drivers/gpu/drm/armada/armada_fbdev.c 
b/drivers/gpu/drm/armada/armada_fbdev.c
index 0a5fd1aa86eb..6c3bbaf53569 100644
--- a/drivers/gpu/drm/armada/armada_fbdev.c
+++ b/drivers/gpu/drm/armada/armada_fbdev.c
@@ -5,6 +5,7 @@
   */
  
  #include 

+#include 
  #include 
  #include 
  
@@ -34,11 +35,9 @@ static void armada_fbdev_fb_destroy(struct fb_info *info)

  static const struct fb_ops armada_fb_ops = {
.owner  = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
-   .fb_read= drm_fb_helper_cfb_read,
-   .fb_write   = drm_fb_helper_cfb_write,

I had expected to see
.fb_read = fb_io_read,

But maybe this only used when using damage handling?


fb_io_read() and fb_io_write() are the default implementations. They are 
called when no callback has been set.  All the other fbdev drivers leave 
them out, so I kept this pattern for the DRM side as well.


Best regards
Thomas



Likewise for drm_fb_helper_cfb_write.

??


-   .fb_fillrect= drm_fb_helper_cfb_fillrect,
-   .fb_copyarea= drm_fb_helper_cfb_copyarea,
-   .fb_imageblit   = drm_fb_helper_cfb_imageblit,
+   .fb_fillrect= cfb_fillrect,
+   .fb_copyarea= cfb_copyarea,
+   .fb_imageblit   = cfb_imageblit,


This part is as expected.

Sam


.fb_destroy = armada_fbdev_fb_destroy,
  };
  
--

2.40.1


--
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: [PATCH V6 6/6] drm: bridge: samsung-dsim: Support non-burst mode

2023-05-16 Thread Adam Ford

On Mon, May 15, 2023 at 10:26 PM Chen-Yu Tsai  wrote:
>
> On Tue, May 16, 2023 at 7:57 AM Adam Ford  wrote:
> >
> > The high-speed clock is hard-coded to the burst-clock
> > frequency specified in the device tree.  However, when
> > using devices like certain bridge chips without burst mode
> > and varying resolutions and refresh rates, it may be
> > necessary to set the high-speed clock dynamically based
> > on the desired pixel clock for the connected device.
> >
> > This also removes the need to set a clock speed from
> > the device tree for non-burst mode operation, since the
> > pixel clock rate is the rate requested from the attached
> > device like a bridge chip.  This should have no impact
> > for people using burst-mode and setting the burst clock
> > rate is still required for those users.  If the burst
> > clock is not present, change the error message to
> > dev_info indicating the clock use the pixel clock.
> >
> > Signed-off-by: Adam Ford 
> > Tested-by: Chen-Yu Tsai 
> > Tested-by: Frieder Schrempf 
> > Reviewed-by: Frieder Schrempf 
> > ---
> >  drivers/gpu/drm/bridge/samsung-dsim.c | 27 +--
> >  1 file changed, 21 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
> > b/drivers/gpu/drm/bridge/samsung-dsim.c
> > index 3944b7cfbbdf..03b21d13f067 100644
> > --- a/drivers/gpu/drm/bridge/samsung-dsim.c
> > +++ b/drivers/gpu/drm/bridge/samsung-dsim.c
> > @@ -655,16 +655,28 @@ static unsigned long samsung_dsim_set_pll(struct 
> > samsung_dsim *dsi,
> >
> > dsi->hs_clock = fout;
> >
> > +   dsi->hs_clock = fout;
> > +
>
> Not sure about the double assignment. Was this caused by a rebase?

Oops,

I moved this to the previous patch since the updated dphy changes
needed to know the hs_clock. I must forgot to check this when I
applied the subsequent patch, so the double assignment appeared.  I am
surprised the patch tool didn't complain.  I guess the good news is
that nothing is broken, but the bad news is I have to spam everyone
with a V7.  I'll wait a couple days to see if anything finds anything
else.

adam
>
> ChenYu
>
> > return fout;
> >  }
> >
> >  static int samsung_dsim_enable_clock(struct samsung_dsim *dsi)
> >  {
> > -   unsigned long hs_clk, byte_clk, esc_clk;
> > +   unsigned long hs_clk, byte_clk, esc_clk, pix_clk;
> > unsigned long esc_div;
> > u32 reg;
> > +   struct drm_display_mode *m = >mode;
> > +   int bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
> > +
> > +   /* m->clock is in KHz */
> > +   pix_clk = m->clock * 1000;
> > +
> > +   /* Use burst_clk_rate if available, otherwise use the pix_clk */
> > +   if (dsi->burst_clk_rate)
> > +   hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
> > +   else
> > +   hs_clk = samsung_dsim_set_pll(dsi, DIV_ROUND_UP(pix_clk * 
> > bpp, dsi->lanes));
> >
> > -   hs_clk = samsung_dsim_set_pll(dsi, dsi->burst_clk_rate);
> > if (!hs_clk) {
> > dev_err(dsi->dev, "failed to configure DSI PLL\n");
> > return -EFAULT;
> > @@ -935,7 +947,7 @@ static void samsung_dsim_set_display_mode(struct 
> > samsung_dsim *dsi)
> > u32 reg;
> >
> > if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> > -   int byte_clk_khz = dsi->burst_clk_rate / 1000 / 8;
> > +   int byte_clk_khz = dsi->hs_clock / 1000 / 8;
> > int hfp = (m->hsync_start - m->hdisplay) * byte_clk_khz / 
> > m->clock;
> > int hbp = (m->htotal - m->hsync_end) * byte_clk_khz / 
> > m->clock;
> > int hsa = (m->hsync_end - m->hsync_start) * byte_clk_khz / 
> > m->clock;
> > @@ -1785,10 +1797,13 @@ static int samsung_dsim_parse_dt(struct 
> > samsung_dsim *dsi)
> > return PTR_ERR(pll_clk);
> > }
> >
> > +   /* If it doesn't exist, use pixel clock instead of failing */
> > ret = samsung_dsim_of_read_u32(node, 
> > "samsung,burst-clock-frequency",
> > -  >burst_clk_rate, 0);
> > -   if (ret < 0)
> > -   return ret;
> > +  >burst_clk_rate, 1);
> > +   if (ret < 0) {
> > +   dev_info(dev, "Using pixel clock for HS clock frequency\n");
> > +   dsi->burst_clk_rate = 0;
> > +   }
> >
> > ret = samsung_dsim_of_read_u32(node, "samsung,esc-clock-frequency",
> >>esc_clk_rate, 0);
> > --
> > 2.39.2
> >

Re: [PATCH v5 0/8] drm/i915: move DSC RC tables to drm_dsc_helper.c


On 15/05/2023 12:12, Jani Nikula wrote:

On Thu, 04 May 2023, Dmitry Baryshkov  wrote:

Other platforms (msm) will benefit from sharing the DSC config setup
functions. This series moves parts of static DSC config data from the
i915 driver to the common helpers to be used by other drivers.

Note: the RC parameters were cross-checked against config files found in
DSC model 2021062, 20161212 (and 20150914). The first patch modifies
tables according to those config files, while preserving parameter
values using the code. I have not changed one of the values in the
pre-SCR config file as it clearly looks like a typo in the config file,
considering the table E in DSC 1.1 and in the DSC 1.1 SCR.


As I believe I've said before, I think it's fine to merge these either
via drm-intel or drm-misc. Which do you prefer?


No strong preference. Maybe drm-misc would be easier for us to 
back-merge it into msm/next. Otherwise it is up to you.




BR,
Jani.





Chances since v4:
- Rebased on top of drm-intel-next
- Cut the first 8 patches of the series to ease merging. The rest of the
   patches will go afterwards.

Chances since v3:
- Rebased on top of drm-intel-next
- Dropped the msm patch to make patchset fully mergeable through
   drm-intel
- Made drm_dsc_set_const_params() ignore rc_model_size, picked up
   drm_dsc_set_initial_scale_value() patch by Jessica and switched
   intel_vdsc.c to use those two helpers.
- Added a patch to make i915 actually use rc_tgt_offset_high,
   rc_tgt_offset_low and rc_edge_factor from struct drm_dsc_config.

Chances since v2:
- Rebased on top of drm-intel-next

Chances since v1:
- Made drm_dsc_rc_buf_thresh static rather than exporting it
- Switched drm_dsc_rc_buf_thresh loop to use ARRAY_SIZE. Added
   BUILD_BUG_ON's to be sure that array sizes are correct
- Fixed rc_parameters_data indentation to be logical and tidy
- Fixed drm_dsc_setup_rc_params() kerneldoc
- Added a clause to drm_dsc_setup_rc_params() to verify bpp and bpc
   being set.
- Fixed range_bpg_offset programming in calculate_rc_params()
- Fixed bpp vs bpc bug in intel_dsc_compute_params()
- Added FIXME comment next to the customizations in
   intel_dsc_compute_params().

Dmitry Baryshkov (8):
   drm/i915/dsc: change DSC param tables to follow the DSC model
   drm/i915/dsc: move rc_buf_thresh values to common helper
   drm/i915/dsc: move DSC tables to DRM DSC helper
   drm/i915/dsc: stop using interim structure for calculated params
   drm/display/dsc: use flat array for rc_parameters lookup
   drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
   drm/display/dsc: include the rest of pre-SCR parameters
   drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters

  drivers/gpu/drm/display/drm_dsc_helper.c  | 986 ++
  drivers/gpu/drm/i915/display/intel_vdsc.c | 443 ++
  include/drm/display/drm_dsc_helper.h  |   9 +
  3 files changed, 1042 insertions(+), 396 deletions(-)




--
With best wishes
Dmitry

Re: [PATCH v4 37/41] fbdev: atyfb: Remove unused clock determination

2023-05-16 Thread Ville Syrjälä

On Tue, May 16, 2023 at 01:00:33PM +0200, Niklas Schnelle wrote:
> Just below the removed lines par->clk_wr_offset is hard coded to 3 so
> there is no use in determining a different clock just to then ignore it
> anyway. This also removes the only I/O port use remaining in the driver
> allowing it to be built without CONFIG_HAS_IOPORT.
> 
> Link: https://lore.kernel.org/all/zbx5alo5h546b...@intel.com/
> Suggested-by: Ville Syrjälä 
> Signed-off-by: Niklas Schnelle 

Reviewed-by: Ville Syrjälä 

> ---
> Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
>   per-subsystem patches may be applied independently
> 
>  drivers/video/fbdev/aty/atyfb_base.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
> b/drivers/video/fbdev/aty/atyfb_base.c
> index b02e4e645035..cba2b113b28b 100644
> --- a/drivers/video/fbdev/aty/atyfb_base.c
> +++ b/drivers/video/fbdev/aty/atyfb_base.c
> @@ -3498,11 +3498,6 @@ static int atyfb_setup_generic(struct pci_dev *pdev, 
> struct fb_info *info,
>   if (ret)
>   goto atyfb_setup_generic_fail;
>  #endif
> - if (!(aty_ld_le32(CRTC_GEN_CNTL, par) & CRTC_EXT_DISP_EN))
> - par->clk_wr_offset = (inb(R_GENMO) & 0x0CU) >> 2;
> - else
> - par->clk_wr_offset = aty_ld_8(CLOCK_CNTL, par) & 0x03U;
> -
>   /* according to ATI, we should use clock 3 for acelerated mode */
>   par->clk_wr_offset = 3;
>  
> -- 
> 2.39.2

-- 
Ville Syrjälä
Intel

[PATCH v4 38/41] video: handle HAS_IOPORT dependencies

2023-05-16 Thread Niklas Schnelle

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them and guard inline code in headers.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
  per-subsystem patches may be applied independently

 drivers/video/console/Kconfig |  1 +
 drivers/video/fbdev/Kconfig   | 21 +++--
 include/video/vga.h   |  8 
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 22cea5082ac4..64974eaa3ac5 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -10,6 +10,7 @@ config VGA_CONSOLE
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC &&  !SUPERH 
&& \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
&& \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390 && !UML
+   depends on HAS_IOPORT
select APERTURE_HELPERS if (DRM || FB || VFIO_PCI_CORE)
default y
help
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 96e91570cdd3..a56c57dd839b 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -335,7 +335,7 @@ config FB_IMX
 
 config FB_CYBER2000
tristate "CyberPro 2000/2010/5000 support"
-   depends on FB && PCI && (BROKEN || !SPARC64)
+   depends on FB && PCI && HAS_IOPORT && (BROKEN || !SPARC64)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -429,6 +429,7 @@ config FB_FM2
 config FB_ARC
tristate "Arc Monochrome LCD board support"
depends on FB && (X86 || COMPILE_TEST)
+   depends on HAS_IOPORT
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
@@ -1332,7 +1333,7 @@ config FB_ATY_BACKLIGHT
 
 config FB_S3
tristate "S3 Trio/Virge support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1393,7 +1394,7 @@ config FB_SAVAGE_ACCEL
 
 config FB_SIS
tristate "SiS/XGI display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1424,7 +1425,7 @@ config FB_SIS_315
 
 config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
-   depends on FB && PCI && GPIOLIB && I2C && (X86 || COMPILE_TEST)
+   depends on FB && PCI && GPIOLIB && I2C && HAS_IOPORT && (X86 || 
COMPILE_TEST)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1463,7 +1464,7 @@ endif
 
 config FB_NEOMAGIC
tristate "NeoMagic display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1493,7 +1494,7 @@ config FB_KYRO
 
 config FB_3DFX
tristate "3Dfx Banshee/Voodoo3/Voodoo5 display support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_IMAGEBLIT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -1543,7 +1544,7 @@ config FB_VOODOO1
 
 config FB_VT8623
tristate "VIA VT8623 support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1558,7 +1559,7 @@ config FB_VT8623
 
 config FB_TRIDENT
tristate "Trident/CyberXXX/CyberBlade support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -1581,7 +1582,7 @@ config FB_TRIDENT
 
 config FB_ARK
tristate "ARK 2000PV support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
@@ -2195,7 +2196,7 @@ config FB_SSD1307
 
 config FB_SM712
tristate "Silicon Motion SM712 framebuffer support"
-   depends on FB && PCI
+   depends on FB && PCI && HAS_IOPORT
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
diff --git a/include/video/vga.h b/include/video/vga.h
index 947c0abd04ef..f4b806b85c86 100644
--- a/include/video/vga.h
+++ b/include/video/vga.h
@@ -203,18 +203,26 @@ extern int restore_vga(struct vgastate *state);
 
 static inline unsigned char vga_io_r (unsigned short port)
 {
+#ifdef CONFIG_HAS_IOPORT
return inb_p(port);
+#else
+   return 0xff;
+#endif
 }
 
 static inline void vga_io_w (unsigned short port, unsigned char val)
 {
+#ifdef

Re: [PATCH 12/13] drm/i915/dp: Get optimal link config to have best compressed bpp

2023-05-16 Thread Ville Syrjälä

On Tue, May 16, 2023 at 01:43:44PM +0300, Lisovskiy, Stanislav wrote:
> On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
> > Currently, we take the max lane, rate and pipe bpp, to get the maximum
> > compressed bpp possible. We then set the output bpp to this value.
> > This patch provides support to have max bpp, min rate and min lanes,
> > that can support the min compressed bpp.
> > 
> > v2:
> > -Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
> > -Fix the checks for limits->max/min_bpp while iterating over list of
> >  valid DSC bpcs. (Stan)
> > 
> > v3:
> > -Refactor the code to have pipe bpp/compressed bpp computation and slice
> > count calculation separately for different cases.
> > 
> > v4:
> > -Separate the pipe_bpp calculation for eDP and DP.
> > 
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_dp.c | 305 +++-
> >  1 file changed, 245 insertions(+), 60 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 39e2bf3d738d..578320220c9a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1642,6 +1642,209 @@ static bool intel_dp_dsc_supports_format(struct 
> > intel_dp *intel_dp,
> > return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd, 
> > sink_dsc_format);
> >  }
> >  
> > +static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int 
> > compressed_bpp,
> > +const struct drm_display_mode *adjusted_mode)
> > +{
> > +   int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, 
> > compressed_bpp);
> > +   int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
> > +
> > +   return mode_rate <= link_avail;
> > +}
> > +
> > +static int dsc_compute_link_config(struct intel_dp *intel_dp,
> > +  struct intel_crtc_state *pipe_config,
> > +  struct link_config_limits *limits,
> > +  int pipe_bpp,
> > +  u16 compressed_bpp,
> > +  int timeslots)
> > +{
> > +   const struct drm_display_mode *adjusted_mode =
> > +   _config->hw.adjusted_mode;
> > +   int link_rate, lane_count;
> > +   int dsc_max_bpp;
> > +   struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> > +   int i;
> > +
> > +   for (i = 0; i < intel_dp->num_common_rates; i++) {
> > +   link_rate = intel_dp_common_rate(intel_dp, i);
> > +   if (link_rate < limits->min_rate || link_rate > 
> > limits->max_rate)
> > +   continue;
> > +
> > +   for (lane_count = limits->min_lane_count;
> > +lane_count <= limits->max_lane_count;
> > +lane_count <<= 1) {
> > +   dsc_max_bpp = 
> > intel_dp_dsc_get_max_compressed_bpp(dev_priv,
> > + 
> > link_rate,
> > + 
> > lane_count,
> > + 
> > adjusted_mode->crtc_clock,
> > + 
> > adjusted_mode->crtc_hdisplay,
> > + 
> > pipe_config->bigjoiner_pipes,
> > + 
> > 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_bpp = min_t(u16, dsc_max_bpp, 31);
> > +
> > +   if (compressed_bpp > dsc_max_bpp)
> > +   continue;
> > +
> > +   if (!is_dsc_bw_sufficient(link_rate, lane_count,
> > + compressed_bpp, 
> > adjusted_mode))
> > +   continue;
> > +
> > +   pipe_config->lane_count = lane_count;
> > +   pipe_config->port_clock = link_rate;
> > +
> > +   return 0;
> > +   }
> > +   }
> > +
> > +   return -EINVAL;
> > +}
> > +
> > +static
> > +u16 intel_dp_dsc_max_sink_compressed_bppx16(struct intel_dp *intel_dp,
> > +   struct intel_crtc_state 
> > *pipe_config,
> > +

[PATCH v4 07/41] drm: handle HAS_IOPORT dependencies

2023-05-16 Thread Niklas Schnelle

In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them. In the bochs driver there is optional MMIO
support detected at runtime, warn if this isn't taken when
HAS_IOPORT is not defined.

There is also a direct and hard coded use in cirrus.c which according to
the comment is only necessary during resume.  Let's just skip this as
for example s390 which doesn't have I/O port support also doesen't
support suspend/resume.

Co-developed-by: Arnd Bergmann 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Niklas Schnelle 
---
Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
  per-subsystem patches may be applied independently

 drivers/gpu/drm/qxl/Kconfig   |  1 +
 drivers/gpu/drm/tiny/bochs.c  | 17 +
 drivers/gpu/drm/tiny/cirrus.c |  2 ++
 3 files changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/qxl/Kconfig b/drivers/gpu/drm/qxl/Kconfig
index ca3f51c2a8fe..d0e0d440c8d9 100644
--- a/drivers/gpu/drm/qxl/Kconfig
+++ b/drivers/gpu/drm/qxl/Kconfig
@@ -2,6 +2,7 @@
 config DRM_QXL
tristate "QXL virtual GPU"
depends on DRM && PCI && MMU
+   depends on HAS_IOPORT
select DRM_KMS_HELPER
select DRM_TTM
select DRM_TTM_HELPER
diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c
index d254679a136e..3710339407cc 100644
--- a/drivers/gpu/drm/tiny/bochs.c
+++ b/drivers/gpu/drm/tiny/bochs.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -105,7 +106,9 @@ static void bochs_vga_writeb(struct bochs_device *bochs, 
u16 ioport, u8 val)
 
writeb(val, bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outb(val, ioport);
+#endif
}
 }
 
@@ -119,7 +122,11 @@ static u8 bochs_vga_readb(struct bochs_device *bochs, u16 
ioport)
 
return readb(bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
return inb(ioport);
+#else
+   return 0xff;
+#endif
}
 }
 
@@ -132,8 +139,12 @@ static u16 bochs_dispi_read(struct bochs_device *bochs, 
u16 reg)
 
ret = readw(bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
ret = inw(VBE_DISPI_IOPORT_DATA);
+#else
+   ret = 0x;
+#endif
}
return ret;
 }
@@ -145,8 +156,10 @@ static void bochs_dispi_write(struct bochs_device *bochs, 
u16 reg, u16 val)
 
writew(val, bochs->mmio + offset);
} else {
+#ifdef CONFIG_HAS_IOPORT
outw(reg, VBE_DISPI_IOPORT_INDEX);
outw(val, VBE_DISPI_IOPORT_DATA);
+#endif
}
 }
 
@@ -229,6 +242,10 @@ static int bochs_hw_init(struct drm_device *dev)
return -ENOMEM;
}
} else {
+   if (!IS_ENABLED(CONFIG_HAS_IOPORT)) {
+   DRM_ERROR("I/O ports are not supported\n");
+   return -EIO;
+   }
ioaddr = VBE_DISPI_IOPORT_INDEX;
iosize = 2;
if (!request_region(ioaddr, iosize, "bochs-drm")) {
diff --git a/drivers/gpu/drm/tiny/cirrus.c b/drivers/gpu/drm/tiny/cirrus.c
index 594bc472862f..c65fea049bc7 100644
--- a/drivers/gpu/drm/tiny/cirrus.c
+++ b/drivers/gpu/drm/tiny/cirrus.c
@@ -508,8 +508,10 @@ static void cirrus_crtc_helper_atomic_enable(struct 
drm_crtc *crtc,
 
cirrus_mode_set(cirrus, _state->mode);
 
+#ifdef CONFIG_HAS_IOPORT
/* Unblank (needed on S3 resume, vgabios doesn't do it then) */
outb(VGA_AR_ENABLE_DISPLAY, VGA_ATT_W);
+#endif
 
drm_dev_exit(idx);
 }
-- 
2.39.2

[PATCH v4 37/41] fbdev: atyfb: Remove unused clock determination

2023-05-16 Thread Niklas Schnelle

Just below the removed lines par->clk_wr_offset is hard coded to 3 so
there is no use in determining a different clock just to then ignore it
anyway. This also removes the only I/O port use remaining in the driver
allowing it to be built without CONFIG_HAS_IOPORT.

Link: https://lore.kernel.org/all/zbx5alo5h546b...@intel.com/
Suggested-by: Ville Syrjälä 
Signed-off-by: Niklas Schnelle 
---
Note: The HAS_IOPORT Kconfig option was added in v6.4-rc1 so
  per-subsystem patches may be applied independently

 drivers/video/fbdev/aty/atyfb_base.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/video/fbdev/aty/atyfb_base.c 
b/drivers/video/fbdev/aty/atyfb_base.c
index b02e4e645035..cba2b113b28b 100644
--- a/drivers/video/fbdev/aty/atyfb_base.c
+++ b/drivers/video/fbdev/aty/atyfb_base.c
@@ -3498,11 +3498,6 @@ static int atyfb_setup_generic(struct pci_dev *pdev, 
struct fb_info *info,
if (ret)
goto atyfb_setup_generic_fail;
 #endif
-   if (!(aty_ld_le32(CRTC_GEN_CNTL, par) & CRTC_EXT_DISP_EN))
-   par->clk_wr_offset = (inb(R_GENMO) & 0x0CU) >> 2;
-   else
-   par->clk_wr_offset = aty_ld_8(CLOCK_CNTL, par) & 0x03U;
-
/* according to ATI, we should use clock 3 for acelerated mode */
par->clk_wr_offset = 3;
 
-- 
2.39.2

Re: [PATCH 1/5] drm/debugfs: drop debugfs_init() for the render and accel node v2

2023-05-16 Thread Stanislaw Gruszka

On Mon, Apr 24, 2023 at 02:30:24PM +0200, Christian König wrote:
> We want to remove per minor debugfs directories. Start by stopping
> drivers from adding anything inside of those in the mid layer callback.
> 
> v2: drop it for the accel node as well
> 
> Signed-off-by: Christian König 
Tested-by: Stanislaw Gruszka 

I tested with accel and ivpu driver.

I believe main concern of prevent access before registering
is already solved. Any plans to apply this ? 

Regards
Stanislaw

Re: [PATCH] drm/panel: simple: fix active size for Ampire AM-480272H3TMQW-T01H

2023-05-16 Thread Neil Armstrong


On 16/05/2023 10:50, Dario Binacchi wrote:

The previous setting was related to the overall dimension and not to the
active display area.
In the "PHYSICAL SPECIFICATIONS" section, the datasheet shows the
following parameters:

  --
|   Item| Specifications| unit |
  --
| Display area  | 98.7 (W) x 57.5 (H)   |  mm  |
  --
| Overall dimension | 105.5(W) x 67.2(H) x 4.96(D)  |  mm  |
  --

Fixes: 966fea78adf23 ("drm/panel: simple: Add support for Ampire 
AM-480272H3TMQW-T01H")
Signed-off-by: Dario Binacchi 
---

  drivers/gpu/drm/panel/panel-simple.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 065f378bba9d..d8efbcee9bc1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -759,8 +759,8 @@ static const struct panel_desc ampire_am_480272h3tmqw_t01h 
= {
.num_modes = 1,
.bpc = 8,
.size = {
-   .width = 105,
-   .height = 67,
+   .width = 99,
+   .height = 58,
},
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
  };


Reviewed-by: Neil Armstrong

RE: [PATCH v3 1/5] i2c: Enhance i2c_new_ancillary_device API

2023-05-16 Thread Biju Das

Hi Geert,

Thanks for the feedback.

> Subject: Re: [PATCH v3 1/5] i2c: Enhance i2c_new_ancillary_device API
> 
> Hi Biju,
> 
> On Sat, May 13, 2023 at 6:52 PM Biju Das 
> wrote:
> > Renesas PMIC RAA215300 exposes two separate i2c devices, one for the
> > main device and another for rtc device.
> >
> > Enhance i2c_new_ancillary_device() to instantiate a real device.
> > (eg: Instantiate rtc device from PMIC driver)
> >
> > Signed-off-by: Biju Das 
> > ---
> > v3:
> >  * New patch
> 
> Thanks for your patch!
> 
> Looks correct to me, so
> Reviewed-by: Geert Uytterhoeven 
> 
> Some suggestions for improvement below...

OK.

> 
> > --- a/drivers/i2c/i2c-core-base.c
> > +++ b/drivers/i2c/i2c-core-base.c
> > @@ -1153,7 +1157,27 @@ struct i2c_client
> *i2c_new_ancillary_device(struct i2c_client *client,
> > }
> >
> > dev_dbg(>adapter->dev, "Address for %s : 0x%x\n",
> name, addr);
> > -   return i2c_new_dummy_device(client->adapter, addr);
> > +
> > +   if (aux_device_name) {
> > +   struct i2c_board_info info;
> > +   size_t aux_device_name_len = strlen(aux_device_name);
> > +
> > +   if (aux_device_name_len > I2C_NAME_SIZE - 1) {
> > +   dev_err(>adapter->dev, "Invalid device
> name\n");
> > +   return ERR_PTR(-EINVAL);
> > +   }
> 
> strscpy() return value?
> 
> > +
> > +   memset(, 0, sizeof(struct i2c_board_info));
> 
> The call to memset() would not be needed if info would be initialized at
> declaration time, i.e.
> 
> struct i2c_board_info info = { .addr = addr };
> 
> Or, use I2C_BOARD_INFO(), to guarantee initialization is aligned with
> whatever future changes made to i2c_board_info? But that relies on
> providing the name at declaration time, which we already have in
> i2c_new_dummy_device().
> 
> So I suggest to add a name parameter to i2c_new_dummy_device(), rename
> it to __i2c_new_dummy_device(), and create a wrapper for compatibility
> with existing users:
> 
> struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter
> *adapter, u16 address,
>  const char *name)
> {
> struct i2c_board_info info = {
> I2C_BOARD_INFO("dummy", address),
> };
> 
> if (name) {
> ssize_ret = strscpy(info.type, name,
> sizeof(info.type));
> 
> if (ret < 0)
> return ERR_PTR(dev_err_probe(
> >adapter->dev,
>ret, "Invalid device
> name\n");
> }
> 
> return i2c_new_client_device(adapter, );
> }

OK will introduce, static function

static struct i2c_client *__i2c_new_dummy_device(struct i2c_adapter *adapter,
u16 address, const char *name)

and is called by both "i2c_new_dummy_device" and "i2c_new_ancillary_device"

Cheers,
Biju


> 
> > +
> > +   memcpy(info.type, aux_device_name,
> aux_device_name_len);
> > +   info.addr = addr;
> > +
> > +   i2c_aux_client = i2c_new_client_device(client-
> >adapter, );
> > +   } else {
> > +   i2c_aux_client = i2c_new_dummy_device(client->adapter,
> addr);
> > +   }
> > +
> > +   return i2c_aux_client;
> >  }
> >  EXPORT_SYMBOL_GPL(i2c_new_ancillary_device);

Re: [PATCH 12/13] drm/i915/dp: Get optimal link config to have best compressed bpp

2023-05-16 Thread Lisovskiy, Stanislav

On Fri, May 12, 2023 at 11:54:16AM +0530, Ankit Nautiyal wrote:
> Currently, we take the max lane, rate and pipe bpp, to get the maximum
> compressed bpp possible. We then set the output bpp to this value.
> This patch provides support to have max bpp, min rate and min lanes,
> that can support the min compressed bpp.
> 
> v2:
> -Avoid ending up with compressed bpp, same as pipe bpp. (Stan)
> -Fix the checks for limits->max/min_bpp while iterating over list of
>  valid DSC bpcs. (Stan)
> 
> v3:
> -Refactor the code to have pipe bpp/compressed bpp computation and slice
> count calculation separately for different cases.
> 
> v4:
> -Separate the pipe_bpp calculation for eDP and DP.
> 
> Signed-off-by: Ankit Nautiyal 
> ---
>  drivers/gpu/drm/i915/display/intel_dp.c | 305 +++-
>  1 file changed, 245 insertions(+), 60 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c 
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 39e2bf3d738d..578320220c9a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1642,6 +1642,209 @@ static bool intel_dp_dsc_supports_format(struct 
> intel_dp *intel_dp,
>   return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd, 
> sink_dsc_format);
>  }
>  
> +static bool is_dsc_bw_sufficient(int link_rate, int lane_count, int 
> compressed_bpp,
> +  const struct drm_display_mode *adjusted_mode)
> +{
> + int mode_rate = intel_dp_link_required(adjusted_mode->crtc_clock, 
> compressed_bpp);
> + int link_avail = intel_dp_max_data_rate(link_rate, lane_count);
> +
> + return mode_rate <= link_avail;
> +}
> +
> +static int dsc_compute_link_config(struct intel_dp *intel_dp,
> +struct intel_crtc_state *pipe_config,
> +struct link_config_limits *limits,
> +int pipe_bpp,
> +u16 compressed_bpp,
> +int timeslots)
> +{
> + const struct drm_display_mode *adjusted_mode =
> + _config->hw.adjusted_mode;
> + int link_rate, lane_count;
> + int dsc_max_bpp;
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + int i;
> +
> + for (i = 0; i < intel_dp->num_common_rates; i++) {
> + link_rate = intel_dp_common_rate(intel_dp, i);
> + if (link_rate < limits->min_rate || link_rate > 
> limits->max_rate)
> + continue;
> +
> + for (lane_count = limits->min_lane_count;
> +  lane_count <= limits->max_lane_count;
> +  lane_count <<= 1) {
> + dsc_max_bpp = 
> intel_dp_dsc_get_max_compressed_bpp(dev_priv,
> +   
> link_rate,
> +   
> lane_count,
> +   
> adjusted_mode->crtc_clock,
> +   
> adjusted_mode->crtc_hdisplay,
> +   
> pipe_config->bigjoiner_pipes,
> +   
> 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_bpp = min_t(u16, dsc_max_bpp, 31);
> +
> + if (compressed_bpp > dsc_max_bpp)
> + continue;
> +
> + if (!is_dsc_bw_sufficient(link_rate, lane_count,
> +   compressed_bpp, 
> adjusted_mode))
> + continue;
> +
> + pipe_config->lane_count = lane_count;
> + pipe_config->port_clock = link_rate;
> +
> + return 0;
> + }
> + }
> +
> + return -EINVAL;
> +}
> +
> +static
> +u16 intel_dp_dsc_max_sink_compressed_bppx16(struct intel_dp *intel_dp,
> + struct intel_crtc_state 
> *pipe_config,
> + int bpc)
> +{
> + u16 max_bppx16 = drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd);
> +
> + if (max_bppx16)
> + return max_bppx16;
> + /*
> +  * If support not given in DPCD

Re: [PATCH v2] drm/dp_mst: Clear MSG_RDY flag before sending new message

2023-05-16 Thread Jani Nikula

On Thu, 27 Apr 2023, Wayne Lin  wrote:
> [Why]
> The sequence for collecting down_reply from source perspective should
> be:
>
> Request_n->repeat (get partial reply of Request_n->clear message ready
> flag to ack DPRX that the message is received) till all partial
> replies for Request_n are received->new Request_n+1.
>
> Now there is chance that drm_dp_mst_hpd_irq() will fire new down
> request in the tx queue when the down reply is incomplete. Source is
> restricted to generate interveleaved message transactions so we should
> avoid it.
>
> Also, while assembling partial reply packets, reading out DPCD DOWN_REP
> Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be
> wrapped up as a complete operation for reading out a reply packet.
> Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might
> be risky. e.g. If the reply of the new request has overwritten the
> DPRX DOWN_REP Sideband MSG buffer before source writing one to clear
> DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply
> for the new request. Should handle the up request in the same way.
>
> [How]
> Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ
> event, driver calls drm_dp_mst_hpd_irq_step2() and might trigger
> drm_dp_mst_kick_tx() only when there is no on going message transaction.
>
> Changes since v1:
> * Reworked on review comments received
> -> Adjust the fix to let driver explicitly kick off new down request
> when mst irq event is handled and acked
> -> Adjust the commit message
>
> Signed-off-by: Wayne Lin 
> Cc: sta...@vger.kernel.org
> ---
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  8 ++---
>  drivers/gpu/drm/display/drm_dp_mst_topology.c | 35 ---
>  drivers/gpu/drm/i915/display/intel_dp.c   |  5 ++-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  5 ++-
>  include/drm/display/drm_dp_mst_helper.h   |  4 +--
>  5 files changed, 45 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 1ad67c2a697e..48bdcb2ee9b1 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -3259,10 +3259,9 @@ static void dm_handle_mst_sideband_msg(struct 
> amdgpu_dm_connector *aconnector)
>   DRM_DEBUG_DRIVER("ESI %02x %02x %02x\n", esi[0], esi[1], 
> esi[2]);
>   /* handle HPD short pulse irq */
>   if (aconnector->mst_mgr.mst_state)
> - drm_dp_mst_hpd_irq(
> - >mst_mgr,
> - esi,
> - _irq_handled);
> + drm_dp_mst_hpd_irq_step1(>mst_mgr,
> +  esi,
> +  _irq_handled);
>  
>   if (new_irq_handled) {
>   /* ACK at DPCD to notify down stream */
> @@ -3281,6 +3280,7 @@ static void dm_handle_mst_sideband_msg(struct 
> amdgpu_dm_connector *aconnector)
>   break;
>   }
>  
> + drm_dp_mst_hpd_irq_step2(>mst_mgr);
>   /* check if there is new irq to be handled */
>   dret = drm_dp_dpcd_read(
>   >dm_dp_aux.aux,
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 70df29fe92db..2e0a38a6509c 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -4045,7 +4045,7 @@ static int drm_dp_mst_handle_up_req(struct 
> drm_dp_mst_topology_mgr *mgr)
>  }
>  
>  /**
> - * drm_dp_mst_hpd_irq() - MST hotplug IRQ notify
> + * drm_dp_mst_hpd_irq_step1() - MST hotplug IRQ notify
>   * @mgr: manager to notify irq for.
>   * @esi: 4 bytes from SINK_COUNT_ESI
>   * @handled: whether the hpd interrupt was consumed or not
> @@ -4055,7 +4055,7 @@ static int drm_dp_mst_handle_up_req(struct 
> drm_dp_mst_topology_mgr *mgr)
>   * topology manager will process the sideband messages received as a result
>   * of this.
>   */
> -int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, bool 
> *handled)
> +int drm_dp_mst_hpd_irq_step1(struct drm_dp_mst_topology_mgr *mgr, u8 *esi, 
> bool *handled)

If you're changing the signature of the function, I'd make esi "const u8
*esi", and add a separate "u8 *ack" that you have to provide, where this
function would |= the flags to ack. It would be useful at least in i915.

As to naming, _step1 and _step2 are pretty vague.

>  {
>   int ret = 0;
>   int sc;
> @@ -4077,11 +4077,38 @@ int drm_dp_mst_hpd_irq(struct drm_dp_mst_topology_mgr 
> *mgr, u8 *esi, bool *handl
>   *handled = true;
>   }
>  
> - drm_dp_mst_kick_tx(mgr);
>   return ret;
>  }
> -EXPORT_SYMBOL(drm_dp_mst_hpd_irq);
>

Re: [PATCH v5 1/6] mm/gup: remove unused vmas parameter from get_user_pages()

2023-05-16 Thread David Hildenbrand


On 15.05.23 21:07, Sean Christopherson wrote:

On Sun, May 14, 2023, Lorenzo Stoakes wrote:

No invocation of get_user_pages() use the vmas parameter, so remove it.

The GUP API is confusing and caveated. Recent changes have done much to
improve that, however there is more we can do. Exporting vmas is a prime
target as the caller has to be extremely careful to preclude their use
after the mmap_lock has expired or otherwise be left with dangling
pointers.

Removing the vmas parameter focuses the GUP functions upon their primary
purpose - pinning (and outputting) pages as well as performing the actions
implied by the input flags.

This is part of a patch series aiming to remove the vmas parameter
altogether.

Suggested-by: Matthew Wilcox (Oracle) 
Acked-by: Greg Kroah-Hartman 
Acked-by: David Hildenbrand 
Reviewed-by: Jason Gunthorpe 
Acked-by: Christian Kï¿½nig  (for radeon parts)
Acked-by: Jarkko Sakkinen 
Signed-off-by: Lorenzo Stoakes 
---
  arch/x86/kernel/cpu/sgx/ioctl.c | 2 +-
  drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
  drivers/misc/sgi-gru/grufault.c | 2 +-
  include/linux/mm.h  | 3 +--
  mm/gup.c| 9 +++--
  mm/gup_test.c   | 5 ++---
  virt/kvm/kvm_main.c | 2 +-
  7 files changed, 10 insertions(+), 15 deletions(-)


Acked-by: Sean Christopherson  (KVM)


diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index cb5c13eee193..eaa5bb8dbadc 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2477,7 +2477,7 @@ static inline int check_user_page_hwpoison(unsigned long 
addr)
  {
int rc, flags = FOLL_HWPOISON | FOLL_WRITE;
  
-	rc = get_user_pages(addr, 1, flags, NULL, NULL);

+   rc = get_user_pages(addr, 1, flags, NULL);
return rc == -EHWPOISON;


Unrelated to this patch, I think there's a pre-existing bug here.  If gup() 
returns
a valid page, KVM will leak the refcount and unintentionally pin the page.  
That's


When passing NULL as "pages" to get_user_pages(), 
__get_user_pages_locked() won't set FOLL_GET. As FOLL_PIN is also not 
set, we won't be messing with the mapcount of the page.


So even if get_user_pages() returns "1", we should be fine.


Or am I misunderstanding your concern? At least hva_to_pfn_slow() most 
certainly didn't return "1" if we end up calling 
check_user_page_hwpoison(), so nothing would have been pinned there as well.


--
Thanks,

David / dhildenb

Re: [PATCH 05/13] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck

2023-05-16 Thread Lisovskiy, Stanislav

On Mon, May 15, 2023 at 05:44:51PM +0300, Ville Syrjälä wrote:
> On Fri, May 12, 2023 at 11:54:09AM +0530, Ankit Nautiyal wrote:
> > As per Bsepc:49259, Bigjoiner BW check puts restriction on the
> > compressed bpp for a given CDCLK, pixelclock in cases where
> > Bigjoiner + DSC are used.
> > 
> > Currently compressed bpp is computed first, and it is ensured that
> > the bpp will work at least with the max CDCLK freq.
> > 
> > Since the CDCLK is computed later, lets account for Bigjoiner BW
> > check while calculating Min CDCLK.
> > 
> > Signed-off-by: Ankit Nautiyal 
> > ---
> >  drivers/gpu/drm/i915/display/intel_cdclk.c | 49 ++
> >  1 file changed, 42 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c 
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 6bed75f1541a..3532640c5027 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -2520,6 +2520,46 @@ static int intel_planes_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > return min_cdclk;
> >  }
> >  
> > +static int intel_vdsc_min_cdclk(const struct intel_crtc_state *crtc_state)
> > +{
> > +   struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> > +   struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> > +   int min_cdclk = 0;
> > +
> > +   /*
> > +* When we decide to use only one VDSC engine, since
> > +* each VDSC operates with 1 ppc throughput, pixel clock
> > +* cannot be higher than the VDSC clock (cdclk)
> > +*/
> > +   if (!crtc_state->dsc.dsc_split)
> > +   min_cdclk = max(min_cdclk, (int)crtc_state->pixel_rate);
> > +
> > +   if (crtc_state->bigjoiner_pipes) {
> > +   /*
> > +* According to Bigjoiner bw check:
> > +* compressed_bpp <= PPC * CDCLK * Big joiner Interface bits / 
> > Pixel clock
> > +*
> > +* We have already computed compressed_bpp, so now compute the 
> > min CDCLK that
> > +* is required to support this compressed_bpp.
> > +*
> > +* => CDCLK >= compressed_bpp * Pixel clock / (PPC * Bigjoiner 
> > Interface bits)
> > +*
> > +* Since Num of pipes joined = 2, and PPC = 2 with bigjoiner
> > +* => CDCLK >= compressed_bpp * pixel_rate  / Bigjoiner 
> > Interface bits
> > +*
> > +* #TODO Bspec mentions to account for FEC overhead while using 
> > pixel clock.
> > +* Check if we need to use FEC overhead in the above 
> > calculations.
> > +*/
> > +   int bigjoiner_interface_bits = DISPLAY_VER(i915) > 13 ? 36 : 24;
> > +   int min_cdclk_bj = crtc_state->dsc.compressed_bpp * 
> > crtc_state->pixel_rate /
> > +  bigjoiner_interface_bits;
> 
> pixel_rate is the downscale adjusted thing, so it doesn't seem
> like the correct thing to use here.
> 
> Hmm. Assuming that the single VDSC engine really throttles the entire
> pipe to 1 PPC then we should probably account for the 1 vs. 2 PPC
> difference in *_plane_min_cdclk() and intel_pixel_rate_to_cdclk()
> directly. Currently all of those assume 2 PPC.

Main thing is to properly align that one you propose above with that check,
where we decide how many VDSC engines to use:

/*
 * VDSC engine operates at 1 Pixel per clock, so if peak pixel rate
 * is greater than the maximum Cdclock and if slice count is even
 * then we need to use 2 VDSC instances.
 */
if (adjusted_mode->crtc_clock > dev_priv->max_cdclk_freq) {
if (pipe_config->dsc.slice_count > 1) {
pipe_config->dsc.dsc_split = true;
} else {
drm_dbg_kms(_priv->drm,
"Cannot split stream to use 2 VDSC 
instances\n");
return -EINVAL;
}
}

Otherwise I agree that we should do that check preferrably in *_plane_min_cdclk
and use plane data rate which is adjusted after scaling is applied(I think we 
even have correspondent function there)
It is strange that scaling wasn't mentioned in BSpec formula.
I would also say that we should account for number of slices(i.e VDSC engines) 
now only in Bigjoiner case, but always, as I understand that number can be 
different not only for Bigjoiner cases.

Stan


> 
> > +
> > +   min_cdclk = max(min_cdclk, min_cdclk_bj);
> > +   }
> > +
> > +   return min_cdclk;
> > +}
> > +
> >  int intel_crtc_compute_min_cdclk(const struct intel_crtc_state *crtc_state)
> >  {
> > struct drm_i915_private *dev_priv =
> > @@ -2591,13 +2631,8 @@ int intel_crtc_compute_min_cdclk(const struct 
> > intel_crtc_state *crtc_state)
> > /* Account for additional needs from the planes */
> > min_cdclk = max(intel_planes_min_cdclk(crtc_state), min_cdclk);
> >  
> > -   /*
> > -* When we decide to

[PATCH 08/12] accel/habanalabs: use binning info when handling razwi

From: Dani Liberman 

When receiving sei interrupt from tpc or decoder, we need to check
the binning mask because if the engine is binned, the razwi info
won't be in the router of the binned engine, instead will be in the
router of the substitute engine.

Signed-off-by: Dani Liberman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/gaudi2/gaudi2.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c 
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index b8644d87f817..a6aa17d86820 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -8040,7 +8040,7 @@ static void gaudi2_ack_module_razwi_event_handler(struct 
hl_device *hdev,
u8 module_sub_idx, u64 *event_mask)
 {
bool via_sft = false;
-   u32 hbw_rtr_id, lbw_rtr_id, dcore_id, dcore_rtr_id, eng_id;
+   u32 hbw_rtr_id, lbw_rtr_id, dcore_id, dcore_rtr_id, eng_id, binned_idx;
u64 hbw_rtr_mstr_if_base_addr, lbw_rtr_mstr_if_base_addr;
u32 hbw_shrd_aw = 0, hbw_shrd_ar = 0;
u32 lbw_shrd_aw = 0, lbw_shrd_ar = 0;
@@ -8048,6 +8048,13 @@ static void gaudi2_ack_module_razwi_event_handler(struct 
hl_device *hdev,
 
switch (module) {
case RAZWI_TPC:
+   sprintf(initiator_name, "TPC_%u", module_idx);
+   if (hdev->tpc_binning) {
+   binned_idx = __ffs(hdev->tpc_binning);
+   if (binned_idx == module_idx)
+   module_idx = TPC_ID_DCORE0_TPC6;
+   }
+
hbw_rtr_id = gaudi2_tpc_initiator_hbw_rtr_id[module_idx];
 
if (hl_is_fw_sw_ver_below(hdev, 1, 9) &&
@@ -8056,7 +8063,6 @@ static void gaudi2_ack_module_razwi_event_handler(struct 
hl_device *hdev,
lbw_rtr_id = DCORE0_RTR0;
else
lbw_rtr_id = 
gaudi2_tpc_initiator_lbw_rtr_id[module_idx];
-   sprintf(initiator_name, "TPC_%u", module_idx);
break;
case RAZWI_MME:
sprintf(initiator_name, "MME_%u", module_idx);
@@ -8115,9 +8121,14 @@ static void gaudi2_ack_module_razwi_event_handler(struct 
hl_device *hdev,
sprintf(initiator_name, "NIC_%u", module_idx);
break;
case RAZWI_DEC:
+   sprintf(initiator_name, "DEC_%u", module_idx);
+   if (hdev->decoder_binning) {
+   binned_idx = __ffs(hdev->decoder_binning);
+   if (binned_idx == module_idx)
+   module_idx = DEC_ID_PCIE_VDEC1;
+   }
hbw_rtr_id = gaudi2_dec_initiator_hbw_rtr_id[module_idx];
lbw_rtr_id = gaudi2_dec_initiator_lbw_rtr_id[module_idx];
-   sprintf(initiator_name, "DEC_%u", module_idx);
break;
case RAZWI_ROT:
hbw_rtr_id = gaudi2_rot_initiator_hbw_rtr_id[module_idx];
-- 
2.40.1

[PATCH 11/12] accel/habanalabs: update state when loading boot fit

From: Koby Elbaz 

Any FW component we load must be followed by a corresponding state
update. However, it seems that so far we skipped doing so for the
bootfit case, so fix that.

Signed-off-by: Koby Elbaz 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/firmware_if.c | 25 ---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/drivers/accel/habanalabs/common/firmware_if.c 
b/drivers/accel/habanalabs/common/firmware_if.c
index eb51d7f70aec..acbc1a6b5cb1 100644
--- a/drivers/accel/habanalabs/common/firmware_if.c
+++ b/drivers/accel/habanalabs/common/firmware_if.c
@@ -2486,16 +2486,6 @@ static int hl_fw_dynamic_load_image(struct hl_device 
*hdev,
if (rc)
goto release_fw;
 
-   /* update state according to boot stage */
-   if (cur_fwc == FW_COMP_BOOT_FIT) {
-   struct cpu_dyn_regs *dyn_regs;
-
-   dyn_regs = _loader->dynamic_loader.comm_desc.cpu_dyn_regs;
-   hl_fw_boot_fit_update_state(hdev,
-   le32_to_cpu(dyn_regs->cpu_boot_dev_sts0),
-   le32_to_cpu(dyn_regs->cpu_boot_dev_sts1));
-   }
-
/* copy boot fit to space allocated by FW */
rc = hl_fw_dynamic_copy_image(hdev, fw, fw_loader);
if (rc)
@@ -2798,6 +2788,14 @@ static int hl_fw_dynamic_init_cpu(struct hl_device *hdev,
goto protocol_err;
}
 
+   rc = hl_fw_dynamic_wait_for_boot_fit_active(hdev, fw_loader);
+   if (rc)
+   goto protocol_err;
+
+   hl_fw_boot_fit_update_state(hdev,
+   le32_to_cpu(dyn_regs->cpu_boot_dev_sts0),
+   le32_to_cpu(dyn_regs->cpu_boot_dev_sts1));
+
/*
 * when testing FW load (without Linux) on PLDM we don't want to
 * wait until boot fit is active as it may take several hours.
@@ -2807,10 +2805,6 @@ static int hl_fw_dynamic_init_cpu(struct hl_device *hdev,
if (hdev->pldm && !(hdev->fw_components & FW_TYPE_LINUX))
return 0;
 
-   rc = hl_fw_dynamic_wait_for_boot_fit_active(hdev, fw_loader);
-   if (rc)
-   goto protocol_err;
-
/* Enable DRAM scrambling before Linux boot and after successful
 *  UBoot
 */
@@ -2844,7 +2838,8 @@ static int hl_fw_dynamic_init_cpu(struct hl_device *hdev,
if (rc)
goto protocol_err;
 
-   hl_fw_linux_update_state(hdev, le32_to_cpu(dyn_regs->cpu_boot_dev_sts0),
+   hl_fw_linux_update_state(hdev,
+   le32_to_cpu(dyn_regs->cpu_boot_dev_sts0),
le32_to_cpu(dyn_regs->cpu_boot_dev_sts1));
 
hl_fw_dynamic_update_linux_interrupt_if(hdev);
-- 
2.40.1

[PATCH 12/12] accel/habanalabs: mask part of hmmu page fault captured address

From: Dani Liberman 

When receiving page fault from hmmu, the captured address is scrambled
both by HW and by driver. The driver part is unscrambled but the HW
part isn't getting unscrambled.
To avoid declaring wrong address, the HW scrambled part will be
masked.

Signed-off-by: Dani Liberman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/gaudi2/gaudi2.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c 
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index 4981b8eb0ff5..1cb2b72e1cd2 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -162,6 +162,9 @@
 #define PSOC_RAZWI_ENG_STR_SIZE 128
 #define PSOC_RAZWI_MAX_ENG_PER_RTR 5
 
+/* HW scrambles only bits 0-25 */
+#define HW_UNSCRAMBLED_BITS_MASK GENMASK_ULL(63, 26)
+
 struct gaudi2_razwi_info {
u32 axuser_xy;
u32 rtr_ctrl;
@@ -8835,11 +8838,16 @@ static void gaudi2_handle_page_error(struct hl_device 
*hdev, u64 mmu_base, bool
addr <<= 32;
addr |= RREG32(mmu_base + 
MMU_OFFSET(mmDCORE0_HMMU0_MMU_PAGE_ERROR_CAPTURE_VA));
 
-   if (!is_pmmu)
+   if (is_pmmu) {
+   dev_err_ratelimited(hdev->dev, "PMMU page fault on va 
0x%llx\n", addr);
+   } else {
+
addr = gaudi2_mmu_descramble_addr(hdev, addr);
+   addr &= HW_UNSCRAMBLED_BITS_MASK;
+   dev_err_ratelimited(hdev->dev, "HMMU page fault on va range 
0x%llx - 0x%llx\n",
+   addr, addr + ~HW_UNSCRAMBLED_BITS_MASK);
+   }
 
-   dev_err_ratelimited(hdev->dev, "%s page fault on va 0x%llx\n",
-   is_pmmu ? "PMMU" : "HMMU", addr);
hl_handle_page_fault(hdev, addr, 0, is_pmmu, event_mask);
 
WREG32(mmu_base + 
MMU_OFFSET(mmDCORE0_HMMU0_MMU_ACCESS_PAGE_ERROR_VALID), 0);
-- 
2.40.1

[PATCH 07/12] accel/habanalabs: remove support for mmu disable