Re: [PATCH 19/25] drm/msm/dpu: don't use unsupported blend stages

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

The atomic_check compares blending stage with DPU_STAGE_MAX (maximum
amount of blending stages supported by the driver), however we should
compare it against .max_mixer_blendstages, the maximum blend stage
supported by the mixer.

Signed-off-by: Dmitry Baryshkov 


This seems reasonable to me,

Reviewed-by: Abhinav Kumar 


---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 637d164667e9..952ff11162c0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -927,9 +927,9 @@ static int dpu_plane_atomic_check(struct drm_plane *plane,
pstate->pipe.multirect_mode = DPU_SSPP_MULTIRECT_NONE;
  
  	pstate->stage = DPU_STAGE_0 + pstate->base.normalized_zpos;

-   if (pstate->stage >= DPU_STAGE_MAX) {
+   if (pstate->stage >= pdpu->catalog->caps->max_mixer_blendstages) {
DPU_ERROR("> %d plane stages assigned\n",
-   DPU_STAGE_MAX - DPU_STAGE_0);
+   pdpu->catalog->caps->max_mixer_blendstages - 
DPU_STAGE_0);
return -EINVAL;
}
  

Re: [git pull] drm fixes for 5.18-rc7 (follow up)

[pr-tracker-bot]

The pull request you sent on Sat, 14 May 2022 08:56:01 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-14

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec7f49619d8ee13e108740c82f942cd401b989e9

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [PATCH] drm/msm/dpu: limit writeback modes according to max_linewidth

[Jessica Zhang]

On 5/13/2022 3:59 PM, Abhinav Kumar wrote:

Writeback modes were being added according to mode_config.max_width
but this is assigned to double of max_mixer_width.

For compositors/clients using a single SSPP, this will fail
the dpu_plane's atomic check as it checks for max_linewidth.

Limit writeback modes according to max_linewidth to allow
even compositors/clients which use only a single SSPP to
use writeback.

Fixes: 77b001acdcfeb ("drm/msm/dpu: add the writeback connector layer")
Reported-by: Jessica Zhang 


Tested-by: Jessica Zhang  # Trogdor (SC8170)


Signed-off-by: Abhinav Kumar 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
index 7620ffe55779..399115e4e217 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
@@ -8,8 +8,10 @@
  static int dpu_wb_conn_get_modes(struct drm_connector *connector)
  {
struct drm_device *dev = connector->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
  
-	return drm_add_modes_noedid(connector, dev->mode_config.max_width,

+   return drm_add_modes_noedid(connector, 
dpu_kms->catalog->caps->max_linewidth,
dev->mode_config.max_height);
  }
  
--

2.35.1

[PATCH] drm/msm/dpu: limit writeback modes according to max_linewidth

[Abhinav Kumar]

Writeback modes were being added according to mode_config.max_width
but this is assigned to double of max_mixer_width.

For compositors/clients using a single SSPP, this will fail
the dpu_plane's atomic check as it checks for max_linewidth.

Limit writeback modes according to max_linewidth to allow
even compositors/clients which use only a single SSPP to
use writeback.

Fixes: 77b001acdcfeb ("drm/msm/dpu: add the writeback connector layer")
Reported-by: Jessica Zhang 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
index 7620ffe55779..399115e4e217 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c
@@ -8,8 +8,10 @@
 static int dpu_wb_conn_get_modes(struct drm_connector *connector)
 {
struct drm_device *dev = connector->dev;
+   struct msm_drm_private *priv = dev->dev_private;
+   struct dpu_kms *dpu_kms = to_dpu_kms(priv->kms);
 
-   return drm_add_modes_noedid(connector, dev->mode_config.max_width,
+   return drm_add_modes_noedid(connector, 
dpu_kms->catalog->caps->max_linewidth,
dev->mode_config.max_height);
 }
 
-- 
2.35.1

[git pull] drm fixes for 5.18-rc7 (follow up)

[Dave Airlie]

Hey Linus,

Turns out I was right, some fixes hadn't made it to me yet. The vmwgfx
ones also popped up later, but all seem like bad enough things to fix.
The dma-buf, vc4 and nouveau ones are all pretty small.

The fbdev fixes are a bit more complicated, a fix to cleanup fbdev
devices properly, uncovered some use-after-free bugs in existing
drivers. Then the fix for those bugs wasn't correct. This reverts that
fix, and puts the proper fixes in place in the drivers to avoid the
use-after-frees. This has had a fair number of eyes on it at this
stage, and I'm confident enough that it puts things in the right
place, and is less dangerous than reverting our way out of the initial
change at this stage.

Let me know if you want more details, the commit msgs are quite verbose.

Dave.

drm-fixes-2022-05-14:
drm fixes for 5.18-rc7 (part two)

fbdev:
- revert NULL deref fix that turned into a use-after-free
- prevent use-after-free in fbdev
- efifb/simplefb/vesafb: fix cleanup paths to avoid use-after-frees

dma-buf:
- fix panic in stats setup

vc4:
- fix hdmi build

nouveau:
- tegra iommu present fix
- fix leak in backlight name

vmwgfx:
- Black screen due to fences using FIFO checks on SVGA3
- Random black screens on boot due to uninitialized drm_mode_fb_cmd2
- Hangs on SVGA3 due to command buffers being used with gbobjects
The following changes since commit 5005e9814698f47c5a3698fcc56c9f5e6f1d4644:

  Merge tag 'amd-drm-fixes-5.18-2022-05-11' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-05-13
10:40:56 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-14

for you to fetch changes up to eb7bac3973d209e5227d1783676362ee5a8a7127:

  Merge tag 'drm-misc-fixes-2022-05-13' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2022-05-14
08:34:07 +1000)


drm fixes for 5.18-rc7 (part two)

fbdev:
- revert NULL deref fix that turned into a use-after-free
- prevent use-after-free in fbdev
- efifb/simplefb/vesafb: fix cleanup paths to avoid use-after-frees

dma-buf:
- fix panic in stats setup

vc4:
- fix hdmi build

nouveau:
- tegra iommu present fix
- fix leak in backlight name

vmwgfx:
- Black screen due to fences using FIFO checks on SVGA3
- Random black screens on boot due to uninitialized drm_mode_fb_cmd2
- Hangs on SVGA3 due to command buffers being used with gbobjects


Charan Teja Reddy (1):
  dma-buf: call dma_buf_stats_setup after dmabuf is in valid list

Christophe JAILLET (1):
  drm/nouveau: Fix a potential theorical leak in
nouveau_get_backlight_name()

Daniel Vetter (1):
  fbdev: Prevent possible use-after-free in fb_release()

Dave Airlie (2):
  Merge tag 'vmwgfx-drm-fixes-5.18-2022-05-13' of
https://gitlab.freedesktop.org/zack/vmwgfx into drm-fixes
  Merge tag 'drm-misc-fixes-2022-05-13' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

Hui Tang (1):
  drm/vc4: hdmi: Fix build error for implicit function declaration

Javier Martinez Canillas (5):
  Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
  fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: efifb: Fix a use-after-free due early fb_info cleanup

Maarten Lankhorst (1):
  Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Robin Murphy (1):
  drm/nouveau/tegra: Stop using iommu_present()

Zack Rusin (3):
  drm/vmwgfx: Fix fencing on SVGAv3
  drm/vmwgfx: Initialize drm_mode_fb_cmd2
  drm/vmwgfx: Disable command buffers on svga3 without gbobjects

 drivers/dma-buf/dma-buf.c  |  8 +++
 drivers/gpu/drm/nouveau/nouveau_backlight.c|  9 +++
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c |  2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c| 13 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  8 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c  | 28 --
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c| 26 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c|  8 ---
 drivers/video/fbdev/core/fbmem.c   |  5 +---
 drivers/video/fbdev/core/fbsysfs.c |  4 
 drivers/video/fbdev/efifb.c|  9 ++-
 drivers/video/fbdev/simplefb.c |  8 ++-
 drivers/video/fbdev/vesafb.c   |  8 ++-
 15 files changed, 99 insertions(+), 40 deletions(-)

Re: [PATCH v2 1/3] dt-bindings: display: rockchip: make reg-names mandatory for VOP2

[Heiko Stuebner]

Hi Rob, Krzysztof,

Am Mittwoch, 11. Mai 2022, 10:21:07 CEST schrieb Sascha Hauer:
> The VOP2 driver relies on reg-names properties, but these are not
> documented. Add the missing documentation, make reg-names mandatory
> and increase minItems to 2 as always both register spaces are needed.
> 
> Signed-off-by: Sascha Hauer 

does this look ok now?

Thanks
Heiko

> ---
> 
> Notes:
> Changes since v1:
> - Drop minItems
> - Add reg-names properties to example
> 
>  .../bindings/display/rockchip/rockchip-vop2.yaml  | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml 
> b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> index 655d9b327f7d3..fba45091d9092 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop2.yaml
> @@ -22,7 +22,6 @@ properties:
>- rockchip,rk3568-vop
>  
>reg:
> -minItems: 1
>  items:
>- description:
>Must contain one entry corresponding to the base address and length
> @@ -31,6 +30,11 @@ properties:
>Can optionally contain a second entry corresponding to
>the CRTC gamma LUT address.
>  
> +  reg-names:
> +items:
> +  - const: vop
> +  - const: gamma-lut
> +
>interrupts:
>  maxItems: 1
>  description:
> @@ -86,6 +90,7 @@ properties:
>  required:
>- compatible
>- reg
> +  - reg-names
>- interrupts
>- clocks
>- clock-names
> @@ -104,6 +109,7 @@ examples:
>  vop: vop@fe04 {
>  compatible = "rockchip,rk3568-vop";
>  reg = <0x0 0xfe04 0x0 0x3000>, <0x0 0xfe044000 0x0 
> 0x1000>;
> +reg-names = "vop", "gamma-lut";
>  interrupts = ;
>  clocks = < ACLK_VOP>,
>   < HCLK_VOP>,
> 

Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

[Jordan Justen]

On 2022-05-13 05:31:00, Lionel Landwerlin wrote:
> On 02/05/2022 17:15, Ramalingam C wrote:
> > Capture the impact of memory region preference list of the objects, on
> > their memory residency and Flat-CCS capability.
> >
> > v2:
> >Fix the Flat-CCS capability of an obj with {lmem, smem} preference
> >list [Thomas]
> > v3:
> >Reworded the doc [Matt]
> >
> > Signed-off-by: Ramalingam C 
> > cc: Matthew Auld 
> > cc: Thomas Hellstrom 
> > cc: Daniel Vetter 
> > cc: Jon Bloomfield 
> > cc: Lionel Landwerlin 
> > cc: Kenneth Graunke 
> > cc: mesa-...@lists.freedesktop.org
> > cc: Jordan Justen 
> > cc: Tony Ye 
> > Reviewed-by: Matthew Auld 
> > ---
> >   include/uapi/drm/i915_drm.h | 16 
> >   1 file changed, 16 insertions(+)
> >
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index a2def7b27009..b7e1c2fe08dc 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -3443,6 +3443,22 @@ struct drm_i915_gem_create_ext {
> >* At which point we get the object handle in 
> > _i915_gem_create_ext.handle,
> >* along with the final object size in _i915_gem_create_ext.size, 
> > which
> >* should account for any rounding up, if required.
> > + *
> > + * Note that userspace has no means of knowing the current backing region
> > + * for objects where @num_regions is larger than one. The kernel will only
> > + * ensure that the priority order of the @regions array is honoured, either
> > + * when initially placing the object, or when moving memory around due to
> > + * memory pressure
> > + *
> > + * On Flat-CCS capable HW, compression is supported for the objects 
> > residing
> > + * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
> > + * memory class in @regions and migrated (by I915, due to memory
> > + * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs 
> > to
> > + * decompress the content. But I915 dosen't have the required information 
> > to
> > + * decompress the userspace compressed objects.
> > + *
> > + * So I915 supports Flat-CCS, only on the objects which can reside only on
> > + * I915_MEMORY_CLASS_DEVICE regions.
> 
> I think it's fine to assume Flat-CSS surface will always be in lmem.
> 
> I see no issue for the Anv Vulkan driver.
> 
> Maybe Nanley or Ken can speak for the Iris GL driver?
> 

Acked-by: Jordan Justen 

I think Nanley has accounted for this on iris with:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/42a865730ef72574e179b56a314f30fdccc6cba8

-Jordan

Re: [PATCH v2 3/3] drm/panel: introduce ebbg,ft8719 panel

[Linus Walleij]

On Wed, May 11, 2022 at 7:28 AM Joel Selvaraj  wrote:

> Add DRM panel driver for EBBG FT8719 6.18" 2246x1080 DSI video mode
> panel, which can be found on some Xiaomi Poco F1 phones. The panel's
> backlight is managed through QCOM WLED driver.
>
> Signed-off-by: Joel Selvaraj 

I see my review comments on v1 arrived after v2.

Nevertheless, please address my review comments on v1.

> +struct ebbg_ft8719 {
> +   struct drm_panel panel;
> +   struct mipi_dsi_device *dsi;
> +
> +   struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +
> +   struct gpio_desc *reset_gpio;
> +   bool prepared;

For example that means to drop this prepared member.

Yours,
Linus Walleij

Re: [PATCH v2 2/3] dt-bindings: display: Add bindings for EBBG FT8719

[Linus Walleij]

On Wed, May 11, 2022 at 7:28 AM Joel Selvaraj  wrote:

> Add bindings for the EBBG FT8719 6.18" 2246x1080 DSI video mode panel,
> which can be found on some Xiaomi Poco F1 phones. The backlight is
> managed through the QCOM WLED driver.
>
> Signed-off-by: Joel Selvaraj 
> ---
> Changes in v2: (Krzysztof Kozlowski's Suggestions)
>  - Specify maxItems for reg
>  - Cleanup and simplify the panel properties
>  - In example change "|+" to "|' and "dsi0" to "dsi"

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij

[PATCH v5] drm/msm/dsi: don't powerup at modeset time for parade-ps8640

[Douglas Anderson]

Commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") caused sc7180 Chromebooks that use the parade-ps8640 bridge
chip to fail to turn the display back on after it turns off.

Unfortunately, it doesn't look easy to fix the parade-ps8640 driver to
handle the new power sequence. The Linux driver has almost nothing in
it and most of the logic for this bridge chip is in black-box firmware
that the bridge chip uses.

Also unfortunately, reverting the patch will break "tc358762".

The long term solution here is probably Dave Stevenson's series [1]
that would give more flexibility. However, that is likely not a quick
fix.

For the short term, we'll look at the compatible of the next bridge in
the chain and go back to the old way for the Parade PS8640 bridge
chip. If it's found that other bridge chips also need this workaround
then we can add them to the list or consider inverting the
condition. However, the hope is that the framework will not take too
much longer to land and we won't have to add anything other than
ps8640 here.

[1] 
https://lore.kernel.org/r/cover.1646406653.git.dave.steven...@raspberrypi.com

Fixes: 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time")
Suggested-by: Rob Clark 
Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Abhinav Kumar 
---
Note that, unlike `struct device`, `struct drm_bridge` still has a
`#ifdef` around the `of_node`. The extra stub function in this patch
is to make sure that we can pass COMPILE_TEST, not because I expect
that we'll actually run into real users who are running this driver
without device tree.

Changes in v5:
- Add a comment saying that this is temporary.

Changes in v4:
- Use the compatible string of the next bridge as per Rob.

Changes in v3:
- No longer a revert; now a module parameter.

Changes in v2:
- Remove the mud from my face.

 drivers/gpu/drm/msm/dsi/dsi_manager.c | 32 ++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 50b987658b1f..7fe5eb1dd066 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,6 +34,32 @@ static struct msm_dsi_manager msm_dsim_glb;
 #define IS_SYNC_NEEDED()   (msm_dsim_glb.is_sync_needed)
 #define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id)
 
+#ifdef CONFIG_OF
+static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
+{
+   struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
+
+   /*
+* If the next bridge in the chain is the Parade ps8640 bridge chip
+* then don't power on early since it seems to violate the expectations
+* of the firmware that the bridge chip is running.
+*
+* NOTE: this is expected to be a temporary special case. It's expected
+* that we'll eventually have a framework that allows the next level
+* bridge to indicate whether it needs us to power on before it or
+* after it. When that framework is in place then we'll use it and
+* remove this special case.
+*/
+   return !(next_bridge && next_bridge->of_node &&
+of_device_is_compatible(next_bridge->of_node, 
"parade,ps8640"));
+}
+#else
+static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
+{
+   return true;
+}
+#endif
+
 static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
 {
return msm_dsim_glb.dsi[id];
@@ -389,6 +415,9 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge 
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
 
+   if (!dsi_mgr_power_on_early(bridge))
+   dsi_mgr_bridge_power_on(bridge);
+
/* Always call panel functions once, because even for dual panels,
 * there is only one drm_panel instance.
 */
@@ -570,7 +599,8 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge 
*bridge,
if (is_bonded_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
 
-   dsi_mgr_bridge_power_on(bridge);
+   if (dsi_mgr_power_on_early(bridge))
+   dsi_mgr_bridge_power_on(bridge);
 }
 
 static enum drm_mode_status dsi_mgr_bridge_mode_valid(struct drm_bridge 
*bridge,
-- 
2.36.0.550.gb090851708-goog

Re: [PATCH v2] drm/probe-helper: Default to 640x480 if no EDID

[Doug Anderson]

Hi,

On Wed, May 11, 2022 at 2:32 PM Doug Anderson  wrote:
>
> Hi,
>
> On Wed, May 11, 2022 at 12:14 AM Thomas Zimmermann  
> wrote:
> >
> > Hi
> >
> > Am 10.05.22 um 22:51 schrieb Douglas Anderson:
> > > If we're unable to read the EDID for a display because it's corrupt /
> > > bogus / invalid then we'll add a set of standard modes for the
> > > display. When userspace looks at these modes it doesn't really have a
> > > good concept for which mode to pick and it'll likely pick the highest
> > > resolution one by default. That's probably not ideal because the modes
> > > were purely guesses on the part of the Linux kernel.
> >
> > I'm skeptical. Why does the kernel do a better job than userspace here?
> > Only the graphics driver could possibly make such a decision.
> >
> > Not setting any preferred mode at least gives a clear message to userspace.
>
> OK, that's a fair point. So I tried to find out what our userspace is
> doing. I believe it's:
>
> https://source.chromium.org/chromium/chromium/src/+/main:ui/ozone/platform/drm/common/drm_util.cc;l=529
>
> Specifically this bit of code:
>
>   // If we still have no preferred mode, then use the first one since it 
> should
>   // be the best mode.
>   if (!*out_native_mode && !modes.empty())
> *out_native_mode = modes.front().get();
>
> Do you agree with what our userspace is doing here, or is it wrong?
>
> If our userspace is doing the right thing, then I guess the problem is
> the call to "drm_mode_sort(>modes);" at the end of
> drm_helper_probe_single_connector_modes(). Would you be OK with me
> _not_ sorting the modes in the "bad EDID" case? That also seems to fix
> my problem...

I've implemented the "don't mark preferred, but don't sort" as a v3.
Hopefully it looks good.

https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid

-Doug

[PATCH v3] drm/probe-helper: Make 640x480 first if no EDID

[Douglas Anderson]

If we're unable to read the EDID for a display because it's corrupt /
bogus / invalid then we'll add a set of standard modes for the
display. Since we have no true information about the connected
display, these modes are essentially guesses but better than nothing.
None of the modes returned is marked as preferred, but the modes are
currently sorted such that the higher resolution modes are listed
first.

When userspace sees these modes presented by the kernel it needs to
figure out which one to pick. At least one userspace, ChromeOS [1]
seems to use the rules:
1. Try to pick the first mode marked as preferred.
2. If no modes were marked as preferred then pick the first mode.

The rules above seem pretty reasonable, but they have unfortunate side
effect that when we have no EDID present we'll default to the highest
resolution (least likely to work) mode.

Let's change things slightly. In the case of a failed EDID read we
still won't mark anything preferred but we _won't_ sort the modes at
the end of drm_helper_probe_single_connector_modes(). The
drm_add_modes_noedid() adds 640x480 first and so by skipping the call
to drm_mode_sort() it will stay first. That will be a hint to
userspace to default to 640x480.

This change makes userspace that behaves like ChromeOS does compliant
with section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a Link
CTS. That section indicates that, at least on DP, if we have a corrupt
EDID userspace may allow other modes to be tried but should default to
640x480 in the absence of more information. Note that if
drm_add_modes_noedid() ever changes to _not_ list 640x480 first we
might need to do more here, but that seems unlikely and, in any case,
it would be caught by a future run of DP compliance testing.

Note: this change could pave the way to further improvement to
drm_helper_probe_single_connector_modes(). Specifically, in the case
of no EDID we could add additional "standard" modes that are riskier
than 1024x768 (the current max we add). Now that we're giving
userspace the hint that it should default to 640x480 perhaps it would
be OK to offer the options of the higher resolution modes just in case
they work. This further improvement is left as an exercise to the
reader.

[1] 
https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488

Signed-off-by: Douglas Anderson 
---
Note that this is the second of two related and similar-sounding but
different patches. See also ("drm/probe-helper: For DP, add 640x480 if
all other modes are bad") [2]. I'm hoping to land _both_ of the
patches since they address different issues. This patch addresses the
case of a corrupt EDID and having 640x480 be the default in the
"guessed" modes. The other patch handles the case where the EDID
_isn't_ corrupt but all the modes listed can't be made with the
existing situations. The two patches can land in either order.

Also note that I didn't carry any Tested-by / Reviewed-by tags since
the patch is now quite different (yet again for v2 to v3).

[2] 
https://lore.kernel.org/r/20220510131309.v2.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid

Changes in v3:
- Don't set preferred, just disable the sort.

Changes in v2:
- Don't modify drm_add_modes_noedid() 'cause that'll break others
- Set 640x480 as preferred in drm_helper_probe_single_connector_modes()

 drivers/gpu/drm/drm_probe_helper.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 682359512996..21dd60f30cc7 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -425,6 +425,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
bool verbose_prune = true;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
+   bool sort_list = true;
 
WARN_ON(!mutex_is_locked(>mode_config.mutex));
 
@@ -516,8 +517,16 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
count = drm_add_override_edid_modes(connector);
 
if (count == 0 && (connector->status == connector_status_connected ||
-  connector->status == connector_status_unknown))
+  connector->status == connector_status_unknown)) {
count = drm_add_modes_noedid(connector, 1024, 768);
+   /*
+* Want lower res modes, like 640x480, first. That indicates
+* to userspace that these are "better" modes. Since we have
+* no EDID the modes are a guess anyway, so guess the safer
+* mode first.
+*/
+   sort_list = false;
+   }
count += drm_helper_probe_add_cmdline_mode(connector);
if (count == 0)
goto prune;
@@ -576,7 +585,8 @@ int 

Re: [PATCH 16/25] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

Since layout is not cached anymore, drop comparison against previous
layout and corresponding EAGAIN handling.

Signed-off-by: Dmitry Baryshkov 


Isnt this preventing the usermode from programming the same address again?

I thought that this check is good in that way and has nothing to do with 
the caching as such.


So its the other way around, by caching we are ensuring that we dont get 
a new frame update for just updating the same src address.



---
  drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 5 +
  2 files changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 440ae93d7bd1..5c7d739143f0 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -927,10 +927,6 @@ int dpu_format_populate_layout(
else
ret = _dpu_format_populate_addrs_linear(aspace, fb, layout);
  
-	/* check if anything changed */

-   if (!ret && !memcmp(plane_addr, layout->plane_addr, sizeof(plane_addr)))
-   ret = -EAGAIN;
-
return ret;
  }
  
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

index a521c0681af6..b2395f02f6d3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1061,10 +1061,7 @@ static void dpu_plane_sspp_atomic_update(struct 
drm_plane *plane)
memset(_cfg, 0, sizeof(struct dpu_hw_pipe_cfg));
  
  	ret = dpu_format_populate_layout(aspace, fb, );

-   if (ret == -EAGAIN) {
-   DPU_DEBUG_PLANE(pdpu, "not updating same src addrs\n");
-   update_src_addr = false;
-   } else if (ret) {
+   if (ret) {
DPU_ERROR_PLANE(pdpu, "failed to get format layout, %d\n", ret);
update_src_addr = false;
}

Re: [PATCH 15/25] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_pipe_cfg

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

Remove dpu_hw_fmt_layout instance from struct dpu_hw_fmt_layout, leaving
only src_rect and dst_rect.


I believe you meant "remove dpu_hw_fmt_layout instance from struct 
dpu_hw_pipe_cfg" ?.


Otherwise nothing wrong with the change as such, but other than making 
struct dpu_hw_pipe_cfg lighter, is there any other motivation behind 
this change?


Dont you think that dpu_hw_fmt_layout remaining to be a part of the 
struct dpu_hw_pipe_cfg is better and they are indeed tied closely.






Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 30 ++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h |  6 ++---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   |  7 ++---
  3 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 2186506e6315..df6698778b6d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -486,7 +486,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe 
*pipe,
  }
  
  static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,

-   struct dpu_hw_pipe_cfg *cfg)
+   struct dpu_hw_fmt_layout *layout)
  {
struct dpu_hw_pipe *ctx = pipe->sspp;
u32 ystride0, ystride1;
@@ -497,41 +497,41 @@ static void dpu_hw_sspp_setup_sourceaddress(struct 
dpu_sw_pipe *pipe,
return;
  
  	if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {

-   for (i = 0; i < ARRAY_SIZE(cfg->layout.plane_addr); i++)
+   for (i = 0; i < ARRAY_SIZE(layout->plane_addr); i++)
DPU_REG_WRITE(>hw, SSPP_SRC0_ADDR + idx + i * 0x4,
-   cfg->layout.plane_addr[i]);
+   layout->plane_addr[i]);
} else if (pipe->multirect_index == DPU_SSPP_RECT_0) {
DPU_REG_WRITE(>hw, SSPP_SRC0_ADDR + idx,
-   cfg->layout.plane_addr[0]);
+   layout->plane_addr[0]);
DPU_REG_WRITE(>hw, SSPP_SRC2_ADDR + idx,
-   cfg->layout.plane_addr[2]);
+   layout->plane_addr[2]);
} else {
DPU_REG_WRITE(>hw, SSPP_SRC1_ADDR + idx,
-   cfg->layout.plane_addr[0]);
+   layout->plane_addr[0]);
DPU_REG_WRITE(>hw, SSPP_SRC3_ADDR + idx,
-   cfg->layout.plane_addr[2]);
+   layout->plane_addr[2]);
}
  
  	if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {

-   ystride0 = (cfg->layout.plane_pitch[0]) |
-   (cfg->layout.plane_pitch[1] << 16);
-   ystride1 = (cfg->layout.plane_pitch[2]) |
-   (cfg->layout.plane_pitch[3] << 16);
+   ystride0 = (layout->plane_pitch[0]) |
+   (layout->plane_pitch[1] << 16);
+   ystride1 = (layout->plane_pitch[2]) |
+   (layout->plane_pitch[3] << 16);
} else {
ystride0 = DPU_REG_READ(>hw, SSPP_SRC_YSTRIDE0 + idx);
ystride1 = DPU_REG_READ(>hw, SSPP_SRC_YSTRIDE1 + idx);
  
  		if (pipe->multirect_index == DPU_SSPP_RECT_0) {

ystride0 = (ystride0 & 0x) |
-   (cfg->layout.plane_pitch[0] & 0x);
+   (layout->plane_pitch[0] & 0x);
ystride1 = (ystride1 & 0x)|
-   (cfg->layout.plane_pitch[2] & 0x);
+   (layout->plane_pitch[2] & 0x);
} else {
ystride0 = (ystride0 & 0x) |
-   ((cfg->layout.plane_pitch[0] << 16) &
+   ((layout->plane_pitch[0] << 16) &
 0x);
ystride1 = (ystride1 & 0x) |
-   ((cfg->layout.plane_pitch[2] << 16) &
+   ((layout->plane_pitch[2] << 16) &
 0x);
}
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index eee8501ea80d..93b60545ba98 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -155,13 +155,11 @@ struct dpu_hw_pixel_ext {
  
  /**

   * struct dpu_hw_pipe_cfg : Pipe description
- * @layout:format layout information for programming buffer to hardware
   * @src_rect:  src ROI, caller takes into account the different operations
   * such as decimation, flip etc to program this field
   * @dest_rect: destination ROI.
   

Re: [PATCH 14/25] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress

[Abhinav Kumar]

On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:

Move stride programming to dpu_hw_sspp_setup_sourceaddress(), so that
dpu_hw_sspp_setup_rects() programs only source and destination
rectangles.

Signed-off-by: Dmitry Baryshkov 


This separation is logically correct, but there is another codepath 
using this.


_dpu_plane_color_fill() calls pdpu->pipe_hw->ops.setup_rects.

So for solid fill, I presume that stride getting programmed is 0 as
there is no buffer to fetch from.

But with this separation, we will miss re-programming stride and it will 
remain at the old value even for solid fil cases?


You might want to add setup_sourceaddress call there? But that wont make 
sense either because for solid fill there is nothing to fetch from.


Perhaps, another op for stride programming then?



---
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 57 +++--
  1 file changed, 29 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 7194c14f87bc..2186506e6315 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -447,7 +447,7 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe 
*pipe,
  {
struct dpu_hw_pipe *ctx = pipe->sspp;
struct dpu_hw_blk_reg_map *c;
-   u32 src_size, src_xy, dst_size, dst_xy, ystride0, ystride1;
+   u32 src_size, src_xy, dst_size, dst_xy;
u32 src_size_off, src_xy_off, out_size_off, out_xy_off;
u32 idx;
  
@@ -478,44 +478,18 @@ static void dpu_hw_sspp_setup_rects(struct dpu_sw_pipe *pipe,

dst_size = (drm_rect_height(>dst_rect) << 16) |
drm_rect_width(>dst_rect);
  
-	if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {

-   ystride0 = (cfg->layout.plane_pitch[0]) |
-   (cfg->layout.plane_pitch[1] << 16);
-   ystride1 = (cfg->layout.plane_pitch[2]) |
-   (cfg->layout.plane_pitch[3] << 16);
-   } else {
-   ystride0 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE0 + idx);
-   ystride1 = DPU_REG_READ(c, SSPP_SRC_YSTRIDE1 + idx);
-
-   if (pipe->multirect_index == DPU_SSPP_RECT_0) {
-   ystride0 = (ystride0 & 0x) |
-   (cfg->layout.plane_pitch[0] & 0x);
-   ystride1 = (ystride1 & 0x)|
-   (cfg->layout.plane_pitch[2] & 0x);
-   } else {
-   ystride0 = (ystride0 & 0x) |
-   ((cfg->layout.plane_pitch[0] << 16) &
-0x);
-   ystride1 = (ystride1 & 0x) |
-   ((cfg->layout.plane_pitch[2] << 16) &
-0x);
-   }
-   }
-
/* rectangle register programming */
DPU_REG_WRITE(c, src_size_off + idx, src_size);
DPU_REG_WRITE(c, src_xy_off + idx, src_xy);
DPU_REG_WRITE(c, out_size_off + idx, dst_size);
DPU_REG_WRITE(c, out_xy_off + idx, dst_xy);
-
-   DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE0 + idx, ystride0);
-   DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
  }
  
  static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,

struct dpu_hw_pipe_cfg *cfg)
  {
struct dpu_hw_pipe *ctx = pipe->sspp;
+   u32 ystride0, ystride1;
int i;
u32 idx;
  
@@ -537,6 +511,33 @@ static void dpu_hw_sspp_setup_sourceaddress(struct dpu_sw_pipe *pipe,

DPU_REG_WRITE(>hw, SSPP_SRC3_ADDR + idx,
cfg->layout.plane_addr[2]);
}
+
+   if (pipe->multirect_index == DPU_SSPP_RECT_SOLO) {
+   ystride0 = (cfg->layout.plane_pitch[0]) |
+   (cfg->layout.plane_pitch[1] << 16);
+   ystride1 = (cfg->layout.plane_pitch[2]) |
+   (cfg->layout.plane_pitch[3] << 16);
+   } else {
+   ystride0 = DPU_REG_READ(>hw, SSPP_SRC_YSTRIDE0 + idx);
+   ystride1 = DPU_REG_READ(>hw, SSPP_SRC_YSTRIDE1 + idx);
+
+   if (pipe->multirect_index == DPU_SSPP_RECT_0) {
+   ystride0 = (ystride0 & 0x) |
+   (cfg->layout.plane_pitch[0] & 0x);
+   ystride1 = (ystride1 & 0x)|
+   (cfg->layout.plane_pitch[2] & 0x);
+   } else {
+   ystride0 = (ystride0 & 0x) |
+   ((cfg->layout.plane_pitch[0] << 16) &
+0x);
+   ystride1 = (ystride1 & 0x) |
+   ((cfg->layout.plane_pitch[2] << 16) &
+0x);
+   }
+   }
+
+   

Re: [git pull] drm fixes for 5.18-rc7

[pr-tracker-bot]

The pull request you sent on Fri, 13 May 2022 15:07:55 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-05-13

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/10b4b67ab58248636723af181734b9574be05ade

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [Intel-gfx] [PATCH] drm/i915/guc/rc: Use i915_probe_error instead of drm_error

[Teres Alexis, Alan Previn]

Nit: not sure why we use ERR_PTR for int when calling func was also returning 
an int.
Anyway, that was how the original code was, so:

Reviewed-by: Alan Previn 


On Thu, 2022-05-05 at 22:41 -0700, Vinay Belgaumkar wrote:
> To avoid false positives in error injection cases.
> 
> Signed-off-by: Vinay Belgaumkar 
> ---
>  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c 
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> index e00661fb0853..8f8dd05835c5 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c
> @@ -49,7 +49,6 @@ static int guc_action_control_gucrc(struct intel_guc *guc, 
> bool enable)
>  static int __guc_rc_control(struct intel_guc *guc, bool enable)
>  {
>   struct intel_gt *gt = guc_to_gt(guc);
> - struct drm_device *drm = _to_gt(guc)->i915->drm;
>   int ret;
>  
>   if (!intel_uc_uses_guc_rc(>uc))
> @@ -60,8 +59,8 @@ static int __guc_rc_control(struct intel_guc *guc, bool 
> enable)
>  
>   ret = guc_action_control_gucrc(guc, enable);
>   if (ret) {
> - drm_err(drm, "Failed to %s GuC RC (%pe)\n",
> - str_enable_disable(enable), ERR_PTR(ret));
> + i915_probe_error(guc_to_gt(guc)->i915, "Failed to %s GuC RC 
> (%pe)\n",
> +  str_enable_disable(enable), ERR_PTR(ret));
>   return ret;
>   }
>  
> -- 
> 2.35.1
> 

Re: [PATCH] drm/amd/display: clean up some inconsistent indenting

[Alex Deucher]

Applied.  Thanks!

Alex

On Thu, May 12, 2022 at 3:19 AM Jiapeng Chong
 wrote:
>
> Eliminate the follow smatch warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9687
> amdgpu_dm_atomic_commit_tail() warn: inconsistent indenting.
>
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index e2b57cf6506c..a92cfb055c15 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -9681,9 +9681,10 @@ static void amdgpu_dm_atomic_commit_tail(struct 
> drm_atomic_state *state)
> dm_enable_per_frame_crtc_master_sync(dc_state);
> mutex_lock(>dc_lock);
> WARN_ON(!dc_commit_state(dm->dc, dc_state));
> -   /* Allow idle optimization when vblank count is 0 for display 
> off */
> -   if (dm->active_vblank_irq_count == 0)
> -   dc_allow_idle_optimizations(dm->dc,true);
> +
> +   /* Allow idle optimization when vblank count is 0 for display 
> off */
> +   if (dm->active_vblank_irq_count == 0)
> +   dc_allow_idle_optimizations(dm->dc, true);
> mutex_unlock(>dc_lock);
> }
>
> --
> 2.20.1.7.g153144c
>

Re: [PATCH] drm/amd/display: Remove macro DC_DEFAULT_LOG_MASK

[Alex Deucher]

On Fri, May 13, 2022 at 3:20 AM pengfuyuan  wrote:
>
> [Why]
> The DC_DEFAULT_LOG_MASK macro has not been used for a long time, so remove it.

I'm sure there are lots of macros in the driver that are not used at
the moment.  Any particular reason to remove it?  DC_MIN_LOG_MASK
doesn't appear to be used at the moment either.

Alex

>
> Signed-off-by: pengfuyuan 
> ---
>  .../drm/amd/display/include/logger_types.h| 33 ---
>  1 file changed, 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h 
> b/drivers/gpu/drm/amd/display/include/logger_types.h
> index f093b49c5e6e..1b38cfc41718 100644
> --- a/drivers/gpu/drm/amd/display/include/logger_types.h
> +++ b/drivers/gpu/drm/amd/display/include/logger_types.h
> @@ -131,37 +131,4 @@ enum dc_log_type {
>  #define DC_MIN_LOG_MASK ((1 << LOG_ERROR) | \
> (1 << LOG_DETECTION_EDID_PARSER))
>
> -#define DC_DEFAULT_LOG_MASK ((1ULL << LOG_ERROR) | \
> -   (1ULL << LOG_WARNING) | \
> -   (1ULL << LOG_EVENT_MODE_SET) | \
> -   (1ULL << LOG_EVENT_DETECTION) | \
> -   (1ULL << LOG_EVENT_LINK_TRAINING) | \
> -   (1ULL << LOG_EVENT_LINK_LOSS) | \
> -   (1ULL << LOG_EVENT_UNDERFLOW) | \
> -   (1ULL << LOG_RESOURCE) | \
> -   (1ULL << LOG_FEATURE_OVERRIDE) | \
> -   (1ULL << LOG_DETECTION_EDID_PARSER) | \
> -   (1ULL << LOG_DC) | \
> -   (1ULL << LOG_HW_HOTPLUG) | \
> -   (1ULL << LOG_HW_SET_MODE) | \
> -   (1ULL << LOG_HW_RESUME_S3) | \
> -   (1ULL << LOG_HW_HPD_IRQ) | \
> -   (1ULL << LOG_SYNC) | \
> -   (1ULL << LOG_BANDWIDTH_VALIDATION) | \
> -   (1ULL << LOG_MST) | \
> -   (1ULL << LOG_DETECTION_DP_CAPS) | \
> -   (1ULL << LOG_BACKLIGHT)) | \
> -   (1ULL << LOG_I2C_AUX) | \
> -   (1ULL << LOG_IF_TRACE) | \
> -   (1ULL << LOG_HDMI_FRL) | \
> -   (1ULL << LOG_SCALER) | \
> -   (1ULL << LOG_DTN) /* | \
> -   (1ULL << LOG_DEBUG) | \
> -   (1ULL << LOG_BIOS) | \
> -   (1ULL << LOG_SURFACE) | \
> -   (1ULL << LOG_DML) | \
> -   (1ULL << LOG_HW_LINK_TRAINING) | \
> -   (1ULL << LOG_HW_AUDIO)| \
> -   (1ULL << LOG_BANDWIDTH_CALCS)*/
> -
>  #endif /* __DAL_LOGGER_TYPES_H__ */
> --
> 2.25.1
>

[GIT PULL] etnaviv-next for 5.19

[Lucas Stach]

Hi Dave, hi Daniel,

please pull the following etnaviv changes for the next merge window,
which fix address space collisions in some edge cases when userspace is
using softpin and cleans up the MMU reference handling a bit.

Regards,
Lucas

The following changes since commit f443e374ae131c168a065ea1748feac6b2e76613:

  Linux 5.17 (2022-03-20 13:14:17 -0700)

are available in the Git repository at:

  https://git.pengutronix.de/git/lst/linux etnaviv/next

for you to fetch changes up to 2829a9fcb738f742baad9d15de4c6eac84bcfd08:

  drm/etnaviv: reap idle softpin mappings when necessary (2022-04-06 10:01:51 
+0200)


Lucas Stach (4):
  drm/etnaviv: check for reaped mapping in etnaviv_iommu_unmap_gem
  drm/etnaviv: move MMU context ref/unref into map/unmap_gem
  drm/etnaviv: move flush_seq increment into etnaviv_iommu_map/unmap
  drm/etnaviv: reap idle softpin mappings when necessary

 drivers/gpu/drm/etnaviv/etnaviv_gem.c | 11 ++
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 54 ++-
 2 files changed, 55 insertions(+), 10 deletions(-)

Re: [PATCH v7 0/6] Proposal for a GPU cgroup controller

[Tejun Heo]

Hello,

On Thu, May 12, 2022 at 08:43:52PM -0700, T.J. Mercier wrote:
> > I'm actually happy I've asked this question, wasn't silly after all. I 
> > think the
> > problem here is a naming issue. What you really are monitor is "video 
> > memory",
> > which consist of a memory segment allocated to store data used to render 
> > images
> > (its not always images of course, GPU an VPU have specialized buffers for 
> > their
> > purpose).
> >
> > Whether this should be split between what is used specifically by the GPU
> > drivers, the display drivers, the VPU (CODEC and pre/post-processor) or 
> > camera
> > drivers is something that should be discussed. But in the current approach, 
> > you
> > really meant Video memory as a superset of the above. Personally, I think
> > generically (to de-Andronized your work), en-globing all video memory is
> > sufficient. What I fail to understand is how you will manage to 
> > distinguished
> > DMABuf Heap allocation (which are used outside of Android btw), from Video
> > allocation or other type of usage. I'm sure non-video usage will exist in 
> > the
> > future (think of machine learning, compute, other high bandwidth streaming
> > thingy ...)
> >
> Ok thank you for pointing out the naming issue. The naming is a
> consequence of the initial use case, but I guess it's too specific.
> What I want out of this change is that android can track dmabufs that
> come out of heaps, and drm can track gpu memory. But other drivers
> could track different resources under different names. Imagine this
> were called a buffer cgroup controller instead of a GPU cgroup
> controller. Then the use component ("video memory") isn't tied up with
> the name of the controller, but it's up to the name of the bucket the
> resource is tracked under. I think this meets the needs of the two use
> cases I'm aware of now, while leaving the door open to other future
> needs. Really the controller is just enabling abstract named buckets
> for tracking and eventually limiting a type of resource.

So, there hasn't been whole lot of discussion w/ other GPU folks and what
comes up still seems to indicate that we're still long way away from having
a meaningful gpu controller. For your use case, would it make sense to just
add dmabuf as a key to the misc controller? I'm not sure it makes sense to
push "gpu controller" forward if there's no conceptual consensus around what
resources are.

Thanks.

-- 
tejun

Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct

[Zack Rusin]

On Fri, 2022-05-13 at 16:18 +0200, Hans de Goede wrote:
> Hi,
> 
> On 5/13/22 15:25, Zack Rusin wrote:
> > 
> > 
> > > On May 13, 2022, at 3:43 AM, Thorsten Leemhuis
> > > mailto:regressi...@leemhuis.info>> wrote:
> > > 
> > > CCing airlied
> > > 
> > > On 09.05.22 14:02, Javier Martinez Canillas wrote:
> > > > On 5/9/22 13:55, Hans de Goede wrote:
> > > > [snip]
> > > > > > > 
> > > > > > > Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
> > > > > > > BugLink:
> > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556data=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0Mru05SK5d7p6fYfIbsKzIMqMeFbaC8HZ81ls47tKic%3Dreserved=0
> > > > > > >  <
> > > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556data=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=0Mru05SK5d7p6fYfIbsKzIMqMeFbaC8HZ81ls47tKic%3Dreserved=0
> > > > > > > >
> > > > > > > Signed-off-by: Hans de Goede
> > > > > > > mailto:hdego...@redhat.com>>
> > > > > > > ---
> > > > > > 
> > > > > > Zack fixed this already:
> > > > > > 
> > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D5405d25b9e8e6data=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=uST30FgZjuY%2BmXP%2F6HhNsR9AWxAEsO5itJ%2FLRdKkRNA%3Dreserved=0
> > > > > >  <
> > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D5405d25b9e8e6data=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=uST30FgZjuY%2BmXP%2F6HhNsR9AWxAEsO5itJ%2FLRdKkRNA%3Dreserved=0
> > > > > > >
> > > > > 
> > > > > I see, but it seems that this was never pushed to drm-misc-fixes,
> > > > > so this is still broken in 5.18-rc#
> > > > 
> > > > Indeed. Agreed that should be cherry-picked in -fixes as well.
> > > 
> > > Looks to me like nobody did that and this regression fix is missing in
> > 
> > No, it has been done. It’s after rc6 so the patch is in drm-misc-next-fixes
> > you can see it at:
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2Fdrivers%2Fgpu%2Fdrm%2Fvmwgfx%3Fh%3Ddrm-misc-next-fixes%26id%3D5405d25b9e8e6e0d3bdb04833d528a9bb35fe7cedata=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cq7OXf1%2FP1ImGH%2BAjTRddDxF9ZnQtait6wQX3NVpdBQ%3Dreserved=0
> >  <
> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2Fdrivers%2Fgpu%2Fdrm%2Fvmwgfx%3Fh%3Ddrm-misc-next-fixes%26id%3D5405d25b9e8e6e0d3bdb04833d528a9bb35fe7cedata=05%7C01%7Czackr%40vmware.com%7C0ad9ee5503bf481d910408da34eb8284%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880483357287655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=cq7OXf1%2FP1ImGH%2BAjTRddDxF9ZnQtait6wQX3NVpdBQ%3Dreserved=0
> > >
> 
> Erm, the after rc6 rule is for fixes for the next cycle, if we want to
> get this in this cycle (which IMHO we want) it should have been in
> drm-misc-fixes before the PR which was send to Linus today.
> 
> At this point in the cycle the best thing is probably to just
> send it directly to Linus. That or wait till 5.19, but it seems
> that for some reason (likely changes elsewhere changing the stack)
> this long standing bugs is hit 100% with 5.18, where as before
> we seemed to be lucky and not hit it.

Hmm, yes, agreed. Just in case Dave was planning to queue up something else I've
sent a pull request to Dave and Daniel for those changes. If they'll say we
should send it to Linus directly then I'll do that.

z

[pull] vmwgfx- drm-fixes-5.18

[Zack Rusin]

Hi Dave, Daniel.

Sorry for the late email, I missed some important fixes for vmwgfx.

The following changes since commit 5005e9814698f47c5a3698fcc56c9f5e6f1d4644:

  Merge tag 'amd-drm-fixes-5.18-2022-05-11' of 
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes (2022-05-13 10:40:56 
+1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/zack/vmwgfx.git 
tags/vmwgfx-drm-fixes-5.18-2022-05-13

for you to fetch changes up to 21d1d192890ced87f2f04f8f4dea92406e0b162a:

  drm/vmwgfx: Disable command buffers on svga3 without gbobjects (2022-05-13 
10:29:36 -0400)


vmwgfx fixes for:
- Black screen due to fences using FIFO checks on SVGA3
- Random black screens on boot due to uninitialized drm_mode_fb_cmd2
- Hangs on SVGA3 due to command buffers being used with gbobjects


Zack Rusin (3):
  drm/vmwgfx: Fix fencing on SVGAv3
  drm/vmwgfx: Initialize drm_mode_fb_cmd2
  drm/vmwgfx: Disable command buffers on svga3 without gbobjects

 drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c   | 13 -
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |  8 
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c|  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 28 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c   | 26 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  8 +---
 6 files changed, 61 insertions(+), 24 deletions(-)

[PATCH 5.10 04/10] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types

[Greg Kroah-Hartman]

From: Lee Jones 

commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function 
‘dal_gpio_service_create’:
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
Signed-off-by: Alex Deucher 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c   |   12 +--
 drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +--
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
@@ -53,8 +53,8 @@
  */
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx)
 {
struct gpio_service *service;
@@ -67,14 +67,14 @@ struct gpio_service *dal_gpio_service_cr
return NULL;
}
 
-   if (!dal_hw_translate_init(>translate, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_translate_init(>translate, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
 
-   if (!dal_hw_factory_init(>factory, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_factory_init(>factory, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
--- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
+++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
@@ -42,8 +42,8 @@ void dal_gpio_destroy(
struct gpio **ptr);
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx);
 
 struct gpio *dal_gpio_service_create_irq(

[PATCH 5.4 03/18] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types

[Greg Kroah-Hartman]

From: Lee Jones 

commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function 
‘dal_gpio_service_create’:
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
Signed-off-by: Alex Deucher 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c   |   12 +--
 drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +--
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
@@ -53,8 +53,8 @@
  */
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx)
 {
struct gpio_service *service;
@@ -67,14 +67,14 @@ struct gpio_service *dal_gpio_service_cr
return NULL;
}
 
-   if (!dal_hw_translate_init(>translate, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_translate_init(>translate, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
 
-   if (!dal_hw_factory_init(>factory, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_factory_init(>factory, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
--- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
+++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
@@ -42,8 +42,8 @@ void dal_gpio_destroy(
struct gpio **ptr);
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx);
 
 struct gpio *dal_gpio_service_create_irq(

[PATCH 4.19 03/15] drm/amd/display/dc/gpio/gpio_service: Pass around correct dce_{version, environment} types

[Greg Kroah-Hartman]

From: Lee Jones 

commit 353f7f3a9dd5fd2833b6462bac89ec1654c9c3aa upstream.

Fixes the following W=1 kernel build warning(s):

 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c: In function 
‘dal_gpio_service_create’:
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:71:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]
 drivers/gpu/drm/amd/amdgpu/../display/dc/gpio/gpio_service.c:77:4: warning: 
implicit conversion from ‘enum dce_version’ to ‘enum dce_environment’ 
[-Wenum-conversion]

Cc: Harry Wentland 
Cc: Leo Li 
Cc: Alex Deucher 
Cc: "Christian König" 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Lee Jones 
Signed-off-by: Alex Deucher 
Cc: Nathan Chancellor 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c   |   12 +--
 drivers/gpu/drm/amd/display/include/gpio_service_interface.h |4 +--
 2 files changed, 8 insertions(+), 8 deletions(-)

--- a/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
+++ b/drivers/gpu/drm/amd/display/dc/gpio/gpio_service.c
@@ -51,8 +51,8 @@
  */
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx)
 {
struct gpio_service *service;
@@ -66,14 +66,14 @@ struct gpio_service *dal_gpio_service_cr
return NULL;
}
 
-   if (!dal_hw_translate_init(>translate, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_translate_init(>translate, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
 
-   if (!dal_hw_factory_init(>factory, dce_version_major,
-   dce_version_minor)) {
+   if (!dal_hw_factory_init(>factory, dce_version,
+   dce_environment)) {
BREAK_TO_DEBUGGER();
goto failure_1;
}
--- a/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
+++ b/drivers/gpu/drm/amd/display/include/gpio_service_interface.h
@@ -42,8 +42,8 @@ void dal_gpio_destroy(
struct gpio **ptr);
 
 struct gpio_service *dal_gpio_service_create(
-   enum dce_version dce_version_major,
-   enum dce_version dce_version_minor,
+   enum dce_version dce_version,
+   enum dce_environment dce_environment,
struct dc_context *ctx);
 
 struct gpio *dal_gpio_service_create_irq(

Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct

[Hans de Goede]

Hi,

On 5/13/22 15:25, Zack Rusin wrote:
> 
> 
>> On May 13, 2022, at 3:43 AM, Thorsten Leemhuis > > wrote:
>>
>> CCing airlied
>>
>> On 09.05.22 14:02, Javier Martinez Canillas wrote:
>>> On 5/9/22 13:55, Hans de Goede wrote:
>>> [snip]
>>
>> Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
>> BugLink: 
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LSQP%2Bqnf4p51QsF%2B7ZkvKlB5gSx0%2FgRUsgcIPChR33g%3Dreserved=0
>>  
>> 
>> Signed-off-by: Hans de Goede > >
>> ---
>
> Zack fixed this already:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D5405d25b9e8e6data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=IMtLj94VBo3Bv8oCGmbatBmT%2F2%2B9xkIptnlPTPuHMHc%3Dreserved=0
>  
> 

 I see, but it seems that this was never pushed to drm-misc-fixes,
 so this is still broken in 5.18-rc#
>>>
>>> Indeed. Agreed that should be cherry-picked in -fixes as well.
>>
>> Looks to me like nobody did that and this regression fix is missing in
> 
> No, it has been done. It’s after rc6 so the patch is in drm-misc-next-fixes 
> you can see it at:
> https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vmwgfx?h=drm-misc-next-fixes=5405d25b9e8e6e0d3bdb04833d528a9bb35fe7ce
>  
> 

Erm, the after rc6 rule is for fixes for the next cycle, if we want to
get this in this cycle (which IMHO we want) it should have been in
drm-misc-fixes before the PR which was send to Linus today.

At this point in the cycle the best thing is probably to just
send it directly to Linus. That or wait till 5.19, but it seems
that for some reason (likely changes elsewhere changing the stack)
this long standing bugs is hit 100% with 5.18, where as before
we seemed to be lucky and not hit it.

Regards,

Hans

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Jagan Teki]

On Wed, May 11, 2022 at 9:17 PM Marek Vasut  wrote:
>
> On 5/11/22 16:58, Marek Szyprowski wrote:
> > Hi Dave,
> >
> > On 05.04.2022 13:43, Dave Stevenson wrote:
> >> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
> >>   wrote:
> >>> On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
> >>>   wrote:
>  Hi All
> >>> A gentle ping on this series. Any comments on the approach?
> >>> Thanks.
> >> I realise the merge window has just closed and therefore folks have
> >> been busy, but no responses on this after a month?
> >>
> >> Do I give up and submit a patch to document that DSI is broken and no one 
> >> cares?
> >
> > Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI
> > DSIM bridge' thread, otherwise I would miss it since I'm not involved
> > much in the DRM development.
> >
> > This resolves most of the issues in the Exynos DSI and its recent
> > conversion to the drm bridge framework. I've added the needed
> > prepare_upstream_first flags to the panels and everything works fine
> > without the bridge chain order hacks.
> >
> > Feel free to add:
> >
> > Tested-by: Marek Szyprowski 
> >
> >
> > The only remaining thing to resolve is the moment of enabling DSI host.
> > The proper sequence is:
> >
> > 1. host power on, 2. device power on, 3. host init, 4. device init, 5.
> > video enable.
>
> +CC Raphael, STM32MP1 has similar topic.
>
> > #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so
> > far done in the first host transfer call, which usually happens in
> > panel's prepare, then the #4 happens. Then video enable is done in the
> > enable callbacks.
> >
> > Jagan wants to move it to the dsi host pre_enable() to let it work with
> > DSI bridges controlled over different interfaces
> > (https://lore.kernel.org/all/20220504114021.33265-6-ja...@amarulasolutions.com/
> > ). This however fails on Exynos with DSI panels, because when dsi's
> > pre_enable is called, the dsi device is not yet powered. I've discussed
> > this with Andrzej Hajda and we came to the conclusion that this can be
> > resolved by adding the init() callback to the struct mipi_dsi_host_ops.
> > Then DSI client (next bridge or panel) would call it after powering self
> > on, but before sending any DSI commands in its pre_enable/prepare functions.
> >
> > I've prepared a prototype of such solution. This approach finally
> > resolved all the initialization issues! The bridge chain finally matches
> > the hardware, no hack are needed, and everything is controlled by the
> > DRM core. This prototype also includes the Jagan's patches, which add
> > IMX support to Samsung DSIM. If one is interested, here is my git repo
> > with all the PoC patches:
> >
> > https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework
>
> Can you CC me on the iMX DSIM discussion/patches ? It seems I was left
> out of it all, even though I work with the iMX8M DRM stuff extensively.

Sorry, this is not intentional. I added you and many others in RFC and
subsequently, I have added in the next versions whoever responds to
the previous. I will do it in the next version DSIM.

Thanks,
Jagan.

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Jagan Teki]

On Wed, May 11, 2022 at 8:28 PM Marek Szyprowski
 wrote:
>
> Hi Dave,
>
> On 05.04.2022 13:43, Dave Stevenson wrote:
> > On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
> >   wrote:
> >> On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
> >>   wrote:
> >>> Hi All
> >> A gentle ping on this series. Any comments on the approach?
> >> Thanks.
> > I realise the merge window has just closed and therefore folks have
> > been busy, but no responses on this after a month?
> >
> > Do I give up and submit a patch to document that DSI is broken and no one 
> > cares?
>
> Thanks for pointing this patchset in the 'drm: bridge: Add Samsung MIPI
> DSIM bridge' thread, otherwise I would miss it since I'm not involved
> much in the DRM development.
>
> This resolves most of the issues in the Exynos DSI and its recent
> conversion to the drm bridge framework. I've added the needed
> prepare_upstream_first flags to the panels and everything works fine
> without the bridge chain order hacks.
>
> Feel free to add:
>
> Tested-by: Marek Szyprowski 
>
>
> The only remaining thing to resolve is the moment of enabling DSI host.
> The proper sequence is:
>
> 1. host power on, 2. device power on, 3. host init, 4. device init, 5.
> video enable.
>
> #1 is done in dsi's pre_enable, #2 is done in panel's prepare. #3 was so
> far done in the first host transfer call, which usually happens in
> panel's prepare, then the #4 happens. Then video enable is done in the
> enable callbacks.
>
> Jagan wants to move it to the dsi host pre_enable() to let it work with
> DSI bridges controlled over different interfaces
> (https://lore.kernel.org/all/20220504114021.33265-6-ja...@amarulasolutions.com/
> ). This however fails on Exynos with DSI panels, because when dsi's
> pre_enable is called, the dsi device is not yet powered. I've discussed
> this with Andrzej Hajda and we came to the conclusion that this can be
> resolved by adding the init() callback to the struct mipi_dsi_host_ops.
> Then DSI client (next bridge or panel) would call it after powering self
> on, but before sending any DSI commands in its pre_enable/prepare functions.
>
> I've prepared a prototype of such solution. This approach finally
> resolved all the initialization issues! The bridge chain finally matches
> the hardware, no hack are needed, and everything is controlled by the
> DRM core. This prototype also includes the Jagan's patches, which add
> IMX support to Samsung DSIM. If one is interested, here is my git repo
> with all the PoC patches:
>
> https://github.com/mszyprow/linux/tree/v5.18-next-20220511-dsi-rework

This seems a bit confusing to me, how come a Host initialization
depends on the downstream bridge call flow?

Thanks,
Jagan.

[PATCH][next] drm/rockchip: Fix spelling mistake "aligened" -> "aligned"

[Colin Ian King]

There is a spelling mistake in a drm_err message. Fix it.

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
index 0b49fed16535..04e8e22a8640 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
@@ -1202,7 +1202,7 @@ static void vop2_plane_atomic_update(struct drm_plane 
*plane,
 */
stride = (fb->pitches[0] << 3) / bpp;
if ((stride & 0x3f) && (xmirror || rotate_90 || rotate_270))
-   drm_err(vop2->drm, "vp%d %s stride[%d] not 64 pixel 
aligened\n",
+   drm_err(vop2->drm, "vp%d %s stride[%d] not 64 pixel 
aligned\n",
vp->id, win->data->name, stride);
 
rb_swap = vop2_afbc_rb_swap(fb->format->format);
-- 
2.35.1

Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct

[Thorsten Leemhuis]

On 13.05.22 15:25, Zack Rusin wrote:
>> On May 13, 2022, at 3:43 AM, Thorsten Leemhuis
>> mailto:regressi...@leemhuis.info>> wrote:
>>
>> CCing airlied
>>
>> On 09.05.22 14:02, Javier Martinez Canillas wrote:
>>> On 5/9/22 13:55, Hans de Goede wrote:
>>> [snip]
>>
>> Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
>> BugLink:
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LSQP%2Bqnf4p51QsF%2B7ZkvKlB5gSx0%2FgRUsgcIPChR33g%3Dreserved=0
>> 
>> Signed-off-by: Hans de Goede > >
>> ---
>
> Zack fixed this already:
>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D5405d25b9e8e6data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=IMtLj94VBo3Bv8oCGmbatBmT%2F2%2B9xkIptnlPTPuHMHc%3Dreserved=0
> 

 I see, but it seems that this was never pushed to drm-misc-fixes,
 so this is still broken in 5.18-rc#
>>>
>>> Indeed. Agreed that should be cherry-picked in -fixes as well.
>>
>> Looks to me like nobody did that and this regression fix is missing in
> 
> No, it has been done. It’s after rc6 so the patch is in
> drm-misc-next-fixes you can see it at:
> https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vmwgfx?h=drm-misc-next-fixes=5405d25b9e8e6e0d3bdb04833d528a9bb35fe7ce
> 

Sorry, I try, but keeping track of subsystem specific rules and branches
is hard -- and Javier actually asked for "drm-misc-fixes".

That being said: I'd like to question the approach here, as the docs for
handling regression clearly explain that this regression fix should be
applied this cycle:
https://www.kernel.org/doc/html/latest/process/handling-regressions.html

[background: the fixes tag in the change mentions an older commit, but
it sees the problem surfaced post-5.17 cycle, as Hand pointed out at the
start of this thread where he linked here:
https://bugzilla.redhat.com/show_bug.cgi?id=2072556 ]

Sure, there are fixes that are dangerous and maybe should wait for the
next cycle, but from what I see this one doesn't look like one of those.
And if we don't fix this now many more people will run into this.

Dave, Daniel, could you please consider picking this up?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

Re: [LINUX PATCH 2/2] drm: xlnx: dsi: driver for Xilinx DSI Tx subsystem

[Laurent Pinchart]

Hi GVRao,

Thank you for the patch.

On Thu, May 12, 2022 at 07:23:13PM +0530, Venkateshwar Rao Gannavarapu wrote:
> The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
> data from AXI-4 stream interface.
> 
> It supports upto 4 lanes, optional register interface for the DPHY
> and multiple RGB color formats.
> This is a MIPI-DSI host driver and provides DSI bus for panels.
> This driver also helps to communicate with its panel using panel
> framework.
> 
> Signed-off-by: Venkateshwar Rao Gannavarapu 
> 
> ---
>  drivers/gpu/drm/xlnx/Kconfig|  14 ++
>  drivers/gpu/drm/xlnx/Makefile   |   1 +
>  drivers/gpu/drm/xlnx/xlnx_dsi.c | 456 
> 
>  3 files changed, 471 insertions(+)
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_dsi.c
> 
> diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> index c3d0826..caa632b 100644
> --- a/drivers/gpu/drm/xlnx/Kconfig
> +++ b/drivers/gpu/drm/xlnx/Kconfig
> @@ -14,3 +14,17 @@ config DRM_ZYNQMP_DPSUB
> This is a DRM/KMS driver for ZynqMP DisplayPort controller. Choose
> this option if you have a Xilinx ZynqMP SoC with DisplayPort
> subsystem.
> +
> +config DRM_XLNX_DSI
> + tristate "Xilinx DRM DSI Subsystem Driver"

I'd add

depends on ARCH_ZYNQMP || COMPILE_TEST

to avoid adding an unnecessary option on unrelated platforms.

> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL
> + select BACKLIGHT_LCD_SUPPORT
> + select BACKLIGHT_CLASS_DEVICE
> + select DRM_PANEL_SIMPLE

Could you please sort these alphabetically ?

> + help
> +   DRM bridge driver for Xilinx programmable DSI subsystem controller.
> +   choose this option if you hava a Xilinx MIPI-DSI Tx subsytem in
> +   video pipeline.
> diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
> index 51c24b7..1e97fbe 100644
> --- a/drivers/gpu/drm/xlnx/Makefile
> +++ b/drivers/gpu/drm/xlnx/Makefile
> @@ -1,2 +1,3 @@
>  zynqmp-dpsub-y := zynqmp_disp.o zynqmp_dpsub.o zynqmp_dp.o
>  obj-$(CONFIG_DRM_ZYNQMP_DPSUB) += zynqmp-dpsub.o
> +obj-$(CONFIG_DRM_XLNX_DSI) += xlnx_dsi.o
> diff --git a/drivers/gpu/drm/xlnx/xlnx_dsi.c b/drivers/gpu/drm/xlnx/xlnx_dsi.c
> new file mode 100644
> index 000..a5291f3
> --- /dev/null
> +++ b/drivers/gpu/drm/xlnx/xlnx_dsi.c
> @@ -0,0 +1,456 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *

You can drop this blank line.

> + * Xilinx FPGA MIPI DSI Tx Controller driver.
> + *
> + * Copyright (C) 2022 Xilinx, Inc.
> + *
> + * Author: Venkateshwar Rao G 
> + *

And this one too.

> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* DSI Tx IP registers */
> +#define XDSI_CCR 0x00
> +#define XDSI_CCR_COREENB BIT(0)
> +#define XDSI_CCR_SOFTRST BIT(1)
> +#define XDSI_CCR_CRREADY BIT(2)
> +#define XDSI_CCR_CMDMODE BIT(3)
> +#define XDSI_CCR_DFIFORSTBIT(4)
> +#define XDSI_CCR_CMDFIFORST  BIT(5)
> +#define XDSI_PCR 0x04
> +#define XDSI_PCR_LANES_MASK  3
> +#define XDSI_PCR_VIDEOMODE(x)(((x) & 0x3) << 3)
> +#define XDSI_PCR_VIDEOMODE_MASK  (0x3 << 3)
> +#define XDSI_PCR_VIDEOMODE_SHIFT 3
> +#define XDSI_PCR_BLLPTYPE(x) ((x) << 5)
> +#define XDSI_PCR_BLLPMODE(x) ((x) << 6)
> +#define XDSI_PCR_PIXELFORMAT_MASK(0x3 << 11)
> +#define XDSI_PCR_PIXELFORMAT_SHIFT   11
> +#define XDSI_PCR_EOTPENABLE(x)   ((x) << 13)
> +#define XDSI_GIER0x20
> +#define XDSI_ISR 0x24
> +#define XDSI_IER 0x28
> +#define XDSI_STR 0x2C
> +#define XDSI_STR_RDY_SHPKT   BIT(6)
> +#define XDSI_STR_RDY_LNGPKT  BIT(7)
> +#define XDSI_STR_DFIFO_FULL  BIT(8)
> +#define XDSI_STR_DFIFO_EMPTY BIT(9)
> +#define XDSI_STR_WAITFR_DATA BIT(10)
> +#define XDSI_STR_CMD_EXE_PGS BIT(11)
> +#define XDSI_STR_CCMD_PROC   BIT(12)
> +#define XDSI_STR_LPKT_MASK   (0x5 << 7)
> +#define XDSI_CMD 0x30
> +#define XDSI_CMD_QUEUE_PACKET(x) ((x) & GENMASK(23, 0))
> +#define XDSI_DFR 0x34
> +#define XDSI_TIME1   0x50
> +#define XDSI_TIME1_BLLP_BURST(x) ((x) & GENMASK(15, 0))
> +#define XDSI_TIME1_HSA(x)(((x) & GENMASK(15, 0)) << 16)
> +#define XDSI_TIME2   0x54
> +#define XDSI_TIME2_VACT(x)   ((x) & GENMASK(15, 0))
> +#define XDSI_TIME2_HACT(x)   (((x) & GENMASK(15, 0)) << 16)
> +#define XDSI_HACT_MULTIPLIER GENMASK(1, 0)
> +#define XDSI_TIME3   0x58
> +#define XDSI_TIME3_HFP(x)((x) & GENMASK(15, 0))
> +#define XDSI_TIME3_HBP(x)(((x) & GENMASK(15, 0)) << 16)
> +#define 

Re: [LINUX PATCH 1/2] dt-bindings: display: xlnx: Add DSI 2.0 Tx subsystem documentation

[Laurent Pinchart]

Hi GVRao,

Thank you for the patch.

On Thu, May 12, 2022 at 07:23:12PM +0530, Venkateshwar Rao Gannavarapu wrote:
> This patch adds dt binding for Xilinx DSI TX subsystem.
> 
> The Xilinx MIPI DSI (Display serial interface) Transmitter Subsystem
> implements the Mobile Industry Processor Interface (MIPI) based display
> interface. It supports the interface with the programmable logic (FPGA).
> 
> Signed-off-by: Venkateshwar Rao Gannavarapu 
> 
> ---
>  .../bindings/display/xlnx/xlnx,dsi-tx.yaml | 105 
> +
>  1 file changed, 105 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml
> 
> diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml 
> b/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml
> new file mode 100644
> index 000..8e23cf5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,dsi-tx.yaml
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/xlnx/xlnx,dsi-tx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Xilinx DSI Transmitter subsystem
> +
> +maintainers:
> +  - Venkateshwar Rao Gannavarapu 
> +
> +description: |
> +  The Xilinx DSI Transmitter Subsystem implements the Mobile Industry
> +  Processor Interface based display interface. It supports the interface
> +  with the programmable logic (FPGA).
> +
> +  For more details refer to PG238 Xilinx MIPI DSI-V2.0 Tx Subsystem.
> +
> +properties:
> +  compatible:
> +const: xlnx,dsi-tx-v2.0
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +description: List of clock specifiers

You can drop the description, clocks is always a list of clock
specifiers.

> +items:
> +  - description: AXI Lite CPU clock
> +  - description: D-phy clock

s/D-phy/D-PHY/

> +
> +  clock-names:
> +items:
> +  - const: s_axis_aclk
> +  - const: dphy_clk_200M
> +
> +  ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> +  port@0:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +description:
> +  Input port node to receive pixel data from the
> +  display controller. Exactly one endpoint must be
> +  specified.
> +properties:
> +  endpoint:
> +$ref: /schemas/graph.yaml#/properties/endpoint
> +description: sub-node describing the input from CRTC

"CRTC" is a DRM term, and DT bindings should document the hardware, not
the driver. I'd drop the endpoint description as I don't think it brings
much, and use /schemas/graph.yaml#/properties/port instead of port-base.

> +
> +  port@1:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  DSI output port node to the panel or the next bridge
> +  in the chain

Same ere about "bridge". Maybe just

description:
  Output port node to DSI device.

> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - clock-names
> +  - ports
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +dsi_tx@8002 {
> +compatible = "xlnx,dsi-tx-v2.0";
> +reg = <0x8002 0x2>;
> +clock-names = "s_axi_aclk", "dphy_clk_200M";

Wrong clock name.

> +clocks = <_clk_0>, <_clk_1>;

You need #address-cells = <1> and #size-cells = <0> here to specify an
address for the panel.

This should have been caught by the schema validation. Please see
Documentation/devicetree/bindings/writing-schema.rst for instructions on
how to validate bindings.

> +
> +panel@0 {

This will also fail to validate. You need to reference
dsi-controller.yaml. You can check the other bindings for DSI controller
for examples.

> +compatible = "auo,b101uan01";
> +reg = <0>;
> +port {
> +panel_in: endpoint {
> +remote-endpoint = <_dsi_out>;
> +};
> +};
> +};
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +#size-cells = <0>;
> +#address-cells = <1>;
> +reg = <0>;
> +mipi_dsi_in: endpoint@0 {
> +reg = <0>;

With a single endpoint you can drop the reg as well as the @0, and the
size and address cells in the parent.

> +remote-endpoint = <_disp_crtc>;
> +};
> +};
> +port@1 {
> +reg = <1>;
> +mipi_dsi_out: endpoint {
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};

-- 
Regards,

Re: Improve TTMs empty object handling

[Matthew Auld]

On Fri, 13 May 2022 at 14:03, Christian König
 wrote:
>
> Am 13.05.22 um 11:21 schrieb Matthew Auld:
> > On Mon, 9 May 2022 at 14:09, Christian König
> >  wrote:
> >> Hi everyone,
> >>
> >> re-sending this because Daniel was requesting a background why this is
> >> useful.
> >>
> >> When TTM creates a buffer this object initially should not have any
> >> backing store and there no resource object associated with it. The same
> >> can happen when a driver requests that the backing store of an object is
> >> destroyed without allocating a new one.
> >>
> >> This is really useful during initial buffer creation as well as temporary
> >> buffers and page tables which content doesn't need to be preserved when
> >> they are evicted.
> >>
> >> Currently TTM allocates dummy system resources for that because drivers
> >> couldn't handle a NULL pointer there. Audit the drivers and then clean
> >> up TTM to stop making those dummy allocations.
> >>
> >> Please review and comment,
> > Any chance we can throw this at intel-ci? Series seems to apply to drm-tip.
>
> It should be enough to CC intel-...@lists.freedesktop.org when sending
> the patch set out, right?

Yes, that should be enough.

>
> Christian.
>
> >
> >> Christian.
> >>
> >>
>

Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct

[Zack Rusin]

On May 13, 2022, at 3:43 AM, Thorsten Leemhuis 
mailto:regressi...@leemhuis.info>> wrote:

CCing airlied

On 09.05.22 14:02, Javier Martinez Canillas wrote:
On 5/9/22 13:55, Hans de Goede wrote:
[snip]

Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
BugLink: 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D2072556data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=LSQP%2Bqnf4p51QsF%2B7ZkvKlB5gSx0%2FgRUsgcIPChR33g%3Dreserved=0
Signed-off-by: Hans de Goede mailto:hdego...@redhat.com>>
---

Zack fixed this already:

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcgit.freedesktop.org%2Fdrm%2Fdrm-misc%2Fcommit%2F%3Fid%3D5405d25b9e8e6data=05%7C01%7Czackr%40vmware.com%7Ca34647a1351748917ad608da34b459a0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637880246471436744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=IMtLj94VBo3Bv8oCGmbatBmT%2F2%2B9xkIptnlPTPuHMHc%3Dreserved=0

I see, but it seems that this was never pushed to drm-misc-fixes,
so this is still broken in 5.18-rc#

Indeed. Agreed that should be cherry-picked in -fixes as well.

Looks to me like nobody did that and this regression fix is missing in

No, it has been done. It’s after rc6 so the patch is in drm-misc-next-fixes you 
can see it at:
https://cgit.freedesktop.org/drm/drm-misc/commit/drivers/gpu/drm/vmwgfx?h=drm-misc-next-fixes=5405d25b9e8e6e0d3bdb04833d528a9bb35fe7ce

z

Re: Improve TTMs empty object handling

[Christian König]

Am 13.05.22 um 11:21 schrieb Matthew Auld:

On Mon, 9 May 2022 at 14:09, Christian König
 wrote:

Hi everyone,

re-sending this because Daniel was requesting a background why this is
useful.

When TTM creates a buffer this object initially should not have any
backing store and there no resource object associated with it. The same
can happen when a driver requests that the backing store of an object is
destroyed without allocating a new one.

This is really useful during initial buffer creation as well as temporary
buffers and page tables which content doesn't need to be preserved when
they are evicted.

Currently TTM allocates dummy system resources for that because drivers
couldn't handle a NULL pointer there. Audit the drivers and then clean
up TTM to stop making those dummy allocations.

Please review and comment,

Any chance we can throw this at intel-ci? Series seems to apply to drm-tip.


It should be enough to CC intel-...@lists.freedesktop.org when sending 
the patch set out, right?


Christian.




Christian.

Re: [PATCH v3 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195

[Rob Herring]

On Thu, 12 May 2022 16:05:21 +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin" 
> 
> Add vdosys1 RDMA definition.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../display/mediatek/mediatek,mdp-rdma.yaml   | 88 +++
>  1 file changed, 88 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml:
 properties:compatible: [{'const': 'mediatek,mt8195-vdo1-rdma'}] is not of type 
'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml:
 ignoring, error in schema: properties: compatible
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.example.dts:25:18:
 fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory
   25 | #include 
  |  ^
compilation terminated.
make[1]: *** [scripts/Makefile.lib:364: 
Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.example.dtb]
 Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1401: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

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

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 v3 3/3] dt-bindings: mediatek: add ethdr definition for mt8195

[Rob Herring]

On Thu, 12 May 2022 16:05:23 +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin" 
> 
> Add vdosys1 ETHDR definition.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: Chun-Kuang Hu 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
> ---
>  .../display/mediatek/mediatek,ethdr.yaml  | 188 ++
>  1 file changed, 188 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.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:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml:
 properties:compatible: [{'const': 'mediatek,mt8195-disp-ethdr'}] is not of 
type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml:
 ignoring, error in schema: properties: compatible
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.example.dts:24:18:
 fatal error: dt-bindings/memory/mt8195-memory-port.h: No such file or directory
   24 | #include 
  |  ^
compilation terminated.
make[1]: *** [scripts/Makefile.lib:364: 
Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.example.dtb] 
Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1401: dt_binding_check] Error 2

doc reference errors (make refcheckdocs):

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

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 v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

[Lionel Landwerlin]

On 02/05/2022 17:15, Ramalingam C wrote:

Capture the impact of memory region preference list of the objects, on
their memory residency and Flat-CCS capability.

v2:
   Fix the Flat-CCS capability of an obj with {lmem, smem} preference
   list [Thomas]
v3:
   Reworded the doc [Matt]

Signed-off-by: Ramalingam C 
cc: Matthew Auld 
cc: Thomas Hellstrom 
cc: Daniel Vetter 
cc: Jon Bloomfield 
cc: Lionel Landwerlin 
cc: Kenneth Graunke 
cc: mesa-...@lists.freedesktop.org
cc: Jordan Justen 
cc: Tony Ye 
Reviewed-by: Matthew Auld 
---
  include/uapi/drm/i915_drm.h | 16 
  1 file changed, 16 insertions(+)

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a2def7b27009..b7e1c2fe08dc 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -3443,6 +3443,22 @@ struct drm_i915_gem_create_ext {
   * At which point we get the object handle in _i915_gem_create_ext.handle,
   * along with the final object size in _i915_gem_create_ext.size, which
   * should account for any rounding up, if required.
+ *
+ * Note that userspace has no means of knowing the current backing region
+ * for objects where @num_regions is larger than one. The kernel will only
+ * ensure that the priority order of the @regions array is honoured, either
+ * when initially placing the object, or when moving memory around due to
+ * memory pressure
+ *
+ * On Flat-CCS capable HW, compression is supported for the objects residing
+ * in I915_MEMORY_CLASS_DEVICE. When such objects (compressed) has other
+ * memory class in @regions and migrated (by I915, due to memory
+ * constrain) to the non I915_MEMORY_CLASS_DEVICE region, then I915 needs to
+ * decompress the content. But I915 dosen't have the required information to
+ * decompress the userspace compressed objects.
+ *
+ * So I915 supports Flat-CCS, only on the objects which can reside only on
+ * I915_MEMORY_CLASS_DEVICE regions.



I think it's fine to assume Flat-CSS surface will always be in lmem.

I see no issue for the Anv Vulkan driver.


Maybe Nanley or Ken can speak for the Iris GL driver?


-Lionel



   */
  struct drm_i915_gem_create_ext_memory_regions {
/** @base: Extension link. See struct i915_user_extension. */

Re: [PATCH] fbdev: vesafb: Allow to be built if COMPILE_TEST is enabled

[Javier Martinez Canillas]

On 5/5/22 14:04, Javier Martinez Canillas wrote:
> The driver has runtime but no build time dependency with X86, so it can
> be built for testing purposes if the COMPILE_TEST option is enabled.
> 
> This is useful to have more build coverage and make sure that the driver
> is not affected by changes that could cause build regressions.
> 
> Signed-off-by: Javier Martinez Canillas 
> ---

Pushed this to drm-misc (drm-misc-next) with Thomas a-b tag provided over IRC.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v5 3/7] fbdev: Restart conflicting fb removal loop when unregistering devices

[Javier Martinez Canillas]

On 5/11/22 13:30, Javier Martinez Canillas wrote:
> Drivers that want to remove registered conflicting framebuffers prior to
> register their own framebuffer, calls remove_conflicting_framebuffers().
> 
> This function takes the registration_lock mutex, to prevent a races when
> drivers register framebuffer devices. But if a conflicting framebuffer
> device is found, the underlaying platform device is unregistered and this
> will lead to the platform driver .remove callback to be called, which in
> turn will call to the unregister_framebuffer() that takes the same lock.
> 
> To prevent this, a struct fb_info.forced_out field was used as indication
> to unregister_framebuffer() whether the mutex has to be grabbed or not.
> 
> A cleaner solution is to drop the lock before platform_device_unregister()
> so unregister_framebuffer() can take it when called from the fbdev driver,
> and just grab the lock again after the device has been registered and do
> a removal loop restart.
> 
> Since the framebuffer devices will already be removed, the loop would just
> finish when no more conflicting framebuffers are found.
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Javier Martinez Canillas 
> Reviewed-by: Daniel Vetter 
> ---
Pushed this to drm-misc (drm-misc-next). Thanks all!

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH 1/2] drm/msm: don't free the IRQ if it was not requested

[Dmitry Baryshkov]

On 12/05/2022 04:41, Stephen Boyd wrote:

Quoting Dmitry Baryshkov (2022-05-11 18:30:55)

On 12/05/2022 04:29, Stephen Boyd wrote:

Quoting Dmitry Baryshkov (2022-05-11 18:01:31)

On Thu, 12 May 2022 at 03:54, Stephen Boyd  wrote:


Quoting Dmitry Baryshkov (2022-05-06 18:00:20)

Does this supersede commit 01013ba9bbdd ("drm/msm/disp/dpu1: avoid
clearing hw interrupts if hw_intr is null during drm uninit")? I mean
that with this patch applied kms->irq_requested makes the check in
dpu_core_irq_uninstall() irrelevant because it isn't called anymore?


Yes.



I didn't see it deleted in the second patch so is a revert going to be
sent?


No need to. They are separate checks. The older one is superseded (as it
will be never hit),  but it is still valid and useful (to protect from
the crash if this code changes again).



Ew, gross. The extra conditionals everywhere really makes it hard to
follow along.


With the second patch being dropped I'd prefer to leave both conditions 
in place.


--
With best wishes
Dmitry

Re: [PATCH v1 13/15] mm: handling Non-LRU pages returned by vm_normal_pages

[Jason Gunthorpe]

On Thu, May 12, 2022 at 05:33:44PM -0500, Sierra Guiza, Alejandro (Alex) wrote:
> 
> On 5/11/2022 1:50 PM, Jason Gunthorpe wrote:
> > On Thu, May 05, 2022 at 04:34:36PM -0500, Alex Sierra wrote:
> > 
> > > diff --git a/mm/memory.c b/mm/memory.c
> > > index 76e3af9639d9..892c4cc54dc2 100644
> > > +++ b/mm/memory.c
> > > @@ -621,6 +621,13 @@ struct page *vm_normal_page(struct vm_area_struct 
> > > *vma, unsigned long addr,
> > >   if (is_zero_pfn(pfn))
> > >   return NULL;
> > >   if (pte_devmap(pte))
> > > +/*
> > > + * NOTE: Technically this should goto check_pfn label. However, 
> > > page->_mapcount
> > > + * is never incremented for device pages that are mmap through DAX 
> > > mechanism
> > > + * using pmem driver mounted into ext4 filesystem. When these pages are 
> > > unmap,
> > > + * zap_pte_range is called and vm_normal_page return a valid page with
> > > + * page_mapcount() = 0, before page_remove_rmap is called.
> > > + */
> > >   return NULL;
> > ? Where does this series cause device coherent to be returned?
> In our case, device coherent pages could be obtained as a result of
> migration(Patches 6/7 of 15), ending up mapped in CPU page tables. Later on,
> these pages might need to be returned by get_user_pages or other callers
> through vm_normal_pages. Our approach in this series, is to handle
> device-coherent-managed pages returned by vm_normal_pages, inside each
> caller. EX. device coherent pages don’t support LRU lists, NUMA migration or
> THP.
> > 
> > Wasn't the plan to not set pte_devmap() ?
> 
> amdgpu does not set pte_devmap for our DEVICE_COHERENT pages. DEVMAP flags
> are set by drivers like virtio_fs or pmem, where MEMORY_DEVICE_FS_DAX type
> is used.
> This patch series deals with DEVICE_COHERENT pages. My understanding was,
> that the DAX code and DEVICE_GENERIC would be fixed up later by someone more
> familiar with it. Were you expecting that we'd fix the DAX usage of
> pte_devmap flags in this patch series as well?

No, I was just trying to find where the pages got inserted and
understand the comment above. I think the comment should be clarified
more like you explained:

  New uers of ZONE_DEVICE will not set pte_devmap() and will have
  refcounts incremented on their struct pages when they are inserted
  into PTEs, thus they are safe to return here. Legacy ZONE_DEVICE
  pages that set pte_devmap() do not have refcounts. 

Jason

Re: [PATCH 2/2] drm/msm: push IRQ setup into individual drivers

[Dmitry Baryshkov]

On 13/05/2022 01:54, Abhinav Kumar wrote:



On 5/6/2022 6:00 PM, Dmitry Baryshkov wrote:

Afther the commit f026e431cf86 ("drm/msm: Convert to Linux IRQ
interfaces") converted MSM DRM driver to handle IRQs on it's own (rather
than using the DRM IRQ mid-layer), there is little point in keeping
irq wrapper in the msm_drv.c which just call into individual drivers.
Push respective code into the mdp4/mdp5/dpu drivers and drop
irq_preinstall/irq_postinstall/irq msm_kms funcs.


Isnt this change causing a lot of code duplication across mdp5/dpu/mdp4?

Do you have any future plans with respect to this separation?

I am missing why this separation into respective mdp4/5/dpu is necessary 
because struct msm_kms remains a common struct in all of this so it 
remaining in msm_drv will avoid duplication.


I wanted to remove back-and-forth calls between msm core and individual 
drivers. But I agree that it comes by the cost of code duplication. 
Let's drop this patch.






Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h  | 13 +---
  .../gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 28 -
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c   |  6 +-
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h   |  7 +++
  drivers/gpu/drm/msm/disp/mdp4/mdp4_irq.c  | 30 -
  drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c  |  4 +-
  drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.h  |  4 +-
  drivers/gpu/drm/msm/disp/mdp5/mdp5_irq.c  | 30 -
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  |  4 +-
  drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h  |  4 +-
  drivers/gpu/drm/msm/msm_drv.c | 62 +++
  drivers/gpu/drm/msm/msm_kms.h |  4 +-
  12 files changed, 105 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h

index b5b6e7031fb9..c6938b1f1870 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h
@@ -8,13 +8,6 @@
  #include "dpu_kms.h"
  #include "dpu_hw_interrupts.h"
-/**
- * dpu_core_irq_preinstall - perform pre-installation of core IRQ 
handler

- * @kms:    MSM KMS handle
- * @return:    none
- */
-void dpu_core_irq_preinstall(struct msm_kms *kms);
-
  /**
   * dpu_core_irq_uninstall - uninstall core IRQ handler
   * @kms:    MSM KMS handle
@@ -23,11 +16,11 @@ void dpu_core_irq_preinstall(struct msm_kms *kms);
  void dpu_core_irq_uninstall(struct msm_kms *kms);
  /**
- * dpu_core_irq - core IRQ handler
+ * dpu_core_irq_install - install core IRQ handler
   * @kms:    MSM KMS handle
- * @return:    interrupt handling status
+ * @return:    non-zero in case of an error
   */
-irqreturn_t dpu_core_irq(struct msm_kms *kms);
+int dpu_core_irq_install(struct msm_kms *kms);
  /**
   * dpu_core_irq_read - IRQ helper function for reading IRQ status
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c

index d6498e45dc2c..fa4f99034a08 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -164,8 +164,9 @@ static void dpu_core_irq_callback_handler(struct 
dpu_kms *dpu_kms, int irq_idx)
  
dpu_kms->hw_intr->irq_tbl[irq_idx].cb(dpu_kms->hw_intr->irq_tbl[irq_idx].arg, 
irq_idx);

  }
-irqreturn_t dpu_core_irq(struct msm_kms *kms)
+static irqreturn_t dpu_irq(int irq, void *arg)
  {
+    struct msm_kms *kms = arg;
  struct dpu_kms *dpu_kms = to_dpu_kms(kms);
  struct dpu_hw_intr *intr = dpu_kms->hw_intr;
  int reg_idx;
@@ -541,7 +542,7 @@ void dpu_debugfs_core_irq_init(struct dpu_kms 
*dpu_kms,

  }
  #endif
-void dpu_core_irq_preinstall(struct msm_kms *kms)
+static void dpu_core_irq_preinstall(struct msm_kms *kms)
  {
  struct dpu_kms *dpu_kms = to_dpu_kms(kms);
  int i;
@@ -570,5 +571,28 @@ void dpu_core_irq_uninstall(struct msm_kms *kms)
  dpu_clear_irqs(dpu_kms);
  dpu_disable_all_irqs(dpu_kms);
+    if (kms->irq_requested)
+    free_irq(kms->irq, kms);
  pm_runtime_put_sync(_kms->pdev->dev);
  }
+
+int dpu_core_irq_install(struct msm_kms *kms)
+{
+    int ret;
+
+    dpu_core_irq_preinstall(kms);
+
+    ret = request_irq(kms->irq, dpu_irq, 0, "dpu", kms);
+    if (ret)
+    return ret;
+
+    kms->irq_requested = true;
+
+    ret = dpu_irq_postinstall(kms);
+    if (ret) {
+    free_irq(kms->irq, kms);
+    return ret;
+    }
+
+    return 0;
+}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c

index 2b9d931474e0..494978da7785 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -884,7 +884,7 @@ static void dpu_kms_destroy(struct msm_kms *kms)
  pm_runtime_disable(_kms->pdev->dev);
  }
-static int dpu_irq_postinstall(struct msm_kms *kms)
+int dpu_irq_postinstall(struct msm_kms *kms)
  {
  struct 

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

Hi Javier

Am 13.05.22 um 13:10 schrieb Javier Martinez Canillas:
...

We already track the memory ranges in drm aperture helpers. We'd need to
move the code to a more prominent location (e.g., )
and change fbdev to use it. Sysfb and DT code needs to insert platform
devices upon creation. We can then implement the more fancy stuff, such
as tracking native-device memory.  (And if we ever get to fix all usage
of Linux' request-mem-region, we can even move all the functionality there).



Agreed. And as mentioned, the race that these patches attempt to fix are for
the less common case when a native driver probes but either no generic driver
registered a framebuffer yet or the platform device wasn't registered yet.

But this can only happen if for example a native driver is built-in but the
generic driver is build as a module, which is not the common configuration.

What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.

So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
  


A first step would be to use DRM's aperture helpers in fbdev. That would 
be a good idea anyway, as it would simplify both. You already mentioned 
some API changes to make aperture helpers DRM-independent.


The affected fbdev drivers use platform devices, so this should be easy.

Aperture helpers have something like the registration_lock. [1] I don't 
know if we need to recreate patch 3 for this as well.


If we absolutely need some special detachment handling for fbdev, we can 
make devm_aperture_aquire() a public interface. The detach helper is 
provided by the caller.


Best regards
Thomas


[1] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L254
[2] 
https://elixir.bootlin.com/linux/v5.17.6/source/drivers/gpu/drm/drm_aperture.c#L159


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

[PATCH V3 RESEND] dma-buf: ensure unique directory name for dmabuf stats

[Charan Teja Kalla]

The dmabuf file uses get_next_ino()(through dma_buf_getfile() ->
alloc_anon_inode()) to get an inode number and uses the same as a
directory name under /sys/kernel/dmabuf/buffers/. This directory is
used to collect the dmabuf stats and it is created through
dma_buf_stats_setup(). At current, failure to create this directory
entry can make the dma_buf_export() to fail.

Now, as the get_next_ino() can definitely give a repetitive inode no
causing the directory entry creation to fail with -EEXIST. This is a
problem on the systems where dmabuf stats functionality is enabled on
the production builds can make the dma_buf_export(), though the dmabuf
memory is allocated successfully, to fail just because it couldn't
create stats entry.

This issue we are able to see on the snapdragon system within 13 days
where there already exists a directory with inode no "122602" so
dma_buf_stats_setup() failed with -EEXIST as it is trying to create
the same directory entry.

To make the dentry name as unique, use the dmabuf fs specific inode
which is based on the simple atomic variable increment. There is tmpfs
subsystem too which relies on its own inode generation rather than
relying on the get_next_ino() for the same reason of avoiding the
duplicate inodes[1].

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e809d5f0b5c912fe981dce738f3283b2010665f0

Signed-off-by: Charan Teja Kalla 
Cc:  # 5.15.x+
Reviewed-by: Greg Kroah-Hartman 
---
Changes in V3-resend:
  -- Collect all the tags and apply stable tag.

Changes in V3:
  -- Used the atomic64 variable to have dmabuf files its own inodes.
  -- Ensured no UAPI breakage as suggested by Christian.

Changes in V2:
  -- Used the atomic64_t variable to generate a unique_id to be appended to 
inode
 to have an unique directory with name  -- 
Suggested by christian
  -- Updated the ABI documentation -- Identified by Greg.
  -- Massaged the commit log.
  -- 
https://lore.kernel.org/all/1652191562-18700-1-git-send-email-quic_chara...@quicinc.com/

Changes in V1:
  -- Used the inode->i_ctime->tv_secs as an id appended to inode to create the
 unique directory with name .
  -- 
https://lore.kernel.org/all/1652178212-22383-1-git-send-email-quic_chara...@quicinc.com/

 drivers/dma-buf/dma-buf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6fc96e..0ad5039 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file)
 
 static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
 {
+   static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
struct file *file;
struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
 
@@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf 
*dmabuf, int flags)
inode->i_size = dmabuf->size;
inode_set_bytes(inode, dmabuf->size);
 
+   /*
+* The ->i_ino acquired from get_next_ino() is not unique thus
+* not suitable for using it as dentry name by dmabuf stats.
+* Override ->i_ino with the unique and dmabuffs specific
+* value.
+*/
+   inode->i_ino = atomic64_add_return(1, _inode);
file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
 flags, _buf_fops);
if (IS_ERR(file))
-- 
2.7.4

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Javier Martinez Canillas]

Hello Thomas,

Thanks for your feedback and comments.

On 5/13/22 12:48, Thomas Zimmermann wrote:
> Hi Javier,
> 
> thanks again for providing the examples. I think I now better get what 
> you're trying to solve.
>

You are welcome.
 
> First of all let's merge patch 3, as it seems unrelated.
>

Agreed. I can push it to drm-misc-next.
 
> For the other patches, I'd like to take a step back and try to solve the 
> broader problem. IIRC we talked about this briefly already.
> 

Yes, that's what we discussed on IRC some time ago.

>  From my understanding, the problem of the current code is that removal 
> of the firmware device is build around drivers (either DRM or fbdev). 
> Everything works fine if a driver is bound to the firmware device and 
> the native driver can remove it.  In other case, we have to manually 

And this is the common case, since most kernels will have some driver
that binds to a platform device registered to provide the firmware FB.

> disable sysfb and force-remove unbound firmware devices.  And the 
> patchset doesn't even cover firmware devices that come from DT nodes.
>

Indeed.
 
> But what we really want is to track resource ownership based on devices. 
> When we add a firmware device (via sysfb or DT), we immediately add it 
> to a list of firmware devices. When the native driver arrives, it can 
> remove the firmware device even if no driver has been bound.
> 
> We can also operate in the other way if the native drivers implicitly 
> reserves the framebuffer range. If sysfb would try to register a 
> firmware device in that range, he can let it fail. No more need to fully 
> disable sysfb on the first arriving native device.
> 
> We already track the memory ranges in drm aperture helpers. We'd need to 
> move the code to a more prominent location (e.g., ) 
> and change fbdev to use it. Sysfb and DT code needs to insert platform 
> devices upon creation. We can then implement the more fancy stuff, such 
> as tracking native-device memory.  (And if we ever get to fix all usage 
> of Linux' request-mem-region, we can even move all the functionality there).
>

Agreed. And as mentioned, the race that these patches attempt to fix are for
the less common case when a native driver probes but either no generic driver
registered a framebuffer yet or the platform device wasn't registered yet.

But this can only happen if for example a native driver is built-in but the
generic driver is build as a module, which is not the common configuration.

What most distros do is the opposite, to have {simple,of,efi,vesa}fb or
simpledrm built-in and the native drivers built as modules.

So there's no rush to fix this by piling more hacks on top of the ones we
already have and instead try to fix it more properly as you suggested.
 
-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [LINUX PATCH 2/2] drm: xlnx: dsi: driver for Xilinx DSI Tx subsystem

[Sam Ravnborg]

Hi Venkateshwar,

On Thu, May 12, 2022 at 07:23:13PM +0530, Venkateshwar Rao Gannavarapu wrote:
> The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
> data from AXI-4 stream interface.
> 
> It supports upto 4 lanes, optional register interface for the DPHY
> and multiple RGB color formats.
> This is a MIPI-DSI host driver and provides DSI bus for panels.
> This driver also helps to communicate with its panel using panel
> framework.

Thanks for submitting this driver. I have added a few comments in the
following that I hope you will find useful to improve the driver.

Sam

> 
> Signed-off-by: Venkateshwar Rao Gannavarapu 
> 
> ---
>  drivers/gpu/drm/xlnx/Kconfig|  14 ++
>  drivers/gpu/drm/xlnx/Makefile   |   1 +
>  drivers/gpu/drm/xlnx/xlnx_dsi.c | 456 
> 
>  3 files changed, 471 insertions(+)
>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_dsi.c
> 
> diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> index c3d0826..caa632b 100644
> --- a/drivers/gpu/drm/xlnx/Kconfig
> +++ b/drivers/gpu/drm/xlnx/Kconfig
> @@ -14,3 +14,17 @@ config DRM_ZYNQMP_DPSUB
> This is a DRM/KMS driver for ZynqMP DisplayPort controller. Choose
> this option if you have a Xilinx ZynqMP SoC with DisplayPort
> subsystem.
It would be nice to have it in some sort of alphabetic order, both in
the Kconfig file and also the Makefile.

> +
> +config DRM_XLNX_DSI
> + tristate "Xilinx DRM DSI Subsystem Driver"
> + depends on DRM && OF
> + select DRM_KMS_HELPER
> + select DRM_MIPI_DSI
> + select DRM_PANEL
> + select BACKLIGHT_LCD_SUPPORT
The BACKLIGHT_LCD_SUPPORT symbol is not relevant and can be dropped.

> + select BACKLIGHT_CLASS_DEVICE
> + select DRM_PANEL_SIMPLE
The symbol DRM_PANEL_SIMPLE is used to enable the panel_simple driver
and should not be selected here.

> + help
> +   DRM bridge driver for Xilinx programmable DSI subsystem controller.
> +   choose this option if you hava a Xilinx MIPI-DSI Tx subsytem in
> +   video pipeline.
> diff --git a/drivers/gpu/drm/xlnx/Makefile b/drivers/gpu/drm/xlnx/Makefile
> index 51c24b7..1e97fbe 100644
> --- a/drivers/gpu/drm/xlnx/Makefile
> +++ b/drivers/gpu/drm/xlnx/Makefile
> @@ -1,2 +1,3 @@
>  zynqmp-dpsub-y := zynqmp_disp.o zynqmp_dpsub.o zynqmp_dp.o
>  obj-$(CONFIG_DRM_ZYNQMP_DPSUB) += zynqmp-dpsub.o
> +obj-$(CONFIG_DRM_XLNX_DSI) += xlnx_dsi.o
> diff --git a/drivers/gpu/drm/xlnx/xlnx_dsi.c b/drivers/gpu/drm/xlnx/xlnx_dsi.c
> new file mode 100644
> index 000..a5291f3
> --- /dev/null
> +++ b/drivers/gpu/drm/xlnx/xlnx_dsi.c
> @@ -0,0 +1,456 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + *
> + * Xilinx FPGA MIPI DSI Tx Controller driver.
> + *
> + * Copyright (C) 2022 Xilinx, Inc.
> + *
> + * Author: Venkateshwar Rao G 
I noticed this is not the mail used in the s-o-b line.

> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* DSI Tx IP registers */
> +#define XDSI_CCR 0x00
> +#define XDSI_CCR_COREENB BIT(0)
> +#define XDSI_CCR_SOFTRST BIT(1)
> +#define XDSI_CCR_CRREADY BIT(2)
> +#define XDSI_CCR_CMDMODE BIT(3)
> +#define XDSI_CCR_DFIFORSTBIT(4)
> +#define XDSI_CCR_CMDFIFORST  BIT(5)
> +#define XDSI_PCR 0x04
> +#define XDSI_PCR_LANES_MASK  3
> +#define XDSI_PCR_VIDEOMODE(x)(((x) & 0x3) << 3)
> +#define XDSI_PCR_VIDEOMODE_MASK  (0x3 << 3)
GENMASK()?
Same for other XXX_MASK definitions below

> +#define XDSI_PCR_VIDEOMODE_SHIFT 3
> +#define XDSI_PCR_BLLPTYPE(x) ((x) << 5)
> +#define XDSI_PCR_BLLPMODE(x) ((x) << 6)
> +#define XDSI_PCR_PIXELFORMAT_MASK(0x3 << 11)
> +#define XDSI_PCR_PIXELFORMAT_SHIFT   11
> +#define XDSI_PCR_EOTPENABLE(x)   ((x) << 13)
> +#define XDSI_GIER0x20
> +#define XDSI_ISR 0x24
> +#define XDSI_IER 0x28
> +#define XDSI_STR 0x2C
> +#define XDSI_STR_RDY_SHPKT   BIT(6)
> +#define XDSI_STR_RDY_LNGPKT  BIT(7)
> +#define XDSI_STR_DFIFO_FULL  BIT(8)
> +#define XDSI_STR_DFIFO_EMPTY BIT(9)
> +#define XDSI_STR_WAITFR_DATA BIT(10)
> +#define XDSI_STR_CMD_EXE_PGS BIT(11)
> +#define XDSI_STR_CCMD_PROC   BIT(12)
> +#define XDSI_STR_LPKT_MASK   (0x5 << 7)
> +#define XDSI_CMD 0x30
> +#define XDSI_CMD_QUEUE_PACKET(x) ((x) & GENMASK(23, 0))
> +#define XDSI_DFR 0x34
> +#define XDSI_TIME1   0x50
> +#define XDSI_TIME1_BLLP_BURST(x) ((x) & GENMASK(15, 0))
> +#define XDSI_TIME1_HSA(x)(((x) & GENMASK(15, 0)) << 16)
> +#define XDSI_TIME2   0x54
> +#define XDSI_TIME2_VACT(x)   ((x) & GENMASK(15, 0))
> +#define 

Re: [PATCH 1/3] usb: gadget: add Aspeed ast2600 udc driver

[kernel test robot]

Hi Neal,

I love your patch! Perhaps something to improve:

[auto build test WARNING on usb/usb-testing]
[also build test WARNING on robh/for-next v5.18-rc6 next-20220513]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/Neal-Liu/add-Aspeed-udc-driver-for-ast2600/20220513-150314
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: alpha-allyesconfig 
(https://download.01.org/0day-ci/archive/20220513/202205131836.qeuysdon-...@intel.com/config)
compiler: alpha-linux-gcc (GCC) 11.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/intel-lab-lkp/linux/commit/272ae26f9fe89f60d584cf445431d0fa566eb24b
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Neal-Liu/add-Aspeed-udc-driver-for-ast2600/20220513-150314
git checkout 272ae26f9fe89f60d584cf445431d0fa566eb24b
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.3.0 make.cross W=1 
O=build_dir ARCH=alpha SHELL=/bin/bash drivers/usb/gadget/udc/

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   drivers/usb/gadget/udc/aspeed_udc.c: In function 'ast_udc_ep0_out':
>> drivers/usb/gadget/udc/aspeed_udc.c:790:13: warning: variable 'buf' set but 
>> not used [-Wunused-but-set-variable]
 790 | u8 *buf;
 | ^~~
   drivers/usb/gadget/udc/aspeed_udc.c: In function 'ast_udc_ep0_handle_setup':
>> drivers/usb/gadget/udc/aspeed_udc.c:1099:60: warning: suggest braces around 
>> empty body in an 'else' statement [-Wempty-body]
1099 | SETUP_DBG(udc, "No gadget for request !\n");
 |^
>> drivers/usb/gadget/udc/aspeed_udc.c:1034:13: warning: variable 'ep_num' set 
>> but not used [-Wunused-but-set-variable]
1034 | u16 ep_num = 0;
 | ^~


vim +/buf +790 drivers/usb/gadget/udc/aspeed_udc.c

   783  
   784  static void ast_udc_ep0_out(struct ast_udc_dev *udc)
   785  {
   786  struct device *dev = >pdev->dev;
   787  struct ast_udc_ep *ep = >ep[0];
   788  struct ast_udc_request *req;
   789  u16 rx_len;
 > 790  u8 *buf;
   791  
   792  if (list_empty(>queue))
   793  return;
   794  
   795  req = list_entry(ep->queue.next, struct ast_udc_request, queue);
   796  
   797  buf = req->req.buf;
   798  rx_len = EP0_GET_RX_LEN(ast_udc_read(udc, AST_UDC_EP0_CTRL));
   799  req->req.actual += rx_len;
   800  
   801  SETUP_DBG(udc, "req %p (%d/%d)\n", req,
   802req->req.actual, req->req.length);
   803  
   804  if ((rx_len < ep->ep.maxpacket) ||
   805  (req->req.actual == req->req.length)) {
   806  ast_udc_ep0_tx(udc);
   807  if (!ep->dir_in)
   808  ast_udc_done(ep, req, 0);
   809  
   810  } else {
   811  if (rx_len > req->req.length) {
   812  // Issue Fix
   813  dev_warn(dev, "Something wrong (%d/%d)\n",
   814   req->req.actual, req->req.length);
   815  ast_udc_ep0_tx(udc);
   816  ast_udc_done(ep, req, 0);
   817  return;
   818  }
   819  
   820  ep->dir_in = 0;
   821  
   822  /* More works */
   823  ast_udc_ep0_queue(ep, req);
   824  }
   825  }
   826  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

Re: [PATCH v5 0/7] Fix some races between sysfb device registration and drivers probe

[Thomas Zimmermann]

Hi Javier,

thanks again for providing the examples. I think I now better get what 
you're trying to solve.


First of all let's merge patch 3, as it seems unrelated.

For the other patches, I'd like to take a step back and try to solve the 
broader problem. IIRC we talked about this briefly already.


From my understanding, the problem of the current code is that removal 
of the firmware device is build around drivers (either DRM or fbdev). 
Everything works fine if a driver is bound to the firmware device and 
the native driver can remove it.  In other case, we have to manually 
disable sysfb and force-remove unbound firmware devices.  And the 
patchset doesn't even cover firmware devices that come from DT nodes.


But what we really want is to track resource ownership based on devices. 
When we add a firmware device (via sysfb or DT), we immediately add it 
to a list of firmware devices. When the native driver arrives, it can 
remove the firmware device even if no driver has been bound.


We can also operate in the other way if the native drivers implicitly 
reserves the framebuffer range. If sysfb would try to register a 
firmware device in that range, he can let it fail. No more need to fully 
disable sysfb on the first arriving native device.


We already track the memory ranges in drm aperture helpers. We'd need to 
move the code to a more prominent location (e.g., ) 
and change fbdev to use it. Sysfb and DT code needs to insert platform 
devices upon creation. We can then implement the more fancy stuff, such 
as tracking native-device memory.  (And if we ever get to fix all usage 
of Linux' request-mem-region, we can even move all the functionality there).


Best regards
Thomas


Am 11.05.22 um 13:24 schrieb Javier Martinez Canillas:

Hello,

The patches in this series contain mostly changes suggested by Daniel Vetter
Thomas Zimmermann. They aim to fix existing races between the Generic System
Framebuffer (sysfb) infrastructure and the fbdev and DRM device registration.

For example, it is currently possible for sysfb to register a platform
device after a real DRM driver was registered and requested to remove the
conflicting framebuffers. Or is possible for a simple{fb,drm} to match with
a device previously registered by sysfb, even after a real driver is present.

A symptom of this issue, was worked around with the commit fb561bf9abde
("fbdev: Prevent probing generic drivers if a FB is already registered")
but that's really a hack and should be reverted instead.

This series attempt to fix it more correctly and revert the mentioned hack.
That will also allow to make the num_registered_fb variable not visible to
drivers anymore, since that's internal to fbdev core.

Pach 1 is just a simple cleanup in preparation for later patches.

Patch 2 add a sysfb_disable() and sysfb_try_unregister() helpers to allow
disabling sysfb and attempt to unregister registered devices respectively.

Patch 3 changes how is dealt with conflicting framebuffers unregistering,
rather than having a variable to determine if a lock should be take, it
just drops the lock before unregistering the platform device.

Patch 4 changes the fbdev core to not attempt to unregister devices that
were registered by sysfb, let the same code doing the registration to also
handle the unregistration.

Patch 5 fixes the race that exists between sysfb devices registration and
fbdev framebuffer devices registration, by disabling the sysfb when a DRM
or fbdev driver requests to remove conflicting framebuffers.

Patch 6 is the revert patch that was posted by Daniel before but dropped
from his set and finally patch 7 is the one that makes num_registered_fb
private to fbmem.c, to not allow drivers to use it anymore.

The patches were tested on a rpi4 with the vc4, simpledrm and simplefb
drivers, using different combinations of built-in and as a module.

For example, having simpledrm as a module and loading it after the vc4
driver probed would not register a DRM device, which happens now without
the patches from this series.

Best regards,
Javier

Changes in v5:
- Move the sysfb_disable() call at conflicting framebuffers again to
   avoid the need of a DRIVER_FIRMWARE capability flag.
- Add Daniel Vetter's Reviewed-by tag again since reverted to the old
   patch that he already reviewed in v2.
- Drop patches that added a DRM_FIRMWARE capability and use them
   since the case those prevented could be ignored (Daniel Vetter).

Changes in v4:
- Make sysfb_disable() to also attempt to unregister a device.
- Drop call to sysfb_disable() in fbmem since is done in other places now.
- Add patch to make registered_fb[] private.
- Add patches that introduce the DRM_FIRMWARE capability and usage.

Changes in v3:
- Add Thomas Zimmermann's Reviewed-by tag to patch #1.
- Call sysfb_disable() when a DRM dev and a fbdev are registered rather
   than when conflicting framebuffers are removed (Thomas Zimmermann).
- Call sysfb_disable() when a fbdev framebuffer is 

Re: [PATCH v2 11/11] dt-bindings: display: convert Arm Komeda to DT schema

[Carsten Haitzler]

That seems sensible to me. It matches the kind of DT content I know 
works. It's certainly more detailed now.


On 5/6/22 15:05, Andre Przywara wrote:

The Arm Komeda (aka Mali-D71) is a display controller that scans out a
framebuffer and hands a signal to a digital encoder to generate a DVI
or HDMI signal. It supports up to two pipelines, each frame can be
composed of up to four layers.

Convert the existing DT binding to DT schema.

Signed-off-by: Andre Przywara 
---
  .../bindings/display/arm,komeda.txt   |  78 ---
  .../bindings/display/arm,komeda.yaml  | 130 ++
  2 files changed, 130 insertions(+), 78 deletions(-)
  delete mode 100644 Documentation/devicetree/bindings/display/arm,komeda.txt
  create mode 100644 Documentation/devicetree/bindings/display/arm,komeda.yaml

diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt 
b/Documentation/devicetree/bindings/display/arm,komeda.txt
deleted file mode 100644
index 8513695ee47fe..0
--- a/Documentation/devicetree/bindings/display/arm,komeda.txt
+++ /dev/null
@@ -1,78 +0,0 @@
-Device Tree bindings for Arm Komeda display driver
-
-Required properties:
-- compatible: Should be "arm,mali-d71"
-- reg: Physical base address and length of the registers in the system
-- interrupts: the interrupt line number of the device in the system
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: A list of clock names. It should contain:
-  - "aclk": for the main processor clock
-- #address-cells: Must be 1
-- #size-cells: Must be 0
-- iommus: configure the stream id to IOMMU, Must be configured if want to
-enable iommu in display. for how to configure this node please reference
-devicetree/bindings/iommu/arm,smmu-v3.txt,
-devicetree/bindings/iommu/iommu.txt
-
-Required properties for sub-node: pipeline@nq
-Each device contains one or two pipeline sub-nodes (at least one), each
-pipeline node should provide properties:
-- reg: Zero-indexed identifier for the pipeline
-- clocks: A list of phandle + clock-specifier pairs, one for each entry
-in 'clock-names'
-- clock-names: should contain:
-  - "pxclk": pixel clock
-
-- port: each pipeline connect to an encoder input port. The connection is
-modeled using the OF graph bindings specified in
-Documentation/devicetree/bindings/graph.txt
-
-Optional properties:
-  - memory-region: phandle to a node describing memory (see
-Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
-to be used for the framebuffer; if not present, the framebuffer may
-be located anywhere in memory.
-
-Example:
-/ {
-   ...
-
-   dp0: display@c0 {
-   #address-cells = <1>;
-   #size-cells = <0>;
-   compatible = "arm,mali-d71";
-   reg = <0xc0 0x2>;
-   interrupts = <0 168 4>;
-   clocks = <_aclk>;
-   clock-names = "aclk";
-   iommus = < 0>, < 1>, < 2>, < 3>,
-   < 4>, < 5>, < 6>, < 7>,
-   < 8>, < 9>;
-
-   dp0_pipe0: pipeline@0 {
-   clocks = <>;
-   clock-names = "pxclk";
-   reg = <0>;
-
-   port {
-   dp0_pipe0_out: endpoint {
-   remote-endpoint = <_dvi0_in>;
-   };
-   };
-   };
-
-   dp0_pipe1: pipeline@1 {
-   clocks = <>;
-   clock-names = "pxclk";
-   reg = <1>;
-
-   port {
-   dp0_pipe1_out: endpoint {
-   remote-endpoint = <_dvi1_in>;
-   };
-   };
-   };
-   };
-   ...
-};
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.yaml 
b/Documentation/devicetree/bindings/display/arm,komeda.yaml
new file mode 100644
index 0..9f4aade97f10a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/arm,komeda.yaml
@@ -0,0 +1,130 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/arm,komeda.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Arm Komeda display processor
+
+maintainers:
+  - Liviu Dudau 
+  - Andre Przywara 
+
+description:
+  The Arm Mali D71 display processor supports up to two displays with up
+  to a 4K resolution each. Each pipeline can be composed of up to four
+  layers. It is typically connected to a digital display connector like HDMI.
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - const: arm,mali-d32
+  - const: arm,mali-d71
+  - const: arm,mali-d71
+
+  reg:
+maxItems: 1
+
+  interrupts:
+ 

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Christian König]

Am 13.05.22 um 12:38 schrieb Charan Teja Kalla:

On 5/13/2022 3:59 PM, Christian König wrote:

Am 13.05.22 um 12:18 schrieb Charan Teja Kalla:

On 5/13/2022 3:41 PM, Greg KH wrote:

Reported-by: kernel test robot 

The trest robot did not say that the dmabuf stat name was being
duplicated, did it?


It reported a printk warning on V2[1]. Should we remove this on V3?

We only add the kernel test robot is report when it found the underlying
problem and not just noted some warning on an intermediate patch version.

Noted. Thanks!!

@Christian: Could you please drop this tag while merging?

Sure, I don't have much on my plate at the moment. But don't let it
become a habit.


Sure. I am also thinking If it is worth to add stable tag? Though it is
not crashing the kernel but definitely making the dma_buf_export to fail
for no reason.

If yes, I can resend the patch with all these tags.


Yeah, sure.

Christian.




Going to push it upstream through drm-misc-fixes now.

RE: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory Display-Port

[Kuo-Hsiang Chou]

Hi Thomas,

-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de] 
Sent: Friday, May 13, 2022 6:21 PM
To: Kuo-Hsiang Chou ; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory 
Display-Port


Hi

Am 13.05.22 um 11:07 schrieb Kuo-Hsiang Chou:
> 
> 
> -Original Message-
> From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
> Sent: Tuesday, May 10, 2022 6:56 PM
> To: Kuo-Hsiang Chou ; 
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED 
> proprietory Display-Port
> 
> Hi
> 
> Am 04.05.22 um 10:49 schrieb Kuo-Hsiang Chou:
>> Hi Thomas,
>>
>> Thanks for your efforts to review this patch.
>>
>> Now, I observe a change that after DP unplugged and then the system 
>> is unable to get EDID from D-sub connecting.
>>
>> The reason seems that TXs are merged into union structure in 
>> /drivers/gpu/drm/ast/ast_drv.h
>>    (a59b026419f33040d7d28b8e3b1cea681b9ce7a7
>> > 0
>> d7d28b8e3b1cea681b9ce7a7>)
> 
> I have posted a patch that enables multiple parallel outputs. See
> 
>   
>  suse.de/T/#u>
> 
> If you have the time, I'd appreciate if you could test it.
> 
> Hi Thomas,
> First, thanks for your efforts on this patch of " enables multiple parallel 
> outputs ".
> But it doesn't work. There is still NO EDID got from D-sub after DP unplugged.
> 
> Base on your patch, I am trying to find out the solution also.
> Final, thanks for your help again!

Let's try to find a solution. I might be able to come up with something if I 
have enough information.

How are these outputs connected to each each other?
1. DP and D-sub both connected: it is correct to get EDID and monitor type is 
correctly shown on display setting. Resolution is up to 1920*1200.
2. DP unplugged and only D-sub connected: Unknown Display is shown on display 
setting. Only 800*600 and 1024*768 are available for Resolution.

They are both served by the same CRTC. Can they be used at the same time?  
No, 2 different monitors are connected at same time. 
One is connected by D-sub and another is connected by DP connecting.

Are they mutually exclusive?
Yes, If DP and D-sub are all connecting, DP's EDID is first priority for 
Display setting.
When DP unplugged, EDID got from D-sub are used for Display setting.

Now, I try to add the codes of ast_vga_connector_helper_get_modes() into 
ast_astdp_connector_helper_get_modes().
The result is failed.
Anyway, I will continue to try and test the feature next Monday. 
Thanks for your great help!

Regards,
Kuo-Hsiang Chou

Best regards
Thomas

> 
> Regards,
>   Kuo-Hsiang Chou
> 
> Best regards
> Thomas
> 
>>
>> Another, do you need the ast2600 EVB to ease verification on "drm/ast" ?
>>
>> Regards,
>>
>>       Kuo-Hsiang Chou
>>
>> -Original Message-
>> From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
>> Sent: Wednesday, May 04, 2022 3:28 PM
>> To: Kuo-Hsiang Chou ; 
>> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
>> Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED 
>> proprietory Display-Port
>>
>> Hi
>>
>> Am 28.04.22 um 09:56 schrieb KuoHsiang Chou:
>>
>>> V1:
>>
>>> 1. The MCU FW controling ASPEED DP is loaded by BMC boot loader.
>>
>>> 2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP,
>>
>>>   and CRD1[5] has been asserted by BMVC boot loader.
>>
>>> 3. EDID is prioritized by DP monitor.
>>
>>> 4. DP's EDID has high priority to decide resolution supporting.
>>
>>>
>>
>>> V2:
>>
>>> Modules description:
>>
>>> 1. ASTDP (ASPEED DisplayPort) is controlled by dedicated
>>
>>>   AST-MCU (ASPEED propriatary MCU).
>>
>>> 2. MCU is looping in charged of HPD, Read EDID, Link Training with
>>
>>>   DP sink.
>>
>>> 3. ASTDP and AST-MUC reside in BMC (Baseboard Management controller)
>>
>>>   addressing-space.
>>
>>> 4. ASPEED DRM driver requests MCU to get HPD and EDID by 
>>> CR-scratched
>>
>>>   register.
>>
>>>
>>
>>> Booting sequence:
>>
>>> 1. Check if TX is ASTDP    //
>>> ast_dp_launch()
>>
>>> 2. Check if DP-MCU FW has loaded
>>> // ast_dp_launch()
>>
>>> 3. Read EDID    //
>>> ast_dp_read_edid()
>>
>>> 4. Resolution switch //
>>> ast_dp_SetOutput()
>>
>>>
>>
>>> V3:
>>
>>> 1. Remove unneeded semicolon.
>>
>>> 2. Apply to git://anongit.freedesktop.org/drm/drm, instead of
>>
>>>   git://anongit.freedesktop.org/drm/drm-misc
>>
>>> 3. Resolve auto build test WARNINGs on V1 patch.
>>
>>>
>>
>>> V4:
>>
>>> 1. Sync code-base with kernel 5.17_rc6 2. Remove the define of
>>
>>> DPControlPower, because DP chips need to be
>>
>>>   powered on to be used.
>>
>>> 3. Remove the switches of 

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Charan Teja Kalla]

On 5/13/2022 3:59 PM, Christian König wrote:
> Am 13.05.22 um 12:18 schrieb Charan Teja Kalla:
>> On 5/13/2022 3:41 PM, Greg KH wrote:
 Reported-by: kernel test robot 
>>> The trest robot did not say that the dmabuf stat name was being
>>> duplicated, did it?
>>>
>> It reported a printk warning on V2[1]. Should we remove this on V3?
> 
> We only add the kernel test robot is report when it found the underlying
> problem and not just noted some warning on an intermediate patch version.

Noted. Thanks!!
> 
>> @Christian: Could you please drop this tag while merging?
> 
> Sure, I don't have much on my plate at the moment. But don't let it
> become a habit.
> 

Sure. I am also thinking If it is worth to add stable tag? Though it is
not crashing the kernel but definitely making the dma_buf_export to fail
for no reason.

If yes, I can resend the patch with all these tags.

> Going to push it upstream through drm-misc-fixes now.

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Christian König]

Am 13.05.22 um 12:18 schrieb Charan Teja Kalla:

On 5/13/2022 3:41 PM, Greg KH wrote:

Reported-by: kernel test robot 

The trest robot did not say that the dmabuf stat name was being
duplicated, did it?


It reported a printk warning on V2[1]. Should we remove this on V3?


We only add the kernel test robot is report when it found the underlying 
problem and not just noted some warning on an intermediate patch version.



@Christian: Could you please drop this tag while merging?


Sure, I don't have much on my plate at the moment. But don't let it 
become a habit.


Going to push it upstream through drm-misc-fixes now.

Regards,
Christian.



[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F202205110511.E0d8TXXC-lkp%40intel.com%2Fdata=05%7C01%7Cchristian.koenig%40amd.com%7C00e38dfb74fb4fe48b8408da34c9ee77%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637880339170888363%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=yH%2FBg2Fjq2ohEFKLgw2CcYEeHiUfgPLlsJaRnt9cKLo%3Dreserved=0



diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6fc96e..0ad5039 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file)
  
  static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)

  {
+   static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
struct file *file;
struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
  
@@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)

inode->i_size = dmabuf->size;
inode_set_bytes(inode, dmabuf->size);
  
+	/*

+* The ->i_ino acquired from get_next_ino() is not unique thus
+* not suitable for using it as dentry name by dmabuf stats.
+* Override ->i_ino with the unique and dmabuffs specific
+* value.
+*/
+   inode->i_ino = atomic64_add_return(1, _inode);
file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
 flags, _buf_fops);
if (IS_ERR(file))
--
2.7.4


Reviewed-by: Greg Kroah-Hartman 

Thanks for the ACK.

--Charan

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Greg KH]

On Fri, May 13, 2022 at 03:48:23PM +0530, Charan Teja Kalla wrote:
> 
> On 5/13/2022 3:41 PM, Greg KH wrote:
> >> Reported-by: kernel test robot 
> > The trest robot did not say that the dmabuf stat name was being
> > duplicated, did it?
> >
> 
> It reported a printk warning on V2[1]. Should we remove this on V3?

Yes, that's different.

> @Christian: Could you please drop this tag while merging?
> 
> [1] https://lore.kernel.org/all/202205110511.e0d8txxc-...@intel.com/

Never ask a maintainer to hand-edit a patch, it increases their workload
:(

thanks,

greg k-h

Re: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory Display-Port

[Thomas Zimmermann]

Hi

Am 13.05.22 um 11:07 schrieb Kuo-Hsiang Chou:



-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Tuesday, May 10, 2022 6:56 PM
To: Kuo-Hsiang Chou ; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory 
Display-Port

Hi

Am 04.05.22 um 10:49 schrieb Kuo-Hsiang Chou:

Hi Thomas,

Thanks for your efforts to review this patch.

Now, I observe a change that after DP unplugged and then the system is
unable to get EDID from D-sub connecting.

The reason seems that TXs are merged into union structure in
/drivers/gpu/drm/ast/ast_drv.h
   (a59b026419f33040d7d28b8e3b1cea681b9ce7a7
)


I have posted a patch that enables multiple parallel outputs. See

  



If you have the time, I'd appreciate if you could test it.

Hi Thomas,
First, thanks for your efforts on this patch of " enables multiple parallel outputs 
".
But it doesn't work. There is still NO EDID got from D-sub after DP unplugged.

Base on your patch, I am trying to find out the solution also.
Final, thanks for your help again!


Let's try to find a solution. I might be able to come up with something 
if I have enough information.


How are these outputs connected to each each other?

They are both served by the same CRTC. Can they be used at the same 
time?  Are they mutually exclusive?


Best regards
Thomas



Regards,
Kuo-Hsiang Chou

Best regards
Thomas



Another, do you need the ast2600 EVB to ease verification on "drm/ast" ?

Regards,

      Kuo-Hsiang Chou

-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Wednesday, May 04, 2022 3:28 PM
To: Kuo-Hsiang Chou ;
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED
proprietory Display-Port

Hi

Am 28.04.22 um 09:56 schrieb KuoHsiang Chou:


V1:



1. The MCU FW controling ASPEED DP is loaded by BMC boot loader.



2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP,



  and CRD1[5] has been asserted by BMVC boot loader.



3. EDID is prioritized by DP monitor.



4. DP's EDID has high priority to decide resolution supporting.







V2:



Modules description:



1. ASTDP (ASPEED DisplayPort) is controlled by dedicated



  AST-MCU (ASPEED propriatary MCU).



2. MCU is looping in charged of HPD, Read EDID, Link Training with



  DP sink.



3. ASTDP and AST-MUC reside in BMC (Baseboard Management controller)



  addressing-space.



4. ASPEED DRM driver requests MCU to get HPD and EDID by CR-scratched



  register.







Booting sequence:



1. Check if TX is ASTDP    //
ast_dp_launch()



2. Check if DP-MCU FW has loaded
// ast_dp_launch()



3. Read EDID    //
ast_dp_read_edid()



4. Resolution switch //
ast_dp_SetOutput()







V3:



1. Remove unneeded semicolon.



2. Apply to git://anongit.freedesktop.org/drm/drm, instead of



  git://anongit.freedesktop.org/drm/drm-misc



3. Resolve auto build test WARNINGs on V1 patch.







V4:



1. Sync code-base with kernel 5.17_rc6 2. Remove the define of



DPControlPower, because DP chips need to be



  powered on to be used.



3. Remove the switches of PHY and Display from EDID procedure.



4. Revise increaing delay to fixed delay, because this version kernel



  doesn't detect minitor consistenntly.



5. Create clean-up code used for reset of power state on errors with



  -EIO manner.



6. Revise the DP detection by TX type and its DP-FW status during



  booting and resume.



7. Correct the CamelCase Style.



8. Use register reading while needing, and remove to hold full



  register.



9. Instead of 'u8', revise to 'bool' on swwitch of PHY and video.



10.Correct typo



11.Remove the duplicated copy of TX definition.



12.Use EDID_LENGTH as the constant of 128.







Signed-off-by: KuoHsiang Chou mailto:kuohsiang_c...@aspeedtech.com>>


Reviewed-by: Thomas Zimmermann mailto:tzimmerm...@suse.de>>

I've meanwhile added your patch to drm-misc-next. It should show up in
one of the next kernel releases.  Thanks a lot.

Best regards

Thomas


---



    drivers/gpu/drm/ast/Makefile   |   2 +-



    drivers/gpu/drm/ast/ast_dp.c   | 282
+



    drivers/gpu/drm/ast/ast_drv.h  | 115 ++



    drivers/gpu/drm/ast/ast_main.c |   5 +-



    drivers/gpu/drm/ast/ast_mode.c | 124 ++-



    drivers/gpu/drm/ast/ast_post.c |   4 +-



    6 files changed, 524 insertions(+), 8 deletions(-)



    create mode 100644 drivers/gpu/drm/ast/ast_dp.c







diff --git a/drivers/gpu/drm/ast/Makefile

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Charan Teja Kalla]

On 5/13/2022 3:41 PM, Greg KH wrote:
>> Reported-by: kernel test robot 
> The trest robot did not say that the dmabuf stat name was being
> duplicated, did it?
>

It reported a printk warning on V2[1]. Should we remove this on V3?

@Christian: Could you please drop this tag while merging?

[1] https://lore.kernel.org/all/202205110511.e0d8txxc-...@intel.com/


>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index a6fc96e..0ad5039 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file)
>>  
>>  static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
>>  {
>> +static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
>>  struct file *file;
>>  struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
>>  
>> @@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf 
>> *dmabuf, int flags)
>>  inode->i_size = dmabuf->size;
>>  inode_set_bytes(inode, dmabuf->size);
>>  
>> +/*
>> + * The ->i_ino acquired from get_next_ino() is not unique thus
>> + * not suitable for using it as dentry name by dmabuf stats.
>> + * Override ->i_ino with the unique and dmabuffs specific
>> + * value.
>> + */
>> +inode->i_ino = atomic64_add_return(1, _inode);
>>  file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
>>   flags, _buf_fops);
>>  if (IS_ERR(file))
>> -- 
>> 2.7.4
>>
> Reviewed-by: Greg Kroah-Hartman 

Thanks for the ACK.

--Charan

Re: DSI Bridge switching

[Jagan Teki]

Hi Maxime,

On Thu, Mar 10, 2022 at 4:05 PM Maxime Ripard  wrote:
>
> On Wed, Mar 09, 2022 at 06:45:10PM -0600, Adam Ford wrote:
> > On Wed, Mar 9, 2022 at 1:11 PM Jagan Teki  
> > wrote:
> > >
> > >  or a Hi All,
> > >
> > > On Thu, Oct 14, 2021 at 6:45 PM Jagan Teki  
> > > wrote:
> > > >
> > > > Hi Laurent,
> > > >
> > > > On Fri, Oct 8, 2021 at 7:07 PM Laurent Pinchart
> > > >  wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Removed my invalid email (I will update files next week).
> > > > > >
> > > > > > On 08.10.2021 13:14, Jagan Teki wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > I think this seems to be a known use case for industrial these 
> > > > > > > days with i.mx8m.
> > > > > > >
> > > > > > > The host DSI would configure with two bridges one for DSI to LVDS
> > > > > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). 
> > > > > > > Technically we
> > > > > > > can use only one bridge at a time as host DSI support single out 
> > > > > > > port.
> > > > > > > So we can have two separate device tree files for LVDS and HDMI 
> > > > > > > and
> > > > > > > load them static.
> > > > > > >
> > > > > > > But, one of the use cases is to support both of them in single 
> > > > > > > dts, and
> > > > > > > - Turn On LVDS (default)
> > > > > > > - Turn Off LVDS then Turn On HDMI when cable plug-in
> > > > > >
> > > > > > Are you sure it will work from hardware PoV? Do you have some 
> > > > > > demuxer?
> > > > > > isolation of pins?
> > > > >
> > > > > It may be in the category of "you shouldn't do this, but it actually
> > > > > works". I've seen the same being done with two CSI-2 camera sensors
> > > > > connected to the same receiver, with one of them being held in reset 
> > > > > at
> > > > > all times.
> > > >
> > > > Yes. Here the design has 2 MIPI D-PHY switches. Each switch take 2
> > > > input data lanes and 1 clock lane from SoC and produces 4 data lanes
> > > > and 2 clock lanes and from switch output 2 lanes and 1 clock are
> > > > inputting to HDMI bridge and other 2 lanes and 1 clock is inputting to
> > > > LVDS. So 1st pair of 1st switch and 1st pair of 2nd switch goes to
> > > > HDMI and 2nd pair of 1st switch and 2nd pair of 2nd switch does to
> > > > LVDS.
> > > >
> > > > However, routing of these lanes are controlled by SEL, OE GPIO pins.
> > > > So at a time we can access only single bridge.
> > > >
> > > > >
> > > > > > > The HDMI event can be detected via some HDMI-INT GPIO on-board 
> > > > > > > design.
> > > > > > >
> > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, 
> > > > > > > HDMI on
> > > > > > > port 2 in the DSI host node, and trying to attach the respective
> > > > > > > bridge based on HDMI-INT like repeating the bridge attachment 
> > > > > > > cycle
> > > > > > > based on the HDMI-INT.
> > > > > >
> > > > > > I think more appropriate would be to share the same port, but 
> > > > > > provide
> > > > > > two endpoints inside this port - we have two hardware sharing the 
> > > > > > same
> > > > > > physical port.
> > > > >
> > > > > That sounds like the correct DT description to me.
> > > > >
> > > > > > > Can it be possible to do bridge attachment at runtime? something 
> > > > > > > like
> > > > > > > a bridge hotplug event? or any other possible solutions?
> > > > > > >
> > > > > > > Any suggestions?
> > > > > >
> > > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi +
> > > > > > some toshiba bridge - panel and bridge are dynamically 'plugged' and
> > > > > > 'unplugged' from exynos_drm, but they do not use bridge chain for 
> > > > > > this
> > > > > > and some other reasons. (un|re|)plugging should be performed of 
> > > > > > course
> > > > > > when pipeline is off (connector disconnected). I am not sure about
> > > > > > bridges added to bridge chain - you need to inspect all opses to 
> > > > > > ensure
> > > > > > it can be done safely.
> > > > > >
> > > > > > And the main issue: Daniel does not like it :)
> > > > >
> > > > > Neither do I :-) Could it be handled with two DRM connectors that are
> > > > > mutually exclusive ?
> > > >
> > > > How about adding lvds-connector, hdmi-connector on the pipeline and
> > > > select them based on the switch SEL GPIO? does it make sense to do
> > > > this implementation via display-connector.c
> > >
> > > I have somehow managed to make runtime switching possible between LVDS
> > > and HDMI with the help of DRM bridges.
> > >
> > >   | => ADV7535=>
> > > HDMI-A Connector
> > > DSI Host => display-switch => |
> > >   |=> SN65DSI83 => 
> > > Panel-Simple
> > >
> > > display-switch here is a bridge driver that can switch or attach the
> > > downstream bridge flow based on HDMI HPD here. One potential problem
> > > is that when we switch from LVDS to 

Re: [PATCH v2] drm: rcar-du: Fix Alpha blending issue on Gen3

[Kieran Bingham]

Quoting Biju Das (2022-04-26 09:41:57)
> From: LUU HOAI 
> 
> As per R-Car-Gen3_Common_OPC_Customer_Notifications_V30.1.pdf,
> unexpected image output(such as incorrect colors or planes being
> invisible) can happen on the below conditions, as PnALPHAR register
> is not initialized by reset.
> 
> When alpha blending (PpMRm.PpSPIM=0b101) is performed and:
> •two Planes are enabled on any DUn (n=0,1,2,3)
> oDSPRn= 0x 0031 or 0x 0013
> •or DU0 and DU1 is used for display at the same time
> oDSPR0= 0x 0001 and DSPR1= 0x 0003
> oDSPR0= 0x 0003 and DSPR1= 0x 0001
> •or DU2 and DU3(H3 Only) is used for display at the same time
> oDSPR2= 0x 0001 and DSPR3= 0x 0003
> oDSPR2= 0x 0003 and DSPR3= 0x 0001
> 
> This patch set PnALPHAR register to 0 to avoid this issue.
> 
> Signed-off-by: LUU HOAI 
> Signed-off-by: Biju Das 
> ---
> v1->v2:
>  * Updated commit description
>  * Updated the code comments
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index f214a8b6cfd3..aa80c44dd8d7 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -510,6 +510,18 @@ static void rcar_du_plane_setup_format_gen3(struct 
> rcar_du_group *rgrp,
>  
> rcar_du_plane_write(rgrp, index, PnDDCR4,
> state->format->edf | PnDDCR4_CODE);
> +
> +   /*
> +* On Gen3, some DU channels have two planes, each being wired to a
> +* separate VSPD instance. The DU can then blend two planes. While
> +* this feature isn't used by the driver, issues related to alpha
> +* blending (such as incorrect colors or planes being invisible) may
> +* still occur if the PnALPHAR register has a stale value. Set the
> +* register to 0 to avoid this.
> +*/
> +

Sounds reasonable.

> +   /* TODO: Check if alpha-blending should be disabled in PnMR. */

How will this be done? Do you have a specific test in mind to determine
if it causes issues? Or does it need validating through the hardware
teams?



> +   rcar_du_plane_write(rgrp, index, PnALPHAR, 0);


Reviewed-by: Kieran Bingham 

>  }
>  
>  static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp,
> -- 
> 2.25.1
>

Re: [PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Greg KH]

On Fri, May 13, 2022 at 03:08:09PM +0530, Charan Teja Kalla wrote:
> The dmabuf file uses get_next_ino()(through dma_buf_getfile() ->
> alloc_anon_inode()) to get an inode number and uses the same as a
> directory name under /sys/kernel/dmabuf/buffers/. This directory is
> used to collect the dmabuf stats and it is created through
> dma_buf_stats_setup(). At current, failure to create this directory
> entry can make the dma_buf_export() to fail.
> 
> Now, as the get_next_ino() can definitely give a repetitive inode no
> causing the directory entry creation to fail with -EEXIST. This is a
> problem on the systems where dmabuf stats functionality is enabled on
> the production builds can make the dma_buf_export(), though the dmabuf
> memory is allocated successfully, to fail just because it couldn't
> create stats entry.
> 
> This issue we are able to see on the snapdragon system within 13 days
> where there already exists a directory with inode no "122602" so
> dma_buf_stats_setup() failed with -EEXIST as it is trying to create
> the same directory entry.
> 
> To make the dentry name as unique, use the dmabuf fs specific inode
> which is based on the simple atomic variable increment. There is tmpfs
> subsystem too which relies on its own inode generation rather than
> relying on the get_next_ino() for the same reason of avoiding the
> duplicate inodes[1].
> 
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e809d5f0b5c912fe981dce738f3283b2010665f0
> 
> Reported-by: kernel test robot 

The trest robot did not say that the dmabuf stat name was being
duplicated, did it?

> Signed-off-by: Charan Teja Kalla 
> ---
> Changes in V3:
>   -- Used the atomic64 variable to have dmabuf files its own inodes.
>   -- Ensured no UAPI breakage as suggested by Christian.
> 
> Changes in V2:
>   -- Used the atomic64_t variable to generate a unique_id to be appended to 
> inode
>  to have an unique directory with name  -- 
> Suggested by christian
>   -- Updated the ABI documentation -- Identified by Greg.
>   -- Massaged the commit log.
>   -- 
> https://lore.kernel.org/all/1652191562-18700-1-git-send-email-quic_chara...@quicinc.com/
> 
> Changes in V1:
>   -- Used the inode->i_ctime->tv_secs as an id appended to inode to create the
>  unique directory with name .
>   -- 
> https://lore.kernel.org/all/1652178212-22383-1-git-send-email-quic_chara...@quicinc.com/
> 
>  drivers/dma-buf/dma-buf.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index a6fc96e..0ad5039 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file)
>  
>  static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
>  {
> + static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
>   struct file *file;
>   struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
>  
> @@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf 
> *dmabuf, int flags)
>   inode->i_size = dmabuf->size;
>   inode_set_bytes(inode, dmabuf->size);
>  
> + /*
> +  * The ->i_ino acquired from get_next_ino() is not unique thus
> +  * not suitable for using it as dentry name by dmabuf stats.
> +  * Override ->i_ino with the unique and dmabuffs specific
> +  * value.
> +  */
> + inode->i_ino = atomic64_add_return(1, _inode);
>   file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
>flags, _buf_fops);
>   if (IS_ERR(file))
> -- 
> 2.7.4
> 

Reviewed-by: Greg Kroah-Hartman 

Re: [PATCH] drm/i915: Fix CFI violation with show_dynamic_id()

[Tvrtko Ursulin]

On 12/05/2022 22:17, Nathan Chancellor wrote:

When an attribute group is created with sysfs_create_group(), the
->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show()
callback to kobj_attr_show(). kobj_attr_show() uses container_of() to
get the ->show() callback from the attribute it was passed, meaning the
->show() callback needs to be the same type as the ->show() callback in
'struct kobj_attribute'.

However, show_dynamic_id() has the type of the ->show() callback in
'struct device_attribute', which causes a CFI violation when opening the
'id' sysfs node under drm/card0/metrics. This happens to work because
the layout of 'struct kobj_attribute' and 'struct device_attribute' are
the same, so the container_of() cast happens to allow the ->show()
callback to still work.

Change the type of show_dynamic_id() to match the ->show() callback in
'struct kobj_attributes' and update the type of sysfs_metric_id to
match, which resolves the CFI violation.

Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG 
interface")
Signed-off-by: Nathan Chancellor 


Merged to drm-intel-gt-next, thanks for the fix and reviews!

Regards,

Tvrtko


---
  drivers/gpu/drm/i915/i915_perf.c   | 4 ++--
  drivers/gpu/drm/i915/i915_perf_types.h | 2 +-
  2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 0a9c3fcc09b1..1577ab6754db 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4050,8 +4050,8 @@ static struct i915_oa_reg *alloc_oa_regs(struct i915_perf 
*perf,
return ERR_PTR(err);
  }
  
-static ssize_t show_dynamic_id(struct device *dev,

-  struct device_attribute *attr,
+static ssize_t show_dynamic_id(struct kobject *kobj,
+  struct kobj_attribute *attr,
   char *buf)
  {
struct i915_oa_config *oa_config =
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h 
b/drivers/gpu/drm/i915/i915_perf_types.h
index 473a3c0544bb..05cb9a335a97 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -55,7 +55,7 @@ struct i915_oa_config {
  
  	struct attribute_group sysfs_metric;

struct attribute *attrs[2];
-   struct device_attribute sysfs_metric_id;
+   struct kobj_attribute sysfs_metric_id;
  
  	struct kref ref;

struct rcu_head rcu;

base-commit: 7ecc3cc8a7b39f08eee9aea7b718187583342a70

[PATCH V3] dma-buf: ensure unique directory name for dmabuf stats

[Charan Teja Kalla]

The dmabuf file uses get_next_ino()(through dma_buf_getfile() ->
alloc_anon_inode()) to get an inode number and uses the same as a
directory name under /sys/kernel/dmabuf/buffers/. This directory is
used to collect the dmabuf stats and it is created through
dma_buf_stats_setup(). At current, failure to create this directory
entry can make the dma_buf_export() to fail.

Now, as the get_next_ino() can definitely give a repetitive inode no
causing the directory entry creation to fail with -EEXIST. This is a
problem on the systems where dmabuf stats functionality is enabled on
the production builds can make the dma_buf_export(), though the dmabuf
memory is allocated successfully, to fail just because it couldn't
create stats entry.

This issue we are able to see on the snapdragon system within 13 days
where there already exists a directory with inode no "122602" so
dma_buf_stats_setup() failed with -EEXIST as it is trying to create
the same directory entry.

To make the dentry name as unique, use the dmabuf fs specific inode
which is based on the simple atomic variable increment. There is tmpfs
subsystem too which relies on its own inode generation rather than
relying on the get_next_ino() for the same reason of avoiding the
duplicate inodes[1].

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=e809d5f0b5c912fe981dce738f3283b2010665f0

Reported-by: kernel test robot 
Signed-off-by: Charan Teja Kalla 
---
Changes in V3:
  -- Used the atomic64 variable to have dmabuf files its own inodes.
  -- Ensured no UAPI breakage as suggested by Christian.

Changes in V2:
  -- Used the atomic64_t variable to generate a unique_id to be appended to 
inode
 to have an unique directory with name  -- 
Suggested by christian
  -- Updated the ABI documentation -- Identified by Greg.
  -- Massaged the commit log.
  -- 
https://lore.kernel.org/all/1652191562-18700-1-git-send-email-quic_chara...@quicinc.com/

Changes in V1:
  -- Used the inode->i_ctime->tv_secs as an id appended to inode to create the
 unique directory with name .
  -- 
https://lore.kernel.org/all/1652178212-22383-1-git-send-email-quic_chara...@quicinc.com/

 drivers/dma-buf/dma-buf.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a6fc96e..0ad5039 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -407,6 +407,7 @@ static inline int is_dma_buf_file(struct file *file)
 
 static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags)
 {
+   static atomic64_t dmabuf_inode = ATOMIC64_INIT(0);
struct file *file;
struct inode *inode = alloc_anon_inode(dma_buf_mnt->mnt_sb);
 
@@ -416,6 +417,13 @@ static struct file *dma_buf_getfile(struct dma_buf 
*dmabuf, int flags)
inode->i_size = dmabuf->size;
inode_set_bytes(inode, dmabuf->size);
 
+   /*
+* The ->i_ino acquired from get_next_ino() is not unique thus
+* not suitable for using it as dentry name by dmabuf stats.
+* Override ->i_ino with the unique and dmabuffs specific
+* value.
+*/
+   inode->i_ino = atomic64_add_return(1, _inode);
file = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf",
 flags, _buf_fops);
if (IS_ERR(file))
-- 
2.7.4

Re: Improve TTMs empty object handling

[Matthew Auld]

On Mon, 9 May 2022 at 14:09, Christian König
 wrote:
>
> Hi everyone,
>
> re-sending this because Daniel was requesting a background why this is
> useful.
>
> When TTM creates a buffer this object initially should not have any
> backing store and there no resource object associated with it. The same
> can happen when a driver requests that the backing store of an object is
> destroyed without allocating a new one.
>
> This is really useful during initial buffer creation as well as temporary
> buffers and page tables which content doesn't need to be preserved when
> they are evicted.
>
> Currently TTM allocates dummy system resources for that because drivers
> couldn't handle a NULL pointer there. Audit the drivers and then clean
> up TTM to stop making those dummy allocations.
>
> Please review and comment,

Any chance we can throw this at intel-ci? Series seems to apply to drm-tip.

> Christian.
>
>

RE: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory Display-Port

[Kuo-Hsiang Chou]

-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de] 
Sent: Tuesday, May 10, 2022 6:56 PM
To: Kuo-Hsiang Chou ; 
dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED proprietory 
Display-Port

Hi

Am 04.05.22 um 10:49 schrieb Kuo-Hsiang Chou:
> Hi Thomas,
> 
> Thanks for your efforts to review this patch.
> 
> Now, I observe a change that after DP unplugged and then the system is 
> unable to get EDID from D-sub connecting.
> 
> The reason seems that TXs are merged into union structure in 
> /drivers/gpu/drm/ast/ast_drv.h
>   (a59b026419f33040d7d28b8e3b1cea681b9ce7a7
>  d7d28b8e3b1cea681b9ce7a7>)

I have posted a patch that enables multiple parallel outputs. See

 


If you have the time, I'd appreciate if you could test it.

Hi Thomas,
First, thanks for your efforts on this patch of " enables multiple parallel 
outputs ".
But it doesn't work. There is still NO EDID got from D-sub after DP unplugged.

Base on your patch, I am trying to find out the solution also.
Final, thanks for your help again!

Regards,
Kuo-Hsiang Chou

Best regards
Thomas

> 
> Another, do you need the ast2600 EVB to ease verification on "drm/ast" ?
> 
> Regards,
> 
>      Kuo-Hsiang Chou
> 
> -Original Message-
> From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
> Sent: Wednesday, May 04, 2022 3:28 PM
> To: Kuo-Hsiang Chou ; 
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v4] drm/ast: Create the driver for ASPEED 
> proprietory Display-Port
> 
> Hi
> 
> Am 28.04.22 um 09:56 schrieb KuoHsiang Chou:
> 
>> V1:
> 
>> 1. The MCU FW controling ASPEED DP is loaded by BMC boot loader.
> 
>> 2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP,
> 
>> and CRD1[5] has been asserted by BMVC boot loader.
> 
>> 3. EDID is prioritized by DP monitor.
> 
>> 4. DP's EDID has high priority to decide resolution supporting.
> 
>> 
> 
>> V2:
> 
>> Modules description:
> 
>> 1. ASTDP (ASPEED DisplayPort) is controlled by dedicated
> 
>> AST-MCU (ASPEED propriatary MCU).
> 
>> 2. MCU is looping in charged of HPD, Read EDID, Link Training with
> 
>> DP sink.
> 
>> 3. ASTDP and AST-MUC reside in BMC (Baseboard Management controller)
> 
>> addressing-space.
> 
>> 4. ASPEED DRM driver requests MCU to get HPD and EDID by CR-scratched
> 
>> register.
> 
>> 
> 
>> Booting sequence:
> 
>> 1. Check if TX is ASTDP    // 
>> ast_dp_launch()
> 
>> 2. Check if DP-MCU FW has loaded    
>> // ast_dp_launch()
> 
>> 3. Read EDID    // 
>> ast_dp_read_edid()
> 
>> 4. Resolution switch // 
>> ast_dp_SetOutput()
> 
>> 
> 
>> V3:
> 
>> 1. Remove unneeded semicolon.
> 
>> 2. Apply to git://anongit.freedesktop.org/drm/drm, instead of
> 
>> git://anongit.freedesktop.org/drm/drm-misc
> 
>> 3. Resolve auto build test WARNINGs on V1 patch.
> 
>> 
> 
>> V4:
> 
>> 1. Sync code-base with kernel 5.17_rc6 2. Remove the define of
> 
>> DPControlPower, because DP chips need to be
> 
>> powered on to be used.
> 
>> 3. Remove the switches of PHY and Display from EDID procedure.
> 
>> 4. Revise increaing delay to fixed delay, because this version kernel
> 
>> doesn't detect minitor consistenntly.
> 
>> 5. Create clean-up code used for reset of power state on errors with
> 
>> -EIO manner.
> 
>> 6. Revise the DP detection by TX type and its DP-FW status during
> 
>> booting and resume.
> 
>> 7. Correct the CamelCase Style.
> 
>> 8. Use register reading while needing, and remove to hold full
> 
>> register.
> 
>> 9. Instead of 'u8', revise to 'bool' on swwitch of PHY and video.
> 
>> 10.Correct typo
> 
>> 11.Remove the duplicated copy of TX definition.
> 
>> 12.Use EDID_LENGTH as the constant of 128.
> 
>> 
> 
>> Signed-off-by: KuoHsiang Chou > >
> 
> Reviewed-by: Thomas Zimmermann  >
> 
> I've meanwhile added your patch to drm-misc-next. It should show up in 
> one of the next kernel releases.  Thanks a lot.
> 
> Best regards
> 
> Thomas
> 
>> ---
> 
>>   drivers/gpu/drm/ast/Makefile   |   2 +-
> 
>>   drivers/gpu/drm/ast/ast_dp.c   | 282 
>>+
> 
>>   drivers/gpu/drm/ast/ast_drv.h  | 115 ++
> 
>>   drivers/gpu/drm/ast/ast_main.c |   5 +-
> 
>>   drivers/gpu/drm/ast/ast_mode.c | 124 ++-
> 
>>   drivers/gpu/drm/ast/ast_post.c |   4 +-
> 
>>   6 files changed, 524 insertions(+), 8 deletions(-)
> 
>>   create mode 100644 drivers/gpu/drm/ast/ast_dp.c
> 
>> 
> 
>> diff --git a/drivers/gpu/drm/ast/Makefile
> 
>> b/drivers/gpu/drm/ast/Makefile index 21f71160b..5a53ce51f 100644

Re: [PATCH 3/3] dt-bindings: usb: add documentation for aspeed udc

[Krzysztof Kozlowski]

On 13/05/2022 08:57, Neal Liu wrote:
> Add device tree binding documentation for the Aspeed USB2.0 Device
> Controller.
> 
> Signed-off-by: Neal Liu 
> ---
>  .../devicetree/bindings/usb/aspeed,udc.yaml   | 52 +++
>  1 file changed, 52 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/aspeed,udc.yaml

Please name the file as first compatible, so "aspeed,ast2600-udc.yaml"


> 
> diff --git a/Documentation/devicetree/bindings/usb/aspeed,udc.yaml 
> b/Documentation/devicetree/bindings/usb/aspeed,udc.yaml
> new file mode 100644
> index ..d1d2f77d1c54
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/aspeed,udc.yaml
> @@ -0,0 +1,52 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (c) 2020 Facebook Inc.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/aspeed,udc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ASPEED USB 2.0 Device Controller
> +
> +maintainers:
> +  - Neal Liu 
> +
> +description: |+
> +  The ASPEED USB 2.0 Device Controller implements 1 control endpoint and
> +  4 generic endpoints for AST260x.
> +
> +  Supports independent DMA channel for each generic endpoint.
> +  Supports 32/256 stages descriptor mode for all generic endpoints.
> +
> +properties:
> +  compatible:
> +enum:
> +  - aspeed,ast2600-udc
> +
> +  reg:
> +maxItems: 1
> +
> +  clocks:
> +maxItems: 1
> +
> +  interrupts:
> +maxItems: 1

No child properties? No ports or any other devices? No usb-hcd.yaml?
> +
> +required:
> +  - compatible
> +  - reg
> +  - clocks
> +  - interrupts
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +#include 
> +udc: udc@1e6a2000 {

Node name: usb

> +compatible = "aspeed,ast2600-udc";
> +reg = <0x1e6a2000 0x300>;
> +interrupts = <9>;
> +clocks = < ASPEED_CLK_GATE_USBPORT2CLK>;
> +pinctrl-names = "default";
> +pinctrl-0 = <_usb2bd_default>;
> +};


Best regards,
Krzysztof

[PATCH v3] drm/mgag200: Enable atomic gamma lut update

[Jocelyn Falempe]

Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is working properly on mgag200.

v2:
 - Add a default linear gamma function
 - renamed functions with mgag200 prefix
 - use format's 4cc code instead of bit depth
 - use better interpolation for 16bits gamma
 - remove legacy function mga_crtc_load_lut()
 - can't remove the call to drm_mode_crtc_set_gamma_size()
because it doesn't work with userspace.
 - other small refactors

v3:
 - change mgag200_crtc_set_gamma*() argument
to struct drm_format_info *format
 - fix printk format to %p4cc for 4cc and %zu for size_t
 - rebased to drm-misc-next.

Signed-off-by: Jocelyn Falempe 
Tested-by: Thomas Zimmermann 
Reviewed-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/mgag200_mode.c | 127 -
 1 file changed, 83 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c 
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index dec744d0bee2..73d5a4a42b3a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -32,57 +32,78 @@
  * This file contains setup code for the CRTC.
  */
 
-static void mga_crtc_load_lut(struct drm_crtc *crtc)
+static void mgag200_crtc_set_gamma_linear(struct mga_device *mdev,
+ const struct drm_format_info *format)
 {
-   struct drm_device *dev = crtc->dev;
-   struct mga_device *mdev = to_mga_device(dev);
-   struct drm_framebuffer *fb;
-   u16 *r_ptr, *g_ptr, *b_ptr;
int i;
 
-   if (!crtc->enabled)
-   return;
-
-   if (!mdev->display_pipe.plane.state)
-   return;
+   WREG8(DAC_INDEX + MGA1064_INDEX, 0);
 
-   fb = mdev->display_pipe.plane.state->fb;
+   switch (format->format) {
+   case DRM_FORMAT_RGB565:
+   /* Use better interpolation, to take 32 values from 0 to 255 */
+   for (i = 0; i < MGAG200_LUT_SIZE / 8; i++) {
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i * 8 + i / 4);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i * 4 + i / 16);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i * 8 + i / 4);
+   }
+   /* Green has one more bit, so add padding with 0 for red and 
blue. */
+   for (i = MGAG200_LUT_SIZE / 8; i < MGAG200_LUT_SIZE / 4; i++) {
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, 0);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i * 4 + i / 16);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, 0);
+   }
+   break;
+   case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_XRGB:
+   for (i = 0; i < MGAG200_LUT_SIZE; i++) {
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i);
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, i);
+   }
+   break;
+   default:
+   drm_warn_once(>base, "Unsupported format %p4cc for gamma 
correction\n",
+ >format);
+   break;
+   }
+}
 
-   r_ptr = crtc->gamma_store;
-   g_ptr = r_ptr + crtc->gamma_size;
-   b_ptr = g_ptr + crtc->gamma_size;
+static void mgag200_crtc_set_gamma(struct mga_device *mdev,
+  const struct drm_format_info *format,
+  struct drm_color_lut *lut)
+{
+   int i;
 
WREG8(DAC_INDEX + MGA1064_INDEX, 0);
 
-   if (fb && fb->format->cpp[0] * 8 == 16) {
-   int inc = (fb->format->depth == 15) ? 8 : 4;
-   u8 r, b;
-   for (i = 0; i < MGAG200_LUT_SIZE; i += inc) {
-   if (fb->format->depth == 16) {
-   if (i > (MGAG200_LUT_SIZE >> 1)) {
-   r = b = 0;
-   } else {
-   r = *r_ptr++ >> 8;
-   b = *b_ptr++ >> 8;
-   r_ptr++;
-   b_ptr++;
-   }
-   } else {
-   r = *r_ptr++ >> 8;
-   b = *b_ptr++ >> 8;
-   }
-   /* VGA registers */
-   WREG8(DAC_INDEX + MGA1064_COL_PAL, r);
-   WREG8(DAC_INDEX + MGA1064_COL_PAL, *g_ptr++ >> 8);
-   WREG8(DAC_INDEX + MGA1064_COL_PAL, b);
+   switch (format->format) {
+   case DRM_FORMAT_RGB565:
+   /* Use better interpolation, to take 32 values from lut[0] to 
lut[255] */
+   for (i = 0; i < MGAG200_LUT_SIZE / 8; i++) {
+   WREG8(DAC_INDEX + MGA1064_COL_PAL, lut[i * 8 + i / 
4].red >> 8);
+   WREG8(DAC_INDEX + 

[PATCH] drm/exynos: mic: Rework initialization

[Marek Szyprowski]

Commit dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
moved Exynos MIC attaching from DSI to MIC driver. However the method
proposed there is incomplete and cannot really work. To properly attach
it to the bridge chain, access to the respective encoder is needed. The
Exynos MIC driver always attaches to the encoder created by the Exynos
DSI driver, so grab it via available helpers for getting access to the
CRTC and encoders. This also requires to change the order of driver
component binding to let DSI to be bound before MIC.

Fixes: dd8b6803bc49 ("exynos: drm: dsi: Attach in_bridge in MIC driver")
Signed-off-by: Marek Szyprowski 
---
A few words of comment. The mentioned commit has my Tested-by tag and
indeed I gave it. However that time due to remote work and incorrect
camera configuration in the office I was not able to check if the board
really produces valid display, I only checked if it boots and reports
valid DRM structures to the userspace.

If possible, please merge this to the drm-misc-next together with the
rest of Exynos DSI to drm bridge rework patches.
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |  6 ++--
 drivers/gpu/drm/exynos/exynos_drm_mic.c | 42 +++--
 2 files changed, 15 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 424ea23eec32..16c539657f73 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -176,15 +176,15 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] 
= {
}, {
DRV_PTR(mixer_driver, CONFIG_DRM_EXYNOS_MIXER),
DRM_COMPONENT_DRIVER
-   }, {
-   DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
-   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(dp_driver, CONFIG_DRM_EXYNOS_DP),
DRM_COMPONENT_DRIVER
}, {
DRV_PTR(dsi_driver, CONFIG_DRM_EXYNOS_DSI),
DRM_COMPONENT_DRIVER
+   }, {
+   DRV_PTR(mic_driver, CONFIG_DRM_EXYNOS_MIC),
+   DRM_COMPONENT_DRIVER
}, {
DRV_PTR(hdmi_driver, CONFIG_DRM_EXYNOS_HDMI),
DRM_COMPONENT_DRIVER
diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
b/drivers/gpu/drm/exynos/exynos_drm_mic.c
index 9e06f8e2a863..09ce28ee08d9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "exynos_drm_drv.h"
+#include "exynos_drm_crtc.h"
 
 /* Sysreg registers for MIC */
 #define DSD_CFG_MUX0x1004
@@ -100,9 +101,7 @@ struct exynos_mic {
 
bool i80_mode;
struct videomode vm;
-   struct drm_encoder *encoder;
struct drm_bridge bridge;
-   struct drm_bridge *next_bridge;
 
bool enabled;
 };
@@ -229,8 +228,6 @@ static void mic_set_reg_on(struct exynos_mic *mic, bool 
enable)
writel(reg, mic->reg + MIC_OP);
 }
 
-static void mic_disable(struct drm_bridge *bridge) { }
-
 static void mic_post_disable(struct drm_bridge *bridge)
 {
struct exynos_mic *mic = bridge->driver_private;
@@ -297,34 +294,30 @@ static void mic_pre_enable(struct drm_bridge *bridge)
mutex_unlock(_mutex);
 }
 
-static void mic_enable(struct drm_bridge *bridge) { }
-
-static int mic_attach(struct drm_bridge *bridge,
- enum drm_bridge_attach_flags flags)
-{
-   struct exynos_mic *mic = bridge->driver_private;
-
-   return drm_bridge_attach(bridge->encoder, mic->next_bridge,
->bridge, flags);
-}
-
 static const struct drm_bridge_funcs mic_bridge_funcs = {
-   .disable = mic_disable,
.post_disable = mic_post_disable,
.mode_set = mic_mode_set,
.pre_enable = mic_pre_enable,
-   .enable = mic_enable,
-   .attach = mic_attach,
 };
 
 static int exynos_mic_bind(struct device *dev, struct device *master,
   void *data)
 {
struct exynos_mic *mic = dev_get_drvdata(dev);
+   struct drm_device *drm_dev = data;
+   struct exynos_drm_crtc *crtc = exynos_drm_crtc_get_by_type(drm_dev,
+  EXYNOS_DISPLAY_TYPE_LCD);
+   struct drm_encoder *e, *encoder = NULL;
+
+   drm_for_each_encoder(e, drm_dev)
+   if (e->possible_crtcs == drm_crtc_mask(>base))
+   encoder = e;
+   if (!encoder)
+   return -ENODEV;
 
mic->bridge.driver_private = mic;
 
-   return 0;
+   return drm_bridge_attach(encoder, >bridge, NULL, 0);
 }
 
 static void exynos_mic_unbind(struct device *dev, struct device *master,
@@ -388,7 +381,6 @@ static int exynos_mic_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
struct exynos_mic *mic;
-   struct device_node *remote;
struct resource res;
int ret, i;
 
@@ -432,16 +424,6 @@ static int 

Re: [PATCH v3 3/3] dt-bindings: mediatek: add ethdr definition for mt8195

[Krzysztof Kozlowski]

On 12/05/2022 10:05, Rex-BC Chen wrote:
> From: "Nancy.Lin" 
> 
> Add vdosys1 ETHDR definition.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: Chun-Kuang Hu 
> Reviewed-by: AngeloGioacchino Del Regno 
> 


Reviewed-by: Krzysztof Kozlowski 


Best regards,
Krzysztof

Re: [PATCH v3 2/3] dt-bindings: reset: mt8195: add vdosys1 reset control bit

[Krzysztof Kozlowski]

On 12/05/2022 10:05, Rex-BC Chen wrote:
> From: "Nancy.Lin" 
> 
> Add vdosys1 reset control bit for MT8195 platform.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: Chun-Kuang Hu 
> Reviewed-by: AngeloGioacchino Del Regno 
> 
> Reviewed-by: Rex-BC Chen 


Acked-by: Krzysztof Kozlowski 


Best regards,
Krzysztof

Re: [PATCH v3 1/3] dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195

[Krzysztof Kozlowski]

On 12/05/2022 10:05, Rex-BC Chen wrote:
> From: "Nancy.Lin" 
> 
> Add vdosys1 RDMA definition.
> 
> Signed-off-by: Nancy.Lin 
> Reviewed-by: AngeloGioacchino Del Regno 
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [5.18 regression] drm/i915 BYT rendering broken due to "Remove short-term pins from execbuf, v6" #forregzbot

[Thorsten Leemhuis]

TWIMC: this mail is primarily send for documentation purposes and for
regzbot, my Linux kernel regression tracking bot. These mails usually
contain '#forregzbot' in the subject, to make them easy to spot and filter.

On 09.05.22 09:01, Thorsten Leemhuis wrote:
> [TLDR: I'm adding this regression report to the list of tracked
> regressions; all text from me you find below is based on a few templates
> paragraphs you might have encountered already already in similar form.]
> 
> Hi, this is your Linux kernel regression tracker. Top-posting for once,
> to make this easily accessible to everyone.
> 
> Thanks for the report.
> 
> To be sure below issue doesn't fall through the cracks unnoticed, I'm
> adding it to regzbot, my Linux kernel regression tracking bot:
> 
> #regzbot ^introduced b5cfe6f7a6e1
> #regzbot title drm/i915: BYT rendering broken due to "Remove short-term
> pins from execbuf, v6"
> #regzbot ignore-activity

#regzbot link: https://gitlab.freedesktop.org/drm/intel/-/issues/5806
#regzbot monitor:
https://lore.kernel.org/all/2022055219.46507-1-maarten.lankho...@linux.intel.com/

> This isn't a regression? This issue or a fix for it are already
> discussed somewhere else? It was fixed already? You want to clarify when
> the regression started to happen? Or point out I got the title or
> something else totally wrong? Then just reply -- ideally with also
> telling regzbot about it, as explained here:
> https://linux-regtracking.leemhuis.info/tracked-regression/
> 
> Reminder for developers: When fixing the issue, add 'Link:' tags
> pointing to the report (the mail this one replied to), as the kernel's
> documentation call for; above page explains why this is important for
> tracked regressions.
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> 
> P.S.: As the Linux kernel's regression tracker I deal with a lot of
> reports and sometimes miss something important when writing mails like
> this. If that's the case here, don't hesitate to tell me in a public
> reply, it's in everyone's interest to set the public record straight.
> 
> 
> 
> On 08.05.22 16:38, Hans de Goede wrote:
>> Hi All,
>>
>> When running a 5.18-rc4 (and -rc5) kernel on a Chuwi Hi 8, which is
>> a Bay Trail based tablet with 2G RAM and a 1200x1920 DSI panel.
>> I noticed that gnome-shell was misrendering. Many UI elements were
>> missing (they were all black) and at the gdm login screen (which is
>> a special gnome-shell session) the screen often was entirely black
>> until I move the cursor around and then various things got
>> highlighted after which they sometimes stuck around and sometimes
>> they disappeared again after the highlight.
>>
>> Since this problem does not happen with various 5.17.y kernels I
>> believe that this is a kernel regression in 5.18. I've bisected this
>> and the bisect points to:
>>
>> commit b5cfe6f7a6e1 ("drm/i915: Remove short-term pins from execbuf, v6.")
>>
>> from Maarten. This commit cleanly reverts on top of 5.18-rc5 and
>> I can confirm that 5.18-rc5 with b5cfe6f7a6e1 reverted fixes things.
>>
>> I would be more then happy to test any possible fixes for this.
>>
>> Regards,
>>
>> Hans
>>
>>
>>

Re: [PATCH] drm/amd/display: Remove macro DC_DEFAULT_LOG_MASK

[kernel test robot]

Hi pengfuyuan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v5.18-rc6 next-20220512]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/intel-lab-lkp/linux/commits/pengfuyuan/drm-amd-display-Remove-macro-DC_DEFAULT_LOG_MASK/20220512-185320
base:   git://anongit.freedesktop.org/drm/drm drm-next
config: arm-randconfig-r016-20220512 
(https://download.01.org/0day-ci/archive/20220513/202205131519.0pphvmxz-...@intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project 
9519dacab7b8afd537811fc2abaceb4d14f4e16a)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# 
https://github.com/intel-lab-lkp/linux/commit/94b3092ea272cf77105cc7b19fcffc44b49e1a71
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
pengfuyuan/drm-amd-display-Remove-macro-DC_DEFAULT_LOG_MASK/20220512-185320
git checkout 94b3092ea272cf77105cc7b19fcffc44b49e1a71
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=arm SHELL=/bin/bash

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:30:
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:31:
>> drivers/gpu/drm/amd/amdgpu/../display/include/logger_types.h:26:2: error: 
>> unterminated conditional directive
   #ifndef __DAL_LOGGER_TYPES_H__
^
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:30:
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:40:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/hw_sequencer.h:29:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/clock_source.h:31:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/bios_parser_types.h:30:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:36:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/logger_interface.h:29:
>> drivers/gpu/drm/amd/amdgpu/../display/include/logger_types.h:26:2: error: 
>> unterminated conditional directive
   #ifndef __DAL_LOGGER_TYPES_H__
^
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:35:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dmub/dmub_srv.h:67:
   drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:862:18: warning: 
field cursor_copy_src within 'struct dmub_rb_cmd_mall' is less aligned than 
'union dmub_addr' and is usually due to 'struct dmub_rb_cmd_mall' being packed, 
which can lead to unaligned accesses [-Wunaligned-access]
   union dmub_addr cursor_copy_src; /**< Cursor copy address */
   ^
   drivers/gpu/drm/amd/amdgpu/../display/dmub/inc/dmub_cmd.h:863:18: warning: 
field cursor_copy_dst within 'struct dmub_rb_cmd_mall' is less aligned than 
'union dmub_addr' and is usually due to 'struct dmub_rb_cmd_mall' being packed, 
which can lead to unaligned accesses [-Wunaligned-access]
   union dmub_addr cursor_copy_dst; /**< Cursor copy destination */
   ^
   2 warnings and 2 errors generated.
--
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:27:
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:31:
>> drivers/gpu/drm/amd/amdgpu/../display/include/logger_types.h:26:2: error: 
>> unterminated conditional directive
   #ifndef __DAL_LOGGER_TYPES_H__
^
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:27:
   In file included from drivers/gpu/drm/amd/amdgpu/../display/dc/dc.h:40:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/hw_sequencer.h:29:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/inc/clock_source.h:31:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/bios_parser_types.h:30:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:36:
   In file included from 
drivers/gpu/drm/amd/amdgpu/../display/include/logger_interface.h:29:
>> drivers/gpu/drm/amd/amdgpu/../display/include/logger_types.h:26:2: error: 
>> unterminated conditional directive
   #ifnd

Re: [PATCH] drm/vmwgfx: Fix passing partly uninitialized drm_mode_fb_cmd2 struct

[Thorsten Leemhuis]

CCing airlied

On 09.05.22 14:02, Javier Martinez Canillas wrote:
> On 5/9/22 13:55, Hans de Goede wrote:
> [snip]

 Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2072556
 Signed-off-by: Hans de Goede 
 ---
>>>
>>> Zack fixed this already:
>>>
>>> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=5405d25b9e8e6
>>
>> I see, but it seems that this was never pushed to drm-misc-fixes,
>> so this is still broken in 5.18-rc#
> 
> Indeed. Agreed that should be cherry-picked in -fixes as well.

Looks to me like nobody did that and this regression fix is missing in
the pull request Dave sent to Linus earlier today. Can anybody please
make sure it makes the next weeks pull? Or was there a change of plans?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

Re: [PATCH v20 8/8] soc: mediatek: remove DDP_DOMPONENT_DITHER from enum

[Matthias Brugger]

Hi Chun-Kuang,

On 02/05/2022 00:54, Chun-Kuang Hu wrote:

Hi, Matthias:

Matthias Brugger  於 2022年4月22日 週五 下午8:42寫道：




On 19/04/2022 11:41, jason-jh.lin wrote:

After mmsys and drm change DITHER enum to DDP_COMPONENT_DITHER0,
mmsys header can remove the useless DDP_COMPONENT_DITHER enum.

Signed-off-by: jason-jh.lin 
Reviewed-by: AngeloGioacchino Del Regno 



Acked-by: Matthias Brugger 

Chun-Kuang, I think it would make sense to take that through your tree as it
depends on the previous patches.

I provide you a stable tag so that you can take it:
v5.18-next-vdso0-stable-tag


After I take this tag, I find one checkpatch warning:

WARNING: DT compatible string "mediatek,mt8195-mmsys" appears
un-documented -- check ./Documentation/devicetree/bindings/
#670: FILE: drivers/soc/mediatek/mtk-mmsys.c:390:
+   .compatible = "mediatek,mt8195-mmsys",

I think this tag lost one binding patch, it's better that this tag has
no this warning.



Sorry for the late reply I was sick.
The warning is, because the stable branch misses commit:
https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux.git/commit/?h=v5.18-next/soc=81c5a41d10b968ea89d5f44fe1e5c2fc70289209

So it's not a real issue and will go away once our branches land in upstream.
Is it OK for you to ignore the issue?

Regards,
Matthias


Regards,
Chun-Kuang.



Regards,
Matthias


---
   include/linux/soc/mediatek/mtk-mmsys.h | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/include/linux/soc/mediatek/mtk-mmsys.h 
b/include/linux/soc/mediatek/mtk-mmsys.h
index 59117d970daf..fb719fd1281c 100644
--- a/include/linux/soc/mediatek/mtk-mmsys.h
+++ b/include/linux/soc/mediatek/mtk-mmsys.h
@@ -16,8 +16,7 @@ enum mtk_ddp_comp_id {
   DDP_COMPONENT_CCORR,
   DDP_COMPONENT_COLOR0,
   DDP_COMPONENT_COLOR1,
- DDP_COMPONENT_DITHER,
- DDP_COMPONENT_DITHER0 = DDP_COMPONENT_DITHER,
+ DDP_COMPONENT_DITHER0,
   DDP_COMPONENT_DITHER1,
   DDP_COMPONENT_DP_INTF0,
   DDP_COMPONENT_DP_INTF1,

[PULL] drm-misc-fixes

[Maxime Ripard]

Hi Dave, Daniel,

Here's this week drm-misc-fixes. drm-misc-next-fixes is empty at the
moment, so there won't be a PR for it this week.

Thanks!
Maxime

drm-misc-fixes-2022-05-13:
Multiple fixes to fbdev to address a regression at unregistration, an
iommu detection improvement for nouveau, a memory leak fix for nouveau,
pointer dereference fix for dma_buf_file_release(), and a build breakage
fix for vc4
The following changes since commit c5eb0a61238dd6faf37f58c9ce61c9980aaffd7a:

  Linux 5.18-rc6 (2022-05-08 13:54:17 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-05-13

for you to fetch changes up to 6fed53de560768bde6d701a7c79c253b45b259e3:

  drm/vc4: hdmi: Fix build error for implicit function declaration (2022-05-12 
11:01:19 +0200)


Multiple fixes to fbdev to address a regression at unregistration, an
iommu detection improvement for nouveau, a memory leak fix for nouveau,
pointer dereference fix for dma_buf_file_release(), and a build breakage
fix for vc4


Charan Teja Reddy (1):
  dma-buf: call dma_buf_stats_setup after dmabuf is in valid list

Christophe JAILLET (1):
  drm/nouveau: Fix a potential theorical leak in 
nouveau_get_backlight_name()

Daniel Vetter (1):
  fbdev: Prevent possible use-after-free in fb_release()

Hui Tang (1):
  drm/vc4: hdmi: Fix build error for implicit function declaration

Javier Martinez Canillas (5):
  Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"
  fbdev: simplefb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: efifb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: vesafb: Cleanup fb_info in .fb_destroy rather than .remove
  fbdev: efifb: Fix a use-after-free due early fb_info cleanup

Maarten Lankhorst (1):
  Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes

Robin Murphy (1):
  drm/nouveau/tegra: Stop using iommu_present()

 drivers/dma-buf/dma-buf.c  | 8 
 drivers/gpu/drm/nouveau/nouveau_backlight.c| 9 +
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
 drivers/gpu/drm/vc4/vc4_hdmi.c | 1 +
 drivers/video/fbdev/core/fbmem.c   | 5 +
 drivers/video/fbdev/core/fbsysfs.c | 4 
 drivers/video/fbdev/efifb.c| 9 -
 drivers/video/fbdev/simplefb.c | 8 +++-
 drivers/video/fbdev/vesafb.c   | 8 +++-
 9 files changed, 38 insertions(+), 16 deletions(-)


signature.asc
Description: PGP signature

[PATCH] drm/amd/display: Remove macro DC_DEFAULT_LOG_MASK

[pengfuyuan]

[Why]
The DC_DEFAULT_LOG_MASK macro has not been used for a long time, so remove it.

Signed-off-by: pengfuyuan 
---
 .../drm/amd/display/include/logger_types.h| 33 ---
 1 file changed, 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/include/logger_types.h 
b/drivers/gpu/drm/amd/display/include/logger_types.h
index f093b49c5e6e..1b38cfc41718 100644
--- a/drivers/gpu/drm/amd/display/include/logger_types.h
+++ b/drivers/gpu/drm/amd/display/include/logger_types.h
@@ -131,37 +131,4 @@ enum dc_log_type {
 #define DC_MIN_LOG_MASK ((1 << LOG_ERROR) | \
(1 << LOG_DETECTION_EDID_PARSER))
 
-#define DC_DEFAULT_LOG_MASK ((1ULL << LOG_ERROR) | \
-   (1ULL << LOG_WARNING) | \
-   (1ULL << LOG_EVENT_MODE_SET) | \
-   (1ULL << LOG_EVENT_DETECTION) | \
-   (1ULL << LOG_EVENT_LINK_TRAINING) | \
-   (1ULL << LOG_EVENT_LINK_LOSS) | \
-   (1ULL << LOG_EVENT_UNDERFLOW) | \
-   (1ULL << LOG_RESOURCE) | \
-   (1ULL << LOG_FEATURE_OVERRIDE) | \
-   (1ULL << LOG_DETECTION_EDID_PARSER) | \
-   (1ULL << LOG_DC) | \
-   (1ULL << LOG_HW_HOTPLUG) | \
-   (1ULL << LOG_HW_SET_MODE) | \
-   (1ULL << LOG_HW_RESUME_S3) | \
-   (1ULL << LOG_HW_HPD_IRQ) | \
-   (1ULL << LOG_SYNC) | \
-   (1ULL << LOG_BANDWIDTH_VALIDATION) | \
-   (1ULL << LOG_MST) | \
-   (1ULL << LOG_DETECTION_DP_CAPS) | \
-   (1ULL << LOG_BACKLIGHT)) | \
-   (1ULL << LOG_I2C_AUX) | \
-   (1ULL << LOG_IF_TRACE) | \
-   (1ULL << LOG_HDMI_FRL) | \
-   (1ULL << LOG_SCALER) | \
-   (1ULL << LOG_DTN) /* | \
-   (1ULL << LOG_DEBUG) | \
-   (1ULL << LOG_BIOS) | \
-   (1ULL << LOG_SURFACE) | \
-   (1ULL << LOG_DML) | \
-   (1ULL << LOG_HW_LINK_TRAINING) | \
-   (1ULL << LOG_HW_AUDIO)| \
-   (1ULL << LOG_BANDWIDTH_CALCS)*/
-
 #endif /* __DAL_LOGGER_TYPES_H__ */
-- 
2.25.1