Re: [PATCH v2] drm/edid: Support type 7 timings

[Jani Nikula]

On Sun, 23 Jan 2022, Yaroslav Bolyukin  wrote:
> Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data
>
> Definitions were already provided as type I, but not used
>
> Signed-off-by: Yaroslav Bolyukin 

Reviewed-by: Jani Nikula 

> ---
>  drivers/gpu/drm/drm_edid.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 12893e7be..5f2ae5bfa 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -5405,7 +5405,8 @@ u32 drm_add_display_info(struct drm_connector 
> *connector, const struct edid *edi
>  }
>  
>  static struct drm_display_mode *drm_mode_displayid_detailed(struct 
> drm_device *dev,
> - struct 
> displayid_detailed_timings_1 *timings)
> + struct 
> displayid_detailed_timings_1 *timings,
> + bool type_7)
>  {
>   struct drm_display_mode *mode;
>   unsigned pixel_clock = (timings->pixel_clock[0] |
> @@ -5426,7 +5427,8 @@ static struct drm_display_mode 
> *drm_mode_displayid_detailed(struct drm_device *d
>   if (!mode)
>   return NULL;
>  
> - mode->clock = pixel_clock * 10;
> + /* resolution is kHz for type VII, and 10 kHz for type I */
> + mode->clock = type_7 ? pixel_clock : pixel_clock * 10;
>   mode->hdisplay = hactive;
>   mode->hsync_start = mode->hdisplay + hsync;
>   mode->hsync_end = mode->hsync_start + hsync_width;
> @@ -5457,6 +5459,7 @@ static int add_displayid_detailed_1_modes(struct 
> drm_connector *connector,
>   int num_timings;
>   struct drm_display_mode *newmode;
>   int num_modes = 0;
> + bool type_7 = block->tag == DATA_BLOCK_2_TYPE_7_DETAILED_TIMING;
>   /* blocks must be multiple of 20 bytes length */
>   if (block->num_bytes % 20)
>   return 0;
> @@ -5465,7 +5468,7 @@ static int add_displayid_detailed_1_modes(struct 
> drm_connector *connector,
>   for (i = 0; i < num_timings; i++) {
>   struct displayid_detailed_timings_1 *timings = >timings[i];
>  
> - newmode = drm_mode_displayid_detailed(connector->dev, timings);
> + newmode = drm_mode_displayid_detailed(connector->dev, timings, 
> type_7);
>   if (!newmode)
>   continue;
>  
> @@ -5484,7 +5487,8 @@ static int add_displayid_detailed_modes(struct 
> drm_connector *connector,
>  
>   displayid_iter_edid_begin(edid, );
>   displayid_iter_for_each(block, ) {
> - if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING)
> + if (block->tag == DATA_BLOCK_TYPE_1_DETAILED_TIMING ||
> + block->tag == DATA_BLOCK_2_TYPE_7_DETAILED_TIMING)
>   num_modes += add_displayid_detailed_1_modes(connector, 
> block);
>   }
>   displayid_iter_end();
>
> base-commit: 99613159ad749543621da8238acf1a122880144e

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH v5 4/4] dt-bindings: drm/bridge: anx7625: Add aux-bus node

[Hsin-Yi Wang]

On Wed, Jan 19, 2022 at 11:36 PM Robert Foss  wrote:
>
> Hey Hsin-Yi,
>
> While I can review this patch, I don't have the authority to merge it
> since it is outside the scope of my maintainership. Rob Herring,
> Daniel Vetter or David Airlie would have to Ack this patch.

hi Rob,

Can you help ack this patch? thanks
>
> On Wed, 19 Jan 2022 at 16:18, Hsin-Yi Wang  wrote:
> >
> > List panel under aux-bus node if it's connected to anx7625's aux bus.
> >
> > Signed-off-by: Hsin-Yi Wang 
> > Reviewed-by: Xin Ji 
> > ---
> >  .../display/bridge/analogix,anx7625.yaml| 17 +
> >  1 file changed, 17 insertions(+)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > index 1d3e88daca041a..0d38d6fe39830f 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > @@ -83,6 +83,9 @@ properties:
> >  type: boolean
> >  description: let the driver enable audio HDMI codec function or not.
> >
> > +  aux-bus:
> > +$ref: /schemas/display/dp-aux-bus.yaml#
> > +
> >ports:
> >  $ref: /schemas/graph.yaml#/properties/ports
> >
> > @@ -167,5 +170,19 @@ examples:
> >  };
> >  };
> >  };
> > +
> > +aux-bus {
> > +panel {
> > +compatible = "innolux,n125hce-gn1";
> > +power-supply = <_disp_x>;
> > +backlight = <_lcd0>;
> > +
> > +port {
> > +panel_in: endpoint {
> > +remote-endpoint = <_out>;
> > +};
> > +};
> > +};
> > +};
> >  };
> >  };
> > --
> > 2.34.1.703.g22d0c6ccf7-goog
> >

Re: [RFC PATCH v3 1/3] drm: introduce fb_modifiers_not_supported flag in mode_config

[Esaki Tomohito]

Hello Laurent-san

Thank you for your reviews and advices.

I'll fix this patch series following your advice.

Thanks,
Esaki

On 2022/01/24 7:50, Laurent Pinchart wrote:

Hello Esaki-san,

On Fri, Jan 14, 2022 at 07:17:51PM +0900, Tomohito Esaki wrote:

If only linear modifier is advertised, since there are many drivers that
only linear supported, the DRM core should handle this rather than
open-coding in every driver. However, there are legacy drivers such as
radeon that do not support modifiers but infer the actual layout of the
underlying buffer. Therefore, a new flag fb_modifiers_not_supported is
introduced for these legacy drivers, and allow_fb_modifiers is replaced
with this new flag.

Signed-off-by: Tomohito Esaki 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  6 +++---
  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|  2 ++
  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|  2 ++
  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |  1 +
  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |  2 ++
  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  3 +++
  drivers/gpu/drm/drm_framebuffer.c |  6 +++---
  drivers/gpu/drm/drm_ioctl.c   |  2 +-
  drivers/gpu/drm/nouveau/nouveau_display.c |  6 --
  drivers/gpu/drm/radeon/radeon_display.c   |  2 ++
  include/drm/drm_mode_config.h | 10 ++
  11 files changed, 33 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 82011e75ed85..edbb30d47b8c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -954,7 +954,7 @@ static int amdgpu_display_verify_sizes(struct 
amdgpu_framebuffer *rfb)
int ret;
unsigned int i, block_width, block_height, block_size_log2;
  
-	if (!rfb->base.dev->mode_config.allow_fb_modifiers)

+   if (rfb->base.dev->mode_config.fb_modifiers_not_supported)
return 0;
  
  	for (i = 0; i < format_info->num_planes; ++i) {

@@ -1141,7 +1141,7 @@ int amdgpu_display_framebuffer_init(struct drm_device 
*dev,
if (ret)
return ret;
  
-	if (!dev->mode_config.allow_fb_modifiers) {

+   if (dev->mode_config.fb_modifiers_not_supported) {
drm_WARN_ONCE(dev, adev->family >= AMDGPU_FAMILY_AI,
  "GFX9+ requires FB check based on format 
modifier\n");
ret = check_tiling_flags_gfx6(rfb);
@@ -1149,7 +1149,7 @@ int amdgpu_display_framebuffer_init(struct drm_device 
*dev,
return ret;
}
  
-	if (dev->mode_config.allow_fb_modifiers &&

+   if (!dev->mode_config.fb_modifiers_not_supported &&
!(rfb->base.flags & DRM_MODE_FB_MODIFIERS)) {
ret = convert_tiling_flags_to_modifier(rfb);
if (ret) {
diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
index d1570a462a51..fb61c0814115 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
@@ -2798,6 +2798,8 @@ static int dce_v10_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
  
+	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;

+
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
  
  	r = amdgpu_display_modeset_create_props(adev);

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
index 18a7b3bd633b..17942a11366d 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
@@ -2916,6 +2916,8 @@ static int dce_v11_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
  
+	adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;

+
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
  
  	r = amdgpu_display_modeset_create_props(adev);

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
index c7803dc2b2d5..2ec99ec8e1a3 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/dce_v6_0.c
@@ -2674,6 +2674,7 @@ static int dce_v6_0_sw_init(void *handle)
adev_to_drm(adev)->mode_config.max_height = 16384;
adev_to_drm(adev)->mode_config.preferred_depth = 24;
adev_to_drm(adev)->mode_config.prefer_shadow = 1;
+   adev_to_drm(adev)->mode_config.fb_modifiers_not_supported = true;
adev_to_drm(adev)->mode_config.fb_base = adev->gmc.aper_base;
  
  	r = amdgpu_display_modeset_create_props(adev);

diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c 
b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
index 8318ee8339f1..de11fbe5aba2 100644
--- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
+++ 

Re: [PATCH] drm/i915/overlay: Prevent divide by zero bugs in scaling

[Ville Syrjälä]

On Mon, Jan 24, 2022 at 03:24:09PM +0300, Dan Carpenter wrote:
> Smatch detected a divide by zero bug in check_overlay_scaling().
> 
> drivers/gpu/drm/i915/display/intel_overlay.c:976 check_overlay_scaling()
> error: potential divide by zero bug '/ rec->dst_height'.
> drivers/gpu/drm/i915/display/intel_overlay.c:980 check_overlay_scaling()
> error: potential divide by zero bug '/ rec->dst_width'.
> 
> Prevent this by ensuring that the dst height and width are non-zero.
> 
> Fixes: 02e792fbaadb ("drm/i915: implement drmmode overlay support v4")
> Signed-off-by: Dan Carpenter 

Thanks. Pushed to drm-intel-next.

> ---
> >From static analysis.  Not tested.
> 
>  drivers/gpu/drm/i915/display/intel_overlay.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
> b/drivers/gpu/drm/i915/display/intel_overlay.c
> index 1a376e9a1ff3..d610e48cab94 100644
> --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> @@ -959,6 +959,9 @@ static int check_overlay_dst(struct intel_overlay 
> *overlay,
>   const struct intel_crtc_state *pipe_config =
>   overlay->crtc->config;
>  
> + if (rec->dst_height == 0 || rec->dst_width == 0)
> + return -EINVAL;
> +
>   if (rec->dst_x < pipe_config->pipe_src_w &&
>   rec->dst_x + rec->dst_width <= pipe_config->pipe_src_w &&
>   rec->dst_y < pipe_config->pipe_src_h &&
> -- 
> 2.20.1

-- 
Ville Syrjälä
Intel

Re: [PATCH v8 04/10] vgaarb: Move framebuffer detection to ADD_DEVICE path

[Huacai Chen]

Hi, Bjorn,

Why this series still missing in 5.17-rc1? :(

Huacai

On Fri, Jan 7, 2022 at 12:21 AM Bjorn Helgaas  wrote:
>
> On Thu, Jan 06, 2022 at 02:44:42PM +0800, Huacai Chen wrote:
> > On Thu, Jan 6, 2022 at 8:07 AM Bjorn Helgaas  wrote:
> > > Previously we selected a device that owns the boot framebuffer as the
> > > default device in vga_arb_select_default_device().  This was only done in
> > > the vga_arb_device_init() subsys_initcall, so devices enumerated later,
> > > e.g., by pcibios_init(), were not eligible.
> > >
> > > Fix this by moving the framebuffer device selection from
> > > vga_arb_select_default_device() to vga_arbiter_add_pci_device(), which is
> > > called after every PCI device is enumerated, either by the
> > > vga_arb_device_init() subsys_initcall or as an ADD_DEVICE notifier.
> > >
> > > Note that if vga_arb_select_default_device() found a device owning the 
> > > boot
> > > framebuffer, it unconditionally set it to be the default VGA device, and 
> > > no
> > > subsequent device could replace it.
> > >
> > > Link: 
> > > https://lore.kernel.org/r/20211015061512.2941859-7-chenhua...@loongson.cn
> > > Based-on-patch-by: Huacai Chen 
> > > Signed-off-by: Bjorn Helgaas 
> > > Cc: Bruno Prémont 
> > > ---
> > >  drivers/gpu/vga/vgaarb.c | 37 +
> > >  1 file changed, 17 insertions(+), 20 deletions(-)
> > >
> > > diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
> > > index b0ae0f177c6f..aefa4f406f7d 100644
> > > --- a/drivers/gpu/vga/vgaarb.c
> > > +++ b/drivers/gpu/vga/vgaarb.c
> > > @@ -72,6 +72,7 @@ struct vga_device {
> > > unsigned int io_norm_cnt;   /* normal IO count */
> > > unsigned int mem_norm_cnt;  /* normal MEM count */
> > > bool bridge_has_one_vga;
> > > +   bool is_framebuffer;/* BAR covers firmware framebuffer */
> > > unsigned int (*set_decode)(struct pci_dev *pdev, bool decode);
> > >  };
> > >
> > > @@ -565,10 +566,9 @@ void vga_put(struct pci_dev *pdev, unsigned int rsrc)
> > >  }
> > >  EXPORT_SYMBOL(vga_put);
> > >
> > > -static void __init vga_select_framebuffer_device(struct pci_dev *pdev)
> > > +static bool vga_is_framebuffer_device(struct pci_dev *pdev)
> > >  {
> > >  #if defined(CONFIG_X86) || defined(CONFIG_IA64)
> > > -   struct device *dev = >dev;
> > > u64 base = screen_info.lfb_base;
> > > u64 size = screen_info.lfb_size;
> > > u64 limit;
> > > @@ -583,15 +583,6 @@ static void __init 
> > > vga_select_framebuffer_device(struct pci_dev *pdev)
> > >
> > > limit = base + size;
> > >
> > > -   /*
> > > -* Override vga_arbiter_add_pci_device()'s I/O based detection
> > > -* as it may take the wrong device (e.g. on Apple system under
> > > -* EFI).
> > > -*
> > > -* Select the device owning the boot framebuffer if there is
> > > -* one.
> > > -*/
> > > -
> > > /* Does firmware framebuffer belong to us? */
> > > for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
> > > flags = pci_resource_flags(pdev, i);
> > > @@ -608,13 +599,10 @@ static void __init 
> > > vga_select_framebuffer_device(struct pci_dev *pdev)
> > > if (base < start || limit >= end)
> > > continue;
> > >
> > > -   if (!vga_default_device())
> > > -   vgaarb_info(dev, "setting as boot device\n");
> > > -   else if (pdev != vga_default_device())
> > > -   vgaarb_info(dev, "overriding boot device\n");
> > > -   vga_set_default_device(pdev);
> > > +   return true;
> > > }
> > >  #endif
> > > +   return false;
> > >  }
> > >
> > >  static bool vga_arb_integrated_gpu(struct device *dev)
> > > @@ -635,6 +623,7 @@ static bool vga_arb_integrated_gpu(struct device *dev)
> > >  static bool vga_is_boot_device(struct vga_device *vgadev)
> > >  {
> > > struct vga_device *boot_vga = vgadev_find(vga_default_device());
> > > +   struct pci_dev *pdev = vgadev->pdev;
> > >
> > > /*
> > >  * We select the default VGA device in this order:
> > > @@ -645,6 +634,18 @@ static bool vga_is_boot_device(struct vga_device 
> > > *vgadev)
> > >  *   Other device (see vga_arb_select_default_device())
> > >  */
> > >
> > > +   /*
> > > +* We always prefer a firmware framebuffer, so if we've already
> > > +* found one, there's no need to consider vgadev.
> > > +*/
> > > +   if (boot_vga && boot_vga->is_framebuffer)
> > > +   return false;
> > > +
> > > +   if (vga_is_framebuffer_device(pdev)) {
> > > +   vgadev->is_framebuffer = true;
> > > +   return true;
> > > +   }
> > Maybe it is better to rename vga_is_framebuffer_device() to
> > vga_is_firmware_device() and rename is_framebuffer to
> > is_fw_framebuffer?
>
> That's a great point, thanks!
>
> 

Re: [PATCH] drm/msm/a6xx: Add missing suspend_count increment

[Dmitry Baryshkov]

On 13/01/2022 19:32, Rob Clark wrote:

From: Rob Clark 

Reported-by: Danylo Piliaiev 
Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count")
Signed-off-by: Rob Clark 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 51b83776951b..17cfad6424db 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1560,6 +1560,8 @@ static int a6xx_pm_suspend(struct msm_gpu *gpu)
for (i = 0; i < gpu->nr_rings; i++)
a6xx_gpu->shadow[i] = 0;
  
+	gpu->suspend_count++;

+
return 0;
  }
  



--
With best wishes
Dmitry

Re: [PATCH] drm/msm: Fix wrong size calculation

[Dmitry Baryshkov]

On 12/01/2022 15:33, Xianting Tian wrote:

For example, memory-region in .dts as below,
reg = <0x0 0x5000 0x0 0x2000>

We can get below values,
struct resource r;
r.start = 0x5000;
r.end   = 0x6fff;

So the size should be:
size = r.end - r.start + 1 = 0x2000

Signed-off-by: Xianting Tian 


Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem")
Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/msm_drv.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 892c04365..f04a2337d 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -466,7 +466,7 @@ static int msm_init_vram(struct drm_device *dev)
of_node_put(node);
if (ret)
return ret;
-   size = r.end - r.start;
+   size = r.end - r.start + 1;
DRM_INFO("using VRAM carveout: %lx@%pa\n", size, );
  
  		/* if we have no IOMMU, then we need to use carveout allocator.



--
With best wishes
Dmitry

Re: [PATCH] drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable

[Dmitry Baryshkov]

On 16/01/2022 21:18, José Expósito wrote:

The function performs a check on the "phy" input parameter, however, it
is used before the check.

Initialize the "dev" variable after the sanity check to avoid a possible
NULL pointer dereference.

Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files")
Addresses-Coverity-ID: 1493860 ("Null pointer dereference")
Signed-off-by: José Expósito 


Reviewed-by: Dmitry Baryshkov 


---
  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 9842e04b5858..baa6af0c3bcc 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -808,12 +808,14 @@ int msm_dsi_phy_enable(struct msm_dsi_phy *phy,
struct msm_dsi_phy_clk_request *clk_req,
struct msm_dsi_phy_shared_timings *shared_timings)
  {
-   struct device *dev = >pdev->dev;
+   struct device *dev;
int ret;
  
  	if (!phy || !phy->cfg->ops.enable)

return -EINVAL;
  
+	dev = >pdev->dev;

+
ret = dsi_phy_enable_resource(phy);
if (ret) {
DRM_DEV_ERROR(dev, "%s: resource enable failed, %d\n",



--
With best wishes
Dmitry

Re: [v3 2/3] drm/msm/dsi: Add dsi phy tuning configuration support

[Dmitry Baryshkov]

On 18/01/2022 23:38, Rajeev Nandan wrote:

Add support for MSM DSI PHY tuning configuration. Current design is
to support drive strength and drive level/amplitude tuning for
10nm PHY version, but this can be extended to other PHY versions.

Signed-off-by: Rajeev Nandan 


Reviewed-by: Dmitry Baryshkov 


---

Changes in v2:
  - New.
  - Split into generic code and 10nm-specific part (Dmitry Baryshkov)

Changes in v3:
  - s/ops.tuning_cfg_init/ops.parse_dt_properties
To parse phy version specific DT properties (Dmitry Baryshkov)
  - Address comments for phy tuning data structure (Dmitry Baryshkov)


  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 6 ++
  drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4 
  2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8c65ef6..fcbca76 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -739,6 +739,12 @@ static int dsi_phy_driver_probe(struct platform_device 
*pdev)
}
}
  
+	if (phy->cfg->ops.parse_dt_properties) {

+   ret = phy->cfg->ops.parse_dt_properties(phy);
+   if (ret)
+   goto fail;
+   }
+
ret = dsi_phy_regulator_init(phy);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
index b91303a..9e08081 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
@@ -25,6 +25,7 @@ struct msm_dsi_phy_ops {
void (*save_pll_state)(struct msm_dsi_phy *phy);
int (*restore_pll_state)(struct msm_dsi_phy *phy);
bool (*set_continuous_clock)(struct msm_dsi_phy *phy, bool enable);
+   int (*parse_dt_properties)(struct msm_dsi_phy *phy);
  };
  
  struct msm_dsi_phy_cfg {

@@ -81,6 +82,8 @@ struct msm_dsi_dphy_timing {
  #define DSI_PIXEL_PLL_CLK 1
  #define NUM_PROVIDED_CLKS 2
  
+#define DSI_LANE_MAX			5

+
  struct msm_dsi_phy {
struct platform_device *pdev;
void __iomem *base;
@@ -98,6 +101,7 @@ struct msm_dsi_phy {
  
  	struct msm_dsi_dphy_timing timing;

const struct msm_dsi_phy_cfg *cfg;
+   void *tuning_cfg;
  
  	enum msm_dsi_phy_usecase usecase;

bool regulator_ldo_mode;



--
With best wishes
Dmitry

Re: [v3 3/3] drm/msm/dsi: Add 10nm dsi phy tuning configuration support

[Dmitry Baryshkov]

On 18/01/2022 23:38, Rajeev Nandan wrote:

The clock and data lanes of the DSI PHY have a calibration circuitry
feature. As per the MSM DSI PHY tuning guidelines, the drive strength
tuning can be done by adjusting rescode offset for hstop/hsbot, and
the drive level tuning can be done by adjusting the LDO output level
for the HSTX drive.

Signed-off-by: Rajeev Nandan 
---

Changes in v2:
  - Split into generic code and 10nm-specific part (Dmitry Baryshkov)
  - Fix the backward compatibility (Dmitry Baryshkov)

Changes in v3:
  - Address comments for phy tuning data structure (Dmitry Baryshkov)
  - Make changes as per updated dt-bindings


  drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 97 --
  1 file changed, 91 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
index d8128f5..2d225fb 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c
@@ -83,6 +83,18 @@ struct dsi_pll_10nm {
  
  #define to_pll_10nm(x)	container_of(x, struct dsi_pll_10nm, clk_hw)
  
+/**

+ * struct dsi_phy_10nm_tuning_cfg - Holds 10nm PHY tuning config parameters.
+ * @rescode_offset_top: Offset for pull-up legs rescode.
+ * @rescode_offset_bot: Offset for pull-down legs rescode.
+ * @vreg_ctrl: vreg ctrl to drive LDO level
+ */
+struct dsi_phy_10nm_tuning_cfg {
+   u8 rescode_offset_top[DSI_LANE_MAX];
+   u8 rescode_offset_bot[DSI_LANE_MAX];
+   u8 vreg_ctrl;
+};
+
  /*
   * Global list of private DSI PLL struct pointers. We need this for bonded DSI
   * mode, where the master PLL's clk_ops needs access the slave's private data
@@ -747,6 +759,7 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
msm_dsi_phy *phy)
int i;
u8 tx_dctrl[] = { 0x00, 0x00, 0x00, 0x04, 0x01 };
void __iomem *lane_base = phy->lane_base;
+   struct dsi_phy_10nm_tuning_cfg *tuning_cfg = phy->tuning_cfg;
  
  	if (phy->cfg->quirks & DSI_PHY_10NM_QUIRK_OLD_TIMINGS)

tx_dctrl[3] = 0x02;
@@ -775,10 +788,13 @@ static void dsi_phy_hw_v3_0_lane_settings(struct 
msm_dsi_phy *phy)
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG2(i), 0x0);
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_CFG3(i),
  i == 4 ? 0x80 : 0x0);
-   dsi_phy_write(lane_base +
- REG_DSI_10nm_PHY_LN_OFFSET_TOP_CTRL(i), 0x0);
-   dsi_phy_write(lane_base +
- REG_DSI_10nm_PHY_LN_OFFSET_BOT_CTRL(i), 0x0);
+
+   /* platform specific dsi phy drive strength adjustment */
+   dsi_phy_write(lane_base + 
REG_DSI_10nm_PHY_LN_OFFSET_TOP_CTRL(i),
+   tuning_cfg->rescode_offset_top[i]);
+   dsi_phy_write(lane_base + 
REG_DSI_10nm_PHY_LN_OFFSET_BOT_CTRL(i),
+   tuning_cfg->rescode_offset_bot[i]);
+
dsi_phy_write(lane_base + REG_DSI_10nm_PHY_LN_TX_DCTRL(i),
  tx_dctrl[i]);
}
@@ -799,6 +815,7 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
u32 const timeout_us = 1000;
struct msm_dsi_dphy_timing *timing = >timing;
void __iomem *base = phy->base;
+   struct dsi_phy_10nm_tuning_cfg *tuning_cfg = phy->tuning_cfg;
u32 data;
  
  	DBG("");

@@ -834,8 +851,9 @@ static int dsi_10nm_phy_enable(struct msm_dsi_phy *phy,
/* Select MS1 byte-clk */
dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_GLBL_CTRL, 0x10);
  
-	/* Enable LDO */

-   dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_VREG_CTRL, 0x59);
+   /* Enable LDO with platform specific drive level/amplitude adjustment */
+   dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_VREG_CTRL,
+ tuning_cfg->vreg_ctrl);
  
  	/* Configure PHY lane swap (TODO: we need to calculate this) */

dsi_phy_write(base + REG_DSI_10nm_PHY_CMN_LANE_CFG0, 0x21);
@@ -922,6 +940,71 @@ static void dsi_10nm_phy_disable(struct msm_dsi_phy *phy)
DBG("DSI%d PHY disabled", phy->id);
  }
  
+static int dsi_10nm_phy_parse_dt(struct msm_dsi_phy *phy)

+{
+   struct device *dev = >pdev->dev;
+   struct dsi_phy_10nm_tuning_cfg *tuning_cfg;
+   u8 offset_top[DSI_LANE_MAX] = { 0 }; /* No offset */
+   u8 offset_bot[DSI_LANE_MAX] = { 0 }; /* No offset */
+   u32 ldo_level = 400; /* 400mV */
+   u8 level;
+   int ret, i;
+
+   tuning_cfg = devm_kzalloc(dev, sizeof(*tuning_cfg), GFP_KERNEL);
+   if (!tuning_cfg)
+   return -ENOMEM;
+
+   /* Drive strength adjustment parameters */
+   ret = of_property_read_u8_array(dev->of_node, 
"qcom,phy-rescode-offset-top",
+   offset_top, DSI_LANE_MAX);
+   if (ret && ret != -EINVAL)
+   DRM_DEV_ERROR(dev, "failed to parse qcom,phy-rescode-offset-top, 
%d\n", ret);
+
+   for (i = 0; i < 

Re: [PATCH] drm/msm/dp: add connector type to enhance debug messages

[Stephen Boyd]

Quoting Kuogee Hsieh (2022-01-24 14:44:52)
> DP driver is a generic driver which supports both eDP and DP.
> For debugging purpose it is required to have capabilities to
> differentiate message are generated from eDP or DP. This patch
> add connector type into debug messages for this purpose.
>
> Signed-off-by: Kuogee Hsieh 
> ---
>  drivers/gpu/drm/msm/dp/dp_ctrl.c| 20 +--
>  drivers/gpu/drm/msm/dp/dp_display.c | 71 
> ++---
>  2 files changed, 60 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c 
> b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 245e1b9..dcd0126 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -1396,6 +1396,8 @@ void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
>
> dp_catalog_ctrl_phy_reset(ctrl->catalog);
> phy_init(phy);
> +   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
> +   phy, phy->init_count, phy->power_count);
>  }
>
>  void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
> @@ -1410,6 +1412,8 @@ void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
>
> dp_catalog_ctrl_phy_reset(ctrl->catalog);
> phy_exit(phy);
> +   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
> +   phy, phy->init_count, phy->power_count);
>  }
>
>  static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
> @@ -1484,6 +1488,8 @@ static int dp_ctrl_deinitialize_mainlink(struct 
> dp_ctrl_private *ctrl)
> phy_exit(phy);
> phy_init(phy);
>
> +   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
> +   phy, phy->init_count, phy->power_count);
> return 0;
>  }
>

These are entirely new messages. Adding messages isn't mentioned in the
commit text. Please either split this out or indicate in the commit text
what's going on here.

> @@ -1895,14 +1901,12 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
>
> phy_power_off(phy);
>
> -   DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
> -   (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
> -
> /* aux channel down, reinit phy */
> phy_exit(phy);
> phy_init(phy);
>
> -   DRM_DEBUG_DP("DP off link/stream done\n");
> +   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",

The DRM_DEBUG_DP macro says it's deprecated now and we should use
drm_dbg_dp() instead. Can you use that macro instead? Then it looks like
drm->dev can actually be any old struct device, so I guess we're allowed
to pass in the particular instance of dp device this is for. Allowing us
to figure out which DP device is actually printing messages.

> +   phy, phy->init_count, phy->power_count);
> return ret;
>  }
>

[PATCH v2] drm/msm/dp: always add fail-safe mode into connector mode list

[Kuogee Hsieh]

Some of DP link compliant test expects to return fail-safe mode
if prefer detailed timing mode can not be supported by mainlink's
lane and rate after link training. Therefore add fail-safe mode
into connector mode list as backup mode. This patch fixes test
case 4.2.2.1.

Changes in v2:
-- add Fixes text string

Fixes: 4b85d405cfe9 ( "drm/msm/dp: reduce link rate if failed at link training 
1")
Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 71db10c..f141872 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -212,6 +212,11 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
if (drm_add_modes_noedid(connector, 640, 480))
drm_set_preferred_mode(connector, 640, 480);
mutex_unlock(>dev->mode_config.mutex);
+   } else {
+   /* always add fail-safe mode as backup mode */
+   mutex_lock(>dev->mode_config.mutex);
+   drm_add_modes_noedid(connector, 640, 480);
+   mutex_unlock(>dev->mode_config.mutex);
}
 
if (panel->aux_cfg_update_done) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[Bug 201957] amdgpu: ring gfx timeout

[bugzilla-daemon]

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

--- Comment #57 from Spencer (s...@nandre.com) ---
Created attachment 300315
  --> https://bugzilla.kernel.org/attachment.cgi?id=300315=edit
Kernel config

OS: Gentoo
Kernel: 5.15.16, config attached, built with make -j12
Launch options: root=/dev/sda2 ro quiet

I'd like to be able to boot with amdgpu.dpm=0, as this seems to fix the bug
with minor tradeoffs, however:
When I boot with dpm disabled, my screen will freeze and leave this nice little
stinker to ruin my day

Jan 24 16:33:05 [kernel] [2.572474] Loading firmware: amdgpu/navi10_pfp.bin
Jan 24 16:33:05 [kernel] [2.572475] Loading firmware: amdgpu/navi10_me.bin
Jan 24 16:33:05 [kernel] [2.572476] Loading firmware: amdgpu/navi10_ce.bin
Jan 24 16:33:05 [kernel] [2.572477] Loading firmware: amdgpu/navi10_rlc.bin
Jan 24 16:33:05 [kernel] [2.572477] Loading firmware: amdgpu/navi10_mec.bin
Jan 24 16:33:05 [kernel] [2.572478] Loading firmware:
amdgpu/navi10_mec2.bin
Jan 24 16:33:05 [kernel] [2.572968] EXT4-fs (sdb1): mounted filesystem with
ordered data mode. Opts: discard. Quota mode: none.
Jan 24 16:33:05 [kernel] [2.573030] Loading firmware:
amdgpu/navi10_sdma.bin
Jan 24 16:33:05 [kernel] [2.573032] Loading firmware:
amdgpu/navi10_sdma1.bin
Jan 24 16:33:05 [kernel] [2.573071] Loading firmware: amdgpu/navi10_vcn.bin
Jan 24 16:33:05 [kernel] [2.573072] [drm] Found VCN firmware Version ENC:
1.14 DEC: 5 VEP: 0 Revision: 20
Jan 24 16:33:05 [kernel] [2.573075] amdgpu :28:00.0: amdgpu: Will use
PSP to load VCN firmware
Jan 24 16:33:05 [kernel] [2.747244] [drm] reserve 0x90 from
0x817e40 for PSP TMR
Jan 24 16:33:05 [kernel] [2.785931] amdgpu :28:00.0: amdgpu: RAS:
optional ras ta ucode is not available
Jan 24 16:33:05 [kernel] [2.790137] amdgpu :28:00.0: amdgpu: RAP:
optional rap ta ucode is not available
Jan 24 16:33:05 [kernel] [2.790138] amdgpu :28:00.0: amdgpu:
SECUREDISPLAY: securedisplay ta ucode is not available
Jan 24 16:33:05 [kernel] [2.790140] amdgpu: smu firmware loading failed
Jan 24 16:33:05 [kernel] [2.790141] amdgpu :28:00.0: amdgpu:
amdgpu_device_ip_init failed
Jan 24 16:33:05 [kernel] [2.790143] amdgpu :28:00.0: amdgpu: Fatal
error during GPU init
Jan 24 16:33:05 [kernel] [2.790144] amdgpu :28:00.0: amdgpu: amdgpu:
finishing device.
Jan 24 16:33:05 [kernel] [2.793726] [drm] free PSP TMR buffer
Jan 24 16:33:05 [kernel] [2.825874] amdgpu: probe of :28:00.0 failed
with error -95
Jan 24 16:33:05 [kernel] [2.825951] BUG: unable to handle page fault for
address: a4af5100d000
Jan 24 16:33:05 [kernel] [2.825954] #PF: supervisor write access in kernel
mode
Jan 24 16:33:05 [kernel] [2.825955] #PF: error_code(0x0002) - not-present
page
Jan 24 16:33:05 [kernel] [2.825957] PGD 10067 P4D 10067 PUD
100104067 PMD 0
Jan 24 16:33:05 [kernel] [2.825960] Oops: 0002 [#1] SMP NOPTI
Jan 24 16:33:05 [kernel] [2.825962] CPU: 6 PID: 759 Comm: systemd-udevd Not
tainted 5.15.16-gentoo #8
Jan 24 16:33:05 [kernel] [2.825965] Hardware name: Micro-Star International
Co., Ltd MS-7B86/B450 GAMING PLUS MAX (MS-7B86), BIOS H.60 04/18/2020
Jan 24 16:33:05 [kernel] [2.825967] RIP: 0010:vcn_v2_0_sw_fini+0x65/0x80
[amdgpu]
Jan 24 16:33:05 [kernel] [2.826139] Code: 89 ef e8 fe 1b ff ff 85 c0 75 08
48 89 ef e8 42 1a ff ff 48 8b 54 24 08 65 48 2b 14 25 28 00 00 00 75 18 48 83
c4 10 5b 5d c3  03 00 00 00 00 8b 7c 24 04 e8 4c c4 4d e9 eb bc e8 15 cd ab
e9
Jan 24 16:33:05 [kernel] [2.826142] RSP: 0018:a4af40bc7c30 EFLAGS:
00010202

TL;DR: amdgpu: smu firmware loading failed
What it means exactly, I know not, but I know it means my screen is frozen
Is there a trick? A workaround to this?
If there is some info I left out ask for it and I'll fetch it

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

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

linux-next: manual merge of the drm-intel-gt tree with the drm-intel tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel-gt tree got a conflict in:

  drivers/gpu/drm/i915/i915_drv.h

between commit:

  2ef97818d3aa ("drm/i915: split out i915_gem_evict.h from i915_drv.h")

from the drm-intel tree and commit:

  7e00897be8bf ("drm/i915: Add object locking to i915_gem_evict_for_node and 
i915_gem_evict_something, v2.")

from the drm-intel-gt tree.

I fixed it up (I used the former and adde the following merge fix patch)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

From: Stephen Rothwell 
Date: Tue, 25 Jan 2022 09:44:44 +1100
Subject: [PATCH] merge fix for "drm/i915: split out i915_gem_evict.h from 
i915_drv.h"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/i915_gem_evict.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.h 
b/drivers/gpu/drm/i915/i915_gem_evict.h
index d4478b6ad11b..bd6e78abd530 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.h
+++ b/drivers/gpu/drm/i915/i915_gem_evict.h
@@ -12,11 +12,13 @@ struct drm_mm_node;
 struct i915_address_space;
 
 int __must_check i915_gem_evict_something(struct i915_address_space *vm,
+ struct i915_gem_ww_ctx *ww,
  u64 min_size, u64 alignment,
  unsigned long color,
  u64 start, u64 end,
  unsigned flags);
 int __must_check i915_gem_evict_for_node(struct i915_address_space *vm,
+struct i915_gem_ww_ctx *ww,
 struct drm_mm_node *node,
 unsigned int flags);
 int i915_gem_evict_vm(struct i915_address_space *vm);
-- 
2.34.1

But then I also needed due to commit:

  6945c53bc712 ("drm/i915: Add locking to i915_gem_evict_vm(), v3.")

From: Stephen Rothwell 
Date: Tue, 25 Jan 2022 09:51:55 +1100
Subject: [PATCH] extra merge fix for "drm/i915: split out i915_gem_evict.h from 
i915_drv.h"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/i915_gem_evict.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_evict.h 
b/drivers/gpu/drm/i915/i915_gem_evict.h
index bd6e78abd530..b7f8e9435b2c 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.h
+++ b/drivers/gpu/drm/i915/i915_gem_evict.h
@@ -21,6 +21,7 @@ int __must_check i915_gem_evict_for_node(struct 
i915_address_space *vm,
 struct i915_gem_ww_ctx *ww,
 struct drm_mm_node *node,
 unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm);
+int i915_gem_evict_vm(struct i915_address_space *vm,
+ struct i915_gem_ww_ctx *ww);
 
 #endif /* __I915_GEM_EVICT_H__ */
-- 
2.34.1

And then this due to commit

  e849f7e70860 ("drm/i915: Call i915_gem_evict_vm in vm_fault_gtt to prevent 
new ENOSPC errors, v2.")
(and the above commit)

From: Stephen Rothwell 
Date: Tue, 25 Jan 2022 10:02:16 +1100
Subject: [PATCH] extra 2 merge fix for "drm/i915: split out i915_gem_evict.h 
from i915_drv.h"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/gem/i915_gem_mman.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c 
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 4afad1604a6a..a69787999d09 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -21,6 +21,7 @@
 #include "i915_trace.h"
 #include "i915_user_extensions.h"
 #include "i915_gem_ttm.h"
+#include "i915_gem_evict.h"
 #include "i915_vma.h"
 
 static inline bool
-- 
2.34.1

-- 
Cheers,
Stephen Rothwell


pgpOLUJu72VkZ.pgp
Description: OpenPGP digital signature

[Bug 215436] admgpu: suspend and resuming from suspend don't work

[bugzilla-daemon]

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

--- Comment #28 from mario.limoncie...@amd.com ---
As this is now in 5.17-rc1:
https://github.com/torvalds/linux/commit/c4849f88164b13dd141885e28210f599741b304b
this issue can be closed.

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

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

[PATCH] drm/msm/dp: add connector type to enhance debug messages

[Kuogee Hsieh]

DP driver is a generic driver which supports both eDP and DP.
For debugging purpose it is required to have capabilities to
differentiate message are generated from eDP or DP. This patch
add connector type into debug messages for this purpose.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_ctrl.c| 20 +--
 drivers/gpu/drm/msm/dp/dp_display.c | 71 ++---
 2 files changed, 60 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
index 245e1b9..dcd0126 100644
--- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
+++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
@@ -1396,6 +1396,8 @@ void dp_ctrl_phy_init(struct dp_ctrl *dp_ctrl)
 
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_init(phy);
+   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+   phy, phy->init_count, phy->power_count);
 }
 
 void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
@@ -1410,6 +1412,8 @@ void dp_ctrl_phy_exit(struct dp_ctrl *dp_ctrl)
 
dp_catalog_ctrl_phy_reset(ctrl->catalog);
phy_exit(phy);
+   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+   phy, phy->init_count, phy->power_count);
 }
 
 static bool dp_ctrl_use_fixed_nvid(struct dp_ctrl_private *ctrl)
@@ -1484,6 +1488,8 @@ static int dp_ctrl_deinitialize_mainlink(struct 
dp_ctrl_private *ctrl)
phy_exit(phy);
phy_init(phy);
 
+   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+   phy, phy->init_count, phy->power_count);
return 0;
 }
 
@@ -1895,14 +1901,12 @@ int dp_ctrl_off_link_stream(struct dp_ctrl *dp_ctrl)
 
phy_power_off(phy);
 
-   DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
-   (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
-
/* aux channel down, reinit phy */
phy_exit(phy);
phy_init(phy);
 
-   DRM_DEBUG_DP("DP off link/stream done\n");
+   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+   phy, phy->init_count, phy->power_count);
return ret;
 }
 
@@ -1933,13 +1937,9 @@ int dp_ctrl_off(struct dp_ctrl *dp_ctrl)
DRM_ERROR("Failed to disable link clocks. ret=%d\n", ret);
}
 
-   DRM_DEBUG_DP("Before, phy=%x init_count=%d power_on=%d\n",
-   (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
-
phy_power_off(phy);
-
-   DRM_DEBUG_DP("After, phy=%x init_count=%d power_on=%d\n",
-   (u32)(uintptr_t)phy, phy->init_count, phy->power_count);
+   DRM_DEBUG_DP("phy=%p init=%d power_on=%d\n",
+   phy, phy->init_count, phy->power_count);
 
return ret;
 }
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c 
b/drivers/gpu/drm/msm/dp/dp_display.c
index e89556ad..0476032 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -376,8 +376,9 @@ static int dp_display_process_hpd_high(struct 
dp_display_private *dp)
 
 static void dp_display_host_phy_init(struct dp_display_private *dp)
 {
-   DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
-   dp->core_initialized, dp->phy_initialized);
+   DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+   dp->dp_display.connector_type, dp->core_initialized,
+   dp->phy_initialized);
 
if (!dp->phy_initialized) {
dp_ctrl_phy_init(dp->ctrl);
@@ -387,8 +388,9 @@ static void dp_display_host_phy_init(struct 
dp_display_private *dp)
 
 static void dp_display_host_phy_exit(struct dp_display_private *dp)
 {
-   DRM_DEBUG_DP("core_init=%d phy_init=%d\n",
-   dp->core_initialized, dp->phy_initialized);
+   DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+   dp->dp_display.connector_type, dp->core_initialized,
+   dp->phy_initialized);
 
if (dp->phy_initialized) {
dp_ctrl_phy_exit(dp->ctrl);
@@ -398,7 +400,9 @@ static void dp_display_host_phy_exit(struct 
dp_display_private *dp)
 
 static void dp_display_host_init(struct dp_display_private *dp)
 {
-   DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
+   DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+   dp->dp_display.connector_type, dp->core_initialized,
+   dp->phy_initialized);
 
dp_power_init(dp->power, false);
dp_ctrl_reset_irq_ctrl(dp->ctrl, true);
@@ -408,7 +412,9 @@ static void dp_display_host_init(struct dp_display_private 
*dp)
 
 static void dp_display_host_deinit(struct dp_display_private *dp)
 {
-   DRM_DEBUG_DP("core_initialized=%d\n", dp->core_initialized);
+   DRM_DEBUG_DP("type=%d core_init=%d phy_init=%d\n",
+   dp->dp_display.connector_type, dp->core_initialized,
+   dp->phy_initialized);
 
dp_ctrl_reset_irq_ctrl(dp->ctrl, false);
dp_aux_deinit(dp->aux);
@@ -519,7 +525,9 @@ static int 

Re: [PATCH v2 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon

[Daniel Vetter]

On Mon, Jan 24, 2022 at 11:37:03PM +0100, Helge Deller wrote:
> On 1/24/22 23:19, Daniel Vetter wrote:
> > On Mon, Jan 24, 2022 at 10:03:17PM +0100, Helge Deller wrote:
> >> This series reverts two patches which disabled scrolling acceleration in
> >> fbcon/fbdev. Those patches introduced a regression for fbdev-supported 
> >> graphic
> >> cards because of the performance penalty by doing screen scrolling by 
> >> software
> >> instead of using existing 2D hardware acceleration.
> >>
> >> This series has been discussed on linux-fbdev, dri-devel and linux-kernel
> >> mailing lists. The consensus is that they will be reverted, but in addition
> >> it's being worked on to find a solution which allows to disable parts of 
> >> the
> >> classic fbdev hardware acceleration code which isn't needed in DRM-only
> >> configurations.
> >
> > That's not my take at least.
> 
> Which is?
> Didn't we discussed about introducing something like
> CONFIG_FBCON_LEGACY_ACCELERATION ?

Yeah, as part of the reverts. Or at least that's what I meant to say.
-Daniel
> 
> >> The patchset is planned to be kept in fbdev's for-next git branch and later
> >> pushed into kernel v5.18 if no issues are found until then.
> >
> > Neither this. I don't think we've resovled maintainership of fbdev core
> > code and fbcon yet. That is the part that drm folks very much still
> > maintained, as a quick git shortlog will show.
> >
> > Maintaining these parts outside of drm trees just doesn't make sense,
> > since none of the other graphics relevant development happens outside of
> 
> I have no objections if you are willing to take those two patches through
> the drm tree.
> 
> Helge
> 
> >> ---
> >> Changes in v2 compared to v1:
> >> - adjusted the stable tags (one v5.10+, the other v5.16+)
> >> - moved the analysis and reasoning why those should be reverted into
> >>   the commit message. That simplifies to analyze later why they were
> >>   reverted.
> >> - resorted the To an Cc mail recipient lists
> >>
> >> Helge Deller (2):
> >>   Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1
> >> (from TODO list)"
> >>   Revert "fbcon: Disable accelerated scrolling"
> >>
> >>  Documentation/gpu/todo.rst  |  24 --
> >>  drivers/video/fbdev/core/bitblit.c  |  16 +
> >>  drivers/video/fbdev/core/fbcon.c| 540 +++-
> >>  drivers/video/fbdev/core/fbcon.h|  59 +++
> >>  drivers/video/fbdev/core/fbcon_ccw.c|  28 +-
> >>  drivers/video/fbdev/core/fbcon_cw.c |  28 +-
> >>  drivers/video/fbdev/core/fbcon_rotate.h |   9 +
> >>  drivers/video/fbdev/core/fbcon_ud.c |  37 +-
> >>  drivers/video/fbdev/core/tileblit.c |  16 +
> >>  drivers/video/fbdev/skeletonfb.c|  12 +-
> >>  include/linux/fb.h  |   2 +-
> >>  11 files changed, 703 insertions(+), 68 deletions(-)
> >>
> >> --
> >> 2.31.1

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/intel_pm.c

between commit:

  cca084692394 ("drm/i915: Use per device iommu check")

from Linus' tree and commit:

  8172375ea95a ("drm/i915: Remove zombie async flip vt-d w/a")

from the drm-intel tree.

I fixed it up (the latter removed the code modified by the former, so
I just did that) and can carry the fix as necessary. This is now fixed
as far as linux-next is concerned, but any non trivial conflicts should
be mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.



-- 
Cheers,
Stephen Rothwell


pgpkF8kMmtLST.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon

[Helge Deller]

On 1/24/22 23:19, Daniel Vetter wrote:
> On Mon, Jan 24, 2022 at 10:03:17PM +0100, Helge Deller wrote:
>> This series reverts two patches which disabled scrolling acceleration in
>> fbcon/fbdev. Those patches introduced a regression for fbdev-supported 
>> graphic
>> cards because of the performance penalty by doing screen scrolling by 
>> software
>> instead of using existing 2D hardware acceleration.
>>
>> This series has been discussed on linux-fbdev, dri-devel and linux-kernel
>> mailing lists. The consensus is that they will be reverted, but in addition
>> it's being worked on to find a solution which allows to disable parts of the
>> classic fbdev hardware acceleration code which isn't needed in DRM-only
>> configurations.
>
> That's not my take at least.

Which is?
Didn't we discussed about introducing something like
CONFIG_FBCON_LEGACY_ACCELERATION ?

>> The patchset is planned to be kept in fbdev's for-next git branch and later
>> pushed into kernel v5.18 if no issues are found until then.
>
> Neither this. I don't think we've resovled maintainership of fbdev core
> code and fbcon yet. That is the part that drm folks very much still
> maintained, as a quick git shortlog will show.
>
> Maintaining these parts outside of drm trees just doesn't make sense,
> since none of the other graphics relevant development happens outside of

I have no objections if you are willing to take those two patches through
the drm tree.

Helge

>> ---
>> Changes in v2 compared to v1:
>> - adjusted the stable tags (one v5.10+, the other v5.16+)
>> - moved the analysis and reasoning why those should be reverted into
>>   the commit message. That simplifies to analyze later why they were
>>   reverted.
>> - resorted the To an Cc mail recipient lists
>>
>> Helge Deller (2):
>>   Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1
>> (from TODO list)"
>>   Revert "fbcon: Disable accelerated scrolling"
>>
>>  Documentation/gpu/todo.rst  |  24 --
>>  drivers/video/fbdev/core/bitblit.c  |  16 +
>>  drivers/video/fbdev/core/fbcon.c| 540 +++-
>>  drivers/video/fbdev/core/fbcon.h|  59 +++
>>  drivers/video/fbdev/core/fbcon_ccw.c|  28 +-
>>  drivers/video/fbdev/core/fbcon_cw.c |  28 +-
>>  drivers/video/fbdev/core/fbcon_rotate.h |   9 +
>>  drivers/video/fbdev/core/fbcon_ud.c |  37 +-
>>  drivers/video/fbdev/core/tileblit.c |  16 +
>>  drivers/video/fbdev/skeletonfb.c|  12 +-
>>  include/linux/fb.h  |   2 +-
>>  11 files changed, 703 insertions(+), 68 deletions(-)
>>
>> --
>> 2.31.1

linux-next: manual merge of the drm-intel tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/i915/i915_reg.h

between commit:

  77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu")

from Linus' tree and commit:

  202b1f4c1234 ("drm/i915/gt: Move engine registers to their own header")

from the drm-intel tree.

I fixed it up (see below - maybe should be done better?) and can carry the
fix as necessary. This is now fixed as far as linux-next is concerned,
but any non trivial conflicts should be mentioned to your upstream
maintainer when your tree is submitted for merging.  You may also want
to consider cooperating with the maintainer of the conflicting tree to
minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/i915_reg.h
index 971d601fe751,cf168c3e0471..
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@@ -2661,52 -1825,7 +1843,9 @@@
  #define   AUX_INV REG_BIT(0)
  #define BLT_HWS_PGA_GEN7  _MMIO(0x04280)
  #define VEBOX_HWS_PGA_GEN7_MMIO(0x04380)
- #define RING_ACTHD(base)  _MMIO((base) + 0x74)
- #define RING_ACTHD_UDW(base)  _MMIO((base) + 0x5c)
- #define RING_NOPID(base)  _MMIO((base) + 0x94)
- #define RING_IMR(base)_MMIO((base) + 0xa8)
- #define RING_HWSTAM(base) _MMIO((base) + 0x98)
- #define RING_TIMESTAMP(base)  _MMIO((base) + 0x358)
- #define RING_TIMESTAMP_UDW(base)  _MMIO((base) + 0x358 + 4)
- #define   TAIL_ADDR   0x0018
- #define   HEAD_WRAP_COUNT 0xFFE0
- #define   HEAD_WRAP_ONE   0x0020
- #define   HEAD_ADDR   0x001C
- #define   RING_NR_PAGES   0x001FF000
- #define   RING_REPORT_MASK0x0006
- #define   RING_REPORT_64K 0x0002
- #define   RING_REPORT_128K0x0004
- #define   RING_NO_REPORT  0x
- #define   RING_VALID_MASK 0x0001
- #define   RING_VALID  0x0001
- #define   RING_INVALID0x
- #define   RING_WAIT_I8XX  (1 << 0) /* gen2, PRBx_HEAD */
- #define   RING_WAIT   (1 << 11) /* gen3+, PRBx_CTL */
- #define   RING_WAIT_SEMAPHORE (1 << 10) /* gen6+ */
  
 +#define GUCPMTIMESTAMP  _MMIO(0xC3E8)
 +
- /* There are 16 64-bit CS General Purpose Registers per-engine on Gen8+ */
- #define GEN8_RING_CS_GPR(base, n) _MMIO((base) + 0x600 + (n) * 8)
- #define GEN8_RING_CS_GPR_UDW(base, n) _MMIO((base) + 0x600 + (n) * 8 + 4)
- 
- #define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 4)
- #define   RING_FORCE_TO_NONPRIV_ADDRESS_MASK  REG_GENMASK(25, 2)
- #define   RING_FORCE_TO_NONPRIV_ACCESS_RW (0 << 28)/* CFL+ & Gen11+ */
- #define   RING_FORCE_TO_NONPRIV_ACCESS_RD (1 << 28)
- #define   RING_FORCE_TO_NONPRIV_ACCESS_WR (2 << 28)
- #define   RING_FORCE_TO_NONPRIV_ACCESS_INVALID(3 << 28)
- #define   RING_FORCE_TO_NONPRIV_ACCESS_MASK   (3 << 28)
- #define   RING_FORCE_TO_NONPRIV_RANGE_1   (0 << 0) /* CFL+ & 
Gen11+ */
- #define   RING_FORCE_TO_NONPRIV_RANGE_4   (1 << 0)
- #define   RING_FORCE_TO_NONPRIV_RANGE_16  (2 << 0)
- #define   RING_FORCE_TO_NONPRIV_RANGE_64  (3 << 0)
- #define   RING_FORCE_TO_NONPRIV_RANGE_MASK(3 << 0)
- #define   RING_FORCE_TO_NONPRIV_MASK_VALID\
-   (RING_FORCE_TO_NONPRIV_RANGE_MASK \
-   | RING_FORCE_TO_NONPRIV_ACCESS_MASK)
- #define   RING_MAX_NONPRIV_SLOTS  12
- 
  #define GEN7_TLB_RD_ADDR  _MMIO(0x4700)
  
  #define GEN9_GAMT_ECO_REG_RW_IA _MMIO(0x4ab0)
@@@ -2778,27 -1885,7 +1905,10 @@@
  #define GEN2_INSTDONE _MMIO(0x2090)
  #define NOPID _MMIO(0x2094)
  #define HWSTAM_MMIO(0x2098)
- #define DMA_FADD_I8XX(base)   _MMIO((base) + 0xd0)
- #define RING_BBSTATE(base)_MMIO((base) + 0x110)
- #define   RING_BB_PPGTT   (1 << 5)
- #define RING_SBBADDR(base)_MMIO((base) + 0x114) /* hsw+ */
- #define RING_SBBSTATE(base)   _MMIO((base) + 0x118) /* hsw+ */
- #define RING_SBBADDR_UDW(base)_MMIO((base) + 0x11c) /* gen8+ */
- #define RING_BBADDR(base) _MMIO((base) + 0x140)
- #define RING_BBADDR_UDW(base) _MMIO((base) + 0x168) /* gen8+ */
- #define RING_BB_PER_CTX_PTR(base) _MMIO((base) + 0x1c0) /* gen8+ */
- #define RING_INDIRECT_CTX(base)   _MMIO((base) + 0x1c4) /* gen8+ 
*/
- #define RING_INDIRECT_CTX_OFFSET(base)_MMIO((base) + 0x1c8) /* gen8+ 
*/
- #define RING_CTX_TIMESTAMP(base)  _MMIO((base) + 0x3a8) /* gen8+ */
- 
- #define VDBOX_CGCTL3F10(base) _MMIO((base) + 0x3f10)
- #define   IECPUNIT_CLKGATE_DISREG_BIT(22)
  
 +#define VDBOX_CGCTL3F18(base) _MMIO((base) + 0x3f18)
 +#define   ALNUNIT_CLKGATE_DIS REG_BIT(13)
 +
  #define ERROR_GEN6_MMIO(0x40a0)
  #define GEN7_ERR_INT  _MMIO(0x44040)
  #define   ERR_INT_POISON  (1 << 31)


pgp73XNiO02MY.pgp
Description: 

Re: [PATCH v2 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon

[Daniel Vetter]

On Mon, Jan 24, 2022 at 10:03:17PM +0100, Helge Deller wrote:
> This series reverts two patches which disabled scrolling acceleration in
> fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic
> cards because of the performance penalty by doing screen scrolling by software
> instead of using existing 2D hardware acceleration.
> 
> This series has been discussed on linux-fbdev, dri-devel and linux-kernel
> mailing lists. The consensus is that they will be reverted, but in addition
> it's being worked on to find a solution which allows to disable parts of the
> classic fbdev hardware acceleration code which isn't needed in DRM-only
> configurations.

That's not my take at least.

> The patchset is planned to be kept in fbdev's for-next git branch and later
> pushed into kernel v5.18 if no issues are found until then.

Neither this. I don't think we've resovled maintainership of fbdev core
code and fbcon yet. That is the part that drm folks very much still
maintained, as a quick git shortlog will show.

Maintaining these parts outside of drm trees just doesn't make sense,
since none of the other graphics relevant development happens outside of
drm.
-Daniel

> 
> Helge
> 
> ---
> Changes in v2 compared to v1:
> - adjusted the stable tags (one v5.10+, the other v5.16+)
> - moved the analysis and reasoning why those should be reverted into
>   the commit message. That simplifies to analyze later why they were
>   reverted.
> - resorted the To an Cc mail recipient lists
> 
> Helge Deller (2):
>   Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1
> (from TODO list)"
>   Revert "fbcon: Disable accelerated scrolling"
> 
>  Documentation/gpu/todo.rst  |  24 --
>  drivers/video/fbdev/core/bitblit.c  |  16 +
>  drivers/video/fbdev/core/fbcon.c| 540 +++-
>  drivers/video/fbdev/core/fbcon.h|  59 +++
>  drivers/video/fbdev/core/fbcon_ccw.c|  28 +-
>  drivers/video/fbdev/core/fbcon_cw.c |  28 +-
>  drivers/video/fbdev/core/fbcon_rotate.h |   9 +
>  drivers/video/fbdev/core/fbcon_ud.c |  37 +-
>  drivers/video/fbdev/core/tileblit.c |  16 +
>  drivers/video/fbdev/skeletonfb.c|  12 +-
>  include/linux/fb.h  |   2 +-
>  11 files changed, 703 insertions(+), 68 deletions(-)
> 
> -- 
> 2.31.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/docs: Document where the C8 color lut is stored

[Alex Deucher]

On Mon, Jan 24, 2022 at 5:16 PM Daniel Vetter  wrote:
>
> Also add notes that for atomic drivers it's really somewhere else and
> no longer in struct drm_crtc.
>
> Maybe we should put a bigger warning here that this is confusing,
> since the pixel format is a plane property, but the GAMMA_LUT property
> is on the crtc. But I think we can fix this if/when someone finds a
> need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
> also not sure whether even hardware with a CLUT and a full color
> correction pipeline with degamm/cgm/gamma exists.
>
> Motivated by comments from Geert that we have a gap here.
>
> v2: More names for color luts (Laurent).
>
> Cc: Laurent Pinchart 
> Reviewed-by: Laurent Pinchart 
> Cc: Geert Uytterhoeven 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_color_mgmt.c |  4 
>  include/drm/drm_crtc.h   | 10 ++
>  2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index bb14f488c8f6..9079fbe21d2f 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -82,6 +82,10 @@
>   * driver boot-up state too. Drivers can access this blob through
>   * _crtc_state.gamma_lut.
>   *
> + * Note that for mostly historical reasons stemming from Xorg heritage,
> + * this is also used to store the color map (also sometimes color lut, 
> CLUT
> + * or color palette) for indexed formats like DRM_FORMAT_C8.
> + *
>   * “GAMMA_LUT_SIZE”:
>   * Unsigned range property to give the size of the lookup table to be set
>   * on the GAMMA_LUT property (the size depends on the underlying 
> hardware).
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4d01b4d89775..a70baea0636c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -285,6 +285,10 @@ struct drm_crtc_state {
>  * Lookup table for converting pixel data after the color conversion
>  * matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
>  * NULL) is an array of  drm_color_lut.
> +*
> +* Note that for mostly historical reasons stemming from Xorg 
> heritage,
> +* this is also used to store the color map (also sometimes color lut,
> +* CLUT or color palette) for indexed formats like DRM_FORMAT_C8.
>  */
> struct drm_property_blob *gamma_lut;
>
> @@ -1075,12 +1079,18 @@ struct drm_crtc {
> /**
>  * @gamma_size: Size of legacy gamma ramp reported to userspace. Set 
> up
>  * by calling drm_mode_crtc_set_gamma_size().
> +*
> +* Note that atomic drivers need to instead use
> +* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
>  */
> uint32_t gamma_size;
>
> /**
>  * @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
>  * GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
> +*
> +* Note that atomic drivers need to instead use
> +* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
>  */
> uint16_t *gamma_store;
>
> --
> 2.33.0
>

[PATCH] drm/docs: Document where the C8 color lut is stored

[Daniel Vetter]

Also add notes that for atomic drivers it's really somewhere else and
no longer in struct drm_crtc.

Maybe we should put a bigger warning here that this is confusing,
since the pixel format is a plane property, but the GAMMA_LUT property
is on the crtc. But I think we can fix this if/when someone finds a
need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
also not sure whether even hardware with a CLUT and a full color
correction pipeline with degamm/cgm/gamma exists.

Motivated by comments from Geert that we have a gap here.

v2: More names for color luts (Laurent).

Cc: Laurent Pinchart 
Reviewed-by: Laurent Pinchart 
Cc: Geert Uytterhoeven 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_color_mgmt.c |  4 
 include/drm/drm_crtc.h   | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..9079fbe21d2f 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -82,6 +82,10 @@
  * driver boot-up state too. Drivers can access this blob through
  * _crtc_state.gamma_lut.
  *
+ * Note that for mostly historical reasons stemming from Xorg heritage,
+ * this is also used to store the color map (also sometimes color lut, CLUT
+ * or color palette) for indexed formats like DRM_FORMAT_C8.
+ *
  * “GAMMA_LUT_SIZE”:
  * Unsigned range property to give the size of the lookup table to be set
  * on the GAMMA_LUT property (the size depends on the underlying hardware).
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4d01b4d89775..a70baea0636c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -285,6 +285,10 @@ struct drm_crtc_state {
 * Lookup table for converting pixel data after the color conversion
 * matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
 * NULL) is an array of  drm_color_lut.
+*
+* Note that for mostly historical reasons stemming from Xorg heritage,
+* this is also used to store the color map (also sometimes color lut,
+* CLUT or color palette) for indexed formats like DRM_FORMAT_C8.
 */
struct drm_property_blob *gamma_lut;
 
@@ -1075,12 +1079,18 @@ struct drm_crtc {
/**
 * @gamma_size: Size of legacy gamma ramp reported to userspace. Set up
 * by calling drm_mode_crtc_set_gamma_size().
+*
+* Note that atomic drivers need to instead use
+* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
 */
uint32_t gamma_size;
 
/**
 * @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
 * GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
+*
+* Note that atomic drivers need to instead use
+* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
 */
uint16_t *gamma_store;
 
-- 
2.33.0

Re: [PATCH -next] drm/amd/display: don't use /** for non-kernel-doc comments

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jan 24, 2022 at 10:25 AM Harry Wentland  wrote:
>
> On 2022-01-21 20:23, Randy Dunlap wrote:
> > Change a static function's comment from "/**" (indicating kernel-doc
> > notation) to "/*" (indicating a regular C language comment).
> > This prevents multiple kernel-doc warnings:
> >
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: 
> > Function parameter or member 'max_supported_frl_bw_in_kbps' not described 
> > in 'intersect_frl_link_bw_support'
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: 
> > Function parameter or member 'hdmi_encoded_link_bw' not described in 
> > 'intersect_frl_link_bw_support'
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning: 
> > expecting prototype for Return PCON's post FRL link training supported BW 
> > if its non(). Prototype was for intersect_frl_link_bw_support() instead
> >
> > Fixes: c022375ae095 ("drm/amd/display: Add DP-HDMI FRL PCON Support in DC")
> > Signed-off-by: Randy Dunlap 
> > Reported-by: kernel test robot 
> > Cc: Fangzhi Zuo 
> > Cc: Alex Deucher 
> > Cc: Nicholas Kazlauskas 
> > Cc: Harry Wentland 
> > Cc: Leo Li 
> > Cc: Rodrigo Siqueira 
> > Cc: amd-...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesktop.org
>
> Reviewed-by: Harry Wentland 
>
> Harry
>
> > ---
> >  drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- 
> > linux-next-20220121.orig/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > +++ linux-next-20220121/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
> > @@ -4970,7 +4970,7 @@ uint32_t dc_link_bw_kbps_from_raw_frl_li
> >   return 0;
> >  }
> >
> > -/**
> > +/*
> >   * Return PCON's post FRL link training supported BW if its non-zero, 
> > otherwise return max_supported_frl_bw.
> >   */
> >  static uint32_t intersect_frl_link_bw_support(
>

Re: [PATCH] drm/radeon: remove redundant assignment to reg

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jan 24, 2022 at 3:21 PM Nick Desaulniers
 wrote:
>
> On Wed, Jan 19, 2022 at 2:46 PM Colin Ian King  wrote:
> >
> > The pointer reg is being assigned a value that is not read, the
> > exit path via label 'out' never accesses it. The assignment is
> > redundant and can be removed.
> >
> > Cleans up clang scan build warning:
> > drivers/gpu/drm/radeon/radeon_object.c:570:3: warning: Value
> > stored to 'reg' is never read [deadcode.DeadStores]
> >
> > Signed-off-by: Colin Ian King 
>
> Thanks for the patch!
> Reviewed-by: Nick Desaulniers 
>
> > ---
> >  drivers/gpu/drm/radeon/radeon_object.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
> > b/drivers/gpu/drm/radeon/radeon_object.c
> > index 56ede9d63b12..87536d205593 100644
> > --- a/drivers/gpu/drm/radeon/radeon_object.c
> > +++ b/drivers/gpu/drm/radeon/radeon_object.c
> > @@ -567,7 +567,6 @@ int radeon_bo_get_surface_reg(struct radeon_bo *bo)
> > return 0;
> >
> > if (bo->surface_reg >= 0) {
> > -   reg = >surface_regs[bo->surface_reg];
> > i = bo->surface_reg;
> > goto out;
> > }
> > --
> > 2.33.1
> >
> >
>
>
> --
> Thanks,
> ~Nick Desaulniers

Re: [PATCH v2] drm/amd/pm: return -ENOTSUPP if there is no get_dpm_ultimate_freq function

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jan 24, 2022 at 3:18 PM  wrote:
>
> From: Tom Rix 
>
> clang static analysis reports this represenative problem
> amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
> return clk_freq * 100;
> ^
>
> If there is no get_dpm_ultimate_freq function,
> smu_get_dpm_freq_range returns success without setting the
> output min,max parameters.  So return an -ENOTSUPP error.
>
> Fixes: e5ef784b1e17 ("drm/amd/powerplay: revise calling chain on retrieving 
> frequency range")
> Signed-off-by: Tom Rix 
> ---
> v2: return error instead of initializing min/max
>
> drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
> b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> index 5ace30434e603..264eb09ccfd51 100644
> --- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> +++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
> @@ -116,7 +116,7 @@ int smu_get_dpm_freq_range(struct smu_context *smu,
>uint32_t *min,
>uint32_t *max)
>  {
> -   int ret = 0;
> +   int ret = -ENOTSUPP;
>
> if (!min && !max)
> return -EINVAL;
> --
> 2.26.3
>

Re: [PATCH] drm/msm/dp: always add fail-safe mode into connector mode list

[Stephen Boyd]

Quoting Kuogee Hsieh (2022-01-24 13:24:25)
>
> On 1/24/2022 1:04 PM, Stephen Boyd wrote:
> > Quoting Kuogee Hsieh (2022-01-24 12:46:10)
> >> Some of DP link compliant test expects to return fail-safe mode
> >> if prefer detailed timing mode can not be supported by mainlink's
> >> lane and rate after link training. Therefore add fail-safe mode
> >> into connector mode list as backup mode. This patch fixes test
> >> case 4.2.2.1.
> >>
> >> Signed-off-by: Kuogee Hsieh 
> > Any Fixes tag? I also wonder why this isn't pushed into the DP core code
> > somehow. Wouldn't every device need to add a 640x480 mode by default?
>
> Original test case 4.2.2.1 always passed until we did firmware upgrade
> of our compliance test tester (Unigraph) recently.

Ok. So the Fixes tag should be the introduction of the driver or at
least whenever compliance testing support was added.

>
> The new firmware of tester use newer edid contains 1080p with 145.7 mhz
> which can not be supported by 2 lanes with 1.6G rate. Hence we failed
> this test case.

Interesting. So the test case wouldn't fail unless the number of lanes
were limited by the hardware? Seems that the test isn't thorough.

>
> After discuss with Vendor, they claims we have to return fail-safe mode
> if prefer detailed timing mode can not be supported.
>
> I think would be good to add fail-safe mode into connector mode list.
>
>
>
>
> > we just run into this problem recently.


Sure I'm not saying it's incorrect, just wondering why a connector
that's DP wouldn't have the 640x480 resolution by default somewhere in
the drm core.

Re: [PATCH] drm/msm/dp: always add fail-safe mode into connector mode list

[Kuogee Hsieh]

On 1/24/2022 1:04 PM, Stephen Boyd wrote:

Quoting Kuogee Hsieh (2022-01-24 12:46:10)

Some of DP link compliant test expects to return fail-safe mode
if prefer detailed timing mode can not be supported by mainlink's
lane and rate after link training. Therefore add fail-safe mode
into connector mode list as backup mode. This patch fixes test
case 4.2.2.1.

Signed-off-by: Kuogee Hsieh 

Any Fixes tag? I also wonder why this isn't pushed into the DP core code
somehow. Wouldn't every device need to add a 640x480 mode by default?


Original test case 4.2.2.1 always passed until we did firmware upgrade 
of our compliance test tester (Unigraph) recently.


The new firmware of tester use newer edid contains 1080p with 145.7 mhz 
which can not be supported by 2 lanes with 1.6G rate. Hence we failed 
this test case.


After discuss with Vendor, they claims we have to return fail-safe mode 
if prefer detailed timing mode can not be supported.


I think would be good to add fail-safe mode into connector mode list.





we just run into this problem recently.

---
  drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 3b02922..7743b45 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -221,6 +221,11 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
 if (drm_add_modes_noedid(connector, 640, 480))
 drm_set_preferred_mode(connector, 640, 480);
 mutex_unlock(>dev->mode_config.mutex);
+   } else {
+   /* always add fail-safe mode as backup mode */
+   mutex_lock(>dev->mode_config.mutex);
+   drm_add_modes_noedid(connector, 640, 480);
+   mutex_unlock(>dev->mode_config.mutex);
 }

 if (panel->aux_cfg_update_done) {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 5.16 0299/1039] drm/tegra: vic: Fix DMA API misuse

[Greg Kroah-Hartman]

From: Robin Murphy 

[ Upstream commit 5566174cb10a5167d59b0793871cab7990b149b8 ]

Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.

Also include the correct header, because the fragile transitive
inclusion currently providing it is going to break soon.

Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding 
CC: Mikko Perttunen 
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/tegra/vic.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index c02010ff2b7f2..da4af53719917 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -232,10 +233,8 @@ static int vic_load_firmware(struct vic *vic)
 
if (!client->group) {
virt = dma_alloc_coherent(vic->dev, size, , GFP_KERNEL);
-
-   err = dma_mapping_error(vic->dev, iova);
-   if (err < 0)
-   return err;
+   if (!virt)
+   return -ENOMEM;
} else {
virt = tegra_drm_alloc(tegra, size, );
}
-- 
2.34.1

[PATCH v2 1/2] Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)"

[Helge Deller]

This reverts commit b3ec8cdf457e5e63d396fe1346cc788cf7c1b578.

Revert the second (of 2) commits which disabled scrolling acceleration
in fbcon/fbdev.  It introduced a regression for fbdev-supported graphic
cards because of the performance penalty by doing screen scrolling by
software instead of using the existing graphic card 2D hardware
acceleration.

Console scrolling acceleration was disabled by dropping code which
checked at runtime the driver hardware capabilities for the
BINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags and if set, it
enabled scrollmode SCROLL_MOVE which uses hardware acceleration to move
screen contents.  After dropping those checks scrollmode was hard-wired
to SCROLL_REDRAW instead, which forces all graphic cards to redraw every
character at the new screen position when scrolling.

This change effectively disabled all hardware-based scrolling acceleration for
ALL drivers, because now all kind of 2D hardware acceleration (bitblt,
fillrect) in the drivers isn't used any longer.

The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm
and gma500) used hardware acceleration in the past and thus code for checking
and using scrolling acceleration is obsolete.

This statement is NOT TRUE, because beside the DRM drivers there are around 35
other fbdev drivers which depend on fbdev/fbcon and still provide hardware
acceleration for fbdev/fbcon.

The original commit message also states that syzbot found lots of bugs in fbcon
and thus it's "often the solution to just delete code and remove features".
This is true, and the bugs - which actually affected all users of fbcon,
including DRM - were fixed, or code was dropped like e.g. the support for
software scrollback in vgacon (commit 973c096f6a85).

So to further analyze which bugs were found by syzbot, I've looked through all
patches in drivers/video which were tagged with syzbot or syzkaller back to
year 2005. The vast majority fixed the reported issues on a higher level, e.g.
when screen is to be resized, or when font size is to be changed. The few ones
which touched driver code fixed a real driver bug, e.g. by adding a check.

But NONE of those patches touched code of either the SCROLL_MOVE or the
SCROLL_REDRAW case.

That means, there was no real reason why SCROLL_MOVE had to be ripped-out and
just SCROLL_REDRAW had to be used instead. The only reason I can imagine so far
was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it
could go away. That argument completely missed the fact that SCROLL_MOVE is
still heavily used by fbdev (non-DRM) drivers.

Some people mention that using memcpy() instead of the hardware acceleration is
pretty much the same speed. But that's not true, at least not for older graphic
cards and machines where we see speed decreases by factor 10 and more and thus
this change leads to console responsiveness way worse than before.

That's why the original commit is to be reverted. By reverting we
reintroduce hardware-based scrolling acceleration and fix the
performance regression for fbdev drivers.

There isn't any impact on DRM when reverting those patches.

Signed-off-by: Helge Deller 
Cc: sta...@vger.kernel.org # v5.16+
---
 Documentation/gpu/todo.rst  |  13 +-
 drivers/video/fbdev/core/bitblit.c  |  16 +
 drivers/video/fbdev/core/fbcon.c| 509 +++-
 drivers/video/fbdev/core/fbcon.h|  59 +++
 drivers/video/fbdev/core/fbcon_ccw.c|  28 +-
 drivers/video/fbdev/core/fbcon_cw.c |  28 +-
 drivers/video/fbdev/core/fbcon_rotate.h |   9 +
 drivers/video/fbdev/core/fbcon_ud.c |  37 +-
 drivers/video/fbdev/core/tileblit.c |  16 +
 drivers/video/fbdev/skeletonfb.c|  12 +-
 include/linux/fb.h  |   2 +-
 11 files changed, 678 insertions(+), 51 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index da138dd39883..29506815d24a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -303,19 +303,16 @@ Level: Advanced
 Garbage collect fbdev scrolling acceleration
 

-Scroll acceleration has been disabled in fbcon. Now it works as the old
-SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
-removed from fbcon_ops.
-Remaining tasks:
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:

-- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
+- lots of code in fbcon.c
+
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
   directly instead of the function table (with a switch on p->rotate)

 - fb_copyarea is unused after this, and can be deleted from all drivers

-- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
-  well as cfb_copyarea
-
 Note that not all acceleration code can be deleted, since clearing and 

[PATCH v2 2/2] Revert "fbcon: Disable accelerated scrolling"

[Helge Deller]

This reverts commit 39aead8373b3c20bb5965c024dfb51a94e526151.

Revert the first (of 2) commits which disabled scrolling acceleration in
fbcon/fbdev.  It introduced a regression for fbdev-supported graphic cards
because of the performance penalty by doing screen scrolling by software
instead of using the existing graphic card 2D hardware acceleration.

Console scrolling acceleration was disabled by dropping code which
checked at runtime the driver hardware capabilities for the
BINFO_HWACCEL_COPYAREA or FBINFO_HWACCEL_FILLRECT flags and if set, it
enabled scrollmode SCROLL_MOVE which uses hardware acceleration to move
screen contents.  After dropping those checks scrollmode was hard-wired
to SCROLL_REDRAW instead, which forces all graphic cards to redraw every
character at the new screen position when scrolling.

This change effectively disabled all hardware-based scrolling acceleration for
ALL drivers, because now all kind of 2D hardware acceleration (bitblt,
fillrect) in the drivers isn't used any longer.

The original commit message mentions that only 3 DRM drivers (nouveau, omapdrm
and gma500) used hardware acceleration in the past and thus code for checking
and using scrolling acceleration is obsolete.

This statement is NOT TRUE, because beside the DRM drivers there are around 35
other fbdev drivers which depend on fbdev/fbcon and still provide hardware
acceleration for fbdev/fbcon.

The original commit message also states that syzbot found lots of bugs in fbcon
and thus it's "often the solution to just delete code and remove features".
This is true, and the bugs - which actually affected all users of fbcon,
including DRM - were fixed, or code was dropped like e.g. the support for
software scrollback in vgacon (commit 973c096f6a85).

So to further analyze which bugs were found by syzbot, I've looked through all
patches in drivers/video which were tagged with syzbot or syzkaller back to
year 2005. The vast majority fixed the reported issues on a higher level, e.g.
when screen is to be resized, or when font size is to be changed. The few ones
which touched driver code fixed a real driver bug, e.g. by adding a check.

But NONE of those patches touched code of either the SCROLL_MOVE or the
SCROLL_REDRAW case.

That means, there was no real reason why SCROLL_MOVE had to be ripped-out and
just SCROLL_REDRAW had to be used instead. The only reason I can imagine so far
was that SCROLL_MOVE wasn't used by DRM and as such it was assumed that it
could go away. That argument completely missed the fact that SCROLL_MOVE is
still heavily used by fbdev (non-DRM) drivers.

Some people mention that using memcpy() instead of the hardware acceleration is
pretty much the same speed. But that's not true, at least not for older graphic
cards and machines where we see speed decreases by factor 10 and more and thus
this change leads to console responsiveness way worse than before.

That's why the original commit is to be reverted. By reverting we
reintroduce hardware-based scrolling acceleration and fix the
performance regression for fbdev drivers.

There isn't any impact on DRM when reverting those patches.

Signed-off-by: Helge Deller 
Cc: sta...@vger.kernel.org # v5.10+
---
 Documentation/gpu/todo.rst   | 21 ---
 drivers/video/fbdev/core/fbcon.c | 45 ++--
 2 files changed, 37 insertions(+), 29 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 29506815d24a..a1212b5b3026 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -300,27 +300,6 @@ Contact: Daniel Vetter, Noralf Tronnes

 Level: Advanced

-Garbage collect fbdev scrolling acceleration
-
-
-Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
-SCROLL_REDRAW. There's a ton of code this will allow us to remove:
-
-- lots of code in fbcon.c
-
-- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
-  directly instead of the function table (with a switch on p->rotate)
-
-- fb_copyarea is unused after this, and can be deleted from all drivers
-
-Note that not all acceleration code can be deleted, since clearing and cursor
-support is still accelerated, which might be good candidates for further
-deletion projects.
-
-Contact: Daniel Vetter
-
-Level: Intermediate
-
 idr_init_base()
 ---

diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 22bb3892f6bd..b813985f1403 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1025,7 +1025,7 @@ static void fbcon_init(struct vc_data *vc, int init)
struct vc_data *svc = *default_mode;
struct fbcon_display *t, *p = _display[vc->vc_num];
int logo = 1, new_rows, new_cols, rows, cols;
-   int ret;
+   int cap, ret;

if (WARN_ON(info_idx == -1))
return;
@@ -1034,6 +1034,7 @@ static void fbcon_init(struct vc_data *vc, 

[PATCH v2 0/2] Fix regression introduced by disabling accelerated scrolling in fbcon

[Helge Deller]

This series reverts two patches which disabled scrolling acceleration in
fbcon/fbdev. Those patches introduced a regression for fbdev-supported graphic
cards because of the performance penalty by doing screen scrolling by software
instead of using existing 2D hardware acceleration.

This series has been discussed on linux-fbdev, dri-devel and linux-kernel
mailing lists. The consensus is that they will be reverted, but in addition
it's being worked on to find a solution which allows to disable parts of the
classic fbdev hardware acceleration code which isn't needed in DRM-only
configurations.

The patchset is planned to be kept in fbdev's for-next git branch and later
pushed into kernel v5.18 if no issues are found until then.

Helge

---
Changes in v2 compared to v1:
- adjusted the stable tags (one v5.10+, the other v5.16+)
- moved the analysis and reasoning why those should be reverted into
  the commit message. That simplifies to analyze later why they were
  reverted.
- resorted the To an Cc mail recipient lists

Helge Deller (2):
  Revert "fbdev: Garbage collect fbdev scrolling acceleration, part 1
(from TODO list)"
  Revert "fbcon: Disable accelerated scrolling"

 Documentation/gpu/todo.rst  |  24 --
 drivers/video/fbdev/core/bitblit.c  |  16 +
 drivers/video/fbdev/core/fbcon.c| 540 +++-
 drivers/video/fbdev/core/fbcon.h|  59 +++
 drivers/video/fbdev/core/fbcon_ccw.c|  28 +-
 drivers/video/fbdev/core/fbcon_cw.c |  28 +-
 drivers/video/fbdev/core/fbcon_rotate.h |   9 +
 drivers/video/fbdev/core/fbcon_ud.c |  37 +-
 drivers/video/fbdev/core/tileblit.c |  16 +
 drivers/video/fbdev/skeletonfb.c|  12 +-
 include/linux/fb.h  |   2 +-
 11 files changed, 703 insertions(+), 68 deletions(-)

-- 
2.31.1

Re: [PATCH] drm/msm/dp: always add fail-safe mode into connector mode list

[Stephen Boyd]

Quoting Kuogee Hsieh (2022-01-24 12:46:10)
> Some of DP link compliant test expects to return fail-safe mode
> if prefer detailed timing mode can not be supported by mainlink's
> lane and rate after link training. Therefore add fail-safe mode
> into connector mode list as backup mode. This patch fixes test
> case 4.2.2.1.
>
> Signed-off-by: Kuogee Hsieh 

Any Fixes tag? I also wonder why this isn't pushed into the DP core code
somehow. Wouldn't every device need to add a 640x480 mode by default?

> ---
>  drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
> b/drivers/gpu/drm/msm/dp/dp_panel.c
> index 3b02922..7743b45 100644
> --- a/drivers/gpu/drm/msm/dp/dp_panel.c
> +++ b/drivers/gpu/drm/msm/dp/dp_panel.c
> @@ -221,6 +221,11 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
> if (drm_add_modes_noedid(connector, 640, 480))
> drm_set_preferred_mode(connector, 640, 480);
> mutex_unlock(>dev->mode_config.mutex);
> +   } else {
> +   /* always add fail-safe mode as backup mode */
> +   mutex_lock(>dev->mode_config.mutex);
> +   drm_add_modes_noedid(connector, 640, 480);
> +   mutex_unlock(>dev->mode_config.mutex);
> }
>
> if (panel->aux_cfg_update_done) {
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>

[PATCH 5.16 0073/1039] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

[Greg Kroah-Hartman]

From: Thomas Hellström 

commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream.

If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.

Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().

v2:
- Update Cc list, and add R-b.

Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container")
Cc: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Christian König 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:  # v5.4+
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma-buf/dma-fence-array.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str
 {
struct dma_fence_array *array = to_dma_fence_array(fence);
 
-   return atomic_read(>num_pending) <= 0;
+   if (atomic_read(>num_pending) > 0)
+   return false;
+
+   dma_fence_array_clear_pending_error(array);
+   return true;
 }
 
 static void dma_fence_array_release(struct dma_fence *fence)

Re: [PATCH] drm/docs: Document where the C8 color lut is stored

[Daniel Vetter]

On Mon, Jan 24, 2022 at 9:41 PM Laurent Pinchart
 wrote:
>
> Hi Daniel,
>
> On Mon, Jan 24, 2022 at 09:28:09PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 24, 2022 at 9:24 PM Laurent Pinchart wrote:
> > > On Mon, Jan 24, 2022 at 08:47:06PM +0100, Daniel Vetter wrote:
> > > > Also add notes that for atomic drivers it's really somewhere else and
> > > > no longer in struct drm_crtc.
> > > >
> > > > Maybe we should put a bigger warning here that this is confusing,
> > > > since the pixel format is a plane property, but the GAMMA_LUT property
> > > > is on the crtc. But I think we can fix this if/when someone finds a
> > > > need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
> > > > also not sure whether even hardware with a CLUT and a full color
> > > > correction pipeline with degamm/cgm/gamma exists.
> > >
> > > Exists, maybe, exists and has a real use case, I'd be surprised.
> > >
> > > > Motivated by comments from Geert that we have a gap here.
> > > >
> > > > Cc: Geert Uytterhoeven 
> > > > Cc: Ville Syrjälä 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Maxime Ripard 
> > > > Cc: Thomas Zimmermann 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/drm_color_mgmt.c |  4 
> > > >  include/drm/drm_crtc.h   | 10 ++
> > > >  2 files changed, 14 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> > > > b/drivers/gpu/drm/drm_color_mgmt.c
> > > > index bb14f488c8f6..96ce57ad37e6 100644
> > > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > > @@ -82,6 +82,10 @@
> > > >   *   driver boot-up state too. Drivers can access this blob through
> > > >   *   _crtc_state.gamma_lut.
> > > >   *
> > > > + *   Note that for mostly historical reasons stemming from Xorg 
> > > > heritage,
> > > > + *   this is also used to store the color lookup table (CLUT) for 
> > > > indexed
> > > > + *   formats like DRM_FORMAT_C8.
> > >
> > > CLUT also stands for Cubic Look Up Table, a type of LUT commonly used
> > > for tone mapping that maps an RGB sample (in 3D space) to a colour.
> > > Compared to traditional LUTs such as gamma and degamma, it allows
> > > correlating colour components, while the gamma and degamma LUTs operate
> > > on each colour component independently.
> > >
> > > Is there any commonly used acronym for the indexed colours lookup table
> > > that we could use here, to avoid future confusions ?
> >
> > Hm intel calls these 3DLUT, so for me there's not confusion here :-)
> > But also since random acronyms are bad I put both the acronym and the
> > full spelling into the text.
> >
> > The cubic lut for me sounds more like cubic filtering from texture
> > units (yet another thing). Do you want me to just drop the CLUT (I
> > figured some people might search for that in the docs, and there's
> > really no other way find this) or ok this way? I don't really have a
> > better idea.
>
> fbdev uses "color map", "color palette" seems to also be a common term.
> Maybe use one of those two ?

Sounds good, I'll just add them all in parathesis. The more the better
the chance people find this.
-Daniel

>
> > > Other than that,
> > >
> > > Reviewed-by: Laurent Pinchart 
> > >
> > > > + *
> > > >   * “GAMMA_LUT_SIZE”:
> > > >   *   Unsigned range property to give the size of the lookup table to 
> > > > be set
> > > >   *   on the GAMMA_LUT property (the size depends on the underlying 
> > > > hardware).
> > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > > index 4d01b4d89775..03cc53220a2a 100644
> > > > --- a/include/drm/drm_crtc.h
> > > > +++ b/include/drm/drm_crtc.h
> > > > @@ -285,6 +285,10 @@ struct drm_crtc_state {
> > > >* Lookup table for converting pixel data after the color 
> > > > conversion
> > > >* matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if 
> > > > not
> > > >* NULL) is an array of  drm_color_lut.
> > > > +  *
> > > > +  * Note that for mostly historical reasons stemming from Xorg 
> > > > heritage,
> > > > +  * this is also used to store the color lookup table (CLUT) for 
> > > > indexed
> > > > +  * formats like DRM_FORMAT_C8.
> > > >*/
> > > >   struct drm_property_blob *gamma_lut;
> > > >
> > > > @@ -1075,12 +1079,18 @@ struct drm_crtc {
> > > >   /**
> > > >* @gamma_size: Size of legacy gamma ramp reported to userspace. 
> > > > Set up
> > > >* by calling drm_mode_crtc_set_gamma_size().
> > > > +  *
> > > > +  * Note that atomic drivers need to instead use
> > > > +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
> > > >*/
> > > >   uint32_t gamma_size;
> > > >
> > > >   /**
> > > >* @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
> > > >* GETGAMMA IOCTls. Set up by calling 
> > > > drm_mode_crtc_set_gamma_size().
> > > > +  *
> > > > +  

[PATCH] drm/msm/dp: always add fail-safe mode into connector mode list

[Kuogee Hsieh]

Some of DP link compliant test expects to return fail-safe mode
if prefer detailed timing mode can not be supported by mainlink's
lane and rate after link training. Therefore add fail-safe mode
into connector mode list as backup mode. This patch fixes test
case 4.2.2.1.

Signed-off-by: Kuogee Hsieh 
---
 drivers/gpu/drm/msm/dp/dp_panel.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 3b02922..7743b45 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -221,6 +221,11 @@ int dp_panel_read_sink_caps(struct dp_panel *dp_panel,
if (drm_add_modes_noedid(connector, 640, 480))
drm_set_preferred_mode(connector, 640, 480);
mutex_unlock(>dev->mode_config.mutex);
+   } else {
+   /* always add fail-safe mode as backup mode */
+   mutex_lock(>dev->mode_config.mutex);
+   drm_add_modes_noedid(connector, 640, 480);
+   mutex_unlock(>dev->mode_config.mutex);
}
 
if (panel->aux_cfg_update_done) {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] drm/docs: Document where the C8 color lut is stored

[Laurent Pinchart]

Hi Daniel,

On Mon, Jan 24, 2022 at 09:28:09PM +0100, Daniel Vetter wrote:
> On Mon, Jan 24, 2022 at 9:24 PM Laurent Pinchart wrote:
> > On Mon, Jan 24, 2022 at 08:47:06PM +0100, Daniel Vetter wrote:
> > > Also add notes that for atomic drivers it's really somewhere else and
> > > no longer in struct drm_crtc.
> > >
> > > Maybe we should put a bigger warning here that this is confusing,
> > > since the pixel format is a plane property, but the GAMMA_LUT property
> > > is on the crtc. But I think we can fix this if/when someone finds a
> > > need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
> > > also not sure whether even hardware with a CLUT and a full color
> > > correction pipeline with degamm/cgm/gamma exists.
> >
> > Exists, maybe, exists and has a real use case, I'd be surprised.
> >
> > > Motivated by comments from Geert that we have a gap here.
> > >
> > > Cc: Geert Uytterhoeven 
> > > Cc: Ville Syrjälä 
> > > Cc: Maarten Lankhorst 
> > > Cc: Maxime Ripard 
> > > Cc: Thomas Zimmermann 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Daniel Vetter 
> > > ---
> > >  drivers/gpu/drm/drm_color_mgmt.c |  4 
> > >  include/drm/drm_crtc.h   | 10 ++
> > >  2 files changed, 14 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> > > b/drivers/gpu/drm/drm_color_mgmt.c
> > > index bb14f488c8f6..96ce57ad37e6 100644
> > > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > @@ -82,6 +82,10 @@
> > >   *   driver boot-up state too. Drivers can access this blob through
> > >   *   _crtc_state.gamma_lut.
> > >   *
> > > + *   Note that for mostly historical reasons stemming from Xorg heritage,
> > > + *   this is also used to store the color lookup table (CLUT) for indexed
> > > + *   formats like DRM_FORMAT_C8.
> >
> > CLUT also stands for Cubic Look Up Table, a type of LUT commonly used
> > for tone mapping that maps an RGB sample (in 3D space) to a colour.
> > Compared to traditional LUTs such as gamma and degamma, it allows
> > correlating colour components, while the gamma and degamma LUTs operate
> > on each colour component independently.
> >
> > Is there any commonly used acronym for the indexed colours lookup table
> > that we could use here, to avoid future confusions ?
> 
> Hm intel calls these 3DLUT, so for me there's not confusion here :-)
> But also since random acronyms are bad I put both the acronym and the
> full spelling into the text.
> 
> The cubic lut for me sounds more like cubic filtering from texture
> units (yet another thing). Do you want me to just drop the CLUT (I
> figured some people might search for that in the docs, and there's
> really no other way find this) or ok this way? I don't really have a
> better idea.

fbdev uses "color map", "color palette" seems to also be a common term.
Maybe use one of those two ?

> > Other than that,
> >
> > Reviewed-by: Laurent Pinchart 
> >
> > > + *
> > >   * “GAMMA_LUT_SIZE”:
> > >   *   Unsigned range property to give the size of the lookup table to be 
> > > set
> > >   *   on the GAMMA_LUT property (the size depends on the underlying 
> > > hardware).
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > index 4d01b4d89775..03cc53220a2a 100644
> > > --- a/include/drm/drm_crtc.h
> > > +++ b/include/drm/drm_crtc.h
> > > @@ -285,6 +285,10 @@ struct drm_crtc_state {
> > >* Lookup table for converting pixel data after the color conversion
> > >* matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
> > >* NULL) is an array of  drm_color_lut.
> > > +  *
> > > +  * Note that for mostly historical reasons stemming from Xorg 
> > > heritage,
> > > +  * this is also used to store the color lookup table (CLUT) for 
> > > indexed
> > > +  * formats like DRM_FORMAT_C8.
> > >*/
> > >   struct drm_property_blob *gamma_lut;
> > >
> > > @@ -1075,12 +1079,18 @@ struct drm_crtc {
> > >   /**
> > >* @gamma_size: Size of legacy gamma ramp reported to userspace. 
> > > Set up
> > >* by calling drm_mode_crtc_set_gamma_size().
> > > +  *
> > > +  * Note that atomic drivers need to instead use
> > > +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
> > >*/
> > >   uint32_t gamma_size;
> > >
> > >   /**
> > >* @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
> > >* GETGAMMA IOCTls. Set up by calling 
> > > drm_mode_crtc_set_gamma_size().
> > > +  *
> > > +  * Note that atomic drivers need to instead use
> > > +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
> > >*/
> > >   uint16_t *gamma_store;
> > >

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm/docs: Document where the C8 color lut is stored

[Daniel Vetter]

On Mon, Jan 24, 2022 at 9:24 PM Laurent Pinchart
 wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Mon, Jan 24, 2022 at 08:47:06PM +0100, Daniel Vetter wrote:
> > Also add notes that for atomic drivers it's really somewhere else and
> > no longer in struct drm_crtc.
> >
> > Maybe we should put a bigger warning here that this is confusing,
> > since the pixel format is a plane property, but the GAMMA_LUT property
> > is on the crtc. But I think we can fix this if/when someone finds a
> > need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
> > also not sure whether even hardware with a CLUT and a full color
> > correction pipeline with degamm/cgm/gamma exists.
>
> Exists, maybe, exists and has a real use case, I'd be surprised.
>
> > Motivated by comments from Geert that we have a gap here.
> >
> > Cc: Geert Uytterhoeven 
> > Cc: Ville Syrjälä 
> > Cc: Maarten Lankhorst 
> > Cc: Maxime Ripard 
> > Cc: Thomas Zimmermann 
> > Cc: David Airlie 
> > Cc: Daniel Vetter 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/drm_color_mgmt.c |  4 
> >  include/drm/drm_crtc.h   | 10 ++
> >  2 files changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> > b/drivers/gpu/drm/drm_color_mgmt.c
> > index bb14f488c8f6..96ce57ad37e6 100644
> > --- a/drivers/gpu/drm/drm_color_mgmt.c
> > +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > @@ -82,6 +82,10 @@
> >   *   driver boot-up state too. Drivers can access this blob through
> >   *   _crtc_state.gamma_lut.
> >   *
> > + *   Note that for mostly historical reasons stemming from Xorg heritage,
> > + *   this is also used to store the color lookup table (CLUT) for indexed
> > + *   formats like DRM_FORMAT_C8.
>
> CLUT also stands for Cubic Look Up Table, a type of LUT commonly used
> for tone mapping that maps an RGB sample (in 3D space) to a colour.
> Compared to traditional LUTs such as gamma and degamma, it allows
> correlating colour components, while the gamma and degamma LUTs operate
> on each colour component independently.
>
> Is there any commonly used acronym for the indexed colours lookup table
> that we could use here, to avoid future confusions ?

Hm intel calls these 3DLUT, so for me there's not confusion here :-)
But also since random acronyms are bad I put both the acronym and the
full spelling into the text.

The cubic lut for me sounds more like cubic filtering from texture
units (yet another thing). Do you want me to just drop the CLUT (I
figured some people might search for that in the docs, and there's
really no other way find this) or ok this way? I don't really have a
better idea.
-Daniel

>
> Other than that,
>
> Reviewed-by: Laurent Pinchart 
>
> > + *
> >   * “GAMMA_LUT_SIZE”:
> >   *   Unsigned range property to give the size of the lookup table to be set
> >   *   on the GAMMA_LUT property (the size depends on the underlying 
> > hardware).
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 4d01b4d89775..03cc53220a2a 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -285,6 +285,10 @@ struct drm_crtc_state {
> >* Lookup table for converting pixel data after the color conversion
> >* matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
> >* NULL) is an array of  drm_color_lut.
> > +  *
> > +  * Note that for mostly historical reasons stemming from Xorg 
> > heritage,
> > +  * this is also used to store the color lookup table (CLUT) for 
> > indexed
> > +  * formats like DRM_FORMAT_C8.
> >*/
> >   struct drm_property_blob *gamma_lut;
> >
> > @@ -1075,12 +1079,18 @@ struct drm_crtc {
> >   /**
> >* @gamma_size: Size of legacy gamma ramp reported to userspace. Set 
> > up
> >* by calling drm_mode_crtc_set_gamma_size().
> > +  *
> > +  * Note that atomic drivers need to instead use
> > +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
> >*/
> >   uint32_t gamma_size;
> >
> >   /**
> >* @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
> >* GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
> > +  *
> > +  * Note that atomic drivers need to instead use
> > +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
> >*/
> >   uint16_t *gamma_store;
> >
>
> --
> Regards,
>
> Laurent Pinchart



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/docs: Document where the C8 color lut is stored

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Mon, Jan 24, 2022 at 08:47:06PM +0100, Daniel Vetter wrote:
> Also add notes that for atomic drivers it's really somewhere else and
> no longer in struct drm_crtc.
> 
> Maybe we should put a bigger warning here that this is confusing,
> since the pixel format is a plane property, but the GAMMA_LUT property
> is on the crtc. But I think we can fix this if/when someone finds a
> need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
> also not sure whether even hardware with a CLUT and a full color
> correction pipeline with degamm/cgm/gamma exists.

Exists, maybe, exists and has a real use case, I'd be surprised.

> Motivated by comments from Geert that we have a gap here.
> 
> Cc: Geert Uytterhoeven 
> Cc: Ville Syrjälä 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_color_mgmt.c |  4 
>  include/drm/drm_crtc.h   | 10 ++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c 
> b/drivers/gpu/drm/drm_color_mgmt.c
> index bb14f488c8f6..96ce57ad37e6 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -82,6 +82,10 @@
>   *   driver boot-up state too. Drivers can access this blob through
>   *   _crtc_state.gamma_lut.
>   *
> + *   Note that for mostly historical reasons stemming from Xorg heritage,
> + *   this is also used to store the color lookup table (CLUT) for indexed
> + *   formats like DRM_FORMAT_C8.

CLUT also stands for Cubic Look Up Table, a type of LUT commonly used
for tone mapping that maps an RGB sample (in 3D space) to a colour.
Compared to traditional LUTs such as gamma and degamma, it allows
correlating colour components, while the gamma and degamma LUTs operate
on each colour component independently.

Is there any commonly used acronym for the indexed colours lookup table
that we could use here, to avoid future confusions ?

Other than that,

Reviewed-by: Laurent Pinchart 

> + *
>   * “GAMMA_LUT_SIZE”:
>   *   Unsigned range property to give the size of the lookup table to be set
>   *   on the GAMMA_LUT property (the size depends on the underlying hardware).
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 4d01b4d89775..03cc53220a2a 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -285,6 +285,10 @@ struct drm_crtc_state {
>* Lookup table for converting pixel data after the color conversion
>* matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
>* NULL) is an array of  drm_color_lut.
> +  *
> +  * Note that for mostly historical reasons stemming from Xorg heritage,
> +  * this is also used to store the color lookup table (CLUT) for indexed
> +  * formats like DRM_FORMAT_C8.
>*/
>   struct drm_property_blob *gamma_lut;
>  
> @@ -1075,12 +1079,18 @@ struct drm_crtc {
>   /**
>* @gamma_size: Size of legacy gamma ramp reported to userspace. Set up
>* by calling drm_mode_crtc_set_gamma_size().
> +  *
> +  * Note that atomic drivers need to instead use
> +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
>*/
>   uint32_t gamma_size;
>  
>   /**
>* @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
>* GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
> +  *
> +  * Note that atomic drivers need to instead use
> +  * _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
>*/
>   uint16_t *gamma_store;
>  

-- 
Regards,

Laurent Pinchart

[PATCH 5.15 257/846] drm/tegra: vic: Fix DMA API misuse

[Greg Kroah-Hartman]

From: Robin Murphy 

[ Upstream commit 5566174cb10a5167d59b0793871cab7990b149b8 ]

Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.

Also include the correct header, because the fragile transitive
inclusion currently providing it is going to break soon.

Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding 
CC: Mikko Perttunen 
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/tegra/vic.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index c02010ff2b7f2..da4af53719917 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -232,10 +233,8 @@ static int vic_load_firmware(struct vic *vic)
 
if (!client->group) {
virt = dma_alloc_coherent(vic->dev, size, , GFP_KERNEL);
-
-   err = dma_mapping_error(vic->dev, iova);
-   if (err < 0)
-   return err;
+   if (!virt)
+   return -ENOMEM;
} else {
virt = tegra_drm_alloc(tegra, size, );
}
-- 
2.34.1

Re: [Intel-gfx] [PATCH 06/11] dma-buf: warn about containers in dma_resv object

[Christian König]

Am 24.01.22 um 17:36 schrieb Thomas Hellström (Intel):


On 1/24/22 14:03, Christian König wrote:

Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 


Reviewed-by: Thomas Hellström 

Is there any indication that this triggers on existing drivers?


There used to be a case in amdgpu which triggered this, but at least I'm 
not aware of any in the current code.


Christian.



Thomas

Re: [PATCH 01/11] drm/radeon: use ttm_resource_manager_debug

[Christian König]

Am 24.01.22 um 17:33 schrieb Thomas Hellström:

On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote:

Instead of calling the debug operation directly.

Signed-off-by: Christian König 
Reviewed-by: Huang Rui 

The first two patches seem unrelated to the series.


No idea what happened here, those two are already upstream.

I probably just forgot to pull drm-misc-next changes from a different 
system.



Also is there a chance of a series cover-letter?


Going to add one the next time, but I though it would be pretty clear 
what this is now about.


Thanks,
Christian.



Thanks,
Thomas




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

diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 11b21d605584..0d1283cdc8fb 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -802,7 +802,7 @@ static int radeon_mm_vram_dump_table_show(struct
seq_file *m, void *unused)

TTM_PL_VRAM);

 struct drm_printer p = drm_seq_file_printer(m);
  
-   man->func->debug(man, );

+   ttm_resource_manager_debug(man, );
 return 0;
  }
  
@@ -820,7 +820,7 @@ static int radeon_mm_gtt_dump_table_show(struct

seq_file *m, void *unused)

TTM_PL_TT);

 struct drm_printer p = drm_seq_file_printer(m);
  
-   man->func->debug(man, );

+   ttm_resource_manager_debug(man, );
 return 0;
  }
  

[PATCH v2] drm/amd/pm: return -ENOTSUPP if there is no get_dpm_ultimate_freq function

[trix]

From: Tom Rix 

clang static analysis reports this represenative problem
amdgpu_smu.c:144:18: warning: The left operand of '*' is a garbage value
return clk_freq * 100;
    ^

If there is no get_dpm_ultimate_freq function,
smu_get_dpm_freq_range returns success without setting the
output min,max parameters.  So return an -ENOTSUPP error.

Fixes: e5ef784b1e17 ("drm/amd/powerplay: revise calling chain on retrieving 
frequency range")
Signed-off-by: Tom Rix 
---
v2: return error instead of initializing min/max

drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c 
b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
index 5ace30434e603..264eb09ccfd51 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
@@ -116,7 +116,7 @@ int smu_get_dpm_freq_range(struct smu_context *smu,
   uint32_t *min,
   uint32_t *max)
 {
-   int ret = 0;
+   int ret = -ENOTSUPP;
 
if (!min && !max)
return -EINVAL;
-- 
2.26.3

[PATCH 5.15 068/846] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

[Greg Kroah-Hartman]

From: Thomas Hellström 

commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream.

If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.

Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().

v2:
- Update Cc list, and add R-b.

Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container")
Cc: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Christian König 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:  # v5.4+
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma-buf/dma-fence-array.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str
 {
struct dma_fence_array *array = to_dma_fence_array(fence);
 
-   return atomic_read(>num_pending) <= 0;
+   if (atomic_read(>num_pending) > 0)
+   return false;
+
+   dma_fence_array_clear_pending_error(array);
+   return true;
 }
 
 static void dma_fence_array_release(struct dma_fence *fence)

Re: [PATCH] drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jan 24, 2022 at 12:05 PM Zhou Qingyang  wrote:
>
> In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()
> is assigned to mode and is passed to drm_mode_probed_add() directly after
> that. drm_mode_probed_add() passes >head to list_add_tail(), and
> there is a dereference of it in list_add_tail() without recoveries, which
> could lead to NULL pointer dereference on failure of
> amdgpu_dm_create_common_mode().
>
> Fix this by adding a NULL check of mode.
>
> This bug was found by a static analyzer.
>
> Builds with 'make allyesconfig' show no new warnings,
> and our static analyzer no longer warns about this code.
>
> Fixes: e7b07ceef2a6 ("drm/amd/display: Merge amdgpu_dm_types and amdgpu_dm")
> Signed-off-by: Zhou Qingyang 
> ---
> The analysis employs differential checking to identify inconsistent
> security operations (e.g., checks or kfrees) between two code paths
> and confirms that the inconsistent operations are not recovered in the
> current function or the callers, so they constitute bugs.
>
> Note that, as a bug found by static analysis, it can be a false
> positive or hard to trigger. Multiple researchers have cross-reviewed
> the bug.
>
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> 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 7f9773f8dab6..9ad94186b146 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -8143,6 +8143,9 @@ static void amdgpu_dm_connector_add_common_modes(struct 
> drm_encoder *encoder,
> mode = amdgpu_dm_create_common_mode(encoder,
> common_modes[i].name, common_modes[i].w,
> common_modes[i].h);
> +   if (!mode)
> +   continue;
> +
> drm_mode_probed_add(connector, mode);
> amdgpu_dm_connector->num_modes++;
> }
> --
> 2.25.1
>

Re: fbdev: Garbage collect fbdev scrolling acceleration

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:27 PM Geert Uytterhoeven  wrote:
>
> Hi Daniel et al,
>
> On Wed, Jan 19, 2022 at 4:39 PM Daniel Vetter  wrote:
> > On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote:
> > > Helge Deller  writes:
> > > > I may have missed some discussions, but I'm objecting against this 
> > > > patch:
> > > >
> > > > b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling 
> > > > acceleration, part 1 (from TODO list)")
> > > >
> > > > Can we please (partly) revert it and restore the scrolling behaviour,
> > > > where fbcon uses fb_copyarea() to copy the screen contents instead of
> > > > redrawing the whole screen?
> > > >
> > > > I'm fine with dropping the ypan-functionality.
> > > >
> > > > Maybe on fast new x86 boxes the performance difference isn't huge,
> > > > but for all old systems, or when emulated in qemu, this makes
> > > > a big difference.
> > > >
> > > > Helge
> > >
> > > I second that. For most people, the framebuffer isn't important as
> > > they're mostly interested in getting to X11/wayland as fast as possible.
> > > But for systems like servers without X11 it's nice to have a fast
> > > console.
> >
> > Fast console howto:
> > - shadow buffer in cached memory
> > - timer based upload of changed areas to the real framebuffer
> >
> > This one is actually fast, instead of trying to use hw bltcopy and having
> > the most terrible fallback path if that's gone. Yes drm fbdev helpers has
> > this (but not enabled on most drivers because very, very few people care).
>
> That depends on the hardware, and the balance between CPU-to-RAM,
> CPU-to-VRAM, and GPU-to-VRAM bandwidths, and CPU and GPU performance.
>
> When scrolling, the fastest copy is the copy that doesn't need to copy
> much.  So that's why fbcon supports (or supported :-( many strategies:
> scrolling by wrapping, panning, copying (either by CPU or by (simple)
> GPU), re-rendering (useful for a GPU with bitmap expansion).  So forcing
> everybody to render into a fully cached shadow buffer and upload changed
> areas is not the silver bullet.
>
> Whether text output is rendered immediately or not is completely
> orthogonal to this.  While timer-based updates would speed up printing
> of large hunks of text (where no one actually reads what was printed at
> the top), that would have almost no impact on actual interactive console
> work: it may still take 0.5s to scroll the screen if you press "enter"
> when your cursor is positioned on the last line.
> BTW, implementing timer-based updates would make measuring real-world
> performance more difficult, as we would have to use a different
> benchmark than "time dmesg" ;-)
>
> Both Daniel and Thomas said: fbdev is not suitable for modern hardware.
> Fine, we do not debate that, and do not want to prevent you from using
> DRM for modern hardware.  Then please accept us saying that DRM (in its
> current form) is not suitable for other types of graphics hardware.
> Still, even modern (embedded) hardware may have small low-color
> displays.
>
> For the last +5 years, we've been pointed to the tinydrm drivers, to
> serve as examples for converting existing fbdev drivers to drm drivers.
> All but one of them are drivers for hi-color or better hardware, thus
> surpassing the capabilities of lots of hardware driven by fbdev drivers.
> The other one is an e-ink driver that exposes an XRGB shadow frame
> buffer, and converts that in a two-step process, first to 8-bit
> grayscale, second to 1-bit monochrome.  If that is considered a good
> example, should I be impressed?
> Compare that to other subsystems boasting about zero-copy...

tiny drivers are the state of the art for small neat drivers. As you
pointed out multiple times now there's not Rx or Cx support for x < 8
in drm or fbdev yet, so that would need to be added. If someone cares
enough for that. Some of the fbtft drivers have gone down
substantially when ported to tiny, which is really the claim we've put
down. Not that you'll find the perfect C4 pixel format example in
there, at most you find C8 support in some of the really old drivers
like i915/radeon/nouveau for old platforms. But that's very well
burried.

I guess in practice (as you point out below) the repaper display is so
glacially slow anyway and connected to machines with enough ram that
generally the only case that mattered was convenience and hence
supporting what every drm userspace can cope with minimally. Which is
xrgb. So yeah don't look at a driver which updates at roughly
0.5fps for efficient upload code :-) The space wasting is a bit more
important and should be trivial to add if someone cares enough to do
that.
-Daniel

> Furthermore, for a contemporary e-ink device like[1], the shadow buffer
> would consume 10 MiB.  Of course this device has 4 GiB of RAM, and quad
> Cortex-A55 CPU cores, but not all systems have 10 MiB to spare...
>
> [1] https://linuxgizmos.com/rk3566-based-pinenote-e-ink-tablet-ships-at-399/
>
> Gr{oetje,eeting}s,
>
>  

[PATCH 5.10 171/563] drm/tegra: vic: Fix DMA API misuse

[Greg Kroah-Hartman]

From: Robin Murphy 

[ Upstream commit 5566174cb10a5167d59b0793871cab7990b149b8 ]

Upon failure, dma_alloc_coherent() returns NULL. If that does happen,
passing some uninitialised stack contents to dma_mapping_error() - which
belongs to a different API in the first place - has precious little
chance of detecting it.

Also include the correct header, because the fragile transitive
inclusion currently providing it is going to break soon.

Fixes: 20e7dce255e9 ("drm/tegra: Remove memory allocation from Falcon library")
CC: Thierry Reding 
CC: Mikko Perttunen 
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Robin Murphy 
Reviewed-by: Christoph Hellwig 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/tegra/vic.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index b77f726303d89..ec0e4d8f0aade 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -5,6 +5,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -265,10 +266,8 @@ static int vic_load_firmware(struct vic *vic)
 
if (!client->group) {
virt = dma_alloc_coherent(vic->dev, size, , GFP_KERNEL);
-
-   err = dma_mapping_error(vic->dev, iova);
-   if (err < 0)
-   return err;
+   if (!virt)
+   return -ENOMEM;
} else {
virt = tegra_drm_alloc(tegra, size, );
}
-- 
2.34.1

[PATCH] drm/docs: Document where the C8 color lut is stored

[Daniel Vetter]

Also add notes that for atomic drivers it's really somewhere else and
no longer in struct drm_crtc.

Maybe we should put a bigger warning here that this is confusing,
since the pixel format is a plane property, but the GAMMA_LUT property
is on the crtc. But I think we can fix this if/when someone finds a
need for a per-plane CLUT, since I'm not sure such hw even exists. I'm
also not sure whether even hardware with a CLUT and a full color
correction pipeline with degamm/cgm/gamma exists.

Motivated by comments from Geert that we have a gap here.

Cc: Geert Uytterhoeven 
Cc: Ville Syrjälä 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_color_mgmt.c |  4 
 include/drm/drm_crtc.h   | 10 ++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index bb14f488c8f6..96ce57ad37e6 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -82,6 +82,10 @@
  * driver boot-up state too. Drivers can access this blob through
  * _crtc_state.gamma_lut.
  *
+ * Note that for mostly historical reasons stemming from Xorg heritage,
+ * this is also used to store the color lookup table (CLUT) for indexed
+ * formats like DRM_FORMAT_C8.
+ *
  * “GAMMA_LUT_SIZE”:
  * Unsigned range property to give the size of the lookup table to be set
  * on the GAMMA_LUT property (the size depends on the underlying hardware).
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4d01b4d89775..03cc53220a2a 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -285,6 +285,10 @@ struct drm_crtc_state {
 * Lookup table for converting pixel data after the color conversion
 * matrix @ctm.  See drm_crtc_enable_color_mgmt(). The blob (if not
 * NULL) is an array of  drm_color_lut.
+*
+* Note that for mostly historical reasons stemming from Xorg heritage,
+* this is also used to store the color lookup table (CLUT) for indexed
+* formats like DRM_FORMAT_C8.
 */
struct drm_property_blob *gamma_lut;
 
@@ -1075,12 +1079,18 @@ struct drm_crtc {
/**
 * @gamma_size: Size of legacy gamma ramp reported to userspace. Set up
 * by calling drm_mode_crtc_set_gamma_size().
+*
+* Note that atomic drivers need to instead use
+* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
 */
uint32_t gamma_size;
 
/**
 * @gamma_store: Gamma ramp values used by the legacy SETGAMMA and
 * GETGAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().
+*
+* Note that atomic drivers need to instead use
+* _crtc_state.gamma_lut. See drm_crtc_enable_color_mgmt().
 */
uint16_t *gamma_store;
 
-- 
2.33.0

[PATCH 5.10 035/563] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

[Greg Kroah-Hartman]

From: Thomas Hellström 

commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream.

If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.

Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().

v2:
- Update Cc list, and add R-b.

Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container")
Cc: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Christian König 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:  # v5.4+
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma-buf/dma-fence-array.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str
 {
struct dma_fence_array *array = to_dma_fence_array(fence);
 
-   return atomic_read(>num_pending) <= 0;
+   if (atomic_read(>num_pending) > 0)
+   return false;
+
+   dma_fence_array_clear_pending_error(array);
+   return true;
 }
 
 static void dma_fence_array_release(struct dma_fence *fence)

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:51 PM Geert Uytterhoeven  wrote:
>
> Hi Daniel,
>
> On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter  wrote:
> > But reading code is too hard I guess, safer to assume it's just
> > broken and not supported.
>
> I confirm there's lots of documentation (and even more code ;-),
> which is always great!
> But both are intimidating to me, and most of the documentation covers
> features I'm not interested in, as they're only applicable to fancy
> modern truecolor 3D-capable multi-buffer and multi-head hardware, while
> what I am looking for is usually not documented.  E.g. I had a hard
> time to discover how color look-up tables work (gamma_{store,size}!),
> as this is not covered in https://docs.kernel.org/gpu/index.html,
> and none of the tinydrm drivers support CLUT modes.

Hm yeah that part is a bit awkward since due to how Xorg works here
the gamma table is abused to be the lookup table for C8. If we're
adding piles of new Cx formats it might be worth it to structure this
a bit better, e.g. (really just thinking on the spot here):
- have a separate Cx lookup table blob in drm_plane_state (in theory
you could have a different one on each plane and still have an overall
gamma ramp on the crtc)
- change the compat functions which map the legacy gamma ramp to
redirect to the plane gamma ramp if the primary plane is set to Cx
- bonus points for then correctly sizing the lookup table to match the
number of bits in the Cx plane format

But unfiddling this confusion properly is going to be tricky. I think
just continuing the tradition we have for C8 and reusing the crtc
gamma ramp for that is probably fine for now.

And yes that's not documented, because when we fixed the docs for the
entire degamm/CGM/gamma color correction pipeline Cx wasn't the top
priority :-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 5.4 027/320] dma_fence_array: Fix PENDING_ERROR leak in dma_fence_array_signaled()

[Greg Kroah-Hartman]

From: Thomas Hellström 

commit 95d35838880fb040ccb9fe4a48816bd0c8b62df5 upstream.

If a dma_fence_array is reported signaled by a call to
dma_fence_is_signaled(), it may leak the PENDING_ERROR status.

Fix this by clearing the PENDING_ERROR status if we return true in
dma_fence_array_signaled().

v2:
- Update Cc list, and add R-b.

Fixes: 1f70b8b812f3 ("dma-fence: Propagate errors to dma-fence-array container")
Cc: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Christian König 
Cc: "Christian König" 
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Cc:  # v5.4+
Signed-off-by: Thomas Hellström 
Reviewed-by: Christian König 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20211129152727.448908-1-thomas.hellst...@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/dma-buf/dma-fence-array.c |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -104,7 +104,11 @@ static bool dma_fence_array_signaled(str
 {
struct dma_fence_array *array = to_dma_fence_array(fence);
 
-   return atomic_read(>num_pending) <= 0;
+   if (atomic_read(>num_pending) > 0)
+   return false;
+
+   dma_fence_array_clear_pending_error(array);
+   return true;
 }
 
 static void dma_fence_array_release(struct dma_fence *fence)

Re: [PATCH] drm/amd/display/dc/calcs/dce_calcs: Fix a memleak in calculate_bandwidth()

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Jan 24, 2022 at 12:05 PM Zhou Qingyang  wrote:
>
> In calculate_bandwidth(), the tag free_sclk and free_yclk are reversed,
> which could lead to a memory leak of yclk.
>
> Fix this bug by changing the location of free_sclk and free_yclk.
>
> This bug was found by a static analyzer.
>
> Builds with 'make allyesconfig' show no new warnings,
> and our static analyzer no longer warns about this code.
>
> Fixes: 2be8989d0fc2 ("drm/amd/display/dc/calcs/dce_calcs: Move some large 
> variables from the stack to the heap")
> Signed-off-by: Zhou Qingyang 
> ---
> The analysis employs differential checking to identify inconsistent
> security operations (e.g., checks or kfrees) between two code paths
> and confirms that the inconsistent operations are not recovered in the
> current function or the callers, so they constitute bugs.
>
> Note that, as a bug found by static analysis, it can be a false
> positive or hard to trigger. Multiple researchers have cross-reviewed
> the bug.
>
>  drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c 
> b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> index ff5bb152ef49..e6ef36de0825 100644
> --- a/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> +++ b/drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
> @@ -2033,10 +2033,10 @@ static void calculate_bandwidth(
> kfree(surface_type);
>  free_tiling_mode:
> kfree(tiling_mode);
> -free_yclk:
> -   kfree(yclk);
>  free_sclk:
> kfree(sclk);
> +free_yclk:
> +   kfree(yclk);
>  }
>
>  
> /***
> --
> 2.25.1
>

Re: [PATCH v1 2/2] drm/panel-edp: Add sharp panel support for sc7280

[Doug Anderson]

Hi,

On Mon, Jan 24, 2022 at 10:16 AM Sankeerth Billakanti
 wrote:
>
> Add eDP panel support for sc7280 CRD platform.
>
> Signed-off-by: Sankeerth Billakanti 
> ---
>  drivers/gpu/drm/panel/panel-edp.c | 11 +++
>  1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c 
> b/drivers/gpu/drm/panel/panel-edp.c
> index 176ef0c..bb2e346 100644
> --- a/drivers/gpu/drm/panel/panel-edp.c
> +++ b/drivers/gpu/drm/panel/panel-edp.c
> @@ -1605,6 +1605,14 @@ static const struct panel_desc sharp_lq123p1jx31 = {
> },
>  };
>
> +static const struct panel_desc sharp_lq140m1jw46 = {
> +   .bpc = 8,
> +   .size = {
> +   .width = 309,
> +   .height = 173,
> +   },

Where are your delays? I very much doubt that they are all 0.

I guess you're also not putting timings in here and you're relying on
these coming from the EDID? My own preference would be:

1. If you are relying on a reliable way to read the EDID of the panel
then you shouldn't even need to add anything to this section of the
file. You should use the "edp-panel" compatible string and then add an
entry to the "edp_panels" structure.

2. If you want to support folks that don't have a reliable way to read
the EDID then you can add things here, but you should add a mode.


> +};
> +
>  static const struct drm_display_mode starry_kr122ea0sra_mode = {
> .clock = 147000,
> .hdisplay = 1920,
> @@ -1719,6 +1727,9 @@ static const struct of_device_id platform_of_match[] = {
> .compatible = "sharp,lq123p1jx31",
> .data = _lq123p1jx31,
> }, {
> +   .compatible = "sharp_lq140m1jw46",
> +   .data = _lq140m1jw46,

Two problems:

1. You should use a ",", not a "_" to separate the vendor from the model.

2. You need to post device tree bindings for this.


NOTE: if instead your eDP controller supports DP AUX bus then you
don't need to add to this table at all and you don't need to add
bindings. Instead, you'd add your EDID panel ID to the "edp_panels"
structure.

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Thomas Zimmermann]

Hi

Am 24.01.22 um 19:38 schrieb Geert Uytterhoeven:

Hi Daniel,

On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter  wrote:

Just to clarify, since we had lots of smaller and bigger
misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so
drm support that already. The fbdev emulation doesn't yet, but all
that's needed for that is filling out the code to remap the drm
description to the fbdev format description for this case. Plus
testing it all works ofc with fbcon and whatelse. Note that RGB332  is
a bit more work than e.g. C4, since atm fbdev still uses only bpp to
identify formats, so would need to be switch over to drm_fourcc first
before adding anything which aliases with something existing (we have
C8 already wired up).


I doubt that RGB332 would be a bit more work than C4, as RGB332 is still
8 bpp, while C4 is less.  To support C4, all DRM code that cannot
handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be
fixed first.

On the plus side, I finally got my proof-of-concept Atari DRM driver
working with fbcon on ARAnyM.  Mapping /dev/fb0 from userspace doesn't
work (fbtest SEGVs while reading from the mapped frame buffer).  I don't
know yet if this is a general issue without deferred I/O in v5.17-rc1,
or a bug in the m68k MM code...

So far it supports C8 only, but I hope to tackle C4 and monochrome soon.
Whether the end result will be usable on real hardware is still to be
seen, but at least I hope to get some DRM code written...


That sounds pretty cool.

Best regards
Thomas



Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH v1 1/2] ARM64: dts: qcom: enable eDP panel support for sc7280

[Doug Anderson]

Hi,

On Mon, Jan 24, 2022 at 10:15 AM Sankeerth Billakanti
 wrote:
>
> Enable the eDP display panel support with backlight on sc7280 platform.
>
> Signed-off-by: Sankeerth Billakanti 
> ---
>  arch/arm64/boot/dts/qcom/sc7280-crd.dts | 127 
> 
>  1 file changed, 127 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts 
> b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> index cd2755c..fde6f75 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> +++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
> @@ -64,6 +64,47 @@ ap_ts_pen_1v8:  {
> };
>  };
>
> + {
> +   status = "okay";
> +};
> +
> +_mdp {
> +   status = "okay";
> +};

"mdss_mdp" sorts after "mdss_edp",


> +_edp {
> +   status = "okay";
> +
> +   vdda-1p2-supply = <_l6b_1p2>;
> +   vdda-0p9-supply = <_l10c_0p8>;
> +
> +   ports {
> +   port@1 {
> +   reg = <1>;
> +   edp_out: endpoint {
> +   remote-endpoint = <_panel_in>;
> +   };
> +   };
> +   };

I think part of the above should be in sc7280.dtsi. Basically in
sc7820.dtsi I think you should have:

ports {
  #address-cells = <1>;
  #size-cells = <0>;
  port@0 {
reg = <0>;
edp_in: endpoint {
  remote-endpoint = <_intf5_out>;
};
  };
  port@1 {
reg = <1>;
edp_out: endpoint {
};
  };
};

...and then the crd dts file just needs:

_out {
  remote-endpoint = <_panel_in>;
};

Right?


> +};
> +
> +_edp_phy {
> +   status = "okay";
> +
> +   vdda-1p2-supply = <_l6b_1p2>;
> +   vdda-0p9-supply = <_l10c_0p8>;
> +};
> +
> +_dp {
> +   status = "okay";
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_hot_plug_det>;
> +   data-lanes = <0 1>;
> +   vdda-1p2-supply = <_l6b_1p2>;
> +   vdda-0p9-supply = <_l1b_0p8>;
> +};
> +
>  _3v3_regulator {
> gpio = < 51 GPIO_ACTIVE_HIGH>;
>  };
> @@ -72,7 +113,93 @@ ap_ts_pen_1v8:  {
> pins = "gpio51";
>  };
>
> +_pwm{

nit: space after "pwm" and before "{"


> +   status = "okay";

Don't you need:

pinctrl-names = "default";
pinctrl-0 = <_pwm_default>;


> +};
> +
> +_gpios {
> +   backlight_pwm_default: backlight_pwm_default {

nit: node name should have dashes, not underscores. Also, don't
include the word "default".


> +   pinconf {
> +   pins = "gpio8";
> +   function = "func1";
> +   output-low;
> +   bias-disable;
> +   power-source = <0>;
> +   qcom,drive-strength = <3>;


Instead of 3, should be PMIC_GPIO_STRENGTH_LOW

> +   };

Don't need the "pinconf" subnode.


> +   };
> +};
> +
> + {

Don't need to put the regulators under  They can be top level, right?


> +   backlight_power: backlight_power {

nit: node names should have "-", not "_"


> +   compatible = "regulator-fixed";
> +   regulator-name = "backlight_power";
> +   regulator-always-on;
> +   regulator-boot-on;
> +   };
> +
> +   edp_power: edp_power {

nit: node names should have "-", not "_"


> +   compatible = "regulator-fixed";
> +   regulator-name = "edp_power";
> +
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +
> +   gpio = < 80 GPIO_ACTIVE_HIGH>;
> +   enable-active-high;
> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_panel_power_default>;
> +   };
> +
> +   edp_backlight: edp_backlight {

nit: node names should have a "-", not an "_".


> +   compatible = "pwm-backlight";
> +
> +   pwms = <_pwm 3 65535>;
> +   power-supply = <_power>;
> +   enable-gpio = <_gpios 7 GPIO_ACTIVE_HIGH>;

So wait. Why do you have a "bogus" backlight_power regulator and then
a separate enable-gpio? Why

> +
> +   pinctrl-names = "default";
> +   pinctrl-0 = <_pwm_default>;

This pinctrl belongs as part of the PWM, not as part of the backlight.

...but where's the pinctrl for pm8350c_gpios #7? That _should_ be here
since that's the backlight enable.


> +   };
> +
> +   edp_panel: edp_panel {
> +   compatible = "sharp_lq140m1jw46";

Device tree compatible strings separate the manufacturer from the
model with ",", not "_".


> +   pinctrl-names = "default";
> +   pinctrl-0 = <_hot_plug_det>;

I think for eDP we probably want the pinctrl to be in the sc7280.dtsi
file. It seems highly likely that people will hook up the eDP HPD pin
to the standard place. If they don't then boards can override it.


> +   power-supply = <_power>;
> +   backlight = <_backlight>;
> +
> +   ports {
> +   #address-cells = <1>;
> +  

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Thu, Jan 20, 2022 at 1:33 PM Daniel Vetter  wrote:
> But reading code is too hard I guess, safer to assume it's just
> broken and not supported.

I confirm there's lots of documentation (and even more code ;-),
which is always great!
But both are intimidating to me, and most of the documentation covers
features I'm not interested in, as they're only applicable to fancy
modern truecolor 3D-capable multi-buffer and multi-head hardware, while
what I am looking for is usually not documented.  E.g. I had a hard
time to discover how color look-up tables work (gamma_{store,size}!),
as this is not covered in https://docs.kernel.org/gpu/index.html,
and none of the tinydrm drivers support CLUT modes.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Daniel Vetter]

On Mon, Jan 24, 2022 at 7:39 PM Geert Uytterhoeven  wrote:
>
> Hi Daniel,
>
> On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter  wrote:
> > Just to clarify, since we had lots of smaller and bigger
> > misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so
> > drm support that already. The fbdev emulation doesn't yet, but all
> > that's needed for that is filling out the code to remap the drm
> > description to the fbdev format description for this case. Plus
> > testing it all works ofc with fbcon and whatelse. Note that RGB332  is
> > a bit more work than e.g. C4, since atm fbdev still uses only bpp to
> > identify formats, so would need to be switch over to drm_fourcc first
> > before adding anything which aliases with something existing (we have
> > C8 already wired up).
>
> I doubt that RGB332 would be a bit more work than C4, as RGB332 is still
> 8 bpp, while C4 is less.  To support C4, all DRM code that cannot
> handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be
> fixed first.

Hm what's broken with it? Current code means it cannot support odd
width for C4 (because to make C4 fit into bytes you need 2 pixels),
but otherwise this should all work. Iirc we have formats with "5
pixels in 4 bytes" and fun stuff like that. Note that stride and also
the actual window you scan out are all separate, so even if your hw
needs an odd stride or you have an odd resolution it should still all
work out for C4 with the existing infra.

RGB322 is more work because in the fbdev code this aliases with bpp=8
which is C8, because no one has yet moved the fbdev emulation code
forward into the drm_fourcc world.

> On the plus side, I finally got my proof-of-concept Atari DRM driver
> working with fbcon on ARAnyM.  Mapping /dev/fb0 from userspace doesn't
> work (fbtest SEGVs while reading from the mapped frame buffer).  I don't
> know yet if this is a general issue without deferred I/O in v5.17-rc1,
> or a bug in the m68k MM code...
>
> So far it supports C8 only, but I hope to tackle C4 and monochrome soon.
> Whether the end result will be usable on real hardware is still to be
> seen, but at least I hope to get some DRM code written...

Yay, this sounds interesting!
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

[Geert Uytterhoeven]

Hi Daniel,

On Fri, Jan 21, 2022 at 9:55 AM Daniel Vetter  wrote:
> Just to clarify, since we had lots of smaller and bigger
> misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so
> drm support that already. The fbdev emulation doesn't yet, but all
> that's needed for that is filling out the code to remap the drm
> description to the fbdev format description for this case. Plus
> testing it all works ofc with fbcon and whatelse. Note that RGB332  is
> a bit more work than e.g. C4, since atm fbdev still uses only bpp to
> identify formats, so would need to be switch over to drm_fourcc first
> before adding anything which aliases with something existing (we have
> C8 already wired up).

I doubt that RGB332 would be a bit more work than C4, as RGB332 is still
8 bpp, while C4 is less.  To support C4, all DRM code that cannot
handle format->cpp[0] < 1 or drm_format_info_block_width() > 1 has to be
fixed first.

On the plus side, I finally got my proof-of-concept Atari DRM driver
working with fbcon on ARAnyM.  Mapping /dev/fb0 from userspace doesn't
work (fbtest SEGVs while reading from the mapped frame buffer).  I don't
know yet if this is a general issue without deferred I/O in v5.17-rc1,
or a bug in the m68k MM code...

So far it supports C8 only, but I hope to tackle C4 and monochrome soon.
Whether the end result will be usable on real hardware is still to be
seen, but at least I hope to get some DRM code written...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: fbdev: Garbage collect fbdev scrolling acceleration

[Geert Uytterhoeven]

Hi Daniel et al,

On Wed, Jan 19, 2022 at 4:39 PM Daniel Vetter  wrote:
> On Thu, Jan 13, 2022 at 10:46:03PM +0100, Sven Schnelle wrote:
> > Helge Deller  writes:
> > > I may have missed some discussions, but I'm objecting against this patch:
> > >
> > > b3ec8cdf457e5 ("fbdev: Garbage collect fbdev scrolling acceleration, 
> > > part 1 (from TODO list)")
> > >
> > > Can we please (partly) revert it and restore the scrolling behaviour,
> > > where fbcon uses fb_copyarea() to copy the screen contents instead of
> > > redrawing the whole screen?
> > >
> > > I'm fine with dropping the ypan-functionality.
> > >
> > > Maybe on fast new x86 boxes the performance difference isn't huge,
> > > but for all old systems, or when emulated in qemu, this makes
> > > a big difference.
> > >
> > > Helge
> >
> > I second that. For most people, the framebuffer isn't important as
> > they're mostly interested in getting to X11/wayland as fast as possible.
> > But for systems like servers without X11 it's nice to have a fast
> > console.
>
> Fast console howto:
> - shadow buffer in cached memory
> - timer based upload of changed areas to the real framebuffer
>
> This one is actually fast, instead of trying to use hw bltcopy and having
> the most terrible fallback path if that's gone. Yes drm fbdev helpers has
> this (but not enabled on most drivers because very, very few people care).

That depends on the hardware, and the balance between CPU-to-RAM,
CPU-to-VRAM, and GPU-to-VRAM bandwidths, and CPU and GPU performance.

When scrolling, the fastest copy is the copy that doesn't need to copy
much.  So that's why fbcon supports (or supported :-( many strategies:
scrolling by wrapping, panning, copying (either by CPU or by (simple)
GPU), re-rendering (useful for a GPU with bitmap expansion).  So forcing
everybody to render into a fully cached shadow buffer and upload changed
areas is not the silver bullet.

Whether text output is rendered immediately or not is completely
orthogonal to this.  While timer-based updates would speed up printing
of large hunks of text (where no one actually reads what was printed at
the top), that would have almost no impact on actual interactive console
work: it may still take 0.5s to scroll the screen if you press "enter"
when your cursor is positioned on the last line.
BTW, implementing timer-based updates would make measuring real-world
performance more difficult, as we would have to use a different
benchmark than "time dmesg" ;-)

Both Daniel and Thomas said: fbdev is not suitable for modern hardware.
Fine, we do not debate that, and do not want to prevent you from using
DRM for modern hardware.  Then please accept us saying that DRM (in its
current form) is not suitable for other types of graphics hardware.
Still, even modern (embedded) hardware may have small low-color
displays.

For the last +5 years, we've been pointed to the tinydrm drivers, to
serve as examples for converting existing fbdev drivers to drm drivers.
All but one of them are drivers for hi-color or better hardware, thus
surpassing the capabilities of lots of hardware driven by fbdev drivers.
The other one is an e-ink driver that exposes an XRGB shadow frame
buffer, and converts that in a two-step process, first to 8-bit
grayscale, second to 1-bit monochrome.  If that is considered a good
example, should I be impressed?
Compare that to other subsystems boasting about zero-copy...

Furthermore, for a contemporary e-ink device like[1], the shadow buffer
would consume 10 MiB.  Of course this device has 4 GiB of RAM, and quad
Cortex-A55 CPU cores, but not all systems have 10 MiB to spare...

[1] https://linuxgizmos.com/rk3566-based-pinenote-e-ink-tablet-ships-at-399/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH V2 0/7] DRM kmap() fixes and kmap_local_page() conversions

[Ira Weiny]

On Mon, Jan 24, 2022 at 01:08:26PM +0100, Christian König wrote:
> Am 24.01.22 um 02:54 schrieb ira.we...@intel.com:
> > From: Ira Weiny 
> > 
> > Changes from V1:
> > Use memcpy_to_page() where appropriate
> > Rebased to latest
> > 
> > The kmap() call may cause issues with work being done with persistent 
> > memory.
> > For this and other reasons it is being deprecated.
> 
> I'm really wondering how we should be able to implement the kernel mapping
> without kmap in TTM.
> 
> > This series starts by converting the last easy kmap() uses in the drm tree 
> > to
> > kmap_local_page().
> > 
> > The final 2 patches fix bugs found while working on the ttm_bo_kmap_ttm()
> > conversion.  They are valid fixes but were found via code inspection not
> > because of any actual bug so don't require a stable tag.[1]
> > 
> > There is one more call to kmap() used in ttm_bo_kmap_ttm().  Unfortunately,
> > fixing this is not straight forward so it is left to future work.[2]
> 
> Patches #2, #4, #6 and #7 are Reviewed-by: Christian König
> 

Christian,

Would you prefer I send those 4 to you as a separate series?

> 
> How to you now want to push those upstream? I can pick them up for the AMD
> tree like Daniel suggested or you can push them through something else.

You picking them up from this series is ok as well.

Daniel will you take #1, #3, and #5?

Thanks,
Ira

> 
> Regards,
> Christian.
> 
> > 
> > [1] 
> > https://lore.kernel.org/lkml/fb71af05-a889-8f6e-031b-426b58a64...@amd.com/
> > [2] 
> > https://lore.kernel.org/lkml/20211215210949.gw3538...@iweiny-desk2.sc.intel.com/
> > 
> > 
> > Ira Weiny (7):
> > drm/i915: Replace kmap() with kmap_local_page()
> > drm/amd: Replace kmap() with kmap_local_page()
> > drm/gma: Remove calls to kmap()
> > drm/radeon: Replace kmap() with kmap_local_page()
> > drm/msm: Alter comment to use kmap_local_page()
> > drm/amdgpu: Ensure kunmap is called on error
> > drm/radeon: Ensure kunmap is called on error
> > 
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 8 
> > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 1 +
> > drivers/gpu/drm/gma500/gma_display.c | 6 ++
> > drivers/gpu/drm/gma500/mmu.c | 8 
> > drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 6 ++
> > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 
> > drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 4 ++--
> > drivers/gpu/drm/i915/gt/shmem_utils.c | 7 ++-
> > drivers/gpu/drm/i915/i915_gem.c | 8 
> > drivers/gpu/drm/i915/i915_gpu_error.c | 4 ++--
> > drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++--
> > drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
> > drivers/gpu/drm/radeon/radeon_uvd.c | 1 +
> > 13 files changed, 32 insertions(+), 37 deletions(-)
> > 
> > --
> > 2.31.1
> > 
> 

[PATCH v1 2/2] drm/panel-edp: Add sharp panel support for sc7280

[Sankeerth Billakanti]

Add eDP panel support for sc7280 CRD platform.

Signed-off-by: Sankeerth Billakanti 
---
 drivers/gpu/drm/panel/panel-edp.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index 176ef0c..bb2e346 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1605,6 +1605,14 @@ static const struct panel_desc sharp_lq123p1jx31 = {
},
 };
 
+static const struct panel_desc sharp_lq140m1jw46 = {
+   .bpc = 8,
+   .size = {
+   .width = 309,
+   .height = 173,
+   },
+};
+
 static const struct drm_display_mode starry_kr122ea0sra_mode = {
.clock = 147000,
.hdisplay = 1920,
@@ -1719,6 +1727,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "sharp,lq123p1jx31",
.data = _lq123p1jx31,
}, {
+   .compatible = "sharp_lq140m1jw46",
+   .data = _lq140m1jw46,
+   }, {
.compatible = "starry,kr122ea0sra",
.data = _kr122ea0sra,
}, {
-- 
2.7.4

[PATCH v1 1/2] ARM64: dts: qcom: enable eDP panel support for sc7280

[Sankeerth Billakanti]

Enable the eDP display panel support with backlight on sc7280 platform.

Signed-off-by: Sankeerth Billakanti 
---
 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 127 
 1 file changed, 127 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sc7280-crd.dts 
b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
index cd2755c..fde6f75 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-crd.dts
+++ b/arch/arm64/boot/dts/qcom/sc7280-crd.dts
@@ -64,6 +64,47 @@ ap_ts_pen_1v8:  {
};
 };
 
+ {
+   status = "okay";
+};
+
+_mdp {
+   status = "okay";
+};
+
+_edp {
+   status = "okay";
+
+   vdda-1p2-supply = <_l6b_1p2>;
+   vdda-0p9-supply = <_l10c_0p8>;
+
+   ports {
+   port@1 {
+   reg = <1>;
+   edp_out: endpoint {
+   remote-endpoint = <_panel_in>;
+   };
+   };
+   };
+};
+
+_edp_phy {
+   status = "okay";
+
+   vdda-1p2-supply = <_l6b_1p2>;
+   vdda-0p9-supply = <_l10c_0p8>;
+};
+
+_dp {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_hot_plug_det>;
+   data-lanes = <0 1>;
+   vdda-1p2-supply = <_l6b_1p2>;
+   vdda-0p9-supply = <_l1b_0p8>;
+};
+
 _3v3_regulator {
gpio = < 51 GPIO_ACTIVE_HIGH>;
 };
@@ -72,7 +113,93 @@ ap_ts_pen_1v8:  {
pins = "gpio51";
 };
 
+_pwm{
+   status = "okay";
+};
+
+_gpios {
+   backlight_pwm_default: backlight_pwm_default {
+   pinconf {
+   pins = "gpio8";
+   function = "func1";
+   output-low;
+   bias-disable;
+   power-source = <0>;
+   qcom,drive-strength = <3>;
+   };
+   };
+};
+
+ {
+   backlight_power: backlight_power {
+   compatible = "regulator-fixed";
+   regulator-name = "backlight_power";
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   edp_power: edp_power {
+   compatible = "regulator-fixed";
+   regulator-name = "edp_power";
+
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+
+   gpio = < 80 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_panel_power_default>;
+   };
+
+   edp_backlight: edp_backlight {
+   compatible = "pwm-backlight";
+
+   pwms = <_pwm 3 65535>;
+   power-supply = <_power>;
+   enable-gpio = <_gpios 7 GPIO_ACTIVE_HIGH>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm_default>;
+   };
+
+   edp_panel: edp_panel {
+   compatible = "sharp_lq140m1jw46";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_hot_plug_det>;
+
+   power-supply = <_power>;
+   backlight = <_backlight>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port@0 {
+   reg = <0>;
+   edp_panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+};
+
  {
+   edp_hot_plug_det: edp-hot-plug-det {
+   pins = "gpio60";
+   function = "edp_hot";
+   bias-pull-down;
+   input-enable;
+   };
+
+   edp_panel_power_default: edp_panel_power_default {
+   pins = "gpio80";
+   function = "gpio";
+   drive-strength = <2>;
+   output-high;
+   };
+
tp_int_odl: tp-int-odl {
pins = "gpio7";
function = "gpio";
-- 
2.7.4

[PATCH v1 0/2] Add support for the eDP panel on sc7280 CRD

[Sankeerth Billakanti]

Add support for the eDP panel on sc7280 CRD platform.

These changes are dependent on the following series:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=586263=both=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=560587=%2A=both


Sankeerth Billakanti (2):
  ARM64: dts: qcom: enable eDP panel support for sc7280
  drm/panel-edp: Add sharp panel support for sc7280

 arch/arm64/boot/dts/qcom/sc7280-crd.dts | 127 
 drivers/gpu/drm/panel/panel-edp.c   |  11 +++
 2 files changed, 138 insertions(+)

-- 
2.7.4

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

[Carsten Haitzler]

This makes sense given the other patches in your series, but it seems as 
yet no one has anything to say about this. I don't have anything 
specific to comment on other than it seems to make the correct changes 
to komeda given the rest.


Reviewed-by: Carsten Haitzler 

On 1/11/22 10:18, Kandpal, Suraj wrote:

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

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

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..eb37f41c1790 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -265,7 +265,7 @@ komeda_crtc_do_flush(struct drm_crtc *crtc,
if (slave && has_bit(slave->id, kcrtc_st->affected_pipes))
komeda_pipeline_update(slave, old->state);
  
-	conn_st = wb_conn ? wb_conn->base.base.state : NULL;

+   conn_st = wb_conn ? wb_conn->base.base->state : NULL;
if (conn_st && conn_st->writeback_job)
drm_writeback_queue_job(_conn->base, conn_st);
  
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h

index 456f3c435719..8d83883a1d99 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -53,6 +53,7 @@ struct komeda_plane_state {
   * struct komeda_wb_connector
   */
  struct komeda_wb_connector {
+   struct drm_connector conn;
/** @base: _writeback_connector */
struct drm_writeback_connector base;
  
@@ -136,7 +137,7 @@ struct komeda_kms_dev {

  static inline bool is_writeback_only(struct drm_crtc_state *st)
  {
struct komeda_wb_connector *wb_conn = to_kcrtc(st->crtc)->wb_conn;
-   struct drm_connector *conn = wb_conn ? _conn->base.base : NULL;
+   struct drm_connector *conn = wb_conn ? wb_conn->base.base : NULL;
  
  	return conn && (st->connector_mask == BIT(drm_connector_index(conn)));

  }
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
index e465cc4879c9..0caaf483276d 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_wb_connector.c
@@ -51,7 +51,7 @@ komeda_wb_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
  
-	wb_layer = to_kconn(to_wb_conn(conn_st->connector))->wb_layer;

+   wb_layer = 
to_kconn(drm_connector_to_writeback(conn_st->connector))->wb_layer;
  
  	/*

 * No need for a full modested when the only connector changed is the
@@ -123,7 +123,7 @@ komeda_wb_connector_fill_modes(struct drm_connector 
*connector,
  static void komeda_wb_connector_destroy(struct drm_connector *connector)
  {
drm_connector_cleanup(connector);
-   kfree(to_kconn(to_wb_conn(connector)));
+   kfree(to_kconn(drm_connector_to_writeback(connector)));
  }
  
  static const struct drm_connector_funcs komeda_wb_connector_funcs = {

@@ -155,6 +155,7 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
kwb_conn->wb_layer = kcrtc->master->wb_layer;
  
  	wb_conn = _conn->base;

+   wb_conn->base = _conn->conn;
wb_conn->encoder.possible_crtcs = BIT(drm_crtc_index(>base));
  
  	formats = komeda_get_layer_fourcc_list(>fmt_tbl,

@@ -171,9 +172,9 @@ static int komeda_wb_connector_add(struct komeda_kms_dev 
*kms,
return err;
}
  
-	drm_connector_helper_add(_conn->base, _wb_conn_helper_funcs);

+   drm_connector_helper_add(wb_conn->base, _wb_conn_helper_funcs);
  
-	info = _conn->base.base.display_info;

+   info = _conn->base.base->display_info;
info->bpc = __fls(kcrtc->master->improc->supported_color_depths);
info->color_formats = kcrtc->master->improc->supported_color_formats;
  

Re: [PATCH 02/60] drm/arm/hdlcd: Add support for the nomodeset kernel parameter

[Carsten Haitzler]

Seems fine.

Reviewed-by: Carsten Haitzler 

On 12/15/21 00:59, Javier Martinez Canillas wrote:

According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.

DRM drivers will not perform display-mode changes or accelerated rendering
and only the systewm system framebuffer will be available if it was set-up.

But only a few DRM drivers currently check for nomodeset, make this driver
to also support the command line parameter.

Signed-off-by: Javier Martinez Canillas 
---

  drivers/gpu/drm/arm/hdlcd_drv.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index 479c2422a2e0..0939a64a9bd2 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -382,6 +382,9 @@ static int hdlcd_probe(struct platform_device *pdev)
struct device_node *port;
struct component_match *match = NULL;
  
+	if (drm_firmware_drivers_only())

+   return -ENODEV;
+
/* there is only one output port inside each device, find it */
port = of_graph_get_remote_node(pdev->dev.of_node, 0, 0);
if (!port)

Re: [PATCH 01/60] drm/komeda: Add support for the nomodeset kernel parameter

[Carsten Haitzler]

Seems fine.

Reviewed-by: Carsten Haitzler 

On 12/15/21 00:59, Javier Martinez Canillas wrote:

According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.

DRM drivers will not perform display-mode changes or accelerated rendering
and only the systewm system framebuffer will be available if it was set-up.

But only a few DRM drivers currently check for nomodeset, make this driver
to also support the command line parameter.

Signed-off-by: Javier Martinez Canillas 
---

  drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
index e7933930a657..4f6d5c2103ec 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
@@ -9,6 +9,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include "komeda_dev.h"
  #include "komeda_kms.h"
@@ -117,6 +118,9 @@ static int komeda_platform_probe(struct platform_device 
*pdev)
struct component_match *match = NULL;
struct device_node *child;
  
+	if (drm_firmware_drivers_only())

+   return -EINVAL;
+
if (!dev->of_node)
return -ENODEV;
  

Re: [PATCH 03/60] drm/malidp: Add support for the nomodeset kernel parameter

[Carsten Haitzler]

Seems fine to me.

Reviewed-by: Carsten Haitzler 

On 12/15/21 00:59, Javier Martinez Canillas wrote:

According to disable Documentation/admin-guide/kernel-parameters.txt, this
parameter can be used to disable kernel modesetting.

DRM drivers will not perform display-mode changes or accelerated rendering
and only the systewm system framebuffer will be available if it was set-up.

But only a few DRM drivers currently check for nomodeset, make this driver
to also support the command line parameter.

Signed-off-by: Javier Martinez Canillas 
---

  drivers/gpu/drm/arm/malidp_drv.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 78d15b04b105..5da4168eb76d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -938,6 +938,9 @@ static int malidp_platform_probe(struct platform_device 
*pdev)
struct device_node *port;
struct component_match *match = NULL;
  
+	if (drm_firmware_drivers_only())

+   return -ENODEV;
+
if (!pdev->dev.of_node)
return -ENODEV;
  

Re: [PATCH] drm/nouveau: fix off by one in BIOS boundry checking

[Karol Herbst]

On Sat, Jan 22, 2022 at 11:44 AM Nick Lopez  wrote:
>
> Bounds checking when parsing init scripts embedded in the BIOS reject
> access to the last byte. This causes driver initialization to fail on
> Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working
> console.
>
> This is probably only seen on OpenFirmware machines like PowerPC Macs
> because the BIOS image provides by OF is only the used parts of the ROM,
> not a power-of-two blocks read from PCI directly so PCs always have
> empty bytes at the end that are never accesseed.
>

small typo nitpicks: provided and accessed

Also, I think it makes sense to add

Fixes: 4d4e9907ff572 "drm/nouveau/bios: guard against out-of-bounds
accesses to image"
Cc:  # v4.10+

so it gets automatically backported to applicable stable kernels

Anyway, whoever picks the patch can make those adjustments as well.

Reviewed-by: Karol Herbst 


> Signed-off-by: Nick Lopez 
> ---
>  drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c 
> b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c
> index d0f52d59fc2f..64e4239e 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/base.c
> @@ -38,7 +38,7 @@ nvbios_addr(struct nvkm_bios *bios, u32 *addr, u8 size)
> *addr += bios->imaged_addr;
> }
>
> -   if (unlikely(*addr + size >= bios->size)) {
> +   if (unlikely(*addr + size > bios->size)) {
> nvkm_error(>subdev, "OOB %d %08x %08x\n", size, p, 
> *addr);
> return false;
> }
> --
> 2.30.2
>

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Noralf Trønnes]

Den 24.01.2022 17.42, skrev Rob Herring:
> On Mon, Jan 24, 2022 at 10:28 AM Noralf Trønnes  wrote:
>>
>>
>>
>> Den 24.01.2022 17.08, skrev Rob Herring:
>>> On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes  wrote:

 Add binding for MIPI DBI compatible SPI panels.
>>>
>>> I'm sure we already have MIPI DBI panels. What's this for?
>>>
>>
>> It aims to use one driver to cover all MIPI DBI panels where the
>> controller setup is loaded from userspace in a firmware file.
> 
> What's the solution when the user wants a splash screen in the
> bootloader and also wants multiple panels supported?
> 

In that case the bootloader needs builtin support for the screen. The OS
driver can then detect that the controller is configured and just skip
the configure stage. I have yet to see someone implement suppport for
such a SPI panel in a bootloader though.

> Also, 1 driver doesn't dictate 1 compatible. A one to many
> relationship is fine and makes the decision entirely the OS's.
> 
>> The cover
>> letter points to the discussion where Maxime proposed this:
>>
>> https://lore.kernel.org/dri-devel/20211129093946.xhp22mvdut3m67sc@houat/
> 
> The proposal there is:
> 
>> compatible = "panel-spi";
>> model = "panel-from-random-place-42";
> 
> The same thing can be accomplished with this:
> 
> compatible = "panel-from-random-place-42", "panel-spi";
> 
> What's the advantage of hijacking 'model'?
> 

That's what Maxime proposed, but having it in the compatible like this
is even better. I suppose it's ok for the driver to use the compatible
to load the firmware file?

Noralf.

[PATCH 6/6 v2] drm/vc4: dpi: Support DPI interface in mode3 for RGB565

[Chris Morgan]

From: Chris Morgan 

Add support for the VC4 DPI driver to utilize DPI mode 3. This is
defined here as xxxRxxGGxxxB:
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#parallel-display-interface-dpi

This mode is required to use the Geekworm MZP280 DPI display.

Signed-off-by: Chris Morgan 
Reviewed-by: Dave Stevenson 
---
 drivers/gpu/drm/vc4/vc4_dpi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
index c180eb60b..3c58ade25 100644
--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -173,6 +173,10 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
*encoder)
dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_3,
   DPI_FORMAT);
break;
+   case MEDIA_BUS_FMT_RGB565_1X24_CPADHI:
+   dpi_c |= VC4_SET_FIELD(DPI_FORMAT_16BIT_565_RGB_2,
+  DPI_FORMAT);
+   break;
default:
DRM_ERROR("Unknown media bus format %d\n", bus_format);
break;
-- 
2.25.1

[PATCH 4/6 v2] dt-bindings: display: simple: add Geekworm MZP280 Panel

[Chris Morgan]

From: Chris Morgan 

The Geekworm MZP280 panel is a 480x640 (portrait) panel with a
capacitive touch interface and a 40 pin header meant to interface
directly with the Raspberry Pi. The screen is 2.8 inches diagonally,
and there appear to be at least 4 distinct versions all with the same
panel timings.

Timings were derived from drivers posted on the github located here:
https://github.com/tianyoujian/MZDPI/tree/master/vga

Additional details about this panel family can be found here:
https://wiki.geekworm.com/2.8_inch_Touch_Screen_for_Pi_zero

Signed-off-by: Chris Morgan 
---
 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 62f5f050c..3d03d8276 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -148,6 +148,8 @@ properties:
   - frida,frd350h54004
 # FriendlyELEC HD702E 800x1280 LCD panel
   - friendlyarm,hd702e
+# Geekworm MZP280 2.8" 480x640 LCD panel with capacitive touch
+  - geekworm,mzp280
 # GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel
   - giantplus,gpg48273qs5
 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel
-- 
2.25.1

[PATCH 1/6 v2] dt-bindings: vendor-prefixes: Add Geekworm

[Chris Morgan]

From: Chris Morgan 

Add vendor prefix for Geekworm (https://geekworm.com).

Signed-off-by: Chris Morgan 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 294093d45..c0c7627c6 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -455,6 +455,8 @@ patternProperties:
 description: General Electric Company
   "^geekbuying,.*":
 description: GeekBuying
+  "^geekworm,.*":
+description: Geekworm
   "^gef,.*":
 description: GE Fanuc Intelligent Platforms Embedded Systems, Inc.
   "^GEFanuc,.*":
-- 
2.25.1

[PATCH 5/6 v2] drm/panel: simple: add Geekworm MZP280 Panel

[Chris Morgan]

From: Chris Morgan 

Add support for the Geekworm MZP280 Panel

Signed-off-by: Chris Morgan 
Acked-by: Maxime Ripard 
---
 drivers/gpu/drm/panel/panel-simple.c | 29 
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9e46db5e3..cbc1a4fd1 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1824,6 +1824,32 @@ static const struct panel_desc friendlyarm_hd702e = {
},
 };
 
+static const struct drm_display_mode geekworm_mzp280_mode = {
+   .clock = 32000,
+   .hdisplay = 480,
+   .hsync_start = 480 + 41,
+   .hsync_end = 480 + 41 + 20,
+   .htotal = 480 + 41 + 20 + 60,
+   .vdisplay = 640,
+   .vsync_start = 640 + 5,
+   .vsync_end = 640 + 5 + 10,
+   .vtotal = 640 + 5 + 10 + 10,
+   .flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
+};
+
+static const struct panel_desc geekworm_mzp280 = {
+   .modes = _mzp280_mode,
+   .num_modes = 1,
+   .bpc = 6,
+   .size = {
+   .width = 47,
+   .height = 61,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB565_1X24_CPADHI,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
 static const struct drm_display_mode giantplus_gpg482739qs5_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -3790,6 +3816,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "friendlyarm,hd702e",
.data = _hd702e,
+   }, {
+   .compatible = "geekworm,mzp280",
+   .data = _mzp280,
}, {
.compatible = "giantplus,gpg482739qs5",
.data = _gpg482739qs5
-- 
2.25.1

[PATCH 3/6 v2] media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI

[Chris Morgan]

From: Chris Morgan 

Add the MEDIA_BUS_FMT_RGB565_1X24_CPADHI format used by the Geekworm
MZP280 panel for the Raspberry Pi.

Signed-off-by: Chris Morgan 
---
 include/uapi/linux/media-bus-format.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/media-bus-format.h 
b/include/uapi/linux/media-bus-format.h
index 0dfc11ee2..a7b765498 100644
--- a/include/uapi/linux/media-bus-format.h
+++ b/include/uapi/linux/media-bus-format.h
@@ -34,13 +34,14 @@
 
 #define MEDIA_BUS_FMT_FIXED0x0001
 
-/* RGB - next is   0x101e */
+/* RGB - next is   0x101f */
 #define MEDIA_BUS_FMT_RGB444_1X12  0x1016
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_BE  0x1001
 #define MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE  0x1002
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_BE  0x1003
 #define MEDIA_BUS_FMT_RGB555_2X8_PADHI_LE  0x1004
 #define MEDIA_BUS_FMT_RGB565_1X16  0x1017
+#define MEDIA_BUS_FMT_RGB565_1X24_CPADHI   0x101e
 #define MEDIA_BUS_FMT_BGR565_2X8_BE0x1005
 #define MEDIA_BUS_FMT_BGR565_2X8_LE0x1006
 #define MEDIA_BUS_FMT_RGB565_2X8_BE0x1007
-- 
2.25.1

[PATCH 2/6 v2] media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI

[Chris Morgan]

From: Chris Morgan 

Add support for MEDIA_BUS_FMT_RGB565_1X24_CPADHI. This format is used
by the Geekworm MZP280 panel which interfaces with the Raspberry Pi.

Signed-off-by: Chris Morgan 
---
 .../media/v4l/subdev-formats.rst  | 37 +++
 1 file changed, 37 insertions(+)

diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst 
b/Documentation/userspace-api/media/v4l/subdev-formats.rst
index 0cbc045d5..e43e07634 100644
--- a/Documentation/userspace-api/media/v4l/subdev-formats.rst
+++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst
@@ -624,6 +624,43 @@ The following tables list existing packed RGB formats.
   - b\ :sub:`2`
   - b\ :sub:`1`
   - b\ :sub:`0`
+* .. _MEDIA_BUS_FMT_RGB565_1X24_CPADHI:
+
+  - MEDIA_BUS_FMT_RGB565_1X24_CPADHI
+  - 0x101e
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  -
+  - 0
+  - 0
+  - 0
+  - r\ :sub:`4`
+  - r\ :sub:`3`
+  - r\ :sub:`2`
+  - r\ :sub:`1`
+  - r\ :sub:`0`
+  - 0
+  - 0
+  - g\ :sub:`5`
+  - g\ :sub:`4`
+  - g\ :sub:`3`
+  - g\ :sub:`2`
+  - g\ :sub:`1`
+  - g\ :sub:`0`
+  - 0
+  - 0
+  - 0
+  - b\ :sub:`4`
+  - b\ :sub:`3`
+  - b\ :sub:`2`
+  - b\ :sub:`1`
+  - b\ :sub:`0`
 * .. _MEDIA-BUS-FMT-BGR565-2X8-BE:
 
   - MEDIA_BUS_FMT_BGR565_2X8_BE
-- 
2.25.1

[PATCH 0/6 v2] Support Geekworm MZP280 Panel for Raspberry Pi

[Chris Morgan]

From: Chris Morgan 

This patch series is to add support for the MZP280 panel for the
Raspberry Pi. This panel requires adding support for Mode 3 of the
Raspberry Pi DPI connector, which necessitates a new media bus format.

This patch series has been tested on my Raspberry Pi 4 with version 1
of the panel in question.

Changes since V1:

 - Added documentation for vendor string.

Signed-off-by: Chris Morgan 

Chris Morgan (6):
  dt-bindings: vendor-prefixes: Add Geekworm
  media: uapi: Document format MEDIA_BUS_FMT_RGB565_1X24_CPADHI
  media: uapi: add MEDIA_BUS_FMT_RGB565_1X24_CPADHI
  dt-bindings: display: simple: add Geekworm MZP280 Panel
  drm/panel: simple: add Geekworm MZP280 Panel
  drm/vc4: dpi: Support DPI interface in mode3 for RGB565

 .../bindings/display/panel/panel-simple.yaml  |  2 +
 .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
 .../media/v4l/subdev-formats.rst  | 37 +++
 drivers/gpu/drm/panel/panel-simple.c  | 29 +++
 drivers/gpu/drm/vc4/vc4_dpi.c |  4 ++
 include/uapi/linux/media-bus-format.h |  3 +-
 6 files changed, 76 insertions(+), 1 deletion(-)

-- 
2.25.1

Re: [PATCH 08/11] dma-buf: add dma_fence_chain_contained helper

[Thomas Hellström]

On 1/24/22 14:03, Christian König wrote:

It's a reoccurring pattern that we need to extract the fence
from a dma_fence_chain object. Add a helper for this.

Signed-off-by: Christian König 


Reviewed-by: Thomas Hellström 



---
  drivers/dma-buf/dma-fence-chain.c |  6 ++
  include/linux/dma-fence-chain.h   | 15 +++
  2 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
index 084c6927b735..06f8ef97c6e8 100644
--- a/drivers/dma-buf/dma-fence-chain.c
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -148,8 +148,7 @@ static bool dma_fence_chain_enable_signaling(struct 
dma_fence *fence)
  
  	dma_fence_get(>base);

dma_fence_chain_for_each(fence, >base) {
-   struct dma_fence_chain *chain = to_dma_fence_chain(fence);
-   struct dma_fence *f = chain ? chain->fence : fence;
+   struct dma_fence *f = dma_fence_chain_contained(fence);
  
  		dma_fence_get(f);

if (!dma_fence_add_callback(f, >cb, dma_fence_chain_cb)) {
@@ -165,8 +164,7 @@ static bool dma_fence_chain_enable_signaling(struct 
dma_fence *fence)
  static bool dma_fence_chain_signaled(struct dma_fence *fence)
  {
dma_fence_chain_for_each(fence, fence) {
-   struct dma_fence_chain *chain = to_dma_fence_chain(fence);
-   struct dma_fence *f = chain ? chain->fence : fence;
+   struct dma_fence *f = dma_fence_chain_contained(fence);
  
  		if (!dma_fence_is_signaled(f)) {

dma_fence_put(fence);
diff --git a/include/linux/dma-fence-chain.h b/include/linux/dma-fence-chain.h
index ee906b659694..10d51bcdf7b7 100644
--- a/include/linux/dma-fence-chain.h
+++ b/include/linux/dma-fence-chain.h
@@ -66,6 +66,21 @@ to_dma_fence_chain(struct dma_fence *fence)
return container_of(fence, struct dma_fence_chain, base);
  }
  
+/**

+ * dma_fence_chain_contained - return the contained fence
+ * @fence: the fence to test
+ *
+ * If the fence is a dma_fence_chain the function returns the fence contained
+ * inside the chain object, otherwise it returns the fence itself.
+ */
+static inline struct dma_fence *
+dma_fence_chain_contained(struct dma_fence *fence)
+{
+   struct dma_fence_chain *chain = to_dma_fence_chain(fence);
+
+   return chain ? chain->fence : fence;
+}
+
  /**
   * dma_fence_chain_alloc
   *

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Rob Herring]

On Mon, Jan 24, 2022 at 10:28 AM Noralf Trønnes  wrote:
>
>
>
> Den 24.01.2022 17.08, skrev Rob Herring:
> > On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes  wrote:
> >>
> >> Add binding for MIPI DBI compatible SPI panels.
> >
> > I'm sure we already have MIPI DBI panels. What's this for?
> >
>
> It aims to use one driver to cover all MIPI DBI panels where the
> controller setup is loaded from userspace in a firmware file.

What's the solution when the user wants a splash screen in the
bootloader and also wants multiple panels supported?

Also, 1 driver doesn't dictate 1 compatible. A one to many
relationship is fine and makes the decision entirely the OS's.

> The cover
> letter points to the discussion where Maxime proposed this:
>
> https://lore.kernel.org/dri-devel/20211129093946.xhp22mvdut3m67sc@houat/

The proposal there is:

> compatible = "panel-spi";
> model = "panel-from-random-place-42";

The same thing can be accomplished with this:

compatible = "panel-from-random-place-42", "panel-spi";

What's the advantage of hijacking 'model'?

Rob

Re: [Intel-gfx] [PATCH 06/11] dma-buf: warn about containers in dma_resv object

[Intel]

On 1/24/22 14:03, Christian König wrote:

Drivers should not add containers as shared fences to the dma_resv
object, instead each fence should be added individually.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 


Reviewed-by: Thomas Hellström 

Is there any indication that this triggers on existing drivers?

Thomas

Re: [PATCH 01/11] drm/radeon: use ttm_resource_manager_debug

[Thomas Hellström]

On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote:
> Instead of calling the debug operation directly.
> 
> Signed-off-by: Christian König 
> Reviewed-by: Huang Rui 

The first two patches seem unrelated to the series. Also is there a
chance of a series cover-letter?

Thanks,
Thomas



> ---
>  drivers/gpu/drm/radeon/radeon_ttm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 11b21d605584..0d1283cdc8fb 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -802,7 +802,7 @@ static int radeon_mm_vram_dump_table_show(struct
> seq_file *m, void *unused)
>    
> TTM_PL_VRAM);
> struct drm_printer p = drm_seq_file_printer(m);
>  
> -   man->func->debug(man, );
> +   ttm_resource_manager_debug(man, );
> return 0;
>  }
>  
> @@ -820,7 +820,7 @@ static int radeon_mm_gtt_dump_table_show(struct
> seq_file *m, void *unused)
>    
> TTM_PL_TT);
> struct drm_printer p = drm_seq_file_printer(m);
>  
> -   man->func->debug(man, );
> +   ttm_resource_manager_debug(man, );
> return 0;
>  }
>  

Re: [PATCH 04/11] dma-buf: warn about dma_fence_array container rules v2

[Thomas Hellström]

On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote:
> It's not allowed to nest another dma_fence container into a
> dma_fence_array
> or otherwise we can run into recursion.
> 
> Warn about that when we create a dma_fence_array.
> 
> v2: fix comment style and typo in the warning pointed out by Thomas
> 
> Signed-off-by: Christian König 
> Reviewed-by: Daniel Vetter 

Reviewed-by: Thomas Hellström 

> ---
>  drivers/dma-buf/dma-fence-array.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-
> fence-array.c
> index 3e07f961e2f3..cb1bacb5a42b 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -176,6 +176,20 @@ struct dma_fence_array
> *dma_fence_array_create(int num_fences,
>  
> array->base.error = PENDING_ERROR;
>  
> +   /*
> +    * dma_fence_array objects should never contain any other
> fence
> +    * containers or otherwise we run into recursion and
> potential kernel
> +    * stack overflow on operations on the dma_fence_array.
> +    *
> +    * The correct way of handling this is to flatten out the
> array by the
> +    * caller instead.
> +    *
> +    * Enforce this here by checking that we don't create a
> dma_fence_array
> +    * with any container inside.
> +    */
> +   while (num_fences--)
> +   WARN_ON(dma_fence_is_container(fences[num_fences]));
> +
> return array;
>  }
>  EXPORT_SYMBOL(dma_fence_array_create);

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Noralf Trønnes]

Den 24.01.2022 17.08, skrev Rob Herring:
> On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes  wrote:
>>
>> Add binding for MIPI DBI compatible SPI panels.
> 
> I'm sure we already have MIPI DBI panels. What's this for?
> 

It aims to use one driver to cover all MIPI DBI panels where the
controller setup is loaded from userspace in a firmware file. The cover
letter points to the discussion where Maxime proposed this:

https://lore.kernel.org/dri-devel/20211129093946.xhp22mvdut3m67sc@houat/

Noralf.

>>
>> Signed-off-by: Noralf Trønnes 
>> ---
>>  .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
>>  1 file changed, 69 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
>> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>> new file mode 100644
>> index ..d6c8accb045c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>> @@ -0,0 +1,69 @@
>> +# SPDX-License-Identifier: GPL-2.0-only
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: MIPI DBI SPI Panels Device Tree Bindings
>> +
>> +maintainers:
>> +  - Noralf Trønnes 
>> +
>> +description:
>> +  This binding is for display panels using a MIPI DBI controller
>> +  in SPI mode.
>> +
>> +allOf:
>> +  - $ref: panel/panel-common.yaml#
>> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
>> +
>> +properties:
>> +  compatible:
>> +const: panel-mipi-dbi-spi
> 
> Does the MIPI spec define how to power on a DBI panel with regulators,
> enable/reset lines, etc. and all the timing constraints between those?
> If not, then this compatible on its own is useless. It's fine as a
> fallback if it's presence means the panel uses only standard DBI
> commands and no vendor specific commands.
> 
>> +
>> +  model:
>> +$ref: /schemas/types.yaml#/definitions/string
>> +description: The name of the display panel.
>> +
>> +  write-only:
>> +type: boolean
>> +description:
>> +  Controller is not readable (ie. MISO is not wired up).
>> +
>> +  dc-gpios:
>> +maxItems: 1
>> +description: |
>> +  Controller data/command selection (D/CX) in 4-line SPI mode.
>> +  If not set, the controller is in 3-line SPI mode.
>> +
>> +  backlight: true
>> +  reg: true
>> +  reset-gpios: true
>> +
>> +required:
>> +  - compatible
>> +  - model
>> +  - reg
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +#include 
>> +
>> +spi {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +display@0{
>> +compatible = "panel-mipi-dbi-spi";
>> +model = "sainsmart18";
>> +reg = <0>;
>> +spi-max-frequency = <4000>;
>> +dc-gpios = < 24 GPIO_ACTIVE_HIGH>;
>> +reset-gpios = < 25 GPIO_ACTIVE_HIGH>;
>> +write-only;
>> +};
>> +};
>> +
>> +...
>> --
>> 2.33.0
>>

Re: [PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER

[Carsten Haitzler]

I sent an updated patch with the Fixes:

On 1/24/22 16:13, Steven Price wrote:

On 24/01/2022 15:13, carsten.haitz...@foss.arm.com wrote:

From: Carsten Haitzler 

Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.

Signed-off-by: Carsten Haitzler 


To add the context, DRM_HDLCD used to select DRM_KMS_CMA_HELPER but that
was removed in commit 09717af7d13d ("drm: Remove
CONFIG_DRM_KMS_CMA_HELPER option"). DRM_KMS_CMA_HELPER would select
DRM_GEM_CMA_HELPER but that transitive dependency was lost and
apparently the fixup was missed in that commit.

So we need a:

Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")

and with that...

Reviewed-by: Steven Price 

Steve


---
  drivers/gpu/drm/arm/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28..6e3f1d600541 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -6,6 +6,7 @@ config DRM_HDLCD
depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST)
depends on COMMON_CLK
select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
help
  Choose this option if you have an ARM High Definition Colour LCD
  controller.

[PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER

[carsten . haitzler]

From: Carsten Haitzler 

Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.

Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")

Signed-off-by: Carsten Haitzler 
---
 drivers/gpu/drm/arm/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28..6e3f1d600541 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -6,6 +6,7 @@ config DRM_HDLCD
depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST)
depends on COMMON_CLK
select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
help
  Choose this option if you have an ARM High Definition Colour LCD
  controller.
-- 
2.30.1

Re: [PATCH] drm/arm: arm hdlcd select DRM_GEM_CMA_HELPER

[Steven Price]

On 24/01/2022 15:13, carsten.haitz...@foss.arm.com wrote:
> From: Carsten Haitzler 
> 
> Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.
> 
> Signed-off-by: Carsten Haitzler 

To add the context, DRM_HDLCD used to select DRM_KMS_CMA_HELPER but that
was removed in commit 09717af7d13d ("drm: Remove
CONFIG_DRM_KMS_CMA_HELPER option"). DRM_KMS_CMA_HELPER would select
DRM_GEM_CMA_HELPER but that transitive dependency was lost and
apparently the fixup was missed in that commit.

So we need a:

Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")

and with that...

Reviewed-by: Steven Price 

Steve

> ---
>  drivers/gpu/drm/arm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> index 58a242871b28..6e3f1d600541 100644
> --- a/drivers/gpu/drm/arm/Kconfig
> +++ b/drivers/gpu/drm/arm/Kconfig
> @@ -6,6 +6,7 @@ config DRM_HDLCD
>   depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST)
>   depends on COMMON_CLK
>   select DRM_KMS_HELPER
> + select DRM_GEM_CMA_HELPER
>   help
> Choose this option if you have an ARM High Definition Colour LCD
> controller.
> 

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Thomas Zimmermann]

Hi

Am 24.01.22 um 16:50 schrieb Geert Uytterhoeven:

On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann  wrote:

With fbdev emulation, every DRM driver is an fbdev driver too. So


Some are even without?

drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);


Well, I counted this as 'emulation' as well. There's fully 
driver-agnostic fbdev support in DRM, but some drivers still run their 
own. At some point, we want all drivers to use DRM's generic solution.


Best regards
Thomas



Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Rob Herring]

On Sun, Jan 23, 2022 at 11:25 AM Noralf Trønnes  wrote:
>
> Add binding for MIPI DBI compatible SPI panels.

I'm sure we already have MIPI DBI panels. What's this for?

>
> Signed-off-by: Noralf Trønnes 
> ---
>  .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
>  1 file changed, 69 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> new file mode 100644
> index ..d6c8accb045c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -0,0 +1,69 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MIPI DBI SPI Panels Device Tree Bindings
> +
> +maintainers:
> +  - Noralf Trønnes 
> +
> +description:
> +  This binding is for display panels using a MIPI DBI controller
> +  in SPI mode.
> +
> +allOf:
> +  - $ref: panel/panel-common.yaml#
> +  - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +properties:
> +  compatible:
> +const: panel-mipi-dbi-spi

Does the MIPI spec define how to power on a DBI panel with regulators,
enable/reset lines, etc. and all the timing constraints between those?
If not, then this compatible on its own is useless. It's fine as a
fallback if it's presence means the panel uses only standard DBI
commands and no vendor specific commands.

> +
> +  model:
> +$ref: /schemas/types.yaml#/definitions/string
> +description: The name of the display panel.
> +
> +  write-only:
> +type: boolean
> +description:
> +  Controller is not readable (ie. MISO is not wired up).
> +
> +  dc-gpios:
> +maxItems: 1
> +description: |
> +  Controller data/command selection (D/CX) in 4-line SPI mode.
> +  If not set, the controller is in 3-line SPI mode.
> +
> +  backlight: true
> +  reg: true
> +  reset-gpios: true
> +
> +required:
> +  - compatible
> +  - model
> +  - reg
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +
> +spi {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +display@0{
> +compatible = "panel-mipi-dbi-spi";
> +model = "sainsmart18";
> +reg = <0>;
> +spi-max-frequency = <4000>;
> +dc-gpios = < 24 GPIO_ACTIVE_HIGH>;
> +reset-gpios = < 25 GPIO_ACTIVE_HIGH>;
> +write-only;
> +};
> +};
> +
> +...
> --
> 2.33.0
>

Re: [PATCH V2 3/7] drm/gma: Remove calls to kmap()

[Daniel Vetter]

On Sun, Jan 23, 2022 at 05:54:05PM -0800, ira.we...@intel.com wrote:
> From: Ira Weiny 
> 
> kmap() is being deprecated and these instances are easy to convert to
> kmap_local_page().
> 
> Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper
> instead of an open coded use of kmap_local_page().
> 
> Signed-off-by: Ira Weiny 

Applied to drm-misc-next, the others should all have full time maintainers
to make sure the patches land. Pls holler if not.

Thanks, Daniel

> ---
>  drivers/gpu/drm/gma500/gma_display.c | 6 ++
>  drivers/gpu/drm/gma500/mmu.c | 8 
>  2 files changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/gma500/gma_display.c 
> b/drivers/gpu/drm/gma500/gma_display.c
> index 99da3118131a..60ba7de59139 100644
> --- a/drivers/gpu/drm/gma500/gma_display.c
> +++ b/drivers/gpu/drm/gma500/gma_display.c
> @@ -335,7 +335,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
>   struct psb_gem_object *pobj;
>   struct psb_gem_object *cursor_pobj = gma_crtc->cursor_pobj;
>   struct drm_gem_object *obj;
> - void *tmp_dst, *tmp_src;
> + void *tmp_dst;
>   int ret = 0, i, cursor_pages;
>  
>   /* If we didn't get a handle then turn the cursor off */
> @@ -400,9 +400,7 @@ int gma_crtc_cursor_set(struct drm_crtc *crtc,
>   /* Copy the cursor to cursor mem */
>   tmp_dst = dev_priv->vram_addr + cursor_pobj->offset;
>   for (i = 0; i < cursor_pages; i++) {
> - tmp_src = kmap(pobj->pages[i]);
> - memcpy(tmp_dst, tmp_src, PAGE_SIZE);
> - kunmap(pobj->pages[i]);
> + memcpy_from_page(tmp_dst, pobj->pages[i], 0, PAGE_SIZE);
>   tmp_dst += PAGE_SIZE;
>   }
>  
> diff --git a/drivers/gpu/drm/gma500/mmu.c b/drivers/gpu/drm/gma500/mmu.c
> index fe9ace2a7967..a70b01ccdf70 100644
> --- a/drivers/gpu/drm/gma500/mmu.c
> +++ b/drivers/gpu/drm/gma500/mmu.c
> @@ -184,17 +184,17 @@ struct psb_mmu_pd *psb_mmu_alloc_pd(struct 
> psb_mmu_driver *driver,
>   pd->invalid_pte = 0;
>   }
>  
> - v = kmap(pd->dummy_pt);
> + v = kmap_local_page(pd->dummy_pt);
>   for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
>   v[i] = pd->invalid_pte;
>  
> - kunmap(pd->dummy_pt);
> + kunmap_local(v);
>  
> - v = kmap(pd->p);
> + v = kmap_local_page(pd->p);
>   for (i = 0; i < (PAGE_SIZE / sizeof(uint32_t)); ++i)
>   v[i] = pd->invalid_pde;
>  
> - kunmap(pd->p);
> + kunmap_local(v);
>  
>   clear_page(kmap(pd->dummy_page));
>   kunmap(pd->dummy_page);
> -- 
> 2.31.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 1/6] dt-bindings: input: touchscreen: add bindings for focaltech, fts

[Rob Herring]

On Sun, 23 Jan 2022 17:37:27 +, Caleb Connolly wrote:
> Add devicetree bindings for the Focaltech FTS touchscreen drivers.
> 
> Signed-off-by: Caleb Connolly 
> ---
>  .../input/touchscreen/focaltech,fts.yaml  | 78 +++
>  1 file changed, 78 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: 
Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.example.dts:21.9-14
 syntax error
FATAL ERROR: Unable to parse input tree
make[1]: *** [scripts/Makefile.lib:378: 
Documentation/devicetree/bindings/input/touchscreen/focaltech,fts.example.dt.yaml]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1398: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1583161

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 1/3] dt-bindings: display: add bindings for MIPI DBI compatible SPI panels

[Rob Herring]

On Sun, 23 Jan 2022 18:25:18 +0100, Noralf Trønnes wrote:
> Add binding for MIPI DBI compatible SPI panels.
> 
> Signed-off-by: Noralf Trønnes 
> ---
>  .../display/panel/panel-mipi-dbi-spi.yaml | 69 +++
>  1 file changed, 69 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> 

My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):

yamllint warnings/errors:

dtschema/dtc warnings/errors:
schemas/display/panel/panel/panel-common.yaml: ignoring, error parsing file
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.example.dt.yaml'
schemas/display/panel/panel/panel-common.yaml: ignoring, error parsing file
Traceback (most recent call last):
  File "/usr/local/bin/dt-validate", line 170, in 
sg.check_trees(filename, testtree)
  File "/usr/local/bin/dt-validate", line 119, in check_trees
self.check_subtree(dt, subtree, False, "/", "/", filename)
  File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
  File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
  File "/usr/local/bin/dt-validate", line 110, in check_subtree
self.check_subtree(tree, value, disabled, name, fullname + name, filename)
  File "/usr/local/bin/dt-validate", line 105, in check_subtree
self.check_node(tree, subtree, disabled, nodename, fullname, filename)
  File "/usr/local/bin/dt-validate", line 49, in check_node
errors = sorted(dtschema.DTValidator(schema).iter_errors(node), key=lambda 
e: e.linecol)
  File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in 
iter_errors
for error in super().iter_errors(instance, _schema):
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
229, in iter_errors
for error in errors:
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/_validators.py", line 
362, in allOf
yield from validator.descend(instance, subschema, schema_path=index)
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
245, in descend
for error in self.evolve(schema=schema).iter_errors(instance):
  File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in 
iter_errors
for error in super().iter_errors(instance, _schema):
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
229, in iter_errors
for error in errors:
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/_validators.py", line 
298, in ref
yield from validator.descend(instance, resolved)
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
245, in descend
for error in self.evolve(schema=schema).iter_errors(instance):
  File "/usr/local/lib/python3.8/dist-packages/dtschema/lib.py", line 771, in 
iter_errors
for error in super().iter_errors(instance, _schema):
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
219, in iter_errors
scope = id_of(_schema)
  File "/usr/local/lib/python3.8/dist-packages/jsonschema/validators.py", line 
96, in _id_of
return schema.get("$id", "")
AttributeError: 'NoneType' object has no attribute 'get'
make[1]: *** [scripts/Makefile.lib:378: 
Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.example.dt.yaml]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1398: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/patch/1583159

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH 2/5] drivers/firmware: Don't mark as busy the simple-framebuffer IO resource

[Zack Rusin]

On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote:
> From: Javier Martinez Canillas 
> 
> The sysfb_create_simplefb() function requests a IO memory resource for
> the
> simple-framebuffer platform device, but it also marks it as busy which
> can
> lead to drivers requesting the same memory resource to fail.
> 
> Let's drop the IORESOURCE_BUSY flag and let drivers to request it as
> busy
> instead.
> 
> Signed-off-by: Javier Martinez Canillas 

Reviewed-by: Zack Rusin 

Re: [PATCH 1/5] fbdev: Hot-unplug firmware fb devices on forced removal

[Zack Rusin]

On Mon, 2022-01-24 at 13:36 +0100, Thomas Zimmermann wrote:
> Hot-unplug all firmware-framebuffer devices as part of removing
> them via remove_conflicting_framebuffers() et al. Releases all
> memory regions to be acquired by native drivers.
> 
> Firmware, such as EFI, install a framebuffer while posting the
> computer. After removing the firmware-framebuffer device from fbdev,
> a native driver takes over the hardware and the firmware framebuffer
> becomes invalid.
> 
> Firmware-framebuffer drivers, specifically simplefb, don't release
> their device from Linux' device hierarchy. It still owns the firmware
> framebuffer and blocks the native drivers from loading. This has been
> observed in the vmwgfx driver. [1]
> 
> Initiating a device removal (i.e., hot unplug) as part of
> remove_conflicting_framebuffers() removes the underlying device and
> returns the memory range to the system.
> 
> [1]
> https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/
> 
> Signed-off-by: Thomas Zimmermann 
> CC: sta...@vger.kernel.org # v5.11+

Looks great, thanks!

Reviewed-by: Zack Rusin 

Re: [PATCH] drm/arm: Fix hdlcd selects to add DRM_GEM_CMA_HELPER for build

[Carsten Haitzler]

Sorry - I meant disregard THIS one - following patch is right.

On 1/24/22 14:58, carsten.haitz...@foss.arm.com wrote:

From: Carsten Haitzler 

Without DRM_GEM_CMA_HELPER HDLCD won't build. This needs to be there too.

Signed-off-by: Carsten Haitzler 
---
  drivers/gpu/drm/arm/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
index 58a242871b28..9eaceb981d92 100644
--- a/drivers/gpu/drm/arm/Kconfig
+++ b/drivers/gpu/drm/arm/Kconfig
@@ -6,6 +6,7 @@ config DRM_HDLCD
depends on DRM && OF && (ARM || ARM64 || COMPILE_TEST)
depends on COMMON_CLK
select DRM_KMS_HELPER
+select DRM_GEM_CMA_HELPER
help
  Choose this option if you have an ARM High Definition Colour LCD
  controller.

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Daniel Vetter]

On Mon, Jan 24, 2022 at 04:29:34PM +0100, Helge Deller wrote:
> On 1/24/22 12:50, Javier Martinez Canillas wrote:
> > On 1/24/22 12:33, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> >>> Thoughts?
> >>
> >> I can't say I approve keeping fbdev alive, but...
> >>
> >> With fbdev emulation, every DRM driver is an fbdev driver too. So
> >> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
> >> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that
> >> absolutely need HW acceleration. That option would then protect the rsp
> >> code.
> 
> I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not
> against it either.
> For me it sounds that this is not the real direction you want to go,
> which is to prevent that any other drivers take the framebuffer before
> you take it with simpledrm or similiar.
> CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable 
> accleration part.
> With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS)
> it's an easy option for distros to disable all of the legacy drivers
> from being built & shipped.
> 
> Instead of CONFIG_FBCON_HW_SCROLLING we could also choose
> CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well...

+1 on that name, since on the lwn discussions I've also seen some noise
about resurrecting scrollback. And I guess we could do that too and then
just add it all behind that same option.
-Daniel

> > Agreed that this option would be better and allow distros
> > to disable the code that was reverted.
> 
> Yes, but IMHO it doesn't hurt either to leave it in.
> It doesn't break anything at least.
> Anyway...
> 
> Helge

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Geert Uytterhoeven]

On Mon, Jan 24, 2022 at 12:33 PM Thomas Zimmermann  wrote:
> With fbdev emulation, every DRM driver is an fbdev driver too. So

Some are even without?

drivers/gpu/drm/vmwgfx/vmwgfx_fb.c: ret = register_framebuffer(info);

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Geert Uytterhoeven]

Hi Helge,

On Mon, Jan 24, 2022 at 4:30 PM Helge Deller  wrote:
> On 1/24/22 12:50, Javier Martinez Canillas wrote:
> > On 1/24/22 12:33, Thomas Zimmermann wrote:
> >
> > [snip]
> >
> >>> Thoughts?
> >>
> >> I can't say I approve keeping fbdev alive, but...
> >>
> >> With fbdev emulation, every DRM driver is an fbdev driver too. So
> >> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
> >> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that
> >> absolutely need HW acceleration. That option would then protect the rsp
> >> code.
>
> I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not
> against it either.
> For me it sounds that this is not the real direction you want to go,
> which is to prevent that any other drivers take the framebuffer before
> you take it with simpledrm or similiar.
> CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable 
> accleration part.
> With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS)
> it's an easy option for distros to disable all of the legacy drivers
> from being built & shipped.
>
> Instead of CONFIG_FBCON_HW_SCROLLING we could also choose
> CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well...

As this is about resurrecting features indicated by the various
FBINFO_HWACCEL_* flags, what about CONFIG_FB_HWACCEL?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Intel-gfx] [PATCH] drm/i915: Lock dpt_obj around set_cache_level.

[Intel]

On 1/24/22 14:02, Maarten Lankhorst wrote:

set_cache_level may unbind the object, which will result in the below
lockdep splat:
<6> [184.578145] [IGT] kms_addfb_basic: starting subtest 
addfb25-framebuffer-vs-set-tiling
<4> [184.578220] [ cut here ]
<4> [184.578221] WARN_ON(debug_locks && 
!(lock_is_held(&(&((obj)->base.resv)->lock.base)->dep_map) != 0))
<4> [184.578237] WARNING: CPU: 6 PID: 5544 at 
drivers/gpu/drm/i915/i915_gem.c:123 i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578323] Modules linked in: vgem drm_shmem_helper snd_hda_codec_hdmi 
i915 mei_hdcp x86_pkg_temp_thermal snd_hda_intel coretemp crct10dif_pclmul 
snd_intel_dspcfg crc32_pclmul ttm snd_hda_codec ghash_clmulni_intel snd_hwdep 
drm_kms_helper snd_hda_core e1000e mei_me syscopyarea ptp snd_pcm sysfillrect mei 
pps_core sysimgblt fb_sys_fops prime_numbers intel_lpss_pci smsc75xx usbnet mii
<4> [184.578349] CPU: 6 PID: 5544 Comm: kms_addfb_basic Not tainted 
5.16.0-CI-Patchwork_22006+ #1
<4> [184.578351] Hardware name: Intel Corporation Alder Lake Client 
Platform/AlderLake-P DDR4 RVP, BIOS ADLPFWI1.R00.2422.A00.2110131104 10/13/2021
<4> [184.578352] RIP: 0010:i915_gem_object_unbind+0x4a9/0x510 [i915]
<4> [184.578424] Code: 00 be ff ff ff ff 48 8d 78 68 e8 a2 6e 2b e1 85 c0 0f 85 b1 fb 
ff ff 48 c7 c6 48 37 9e a0 48 c7 c7 d9 fc a1 a0 e8 a3 54 26 e1 <0f> 0b e9 97 fb ff ff 
31 ed 48 8b 5c 24 58 65 48 33 1c 25 28 00 00
<4> [184.578426] RSP: 0018:c900013b3b68 EFLAGS: 00010286
<4> [184.578428] RAX:  RBX: c900013b3bb0 RCX: 
0001
<4> [184.578429] RDX: 8001 RSI: 8230b42d RDI: 

<4> [184.578430] RBP: 888120e1 R08:  R09: 
c0007fff
<4> [184.578431] R10: 0001 R11: c900013b3980 R12: 
8881176ea740
<4> [184.578432] R13: 888120e1 R14:  R15: 
0001
<4> [184.578433] FS:  7f65074f5e40() GS:8f30() 
knlGS:
<4> [184.578435] CS:  0010 DS:  ES:  CR0: 80050033
<4> [184.578436] CR2: 7fff4420ede8 CR3: 00010c2f2005 CR4: 
00770ee0
<4> [184.578437] PKRU: 5554
<4> [184.578438] Call Trace:
<4> [184.578439]  
<4> [184.578440]  ? dma_resv_iter_first_unlocked+0x78/0xf0
<4> [184.578447]  intel_dpt_create+0x88/0x220 [i915]
<4> [184.578530]  intel_framebuffer_init+0x5b8/0x620 [i915]
<4> [184.578612]  intel_framebuffer_create+0x3d/0x60 [i915]
<4> [184.578691]  intel_user_framebuffer_create+0x18f/0x2c0 [i915]
<4> [184.578775]  drm_internal_framebuffer_create+0x36d/0x4c0
<4> [184.578779]  drm_mode_addfb2+0x2f/0xd0
<4> [184.578781]  ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578784]  drm_ioctl_kernel+0xac/0x140
<4> [184.578787]  drm_ioctl+0x201/0x3d0
<4> [184.578789]  ? drm_mode_addfb_ioctl+0x10/0x10
<4> [184.578796]  __x64_sys_ioctl+0x6a/0xa0
<4> [184.578800]  do_syscall_64+0x37/0xb0
<4> [184.578803]  entry_SYSCALL_64_after_hwframe+0x44/0xae
<4> [184.578805] RIP: 0033:0x7f6506736317
<4> [184.578807] Code: b3 66 90 48 8b 05 71 4b 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff 
ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 
01 c3 48 8b 0d 41 4b 2d 00 f7 d8 64 89 01 48
<4> [184.578808] RSP: 002b:7fff44211a98 EFLAGS: 0246 ORIG_RAX: 
0010
<4> [184.578810] RAX: ffda RBX: 0006 RCX: 
7f6506736317
<4> [184.578811] RDX: 7fff44211b30 RSI: c06864b8 RDI: 
0006
<4> [184.578812] RBP: 7fff44211b30 R08: 7fff44311170 R09: 

<4> [184.578813] R10: 0008 R11: 0246 R12: 
c06864b8
<4> [184.578813] R13: 0006 R14:  R15: 

<4> [184.578819]  
<4> [184.578820] irq event stamp: 47931
<4> [184.578821] hardirqs last  enabled at (47937): [] 
__up_console_sem+0x62/0x70
<4> [184.578824] hardirqs last disabled at (47942): [] 
__up_console_sem+0x47/0x70
<4> [184.578826] softirqs last  enabled at (47340): [] 
__do_softirq+0x32d/0x493
<4> [184.578828] softirqs last disabled at (47335): [] 
irq_exit_rcu+0xa6/0xe0
<4> [184.578830] ---[ end trace f17ec219f892c7d4 ]---

Fixes: 0f341974cbc2 ("drm/i915: Add i915_vma_unbind_unlocked, and take obj lock for 
i915_vma_unbind, v2.")
Signed-off-by: Maarten Lankhorst 
Testcase: kms_addfb_basic
---
  drivers/gpu/drm/i915/display/intel_dpt.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)


LGTM. Reviewed-by: Thomas Hellström 




diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c
index 63a83d5f85a1..c2f8f853db90 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -253,7 +253,11 @@ intel_dpt_create(struct intel_framebuffer *fb)
if (IS_ERR(dpt_obj))
return ERR_CAST(dpt_obj);
  
-	ret = i915_gem_object_set_cache_level(dpt_obj, I915_CACHE_NONE);

+   ret = 

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Thomas Zimmermann]

Hi

Am 24.01.22 um 16:29 schrieb Helge Deller:

On 1/24/22 12:50, Javier Martinez Canillas wrote:

On 1/24/22 12:33, Thomas Zimmermann wrote:

[snip]


Thoughts?


I can't say I approve keeping fbdev alive, but...

With fbdev emulation, every DRM driver is an fbdev driver too. So
CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that
absolutely need HW acceleration. That option would then protect the rsp
code.


I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not
against it either.
For me it sounds that this is not the real direction you want to go,
which is to prevent that any other drivers take the framebuffer before
you take it with simpledrm or similiar.
CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable 
accleration part.
With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS)
it's an easy option for distros to disable all of the legacy drivers
from being built & shipped.


These drivers have been disabled by most distros a long time ago. Those 
that still remain are the generic, soon to be replaced, ones; and 
drivers for niche architectures where no DRM-based replacement exists.


If I run DRM with fbdev emulation, HW scrolling is unused, possibly 
buggy, and I'd want to not built it if possible. I guess that's what 
most distros would want as well. That's the use case for FBCON_HW_SCROLLING.


Best regards
Thomas


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 2/2] Revert "fbcon: Disable accelerated scrolling"

[Helge Deller]

On 1/24/22 12:50, Javier Martinez Canillas wrote:
> On 1/24/22 12:33, Thomas Zimmermann wrote:
>
> [snip]
>
>>> Thoughts?
>>
>> I can't say I approve keeping fbdev alive, but...
>>
>> With fbdev emulation, every DRM driver is an fbdev driver too. So
>> CONFIG_FB_DRIVER is somewhat misleading. Better add an option like
>> CONFIG_FBCON_HW_SCROLLING and have it selected by the fbdev drivers that
>> absolutely need HW acceleration. That option would then protect the rsp
>> code.

I'm not a fan of something like CONFIG_FBCON_HW_SCROLLING, but I'm not
against it either.
For me it sounds that this is not the real direction you want to go,
which is to prevent that any other drivers take the framebuffer before
you take it with simpledrm or similiar.
CONFIG_FBCON_HW_SCROLLING IMHO just disables the (from your POV) neglectable 
accleration part.
With an option like CONFIG_FB_DRIVER (maybe better: CONFIG_FB_LEGACY_DRIVERS)
it's an easy option for distros to disable all of the legacy drivers
from being built & shipped.

Instead of CONFIG_FBCON_HW_SCROLLING we could also choose
CONFIG_FBCON_LEGACY_ACCELERATION, because it includes fillrect() as well...

> Agreed that this option would be better and allow distros
> to disable the code that was reverted.

Yes, but IMHO it doesn't hurt either to leave it in.
It doesn't break anything at least.
Anyway...

Helge

Re: [PATCH 11/11] drm/vmwgfx: remove vmw_wait_dma_fence

[Zack Rusin]

On Mon, 2022-01-24 at 14:03 +0100, Christian König wrote:
> Decomposing fence containers don't seem to make any sense here.
> 
> So just remove the function entirely and call dma_fence_wait()
> directly.
> 
> Signed-off-by: Christian König 
> Cc: VMware Graphics 
> Cc: Zack Rusin 

Looks good. That's a great cleanup.

Reviewed-by: Zack Rusin