Re: [PATCH 2/4] fbdev/stifb: Allocate fb_info instance with framebuffer_alloc()

[Thomas Zimmermann]

Hi Helge

Am 30.12.23 um 09:35 schrieb Helge Deller:

Hi Thomas,

On 12/20/23 14:22, Thomas Zimmermann wrote:

Allocate stifb's instance of fb_info with framebuffer_alloc(). This
is the preferred way of creating fb_info with associated driver data
stored in struct fb_info.par. Requires several, but minor, changes
through out the driver's code.

The intended side effect of this patch is that the new instance of
struct fb_info now has its device field correctly set to the parent
device of the STI ROM. A later patch can detect if the device is the
firmware's primary output. It is also now correctly located within
the Linux device hierarchy.


Thanks for this cleanup series!
Sadly stifb then crashes at bootup.

Please include this copy&pasted hunk in this patch, which then fixes the 
crash:


diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 2de0e675fd15..f8bbd8d6f5b2 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1158,7 +1158,7 @@ stifb_init_display(struct stifb_info *fb)
     }
     break;
     }
-   stifb_blank(0, (struct fb_info *)fb);   /* 0=enable screen */
+   stifb_blank(0, fb->info);   /* 0=enable screen */



With this applied, you may add to the series:

Tested-by: Helge Deller 
Reviewed-by: Helge Deller 


Thanks so much for testing and fixing the problem.

Which tree should this go through?

Best regards
Thomas



Thanks!
Helge



Signed-off-by: Thomas Zimmermann 
---
  drivers/video/fbdev/stifb.c | 106 +++-
  1 file changed, 56 insertions(+), 50 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 548d992f8cb1..36e6bcab83aa 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -103,7 +103,7 @@ typedef struct {
  } ngle_rom_t;

  struct stifb_info {
-    struct fb_info info;
+    struct fb_info *info;
  unsigned int id;
  ngle_rom_t ngle_rom;
  struct sti_struct *sti;
@@ -153,15 +153,15 @@ static int __initdata stifb_bpp_pref[MAX_STI_ROMS];
  #define REG_44    0x210030
  #define REG_45    0x210034

-#define READ_BYTE(fb,reg)    gsc_readb((fb)->info.fix.mmio_start 
+ (reg))
-#define READ_WORD(fb,reg)    gsc_readl((fb)->info.fix.mmio_start 
+ (reg))
+#define READ_BYTE(fb, reg)
gsc_readb((fb)->info->fix.mmio_start + (reg))
+#define READ_WORD(fb, reg)
gsc_readl((fb)->info->fix.mmio_start + (reg))



  #ifndef DEBUG_STIFB_REGS
  # define  DEBUG_OFF()
  # define  DEBUG_ON()
-# define WRITE_BYTE(value,fb,reg)
gsc_writeb((value),(fb)->info.fix.mmio_start + (reg))
-# define WRITE_WORD(value,fb,reg)
gsc_writel((value),(fb)->info.fix.mmio_start + (reg))
+# define WRITE_BYTE(value, fb, reg)    gsc_writeb((value), 
(fb)->info->fix.mmio_start + (reg))
+# define WRITE_WORD(value, fb, reg)    gsc_writel((value), 
(fb)->info->fix.mmio_start + (reg))

  #else
    static int debug_on = 1;
  # define  DEBUG_OFF() debug_on=0
@@ -169,11 +169,11 @@ static int __initdata stifb_bpp_pref[MAX_STI_ROMS];
  # define WRITE_BYTE(value,fb,reg)    do { if (debug_on) \
  printk(KERN_DEBUG "%30s: WRITE_BYTE(0x%06x) 
= 0x%02x (old=0x%02x)\n", \
  __func__, reg, value, 
READ_BYTE(fb,reg));   \
-    gsc_writeb((value),(fb)->info.fix.mmio_start + 
(reg)); } while (0)
+    gsc_writeb((value), (fb)->info->fix.mmio_start + 
(reg)); } while (0)

  # define WRITE_WORD(value,fb,reg)    do { if (debug_on) \
  printk(KERN_DEBUG "%30s: WRITE_WORD(0x%06x) 
= 0x%08x (old=0x%08x)\n", \
  __func__, reg, value, 
READ_WORD(fb,reg));   \
-    gsc_writel((value),(fb)->info.fix.mmio_start + 
(reg)); } while (0)
+    gsc_writel((value), (fb)->info->fix.mmio_start + 
(reg)); } while (0)

  #endif /* DEBUG_STIFB_REGS */


@@ -210,13 +210,13 @@ SETUP_FB(struct stifb_info *fb)
  reg10_value = 0x13601000;
  break;
  case S9000_ID_A1439A:
-    if (fb->info.var.bits_per_pixel == 32)
+    if (fb->info->var.bits_per_pixel == 32)
  reg10_value = 0xBBA0A000;
  else
  reg10_value = 0x13601000;
  break;
  case S9000_ID_HCRX:
-    if (fb->info.var.bits_per_pixel == 32)
+    if (fb->info->var.bits_per_pixel == 32)
  reg10_value = 0xBBA0A000;
  else
  reg10_value = 0x13602000;
@@ -254,7 +254,7 @@ static void
  FINISH_IMAGE_COLORMAP_ACCESS(struct stifb_info *fb)
  {
  WRITE_WORD(0x400, fb, REG_2);
-    if (fb->info.var.bits_per_pixel == 32) {
+    if (fb->info->var.bits_per_pixel == 32) {
  WRITE_WORD(0x83000100, fb, REG_1);
  } else {
  if (fb->id == S9000_ID_ARTIST || fb->id == CRT_ID_VISUALIZE_EG)
@@ -503,7 +503,7 @@ static void
  ngleSetupAttrPlanes(struct stif

Re: [PATCH v4 12/17] drm/mediatek: Support CRC in display driver

[胡俊光]

Re: [PATCH v4 16/17] drm/mediatek: Fix errors when reporting rotation capability

[胡俊光]

Re: [PATCH 27/27] fbdev/p9100: Drop now unused driver p9100

[Thomas Zimmermann]

Hi Sam

Am 19.12.23 um 23:03 schrieb Sam Ravnborg via B4 Relay:

From: Sam Ravnborg 

The p9100 driver is only relevant for the Sparcbook 3 machine,
and with sun4m support removed this driver is no longer relevant.

Signed-off-by: Sam Ravnborg 
Cc: "David S. Miller" 
Cc: Arnd Bergmann 
Cc: Andreas Larsson 
Cc: Helge Deller 


Thanks for cleaning up.

Ack-by: Thomas Zimmermann 

if the series is accepted.

Best regards
Thomas


---
  drivers/video/fbdev/Kconfig  |   8 -
  drivers/video/fbdev/Makefile |   1 -
  drivers/video/fbdev/p9100.c  | 372 ---
  3 files changed, 381 deletions(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 94f6dca5856f..ebcc3815c7a5 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -576,14 +576,6 @@ config FB_CG14
  This is the frame buffer device driver for the CGfourteen frame
  buffer on Desktop SPARCsystems with the SX graphics option.
  
-config FB_P9100

-   bool "P9100 (Sparcbook 3 only) support"
-   depends on FB_SBUS
-   select FB_SBUS_HELPERS
-   help
- This is the frame buffer device driver for the P9100 card
- supported on Sparcbook 3 machines.
-
  config FB_LEO
bool "Leo (ZX) support"
depends on FB_SBUS
diff --git a/drivers/video/fbdev/Makefile b/drivers/video/fbdev/Makefile
index 8e15220152bd..bc9b24648347 100644
--- a/drivers/video/fbdev/Makefile
+++ b/drivers/video/fbdev/Makefile
@@ -51,7 +51,6 @@ obj-$(CONFIG_FB_CG6)  += cg6.o
  obj-$(CONFIG_FB_CG3)  += cg3.o
  obj-$(CONFIG_FB_BW2)  += bw2.o
  obj-$(CONFIG_FB_CG14) += cg14.o
-obj-$(CONFIG_FB_P9100)+= p9100.o
  obj-$(CONFIG_FB_TCX)  += tcx.o
  obj-$(CONFIG_FB_LEO)  += leo.o
  obj-$(CONFIG_FB_ACORN)+= acornfb.o
diff --git a/drivers/video/fbdev/p9100.c b/drivers/video/fbdev/p9100.c
deleted file mode 100644
index e1356f8a866e..
--- a/drivers/video/fbdev/p9100.c
+++ /dev/null
@@ -1,372 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/* p9100.c: P9100 frame buffer driver
- *
- * Copyright (C) 2003, 2006 David S. Miller (da...@davemloft.net)
- * Copyright 1999 Derrick J Brashear (sha...@dementia.org)
- *
- * Driver layout based loosely on tgafb.c, see that file for credits.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include "sbuslib.h"
-
-/*
- * Local functions.
- */
-
-static int p9100_setcolreg(unsigned, unsigned, unsigned, unsigned,
-  unsigned, struct fb_info *);
-static int p9100_blank(int, struct fb_info *);
-
-static int p9100_sbusfb_mmap(struct fb_info *info, struct vm_area_struct *vma);
-static int p9100_sbusfb_ioctl(struct fb_info *info, unsigned int cmd, unsigned 
long arg);
-
-/*
- *  Frame buffer operations
- */
-
-static const struct fb_ops p9100_ops = {
-   .owner  = THIS_MODULE,
-   FB_DEFAULT_SBUS_OPS(p9100),
-   .fb_setcolreg   = p9100_setcolreg,
-   .fb_blank   = p9100_blank,
-};
-
-/* P9100 control registers */
-#define P9100_SYSCTL_OFF   0x0UL
-#define P9100_VIDEOCTL_OFF 0x100UL
-#define P9100_VRAMCTL_OFF  0x180UL
-#define P9100_RAMDAC_OFF   0x200UL
-#define P9100_VIDEOCOPROC_OFF  0x400UL
-
-/* P9100 command registers */
-#define P9100_CMD_OFF 0x0UL
-
-/* P9100 framebuffer memory */
-#define P9100_FB_OFF 0x0UL
-
-/* 3 bits: 2=8bpp 3=16bpp 5=32bpp 7=24bpp */
-#define SYS_CONFIG_PIXELSIZE_SHIFT 26
-
-#define SCREENPAINT_TIMECTL1_ENABLE_VIDEO 0x20 /* 0 = off, 1 = on */
-
-struct p9100_regs {
-   /* Registers for the system control */
-   u32 sys_base;
-   u32 sys_config;
-   u32 sys_intr;
-   u32 sys_int_ena;
-   u32 sys_alt_rd;
-   u32 sys_alt_wr;
-   u32 sys_xxx[58];
-
-   /* Registers for the video control */
-   u32 vid_base;
-   u32 vid_hcnt;
-   u32 vid_htotal;
-   u32 vid_hsync_rise;
-   u32 vid_hblank_rise;
-   u32 vid_hblank_fall;
-   u32 vid_hcnt_preload;
-   u32 vid_vcnt;
-   u32 vid_vlen;
-   u32 vid_vsync_rise;
-   u32 vid_vblank_rise;
-   u32 vid_vblank_fall;
-   u32 vid_vcnt_preload;
-   u32 vid_screenpaint_addr;
-   u32 vid_screenpaint_timectl1;
-   u32 vid_screenpaint_qsfcnt;
-   u32 vid_screenpaint_timectl2;
-   u32 vid_xxx[15];
-
-   /* Registers for the video control */
-   u32 vram_base;
-   u32 vram_memcfg;
-   u32 vram_refresh_pd;
-   u32 vram_refresh_cnt;
-   u32 vram_raslo_max;
-   u32 vram_raslo_cur;
-   u32 pwrup_cfg;
-   u32 vram_xxx[25];
-
-   /* Registers for IBM RGB528 Palette */
-   u32 ramdac_cmap_wridx;
-   u32 ramdac_palette_data;
-   u32 ramdac_pixel_mask;
-   u32 ramdac_palette_rdaddr;
-   u32 ramdac_idx_lo;
-   u32 ramdac_idx_hi;
-   u3

[PATCH][next] drm/xe: Fix spelling mistake "gueue" -> "queue"

[Colin Ian King]

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

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

diff --git a/drivers/gpu/drm/xe/xe_wait_user_fence.c 
b/drivers/gpu/drm/xe/xe_wait_user_fence.c
index b0a7896f7fcb..b3ccdcf40557 100644
--- a/drivers/gpu/drm/xe/xe_wait_user_fence.c
+++ b/drivers/gpu/drm/xe/xe_wait_user_fence.c
@@ -147,7 +147,7 @@ int xe_wait_user_fence_ioctl(struct drm_device *dev, void 
*data,
 
if (q) {
if (q->ops->reset_status(q)) {
-   drm_info(&xe->drm, "exec gueue reset 
detected\n");
+   drm_info(&xe->drm, "exec queue reset 
detected\n");
err = -EIO;
break;
}
-- 
2.39.2

[PATCH v3] drm/ci: add tests on vkms

[Vignesh Raman]

From: Helen Koike 

Add job that runs igt on top of vkms.

Signed-off-by: Vignesh Raman 
Acked-by: Jessica Zhang 
Tested-by: Jessica Zhang 
Acked-by: Maxime Ripard 
Signed-off-by: Helen Koike 
---

v2:
- do not mv modules to /lib/modules in the job definition, leave it to
  crosvm-runner.sh

v3:
- Enable CONFIG_DRM_VKMS in x86_64.config and update xfails

---
 MAINTAINERS   |  1 +
 drivers/gpu/drm/ci/gitlab-ci.yml  |  1 +
 drivers/gpu/drm/ci/image-tags.yml |  4 +--
 drivers/gpu/drm/ci/test.yml   | 22 +
 drivers/gpu/drm/ci/x86_64.config  |  1 +
 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt | 33 +++
 .../gpu/drm/ci/xfails/vkms-none-flakes.txt|  9 +
 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt | 14 
 8 files changed, 83 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
 create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-flakes.txt
 create mode 100644 drivers/gpu/drm/ci/xfails/vkms-none-skips.txt

diff --git a/MAINTAINERS b/MAINTAINERS
index 9d959a6881f7..2c1593aa436f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6922,6 +6922,7 @@ L:dri-devel@lists.freedesktop.org
 S: Maintained
 T: git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/gpu/vkms.rst
+F: drivers/gpu/drm/ci/xfails/vkms*
 F: drivers/gpu/drm/vkms/
 
 DRM DRIVER FOR VIRTUALBOX VIRTUAL GPU
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 084e3ff8e3f4..4b636d39734c 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -108,6 +108,7 @@ stages:
   - rockchip
   - virtio-gpu
   - lint
+  - software-driver
 
 # YAML anchors for rule conditions
 # 
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml
index 7ab4f2514da8..bfa70f8cdf57 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
-   DEBIAN_BUILD_TAG: "2023-10-08-config"
+   DEBIAN_BUILD_TAG: "2024-01-02-vkms"
 
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
 
@@ -12,4 +12,4 @@ variables:
DEBIAN_X86_64_TEST_IMAGE_GL_PATH: "debian/x86_64_test-gl"
DEBIAN_X86_64_TEST_GL_TAG: "${CONTAINER_TAG}"
 
-   ALPINE_X86_64_LAVA_SSH_TAG: "${CONTAINER_TAG}"
\ No newline at end of file
+   ALPINE_X86_64_LAVA_SSH_TAG: "${CONTAINER_TAG}"
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 1705f268547a..a079f3632a95 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -337,3 +337,25 @@ virtio_gpu:none:
 - debian/x86_64_test-gl
 - testing:x86_64
 - igt:x86_64
+
+vkms:none:
+  stage: software-driver
+  variables:
+DRIVER_NAME: vkms
+GPU_VERSION: none
+  extends:
+- .test-gl
+- .test-rules
+  tags:
+- kvm
+  script:
+- ln -sf $CI_PROJECT_DIR/install /install
+- mv install/bzImage /lava-files/bzImage
+- mkdir -p /lib/modules
+- mkdir -p $CI_PROJECT_DIR/results
+- ln -sf $CI_PROJECT_DIR/results /results
+- ./install/crosvm-runner.sh ./install/igt_runner.sh
+  needs:
+- debian/x86_64_test-gl
+- testing:x86_64
+- igt:x86_64
diff --git a/drivers/gpu/drm/ci/x86_64.config b/drivers/gpu/drm/ci/x86_64.config
index 1cbd49a5b23a..ab4dcca749cc 100644
--- a/drivers/gpu/drm/ci/x86_64.config
+++ b/drivers/gpu/drm/ci/x86_64.config
@@ -24,6 +24,7 @@ CONFIG_DRM=y
 CONFIG_DRM_PANEL_SIMPLE=y
 CONFIG_PWM_CROS_EC=y
 CONFIG_BACKLIGHT_PWM=y
+CONFIG_DRM_VKMS=y
 
 # Strip out some stuff we don't need for graphics testing, to reduce
 # the build.
diff --git a/drivers/gpu/drm/ci/xfails/vkms-none-fails.txt 
b/drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
new file mode 100644
index ..ce8c93008d7e
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/vkms-none-fails.txt
@@ -0,0 +1,33 @@
+kms_cursor_crc@cursor-rapid-movement-128x128,Fail
+kms_cursor_crc@cursor-rapid-movement-128x42,Fail
+kms_cursor_crc@cursor-rapid-movement-256x256,Fail
+kms_cursor_crc@cursor-rapid-movement-256x85,Fail
+kms_cursor_crc@cursor-rapid-movement-32x10,Fail
+kms_cursor_crc@cursor-rapid-movement-32x32,Fail
+kms_cursor_crc@cursor-rapid-movement-512x170,Fail
+kms_cursor_crc@cursor-rapid-movement-512x512,Fail
+kms_cursor_crc@cursor-rapid-movement-64x21,Fail
+kms_cursor_crc@cursor-rapid-movement-64x64,Fail
+kms_cursor_legacy@basic-flip-before-cursor-atomic,Fail
+kms_cursor_legacy@basic-flip-before-cursor-legacy,Fail
+kms_cursor_legacy@cursor-vs-flip-atomic,Fail
+kms_cursor_legacy@cursor-vs-flip-legacy,Fail
+kms_cursor_legacy@cursor-vs-flip-toggle,Fail
+kms_cursor_legacy@cursor-vs-flip-varying-size,Fail
+kms_cursor_legacy@cursorA-vs-flipA-legacy,Fail
+kms_cursor_legacy@flip-vs-cursor-atomic,Fail
+kms_cursor_legacy@flip-vs-cursor-crc-atomic,Fail
+kms_cursor

[PATCH v2 0/4] arch/parisc: Detect primary framebuffer from device

[Thomas Zimmermann]

On parisc, change detection of the primary framebuffer to test for
the Linux device instead of fbdev's fb_info in fb_is_primary_device().
Makes the test independent from fbdev.

This patchset is part of a larger effort to clean up the low-level
display handling. There are various functions that attempt to detect
the system's primary framebuffer device, such as in vgaarb, [1]
fbcon, [2] or fbmon. [3] This code should be unified in a single helper
that implements the test. The function fb_is_primary_device() already
does this, but requires fbdev on parisc. With the patchset applied, the
parisc implementation tests directly with the Linux device. No fbdev is
required.

Patch 1 adds the framebuffer's Linux device to the STI ROM structures,
which represents the graphics firmware. Patches 2 updates the stifb
driver to refer to the correct Linux device. The device is used in
patch 3 to change the test in fb_is_primary_device(). Patch 4 removes
the obsolete fb_info from the STI ROM structures.

A later patchset will update the interface of fb_is_primary_device() to
receive a Linux device instead of an instance of fb_info. This involves
several architectures, so it is better done in a separate patch.

[1] https://elixir.bootlin.com/linux/v6.6/source/drivers/pci/vgaarb.c#L557
[2] 
https://elixir.bootlin.com/linux/v6.6/source/drivers/video/fbdev/core/fbcon.c#L2943
[3] 
https://elixir.bootlin.com/linux/v6.6/source/drivers/video/fbdev/core/fbmon.c#L1503

v2:
* fix crash during driver initialization (Helge)

Thomas Zimmermann (4):
  video/sticore: Store ROM device in STI struct
  fbdev/stifb: Allocate fb_info instance with framebuffer_alloc()
  arch/parisc: Detect primary video device from device instance
  video/sticore: Remove info field from STI struct

 arch/parisc/video/fbdev.c   |   2 +-
 drivers/video/fbdev/stifb.c | 111 ++--
 drivers/video/sticore.c |   5 ++
 include/video/sticore.h |   6 +-
 4 files changed, 66 insertions(+), 58 deletions(-)


base-commit: 25232eb8a9ac7fa0dac7e846a4bf7fba2b6db39a
-- 
2.43.0

[PATCH v2 1/4] video/sticore: Store ROM device in STI struct

[Thomas Zimmermann]

Store the ROM's parent device in each STI struct, so we can associate
the STI framebuffer with a device.

The new field will eventually replace the fbdev subsystem's info field,
which the function fb_is_primary_device() currently requires to detect
the firmware's output. By using the device instead of the framebuffer
info, a later patch can generalize the helper for use in non-fbdev code.

Signed-off-by: Thomas Zimmermann 
Tested-by: Helge Deller 
Reviewed-by: Helge Deller 
---
 drivers/video/sticore.c | 5 +
 include/video/sticore.h | 4 
 2 files changed, 9 insertions(+)

diff --git a/drivers/video/sticore.c b/drivers/video/sticore.c
index c3765ad6eedf..7115b325817f 100644
--- a/drivers/video/sticore.c
+++ b/drivers/video/sticore.c
@@ -1041,6 +1041,9 @@ static int __init sticore_pa_init(struct parisc_device 
*dev)
 
print_pa_hwpath(dev, sti->pa_path);
sticore_check_for_default_sti(sti, sti->pa_path);
+
+   sti->dev = &dev->dev;
+
return 0;
 }
 
@@ -1084,6 +1087,8 @@ static int sticore_pci_init(struct pci_dev *pd, const 
struct pci_device_id *ent)
pr_warn("Unable to handle STI device '%s'\n", pci_name(pd));
return -ENODEV;
}
+
+   sti->dev = &pd->dev;
 #endif /* CONFIG_PCI */
 
return 0;
diff --git a/include/video/sticore.h b/include/video/sticore.h
index 012b5b46ad7d..9d993e22805d 100644
--- a/include/video/sticore.h
+++ b/include/video/sticore.h
@@ -2,6 +2,7 @@
 #ifndef STICORE_H
 #define STICORE_H
 
+struct device;
 struct fb_info;
 
 /* generic STI structures & functions */
@@ -370,6 +371,9 @@ struct sti_struct {
/* pointer to the fb_info where this STI device is used */
struct fb_info *info;
 
+   /* pointer to the parent device */
+   struct device *dev;
+
/* pointer to all internal data */
struct sti_all_data *sti_data;
 
-- 
2.43.0

[PATCH v2 4/4] video/sticore: Remove info field from STI struct

[Thomas Zimmermann]

The info field in struct sti_struct was used to detect the default
display device. That test is now done with the respective Linux device
and the info field is unused. Remove it.

Signed-off-by: Thomas Zimmermann 
Tested-by: Helge Deller 
Reviewed-by: Helge Deller 
---
 drivers/video/fbdev/stifb.c | 3 ---
 include/video/sticore.h | 4 
 2 files changed, 7 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 9954640faae6..8e5bac27542d 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -1389,7 +1389,6 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
}
 
/* save for primary gfx device detection & unregister_framebuffer() */
-   sti->info = info;
if (register_framebuffer(fb->info) < 0)
goto out_err4;
 
@@ -1417,7 +1416,6 @@ static int __init stifb_init_fb(struct sti_struct *sti, 
int bpp_pref)
iounmap(info->screen_base);
 out_err0:
framebuffer_release(info);
-   sti->info = NULL;
return -ENXIO;
 }
 
@@ -1496,7 +1494,6 @@ stifb_cleanup(void)
framebuffer_release(info);
dev_set_drvdata(sti->dev, NULL);
}
-   sti->info = NULL;
}
 }
 
diff --git a/include/video/sticore.h b/include/video/sticore.h
index 9d993e22805d..823666af1871 100644
--- a/include/video/sticore.h
+++ b/include/video/sticore.h
@@ -3,7 +3,6 @@
 #define STICORE_H
 
 struct device;
-struct fb_info;
 
 /* generic STI structures & functions */
 
@@ -368,9 +367,6 @@ struct sti_struct {
/* PCI data structures (pg. 17ff from sti.pdf) */
u8 rm_entry[16]; /* pci region mapper array == pci config space offset 
*/
 
-   /* pointer to the fb_info where this STI device is used */
-   struct fb_info *info;
-
/* pointer to the parent device */
struct device *dev;
 
-- 
2.43.0

[PATCH v2 3/4] arch/parisc: Detect primary video device from device instance

[Thomas Zimmermann]

Update fb_is_primary device() on parisc to detect the primary display
device from the Linux device instance. Aligns the code with the other
architectures. A later patch will remove the fbdev dependency from the
function's interface.

Signed-off-by: Thomas Zimmermann 
Tested-by: Helge Deller 
Reviewed-by: Helge Deller 
---
 arch/parisc/video/fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/parisc/video/fbdev.c b/arch/parisc/video/fbdev.c
index 137561d98246..e4f8ac99fc9e 100644
--- a/arch/parisc/video/fbdev.c
+++ b/arch/parisc/video/fbdev.c
@@ -21,6 +21,6 @@ int fb_is_primary_device(struct fb_info *info)
return true;
 
/* return true if it's the default built-in framebuffer driver */
-   return (sti->info == info);
+   return (sti->dev == info->device);
 }
 EXPORT_SYMBOL(fb_is_primary_device);
-- 
2.43.0

[PATCH v2 2/4] fbdev/stifb: Allocate fb_info instance with framebuffer_alloc()

[Thomas Zimmermann]

Allocate stifb's fb_info instance with framebuffer_alloc(). This is
the prefered way of creating fb_info with associated driver data in
struct fb_info.par. Requires some minor changes through out the driver's
code.

The intended side effect of this patch is that the new instance of
struct fb_info now has its device field correctly set to the parent
device of the STI ROM. It's now correctly located within the Linux
device hierarchy and a later patch can detect if it's the firmware's
primary output.

v2:
* fix crash during driver initialization (Helge)

Signed-off-by: Thomas Zimmermann 
Tested-by: Helge Deller 
Reviewed-by: Helge Deller 
---
 drivers/video/fbdev/stifb.c | 108 +++-
 1 file changed, 57 insertions(+), 51 deletions(-)

diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 548d992f8cb1..9954640faae6 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -103,7 +103,7 @@ typedef struct {
 } ngle_rom_t;
 
 struct stifb_info {
-   struct fb_info info;
+   struct fb_info *info;
unsigned int id;
ngle_rom_t ngle_rom;
struct sti_struct *sti;
@@ -153,15 +153,15 @@ static int __initdata stifb_bpp_pref[MAX_STI_ROMS];
 #define REG_44 0x210030
 #define REG_45 0x210034
 
-#define READ_BYTE(fb,reg)  gsc_readb((fb)->info.fix.mmio_start + 
(reg))
-#define READ_WORD(fb,reg)  gsc_readl((fb)->info.fix.mmio_start + 
(reg))
+#define READ_BYTE(fb, reg) gsc_readb((fb)->info->fix.mmio_start + 
(reg))
+#define READ_WORD(fb, reg) gsc_readl((fb)->info->fix.mmio_start + 
(reg))
 
 
 #ifndef DEBUG_STIFB_REGS
 # define  DEBUG_OFF()
 # define  DEBUG_ON()
-# define WRITE_BYTE(value,fb,reg)  
gsc_writeb((value),(fb)->info.fix.mmio_start + (reg))
-# define WRITE_WORD(value,fb,reg)  
gsc_writel((value),(fb)->info.fix.mmio_start + (reg))
+# define WRITE_BYTE(value, fb, reg)gsc_writeb((value), 
(fb)->info->fix.mmio_start + (reg))
+# define WRITE_WORD(value, fb, reg)gsc_writel((value), 
(fb)->info->fix.mmio_start + (reg))
 #else
   static int debug_on = 1;
 # define  DEBUG_OFF() debug_on=0
@@ -169,11 +169,11 @@ static int __initdata stifb_bpp_pref[MAX_STI_ROMS];
 # define WRITE_BYTE(value,fb,reg)  do { if (debug_on) \
printk(KERN_DEBUG "%30s: 
WRITE_BYTE(0x%06x) = 0x%02x (old=0x%02x)\n", \
__func__, reg, value, 
READ_BYTE(fb,reg)); \
-   
gsc_writeb((value),(fb)->info.fix.mmio_start + (reg)); } while (0)
+   gsc_writeb((value), 
(fb)->info->fix.mmio_start + (reg)); } while (0)
 # define WRITE_WORD(value,fb,reg)  do { if (debug_on) \
printk(KERN_DEBUG "%30s: 
WRITE_WORD(0x%06x) = 0x%08x (old=0x%08x)\n", \
__func__, reg, value, 
READ_WORD(fb,reg)); \
-   
gsc_writel((value),(fb)->info.fix.mmio_start + (reg)); } while (0)
+   gsc_writel((value), 
(fb)->info->fix.mmio_start + (reg)); } while (0)
 #endif /* DEBUG_STIFB_REGS */
 
 
@@ -210,13 +210,13 @@ SETUP_FB(struct stifb_info *fb)
reg10_value = 0x13601000;
break;
case S9000_ID_A1439A:
-   if (fb->info.var.bits_per_pixel == 32)
+   if (fb->info->var.bits_per_pixel == 32)
reg10_value = 0xBBA0A000;
else
reg10_value = 0x13601000;
break;
case S9000_ID_HCRX:
-   if (fb->info.var.bits_per_pixel == 32)
+   if (fb->info->var.bits_per_pixel == 32)
reg10_value = 0xBBA0A000;
else
reg10_value = 0x13602000;
@@ -254,7 +254,7 @@ static void
 FINISH_IMAGE_COLORMAP_ACCESS(struct stifb_info *fb)
 {
WRITE_WORD(0x400, fb, REG_2);
-   if (fb->info.var.bits_per_pixel == 32) {
+   if (fb->info->var.bits_per_pixel == 32) {
WRITE_WORD(0x83000100, fb, REG_1);
} else {
if (fb->id == S9000_ID_ARTIST || fb->id == CRT_ID_VISUALIZE_EG)
@@ -503,7 +503,7 @@ static void
 ngleSetupAttrPlanes(struct stifb_info *fb, int BufferNumber)
 {
SETUP_ATTR_ACCESS(fb, BufferNumber);
-   SET_ATTR_SIZE(fb, fb->info.var.xres, fb->info.var.yres);
+   SET_ATTR_SIZE(fb, fb->info->var.xres, fb->info->var.yres);
FINISH_ATTR_ACCESS(fb);
SETUP_FB(fb);
 }
@@ -526,9 +526,9 @@ rattlerSetupPlanes(struct stifb_info *fb)
SETUP_FB(fb);
fb->id = saved_id;
 
-   for (y = 0; y < fb->info.var.yres; ++y)
-   

Re: RPI4B: what is needed for /dev/video10 to work ( v4l_m2m )

[Maxime Ripard]

Hi,

On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
> I have a RPI4B with upstream kernel 6.1 64bit and there is no /dev/video10
> present. I thought if I waited a bit more, it would appear in the kernel,
> but that was folly on my part.
> 
> Currently, watching a movie is painful since the software decoding is way
> too slow and it has very low fps on 1080p (or even 720p or even 480p)
> 
> IIRC, someone told me something else has to be fixed before the codecs can
> be done, but I don't remember what it was, or i didn't find it in my
> email/the archives.
> 
> Can someone tell me what exactly needs to be done (in kernel) so that I can
> take a crack at it, (hopefully with some help)?
> 
> I don't remember if this was relevant, but there was some talk of needing to
> use opengl output with a specific texture format for it to work? or is that
> seperate?

That's something for linux-media. The hardware codec isn't part of vc4
or v3d, it's a separate controller that requires a separate driver (in
v4l2).

That driver isn't upstream, and that would need the first thing to
tackle.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH] drm/vmwgfx: Unmap the surface before resetting it on a plane state

[Javier Martinez Canillas]

Zack Rusin  writes:

Hello Zack,

> Switch to a new plane state requires unreferencing of all held surfaces.
> In the work required for mob cursors the mapped surfaces started being
> cached but the variable indicating whether the surface is currently
> mapped was not being reset. This leads to crashes as the duplicated
> state, incorrectly, indicates the that surface is mapped even when
> no surface is present. That's because after unreferencing the surface
> it's perfectly possible for the plane to be backed by a bo instead of a
> surface.
>
> Reset the surface mapped flag when unreferencing the plane state surface
> to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:
>
> Oops:  [#1] PREEMPT SMP PTI
> CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2
> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference 
> Platform, BIOS 6.00 11/12/2020
> RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
> Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
> c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
> RSP: 0018:b6b98216fa80 EFLAGS: 00010246
> RAX:  RBX: 969d84cdcb00 RCX: 0027
> RDX:  RSI: 0001 RDI: 969e75f21600
> RBP: 969d4143dc50 R08:  R09: b6b98216f920
> R10: 0003 R11: 969e7feb3b10 R12: 
> R13:  R14: 027b R15: 969d49c9fc00
> FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0028 CR3: 000104006004 CR4: 003706f0
> Call Trace:
>  
>  ? __die+0x23/0x70
>  ? page_fault_oops+0x171/0x4e0
>  ? exc_page_fault+0x7f/0x180
>  ? asm_exc_page_fault+0x26/0x30
>  ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
>  drm_atomic_helper_cleanup_planes+0x9b/0xc0
>  commit_tail+0xd1/0x130
>  drm_atomic_helper_commit+0x11a/0x140
>  drm_atomic_commit+0x97/0xd0
>  ? __pfx___drm_printfn_info+0x10/0x10
>  drm_atomic_helper_update_plane+0xf5/0x160
>  drm_mode_cursor_universal+0x10e/0x270
>  drm_mode_cursor_common+0x102/0x230
>  ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
>  drm_ioctl_kernel+0xb2/0x110
>  drm_ioctl+0x26d/0x4b0
>  ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10
>  ? __pfx_drm_ioctl+0x10/0x10
>  vmw_generic_ioctl+0xa4/0x110 [vmwgfx]
>  __x64_sys_ioctl+0x94/0xd0
>  do_syscall_64+0x61/0xe0
>  ? __x64_sys_ioctl+0xaf/0xd0
>  ? syscall_exit_to_user_mode+0x2b/0x40
>  ? do_syscall_64+0x70/0xe0
>  ? __x64_sys_ioctl+0xaf/0xd0
>  ? syscall_exit_to_user_mode+0x2b/0x40
>  ? do_syscall_64+0x70/0xe0
>  ? exc_page_fault+0x7f/0x180
>  entry_SYSCALL_64_after_hwframe+0x6e/0x76
> RIP: 0033:0x7f1e93f279ed
> Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 
> 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>
> RSP: 002b:7ffca0faf600 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: 55db876ed2c0 RCX: 7f1e93f279ed
> RDX: 7ffca0faf6c0 RSI: c02464bb RDI: 0015
> RBP: 7ffca0faf650 R08: 55db87184010 R09: 0007
> R10: 55db886471a0 R11: 0246 R12: 7ffca0faf6c0
> R13: c02464bb R14: 0015 R15: 7ffca0faf790
>  
> Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns 
> nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib 
> nft_reject_ine>
> CR2: 0028
> ---[ end trace  ]---
> RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]
> Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 
> c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>
> RSP: 0018:b6b98216fa80 EFLAGS: 00010246
> RAX:  RBX: 969d84cdcb00 RCX: 0027
> RDX:  RSI: 0001 RDI: 969e75f21600
> RBP: 969d4143dc50 R08:  R09: b6b98216f920
> R10: 0003 R11: 969e7feb3b10 R12: 
> R13:  R14: 027b R15: 969d49c9fc00
> FS:  7f1e8f1b4180() GS:969e75f0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 0028 CR3: 000104006004 CR4: 003706f0
>
> Signed-off-by: Zack Rusin 
> Fixes: 485d98d472d5 ("drm/vmwgfx: Add support for CursorMob and CursorBypass 
> 4")
> Reported-by: Stefan Hoffmeister 
> Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/34
> Cc: Martin Krastev 
> Cc: Maaz Mombasawala 
> Cc: Ian Forbes 
> Cc: Broadcom internal kernel review list 
> 
> Cc: dri-devel@lists.freedesktop.org
> Cc:  # v5.19+
> ---

I'm not familiar with this driver but your explanation in the commit
message is very clear and from inspecting the code, the change looks
correct to me.

Acked-by: Javier Martinez Canillas 

-- 
Be

Re: RPI4B: what is needed for /dev/video10 to work ( v4l_m2m )

[Dave Stevenson]

On Tue, 2 Jan 2024 at 10:03, Maxime Ripard  wrote:
>
> Hi,
>
> On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
> > I have a RPI4B with upstream kernel 6.1 64bit and there is no /dev/video10
> > present. I thought if I waited a bit more, it would appear in the kernel,
> > but that was folly on my part.
> >
> > Currently, watching a movie is painful since the software decoding is way
> > too slow and it has very low fps on 1080p (or even 720p or even 480p)
> >
> > IIRC, someone told me something else has to be fixed before the codecs can
> > be done, but I don't remember what it was, or i didn't find it in my
> > email/the archives.
> >
> > Can someone tell me what exactly needs to be done (in kernel) so that I can
> > take a crack at it, (hopefully with some help)?
> >
> > I don't remember if this was relevant, but there was some talk of needing to
> > use opengl output with a specific texture format for it to work? or is that
> > seperate?
>
> That's something for linux-media. The hardware codec isn't part of vc4
> or v3d, it's a separate controller that requires a separate driver (in
> v4l2).
>
> That driver isn't upstream, and that would need the first thing to
> tackle.

IdeasOnBoard are working on our behalf to clean up the VCHIQ driver in
staging (hopefully unstaging it), and adding the mmal-vchiq, vcsm, and
ISP drivers. 
https://patchwork.linuxtv.org/project/linux-media/list/?series=11633
is probably the latest revision of the series, but there are a number
of supporting series around too.

The codec driver relies on the same mmal-vchiq and vcsm drivers as the
ISP, so adding that afterwards should be relatively simple.

Even though he's stepped back from being a maintainer, Stefan Wahren
is still keeping track of a number of the upstreaming tasks for the Pi
platform - see https://github.com/lategoodbye/rpi-zero/issues/43

  Dave

[PATCH] drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modes

[Javier Martinez Canillas]

The helper is generic and doesn't use the opaque EDID type struct drm_edid
and is also used by drivers that only support non-probeable displays, such
as fixed panels.

These drivers add a list of modes using drm_mode_probed_add() and then set
a preferred mode using the drm_set_preferred_mode() helper.

It seems more logical to have the helper definition in drm_modes.o instead
of drm_edid.o, since the former contains modes helper while the latter has
helpers to manage the EDID information.

Since both drm_edid.o and drm_modes.o object files are built-in the drm.o
object, there are no functional changes. But besides being a more logical
place for this helper, it could also allow to eventually make drm_edid.o
optional and not included in drm.o if only fixed panels must be supported
in a given system.

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

 drivers/gpu/drm/drm_edid.c  | 23 +--
 drivers/gpu/drm/drm_modes.c | 22 ++
 include/drm/drm_edid.h  |  2 --
 include/drm/drm_modes.h |  2 ++
 4 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb4031d5dcbb..48dd2a0a0395 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "drm_crtc_internal.h"
@@ -6989,28 +6990,6 @@ int drm_add_modes_noedid(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_add_modes_noedid);
 
-/**
- * drm_set_preferred_mode - Sets the preferred mode of a connector
- * @connector: connector whose mode list should be processed
- * @hpref: horizontal resolution of preferred mode
- * @vpref: vertical resolution of preferred mode
- *
- * Marks a mode as preferred if it matches the resolution specified by @hpref
- * and @vpref.
- */
-void drm_set_preferred_mode(struct drm_connector *connector,
-  int hpref, int vpref)
-{
-   struct drm_display_mode *mode;
-
-   list_for_each_entry(mode, &connector->probed_modes, head) {
-   if (mode->hdisplay == hpref &&
-   mode->vdisplay == vpref)
-   mode->type |= DRM_MODE_TYPE_PREFERRED;
-   }
-}
-EXPORT_SYMBOL(drm_set_preferred_mode);
-
 static bool is_hdmi2_sink(const struct drm_connector *connector)
 {
/*
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac9a406250c5..01aa44e87534 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2754,3 +2754,25 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
 }
 EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_set_preferred_mode - Sets the preferred mode of a connector
+ * @connector: connector whose mode list should be processed
+ * @hpref: horizontal resolution of preferred mode
+ * @vpref: vertical resolution of preferred mode
+ *
+ * Marks a mode as preferred if it matches the resolution specified by @hpref
+ * and @vpref.
+ */
+void drm_set_preferred_mode(struct drm_connector *connector,
+  int hpref, int vpref)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, &connector->probed_modes, head) {
+   if (mode->hdisplay == hpref &&
+   mode->vdisplay == vpref)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+   }
+}
+EXPORT_SYMBOL(drm_set_preferred_mode);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 54cc6f04a708..5bd6b6eb6c57 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -426,8 +426,6 @@ enum hdmi_quantization_range
 drm_default_rgb_quant_range(const struct drm_display_mode *mode);
 int drm_add_modes_noedid(struct drm_connector *connector,
 int hdisplay, int vdisplay);
-void drm_set_preferred_mode(struct drm_connector *connector,
-   int hpref, int vpref);
 
 int drm_edid_header_is_valid(const void *edid);
 bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index c613f0abe9dc..b9bb92e4b029 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -467,6 +467,8 @@ bool drm_mode_is_420_also(const struct drm_display_info 
*display,
  const struct drm_display_mode *mode);
 bool drm_mode_is_420(const struct drm_display_info *display,
 const struct drm_display_mode *mode);
+void drm_set_preferred_mode(struct drm_connector *connector,
+   int hpref, int vpref);
 
 struct drm_display_mode *drm_analog_tv_mode(struct drm_device *dev,
enum drm_connector_tv_mode mode,
-- 
2.43.0

Re: [PATCH] drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modes

[Jani Nikula]

On Tue, 02 Jan 2024, Javier Martinez Canillas  wrote:
> The helper is generic and doesn't use the opaque EDID type struct drm_edid
> and is also used by drivers that only support non-probeable displays, such
> as fixed panels.
>
> These drivers add a list of modes using drm_mode_probed_add() and then set
> a preferred mode using the drm_set_preferred_mode() helper.
>
> It seems more logical to have the helper definition in drm_modes.o instead
> of drm_edid.o, since the former contains modes helper while the latter has
> helpers to manage the EDID information.
>
> Since both drm_edid.o and drm_modes.o object files are built-in the drm.o
> object, there are no functional changes. But besides being a more logical
> place for this helper, it could also allow to eventually make drm_edid.o
> optional and not included in drm.o if only fixed panels must be supported
> in a given system.
>
> Signed-off-by: Javier Martinez Canillas 
> ---
>
>  drivers/gpu/drm/drm_edid.c  | 23 +--
>  drivers/gpu/drm/drm_modes.c | 22 ++
>  include/drm/drm_edid.h  |  2 --
>  include/drm/drm_modes.h |  2 ++
>  4 files changed, 25 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index cb4031d5dcbb..48dd2a0a0395 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -43,6 +43,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

Unnecessary.

Other than that,

Reviewed-by: Jani Nikula 


>  #include 
>  
>  #include "drm_crtc_internal.h"
> @@ -6989,28 +6990,6 @@ int drm_add_modes_noedid(struct drm_connector 
> *connector,
>  }
>  EXPORT_SYMBOL(drm_add_modes_noedid);
>  
> -/**
> - * drm_set_preferred_mode - Sets the preferred mode of a connector
> - * @connector: connector whose mode list should be processed
> - * @hpref: horizontal resolution of preferred mode
> - * @vpref: vertical resolution of preferred mode
> - *
> - * Marks a mode as preferred if it matches the resolution specified by @hpref
> - * and @vpref.
> - */
> -void drm_set_preferred_mode(struct drm_connector *connector,
> -int hpref, int vpref)
> -{
> - struct drm_display_mode *mode;
> -
> - list_for_each_entry(mode, &connector->probed_modes, head) {
> - if (mode->hdisplay == hpref &&
> - mode->vdisplay == vpref)
> - mode->type |= DRM_MODE_TYPE_PREFERRED;
> - }
> -}
> -EXPORT_SYMBOL(drm_set_preferred_mode);
> -
>  static bool is_hdmi2_sink(const struct drm_connector *connector)
>  {
>   /*
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index ac9a406250c5..01aa44e87534 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -2754,3 +2754,25 @@ bool drm_mode_is_420(const struct drm_display_info 
> *display,
>   drm_mode_is_420_also(display, mode);
>  }
>  EXPORT_SYMBOL(drm_mode_is_420);
> +
> +/**
> + * drm_set_preferred_mode - Sets the preferred mode of a connector
> + * @connector: connector whose mode list should be processed
> + * @hpref: horizontal resolution of preferred mode
> + * @vpref: vertical resolution of preferred mode
> + *
> + * Marks a mode as preferred if it matches the resolution specified by @hpref
> + * and @vpref.
> + */
> +void drm_set_preferred_mode(struct drm_connector *connector,
> +int hpref, int vpref)
> +{
> + struct drm_display_mode *mode;
> +
> + list_for_each_entry(mode, &connector->probed_modes, head) {
> + if (mode->hdisplay == hpref &&
> + mode->vdisplay == vpref)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> + }
> +}
> +EXPORT_SYMBOL(drm_set_preferred_mode);
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 54cc6f04a708..5bd6b6eb6c57 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -426,8 +426,6 @@ enum hdmi_quantization_range
>  drm_default_rgb_quant_range(const struct drm_display_mode *mode);
>  int drm_add_modes_noedid(struct drm_connector *connector,
>int hdisplay, int vdisplay);
> -void drm_set_preferred_mode(struct drm_connector *connector,
> - int hpref, int vpref);
>  
>  int drm_edid_header_is_valid(const void *edid);
>  bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index c613f0abe9dc..b9bb92e4b029 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -467,6 +467,8 @@ bool drm_mode_is_420_also(const struct drm_display_info 
> *display,
> const struct drm_display_mode *mode);
>  bool drm_mode_is_420(const struct drm_display_info *display,
>const struct drm_display_mode *mode);
> +void drm_set_preferred_mode(struct drm_connector *connector,
> + int hpref, int vpref);
>  
>  struct drm_display_m

Re: (subset) [PATCH] drm/gpuvm: fix all kernel-doc warnings in include/drm/drm_gpuvm.h

[Maxime Ripard]

On Sat, 30 Dec 2023 21:48:56 -0800, Randy Dunlap wrote:
> Update kernel-doc comments in  to correct all
> kernel-doc warnings:
> 
> drm_gpuvm.h:148: warning: Excess struct member 'addr' description in 
> 'drm_gpuva'
> drm_gpuvm.h:148: warning: Excess struct member 'offset' description in 
> 'drm_gpuva'
> drm_gpuvm.h:148: warning: Excess struct member 'obj' description in 
> 'drm_gpuva'
> drm_gpuvm.h:148: warning: Excess struct member 'entry' description in 
> 'drm_gpuva'
> drm_gpuvm.h:148: warning: Excess struct member '__subtree_last' description 
> in 'drm_gpuva'
> drm_gpuvm.h:192: warning: No description found for return value of 
> 'drm_gpuva_invalidated'
> drm_gpuvm.h:331: warning: Excess struct member 'tree' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'list' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'list' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'local_list' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'lock' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'list' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'local_list' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:331: warning: Excess struct member 'lock' description in 
> 'drm_gpuvm'
> drm_gpuvm.h:352: warning: No description found for return value of 
> 'drm_gpuvm_get'
> drm_gpuvm.h:545: warning: Excess struct member 'fn' description in 
> 'drm_gpuvm_exec'
> drm_gpuvm.h:545: warning: Excess struct member 'priv' description in 
> 'drm_gpuvm_exec'
> drm_gpuvm.h:597: warning: missing initial short description on line:
>  * drm_gpuvm_exec_resv_add_fence()
> drm_gpuvm.h:616: warning: missing initial short description on line:
>  * drm_gpuvm_exec_validate()
> drm_gpuvm.h:623: warning: No description found for return value of 
> 'drm_gpuvm_exec_validate'
> drm_gpuvm.h:698: warning: Excess struct member 'gpuva' description in 
> 'drm_gpuvm_bo'
> drm_gpuvm.h:698: warning: Excess struct member 'entry' description in 
> 'drm_gpuvm_bo'
> drm_gpuvm.h:698: warning: Excess struct member 'gem' description in 
> 'drm_gpuvm_bo'
> drm_gpuvm.h:698: warning: Excess struct member 'evict' description in 
> 'drm_gpuvm_bo'
> drm_gpuvm.h:726: warning: No description found for return value of 
> 'drm_gpuvm_bo_get'
> drm_gpuvm.h:738: warning: missing initial short description on line:
>  * drm_gpuvm_bo_gem_evict()
> drm_gpuvm.h:740: warning: missing initial short description on line:
>  * drm_gpuvm_bo_gem_evict()
> drm_gpuvm.h:698: warning: Excess struct member 'evict' description in 
> 'drm_gpuvm_bo'
> drm_gpuvm.h:844: warning: Excess struct member 'addr' description in 
> 'drm_gpuva_op_map'
> drm_gpuvm.h:844: warning: Excess struct member 'range' description in 
> 'drm_gpuva_op_map'
> drm_gpuvm.h:844: warning: Excess struct member 'offset' description in 
> 'drm_gpuva_op_map'
> drm_gpuvm.h:844: warning: Excess struct member 'obj' description in 
> 'drm_gpuva_op_map'
> 
> [...]

Applied to drm/drm-misc (drm-misc-next-fixes).

Thanks!
Maxime

Re: (subset) [PATCH] drm/imagination: pvr_device.h: fix all kernel-doc warnings

[Maxime Ripard]

On Sat, 30 Dec 2023 21:49:10 -0800, Randy Dunlap wrote:
> Correct all kernel-doc notation on pvr_device.h so that there are no
> kernel-doc warnings remaining.
> 
> pvr_device.h:292: warning: Excess struct member 'active' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'idle' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'lock' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'work' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'old_kccb_cmds_executed' 
> description in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'kccb_stall_count' 
> description in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'ccb' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn_q' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn_obj' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'slot_count' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'reserved_count' description 
> in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'waiters' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'fence_ctx' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'id' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'seqno' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'lock' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'active' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'idle' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'lock' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'work' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'old_kccb_cmds_executed' 
> description in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'kccb_stall_count' 
> description in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'ccb' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn_q' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn_obj' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'rtn' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'slot_count' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'reserved_count' description 
> in 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'waiters' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'fence_ctx' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'id' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'seqno' description in 
> 'pvr_device'
> pvr_device.h:292: warning: Excess struct member 'lock' description in 
> 'pvr_device'
> 
> [...]

Applied to drm/drm-misc (drm-misc-next-fixes).

Thanks!
Maxime

Re: (subset) [PATCH] drm/vc4: plane: check drm_gem_plane_helper_prepare_fb() return value

[Maxime Ripard]

On Sat, 16 Dec 2023 14:15:27 +, Simon Ser wrote:
> Bubble up any error to the caller.
> 
> 

Applied to drm/drm-misc (drm-misc-next).

Thanks!
Maxime

Re: [PATCH 1/4] video/sticore: Store ROM device in STI struct

[Helge Deller]

On 12/20/23 14:22, Thomas Zimmermann wrote:

Store the ROM's parent device in each STI struct, so we can associate
the STI framebuffer with a device.

The new field will eventually replace the fbdev subsystem's info field,
which the function fb_is_primary_device() currently requires to detect
the firmware's output. By using the device instead of the framebuffer
info, a later patch can generalize the helper for use in non-fbdev code.

Signed-off-by: Thomas Zimmermann 
---
  drivers/video/sticore.c | 5 +
  include/video/sticore.h | 4 
  2 files changed, 9 insertions(+)


Series applied to fbdev git tree.

Thanks!
Helge

Re: [PATCH] drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modes

[Javier Martinez Canillas]

Jani Nikula  writes:

Hello Jani,

> On Tue, 02 Jan 2024, Javier Martinez Canillas  wrote:
>> The helper is generic and doesn't use the opaque EDID type struct drm_edid
>> and is also used by drivers that only support non-probeable displays, such
>> as fixed panels.
>>
>> These drivers add a list of modes using drm_mode_probed_add() and then set
>> a preferred mode using the drm_set_preferred_mode() helper.
>>
>> It seems more logical to have the helper definition in drm_modes.o instead
>> of drm_edid.o, since the former contains modes helper while the latter has
>> helpers to manage the EDID information.
>>
>> Since both drm_edid.o and drm_modes.o object files are built-in the drm.o
>> object, there are no functional changes. But besides being a more logical
>> place for this helper, it could also allow to eventually make drm_edid.o
>> optional and not included in drm.o if only fixed panels must be supported
>> in a given system.
>>
>> Signed-off-by: Javier Martinez Canillas 
>> ---
>>
>>  drivers/gpu/drm/drm_edid.c  | 23 +--
>>  drivers/gpu/drm/drm_modes.c | 22 ++
>>  include/drm/drm_edid.h  |  2 --
>>  include/drm/drm_modes.h |  2 ++
>>  4 files changed, 25 insertions(+), 24 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index cb4031d5dcbb..48dd2a0a0395 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -43,6 +43,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>
> Unnecessary.
>

Indeed. I could swear that saw drm_set_preferred_mode() being called
somewhere in drm_edid.c but looking again I see that's not the case.

> Other than that,
>
> Reviewed-by: Jani Nikula 
>

Thanks. I'll post a v2 that drops the unnecessary header include.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[PATCH v2] drm: Move drm_set_preferred_mode() helper from drm_edid to drm_modes

[Javier Martinez Canillas]

The helper is generic, it doesn't use the opaque EDID type struct drm_edid
and is also used by drivers that only support non-probeable displays such
as fixed panels.

These drivers add a list of modes using drm_mode_probed_add() and then set
a preferred mode using the drm_set_preferred_mode() helper.

It seems more logical to have the helper definition in drm_modes.o instead
of drm_edid.o, since the former contains modes helper while the latter has
helpers to manage the EDID information.

Since both drm_edid.o and drm_modes.o object files are built-in the drm.o
object, there are no functional changes. But besides being a more logical
place for this helper, it could also allow to eventually make drm_edid.o
optional and not included in drm.o if only fixed panels must be supported
in a given system.

Signed-off-by: Javier Martinez Canillas 
Reviewed-by: Jani Nikula 
---

Changes in v2:
- Drop unnecessary drm_modes.h header include in drm_edid.c (Jani Nikula).
- Add Jani Nikula's Reviewed-by tag.

 drivers/gpu/drm/drm_edid.c  | 22 --
 drivers/gpu/drm/drm_modes.c | 22 ++
 include/drm/drm_edid.h  |  2 --
 include/drm/drm_modes.h |  2 ++
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index cb4031d5dcbb..e677dc8eb7a9 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6989,28 +6989,6 @@ int drm_add_modes_noedid(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_add_modes_noedid);
 
-/**
- * drm_set_preferred_mode - Sets the preferred mode of a connector
- * @connector: connector whose mode list should be processed
- * @hpref: horizontal resolution of preferred mode
- * @vpref: vertical resolution of preferred mode
- *
- * Marks a mode as preferred if it matches the resolution specified by @hpref
- * and @vpref.
- */
-void drm_set_preferred_mode(struct drm_connector *connector,
-  int hpref, int vpref)
-{
-   struct drm_display_mode *mode;
-
-   list_for_each_entry(mode, &connector->probed_modes, head) {
-   if (mode->hdisplay == hpref &&
-   mode->vdisplay == vpref)
-   mode->type |= DRM_MODE_TYPE_PREFERRED;
-   }
-}
-EXPORT_SYMBOL(drm_set_preferred_mode);
-
 static bool is_hdmi2_sink(const struct drm_connector *connector)
 {
/*
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac9a406250c5..01aa44e87534 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -2754,3 +2754,25 @@ bool drm_mode_is_420(const struct drm_display_info 
*display,
drm_mode_is_420_also(display, mode);
 }
 EXPORT_SYMBOL(drm_mode_is_420);
+
+/**
+ * drm_set_preferred_mode - Sets the preferred mode of a connector
+ * @connector: connector whose mode list should be processed
+ * @hpref: horizontal resolution of preferred mode
+ * @vpref: vertical resolution of preferred mode
+ *
+ * Marks a mode as preferred if it matches the resolution specified by @hpref
+ * and @vpref.
+ */
+void drm_set_preferred_mode(struct drm_connector *connector,
+  int hpref, int vpref)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, &connector->probed_modes, head) {
+   if (mode->hdisplay == hpref &&
+   mode->vdisplay == vpref)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+   }
+}
+EXPORT_SYMBOL(drm_set_preferred_mode);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 54cc6f04a708..5bd6b6eb6c57 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -426,8 +426,6 @@ enum hdmi_quantization_range
 drm_default_rgb_quant_range(const struct drm_display_mode *mode);
 int drm_add_modes_noedid(struct drm_connector *connector,
 int hdisplay, int vdisplay);
-void drm_set_preferred_mode(struct drm_connector *connector,
-   int hpref, int vpref);
 
 int drm_edid_header_is_valid(const void *edid);
 bool drm_edid_block_valid(u8 *raw_edid, int block, bool print_bad_edid,
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index c613f0abe9dc..b9bb92e4b029 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -467,6 +467,8 @@ bool drm_mode_is_420_also(const struct drm_display_info 
*display,
  const struct drm_display_mode *mode);
 bool drm_mode_is_420(const struct drm_display_info *display,
 const struct drm_display_mode *mode);
+void drm_set_preferred_mode(struct drm_connector *connector,
+   int hpref, int vpref);
 
 struct drm_display_mode *drm_analog_tv_mode(struct drm_device *dev,
enum drm_connector_tv_mode mode,
-- 
2.43.0

[syzbot] Monthly dri report (Jan 2024)

[syzbot]

Hello dri maintainers/developers,

This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri

During the period, 4 new issues were detected and 0 were fixed.
In total, 18 issues are still open and 31 have been fixed so far.

Some of the still happening issues:

Ref Crashes Repro Title
<1> 375 Yes   WARNING in drm_wait_one_vblank
  https://syzkaller.appspot.com/bug?extid=6f7fe2dbc479dca0ed17
<2> 147 Yes   WARNING in vkms_get_vblank_timestamp (2)
  https://syzkaller.appspot.com/bug?extid=93bd128a383695391534
<3> 143 Yes   WARNING in drm_syncobj_array_find
  https://syzkaller.appspot.com/bug?extid=95416f957d84e858b377
<4> 94  Yes   inconsistent lock state in sync_timeline_debug_remove
  https://syzkaller.appspot.com/bug?extid=7dcd254b8987a29f6450
<5> 54  Yes   inconsistent lock state in sync_info_debugfs_show
  https://syzkaller.appspot.com/bug?extid=007bfe0f3330f6e1e7d1
<6> 9   Yes   kernel BUG in vmf_insert_pfn_prot (2)
  https://syzkaller.appspot.com/bug?extid=398e17b61dab22cc56bc
<7> 6   Yes   WARNING in drm_gem_prime_fd_to_handle
  https://syzkaller.appspot.com/bug?extid=268d319a7bfd92f4ae01
<8> 5   Yes   divide error in drm_mode_vrefresh
  https://syzkaller.appspot.com/bug?extid=622bba18029bcde672e1
<9> 1   Yes   divide error in drm_mode_debug_printmodeline
  https://syzkaller.appspot.com/bug?extid=2e93e6fb36e6fdc56574

---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

To disable reminders for individual bugs, reply with the following command:
#syz set  no-reminders

To change bug's subsystems, reply with:
#syz set  subsystems: new-subsystem

You may send multiple commands in a single email message.

Re: [PATCH v2 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A panel

[Manuel Traut]

On Tue, Dec 26, 2023 at 02:56:58PM -0800, Jessica Zhang wrote:
> 
> 
> On 12/23/2023 7:20 AM, Manuel Traut wrote:
> > From: Alexander Warnecke 
> > 
> > The BOE TH101MB31IG002-28A panel is a WXGA panel.
> > It is used in Pine64 Pinetab2 and PinetabV.
> > 

> Hi Manuel,

Hi Jessica,

> Sorry, I responded to the v1 instead of the latest version. Carrying my
> comment over to here:
> 
> If I remember correctly, commit d2aacaf07395bd798373cbec6af05fff4147aff3
> should have introduced prepared/enabled do the drm_panel struct.

thanks for the hint, I will update this in v3.

Regards
Manuel

Re: [PATCH v2] drm/debugfs: drop unneeded DEBUG_FS guard

[Jani Nikula]

On Sat, 23 Dec 2023, Dario Binacchi  wrote:
> The Makefile enables/disables the file compilation depending on
> CONFIG_DEBUG_FS.
>
> Signed-off-by: Dario Binacchi 
> Reviewed-by: Jani Nikula 

Thanks for the patch, pushed to drm-misc-next.

BR,
Jani.

>
> ---
>
> Changes in v2:
> - Add 'Reviewed-by' tag of Jani Nikula
>
>  drivers/gpu/drm/drm_debugfs.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index f291fb4b359f..f80d9cf3e71a 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -45,8 +45,6 @@
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
>  
> -#if defined(CONFIG_DEBUG_FS)
> -
>  /***
>   * Initialization, etc.
>   **/
> @@ -588,5 +586,3 @@ void drm_debugfs_crtc_remove(struct drm_crtc *crtc)
>   debugfs_remove_recursive(crtc->debugfs_entry);
>   crtc->debugfs_entry = NULL;
>  }
> -
> -#endif /* CONFIG_DEBUG_FS */

-- 
Jani Nikula, Intel

[PATCH 1/6] accel/habanalabs: check failure of eventfd_signal

[Oded Gabbay]

From: Dafna Hirschfeld 

print err log if eventfd_signal return val is not 1 as expected.

Signed-off-by: Dafna Hirschfeld 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/device.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/accel/habanalabs/common/device.c 
b/drivers/accel/habanalabs/common/device.c
index a365791a9f5c..e81ccafddfb3 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -2043,13 +2043,19 @@ int hl_device_cond_reset(struct hl_device *hdev, u32 
flags, u64 event_mask)
return hl_device_reset(hdev, flags | HL_DRV_RESET_HARD);
 }
 
-static void hl_notifier_event_send(struct hl_notifier_event *notifier_event, 
u64 event_mask)
+static void hl_notifier_event_send(struct hl_device *hdev,
+   struct hl_notifier_event *notifier_event, u64 
event_mask)
 {
+   u64 n;
+
mutex_lock(¬ifier_event->lock);
notifier_event->events_mask |= event_mask;
 
-   if (notifier_event->eventfd)
-   eventfd_signal(notifier_event->eventfd, 1);
+   if (notifier_event->eventfd) {
+   n = eventfd_signal(notifier_event->eventfd, 1);
+   if (n != 1)
+   dev_err(hdev->dev, "eventfd signal failed, incremented 
by %llu\n", n);
+   }
 
mutex_unlock(¬ifier_event->lock);
 }
@@ -2073,7 +2079,7 @@ void hl_notifier_event_send_all(struct hl_device *hdev, 
u64 event_mask)
mutex_lock(&hdev->fpriv_list_lock);
 
list_for_each_entry(hpriv, &hdev->fpriv_list, dev_node)
-   hl_notifier_event_send(&hpriv->notifier_event, event_mask);
+   hl_notifier_event_send(hdev, &hpriv->notifier_event, 
event_mask);
 
mutex_unlock(&hdev->fpriv_list_lock);
 }
-- 
2.34.1

[PATCH 2/6] accel/habanalabs/gaudi2: add interrupt affinity for user interrupts

[Oded Gabbay]

From: Dani Liberman 

User interrupts are MSIx interrupts coming from Gaudi2, that have
specific range of IDs and are assigned to the sole use of the user
process that opened the Gaudi2 device (reminder: there can be only
a single user process running on Gaudi2 at any given time).

The interrupts are allocated and managed by the driver and therefore,
the user expects the driver to initialize them properly, which also
includes setting the affinity to the related CPU cores of the
device's NUMA node to get maximum performance.

Signed-off-by: Dani Liberman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/device.c | 30 
 drivers/accel/habanalabs/common/habanalabs.h |  5 
 drivers/accel/habanalabs/gaudi2/gaudi2.c |  5 
 3 files changed, 40 insertions(+)

diff --git a/drivers/accel/habanalabs/common/device.c 
b/drivers/accel/habanalabs/common/device.c
index e81ccafddfb3..514459396818 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -2807,3 +2807,33 @@ void hl_enable_err_info_capture(struct hl_error_info 
*captured_err_info)
atomic_set(&captured_err_info->cs_timeout.write_enable, 1);
captured_err_info->undef_opcode.write_enable = true;
 }
+
+void hl_init_cpu_for_irq(struct hl_device *hdev)
+{
+   struct cpumask *available_mask = &hdev->irq_affinity_mask;
+   int numa_node = hdev->pdev->dev.numa_node, i;
+   static struct cpumask cpu_mask;
+
+   if (numa_node < 0)
+   return;
+
+   if (!cpumask_and(&cpu_mask, cpumask_of_node(numa_node), 
cpu_online_mask)) {
+   dev_err(hdev->dev, "No available affinities in current numa 
node\n");
+   return;
+   }
+
+   /* Remove HT siblings */
+   for_each_cpu(i, &cpu_mask)
+   cpumask_set_cpu(cpumask_first(topology_sibling_cpumask(i)), 
available_mask);
+}
+
+void hl_set_irq_affinity(struct hl_device *hdev, int irq)
+{
+   if (cpumask_empty(&hdev->irq_affinity_mask)) {
+   dev_dbg(hdev->dev, "affinity mask is empty\n");
+   return;
+   }
+
+   if (irq_set_affinity_hint(irq, &hdev->irq_affinity_mask))
+   dev_err(hdev->dev, "Failed setting irq %d affinity\n", irq);
+}
diff --git a/drivers/accel/habanalabs/common/habanalabs.h 
b/drivers/accel/habanalabs/common/habanalabs.h
index 2a900c9941fe..b1a7b229e161 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -3257,6 +3257,7 @@ struct hl_reset_info {
  * @clk_throttling: holds information about current/previous clock throttling 
events
  * @captured_err_info: holds information about errors.
  * @reset_info: holds current device reset information.
+ * @irq_affinity_mask: mask of available CPU cores for user and decoder 
interrupt handling.
  * @stream_master_qid_arr: pointer to array with QIDs of master streams.
  * @fw_inner_major_ver: the major of current loaded preboot inner version.
  * @fw_inner_minor_ver: the minor of current loaded preboot inner version.
@@ -3446,6 +3447,8 @@ struct hl_device {
 
struct hl_reset_inforeset_info;
 
+   cpumask_t   irq_affinity_mask;
+
u32 *stream_master_qid_arr;
u32 fw_inner_major_ver;
u32 fw_inner_minor_ver;
@@ -4032,6 +4035,8 @@ void hl_handle_critical_hw_err(struct hl_device *hdev, 
u16 event_id, u64 *event_
 void hl_handle_fw_err(struct hl_device *hdev, struct hl_info_fw_err_info 
*info);
 void hl_capture_engine_err(struct hl_device *hdev, u16 engine_id, u16 
error_count);
 void hl_enable_err_info_capture(struct hl_error_info *captured_err_info);
+void hl_init_cpu_for_irq(struct hl_device *hdev);
+void hl_set_irq_affinity(struct hl_device *hdev, int irq);
 
 #ifdef CONFIG_DEBUG_FS
 
diff --git a/drivers/accel/habanalabs/gaudi2/gaudi2.c 
b/drivers/accel/habanalabs/gaudi2/gaudi2.c
index e0e5615ef9b0..fd01525b1ea2 100644
--- a/drivers/accel/habanalabs/gaudi2/gaudi2.c
+++ b/drivers/accel/habanalabs/gaudi2/gaudi2.c
@@ -4254,6 +4254,8 @@ static int gaudi2_enable_msix(struct hl_device *hdev)
if (gaudi2->hw_cap_initialized & HW_CAP_MSIX)
return 0;
 
+   hl_init_cpu_for_irq(hdev);
+
rc = pci_alloc_irq_vectors(hdev->pdev, GAUDI2_MSIX_ENTRIES, 
GAUDI2_MSIX_ENTRIES,
PCI_IRQ_MSIX);
if (rc < 0) {
@@ -4307,6 +4309,7 @@ static int gaudi2_enable_msix(struct hl_device *hdev)
i++, j++, user_irq_init_cnt++) {
 
irq = pci_irq_vector(hdev->pdev, i);
+   hl_set_irq_affinity(hdev, irq);
rc = request_irq(irq, hl_irq_user_interrupt_handler, 0, 
gaudi2_irq_name(i),
&hdev->user_interrupt[j]);
if (rc) {
@@ -4333,6 +4336,7 @@ static int gaudi2_

[PATCH 3/6] accel/habanalabs: increase HL_MAX_STR to 64 bytes to avoid warnings

[Oded Gabbay]

From: Koby Elbaz 

Fix a warning of a buffer overflow:
‘snprintf’ output between 38 and 47 bytes into a destination of size 32

Signed-off-by: Koby Elbaz 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/habanalabs.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/accel/habanalabs/common/habanalabs.h 
b/drivers/accel/habanalabs/common/habanalabs.h
index b1a7b229e161..253873315888 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -2547,7 +2547,7 @@ struct hl_state_dump_specs {
  * DEVICES
  */
 
-#define HL_STR_MAX 32
+#define HL_STR_MAX 64
 
 #define HL_DEV_STS_MAX (HL_DEVICE_STATUS_LAST + 1)
 
-- 
2.34.1

[PATCH 5/6] accel/habanalabs/gaudi2: move HMMU page tables to device memory

[Oded Gabbay]

From: Farah Kassabri 

Currently the HMMU page tables reside in the host memory,
which will cause host access from the device for every page walk.
This can affect PCIe bandwidth in certain scenarios.

To prevent that problem, HMMU page tables will be moved to the device
memory so the miss transaction will read the hops from there instead of
going to the host.

Signed-off-by: Farah Kassabri 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/habanalabs.h  |  26 ++
 drivers/accel/habanalabs/common/hw_queue.c|  17 +
 drivers/accel/habanalabs/common/mmu/Makefile  |   2 +-
 drivers/accel/habanalabs/common/mmu/mmu.c | 223 ++-
 drivers/accel/habanalabs/common/mmu/mmu_v1.c  | 352 +++---
 drivers/accel/habanalabs/common/mmu/mmu_v2.c  | 338 +
 drivers/accel/habanalabs/gaudi/gaudi.c|   1 +
 drivers/accel/habanalabs/gaudi2/gaudi2.c  | 245 
 drivers/accel/habanalabs/gaudi2/gaudi2P.h |  12 +-
 .../include/hw_ip/mmu/mmu_general.h   |   2 +
 10 files changed, 836 insertions(+), 382 deletions(-)
 create mode 100644 drivers/accel/habanalabs/common/mmu/mmu_v2.c

diff --git a/drivers/accel/habanalabs/common/habanalabs.h 
b/drivers/accel/habanalabs/common/habanalabs.h
index 253873315888..7397ce86b7f0 100644
--- a/drivers/accel/habanalabs/common/habanalabs.h
+++ b/drivers/accel/habanalabs/common/habanalabs.h
@@ -443,18 +443,22 @@ enum hl_collective_mode {
  *  a CB handle can be provided for jobs on this queue.
  *  Otherwise, a CB address must be provided.
  * @collective_mode: collective mode of current queue
+ * @q_dram_bd_address: PQ dram address, used when PQ need to reside in DRAM.
  * @driver_only: true if only the driver is allowed to send a job to this 
queue,
  *   false otherwise.
  * @binned: True if the queue is binned out and should not be used
  * @supports_sync_stream: True if queue supports sync stream
+ * @dram_bd: True if the bd should be copied to dram, needed for PQ which has 
been allocated on dram
  */
 struct hw_queue_properties {
enum hl_queue_type  type;
enum queue_cb_alloc_flags   cb_alloc_flags;
enum hl_collective_mode collective_mode;
+   u64 q_dram_bd_address;
u8  driver_only;
u8  binned;
u8  supports_sync_stream;
+   u8  dram_bd;
 };
 
 /**
@@ -1052,6 +1056,8 @@ struct hl_encaps_signals_mgr {
  * @collective_mode: collective mode of current queue
  * @kernel_address: holds the queue's kernel virtual address.
  * @bus_address: holds the queue's DMA address.
+ * @pq_dram_address: hold the dram address when the PQ is allocated, used when 
dram_bd is true in
+ *   queue properites.
  * @pi: holds the queue's pi value.
  * @ci: holds the queue's ci value, AS CALCULATED BY THE DRIVER (not real ci).
  * @hw_queue_id: the id of the H/W queue.
@@ -1061,6 +1067,7 @@ struct hl_encaps_signals_mgr {
  * @valid: is the queue valid (we have array of 32 queues, not all of them
  * exist).
  * @supports_sync_stream: True if queue supports sync stream
+ * @dram_bd: True if the bd should be copied to dram, needed for PQ which has 
been allocated on dram
  */
 struct hl_hw_queue {
struct hl_cs_job**shadow_queue;
@@ -1069,6 +1076,7 @@ struct hl_hw_queue {
enum hl_collective_mode collective_mode;
void*kernel_address;
dma_addr_t  bus_address;
+   u64 pq_dram_address;
u32 pi;
atomic_tci;
u32 hw_queue_id;
@@ -1077,6 +1085,7 @@ struct hl_hw_queue {
u16 int_queue_len;
u8  valid;
u8  supports_sync_stream;
+   u8  dram_bd;
 };
 
 /**
@@ -3889,6 +3898,7 @@ int hl_mmu_hr_get_tlb_info(struct hl_ctx *ctx, u64 
virt_addr, struct hl_mmu_hop_
struct hl_hr_mmu_funcs 
*hr_func);
 int hl_mmu_if_set_funcs(struct hl_device *hdev);
 void hl_mmu_v1_set_funcs(struct hl_device *hdev, struct hl_mmu_funcs *mmu);
+void hl_mmu_v2_set_funcs(struct hl_device *hdev, struct hl_mmu_funcs *mmu);
 void hl_mmu_v2_hr_set_funcs(struct hl_device *hdev, struct hl_mmu_funcs *mmu);
 int hl_mmu_va_to_pa(struct hl_ctx *ctx, u64 virt_addr, u64 *phys_addr);
 int hl_mmu_get_tlb_info(struct hl_ctx *ctx, u64 virt_addr,
@@ -3896,6 +3906,22 @@ int hl_mmu_get_tlb_info(struct hl_ctx *ctx, u64 
virt_addr,
 u64 hl_mmu_scramble_addr(struct hl_device *

[PATCH 4/6] accel/habanalabs: fix DRAM BAR base address calculation

[Oded Gabbay]

From: Tomer Tayar 

When the DRAM region size in the BAR is not a power of 2, calculating
the corresponding BAR base address should be done using the offset from
the DRAM start address, and not using directly the DRAM address.

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/device.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/accel/habanalabs/common/device.c 
b/drivers/accel/habanalabs/common/device.c
index 514459396818..15891de6cf39 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -55,7 +55,8 @@ static u64 hl_set_dram_bar(struct hl_device *hdev, u64 addr, 
struct pci_mem_regi
if (is_power_of_2(prop->dram_pci_bar_size))
bar_base_addr = addr & ~(prop->dram_pci_bar_size - 0x1ull);
else
-   bar_base_addr = DIV_ROUND_DOWN_ULL(addr, 
prop->dram_pci_bar_size) *
+   bar_base_addr = region->region_base +
+   div64_u64((addr - region->region_base), 
prop->dram_pci_bar_size) *
prop->dram_pci_bar_size;
 
old_base = hdev->asic_funcs->set_dram_bar_base(hdev, bar_base_addr);
-- 
2.34.1

[PATCH 6/6] accel/habanalabs: abort device reset for consecutive heartbeat failures

[Oded Gabbay]

From: Tomer Tayar 

The mechanism of aborting device reset for consecutive fatal errors is
currently only for fatal errors that are reported by FW.
A non-responsive FW and consecutive heartbeat failures is also
considered fatal, so add them as well to this mechanism to avoid
recurring device reset in such a case.

Signed-off-by: Tomer Tayar 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/accel/habanalabs/common/device.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/accel/habanalabs/common/device.c 
b/drivers/accel/habanalabs/common/device.c
index 15891de6cf39..581fc99ad89b 100644
--- a/drivers/accel/habanalabs/common/device.c
+++ b/drivers/accel/habanalabs/common/device.c
@@ -1769,14 +1769,16 @@ int hl_device_reset(struct hl_device *hdev, u32 flags)
hdev->device_cpu_disabled = false;
hdev->reset_info.hard_reset_pending = false;
 
+   /*
+* Put the device in an unusable state if there are 2 back to 
back resets due to
+* fatal errors.
+*/
if (hdev->reset_info.reset_trigger_repeated &&
-   (hdev->reset_info.prev_reset_trigger ==
-   HL_DRV_RESET_FW_FATAL_ERR)) {
-   /* if there 2 back to back resets from FW,
-* ensure driver puts the driver in a unusable state
-*/
+   (hdev->reset_info.prev_reset_trigger == 
HL_DRV_RESET_FW_FATAL_ERR ||
+   
hdev->reset_info.prev_reset_trigger ==
+   
HL_DRV_RESET_HEARTBEAT)) {
dev_crit(hdev->dev,
-   "%s Consecutive FW fatal errors received, 
stopping hard reset\n",
+   "%s Consecutive fatal errors, stopping hard 
reset\n",
dev_name(&(hdev)->pdev->dev));
rc = -EIO;
goto out_err;
-- 
2.34.1

Re: [PATCH v9 09/25] drm/modes: Move named modes parsing to a separate function

[Dave Stevenson]

Hi Maxime

On Mon, 14 Nov 2022 at 13:00, Maxime Ripard  wrote:
>
> The current construction of the named mode parsing doesn't allow to extend
> it easily. Let's move it to a separate function so we can add more
> parameters and modes.
>
> In order for the tests to still pass, some extra checks are needed, so
> it's not a 1:1 move.
>
> Reviewed-by: Noralf Trønnes 
> Tested-by: Mateusz Kwiatkowski 
> Signed-off-by: Maxime Ripard 
>
> ---
> Changes in v7:
> - Add Noralf Reviewed-by
>
> Changes in v6:
> - Simplify the test for connection status extras
> - Simplify the code path to call drm_mode_parse_cmdline_named_mode
>
> Changes in v4:
> - Fold down all the named mode patches that were split into a single
>   patch again to maintain bisectability
> ---
>  drivers/gpu/drm/drm_modes.c | 70 
> +
>  1 file changed, 58 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 71c050c3ee6b..37542612912b 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -2229,6 +2229,51 @@ static const char * const drm_named_modes_whitelist[] 
> = {
> "PAL",
>  };
>
> +static int drm_mode_parse_cmdline_named_mode(const char *name,
> +unsigned int name_end,
> +struct drm_cmdline_mode 
> *cmdline_mode)
> +{
> +   unsigned int i;
> +
> +   if (!name_end)
> +   return 0;
> +
> +   /* If the name starts with a digit, it's not a named mode */
> +   if (isdigit(name[0]))
> +   return 0;
> +
> +   /*
> +* If there's an equal sign in the name, the command-line
> +* contains only an option and no mode.
> +*/
> +   if (strnchr(name, name_end, '='))
> +   return 0;
> +
> +   /* The connection status extras can be set without a mode. */
> +   if (name_end == 1 &&
> +   (name[0] == 'd' || name[0] == 'D' || name[0] == 'e'))
> +   return 0;
> +
> +   /*
> +* We're sure we're a named mode at this point, iterate over the
> +* list of modes we're aware of.
> +*/
> +   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> +   int ret;
> +
> +   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> +   if (ret != name_end)
> +   continue;
> +
> +   strcpy(cmdline_mode->name, drm_named_modes_whitelist[i]);
> +   cmdline_mode->specified = true;
> +
> +   return 1;
> +   }
> +
> +   return -EINVAL;
> +}
> +
>  /**
>   * drm_mode_parse_command_line_for_connector - parse command line modeline 
> for connector
>   * @mode_option: optional per connector mode option
> @@ -2265,7 +2310,7 @@ bool drm_mode_parse_command_line_for_connector(const 
> char *mode_option,
> const char *bpp_ptr = NULL, *refresh_ptr = NULL, *extra_ptr = NULL;
> const char *options_ptr = NULL;
> char *bpp_end_ptr = NULL, *refresh_end_ptr = NULL;
> -   int i, len, ret;
> +   int len, ret;
>
> memset(mode, 0, sizeof(*mode));
> mode->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> @@ -2306,18 +2351,19 @@ bool drm_mode_parse_command_line_for_connector(const 
> char *mode_option,
> parse_extras = true;
> }
>
> -   /* First check for a named mode */
> -   for (i = 0; i < ARRAY_SIZE(drm_named_modes_whitelist); i++) {
> -   ret = str_has_prefix(name, drm_named_modes_whitelist[i]);
> -   if (ret == mode_end) {
> -   if (refresh_ptr)
> -   return false; /* named + refresh is invalid */
> +   if (!mode_end)
> +   return false;

I'm chasing down a change in behaviour between 6.1 and 6.6, and this
patch seems to be at least part of the cause.

Since [1] we've had the emulated framebuffer on Pi being 16bpp to save
memory. All good.

It used to be possible to use "video=HDMI-A-1:-32" on the kernel
command line to set it back to 32bpp.

After this patch that is no longer possible. "mode_end = bpp_off", and
"bpp_off = bpp_ptr - name", so with bpp_ptr = name we get mode_end
being 0. That fails this conditional.
drm_mode_parse_cmdline_named_mode already aborts early but with no
error if name_end / mode_end is 0, so this "if" clause seems
redundant, and is a change in behaviour.

We do then get a second parsing failure due to the check if (bpp_ptr
|| refresh_ptr) at [2].
Prior to this patch my video= line would get mode->specified set via
"if (ret == mode_end)" removed above, as ret = mode_end = 0. We
therefore didn't evaluate the conditional that now fails.

So I guess my question is whether my command line is valid or not, and
therefore is this a regression?
If considered invalid, then presumably there is no way to update the
bpp without also having t

Re: linux-next: manual merge of the drm tree with the mm tree

[Jeffrey Hugo]

On 1/1/2024 4:52 PM, Stephen Rothwell wrote:

Hi all,

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

   drivers/accel/qaic/qaic_data.c

between commit:

   78f5d33f3dd4 ("mm, treewide: rename MAX_ORDER to MAX_PAGE_ORDER")

from the mm tree and commit:

   47fbee5f27ed ("accel/qaic: Update MAX_ORDER use to be inclusive")

from the drm tree.

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



Thanks Stephen.  Your fixup is correct.

-Jeff

Re: RPI4B: what is needed for /dev/video10 to work ( v4l_m2m )

[AL13N]

Maxime Ripard schreef op 2024-01-02 11:03:

Hi,

On Wed, Dec 27, 2023 at 04:19:19PM +0100, AL13N wrote:
I have a RPI4B with upstream kernel 6.1 64bit and there is no 
/dev/video10
present. I thought if I waited a bit more, it would appear in the 
kernel,

but that was folly on my part.

Currently, watching a movie is painful since the software decoding is 
way

too slow and it has very low fps on 1080p (or even 720p or even 480p)

IIRC, someone told me something else has to be fixed before the codecs 
can

be done, but I don't remember what it was, or i didn't find it in my
email/the archives.

Can someone tell me what exactly needs to be done (in kernel) so that 
I can

take a crack at it, (hopefully with some help)?

I don't remember if this was relevant, but there was some talk of 
needing to
use opengl output with a specific texture format for it to work? or is 
that

seperate?


That's something for linux-media. The hardware codec isn't part of vc4
or v3d, it's a separate controller that requires a separate driver (in
v4l2).

That driver isn't upstream, and that would need the first thing to
tackle.

Maxime


Can I assume you're talking about the vchiq driver, which would have 
multiple things including codecs, or am I misunderstanding it?

[PATCH v3 1/4] dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel

[Manuel Traut]

Add bindings for the BOE TH101MB31IG002-28A LCD panel. It is
used e.g. in the Pine64 PineTab2 and PineTab-V.

Signed-off-by: Manuel Traut 
Reviewed-by: Krzysztof Kozlowski 
---
 .../display/panel/boe,th101mb31ig002-28a.yaml  | 58 ++
 1 file changed, 58 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml 
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
new file mode 100644
index ..32df26cbfeed
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
@@ -0,0 +1,58 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/boe,th101mb31ig002-28a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: BOE TH101MB31IG002-28A WXGA DSI Display Panel
+
+maintainers:
+  - Manuel Traut 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+enum:
+# BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
+  - boe,th101mb31ig002-28a
+
+  reg: true
+  backlight: true
+  enable-gpios: true
+  power-supply: true
+  port: true
+  rotation: true
+
+required:
+  - compatible
+  - reg
+  - enable-gpios
+  - power-supply
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+panel@0 {
+compatible = "boe,th101mb31ig002-28a";
+reg = <0>;
+backlight = <&backlight_lcd0>;
+enable-gpios = <&gpio 45 GPIO_ACTIVE_HIGH>;
+rotation = <90>;
+power-supply = <&vcc_3v3>;
+port {
+panel_in_dsi: endpoint {
+remote-endpoint = <&dsi_out_con>;
+};
+};
+};
+};
+
+...

-- 
2.43.0

[PATCH v3 0/4] arm64: rockchip: Pine64 PineTab2 support

[Manuel Traut]

This adds support for the BOE TH101MB31IG002 LCD Panel used in PineTab2 [1] and
PineTab-V [2] as well as the devictrees for the PineTab2 v0.1 and v2.0.

The BOE LCD Panel patch was retrieved from [3]. The function-name prefix has
been adapted and the LCD init section was simplified.

The PineTab2 devicetree patch was retrieved from [4]. Some renaming was needed
to pass the dtb-checks, the brightness-levels are specified as range and steps
instead of a list of values.

[5] and [6] was also used as source for this queue.

[1] https://wiki.pine64.org/wiki/PineTab2
[2] https://wiki.pine64.org/wiki/PineTab-V
[3] 
https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/display/0018-drm-panel-add-BOE-TH101MB31IG002-28A-driver.patch?ref_type=heads
[4] 
https://salsa.debian.org/Mobian-team/devices/kernels/rockchip-linux/-/blob/mobian-6.6/debian/patches/device-tree/0134-arch-arm64-add-Pine64-PineTab2-device-trees.patch?ref_type=heads
[5] https://github.com/dreemurrs-embedded/linux-pinetab2/tree/v6.6.7-danctnix1
[6] https://xff.cz/git/linux?h=pt2-6.7

Signed-off-by: Manuel Traut 
---
Changes in v3:
- PineTab2 dts:
* Remove useless regulator-state-mem nodes for fixed regulators
* Swap mmc0 and mmc1, so mmc0 is now the internal eMMC
- BOE TH101MB31IG002 LCD Panel:
* Remove enabled/prepared checks since they are done in core.
- Use consistent naming (PineTab2 and PineTab-V) in commit messages.
- Link to v2: 
https://lore.kernel.org/r/20231223-pinetab2-v2-0-ec1856d00...@mecka.net

Changes in v2:
- Removed dtb-checker fixups, cause I am not sure if they are correct
- Applied review comments for dt bindings
- pinetab2 dts:
* Remove unverified WLAN entries, as in [5]
* Simplify flash LED definition, as in [5]
* Fix headphone detection and sound routing, as in [5]
* Fix CRU clock configuration
- BOE TH101MB31IG002 LCD Panel:
* Reworked prepare/enable unprepare/disable, as in [5]
- Replaced nicknames by realnames in author and signed-offs

- Link to v1: 
https://lore.kernel.org/r/20231222-pinetab2-v1-0-e148a7f61...@mecka.net

---
Alexander Warnecke (2):
  drm/panel: Add driver for BOE TH101MB31IG002-28A panel
  arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

Manuel Traut (2):
  dt-bindings: display: panel: Add BOE TH101MB31IG002-28A panel
  dt-bindings: arm64: rockchip: Add Pine64 PineTab2

 .../devicetree/bindings/arm/rockchip.yaml  |   8 +
 .../display/panel/boe,th101mb31ig002-28a.yaml  |  58 ++
 arch/arm64/boot/dts/rockchip/Makefile  |   2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts |  26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts |  46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 959 +
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 322 +++
 9 files changed, 1433 insertions(+)
---
base-commit: 610a9b8f49fbcf1100716370d3b5f6f884a2835a
change-id: 20231222-pinetab2-faa77e01db6f

Best regards,
-- 
Manuel Traut 

[PATCH v3 3/4] dt-bindings: arm64: rockchip: Add Pine64 PineTab2

[Manuel Traut]

Add devicvetree binding documentation for Pine64 PineTab2
which uses the Rockchip RK3566 SoC.

Signed-off-by: Manuel Traut 
Acked-by: Krzysztof Kozlowski 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 5f7c6c4aad8f..96d54b0587ab 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -635,6 +635,14 @@ properties:
   - const: pine64,pinenote
   - const: rockchip,rk3566
 
+  - description: Pine64 PineTab2
+items:
+  - enum:
+  - pine64,pinetab2-v0.1
+  - pine64,pinetab2-v2.0
+  - const: pine64,pinetab2
+  - const: rockchip,rk3566
+
   - description: Pine64 PinePhonePro
 items:
   - const: pine64,pinephone-pro

-- 
2.43.0

[PATCH v3 2/4] drm/panel: Add driver for BOE TH101MB31IG002-28A panel

[Manuel Traut]

From: Alexander Warnecke 

The BOE TH101MB31IG002-28A panel is a WXGA panel.
It is used in Pine64 PineTab2 and PineTab-V.

Signed-off-by: Alexander Warnecke 
Signed-off-by: Manuel Traut 
---
 drivers/gpu/drm/panel/Kconfig  |  11 +
 drivers/gpu/drm/panel/Makefile |   1 +
 .../gpu/drm/panel/panel-boe-th101mb31ig002-28a.c   | 322 +
 3 files changed, 334 insertions(+)

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..927ddd10e688 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -67,6 +67,17 @@ config DRM_PANEL_BOE_HIMAX8279D
  24 bit RGB per pixel. It provides a MIPI DSI interface to
  the host and has a built-in LED backlight.
 
+config DRM_PANEL_BOE_TH101MB31UIG002_28A
+   tristate "Boe TH101MB31UIG002-28A panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Boe
+ TH101MB31UIG002-28A TFT-LCD modules. The panel has a 800x1280
+ resolution and uses 24 bit RGB per pixel. It provides a MIPI DSI
+ interface to the host and has a built-in LED backlight.
+
 config DRM_PANEL_BOE_TV101WUM_NL6
tristate "BOE TV101WUM and AUO KD101N80 45NA 1200x1920 panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..dd6e1ac9d0a2 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_PANEL_ASUS_Z00T_TM5P5_NT35596) += 
panel-asus-z00t-tm5p5-n35596.
 obj-$(CONFIG_DRM_PANEL_AUO_A030JTN01) += panel-auo-a030jtn01.o
 obj-$(CONFIG_DRM_PANEL_BOE_BF060Y8M_AJ0) += panel-boe-bf060y8m-aj0.o
 obj-$(CONFIG_DRM_PANEL_BOE_HIMAX8279D) += panel-boe-himax8279d.o
+obj-$(CONFIG_DRM_PANEL_BOE_TH101MB31UIG002_28A) += 
panel-boe-th101mb31ig002-28a.o
 obj-$(CONFIG_DRM_PANEL_BOE_TV101WUM_NL6) += panel-boe-tv101wum-nl6.o
 obj-$(CONFIG_DRM_PANEL_DSI_CM) += panel-dsi-cm.o
 obj-$(CONFIG_DRM_PANEL_LVDS) += panel-lvds.o
diff --git a/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c 
b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
new file mode 100644
index ..763e9f8342d3
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-boe-th101mb31ig002-28a.c
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023 Alexander Warnecke 
+ * Copyright (c) 2023 Manuel Traut 
+ * Copyright (c) 2023 Dang Huynh 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+struct boe_th101mb31ig002 {
+   struct drm_panel panel;
+
+   struct mipi_dsi_device *dsi;
+
+   struct regulator *power;
+   struct gpio_desc *enable;
+   struct gpio_desc *reset;
+
+   enum drm_panel_orientation orientation;
+};
+
+static void boe_th101mb31ig002_reset(struct boe_th101mb31ig002 *ctx)
+{
+   gpiod_direction_output(ctx->reset, 0);
+   usleep_range(10, 100);
+   gpiod_direction_output(ctx->reset, 1);
+   usleep_range(10, 100);
+   gpiod_direction_output(ctx->reset, 0);
+   usleep_range(5000, 6000);
+}
+
+static int boe_th101mb31ig002_enable(struct drm_panel *panel)
+{
+   struct boe_th101mb31ig002 *ctx = container_of(panel,
+ struct boe_th101mb31ig002,
+ panel);
+   struct mipi_dsi_device *dsi = ctx->dsi;
+   struct device *dev = &dsi->dev;
+   int ret;
+
+   mipi_dsi_dcs_write_seq(dsi, 0xE0, 0xAB, 0xBA);
+   mipi_dsi_dcs_write_seq(dsi, 0xE1, 0xBA, 0xAB);
+   mipi_dsi_dcs_write_seq(dsi, 0xB1, 0x10, 0x01, 0x47, 0xFF);
+   mipi_dsi_dcs_write_seq(dsi, 0xB2, 0x0C, 0x14, 0x04, 0x50, 0x50, 0x14);
+   mipi_dsi_dcs_write_seq(dsi, 0xB3, 0x56, 0x53, 0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB4, 0x33, 0x30, 0x04);
+   mipi_dsi_dcs_write_seq(dsi, 0xB6, 0xB0, 0x00, 0x00, 0x10, 0x00, 0x10,
+   0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB8, 0x05, 0x12, 0x29, 0x49, 0x48, 0x00,
+   0x00);
+   mipi_dsi_dcs_write_seq(dsi, 0xB9, 0x7C, 0x65, 0x55, 0x49, 0x46, 0x36,
+   0x3B, 0x24, 0x3D, 0x3C, 0x3D, 0x5C, 0x4C,
+   0x55, 0x47, 0x46, 0x39, 0x26, 0x06, 0x7C,
+   0x65, 0x55, 0x49, 0x46, 0x36, 0x3B, 0x24,
+   0x3D, 0x3C, 0x3D, 0x5C, 0x4C, 0x55, 0x47,
+   0x46, 0x39, 0x26, 0x06);
+   mipi_dsi_dcs_write_seq(dsi, 0x00, 0xFF, 0x87, 0x12, 0x34, 0x44, 0x44,
+   0x44, 0x44, 0x98, 0x04, 0x98, 0x04, 0x0F,
+   0x00, 0x00, 0xC1);
+   mipi_dsi_dcs_write_seq(dsi, 0xC1, 0x54, 0x94, 0x02, 0x85, 0x9F, 0x00,
+  

[PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

[Manuel Traut]

From: Alexander Warnecke 

This includes support for both the v0.1 units that were sent to developers and
the v2.0 units from production.

v1.0 is not included as no units are known to exist.

Working/Tested:
- SDMMC
- UART
- Buttons
- Charging/Battery/PMIC
- Audio
- USB
- Display

Signed-off-by: Alexander Warnecke 
Signed-off-by: Manuel Traut 
Tested-By: Diederik de Haas 
---
 arch/arm64/boot/dts/rockchip/Makefile  |   2 +
 .../boot/dts/rockchip/rk3566-pinetab2-v0.1.dts |  26 +
 .../boot/dts/rockchip/rk3566-pinetab2-v2.0.dts |  46 +
 arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi  | 959 +
 4 files changed, 1033 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index a18f33bf0c0e..ef66c0937a9b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -77,6 +77,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg353vs.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg503.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinenote-v1.2.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v0.1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-pinetab2-v2.0.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-powkiddy-rgb30.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-quartz64-b.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
new file mode 100644
index ..8b110186a3eb
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v0.1.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+   model = "Pine64 PineTab2 v0.1";
+   compatible = "pine64,pinetab2-v0.1", "pine64,pinetab2", 
"rockchip,rk3566";
+};
+
+&lcd {
+   reset-gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+   lcd0 {
+   lcd0_rst_l: lcd0-rst-l {
+   rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+};
+
+&sdmmc1 {
+   vmmc-supply = <&vcc3v3_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts 
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
new file mode 100644
index ..6f80446b5802
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2-v2.0.dts
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3566-pinetab2.dtsi"
+
+/ {
+   model = "Pine64 PineTab2 v2.0";
+   compatible = "pine64,pinetab2-v2.0", "pine64,pinetab2", 
"rockchip,rk3566";
+};
+
+&gpio_keys {
+   pinctrl-0 = <&kb_id_det>, <&hall_int_l>;
+
+   event-hall-sensor {
+   debounce-interval = <20>;
+   gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_LOW>;
+   label = "Hall Sensor";
+   linux,code = ;
+   linux,input-type = ;
+   wakeup-event-action = ;
+   wakeup-source;
+   };
+};
+
+&lcd {
+   reset-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_LOW>;
+};
+
+&pinctrl {
+   lcd0 {
+   lcd0_rst_l: lcd0-rst-l {
+   rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+
+   hall {
+   hall_int_l: hall-int-l {
+   rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+   };
+   };
+};
+
+&sdmmc1 {
+   vmmc-supply = <&vcc_sys>;
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
new file mode 100644
index ..5d895628406b
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -0,0 +1,959 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk3566.dtsi"
+
+/ {
+   chassis-type = "tablet";
+
+   aliases {
+   mmc0 = &sdhci;
+   mmc1 = &sdmmc0;
+   };
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = <&saradc 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <25>;
+
+   button-vol-up {
+   label = "Volume Up";
+   linux,code = ;
+   press-threshold-microvolt = <297500>;
+   };
+
+   button-vol-down {
+   label = "Volume Down";
+   linux,code = ;
+   press-threshold-microvolt = <1750>;
+   };
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = <&pwm4 0 25000 0>;
+ 

Re: [PATCH 27/27] fbdev/p9100: Drop now unused driver p9100

[Sam Ravnborg]

Hi Thomas,

On Tue, Jan 02, 2024 at 09:26:27AM +0100, Thomas Zimmermann wrote:
> Hi Sam
> 
> Am 19.12.23 um 23:03 schrieb Sam Ravnborg via B4 Relay:
> > From: Sam Ravnborg 
> > 
> > The p9100 driver is only relevant for the Sparcbook 3 machine,
> > and with sun4m support removed this driver is no longer relevant.
> > 
> > Signed-off-by: Sam Ravnborg 
> > Cc: "David S. Miller" 
> > Cc: Arnd Bergmann 
> > Cc: Andreas Larsson 
> > Cc: Helge Deller 
> 
> Thanks for cleaning up.
> 
> Ack-by: Thomas Zimmermann 
Thanks.
> 
> if the series is accepted.
As you may have seen there is a maintainer vacuum at the moment :-(
That holds up clean-up a bit, and I cannot find the motivation/time
to offer it myself at the moment (no sponsor for this type of work).

Sam

Re: [PATCH v9 0/2] Resolve suspend-resume racing with GuC destroy-context-worker

[Teres Alexis, Alan Previn]

On Wed, 2023-12-27 at 20:55 -0800, Teres Alexis, Alan Previn wrote:
> This series is the result of debugging issues root caused to
> races between the GuC's destroyed_worker_func being triggered
> vs repeating suspend-resume cycles with concurrent delayed
> fence signals for engine-freeing.
> 
alan:snip.

alan: I did not receive the CI-premerge email where the following was reported:
  IGT changes
  Possible regressions
  igt@i915_selftest@live@gt_pm:
  shard-rkl: PASS -> DMESG-FAIL
After going thru the error in dmesg and codes, i am confident this failure not
related to the series. This selftest calls rdmsrl functions (that doen't do
any requests / guc submissions) but gets a reply power of zero (the bug 
reported).
So this is unrelated.


Hi @"Vivi, Rodrigo" , just an FYI note that after the 
last
requested rebase, BAT passed twice in a row now so i am confident failures on 
rev7
and prior was unrelated and that this series is ready for merging. Thanks again
for all your help and patiences - this was a long one  :)

Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

[Ondřej Jirman]

Hello Manuel,

see below...

On Tue, Jan 02, 2024 at 05:15:47PM +0100, Manuel Traut wrote:
> From: Alexander Warnecke 
> 
> [...]
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> new file mode 100644
> index ..5d895628406b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
> @@ -0,0 +1,959 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "rk3566.dtsi"
> +
> +/ {
> + chassis-type = "tablet";
> +
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc0;
> + };
> +
> + chosen {
> + stdout-path = "serial2:150n8";
> + };
> +
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = <&saradc 0>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> + poll-interval = <25>;
> +
> + button-vol-up {
> + label = "Volume Up";
> + linux,code = ;
> + press-threshold-microvolt = <297500>;
> + };
> +
> + button-vol-down {
> + label = "Volume Down";
> + linux,code = ;
> + press-threshold-microvolt = <1750>;
> + };
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pwms = <&pwm4 0 25000 0>;
> + brightness-levels = <20 220>;
> + num-interpolated-steps = <200>;

Does this linear brightness -> PWM duty cycle mapping lead to linear
relationship between brighntess level and subjective brightness on this HW?

I doubt it a bit...

> + default-brightness-level = <100>;
> + power-supply = <&vcc_sys>;
> + };
> +
> + battery: battery {
> + compatible = "simple-battery";
> + charge-full-design-microamp-hours = <600>;
> + charge-term-current-microamp = <30>;
> + constant-charge-current-max-microamp = <200>;
> + constant-charge-voltage-max-microvolt = <430>;
> + voltage-max-design-microvolt = <435>;
> + voltage-min-design-microvolt = <340>;
> +
> + ocv-capacity-celsius = <20>;
> + ocv-capacity-table-0 = <4322000 100>, <425 95>, <4192000 
> 90>, <4136000 85>,
> +<408 80>, <4022000 75>, <3972000 
> 70>, <3928000 65>,
> +<3885000 60>, <3833000 55>, <3798000 
> 50>, <378 45>,
> +<3776000 40>, <3773000 35>, <3755000 
> 30>, <3706000 25>,
> +<364 20>, <3589000 15>, <3535000 
> 10>, <3492000 5>,
> +<340 0>;
> + };
> +
> + gpio_keys: gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&kb_id_det>;
> +
> + tablet-mode-switch {
> + debounce-interval = <20>;
> + gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
> + label = "Tablet Mode";
> + linux,input-type = ;
> + linux,code = ;
> + };
> + };
> +
> + hdmi-con {

hdmi-connector

> + compatible = "hdmi-connector";
> + type = "d";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +

Spurious newline ^

> + pinctrl-names = "default";
> + pinctrl-0 = <&flash_led_en_h>;
> +
> + led-0 {
> + gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> + color = ;
> + function = LED_FUNCTION_FLASH;
> + };
> + };
> +
> + rk817-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_det_l>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,name = "rk817_ext";
> + simple-audio-card,mclk-fs = <256>;
> +
> + simple-audio-card,widgets =
> + "Microphone", "Mic Jack",
> + "Headphone", "Headphones",
> + "Speaker", "Internal Speakers";
> +
> + simple-audio-card,routing =
> + "MICR", "Mic Jack",
> + "Headphones", "HPOL",
> + "Headphones", "HPOR",
> + "Internal Speakers", "Speaker Amplifier OUTL",
> + "Internal Speakers", 

Re: [PATCH] drm/amdkfd: fixes for HMM mem allocation

[Felix Kuehling]

On 2023-12-31 09:37, Dafna Hirschfeld wrote:

Few fixes to amdkfd and the doc of
devm_request_free_mem_region.

Signed-off-by: Dafna Hirschfeld 
---
  drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 6 +++---
  kernel/resource.c| 2 +-
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
index 6c25dab051d5..b8680e0753ca 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
@@ -1021,7 +1021,7 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
} else {
res = devm_request_free_mem_region(adev->dev, &iomem_resource, 
size);
if (IS_ERR(res))
-   return -ENOMEM;
+   return PTR_ERR(res);
pgmap->range.start = res->start;
pgmap->range.end = res->end;
pgmap->type = MEMORY_DEVICE_PRIVATE;
@@ -1037,10 +1037,10 @@ int kgd2kfd_init_zone_device(struct amdgpu_device *adev)
r = devm_memremap_pages(adev->dev, pgmap);
if (IS_ERR(r)) {
pr_err("failed to register HMM device memory\n");
-   /* Disable SVM support capability */
-   pgmap->type = 0;
if (pgmap->type == MEMORY_DEVICE_PRIVATE)
devm_release_mem_region(adev->dev, res->start, 
resource_size(res));
+   /* Disable SVM support capability */
+   pgmap->type = 0;


Ooff, thanks for catching that. For the KFD driver changes you can add

Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling 



return PTR_ERR(r);
}
  
diff --git a/kernel/resource.c b/kernel/resource.c

index 866ef3663a0b..fe890b874606 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1905,8 +1905,8 @@ get_free_mem_region(struct device *dev, struct resource 
*base,
   * devm_request_free_mem_region - find free region for device private memory
   *
   * @dev: device struct to bind the resource to
- * @size: size in bytes of the device memory to add
   * @base: resource tree to look in
+ * @size: size in bytes of the device memory to add
   *
   * This function tries to find an empty range of physical address big enough 
to
   * contain the new resource, so that it can later be hotplugged as ZONE_DEVICE

Re: [PATCH v4 01/29] dt-bindings: display: rockchip,inno-hdmi: Document RK3128 compatible

[Rob Herring]

On Fri, 22 Dec 2023 18:41:52 +0100, Alex Bee wrote:
> The integration for this SoC is different from the currently existing: It
> needs it's PHY's reference clock rate to calculate the DDC bus frequency
> correctly. The controller is also part of a powerdomain, so this gets added
> as an mandatory property for this variant.
> 
> Signed-off-by: Alex Bee 
> Reviewed-by: Conor Dooley 
> ---
> changes in v2:
>  - clarify that the controller itself is part of the powerdomain
>  - simplify clock-names
>  - made power-domains property only allowed (and required) for new variant
> 
> changes in v3:
>  - collect RB
> 
> changes in v4:
>  - none
> 
>  .../display/rockchip/rockchip,inno-hdmi.yaml  | 40 ++-
>  1 file changed, 38 insertions(+), 2 deletions(-)
> 

Since I applied the conversion I applied this one, thanks!

[PATCH] drm/msm/a7xx: Fix LLC typo

[Rob Clark]

From: Rob Clark 

We'd miss actually activating LLC.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index a5660d63535b..54dc5eb37f70 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -1646,7 +1646,7 @@ static int a6xx_gmu_pm_resume(struct msm_gpu *gpu)
 
msm_devfreq_resume(gpu);
 
-   adreno_is_a7xx(adreno_gpu) ? a7xx_llc_activate : 
a6xx_llc_activate(a6xx_gpu);
+   adreno_is_a7xx(adreno_gpu) ? a7xx_llc_activate(a6xx_gpu) : 
a6xx_llc_activate(a6xx_gpu);
 
return ret;
 }
-- 
2.43.0

Re: [PATCH 2/2] drm/panel: samsung-s6d7aa0: drop DRM_BUS_FLAG_DE_HIGH for lsl080al02

[Henrik Grimler]

Hi Artur,

On Mon, Jan 01, 2024 at 10:00:16PM +0100, Artur Weber wrote:
> It turns out that I had misconfigured the device I was using the panel
> with; the bus data polarity is not high for this panel, I had to change
> the config on the display controller's side.
> 
> Fix the panel config to properly reflect its accurate settings.
> 
> Signed-off-by: Artur Weber 

I guess it deserves a Fixes tag:
Fixes: 6810bb390282 ("drm/panel: Add Samsung S6D7AA0 panel controller driver")

Best regards,
Henrik Grimler

> ---
>  drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c 
> b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> index ea5a85779382..f23d8832a1ad 100644
> --- a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> +++ b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
> @@ -309,7 +309,7 @@ static const struct s6d7aa0_panel_desc 
> s6d7aa0_lsl080al02_desc = {
>   .off_func = s6d7aa0_lsl080al02_off,
>   .drm_mode = &s6d7aa0_lsl080al02_mode,
>   .mode_flags = MIPI_DSI_MODE_VSYNC_FLUSH | MIPI_DSI_MODE_VIDEO_NO_HFP,
> - .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> + .bus_flags = 0,
>  
>   .has_backlight = false,
>   .use_passwd3 = false,
> 
> -- 
> 2.43.0
> 
> 

Re: [PATCH] drm/msm/a7xx: Fix LLC typo

[Konrad Dybcio]

On 2.01.2024 20:33, Rob Clark wrote:
> From: Rob Clark 
> 
> We'd miss actually activating LLC.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c 
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index a5660d63535b..54dc5eb37f70 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -1646,7 +1646,7 @@ static int a6xx_gmu_pm_resume(struct msm_gpu *gpu)
>  
>   msm_devfreq_resume(gpu);
>  
> - adreno_is_a7xx(adreno_gpu) ? a7xx_llc_activate : 
> a6xx_llc_activate(a6xx_gpu);
> + adreno_is_a7xx(adreno_gpu) ? a7xx_llc_activate(a6xx_gpu) : 
> a6xx_llc_activate(a6xx_gpu);

/me cleans glasses

oh..

Reviewed-by: Konrad Dybcio 

Konrad

Re: [PATCH 2/2] drm/panel: samsung-s6d7aa0: drop DRM_BUS_FLAG_DE_HIGH for lsl080al02

[Jessica Zhang]

On 1/1/2024 1:00 PM, Artur Weber wrote:

It turns out that I had misconfigured the device I was using the panel
with; the bus data polarity is not high for this panel, I had to change
the config on the display controller's side.

Fix the panel config to properly reflect its accurate settings.

Signed-off-by: Artur Weber 


Hi Artur,

With Henrik's suggestion to add the Fixes tag,

Reviewed-by: Jessica Zhang 

Thanks,

Jessica Zhang


---
  drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c 
b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
index ea5a85779382..f23d8832a1ad 100644
--- a/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
+++ b/drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c
@@ -309,7 +309,7 @@ static const struct s6d7aa0_panel_desc 
s6d7aa0_lsl080al02_desc = {
.off_func = s6d7aa0_lsl080al02_off,
.drm_mode = &s6d7aa0_lsl080al02_mode,
.mode_flags = MIPI_DSI_MODE_VSYNC_FLUSH | MIPI_DSI_MODE_VIDEO_NO_HFP,
-   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+   .bus_flags = 0,
  
  	.has_backlight = false,

.use_passwd3 = false,

--
2.43.0

Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

[Jonas Karlman]

Hi Manuel and Ondřej,

On 2024-01-02 19:07, Ondřej Jirman wrote:
> Hello Manuel,

[...]

>> +
>> +&sfc {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <&fspi_dual_io_pins>;
>> +status = "okay";
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +flash@0 {
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +spi-max-frequency = <2400>;
> 
> That's a bit on the low side. The flash chip should work for all commands up 
> to
> 80MHz https://megous.com/dl/tmp/b428ad9b85ac4633.png and SGM3157YC6 switch
> for the FSPI-CLK should have high enough bandwidth, too.

I agree that this is a little bit on the low side, it was a safe rate
that I used for U-Boot. U-Boot required an exact rate of the supported
sfc clk rates: 24, 50, 75, 100, 125 or 150 MHz.

Please also note that the SPI NOR flash chip used in PineTab2 is not a
GigaDevice GD25LQ128E, it should be a SiliconKaiser SK25LP128, same as
found in the Pine64 PinePhone Pro.

> 
>> +spi-rx-bus-width = <2>;
> 
> GD25LQ128E supports quad I/O. Maybe try 4 if it will work.

The schematic only shows fspi D0 and D1 connected, and use the D2 line
for eMMC_RSTn, so spi-rx-bus-width = <2> should be correct.

> 
>> +spi-tx-bus-width = <1>;
>> +};
>> +};
>> +

Regards,
Jonas

Re: [PATCH v2 5/8] dt-bindings: nt35510: add compatible for FRIDA FRD400B25025-A-CTK

[Krzysztof Kozlowski]

On 01/01/2024 17:15, Dario Binacchi wrote:
> The patch adds the FRIDA FRD400B25025-A-CTK panel, which belongs to the
> Novatek NT35510-based panel family.
> 
> Signed-off-by: Dario Binacchi 
> 
> ---
> 
> Changes in v2:
> - Add a dash in front of each "items:"
> 
>  .../bindings/display/panel/novatek,nt35510.yaml| 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml 
> b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> index bc92928c805b..8e69446e00e0 100644
> --- a/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt35510.yaml
> @@ -14,9 +14,13 @@ allOf:
>  
>  properties:
>compatible:
> -items:
> -  - const: hydis,hva40wv1
> -  - const: novatek,nt35510
> +oneOf:
> +  - items:
> +  - const: hydis,hva40wv1
> +  - const: novatek,nt35510
> +  - items:
> +  - const: frida,frd400b25025
> +  - const: novatek,nt35510

If fallback compatibles are the same, just make  the first item as enum.
Less code.

Best regards,
Krzysztof

Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

[Ondřej Jirman]

On Tue, Jan 02, 2024 at 09:56:20PM +0100, Jonas Karlman wrote:
> Hi Manuel and Ondřej,
> 
> On 2024-01-02 19:07, Ondřej Jirman wrote:
> > Hello Manuel,
> 
> [...]
> 
> >> +
> >> +&sfc {
> >> +  pinctrl-names = "default";
> >> +  pinctrl-0 = <&fspi_dual_io_pins>;
> >> +  status = "okay";
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> >> +
> >> +  flash@0 {
> >> +  compatible = "jedec,spi-nor";
> >> +  reg = <0>;
> >> +  spi-max-frequency = <2400>;
> > 
> > That's a bit on the low side. The flash chip should work for all commands 
> > up to
> > 80MHz https://megous.com/dl/tmp/b428ad9b85ac4633.png and SGM3157YC6 switch
> > for the FSPI-CLK should have high enough bandwidth, too.
> 
> I agree that this is a little bit on the low side, it was a safe rate
> that I used for U-Boot. U-Boot required an exact rate of the supported
> sfc clk rates: 24, 50, 75, 100, 125 or 150 MHz.
> 
> Please also note that the SPI NOR flash chip used in PineTab2 is not a
> GigaDevice GD25LQ128E, it should be a SiliconKaiser SK25LP128, same as
> found in the Pine64 PinePhone Pro.

According to this http://en.siliconkaiser.com/pro/  it should maybe go up to
133MHz. No idea what's the difference between LP vs LE variant. So it may work
with 100 MHz.

On Pinephone Pro variants with nerfed SPI CLK signal integrity (any variant with
RE instead of a RESET button - so all production batches), anything above 10 MHz
has real trouble working. But this should not be the case here with PT2, looking
at the schematic...

Anyway, it's a nice to have.

> > 
> >> +  spi-rx-bus-width = <2>;
> > 
> > GD25LQ128E supports quad I/O. Maybe try 4 if it will work.
> 
> The schematic only shows fspi D0 and D1 connected, and use the D2 line
> for eMMC_RSTn, so spi-rx-bus-width = <2> should be correct.

Ah, I see.

regards,
o.

> > 
> >> +  spi-tx-bus-width = <1>;
> >> +  };
> >> +};
> >> +
> 
> Regards,
> Jonas

Re: [PATCH] drm/msm/dpu: fix kernel-doc warnings

[Paloma Arellano]

On 12/30/2023 10:08 PM, Randy Dunlap wrote:

Correct all kernel-doc warnings in dpu_encoder.c and dpu_rm.c:

dpu_encoder.c:212: warning: Excess struct member 'crtc_kickoff_cb' description 
in 'dpu_encoder_virt'
dpu_encoder.c:212: warning: Excess struct member 'crtc_kickoff_cb_data' 
description in 'dpu_encoder_virt'
dpu_encoder.c:212: warning: Excess struct member 'debugfs_root' description in 
'dpu_encoder_virt'

dpu_rm.c:35: warning: Excess struct member 'hw_res' description in 
'dpu_rm_requirements'
dpu_rm.c:208: warning: No description found for return value of 
'_dpu_rm_get_lm_peer'

Signed-off-by: Randy Dunlap 

Reviewed-by: Paloma Arellano 

Cc: Rob Clark 
Cc: Abhinav Kumar 
Cc: Dmitry Baryshkov 
Cc: Sean Paul 
Cc: Marijn Suijten 
Cc: linux-arm-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Jonathan Corbet 
Cc: Vegard Nossum 

[PATCH] drm/i915/huc: Allow for very slow HuC loading

[John . C . Harrison]

From: John Harrison 

A failure to load the HuC is occasionally observed where the cause is
believed to be a low GT frequency leading to very long load times.

So a) increase the timeout so that the user still gets a working
system even in the case of slow load. And b) report the frequency
during the load to see if that is the cause of the slow down.

Also update the similar code on the GuC load to not use uncore->gt
when there is a local gt available. The two should match, but no need
for unnecessary de-referencing.

Signed-off-by: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 10 ++--
 drivers/gpu/drm/i915/gt/uc/intel_huc.c| 64 ---
 2 files changed, 63 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 0f79cb6585182..52332bb143395 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -184,7 +184,7 @@ static int guc_wait_ucode(struct intel_guc *guc)
 * in the seconds range. However, there is a limit on how long an
 * individual wait_for() can wait. So wrap it in a loop.
 */
-   before_freq = intel_rps_read_actual_frequency(&uncore->gt->rps);
+   before_freq = intel_rps_read_actual_frequency(>->rps);
before = ktime_get();
for (count = 0; count < GUC_LOAD_RETRY_LIMIT; count++) {
ret = wait_for(guc_load_done(uncore, &status, &success), 1000);
@@ -192,7 +192,7 @@ static int guc_wait_ucode(struct intel_guc *guc)
break;
 
guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz, 
status = 0x%08X [0x%02X/%02X]\n",
-   count, 
intel_rps_read_actual_frequency(&uncore->gt->rps), status,
+   count, intel_rps_read_actual_frequency(>->rps), 
status,
REG_FIELD_GET(GS_BOOTROM_MASK, status),
REG_FIELD_GET(GS_UKERNEL_MASK, status));
}
@@ -204,7 +204,7 @@ static int guc_wait_ucode(struct intel_guc *guc)
u32 bootrom = REG_FIELD_GET(GS_BOOTROM_MASK, status);
 
guc_info(guc, "load failed: status = 0x%08X, time = %lldms, 
freq = %dMHz, ret = %d\n",
-status, delta_ms, 
intel_rps_read_actual_frequency(&uncore->gt->rps), ret);
+status, delta_ms, 
intel_rps_read_actual_frequency(>->rps), ret);
guc_info(guc, "load failed: status: Reset = %d, BootROM = 
0x%02X, UKernel = 0x%02X, MIA = 0x%02X, Auth = 0x%02X\n",
 REG_FIELD_GET(GS_MIA_IN_RESET, status),
 bootrom, ukernel,
@@ -254,11 +254,11 @@ static int guc_wait_ucode(struct intel_guc *guc)
guc_warn(guc, "excessive init time: %lldms! [status = 0x%08X, 
count = %d, ret = %d]\n",
 delta_ms, status, count, ret);
guc_warn(guc, "excessive init time: [freq = %dMHz, before = 
%dMHz, perf_limit_reasons = 0x%08X]\n",
-intel_rps_read_actual_frequency(&uncore->gt->rps), 
before_freq,
+intel_rps_read_actual_frequency(>->rps), before_freq,
 intel_uncore_read(uncore, 
intel_gt_perf_limit_reasons_reg(gt)));
} else {
guc_dbg(guc, "init took %lldms, freq = %dMHz, before = %dMHz, 
status = 0x%08X, count = %d, ret = %d\n",
-   delta_ms, 
intel_rps_read_actual_frequency(&uncore->gt->rps),
+   delta_ms, intel_rps_read_actual_frequency(>->rps),
before_freq, status, count, ret);
}
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index ba9e07fc2b577..9ccec7de9628a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
 #include 
 
 #include "gt/intel_gt.h"
+#include "gt/intel_rps.h"
 #include "intel_guc_reg.h"
 #include "intel_huc.h"
 #include "intel_huc_print.h"
@@ -447,17 +448,68 @@ static const char *auth_mode_string(struct intel_huc *huc,
return partial ? "clear media" : "all workloads";
 }
 
+/*
+ * Use a longer timeout for debug builds so that problems can be detected
+ * and analysed. But a shorter timeout for releases so that user's don't
+ * wait forever to find out there is a problem. Note that the only reason
+ * an end user should hit the timeout is in case of extreme thermal throttling.
+ * And a system that is that hot during boot is probably dead anyway!
+ */
+#if defined(CONFIG_DRM_I915_DEBUG_GEM)
+#define HUC_LOAD_RETRY_LIMIT   20
+#else
+#define HUC_LOAD_RETRY_LIMIT   3
+#endif
+
 int intel_huc_wait_for_auth_complete(struct intel_huc *huc,
 enum intel_huc_authentication_type type)
 {
struct intel_gt *gt = huc_to_gt(huc);
-   int ret;
+   struct intel_uncore *uncore = gt->uncore;
+   kt

Re: [PATCH] drm/msm/dpu: fix kernel-doc warnings

[Dmitry Baryshkov]

On Sun, 31 Dec 2023 at 08:08, Randy Dunlap  wrote:
>
> Correct all kernel-doc warnings in dpu_encoder.c and dpu_rm.c:
>
> dpu_encoder.c:212: warning: Excess struct member 'crtc_kickoff_cb' 
> description in 'dpu_encoder_virt'
> dpu_encoder.c:212: warning: Excess struct member 'crtc_kickoff_cb_data' 
> description in 'dpu_encoder_virt'
> dpu_encoder.c:212: warning: Excess struct member 'debugfs_root' description 
> in 'dpu_encoder_virt'
>
> dpu_rm.c:35: warning: Excess struct member 'hw_res' description in 
> 'dpu_rm_requirements'
> dpu_rm.c:208: warning: No description found for return value of 
> '_dpu_rm_get_lm_peer'
>
> Signed-off-by: Randy Dunlap 
> Cc: Rob Clark 
> Cc: Abhinav Kumar 
> Cc: Dmitry Baryshkov 
> Cc: Sean Paul 
> Cc: Marijn Suijten 
> Cc: linux-arm-...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: freedr...@lists.freedesktop.org
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Thomas Zimmermann 
> Cc: Jonathan Corbet 
> Cc: Vegard Nossum 
> --
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c |4 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c  |3 ++-
>  2 files changed, 2 insertions(+), 5 deletions(-)
>

Reviewed-by: Dmitry Baryshkov 

-- 
With best wishes
Dmitry

[PATCH -next] drm/xe: Remove unneeded semicolon

[Yang Li]

./drivers/gpu/drm/xe/xe_rtp.c:168:2-3: Unneeded semicolon

Signed-off-by: Yang Li 
---
 drivers/gpu/drm/xe/xe_rtp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/xe_rtp.c b/drivers/gpu/drm/xe/xe_rtp.c
index fb44cc7521d8..316ed2f6d1f0 100644
--- a/drivers/gpu/drm/xe/xe_rtp.c
+++ b/drivers/gpu/drm/xe/xe_rtp.c
@@ -165,7 +165,7 @@ static void rtp_get_context(struct xe_rtp_process_ctx *ctx,
*gt = (*hwe)->gt;
*xe = gt_to_xe(*gt);
break;
-   };
+   }
 }
 
 /**
-- 
2.20.1.7.g153144c

Re: linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi all,

On Tue, 2 Jan 2024 11:12:22 +1100 Stephen Rothwell  
wrote:
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
> 
> In file included from include/drm/drm_mm.h:51,
>  from drivers/gpu/drm/xe/xe_bo_types.h:11,
>  from drivers/gpu/drm/xe/xe_bo.h:11,
>  from 
> drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11,
>  from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15,
>  from drivers/gpu/drm/i915/display/intel_display_power.c:8:
> drivers/gpu/drm/i915/display/intel_display_power.c: In function 
> 'print_async_put_domains_state':
> drivers/gpu/drm/i915/display/intel_display_power.c:408:29: warning: format 
> '%lu' expects argument of type 'long unsigned int', but argument 5 has type 
> 'int' [-Wformat=]
>   408 | drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
>   | ^
>   409 | power_domains->async_put_wakeref);
>   | 
>   |  |
>   |  int
> 
> Introduced by commit
> 
>   b49e894c3fd8 ("drm/i915: Replace custom intel runtime_pm tracker with 
> ref_tracker library")
> 
> This would be an error except that I am building with CONFIG_WERROR=n

OK, so I have turned off CONFIG_WERROR=n in the run up to the merge
window opening and so this is now a build failure.  I have tried
applying the following patch for today:

From: Stephen Rothwell 
Date: Wed, 3 Jan 2024 11:40:26 +1100
Subject: [PATCH] fix up for "drm/i915: Replace custom intel runtime_pm tracker
 with ref_tracker library"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5f091502719b..f23080a4368d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -405,7 +405,7 @@ print_async_put_domains_state(struct i915_power_domains 
*power_domains)
 struct drm_i915_private,
 display.power.domains);
 
-   drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
+   drm_dbg(&i915->drm, "async_put_wakeref %u\n",
power_domains->async_put_wakeref);
 
print_power_domains(power_domains, "async_put_domains[0]",
-- 
2.43.0

but that produces this failure:

In file included from include/drm/ttm/ttm_resource.h:34,
 from include/drm/ttm/ttm_device.h:30,
 from drivers/gpu/drm/i915/i915_drv.h:37,
 from drivers/gpu/drm/i915/display/intel_display_power.c:8:  
drivers/gpu/drm/i915/display/intel_display_power.c: In function 
'print_async_put_domains_state':
drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error: format '%u' 
expects argument of type 'unsigned int', but argument 5 has type 
'intel_wakeref_t' {aka 'long unsigned int'} [-Werror=format=]
  408 | drm_dbg(&i915->drm, "async_put_wakeref %u\n",
  | ^~~~
  409 | power_domains->async_put_wakeref);
  | 
  |  |
  |  intel_wakeref_t {aka long unsigned int}

I don't understand how the above patch can change the compilation like
that.  I must be missing something obvious.  Maybe my compiler is
strangely broken?  I have applied the following instead (which at least
builds):

From: Stephen Rothwell 
Date: Wed, 3 Jan 2024 11:40:26 +1100
Subject: [PATCH] fix up for "drm/i915: Replace custom intel runtime_pm tracker
 with ref_tracker library"

Signed-off-by: Stephen Rothwell 
---
 drivers/gpu/drm/i915/display/intel_display_power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5f091502719b..6253ce061d20 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -406,7 +406,7 @@ print_async_put_domains_state(struct i915_power_domains 
*power_domains)
 display.power.domains);
 
drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
-   power_domains->async_put_wakeref);
+   (unsigned long int)power_domains->async_put_wakeref);
 
print_power_domains(power_domains, "async_put_domains[0]",
&power_domains->async_put_domains[0]);
-- 
2.43.0

-- 
Cheers,
Stephen Rothwell


pgpaB05o7PZcs.pgp
Description: OpenPGP digital signature

[PATCH -next] drm/xe/kunit: Remove duplicated include in xe_pci.c

[Yang Li]

The header files test-bug.h is included twice in xe_pci.c,
so one inclusion can be removed.

./drivers/gpu/drm/xe/tests/xe_pci.c: kunit/test-bug.h is included more than 
once.

Signed-off-by: Yang Li 
---
 drivers/gpu/drm/xe/tests/xe_pci.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/xe/tests/xe_pci.c 
b/drivers/gpu/drm/xe/tests/xe_pci.c
index 602793644f61..6d53f9fd17e4 100644
--- a/drivers/gpu/drm/xe/tests/xe_pci.c
+++ b/drivers/gpu/drm/xe/tests/xe_pci.c
@@ -9,7 +9,6 @@
 
 #include 
 #include 
-#include 
 #include 
 
 struct kunit_test_data {
-- 
2.20.1.7.g153144c

Re: linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi all,

On Wed, 3 Jan 2024 12:19:11 +1100 Stephen Rothwell  
wrote:
>
> On Tue, 2 Jan 2024 11:12:22 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> > produced this warning:
> > 
> > In file included from include/drm/drm_mm.h:51,
> >  from drivers/gpu/drm/xe/xe_bo_types.h:11,
> >  from drivers/gpu/drm/xe/xe_bo.h:11,
> >  from 
> > drivers/gpu/drm/xe/compat-i915-headers/gem/i915_gem_object.h:11,
> >  from drivers/gpu/drm/xe/compat-i915-headers/i915_drv.h:15,
> >  from drivers/gpu/drm/i915/display/intel_display_power.c:8:
> > drivers/gpu/drm/i915/display/intel_display_power.c: In function 
> > 'print_async_put_domains_state':
> > drivers/gpu/drm/i915/display/intel_display_power.c:408:29: warning: format 
> > '%lu' expects argument of type 'long unsigned int', but argument 5 has type 
> > 'int' [-Wformat=]
> >   408 | drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
> >   | ^
> >   409 | power_domains->async_put_wakeref);
> >   | 
> >   |  |
> >   |  int
> > 
>
> In file included from include/drm/ttm/ttm_resource.h:34,
>  from include/drm/ttm/ttm_device.h:30,
>  from drivers/gpu/drm/i915/i915_drv.h:37,
>  from drivers/gpu/drm/i915/display/intel_display_power.c:8:  
> drivers/gpu/drm/i915/display/intel_display_power.c: In function 
> 'print_async_put_domains_state':
> drivers/gpu/drm/i915/display/intel_display_power.c:408:29: error: format '%u' 
> expects argument of type 'unsigned int', but argument 5 has type 
> 'intel_wakeref_t' {aka 'long unsigned int'} [-Werror=format=]
>   408 | drm_dbg(&i915->drm, "async_put_wakeref %u\n",
>   | ^~~~
>   409 | power_domains->async_put_wakeref);
>   | 
>   |  |
>   |  intel_wakeref_t {aka long unsigned int}
> 
> I don't understand how the above patch can change the compilation like
> that.  I must be missing something obvious.  Maybe my compiler is
> strangely broken?

OK, the only thing I can find is that there are 2 intel_wakeref.h files
that have different definitions for intel_wakeref_t:

./drivers/gpu/drm/i915/intel_wakeref.h:typedef unsigned long intel_wakeref_t;
./drivers/gpu/drm/xe/compat-i915-headers/intel_wakeref.h:typedef bool 
intel_wakeref_t;

and the two compilations above seem to use different include paths, but
how the single character change causes that is beyond me.
-- 
Cheers,
Stephen Rothwell


pgpQsr7SGYoJY.pgp
Description: OpenPGP digital signature

[PATCH] drm/xe/vm: Simplify the calculation of variables

[Jiapeng Chong]

./drivers/gpu/drm/xe/xe_vm.c:187:25-27: WARNING !A || A && B is equivalent to 
!A || B.

Reported-by: Abaci Robot 
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7818
Signed-off-by: Jiapeng Chong 
---
 drivers/gpu/drm/xe/xe_vm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c
index 9180f2d2d71d..dd304a92d0bb 100644
--- a/drivers/gpu/drm/xe/xe_vm.c
+++ b/drivers/gpu/drm/xe/xe_vm.c
@@ -184,8 +184,8 @@ static bool preempt_fences_waiting(struct xe_vm *vm)
 
list_for_each_entry(q, &vm->preempt.exec_queues, compute.link) {
if (!q->compute.pfence ||
-   (q->compute.pfence && 
test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
-  &q->compute.pfence->flags))) 
{
+   test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+&q->compute.pfence->flags)) {
return true;
}
}
-- 
2.20.1.7.g153144c

Re: [PATCH -next] drm/nouveau: uapi: fix kerneldoc warnings

[Randy Dunlap]

Hi Vegard,

On 12/25/23 09:08, Randy Dunlap wrote:
> 
> 
> On 12/25/23 00:30, Vegard Nossum wrote:
>>
>> On 25/12/2023 08:40, Randy Dunlap wrote:
>>> I do see one thing that I don't like in the generated html output.
>>> It's not a problem with this patch.
>>> The #defines for DRM_NOUVEAU_VM_BIND_OP_MAP etc. have a ';' at the
>>> end of each line:
>>>
>>> struct drm_nouveau_vm_bind_op {
>>>  __u32 op;
>>> #define DRM_NOUVEAU_VM_BIND_OP_MAP 0x0;
>>> #define DRM_NOUVEAU_VM_BIND_OP_UNMAP 0x1;
>>>  __u32 flags;
>>> #define DRM_NOUVEAU_VM_BIND_SPARSE (1 << 8);
>>>  __u32 handle;
>>>  __u32 pad;
>>>  __u64 addr;
>>>  __u64 bo_offset;
>>>  __u64 range;
>>> };
>>
>> Do we actually ever want preprocessor directives to appear inside
>> definitions in the output? If not, I think this should work:
> 
> Not necessarily.
> 
>> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
>> index 3cdc7dba37e3..61425fc9645e 100755
>> --- a/scripts/kernel-doc
>> +++ b/scripts/kernel-doc
>> @@ -1259,6 +1259,8 @@ sub dump_struct($$) {
>> $clause =~ s/\s+$//;
>> $clause =~ s/\s+/ /;
>> next if (!$clause);
>> +   # skip preprocessor directives
>> +   next if $clause =~ m/^#/;
>> $level-- if ($clause =~ m/(\})/ && $level > 1);
>> if (!($clause =~ m/^\s*#/)) {
>> $declaration .= "\t" x $level;
>>
>>
> 
> but that didn't work for me.
> I don't have time to look into it any more today.  :)

I retested this patch. I must have really messed up my testing
in the first round. This now LGTM. Thanks.

Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 

-- 
#Randy

Re: [PATCH v3 4/4] arm64: dts: rockchip: Add devicetree for Pine64 PineTab2

[Dang Huynh]

On Tuesday, January 2, 2024 6:07:56 PM UTC Ondřej Jirman wrote:
> On Tue, Jan 02, 2024 at 05:15:47PM +0100, Manuel Traut wrote:
> > +&pcie2x1 {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pcie_reset_h>;
> > +   reset-gpios = <&gpio1 RK_PB2 GPIO_ACTIVE_HIGH>;
> > +   vpcie3v3-supply = <&vcc3v3_minipcie>;
> > +   status = "okay";
> > +};
> 
> Does it make sense to enable this HW block by default, when it isn't used on
> actual HW?
> 

PCI-E is hooked up to a connector in the schematics, so I think it make sense 
to enable it when there's one available.

Re: [PATCH v3 00/11] Add mediate-drm secure flow for SVP

[林睿祥]