Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Krzysztof Kozlowski]

On 05/12/2023 08:56, Tony Lindgren wrote:
> * Krzysztof Kozlowski  [231205 07:10]:
>> On 04/12/2023 19:22, Andrew Davis wrote:
>>> @@ -56,6 +76,43 @@ allOf:
>>>properties:
>>>  clocks:
>>>maxItems: 1
>>> +  required:
>>> +- clocks
>>> +- clock-names
>>
>> You need to define the clocks for your variants or disallow them. The
>> original code should be fixed as well and make the clocks fixed for all
>> img-axe cases.
> 
> To clarify, the clocks may be optional as they can be hardwired and coming
> from the interconnect target wrapper module and enabled with runtime PM.

What does runtime PM have to do with it? If runtime PM enables clocks,
these are real signals and not optional.

The bindings is quite unspecific in that matter which is not what we
want usually. If you have implementation which does not have these
clocks exposed, then disallow them.

Just don't make it floating like it is in existing binding and how
Andrew continues for new devices.

Best regards,
Krzysztof

Re: [PATCH v3 00/14] drm: Add a driver for CSF-based Mali GPUs

[Boris Brezillon]

Hi Clément,

On Mon, 4 Dec 2023 19:09:54 +0100
Clément Péron  wrote:

> Hi Boris,
> 
> On Mon, 4 Dec 2023 at 18:33, Boris Brezillon
>  wrote:
> >
> > Hello,
> >
> > This is the 3rd version of the kernel driver for Mali CSF-based GPUs.
> >
> > With all the DRM dependencies being merged (drm-sched single entity and
> > drm_gpuvm), I thought now was a good time to post a new version. Note
> > that the iommu series we depend on [1] has been merged recently. The
> > only remaining dependency that hasn't been merged yet is this rather
> > trival drm_gpuvm [2] patch.
> >
> > As for v2, I pushed a branch based on drm-misc-next and containing
> > all the dependencies that are not yet available in drm-misc-next
> > here[3], and another [4] containing extra patches to have things
> > working on rk3588. The CSF firmware binary can be found here[5], and
> > should be placed under /lib/firmware/arm/mali/arch10.8/mali_csffw.bin.
> >
> > The mesa MR adding v10 support on top of panthor is available here [6].
> >
> > Regarding the GPL2+MIT relicensing, Liviu did an audit and found two
> > more people that I didn't spot initially: Clément Péron for the devfreq
> > code, and Alexey Sheplyakov for some bits in panthor_gpu.c. Both are
> > Cc-ed on the relevant patches. The rest of the code is either new, or
> > covered by the Linaro, Arm and Collabora acks.  
> 
> I only did some trivial cleaning, the relicensing is fine for me.
> Do you need me to ack some patches?

Yes, please. We identified that most of your contributions were related
to the devfreq logic ("drm/panthor: Add the devfreq logical block" in
this series), but if you remember contributing to other files in
panfrost, feel free to give a general ack on all your panfrost
contributions.

Thanks,

Boris

[Bug 218221] Nouveau GSP fail on command cli:0xc1d0000

[bugzilla-daemon]

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

--- Comment #3 from marc barbier (mmarc...@gmail.com) ---
(In reply to airlied from comment #2)
> Can't remember my bz, but all those errors are fine, I've sent patches
> to clean them up so we don't report them in dmesg anymore.
> 
> On Tue, 5 Dec 2023 at 01:12,  wrote:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=218221
> >
> > Bug ID: 218221
> >Summary: Nouveau GSP fail on command cli:0xc1d
> >Product: Drivers
> >Version: 2.5
> >   Hardware: All
> > OS: Linux
> > Status: NEW
> >   Severity: normal
> >   Priority: P3
> >  Component: Video(DRI - non Intel)
> >   Assignee: drivers_video-...@kernel-bugs.osdl.org
> >   Reporter: mmarc...@gmail.com
> > Regression: No
> >
> > Running Linux 6.7.0-rc3 on Gentoo Linux
> >
> > I'm using a 3070(laptop) with the command line argument
> > nouveau.config=NvGspRm=1
> >
> > I have confirmed that the Gsp firmware in present in my system, and I'm
> > running
> > mesa 23.3.0
> >
> > This should allow the nouveau kernel driver to call the GSP firmware for
> > tasks
> > such as reclocking.
> >
> > As my system is a laptop my main GPU is an integrated radeon gpu so
> starting
> > Xorg doesn't require nouveau to work.
> >
> > Once X11 is started I can try to launch vulkan applications which causes
> the
> > following errors to appear in the kernel log.
> >
> > > dmesg
> > [   17.007772] nouveau :01:00.0: gsp:msg fn:4123 len:0x24/0x4 res:0x0
> > resp:0x0
> > [   17.010650] nouveau :01:00.0: gsp:msg fn:4108 len:0x38/0x18 res:0x0
> > resp:0x0
> > [   17.010945] nouveau :01:00.0: gsp:msg fn:4108 len:0x40/0x20 res:0x0
> > resp:0x0
> > [15217.991692] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.992913] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.994155] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.995408] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.996738] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.997859] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15217.999154] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.000392] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.001799] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.003055] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.004271] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.005615] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.007023] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.008281] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.009543] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.010843] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.012054] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.013295] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.014570] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.015841] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.017084] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.018206] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.019532] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.020804] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.022064] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.023324] nouveau :01:00.0: gsp: cli:0xc1d2 obj:0x0073
> ctrl
> > cmd:0x00731341 failed: 0x
> > [15218.024644] nouveau :01:00.0: gsp: cli:0xc1d2 obj

Re: [PATCH v3 06/10] drm/panel: Add Synaptics R63353 panel driver

[Neil Armstrong]

Hi Dario,

On 30/11/2023 15:16, Dario Binacchi wrote:

From: Michael Trimarchi 

The LS068B3SX02 panel is based on the Synaptics R63353 Controller.
Add a driver for it.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

(no changes since v2)

Changes in v2:
- Adjust the timings of the panel reset

  MAINTAINERS   |   6 +
  drivers/gpu/drm/panel/Kconfig |   9 +
  drivers/gpu/drm/panel/Makefile|   1 +
  .../gpu/drm/panel/panel-synaptics-r63353.c| 375 ++
  4 files changed, 391 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 012df8ccf34e..c373764b6e64 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6875,6 +6875,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/display/ste,mcde.yaml
  F:drivers/gpu/drm/mcde/
  
+DRM DRIVER FOR SYNAPTICS R63353 PANELS

+M: Michael Trimarchi 
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
+F: drivers/gpu/drm/panel/panel-synaptics-r63353.c
+
  DRM DRIVER FOR TI DLPC3433 MIPI DSI TO DMD BRIDGE
  M:Jagan Teki 
  S:Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..d018702be3dc 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -735,6 +735,15 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
  
+config DRM_PANEL_SYNAPTICS_R63353

+   tristate "Synaptics R63353-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Synaptics R63353 controller.
+
  config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..f267d932c2b5 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS060T1SX01) += 
panel-sharp-ls060t1sx01.o
  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SYNAPTICS_R63353) += panel-synaptics-r63353.o
  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
  obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
  obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) += 
panel-sony-tulip-truly-nt35521.o
diff --git a/drivers/gpu/drm/panel/panel-synaptics-r63353.c 
b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
new file mode 100644
index ..d45373de7c9f
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synaptics R63353 Controller driver
+ *
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define R63353_INSTR(...) { \
+   .len = sizeof((u8[]) {__VA_ARGS__}), \
+   .data = (u8[]){__VA_ARGS__} \
+   }
+
+struct r63353_instr {
+   size_t len;
+   const u8 *data;
+};
+
+static const struct r63353_instr sharp_ls068b3sx02_init[] = {
+   R63353_INSTR(0x51, 0xff),
+   R63353_INSTR(0x53, 0x0c),
+   R63353_INSTR(0x55, 0x00),
+   R63353_INSTR(0x84, 0x00),
+   R63353_INSTR(0x29),
+};
+
+struct r63353_desc {
+   const char *name;
+   const struct r63353_instr *init;
+   const size_t init_length;
+   const struct drm_display_mode *mode;
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct r63353_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct gpio_desc *reset_gpio;
+   struct regulator *dvdd;
+   struct regulator *avdd;
+
+   bool prepared;


You can drop this, it's no more needed since:commit:
d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel")


+   struct r63353_desc *pdata;
+};
+
+static inline struct r63353_panel *to_r63353_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct r63353_panel, base);
+}
+
+static int r63353_panel_power_on(struct r63353_panel *rpanel)
+{
+   struct mipi_dsi_device *dsi = rpanel->dsi;
+   struct device *dev = &dsi->dev;
+   int ret;
+
+   ret = regulator_enable(rpanel->avdd);
+   if (ret) {
+   dev_err(dev, "Failed to enable avdd regulator (%d)\n", ret);
+   return ret;
+   }
+
+   usleep_range(15000, 25000)

Re: [PATCH v3 08/10] drm/panel: Add Ilitek ILI9805 panel driver

[Neil Armstrong]

Hi Dario,

On 30/11/2023 15:16, Dario Binacchi wrote:

From: Michael Trimarchi 

The GPM1790A0 panel is based on the Ilitek ILI9805 Controller.
Add a driver for it.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

  MAINTAINERS  |   6 +
  drivers/gpu/drm/panel/Kconfig|   9 +
  drivers/gpu/drm/panel/Makefile   |   1 +
  drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 365 +++
  4 files changed, 381 insertions(+)
  create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c

diff --git a/MAINTAINERS b/MAINTAINERS
index c373764b6e64..a89fbc811dc5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6647,6 +6647,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
  F:Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
  F:drivers/gpu/drm/tiny/ili9486.c
  
+DRM DRIVER FOR ILITEK ILI9805 PANELS

+M: Michael Trimarchi 
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
+F: drivers/gpu/drm/panel/panel-ilitek-ili9805.c
+
  DRM DRIVER FOR JADARD JD9365DA-H3 MIPI-DSI LCD PANELS
  M:Jagan Teki 
  S:Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d018702be3dc..dad938cf6dec 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -194,6 +194,15 @@ config DRM_PANEL_ILITEK_ILI9341
  QVGA (240x320) RGB panels. support serial & parallel rgb
  interface.
  
+config DRM_PANEL_ILITEK_ILI9805

+   tristate "Ilitek ILI9805-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9805 controller.
+
  config DRM_PANEL_ILITEK_ILI9881C
tristate "Ilitek ILI9881C-based panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f267d932c2b5..d94a644d0a6c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d
  obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
  obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o
  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
  obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o
  obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
new file mode 100644
index ..749959e10d92
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -0,0 +1,365 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define ILI9805_EXTCMD_CMD_SET_ENABLE_REG  (0xff)
+#define ILI9805_SETEXTC_PARAMETER1 (0xff)
+#define ILI9805_SETEXTC_PARAMETER2 (0x98)
+#define ILI9805_SETEXTC_PARAMETER3 (0x05)
+
+#define ILI9805_INSTR(_delay, ...) { \
+   .delay = (_delay), \
+   .len = sizeof((u8[]) {__VA_ARGS__}), \
+   .data = (u8[]){__VA_ARGS__} \
+   }
+
+struct ili9805_instr {
+   size_t len;
+   const u8 *data;
+   u32 delay;
+};
+
+struct ili9805_desc {
+   const char *name;
+   const struct ili9805_instr *init;
+   const size_t init_length;
+   const struct drm_display_mode *mode;
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct ili9805 {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+   const struct ili9805_desc   *desc;
+
+   struct regulator*dvdd;
+   struct regulator*avdd;
+   struct gpio_desc*reset_gpio;
+
+   boolprepared;


Like patch 6, please from this, it's not more needed.


+};
+
+static const struct ili9805_instr gpm1780a0_init[] = {
+   ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG, 
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+   ILI9805_INSTR(100, 0xFD, 0x0F, 0x10, 0x44, 0x00),
+   ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x00,
+ 0x00, 0x30, 0x00, 0x00, 0x30, 0x00, 0x00),
+   ILI9805_INSTR(0, 0xB8, 0x62),
+   ILI9805_INSTR(0, 0xF1, 0x00),
+   ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+   ILI9805_INSTR(0, 0xF3, 0x60, 0x83, 0x04),
+   ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+   ILI9805_INSTR(0, 0xEB, 0x0

Re: [PATCH v3 09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel

[Neil Armstrong]

On 30/11/2023 15:16, Dario Binacchi wrote:

From: Michael Trimarchi 

Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller.

Add this panel's initialzation sequence and timing to ILI9805 driver.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

  drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 53 
  1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
index 749959e10d92..cd187b0b1998 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -89,6 +89,36 @@ static const struct ili9805_instr gpm1780a0_init[] = {
ILI9805_INSTR(0, 0xB9, 0x02, 0x00),
  };
  
+static const struct ili9805_instr tm041xdhg01_init[] = {

+   ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG, 
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+   ILI9805_INSTR(100, 0xFD, 0x0F, 0x13, 0x44, 0x00),
+   ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x01,
+ 0x01, 0x30, 0x01, 0x01, 0x30, 0x01, 0x01),
+   ILI9805_INSTR(0, 0xB8, 0x74),
+   ILI9805_INSTR(0, 0xF1, 0x00),
+   ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+   ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+   ILI9805_INSTR(0, 0xEB, 0x08, 0x0F),
+   ILI9805_INSTR(0, 0xe0, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08, 
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+   ILI9805_INSTR(0, 0xe1, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08, 
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+   ILI9805_INSTR(10, 0xc1, 0x15, 0x03, 0x03, 0x31),
+   ILI9805_INSTR(10, 0xB1, 0x00, 0x12, 0x14),
+   ILI9805_INSTR(10, 0xB4, 0x02),
+   ILI9805_INSTR(0, 0xBB, 0x14, 0x55),
+   ILI9805_INSTR(0, MIPI_DCS_SET_ADDRESS_MODE, 0x0a),
+   ILI9805_INSTR(0, MIPI_DCS_SET_PIXEL_FORMAT, 0x77),
+   ILI9805_INSTR(0, 0x20),
+   ILI9805_INSTR(0, 0xB0, 0x00),
+   ILI9805_INSTR(0, 0xB6, 0x01),
+   ILI9805_INSTR(0, 0xc2, 0x11),
+   ILI9805_INSTR(0, 0x51, 0xFF),
+   ILI9805_INSTR(0, 0x53, 0x24),
+   ILI9805_INSTR(0, 0x55, 0x00),
+};
+
  static inline struct ili9805 *panel_to_ili9805(struct drm_panel *panel)
  {
return container_of(panel, struct ili9805, panel);
@@ -239,6 +269,20 @@ static const struct drm_display_mode gpm1780a0_timing = {
.vtotal = 480 + 2 + 4 + 10,
  };
  
+static const struct drm_display_mode tm041xdhg01_timing = {

+   .clock = 26227,
+
+   .hdisplay = 480,
+   .hsync_start = 480 + 10,
+   .hsync_end = 480 + 10 + 2,
+   .htotal = 480 + 10 + 2 + 36,
+
+   .vdisplay = 768,
+   .vsync_start = 768 + 2,
+   .vsync_end = 768 + 10 + 4,
+   .vtotal = 768 + 2 + 4 + 10,
+};
+
  static int ili9805_get_modes(struct drm_panel *panel,
  struct drm_connector *connector)
  {
@@ -343,8 +387,17 @@ static const struct ili9805_desc gpm1780a0_desc = {
.height_mm = 65,
  };
  
+static const struct ili9805_desc tm041xdhg01_desc = {

+   .init = tm041xdhg01_init,
+   .init_length = ARRAY_SIZE(tm041xdhg01_init),
+   .mode = &tm041xdhg01_timing,
+   .width_mm = 42,
+   .height_mm = 96,
+};
+
  static const struct of_device_id ili9805_of_match[] = {
{ .compatible = "giantplus,gpm1790a0", .data = &gpm1780a0_desc },
+   { .compatible = "tianma,tm041xdhg01", .data = &tm041xdhg01_desc },
{ }
  };
  MODULE_DEVICE_TABLE(of, ili9805_of_match);


Reviewed-by: Neil Armstrong 

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Tony Lindgren]

* Krzysztof Kozlowski  [231205 08:03]:
> What does runtime PM have to do with it? If runtime PM enables clocks,
> these are real signals and not optional.

Runtime PM propagates to the parent device.

Regards,

Tony

Re: [PATCH 2/2] drm/panel: simple: Add BOE BP101WX1-100 panel

[Neil Armstrong]

On 27/11/2023 06:15, Tony Lindgren wrote:

This panel is found on Motorola mapphone tablets from mz615 to mz617.

Signed-off-by: Tony Lindgren 
---
  drivers/gpu/drm/panel/panel-simple.c | 32 
  1 file changed, 32 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1324,6 +1324,35 @@ static const struct panel_desc bananapi_s070wv20_ct16 = {
},
  };
  
+static const struct drm_display_mode boe_bp101wx1_100_mode = {

+   .clock = 78945,
+   .hdisplay = 1280,
+   .hsync_start = 1280 + 0,
+   .hsync_end = 1280 + 0 + 2,
+   .htotal = 1280 + 62 + 0 + 2,
+   .vdisplay = 800,
+   .vsync_start = 800 + 8,
+   .vsync_end = 800 + 8 + 2,
+   .vtotal = 800 + 6 + 8 + 2,
+};
+
+static const struct panel_desc boe_bp101wx1_100 = {
+   .modes = &boe_bp101wx1_100_mode,
+   .num_modes = 1,
+   .bpc = 8,
+   .size = {
+   .width = 217,
+   .height = 136,
+   },
+   .delay = {
+   .enable = 50,
+   .disable = 50,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+   .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
  static const struct display_timing boe_ev121wxm_n10_1850_timing = {
.pixelclock = { 69922000, 7100, 72293000 },
.hactive = { 1280, 1280, 1280 },
@@ -4252,6 +4281,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "bananapi,s070wv20-ct16",
.data = &bananapi_s070wv20_ct16,
+   }, {
+   .compatible = "boe,bp101wx1-100",
+   .data = &boe_bp101wx1_100,
}, {
.compatible = "boe,ev121wxm-n10-1850",
.data = &boe_ev121wxm_n10_1850,


Reviewed-by: Neil Armstrong 

Re: [PATCH 3/3] drm/panel: ilitek-ili9881c: Add Ampire AM8001280G LCD panel

[Neil Armstrong]

On 23/11/2023 18:08, Philipp Zabel wrote:

Add support for Ampire AM8001280G LCD panels.

Signed-off-by: Philipp Zabel 
---
  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 223 ++
  1 file changed, 223 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0c911ed9141b..2ffe5f68a890 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -830,6 +830,203 @@ static const struct ili9881c_instr w552946ab_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(0),
  };
  
+static const struct ili9881c_instr am8001280g_init[] = {

+   ILI9881C_SWITCH_PAGE_INSTR(3),
+   ILI9881C_COMMAND_INSTR(0x01, 0x00),
+   ILI9881C_COMMAND_INSTR(0x02, 0x00),
+   ILI9881C_COMMAND_INSTR(0x03, 0x73),
+   ILI9881C_COMMAND_INSTR(0x04, 0xD3),
+   ILI9881C_COMMAND_INSTR(0x05, 0x00),
+   ILI9881C_COMMAND_INSTR(0x06, 0x0A),
+   ILI9881C_COMMAND_INSTR(0x07, 0x0E),
+   ILI9881C_COMMAND_INSTR(0x08, 0x00),
+   ILI9881C_COMMAND_INSTR(0x09, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0a, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0b, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0c, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0d, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0e, 0x01),
+   ILI9881C_COMMAND_INSTR(0x0f, 0x01),
+   ILI9881C_COMMAND_INSTR(0x10, 0x01),
+   ILI9881C_COMMAND_INSTR(0x11, 0x00),
+   ILI9881C_COMMAND_INSTR(0x12, 0x00),
+   ILI9881C_COMMAND_INSTR(0x13, 0x00),
+   ILI9881C_COMMAND_INSTR(0x14, 0x00),
+   ILI9881C_COMMAND_INSTR(0x15, 0x00),
+   ILI9881C_COMMAND_INSTR(0x16, 0x00),
+   ILI9881C_COMMAND_INSTR(0x17, 0x00),
+   ILI9881C_COMMAND_INSTR(0x18, 0x00),
+   ILI9881C_COMMAND_INSTR(0x19, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x1e, 0x40),
+   ILI9881C_COMMAND_INSTR(0x1f, 0x80),
+   ILI9881C_COMMAND_INSTR(0x20, 0x06),
+   ILI9881C_COMMAND_INSTR(0x21, 0x01),
+   ILI9881C_COMMAND_INSTR(0x22, 0x00),
+   ILI9881C_COMMAND_INSTR(0x23, 0x00),
+   ILI9881C_COMMAND_INSTR(0x24, 0x00),
+   ILI9881C_COMMAND_INSTR(0x25, 0x00),
+   ILI9881C_COMMAND_INSTR(0x26, 0x00),
+   ILI9881C_COMMAND_INSTR(0x27, 0x00),
+   ILI9881C_COMMAND_INSTR(0x28, 0x33),
+   ILI9881C_COMMAND_INSTR(0x29, 0x03),
+   ILI9881C_COMMAND_INSTR(0x2a, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2b, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x2f, 0x00),
+   ILI9881C_COMMAND_INSTR(0x30, 0x00),
+   ILI9881C_COMMAND_INSTR(0x31, 0x00),
+   ILI9881C_COMMAND_INSTR(0x32, 0x00),
+   ILI9881C_COMMAND_INSTR(0x33, 0x00),
+   ILI9881C_COMMAND_INSTR(0x34, 0x03),
+   ILI9881C_COMMAND_INSTR(0x35, 0x00),
+   ILI9881C_COMMAND_INSTR(0x36, 0x03),
+   ILI9881C_COMMAND_INSTR(0x37, 0x00),
+   ILI9881C_COMMAND_INSTR(0x38, 0x00),
+   ILI9881C_COMMAND_INSTR(0x39, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3a, 0x40),
+   ILI9881C_COMMAND_INSTR(0x3b, 0x40),
+   ILI9881C_COMMAND_INSTR(0x3c, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3d, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3e, 0x00),
+   ILI9881C_COMMAND_INSTR(0x3f, 0x00),
+   ILI9881C_COMMAND_INSTR(0x40, 0x00),
+   ILI9881C_COMMAND_INSTR(0x41, 0x00),
+   ILI9881C_COMMAND_INSTR(0x42, 0x00),
+   ILI9881C_COMMAND_INSTR(0x43, 0x00),
+   ILI9881C_COMMAND_INSTR(0x44, 0x00),
+
+   ILI9881C_COMMAND_INSTR(0x50, 0x01),
+   ILI9881C_COMMAND_INSTR(0x51, 0x23),
+   ILI9881C_COMMAND_INSTR(0x52, 0x45),
+   ILI9881C_COMMAND_INSTR(0x53, 0x67),
+   ILI9881C_COMMAND_INSTR(0x54, 0x89),
+   ILI9881C_COMMAND_INSTR(0x55, 0xab),
+   ILI9881C_COMMAND_INSTR(0x56, 0x01),
+   ILI9881C_COMMAND_INSTR(0x57, 0x23),
+   ILI9881C_COMMAND_INSTR(0x58, 0x45),
+   ILI9881C_COMMAND_INSTR(0x59, 0x67),
+   ILI9881C_COMMAND_INSTR(0x5a, 0x89),
+   ILI9881C_COMMAND_INSTR(0x5b, 0xab),
+   ILI9881C_COMMAND_INSTR(0x5c, 0xcd),
+   ILI9881C_COMMAND_INSTR(0x5d, 0xef),
+
+   ILI9881C_COMMAND_INSTR(0x5e, 0x11),
+   ILI9881C_COMMAND_INSTR(0x5f, 0x02),
+   ILI9881C_COMMAND_INSTR(0x60, 0x00),
+   ILI9881C_COMMAND_INSTR(0x61, 0x01),
+   ILI9881C_COMMAND_INSTR(0x62, 0x0D),
+   ILI9881C_COMMAND_INSTR(0x63, 0x0C),
+   ILI9881C_COMMAND_INSTR(0x64, 0x0F),
+   ILI9881C_COMMAND_INSTR(0x65, 0x0E),
+   ILI9881C_COMMAND_INSTR(0x66, 0x06),
+   ILI9881C_COMMAND_INSTR(0x67, 0x07),
+   ILI9881C_COMMAND_INSTR(0x68, 0x02),
+   ILI9881C_COMMAND_INSTR(0x69, 0x02),
+   ILI9881C_COMMAND_INSTR(0x6a, 0x08),
+   ILI9881C_COMMAND_INSTR(0x6b, 0x02),
+   ILI9881C_COMMAND_INSTR(0x6c, 0x02),
+   I

Re: [PATCH 1/3] drm/panel: ilitek-ili9881c: make use of prepare_prev_first

[Neil Armstrong]

On 23/11/2023 18:08, Philipp Zabel wrote:

From: Marco Felsch 

The panel.prepare() call requires an initialized MIPI-DSI host, so set
the prepare_prev_first flag to indicate that the host must be
initialized first.

Signed-off-by: Marco Felsch 
Signed-off-by: Philipp Zabel 
---
  drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 7838947a1bf3..0c911ed9141b 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -1094,6 +1094,8 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return ret;
}
  
+	ctx->panel.prepare_prev_first = true;

+
ret = drm_panel_of_backlight(&ctx->panel);
if (ret)
return ret;



Reviewed-by: Neil Armstrong 

Re: [PATCH 2/2] drm/panel-simple: add Evervision VGG644804 panel entry

[Neil Armstrong]

On 23/11/2023 11:24, Michael Walle wrote:

Timings taken from the datasheet, although sometimes there are just
typical values and it's not clear if they are no min and max values or
if you must use the typical value exactly. To make things worse, there
is no back porch but only a combined sync and back porch length.

Unfortunately, there is not public datasheet. Therefore, here are the
relevant timings:
  | min |  typ   | max |
-+-++-+
CLK frequency|  -  | 25.175 |  -  |
HS period|  -  |   800  |  -  |
HS pulse width   |  5  |30  |  -  |
HS-DEN time  | 112 |   144  | 175 |
DEN pulse width  |  -  |   640  |  -  |
VS pulse width   |  1  | 3  |  5  |
VS-DEN time  |  -  |35  |  -  |
VS period|  -  |   525  |  -  |

Signed-off-by: Michael Walle 
---
  drivers/gpu/drm/panel/panel-simple.c | 30 
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 9367a4572dcf..26702a847b63 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1973,6 +1973,33 @@ static const struct panel_desc eink_vb3300_kca = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
  };
  
+static const struct display_timing evervision_vgg644804_timing = {

+   .pixelclock = { 25175000, 25175000, 25175000 },
+   .hactive = { 640, 640, 640 },
+   .hfront_porch = { 16, 16, 16 },
+   .hback_porch = { 82, 114, 170 },
+   .hsync_len = { 5, 30, 30 },
+   .vactive = { 480, 480, 480 },
+   .vfront_porch = { 10, 10, 10 },
+   .vback_porch = { 30, 32, 34 },
+   .vsync_len = { 1, 3, 5 },
+   .flags = DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW |
+DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE |
+DISPLAY_FLAGS_SYNC_POSEDGE,
+};
+
+static const struct panel_desc evervision_vgg644804 = {
+   .timings = &evervision_vgg644804_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 115,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+   .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE,
+};
+
  static const struct display_timing evervision_vgg804821_timing = {
.pixelclock = { 2760, 3330, 5000 },
.hactive = { 800, 800, 800 },
@@ -4334,6 +4361,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "eink,vb3300-kca",
.data = &eink_vb3300_kca,
+   }, {
+   .compatible = "evervision,vgg644804",
+   .data = &evervision_vgg644804,
}, {
.compatible = "evervision,vgg804821",
.data = &evervision_vgg804821,


Reviewed-by: Neil Armstrong 

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Krzysztof Kozlowski]

On 05/12/2023 09:10, Tony Lindgren wrote:
> * Krzysztof Kozlowski  [231205 08:03]:
>> What does runtime PM have to do with it? If runtime PM enables clocks,
>> these are real signals and not optional.
> 
> Runtime PM propagates to the parent device.

Then it is not really relevant to the hardware talk here, unless you put
this device clocks in parent node, but then it's just wrong hardware
description.

Best regards,
Krzysztof

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[H. Nikolaus Schaller]

Hi Andrew,

> Am 04.12.2023 um 19:22 schrieb Andrew Davis :
> 
> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
> multiple vendors.

Great and thanks for the new attempt to get at least the Device Tree side
upstream. Really appreciated!

> Describe how the SGX GPU is integrated in these SoC,
> including register space and interrupts.

> Clocks, reset, and power domain
> information is SoC specific.

Indeed. This makes it understandable why you did not directly
take our scheme from the openpvrsgx project.

> 
> Signed-off-by: Andrew Davis 
> ---
> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +--
> 1 file changed, 63 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr.yaml 
> b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> index a13298f1a1827..9f036891dad0b 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr.yaml
> @@ -11,11 +11,33 @@ maintainers:
>   - Frank Binns 
> 
> properties:
> +  $nodename:
> +pattern: '^gpu@[a-f0-9]+$'
> +
>   compatible:
> -items:
> -  - enum:
> -  - ti,am62-gpu
> -  - const: img,img-axe # IMG AXE GPU model/revision is fully discoverable
> +oneOf:
> +  - items:
> +  - enum:
> +  - ti,am62-gpu
> +  - const: img,img-axe # IMG AXE GPU model/revision is fully 
> discoverable
> +  - items:
> +  - enum:
> +  - ti,omap3430-gpu # Rev 121
> +  - ti,omap3630-gpu # Rev 125

Is the "Rev 121" and "Rev 125" a property of the SoC integration 
(clock/reset/power
hookup etc.) or of the integrated SGX core?

In my understanding the Revs are different variants of the SGX core (errata
fixes, instruction set, pipeline size etc.). And therefore the current driver 
code
has to be configured by some macros to handle such cases.

So the Rev should IMHO be part of the next line:

> +  - const: img,powervr-sgx530

+  - enum:
+  - img,powervr-sgx530-121
+  - img,powervr-sgx530-125

We have a similar definition in the openpvrsgx code.
Example: compatible = "ti,omap3-sgx530-121", "img,sgx530-121", "img,sgx530";

(I don't mind about the powervr- prefix).

This would allow a generic and universal sgx driver (loaded through just 
matching
"img,sgx530") to handle the errata and revision specifics at runtime based on 
the
compatible entry ("img,sgx530-121") and know about SoC integration 
("ti,omap3-sgx530-121").

And user-space can be made to load the right firmware variant based on 
"img,sgx530-121"

I don't know if there is some register which allows to discover the revision 
long
before the SGX subsystem is initialized and the firmware is up and running.

What I know is that it is possible to read out the revision after starting the 
firmware
but it may just echo the version number of the firmware binary provided from 
user-space.

> +  - items:
> +  - enum:
> +  - ingenic,jz4780-gpu # Rev 130
> +  - ti,omap4430-gpu # Rev 120
> +  - const: img,powervr-sgx540
> +  - items:
> +  - enum:
> +  - allwinner,sun6i-a31-gpu # MP2 Rev 115
> +  - ti,omap4470-gpu # MP1 Rev 112
> +  - ti,omap5432-gpu # MP2 Rev 105
> +  - ti,am5728-gpu # MP2 Rev 116
> +  - ti,am6548-gpu # MP1 Rev 117
> +  - const: img,powervr-sgx544
> 
>   reg:
> maxItems: 1
> @@ -40,8 +62,6 @@ properties:
> required:
>   - compatible
>   - reg
> -  - clocks
> -  - clock-names
>   - interrupts
> 
> additionalProperties: false
> @@ -56,6 +76,43 @@ allOf:
>   properties:
> clocks:
>   maxItems: 1
> +  required:
> +- clocks
> +- clock-names
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: ti,am654-sgx544
> +then:
> +  properties:
> +power-domains:
> +  minItems: 1
> +  required:
> +- power-domains
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: allwinner,sun6i-a31-gpu
> +then:
> +  properties:
> +clocks:
> +  minItems: 2
> +clock-names:
> +  minItems: 2
> +  required:
> +- clocks
> +- clock-names
> +  - if:
> +  properties:
> +compatible:
> +  contains:
> +const: ingenic,jz4780-gpu
> +then:
> +  required:
> +- clocks
> +- clock-names
> 
> examples:
>   - |
> -- 
> 2.39.2
> 

BR and thanks,
Nikolaus

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[H. Nikolaus Schaller]

> Am 05.12.2023 um 07:57 schrieb Maxime Ripard :
> 
> On Mon, Dec 04, 2023 at 12:22:36PM -0600, Andrew Davis wrote:
>> The Imagination PowerVR Series5 "SGX" GPU is part of several SoCs from
>> multiple vendors. Describe how the SGX GPU is integrated in these SoC,
>> including register space and interrupts. Clocks, reset, and power domain
>> information is SoC specific.
>> 
>> Signed-off-by: Andrew Davis 
>> ---
>> .../devicetree/bindings/gpu/img,powervr.yaml  | 69 +--
>> 1 file changed, 63 insertions(+), 6 deletions(-)
> 
> I think it would be best to have a separate file for this, img,sgx.yaml
> maybe?

Why?

The whole family of IMG GPUs is PowerVR and SGX and Rogue are generations 5 and 
6++:

https://en.wikipedia.org/wiki/PowerVR

So I would suggest to keep either img,powervr.yaml for all of them or

img,powervr-sgx.yaml
img,powervr-rogue.yaml

etc.

But as far as I can see the hardware integration into SoC (and hence 
description)
is quite similar so a single file should suffice.

BR,
Nikolaus

Re: [PATCH 1/2] dt-bindings: display: simple: Add boe,bp101wx1-100 panel

[Neil Armstrong]

Hi,

On Mon, 27 Nov 2023 07:15:43 +0200, Tony Lindgren wrote:
> This panel is found on Motorola mapphone tablets mz615 to mz617.
> 
> 

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[1/2] dt-bindings: display: simple: Add boe,bp101wx1-100 panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=4777dded21717c31d2d8471bccaf7c0ff58feaa4
[2/2] drm/panel: simple: Add BOE BP101WX1-100 panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=eeaddab4c14beb02157db5ca8f9e074066759bfd

-- 
Neil

Re: [PATCH V2 00/10] rockchip: Add Powkiddy X55

[Neil Armstrong]

Hi,

On Mon, 04 Dec 2023 12:57:09 -0600, Chris Morgan wrote:
> From: Chris Morgan 
> 
> Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming
> console.
> 
> Changes since V1:
>  - Corrected a bug with the DRM mode flags for the video driver.
>  - Adjusted panel front and back porch and pixel clock to fix
>issues with display that occurred after correcting DRM mode
>flag bug.
>  - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz.
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[01/10] drm/panel: himax-hx8394: Drop prepare/unprepare tracking

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8c2c5d1d33f0725b7995f44f87a81311d13a441d
[02/10] drm/panel: himax-hx8394: Drop shutdown logic

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e4f53a4d921eba6187a2599cf184a3beeb604fe2
[03/10] dt-bindings: display: Document Himax HX8394 panel rotation

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=be478bc7ab08127473ce9ed893378cc2a8762611
[04/10] drm/panel: himax-hx8394: Add Panel Rotation Support

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a695a5009c8fd239a98d98209489997ff5397d2b
[05/10] dt-bindings: display: himax-hx8394: Add Powkiddy X55 panel

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=00830a0d8f0d820335e7beb26e251069d90f2574
[06/10] drm/panel: himax-hx8394: Add Support for Powkiddy X55 panel

https://cgit.freedesktop.org/drm/drm-misc/commit/?id=38db985966d2f0f89f7e1891253489a16936fc5e
[07/10] clk: rockchip: Mark pclk_usb as critical on rk3568
(no commit info)
[08/10] clk: rockchip: rk3568: Add PLL rate for 126.4MHz
(no commit info)
[09/10] dt-bindings: arm: rockchip: Add Powkiddy X55
(no commit info)
[10/10] arm64: dts: rockchip: Add Powkiddy X55
(no commit info)

-- 
Neil

Re: [PATCH 1/2] dt-bindings: display: simple: add Evervision VGG644804 panel

[Neil Armstrong]

Hi,

On Thu, 23 Nov 2023 11:24:03 +0100, Michael Walle wrote:
> Add Evervision VGG644804 5.7" 640x480 LVDS panel compatible string.
> 
> 

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[1/2] dt-bindings: display: simple: add Evervision VGG644804 panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2a5244a04e751c8617d5e7707550d97a83b1102d
[2/2] drm/panel-simple: add Evervision VGG644804 panel entry
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=1319f2178bdf1898a76ea8c4f00d57b240bbc5fd

-- 
Neil

Re: [PATCH 0/3] drm/panel: ilitek-ili9881c: Support Ampire AM8001280G LCD panel

[Neil Armstrong]

Hi,

On Thu, 23 Nov 2023 18:08:04 +0100, Philipp Zabel wrote:
> Add support for Ampire AM8001280G LCD panels to the Ilitek ILI9881C
> driver.
> 
> Also set prepare_prev_first, to make sure that the DSI host controller
> is initialized to LP-11 before the panel is powered up. Tested to work
> with samsung-dsim on i.MX8MM after commit 0c14d3130654 ("drm: bridge:
> samsung-dsim: Fix i.MX8M enable flow to meet spec").
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[1/3] drm/panel: ilitek-ili9881c: make use of prepare_prev_first
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=68c193c8d4a403222ce51c8b08bd1715f8b74274
[2/3] dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=7ff02f82c3e9ddd5dd81957c8659d350261196ae
[3/3] drm/panel: ilitek-ili9881c: Add Ampire AM8001280G LCD panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=2748848ceaf32671927c3b19672ba3104a1dba7e

-- 
Neil

Re: [PATCH V2 00/10] rockchip: Add Powkiddy X55

[Neil Armstrong]

On 05/12/2023 09:26, Neil Armstrong wrote:

Hi,

On Mon, 04 Dec 2023 12:57:09 -0600, Chris Morgan wrote:

From: Chris Morgan 

Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming
console.

Changes since V1:
  - Corrected a bug with the DRM mode flags for the video driver.
  - Adjusted panel front and back porch and pixel clock to fix
issues with display that occurred after correcting DRM mode
flag bug.
  - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz.

[...]


Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-next)

[01/10] drm/panel: himax-hx8394: Drop prepare/unprepare tracking
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8c2c5d1d33f0725b7995f44f87a81311d13a441d
[02/10] drm/panel: himax-hx8394: Drop shutdown logic
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e4f53a4d921eba6187a2599cf184a3beeb604fe2
[03/10] dt-bindings: display: Document Himax HX8394 panel rotation
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=be478bc7ab08127473ce9ed893378cc2a8762611
[04/10] drm/panel: himax-hx8394: Add Panel Rotation Support
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a695a5009c8fd239a98d98209489997ff5397d2b
[05/10] dt-bindings: display: himax-hx8394: Add Powkiddy X55 panel
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=00830a0d8f0d820335e7beb26e251069d90f2574
[06/10] drm/panel: himax-hx8394: Add Support for Powkiddy X55 panel
 
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=38db985966d2f0f89f7e1891253489a16936fc5e
[07/10] clk: rockchip: Mark pclk_usb as critical on rk3568
 (no commit info)
[08/10] clk: rockchip: rk3568: Add PLL rate for 126.4MHz
 (no commit info)
[09/10] dt-bindings: arm: rockchip: Add Powkiddy X55
 (no commit info)
[10/10] arm64: dts: rockchip: Add Powkiddy X55
 (no commit info)



To clarify, only patches 1 to 6 were applied to drm-misc-next,

Thanks,
Neil

Re: [PATCH] drm/bridge: nxp-ptn3460: fix i2c_master_send() error checking

[Neil Armstrong]

On 04/12/2023 17:59, Dan Carpenter wrote:

On Mon, Dec 04, 2023 at 02:53:05PM +0100, Neil Armstrong wrote:

On 04/12/2023 13:29, Dan Carpenter wrote:

The i2c_master_send/recv() functions return negative error codes or the
number of bytes that were able to be sent/received.  This code has
two problems.  1)  Instead of checking if all the bytes were sent or
received, it checks that at least one byte was sent or received.
2) If there was a partial send/receive then we should return a negative
error code but this code returns success.

Fixes: a9fe713d7d45 ("drm/bridge: Add PTN3460 bridge driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Dan Carpenter 
---
This is from static analysis and code review.  It's always a concern
when you add stricter error handling that something will break.

   drivers/gpu/drm/bridge/nxp-ptn3460.c | 10 +-
   1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/nxp-ptn3460.c 
b/drivers/gpu/drm/bridge/nxp-ptn3460.c
index d81920227a8a..9b7eb8c669c1 100644
--- a/drivers/gpu/drm/bridge/nxp-ptn3460.c
+++ b/drivers/gpu/drm/bridge/nxp-ptn3460.c
@@ -56,13 +56,13 @@ static int ptn3460_read_bytes(struct ptn3460_bridge 
*ptn_bridge, char addr,
ret = i2c_master_send(ptn_bridge->client, &addr, 1);
if (ret <= 0) {
DRM_ERROR("Failed to send i2c command, ret=%d\n", ret);
-   return ret;
+   return ret ?: -EIO;
}
ret = i2c_master_recv(ptn_bridge->client, buf, len);
-   if (ret <= 0) {
+   if (ret != len) {


This is impossible, i2c_transfer_buffer_flags() returns len as-is if no error, 
so
ret can only be negative or equal to len. The original code is right.


It works, but it's not "right".  The <= 0 could be changed to < 0.  The
"len" variable is EDID_LENGTH (128).


So indeed, switching to < 0 is the most reasonable, no need to change the ret 
value in this case.

Neil



regards,
dan carpenter

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Tony Lindgren]

* Krzysztof Kozlowski  [231205 08:16]:
> On 05/12/2023 09:10, Tony Lindgren wrote:
> > * Krzysztof Kozlowski  [231205 08:03]:
> >> What does runtime PM have to do with it? If runtime PM enables clocks,
> >> these are real signals and not optional.
> > 
> > Runtime PM propagates to the parent device.
> 
> Then it is not really relevant to the hardware talk here, unless you put
> this device clocks in parent node, but then it's just wrong hardware
> description.

No it's not. The interconnect target module may have one or more separate
devices with the same shared clocks. See for example the am3 usb module that
has usb controllers, phys and dma at target-module@4740 in am33xx.dtsi.

Sure the clock nodes can be there for the child IP, but they won't do
anything. And still need to be managed separately by the device driver if
added.

Regards,

Tony

Re: [PATCH] drm/bridge: tc358768: select CONFIG_VIDEOMODE_HELPERS

[Neil Armstrong]

Hi,

On Mon, 04 Dec 2023 08:27:36 +0100, Arnd Bergmann wrote:
> A dependency on this feature was recently introduced:
> 
> x86_64-linux-ld: vmlinux.o: in function `tc358768_bridge_pre_enable':
> tc358768.c:(.text+0xbe3dae): undefined reference to 
> `drm_display_mode_to_videomode'
> 
> Make sure this is always enabled.
> 
> [...]

Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
(drm-misc-fixes)

[1/1] drm/bridge: tc358768: select CONFIG_VIDEOMODE_HELPERS
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=26513300978f7285c3e776c144f27ef71be61f57

-- 
Neil

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Tvrtko Ursulin]

On 01/12/2023 15:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.


No complaints per se but I don't see the caller deciding and it is not 
really reducing log level but converting to trace. So commit message and 
patch do not align for me which I think should be improved.


Regards,

Tvrtko


Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)
ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
   700, 0, NULL);
if (ret)
-   gt_err(engine->gt,
-  "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
-  engine->name, request,
-  intel_uncore_read_fw(uncore, reg));
+   GT_TRACE(engine->gt,
+"%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
+engine->name, request,
+intel_uncore_read_fw(uncore, reg));
  
  	return ret;

  }

Re: [PATCH] drm/doc: Define KMS atomic state set

[Pekka Paalanen]

On Mon, 4 Dec 2023 10:21:03 +0100
Maxime Ripard  wrote:

> Hi
> 
> On Fri, Dec 01, 2023 at 06:03:48PM +0200, Pekka Paalanen wrote:
> > On Fri, 1 Dec 2023 14:20:55 +0100
> > Maxime Ripard  wrote:
> >   
> > > On Fri, Dec 01, 2023 at 12:06:48PM +0200, Pekka Paalanen wrote:  

...

> > Is it really "global" too? Or is it device-wide? Or is it just the bits
> > that userspace bothered to mention in an atomic commit?  
> 
> As far as I'm concerned, global == "device-wide", so I'm not entirely
> sure what is the distinction you want to raise here, so I might be off.
> 
> But to answer the latter part of your question, drm_atomic_state
> contains the changes of all the objects affected by the commit userspace
> mentioned to bother. Which is is why I found the "global" to be
> confusing, because it's not a device-wide-global state, it's a
> commit-global state.

I think the word "global" should be simply avoided. Nothing here is
truly global (machine wide? kernel instance wide? worldwide like
UUID?), and its meaning varies by speaker and context.


Thanks,
pq


pgpeQJhKrPGOR.pgp
Description: OpenPGP digital signature

Re: Kunit drm_test_check_plane_state: EXPECTATION FAILED at drivers/gpu/drm/tests/drm_plane_helper_test.c:123

[Maxime Ripard]

Hi Naresh,

Thanks for the report

On Mon, Dec 04, 2023 at 11:05:36PM +0530, Naresh Kamboju wrote:
> The Kunit drm_plane_helper failed on all devices running Linux next-20231204
> 
> ## Test Regressions (compared to next-20231201)
> * qemu-armv7, kunit and
> * x86, kunit
>   - drm_test_check_invalid_plane_state_downscaling_invalid
>   - drm_test_check_invalid_plane_state_drm_plane_helper
>   - drm_test_check_invalid_plane_state_drm_test_check_invalid_plane_state
>   - drm_test_check_invalid_plane_state_positioning_invalid
>   - drm_test_check_invalid_plane_state_upscaling_invalid
>   - drm_test_check_plane_state_clipping_rotate_reflect
>   - drm_test_check_plane_state_clipping_simple
>   - drm_test_check_plane_state_downscaling
>   - drm_test_check_plane_state_drm_test_check_plane_state
>   - drm_test_check_plane_state_positioning_simple
>   - drm_test_check_plane_state_rounding1
>   - drm_test_check_plane_state_rounding2
>   - drm_test_check_plane_state_rounding3
>   - drm_test_check_plane_state_rounding4
>   - drm_test_check_plane_state_upscaling

I found the source of failure to be f1e75da5364e ("drm/atomic: Loosen FB
atomic checks").

Fortunately for us, it's already been reverted yesterday for some
unrelated reason, so it should be fixed in next-20231205 onward.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH RFC v7 07/10] drm/atomic: Loosen FB atomic checks

[Maxime Ripard]

Hi,

On Fri, Oct 27, 2023 at 03:32:57PM -0700, Jessica Zhang wrote:
> Loosen the requirements for atomic and legacy commit so that, in cases
> where pixel_source != FB, the commit can still go through.
> 
> This includes adding framebuffer NULL checks in other areas to account for
> FB being NULL when non-FB pixel sources are enabled.
> 
> To disable a plane, the pixel_source must be NONE or the FB must be NULL
> if pixel_source == FB.
> 
> Signed-off-by: Jessica Zhang 

This breaks some plane kunit tests we have:

See 
https://lore.kernel.org/dri-devel/20231204173536.51003-1-naresh.kamb...@linaro.org/

Maxime


signature.asc
Description: PGP signature

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Krzysztof Kozlowski]

On 05/12/2023 09:30, Tony Lindgren wrote:
> * Krzysztof Kozlowski  [231205 08:16]:
>> On 05/12/2023 09:10, Tony Lindgren wrote:
>>> * Krzysztof Kozlowski  [231205 08:03]:
 What does runtime PM have to do with it? If runtime PM enables clocks,
 these are real signals and not optional.
>>>
>>> Runtime PM propagates to the parent device.
>>
>> Then it is not really relevant to the hardware talk here, unless you put
>> this device clocks in parent node, but then it's just wrong hardware
>> description.
> 
> No it's not. The interconnect target module may have one or more separate

Interconnects are not parents of devices, so I still don't get why do
you bring it here.

> devices with the same shared clocks. See for example the am3 usb module that
> has usb controllers, phys and dma at target-module@4740 in am33xx.dtsi.

There is no interconnect-cells there, so why do we talk about
interconnect here?

> 
> Sure the clock nodes can be there for the child IP, but they won't do
> anything. And still need to be managed separately by the device driver if
> added.

So if OS does not have runtime PM, the bindings are wrong? Bindings
should not depend on some particular feature of some particular OS.

Best regards,
Krzysztof

Re: [PATCH v3 13/14] dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs

[Boris Brezillon]

On Mon, 04 Dec 2023 13:29:17 -0600
Rob Herring  wrote:

> On Mon, 04 Dec 2023 18:33:06 +0100, Boris Brezillon wrote:
> > From: Liviu Dudau 
> > 
> > Arm has introduced a new v10 GPU architecture that replaces the Job Manager
> > interface with a new Command Stream Frontend. It adds firmware driven
> > command stream queues that can be used by kernel and user space to submit
> > jobs to the GPU.
> > 
> > Add the initial schema for the device tree that is based on support for
> > RK3588 SoC. The minimum number of clocks is one for the IP, but on Rockchip
> > platforms they will tend to expose the semi-independent clocks for better
> > power management.
> > 
> > v3:
> > - Cleanup commit message to remove redundant text
> > - Added opp-table property and re-ordered entries
> > - Clarified power-domains and power-domain-names requirements for RK3588.
> > - Cleaned up example
> > 
> > Note: power-domains and power-domain-names requirements for other platforms
> > are still work in progress, hence the bindings are left incomplete here.
> > 
> > v2:
> > - New commit
> > 
> > Signed-off-by: Liviu Dudau 
> > Cc: Krzysztof Kozlowski 
> > Cc: Rob Herring 
> > Cc: Conor Dooley 
> > Cc: devicet...@vger.kernel.org
> > ---
> >  .../bindings/gpu/arm,mali-valhall-csf.yaml| 147 ++
> >  1 file changed, 147 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> >   
> 
> My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
> on your patch (DT_CHECKER_FLAGS is new in v5.13):
> 
> yamllint warnings/errors:
> ./Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml:108:1: 
> [error] syntax error: found character '\t' that cannot start any token 
> (syntax)
> 
> dtschema/dtc warnings/errors:
> make[2]: *** Deleting file 
> 'Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.example.dts'
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml:108:1: found 
> a tab character that violates indentation
> make[2]: *** [Documentation/devicetree/bindings/Makefile:26: 
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.example.dts] Error 
> 1
> make[2]: *** Waiting for unfinished jobs
> ./Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml:108:1: 
> found a tab character that violates indentation
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml:
>  ignoring, error parsing file
> make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1424: 
> dt_binding_check] Error 2
> make: *** [Makefile:234: __sub-make] Error 2

Uh, sorry. I messed up when applying Liviu's changes. Will fix that in v4.

> 
> doc reference errors (make refcheckdocs):
> 
> See 
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20231204173313.2098733-14-boris.brezil...@collabora.com
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
> 

Re: [PATCH v3 00/14] drm: Add a driver for CSF-based Mali GPUs

[Boris Brezillon]

Hi Steve,

I forgot to mention that I intentionally dropped your R-b, because
there was a gazillion of changes all over the place, and I thought it
deserved a fresh review.

Regards,

Boris

On Mon,  4 Dec 2023 18:32:53 +0100
Boris Brezillon  wrote:

> Hello,
> 
> This is the 3rd version of the kernel driver for Mali CSF-based GPUs.
> 
> With all the DRM dependencies being merged (drm-sched single entity and
> drm_gpuvm), I thought now was a good time to post a new version. Note
> that the iommu series we depend on [1] has been merged recently. The
> only remaining dependency that hasn't been merged yet is this rather
> trival drm_gpuvm [2] patch.
> 
> As for v2, I pushed a branch based on drm-misc-next and containing
> all the dependencies that are not yet available in drm-misc-next
> here[3], and another [4] containing extra patches to have things
> working on rk3588. The CSF firmware binary can be found here[5], and
> should be placed under /lib/firmware/arm/mali/arch10.8/mali_csffw.bin.
> 
> The mesa MR adding v10 support on top of panthor is available here [6].
> 
> Regarding the GPL2+MIT relicensing, Liviu did an audit and found two
> more people that I didn't spot initially: Clément Péron for the devfreq
> code, and Alexey Sheplyakov for some bits in panthor_gpu.c. Both are
> Cc-ed on the relevant patches. The rest of the code is either new, or
> covered by the Linaro, Arm and Collabora acks.
> 
> And here is a non-exhaustive changelog, check each commit for a detailed
> changelog.
> 
> v3;
> - Quite a few changes at the MMU/sched level to make the fix some
>   race conditions and deadlocks
> - Addition of the a sync-only VM_BIND operation (to support
>   vkQueueSparseBind with zero commands).
> - Addition of a VM_GET_STATE ioctl
> - Various cosmetic changes (see the commit changelogs for more details)
> - Various fixes (see the commit changelogs for more details)
> 
> v2:
> - Rename the driver (pancsf -> panthor)
> - Split the commit adding the driver to ease review
> - Use drm_sched for dependency tracking/job submission
> - Add a VM_BIND ioctl
> - Add the concept of exclusive VM for BOs that are only ever mapped to a
>   single VM
> - Document the code and uAPI
> - Add a DT binding doc
> 
> Regards,
> 
> Boris
> 
> [1]https://lore.kernel.org/linux-arm-kernel/20231124142434.1577550-1-boris.brezil...@collabora.com/T/
> [2]https://patchwork.freedesktop.org/patch/570380/
> [3]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v3
> [4]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v3+rk3588
> [5]https://gitlab.com/firefly-linux/external/libmali/-/raw/firefly/firmware/g610/mali_csffw.bin
> [6]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358
> 
> Boris Brezillon (13):
>   drm/panthor: Add uAPI
>   drm/panthor: Add GPU register definitions
>   drm/panthor: Add the device logical block
>   drm/panthor: Add the GPU logical block
>   drm/panthor: Add GEM logical block
>   drm/panthor: Add the devfreq logical block
>   drm/panthor: Add the MMU/VM logical block
>   drm/panthor: Add the FW logical block
>   drm/panthor: Add the heap logical block
>   drm/panthor: Add the scheduler logical block
>   drm/panthor: Add the driver frontend block
>   drm/panthor: Allow driver compilation
>   drm/panthor: Add an entry to MAINTAINERS



> 
> Liviu Dudau (1):
>   dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs
> 
>  .../bindings/gpu/arm,mali-valhall-csf.yaml|  147 +
>  Documentation/gpu/driver-uapi.rst |5 +
>  MAINTAINERS   |   11 +
>  drivers/gpu/drm/Kconfig   |2 +
>  drivers/gpu/drm/Makefile  |1 +
>  drivers/gpu/drm/panthor/Kconfig   |   23 +
>  drivers/gpu/drm/panthor/Makefile  |   15 +
>  drivers/gpu/drm/panthor/panthor_devfreq.c |  283 ++
>  drivers/gpu/drm/panthor/panthor_devfreq.h |   25 +
>  drivers/gpu/drm/panthor/panthor_device.c  |  497 +++
>  drivers/gpu/drm/panthor/panthor_device.h  |  381 ++
>  drivers/gpu/drm/panthor/panthor_drv.c | 1454 +++
>  drivers/gpu/drm/panthor/panthor_fw.c  | 1332 +++
>  drivers/gpu/drm/panthor/panthor_fw.h  |  504 +++
>  drivers/gpu/drm/panthor/panthor_gem.c |  227 ++
>  drivers/gpu/drm/panthor/panthor_gem.h |  144 +
>  drivers/gpu/drm/panthor/panthor_gpu.c |  481 +++
>  drivers/gpu/drm/panthor/panthor_gpu.h |   52 +
>  drivers/gpu/drm/panthor/panthor_heap.c|  517 +++
>  drivers/gpu/drm/panthor/panthor_heap.h|   36 +
>  drivers/gpu/drm/panthor/panthor_mmu.c | 2653 +
>  drivers/gpu/drm/panthor/panthor_mmu.h |  101 +
>  drivers/gpu/drm/panthor/panthor_regs.h|  237 ++
>  drivers/gpu/drm/panthor/panthor_sched.c   | 3410 +
>  drivers/gpu/drm/panthor/panthor_sched.h   |   48 +
>  include/uapi/drm/panthor_drm.h|  892 +
>  26 files 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Nirmoy Das]

Hi Tvrtko,

On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:


On 01/12/2023 15:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.


No complaints per se but I don't see the caller deciding and it is not 
really reducing log level but converting to trace. So commit message 
and patch do not align for me which I think should be improved.



I meant the return value is checked by the caller, gen8_reset_engines(). 
I will resend with a improved commit message.


Thanks,

Nirmoy



Regards,

Tvrtko


Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

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

index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)

  ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
 700, 0, NULL);
  if (ret)
-    gt_err(engine->gt,
-   "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

-   engine->name, request,
-   intel_uncore_read_fw(uncore, reg));
+    GT_TRACE(engine->gt,
+ "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",

+ engine->name, request,
+ intel_uncore_read_fw(uncore, reg));
    return ret;
  }

Re: [PATCH 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous

[Pekka Paalanen]

On Mon,  4 Dec 2023 13:17:06 +0100
Maxime Ripard  wrote:

> The current documentation of drm_atomic_state says that it's the "global
> state object". This is confusing since, while it does contain all the
> objects affected by an update and their respective states, if an object
> isn't affected by this update it won't be part of it.
> 
> Thus, it's not truly a "global state", unlike object state structures
> that do contain the entire state of a given object.
> 
> Signed-off-by: Maxime Ripard 
> ---
>  include/drm/drm_atomic.h | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 914574b58ae7..81ad7369b90d 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -346,11 +346,19 @@ struct __drm_private_objs_state {
>  };
>  
>  /**
> - * struct drm_atomic_state - the global state object for atomic updates
> + * struct drm_atomic_state - Atomic Update structure
> + *
> + * This structure is the kernel counterpart of @drm_mode_atomic and contains
> + * all the objects affected by an atomic modeset update and their states.

Drop "modeset"? An update can be without a modeset.

>   *
>   * States are added to an atomic update by calling 
> drm_atomic_get_crtc_state(),
>   * drm_atomic_get_plane_state(), drm_atomic_get_connector_state(), or for
>   * private state structures, drm_atomic_get_private_obj_state().
> + *
> + * NOTE: While this structure looks to be global and affecting the whole DRM
> + * device, it only contains the objects affected by the atomic commit.

This new phrasing is much more clear to me than the old one.

> + * Unaffected objects will not be part of that update, unless they have been
> + * explicitly added by either the framework or the driver.

If the framework or a driver adds an object, then it's no longer
unaffected, is it?

Should there be some discussion how this struct starts with only what
userspace mentioned, and more affected objects may be added by the
framework or a driver? And adding more objects can surprise the
userspace and cause even failures (e.g. random, hard-to-diagnose EBUSY
errors from atomic commit when a driver added a CRTC that was not
supposed to be affected)? Even unexpected failures on *future* atomic
commits, as in the CRTC example.

Was there actually a rule of when the kernel can add unmentioned
objects, like needing ALLOW_MODESET from userspace?

It's fine to leave those details for later if you want.

>   */
>  struct drm_atomic_state {
>   /**


Thanks,
pq


pgpFYIUrKm7m5.pgp
Description: OpenPGP digital signature

[PATCH] drm/tests: Switch to kunit devices

[Maxime Ripard]

Kunit recently gained helpers to create test managed devices. This means
that we no longer have to roll our own helpers in KMS and we can reuse
them.

Signed-off-by: Maxime Ripard 

---

David, feel free to integrate that patch into your series and merge it
whenever and wherever you see fit.
---
 drivers/gpu/drm/tests/drm_kunit_helpers.c | 66 ++-
 1 file changed, 3 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/tests/drm_kunit_helpers.c 
b/drivers/gpu/drm/tests/drm_kunit_helpers.c
index c251e6b34de0..ca4f8e4c5d5d 100644
--- a/drivers/gpu/drm/tests/drm_kunit_helpers.c
+++ b/drivers/gpu/drm/tests/drm_kunit_helpers.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #include 
@@ -15,28 +16,6 @@
 static const struct drm_mode_config_funcs drm_mode_config_funcs = {
 };
 
-static int fake_probe(struct platform_device *pdev)
-{
-   return 0;
-}
-
-static struct platform_driver fake_platform_driver = {
-   .probe  = fake_probe,
-   .driver = {
-   .name   = KUNIT_DEVICE_NAME,
-   },
-};
-
-KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_platform_driver_unregister,
-   platform_driver_unregister,
-   struct platform_driver *);
-KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_platform_device_put,
-   platform_device_put,
-   struct platform_device *);
-KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_platform_device_del,
-   platform_device_del,
-   struct platform_device *);
-
 /**
  * drm_kunit_helper_alloc_device - Allocate a mock device for a KUnit test
  * @test: The test context object
@@ -54,34 +33,7 @@ KUNIT_DEFINE_ACTION_WRAPPER(kunit_action_platform_device_del,
  */
 struct device *drm_kunit_helper_alloc_device(struct kunit *test)
 {
-   struct platform_device *pdev;
-   int ret;
-
-   ret = platform_driver_register(&fake_platform_driver);
-   KUNIT_ASSERT_EQ(test, ret, 0);
-
-   ret = kunit_add_action_or_reset(test,
-   kunit_action_platform_driver_unregister,
-   &fake_platform_driver);
-   KUNIT_ASSERT_EQ(test, ret, 0);
-
-   pdev = platform_device_alloc(KUNIT_DEVICE_NAME, PLATFORM_DEVID_NONE);
-   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, pdev);
-
-   ret = kunit_add_action_or_reset(test,
-   kunit_action_platform_device_put,
-   pdev);
-   KUNIT_ASSERT_EQ(test, ret, 0);
-
-   ret = platform_device_add(pdev);
-   KUNIT_ASSERT_EQ(test, ret, 0);
-
-   ret = kunit_add_action_or_reset(test,
-   kunit_action_platform_device_del,
-   pdev);
-   KUNIT_ASSERT_EQ(test, ret, 0);
-
-   return &pdev->dev;
+   return kunit_device_register(test, KUNIT_DEVICE_NAME);
 }
 EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
 
@@ -94,19 +46,7 @@ EXPORT_SYMBOL_GPL(drm_kunit_helper_alloc_device);
  */
 void drm_kunit_helper_free_device(struct kunit *test, struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-
-   kunit_release_action(test,
-kunit_action_platform_device_del,
-pdev);
-
-   kunit_release_action(test,
-kunit_action_platform_device_put,
-pdev);
-
-   kunit_release_action(test,
-kunit_action_platform_driver_unregister,
-&fake_platform_driver);
+   kunit_device_unregister(test, dev);
 }
 EXPORT_SYMBOL_GPL(drm_kunit_helper_free_device);
 
-- 
2.43.0

Re: Kunit drm_test_check_plane_state: EXPECTATION FAILED at drivers/gpu/drm/tests/drm_plane_helper_test.c:123

[Dan Carpenter]

On Tue, Dec 05, 2023 at 09:37:05AM +0100, Maxime Ripard wrote:
> Hi Naresh,
> 
> Thanks for the report
> 
> On Mon, Dec 04, 2023 at 11:05:36PM +0530, Naresh Kamboju wrote:
> > The Kunit drm_plane_helper failed on all devices running Linux next-20231204
> > 
> > ## Test Regressions (compared to next-20231201)
> > * qemu-armv7, kunit and
> > * x86, kunit
> >   - drm_test_check_invalid_plane_state_downscaling_invalid
> >   - drm_test_check_invalid_plane_state_drm_plane_helper
> >   - drm_test_check_invalid_plane_state_drm_test_check_invalid_plane_state
> >   - drm_test_check_invalid_plane_state_positioning_invalid
> >   - drm_test_check_invalid_plane_state_upscaling_invalid
> >   - drm_test_check_plane_state_clipping_rotate_reflect
> >   - drm_test_check_plane_state_clipping_simple
> >   - drm_test_check_plane_state_downscaling
> >   - drm_test_check_plane_state_drm_test_check_plane_state
> >   - drm_test_check_plane_state_positioning_simple
> >   - drm_test_check_plane_state_rounding1
> >   - drm_test_check_plane_state_rounding2
> >   - drm_test_check_plane_state_rounding3
> >   - drm_test_check_plane_state_rounding4
> >   - drm_test_check_plane_state_upscaling
> 
> I found the source of failure to be f1e75da5364e ("drm/atomic: Loosen FB
> atomic checks").
> 
> Fortunately for us, it's already been reverted yesterday for some
> unrelated reason, so it should be fixed in next-20231205 onward.

Sorry, that's a bummer that these patches were reverted.  :(  The whole
episode was a bit unfortunate...

Qualcom has been working on those patches for a year.  They must not be
using kunit testing as part of their QC...  It's some kind of
communication failure on our part.

Hopefully we can get this all sorted out and re-apply the patches soon.

regards,
dan carpenter

[PATCH v2] drm/i915/gt: Convert reset prepare failure log to trace

[Nirmoy Das]

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Convert the log to a trace log for debugging without triggering
unnecessary concerns in CI or for end-users during non-fatal scenarios.

v2: Improve commit message(Tvrtko)

Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_reset.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)
ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
   700, 0, NULL);
if (ret)
-   gt_err(engine->gt,
-  "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
-  engine->name, request,
-  intel_uncore_read_fw(uncore, reg));
+   GT_TRACE(engine->gt,
+"%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",
+engine->name, request,
+intel_uncore_read_fw(uncore, reg));
 
return ret;
 }
-- 
2.42.0

Re: [PATCH v2] drm/i915/gt: Convert reset prepare failure log to trace

[John Harrison]

On 12/5/2023 00:52, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Convert the log to a trace log for debugging without triggering
unnecessary concerns in CI or for end-users during non-fatal scenarios.
I strongly disagree with this change. The hardware spec for the 
RESET_CTL and GDRST registers are that they will self clear within a 
matter of microseconds. If something is so badly wrong with the hardware 
that it can't even manage to reset then that is something that very much 
warrants more than a completely silent trace event. It most certainly 
should be flagged as a failure in CI.


Just because the driver will retry does not mean that this is not a 
serious error. And if the first attempt failed, why would a subsequent 
attempt succeed? Escalating to FLR may have more success, but that is 
not something that i915 currently does.


John.




v2: Improve commit message(Tvrtko)

Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c 
b/drivers/gpu/drm/i915/gt/intel_reset.c
index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)
ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
   700, 0, NULL);
if (ret)
-   gt_err(engine->gt,
-  "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
-  engine->name, request,
-  intel_uncore_read_fw(uncore, reg));
+   GT_TRACE(engine->gt,
+"%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",
+engine->name, request,
+intel_uncore_read_fw(uncore, reg));
  
  	return ret;

  }

Re: [PATCH 4/5] drm/atomic: Make the drm_atomic_state documentation less ambiguous

[Pekka Paalanen]

On Tue, 5 Dec 2023 10:51:06 +0200
Pekka Paalanen  wrote:

> On Mon,  4 Dec 2023 13:17:06 +0100
> Maxime Ripard  wrote:
> 
> > The current documentation of drm_atomic_state says that it's the "global
> > state object". This is confusing since, while it does contain all the
> > objects affected by an update and their respective states, if an object
> > isn't affected by this update it won't be part of it.
> > 
> > Thus, it's not truly a "global state", unlike object state structures
> > that do contain the entire state of a given object.
> > 
> > Signed-off-by: Maxime Ripard 

Hi Maxime,

could you figure out how your email got the linux.ie address for Dave
Airlie?

I got a bounce from skynet.ie when replying to all. Maybe there is a
leftover email address for Dave still somewhere?


Thanks,
pq


pgpGC8eRN_2is.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 12/14] drm/rockchip: vop2: Add debugfs support

[Sascha Hauer]

On Thu, Nov 30, 2023 at 08:24:49PM +0800, Andy Yan wrote:
> From: Andy Yan 
> 
> /sys/kernel/debug/dri/vop2/summary:  dump vop display state
> /sys/kernel/debug/dri/vop2/regs: dump whole vop registers
> /sys/kernel/debug/dri/vop2/active_regs: only dump the registers of
> activated modules
> 
> Signed-off-by: Andy Yan 
> 
> ---
> 
> Changes in v3:
> - put regs dump info in vop2_data
> 
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 268 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop2.h |  11 +
>  drivers/gpu/drm/rockchip/rockchip_vop2_reg.c | 191 +
>  3 files changed, 470 insertions(+)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index 6f17cc56501e..56a165c0b130 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -187,6 +188,7 @@ struct vop2 {
>*/
>   u32 registered_num_wins;
>  
> + struct resource *res;
>   void __iomem *regs;
>   struct regmap *map;
>  
> @@ -238,6 +240,37 @@ struct vop2 {
>  
>  #define vop2_output_if_is_dpi(x) ((x) == ROCKCHIP_VOP2_EP_RGB0)
>  
> +
> +/*
> + * bus-format types.
> + */
> +struct drm_bus_format_enum_list {
> + int type;
> + const char *name;
> +};
> +
> +static const struct drm_bus_format_enum_list drm_bus_format_enum_list[] = {
> + { DRM_MODE_CONNECTOR_Unknown, "Unknown" },
> + { MEDIA_BUS_FMT_RGB565_1X16, "RGB565_1X16" },
> + { MEDIA_BUS_FMT_RGB666_1X18, "RGB666_1X18" },
> + { MEDIA_BUS_FMT_RGB666_1X24_CPADHI, "RGB666_1X24_CPADHI" },
> + { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, "RGB666_1X7X3_SPWG" },
> + { MEDIA_BUS_FMT_YUV8_1X24, "YUV8_1X24" },
> + { MEDIA_BUS_FMT_UYYVYY8_0_5X24, "UYYVYY8_0_5X24" },
> + { MEDIA_BUS_FMT_YUV10_1X30, "YUV10_1X30" },
> + { MEDIA_BUS_FMT_UYYVYY10_0_5X30, "UYYVYY10_0_5X30" },
> + { MEDIA_BUS_FMT_RGB888_3X8, "RGB888_3X8" },
> + { MEDIA_BUS_FMT_RGB888_1X24, "RGB888_1X24" },
> + { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, "RGB888_1X7X4_SPWG" },
> + { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, "RGB888_1X7X4_JEIDA" },
> + { MEDIA_BUS_FMT_UYVY8_2X8, "UYVY8_2X8" },
> + { MEDIA_BUS_FMT_YUYV8_1X16, "YUYV8_1X16" },
> + { MEDIA_BUS_FMT_UYVY8_1X16, "UYVY8_1X16" },
> + { MEDIA_BUS_FMT_RGB101010_1X30, "RGB101010_1X30" },
> + { MEDIA_BUS_FMT_YUYV10_1X20, "YUYV10_1X20" },
> +};
> +static DRM_ENUM_NAME_FN(drm_get_bus_format_name, drm_bus_format_enum_list)
> +
>  static const struct regmap_config vop2_regmap_config;
>  
>  static struct vop2_video_port *to_vop2_video_port(struct drm_crtc *crtc)
> @@ -2522,6 +2555,239 @@ static const struct drm_crtc_helper_funcs 
> vop2_crtc_helper_funcs = {
>   .atomic_disable = vop2_crtc_atomic_disable,
>  };
>  
> +static void vop2_dump_connector_on_crtc(struct drm_crtc *crtc, struct 
> seq_file *s)
> +{
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector;
> +
> + drm_connector_list_iter_begin(crtc->dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (crtc->state->connector_mask & drm_connector_mask(connector))
> + seq_printf(s, "Connector: %s\n", connector->name);
> +
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +}
> +
> +static int vop2_plane_state_dump(struct seq_file *s, struct drm_plane *plane)
> +{
> + struct vop2_win *win = to_vop2_win(plane);
> + struct drm_plane_state *pstate = plane->state;
> + struct drm_rect *src, *dst;
> + struct drm_framebuffer *fb;
> + struct drm_gem_object *obj;
> + struct rockchip_gem_object *rk_obj;
> + bool xmirror;
> + bool ymirror;
> + bool rotate_270;
> + bool rotate_90;
> + dma_addr_t fb_addr;
> + int i;
> +
> + seq_printf(s, "%s: %s\n", win->data->name, pstate->crtc ? "ACTIVE" 
> : "DISABLED");
> + if (!pstate || !pstate->fb)
> + return 0;

'pstate' is dereferenced before its checked being non NULL. Either the
check is unnecessary or should be before the seq_printf() call.

> +
> + fb = pstate->fb;
> + src = &pstate->src;
> + dst = &pstate->dst;
> + xmirror = pstate->rotation & DRM_MODE_REFLECT_X ? true : false;
> + ymirror = pstate->rotation & DRM_MODE_REFLECT_Y ? true : false;
> + rotate_270 = pstate->rotation & DRM_MODE_ROTATE_270;
> + rotate_90 = pstate->rotation & DRM_MODE_ROTATE_90;
> +
> + seq_printf(s, "\twin_id: %d\n", win->win_id);
> +
> + seq_printf(s, "\tformat: %p4cc%s glb_alpha[0x%x]\n",
> +&fb->format->format,
> +drm_is_afbc(fb->modifier) ? "[AFBC]" : "",
> +pstate->alpha >> 8);
> + seq_printf(s, "\trotate: xmirror: %d ymirror: %d rotate_90: %d 
> rotate_270: %d\n",
> +xmirror, ymirror, rotate_90, rotate_270);
> + 

Re: (subset) [PATCH 00/17] dt-bindings: samsung: add specific compatibles for existing SoC

[Krzysztof Kozlowski]

On 28/11/2023 21:58, Uwe Kleine-König wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
>>
>> On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
>>> Merging
>>> ===
>>> I propose to take entire patchset through my tree (Samsung SoC), because:
> ^^^
> 
>>> 1. Next cycle two new SoCs will be coming (Google GS101 and 
>>> ExynosAutov920), so
>>>they will touch the same lines in some of the DT bindings (not all, 
>>> though).
>>>It is reasonable for me to take the bindings for the new SoCs, to have 
>>> clean
>>>`make dtbs_check` on the new DTS.
>>> 2. Having it together helps me to have clean `make dtbs_check` within my 
>>> tree
>>>on the existing DTS.
>>> 3. No drivers are affected by this change.
>>> 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
>>>follow up patchsets.
>>>
>>> [...]
>>
>> Applied, thanks!
>>
>> [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
>> commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?
> 

It was also written in the PWM patch itself (under changelog ---) and
expressed with my "applied" response when I took everything. I am
sending now another set, also touching PWM.

Best regards,
Krzysztof

amdgpu header files (was: Re: [git pull] drm for 6.7-rc1)

[Geert Uytterhoeven]

On Tue, 31 Oct 2023, Dave Airlie wrote:

This is the main drm pull request for 6.7.



Highlights:
- AMD adds some more upcoming HW platforms



Alex Deucher (24):
 drm/amdgpu: update to the latest GC 11.5 headers



Candice Li (8):
 drm/amd: Add umc v12_0_0 ip headers



Lang Yu (57):
 drm/amdgpu: add gc headers for gc 11.5.0
 drm/amdgpu: add mmhub 3.3.0 headers
 drm/amdgpu: add VPE 6.1.0 header files
 drm/amdgpu: add UMSCH 4.0 register headers



Li Ma (11):
 drm/amdgpu: add header files for MP 14.0.0
 drm/amdgpu: fix missing stuff in NBIO v7.11



Qingqing Zhuo (38):
 drm/amd/display: Add dcn35 register header files



Saleemkhan Jamadar (9):
 drm/amdgpu: add vcn 4_0_5 header files



Yang Wang (16):
 drm/amd/pm: add smu_13_0_6 mca dump support



benl (3):
 drm/amdgpu: add nbio 7.11 registers



.../amd/include/asic_reg/dcn/dcn_3_5_0_offset.h| 15255 +
.../amd/include/asic_reg/dcn/dcn_3_5_0_sh_mask.h   | 53412 +
.../drm/amd/include/asic_reg/gc/gc_11_5_0_offset.h | 1 
.../amd/include/asic_reg/gc/gc_11_5_0_sh_mask.h| 36579 
.../include/asic_reg/mmhub/mmhub_3_3_0_offset.h|  1395 +
.../include/asic_reg/mmhub/mmhub_3_3_0_sh_mask.h   |  6722 +++
.../amd/include/asic_reg/mp/mp_13_0_6_sh_mask.h|28 +
.../drm/amd/include/asic_reg/mp/mp_14_0_0_offset.h |   359 +
.../amd/include/asic_reg/mp/mp_14_0_0_sh_mask.h|   534 +
.../amd/include/asic_reg/nbio/nbio_7_11_0_offset.h |  9400 +++
.../include/asic_reg/nbio/nbio_7_11_0_sh_mask.h| 57857 +++
.../amd/include/asic_reg/umc/umc_12_0_0_offset.h   |33 +
.../amd/include/asic_reg/umc/umc_12_0_0_sh_mask.h  |95 +
.../amd/include/asic_reg/vcn/vcn_4_0_0_offset.h|   422 +
.../amd/include/asic_reg/vcn/vcn_4_0_0_sh_mask.h   |   882 +
.../amd/include/asic_reg/vcn/vcn_4_0_5_offset.h|  1797 +
.../amd/include/asic_reg/vcn/vcn_4_0_5_sh_mask.h   |  8614 +++
.../amd/include/asic_reg/vpe/vpe_6_1_0_offset.h|  1553 +
.../amd/include/asic_reg/vpe/vpe_6_1_0_sh_mask.h   |  4393 ++


These huge files can be reduced by 50%: all the *_SHIFT definitions are
redundant, as they can be derived from the corresponding *_MASK
definitions at compile-time, cfr. .

E.g.:

#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER__SHIFT0x0
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET__SHIFT  0xf
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_MASK  0x00FFL
#define AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET_MASK0x8000L

AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER__SHIFT =
__bf_shf(AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_MASK)
AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET__SHIFT =
__bf_shf(AZCONTROLLER0_CORB_READ_POINTER__CORB_READ_POINTER_RESET_MASK)

set_reg_field_value_masks() takes a shift and a mask, while it
could calculate the shift at run-time.
set_reg_field_values() takes pairs of shifts and masks, but the shifts
are not needed; lots of tables can be halved, etc...

Gr{oetje,eeting}s,

Geert

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

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

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Krzysztof Kozlowski]

On 05/12/2023 10:02, Andreas Kemnade wrote:
> On Tue, 5 Dec 2023 09:45:44 +0100
> Krzysztof Kozlowski  wrote:
> 
>>> Sure the clock nodes can be there for the child IP, but they won't do
>>> anything. And still need to be managed separately by the device driver if
>>> added.  
>>
>> So if OS does not have runtime PM, the bindings are wrong? Bindings
>> should not depend on some particular feature of some particular OS.
> 
> Any user of the devicetree sees that there is a parent and the parent needs
> to be enabled by some mechanism.
> E.g. I2c devices do not specify the clocks of the parent (the i2c master)

If you use this analogy, then compare it with an I2C device which has
these clock inputs. Such device must have clocks in the bindings.

> 
> Maybe it is just more fine-grained on omap.
> 
> look e.g. at ti/omap/omap4-l4.dtsi
> there are target-module@
> with the devices as a child and a clock in the parent.

Not related to runtime PM...

Best regards,
Krzysztof

Re: [PATCH v3 11/14] drm/rockchip: vop2: Add support for rk3588

[Sascha Hauer]

On Thu, Nov 30, 2023 at 08:24:39PM +0800, Andy Yan wrote:
> From: Andy Yan 
> 
> VOP2 on rk3588:
> 
> Four video ports:
> VP0 Max 4096x2160
> VP1 Max 4096x2160
> VP2 Max 4096x2160
> VP3 Max 2048x1080
> 
> 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> 4 4K Esmart windows with line RGB/YUV support
> 
> Signed-off-by: Andy Yan 

With the two nits below feel free to add my:

Reviewed-by: Sascha Hauer 

Thanks for working on this.

> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h 
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> index 8d7ff52523fb..8b16031eda52 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> @@ -13,9 +13,16 @@
>  
>  #define VOP_FEATURE_OUTPUT_10BITBIT(0)

You could rename this to include "VP" for Video Port so it's not so
easily mixed up with the defines below.

>  
> +#define VOP2_FEATURE_HAS_SYS_GRF BIT(0)
> +#define VOP2_FEATURE_HAS_VO0_GRF BIT(1)
> +#define VOP2_FEATURE_HAS_VO1_GRF BIT(2)
> +#define VOP2_FEATURE_HAS_VOP_GRF BIT(3)
> +#define VOP2_FEATURE_HAS_SYS_PMU BIT(5)

Should be BIT(4)

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] drm/i915/display: Use i915_gem_object_get_dma_address to get dma address

[Hogander, Jouni]

On Mon, 2023-12-04 at 14:49 +0100, Maarten Lankhorst wrote:
> Works better for xe like that. obj is no longer const.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Jouni Högander 

> ---
>  drivers/gpu/drm/i915/display/intel_cursor.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_cursor.c
> b/drivers/gpu/drm/i915/display/intel_cursor.c
> index a515ae2831f8..926e2de00eb5 100644
> --- a/drivers/gpu/drm/i915/display/intel_cursor.c
> +++ b/drivers/gpu/drm/i915/display/intel_cursor.c
> @@ -24,6 +24,8 @@
>  #include "intel_psr_regs.h"
>  #include "skl_watermark.h"
>  
> +#include "gem/i915_gem_object.h"
> +
>  /* Cursor formats */
>  static const u32 intel_cursor_formats[] = {
> DRM_FORMAT_ARGB,
> @@ -34,11 +36,11 @@ static u32 intel_cursor_base(const struct
> intel_plane_state *plane_state)
> struct drm_i915_private *dev_priv =
> to_i915(plane_state->uapi.plane->dev);
> const struct drm_framebuffer *fb = plane_state->hw.fb;
> -   const struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> +   struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> u32 base;
>  
> if (DISPLAY_INFO(dev_priv)->cursor_needs_physical)
> -   base = sg_dma_address(obj->mm.pages->sgl);
> +   base = i915_gem_object_get_dma_address(obj, 0);
> else
> base = intel_plane_ggtt_offset(plane_state);
>  

Re: [PATCH V2 00/10] rockchip: Add Powkiddy X55

[Heiko Stübner]

Am Dienstag, 5. Dezember 2023, 09:28:24 CET schrieb Neil Armstrong:
> On 05/12/2023 09:26, Neil Armstrong wrote:
> > Hi,
> > 
> > On Mon, 04 Dec 2023 12:57:09 -0600, Chris Morgan wrote:
> >> From: Chris Morgan 
> >>
> >> Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming
> >> console.
> >>
> >> Changes since V1:
> >>   - Corrected a bug with the DRM mode flags for the video driver.
> >>   - Adjusted panel front and back porch and pixel clock to fix
> >> issues with display that occurred after correcting DRM mode
> >> flag bug.
> >>   - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz.
> >>
> >> [...]
> > 
> > Thanks, Applied to https://anongit.freedesktop.org/git/drm/drm-misc.git 
> > (drm-misc-next)
> > 
> > [01/10] drm/panel: himax-hx8394: Drop prepare/unprepare tracking
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=8c2c5d1d33f0725b7995f44f87a81311d13a441d
> > [02/10] drm/panel: himax-hx8394: Drop shutdown logic
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=e4f53a4d921eba6187a2599cf184a3beeb604fe2
> > [03/10] dt-bindings: display: Document Himax HX8394 panel rotation
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=be478bc7ab08127473ce9ed893378cc2a8762611
> > [04/10] drm/panel: himax-hx8394: Add Panel Rotation Support
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=a695a5009c8fd239a98d98209489997ff5397d2b
> > [05/10] dt-bindings: display: himax-hx8394: Add Powkiddy X55 panel
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=00830a0d8f0d820335e7beb26e251069d90f2574
> > [06/10] drm/panel: himax-hx8394: Add Support for Powkiddy X55 panel
> >  
> > https://cgit.freedesktop.org/drm/drm-misc/commit/?id=38db985966d2f0f89f7e1891253489a16936fc5e
> > [07/10] clk: rockchip: Mark pclk_usb as critical on rk3568
> >  (no commit info)
> > [08/10] clk: rockchip: rk3568: Add PLL rate for 126.4MHz
> >  (no commit info)
> > [09/10] dt-bindings: arm: rockchip: Add Powkiddy X55
> >  (no commit info)
> > [10/10] arm64: dts: rockchip: Add Powkiddy X55
> >  (no commit info)
> > 
> 
> To clarify, only patches 1 to 6 were applied to drm-misc-next,

thanks for the clarification (and applying the patches already)

Heiko

Re: [PATCH v3 06/14] drm/panthor: Add the devfreq logical block

[Clément Péron]

Hi Boris,

On Mon, 4 Dec 2023 at 18:33, Boris Brezillon
 wrote:
>
> Every thing related to devfreq in placed in panthor_devfreq.c, and
> helpers that can be called by other logical blocks are exposed through
> panthor_devfreq.h.
>
> This implementation is loosely based on the panfrost implementation,
> the only difference being that we don't count device users, because
> the idle/active state will be managed by the scheduler logic.
>
> v3:
> - Add acks for the MIT/GPL2 relicensing
>
> v2:
> - Added in v2
>
> Cc: Clément Péron  # MIT+GPL2 relicensing

For the MIT+GPL2 relicensing.

Acked-by: Clément Péron 

> Reviewed-by: Steven Price 
> Signed-off-by: Boris Brezillon 
> Acked-by: Steven Price  # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely  # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon  # MIT+GPL2 
> relicensing,Collabora
> ---
>  drivers/gpu/drm/panthor/panthor_devfreq.c | 283 ++
>  drivers/gpu/drm/panthor/panthor_devfreq.h |  25 ++
>  2 files changed, 308 insertions(+)
>  create mode 100644 drivers/gpu/drm/panthor/panthor_devfreq.c
>  create mode 100644 drivers/gpu/drm/panthor/panthor_devfreq.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c 
> b/drivers/gpu/drm/panthor/panthor_devfreq.c
> new file mode 100644
> index ..dd28b15337d4
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
> @@ -0,0 +1,283 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2019 Collabora ltd. */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include "panthor_device.h"
> +#include "panthor_devfreq.h"
> +
> +/**
> + * struct panthor_devfreq - Device frequency management
> + */
> +struct panthor_devfreq {
> +   /** @devfreq: devfreq device. */
> +   struct devfreq *devfreq;
> +
> +   /** @gov_data: Governor data. */
> +   struct devfreq_simple_ondemand_data gov_data;
> +
> +   /** @busy_time: Busy time. */
> +   ktime_t busy_time;
> +
> +   /** @idle_time: Idle time. */
> +   ktime_t idle_time;
> +
> +   /** @time_last_update: Last update time. */
> +   ktime_t time_last_update;
> +
> +   /** @last_busy_state: True if the GPU was busy last time we updated 
> the state. */
> +   bool last_busy_state;
> +
> +   /*
> +* @lock: Lock used to protect busy_time, idle_time, time_last_update 
> and
> +* last_busy_state.
> +*
> +* These fields can be accessed concurrently by 
> panthor_devfreq_get_dev_status()
> +* and panthor_devfreq_record_{busy,idle}().
> +*/
> +   spinlock_t lock;
> +};
> +
> +static void panthor_devfreq_update_utilization(struct panthor_devfreq 
> *pdevfreq)
> +{
> +   ktime_t now, last;
> +
> +   now = ktime_get();
> +   last = pdevfreq->time_last_update;
> +
> +   if (pdevfreq->last_busy_state)
> +   pdevfreq->busy_time += ktime_sub(now, last);
> +   else
> +   pdevfreq->idle_time += ktime_sub(now, last);
> +
> +   pdevfreq->time_last_update = now;
> +}
> +
> +static int panthor_devfreq_target(struct device *dev, unsigned long *freq,
> + u32 flags)
> +{
> +   struct dev_pm_opp *opp;
> +
> +   opp = devfreq_recommended_opp(dev, freq, flags);
> +   if (IS_ERR(opp))
> +   return PTR_ERR(opp);
> +   dev_pm_opp_put(opp);
> +
> +   return dev_pm_opp_set_rate(dev, *freq);
> +}
> +
> +static void panthor_devfreq_reset(struct panthor_devfreq *pdevfreq)
> +{
> +   pdevfreq->busy_time = 0;
> +   pdevfreq->idle_time = 0;
> +   pdevfreq->time_last_update = ktime_get();
> +}
> +
> +static int panthor_devfreq_get_dev_status(struct device *dev,
> + struct devfreq_dev_status *status)
> +{
> +   struct panthor_device *ptdev = dev_get_drvdata(dev);
> +   struct panthor_devfreq *pdevfreq = ptdev->devfreq;
> +   unsigned long irqflags;
> +
> +   status->current_frequency = clk_get_rate(ptdev->clks.core);
> +
> +   spin_lock_irqsave(&pdevfreq->lock, irqflags);
> +
> +   panthor_devfreq_update_utilization(pdevfreq);
> +
> +   status->total_time = ktime_to_ns(ktime_add(pdevfreq->busy_time,
> +  pdevfreq->idle_time));
> +
> +   status->busy_time = ktime_to_ns(pdevfreq->busy_time);
> +
> +   panthor_devfreq_reset(pdevfreq);
> +
> +   spin_unlock_irqrestore(&pdevfreq->lock, irqflags);
> +
> +   drm_dbg(&ptdev->base, "busy %lu total %lu %lu %% freq %lu MHz\n",
> +   status->busy_time, status->total_time,
> +   status->busy_time / (status->total_time / 100),
> +   status->current_frequency / 1000 / 1000);
> +
> +   return 0;
> +}
> +
> +static struct devfreq_dev_profile panthor_devfreq_profile = {
> +   .timer = DEVFREQ_TIMER_DELAYED,
> +   .polling_ms = 50, /* ~3 frames */
> +   .target = panthor_devfreq_ta

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Andreas Kemnade]

On Tue, 5 Dec 2023 10:27:56 +0100
Krzysztof Kozlowski  wrote:

> On 05/12/2023 10:02, Andreas Kemnade wrote:
> > On Tue, 5 Dec 2023 09:45:44 +0100
> > Krzysztof Kozlowski  wrote:
> >   
> >>> Sure the clock nodes can be there for the child IP, but they won't do
> >>> anything. And still need to be managed separately by the device driver if
> >>> added.
> >>
> >> So if OS does not have runtime PM, the bindings are wrong? Bindings
> >> should not depend on some particular feature of some particular OS.  
> > 
> > Any user of the devicetree sees that there is a parent and the parent needs
> > to be enabled by some mechanism.
> > E.g. I2c devices do not specify the clocks of the parent (the i2c master)  
> 
> If you use this analogy, then compare it with an I2C device which has
> these clock inputs. Such device must have clocks in the bindings.
> 
I would see target-module = i2c master.

Well, if there is a variant of the i2c device which does not require
external clocks and a variant which requires it, then clock can be
optional.

> > 
> > Maybe it is just more fine-grained on omap.
> > 
> > look e.g. at ti/omap/omap4-l4.dtsi
> > there are target-module@
> > with the devices as a child and a clock in the parent.  
> 
> Not related to runtime PM...
> 
Well, runtime PM is just the linux-specific mechanism to enable the
resources needed by the parent, so yes, it is not related... As said,
another OS can have another mechanism.

But anyways, the target module specifies resources which are required.

Regards,
Andreas

Re: [PATCH v3 11/14] drm/rockchip: vop2: Add support for rk3588

[Andy Yan]

Hi Sascha:

On 12/5/23 17:29, Sascha Hauer wrote:

On Thu, Nov 30, 2023 at 08:24:39PM +0800, Andy Yan wrote:

From: Andy Yan 

VOP2 on rk3588:

Four video ports:
VP0 Max 4096x2160
VP1 Max 4096x2160
VP2 Max 4096x2160
VP3 Max 2048x1080

4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
4 4K Esmart windows with line RGB/YUV support

Signed-off-by: Andy Yan 


With the two nits below feel free to add my:

Reviewed-by: Sascha Hauer 

Thanks for working on this.


diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
index 8d7ff52523fb..8b16031eda52 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
@@ -13,9 +13,16 @@
  
  #define VOP_FEATURE_OUTPUT_10BITBIT(0)


You could rename this to include "VP" for Video Port so it's not so
easily mixed up with the defines below.


Yes, I have the same idea, maybe it's better to do the rename in a separate ?


  
+#define VOP2_FEATURE_HAS_SYS_GRF	BIT(0)

+#define VOP2_FEATURE_HAS_VO0_GRF   BIT(1)
+#define VOP2_FEATURE_HAS_VO1_GRF   BIT(2)
+#define VOP2_FEATURE_HAS_VOP_GRF   BIT(3)
+#define VOP2_FEATURE_HAS_SYS_PMU   BIT(5)


Should be BIT(4)


Thanks for catching this, will fix in next version.


Sascha

Re: [PATCH RFC 01/10] dt-bindings: gpu: Add PowerVR Series5 SGX GPUs

[Andreas Kemnade]

On Tue, 5 Dec 2023 09:45:44 +0100
Krzysztof Kozlowski  wrote:

> > Sure the clock nodes can be there for the child IP, but they won't do
> > anything. And still need to be managed separately by the device driver if
> > added.  
> 
> So if OS does not have runtime PM, the bindings are wrong? Bindings
> should not depend on some particular feature of some particular OS.

Any user of the devicetree sees that there is a parent and the parent needs
to be enabled by some mechanism.
E.g. I2c devices do not specify the clocks of the parent (the i2c master)

Maybe it is just more fine-grained on omap.

look e.g. at ti/omap/omap4-l4.dtsi
there are target-module@
with the devices as a child and a clock in the parent.

Regards,
Andreas

Re: [PATCH v3 11/14] drm/rockchip: vop2: Add support for rk3588

[Sascha Hauer]

On Tue, Dec 05, 2023 at 05:44:03PM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 12/5/23 17:29, Sascha Hauer wrote:
> > On Thu, Nov 30, 2023 at 08:24:39PM +0800, Andy Yan wrote:
> > > From: Andy Yan 
> > > 
> > > VOP2 on rk3588:
> > > 
> > > Four video ports:
> > > VP0 Max 4096x2160
> > > VP1 Max 4096x2160
> > > VP2 Max 4096x2160
> > > VP3 Max 2048x1080
> > > 
> > > 4 4K Cluster windows with AFBC/line RGB and AFBC-only YUV support
> > > 4 4K Esmart windows with line RGB/YUV support
> > > 
> > > Signed-off-by: Andy Yan 
> > 
> > With the two nits below feel free to add my:
> > 
> > Reviewed-by: Sascha Hauer 
> > 
> > Thanks for working on this.
> > 
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h 
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > > index 8d7ff52523fb..8b16031eda52 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.h
> > > @@ -13,9 +13,16 @@
> > >   #define VOP_FEATURE_OUTPUT_10BITBIT(0)
> > 
> > You could rename this to include "VP" for Video Port so it's not so
> > easily mixed up with the defines below.
> 
> Yes, I have the same idea, maybe it's better to do the rename in a separate ?

Ah Yes, I didn't realize this is just a context line. I thought you
had added it.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[RFC][PATCH v6 0/5] drm/panic: Add a drm panic handler

[Jocelyn Falempe]

drm/panic: Add a drm panic handler

This introduces a new drm panic handler, which displays a message when a panic 
occurs.
So when fbcon is disabled, you can still see a kernel panic.

This is one of the missing feature, when disabling VT/fbcon in the kernel:
https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/
Fbcon can be replaced by a userspace kms console, but the panic screen must be 
done in the kernel.

This is a proof of concept, and works with simpledrm and mgag200, using a new 
get_scanout_buffer() api

To test it, make sure you're using the simpledrm driver, and trigger a panic:
echo c > /proc/sysrq-trigger

v2:
 * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann)
 * Add the panic reason to the panic message (Nerdopolis)
 * Add an exclamation mark (Nerdopolis)
 
v3:
 * Rework the drawing functions, to write the pixels line by line and
 to use the drm conversion helper to support other formats.
 (Thomas Zimmermann)
 
v4:
 * Fully support all simpledrm formats using drm conversion helpers
 * Rename dpanic_* to drm_panic_*, and have more coherent function name.
   (Thomas Zimmermann)
 * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann)
 * Remove the default y to DRM_PANIC config option (Thomas Zimmermann)
 * Add foreground/background color config option
 * Fix the bottom lines not painted if the framebuffer height
   is not a multiple of the font height.
 * Automatically register the driver to drm_panic, if the function
   get_scanout_buffer() exists. (Thomas Zimmermann)
 * Add mgag200 support.
 
v5:
 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
   (Thomas Zimmermann)
 * Also add drm_fb_fill() to fill area with background color.
 * Add draw_pixel_xy() API for drivers that can't provide a linear buffer.
 * Add a flush() callback for drivers that needs to synchronize the buffer.
 * Add a void *private field, so drivers can pass private data to
   draw_pixel_xy() and flush(). 
 * Add ast support.
 * Add experimental imx/ipuv3 support, to test on an ARM hw. (Maxime Ripard)

v6:
 * Fix sparse and __le32 warnings
 * Drop the IMX/IPUV3 experiment, it was just to show that it works also on ARM 
devices.

With mgag200 support, I was able to test that the xrgb to rgb565 conversion 
is working.

IMX/IPUV3 support is not complete, I wasn't able to have etnaviv working on my 
board.
But it shows that it can still work on ARM with DMA buffer in this case.

Best regards,

Jocelyn Falempe (5):
  drm/format-helper: Add drm_fb_blit_from_r1 and drm_fb_fill
  drm/panic: Add a drm panic handler
  drm/simpledrm: Add drm_panic support
  drm/mgag200: Add drm_panic support
  drm/ast: Add drm_panic support

 drivers/gpu/drm/Kconfig   |  22 ++
 drivers/gpu/drm/Makefile  |   1 +
 drivers/gpu/drm/ast/ast_drv.c |  29 +-
 drivers/gpu/drm/drm_drv.c |   8 +
 drivers/gpu/drm/drm_format_helper.c   | 431 +-
 drivers/gpu/drm/drm_panic.c   | 368 ++
 drivers/gpu/drm/mgag200/mgag200_drv.c |  25 ++
 drivers/gpu/drm/tiny/simpledrm.c  |  15 +
 include/drm/drm_drv.h |  21 ++
 include/drm/drm_format_helper.h   |   9 +
 include/drm/drm_panic.h   |  96 ++
 11 files changed, 942 insertions(+), 83 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_panic.c
 create mode 100644 include/drm/drm_panic.h


base-commit: d0b3c318e04cc6c4e2a3c30ee0f6f619aa8d0db5
-- 
2.42.0

[PATCH v6 1/5] drm/format-helper: Add drm_fb_blit_from_r1 and drm_fb_fill

[Jocelyn Falempe]

This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.

v5:
 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
 * Also add drm_fb_fill() to fill area with background color.
v6:
 * fix __le32 conversion warning found by the kernel test bot

Signed-off-by: Jocelyn Falempe 
---
 drivers/gpu/drm/drm_format_helper.c | 431 ++--
 include/drm/drm_format_helper.h |   9 +
 2 files changed, 359 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index b1be458ed4dd..38a3c38f5d84 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -111,6 +111,152 @@ void drm_format_conv_state_release(struct 
drm_format_conv_state *state)
 }
 EXPORT_SYMBOL(drm_format_conv_state_release);
 
+static inline __le16 drm_format_xrgb_to_rgb565(__le32 val32)
+{
+   u16 val16;
+   u32 pix;
+
+   pix = le32_to_cpu(val32);
+   val16 = ((pix & 0x00F8) >> 8) |
+   ((pix & 0xFC00) >> 5) |
+   ((pix & 0x00F8) >> 3);
+   return cpu_to_le16(val16);
+}
+
+static inline __le16 drm_format_xrgb_to_rgba5551(__le32 val32)
+{
+   u16 val16;
+   u32 pix;
+
+   pix = le32_to_cpu(val32);
+   val16 = ((pix & 0x00f8) >> 8) |
+   ((pix & 0xf800) >> 5) |
+   ((pix & 0x00f8) >> 2) |
+   BIT(0); /* set alpha bit */
+   return cpu_to_le16(val16);
+}
+
+static inline __le16 drm_format_xrgb_to_xrgb1555(__le32 val32)
+{
+   u16 val16;
+   u32 pix;
+
+   pix = le32_to_cpu(val32);
+   val16 = ((pix & 0x00f8) >> 9) |
+   ((pix & 0xf800) >> 6) |
+   ((pix & 0x00f8) >> 3);
+   return cpu_to_le16(val16);
+}
+
+static inline __le16 drm_format_xrgb_to_argb1555(__le32 val32)
+{
+   u16 val16;
+   u32 pix;
+
+   pix = le32_to_cpu(val32);
+   val16 = BIT(15) | /* set alpha bit */
+   ((pix & 0x00f8) >> 9) |
+   ((pix & 0xf800) >> 6) |
+   ((pix & 0x00f8) >> 3);
+   return cpu_to_le16(val16);
+}
+
+static inline __le32 drm_format_xrgb_to_argb(__le32 pix)
+{
+   u32 val32;
+
+   val32 = le32_to_cpu(pix);
+   val32 |= GENMASK(31, 24); /* fill alpha bits */
+   return cpu_to_le32(val32);
+}
+
+static inline __le32 drm_format_xrgb_to_xbgr(__le32 pix)
+{
+   u32 val32;
+
+   val32 = le32_to_cpu(pix);
+   val32 = ((val32 & 0x00ff) >> 16) <<  0 |
+   ((val32 & 0xff00) >>  8) <<  8 |
+   ((val32 & 0x00ff) >>  0) << 16 |
+   ((val32 & 0xff00) >> 24) << 24;
+   return cpu_to_le32(val32);
+}
+
+static inline __le32 drm_format_xrgb_to_abgr(__le32 pix)
+{
+   u32 val32;
+
+   val32 = le32_to_cpu(pix);
+   val32 = ((val32 & 0x00ff) >> 16) <<  0 |
+   ((val32 & 0xff00) >>  8) <<  8 |
+   ((val32 & 0x00ff) >>  0) << 16 |
+   GENMASK(31, 24); /* fill alpha bits */
+   return cpu_to_le32(val32);
+}
+
+static inline __le32 drm_format_xrgb_to_xrgb2101010(__le32 pix)
+{
+   u32 val32;
+
+   val32 = le32_to_cpu(pix);
+   val32 = ((val32 & 0x00FF) << 2) |
+   ((val32 & 0xFF00) << 4) |
+   ((val32 & 0x00FF) << 6);
+   return cpu_to_le32(val32 | ((val32 >> 8) & 0x00300C03));
+}
+
+static inline __le32 drm_format_xrgb_to_argb2101010(__le32 pix)
+{
+   u32 val32;
+
+   val32 = le32_to_cpu(pix);
+   val32 = ((val32 & 0x00FF) << 2) |
+   ((val32 & 0xFF00) << 4) |
+   ((val32 & 0x00FF) << 6);
+   val32 = GENMASK(31, 30) | /* set alpha bits */
+ val32 | ((val32 >> 8) & 0x00300c03);
+   return cpu_to_le32(val32);
+}
+
+/**
+ * drm_fb_convert_from_xrgb - convert one pixel from xrgb to the 
desired format
+ * @color: input color, in xrgb format
+ * @format: output format
+ *
+ * Returns:
+ * Color in the format specified, casted to u32.
+ */
+u32 drm_fb_convert_from_xrgb(u32 color, u32 format)
+{
+   __le32 pix = cpu_to_le32(color);
+
+   switch (format) {
+   case DRM_FORMAT_RGB565:
+   return le16_to_cpu(drm_format_xrgb_to_rgb565(pix));
+   case DRM_FORMAT_RGBA5551:
+   return le16_to_cpu(drm_format_xrgb_to_rgba5551(pix));
+   case DRM_FORMAT_XRGB1555:
+   return le16_to_cpu(drm_format_xrgb_to_xrgb1555(pix));
+   case DRM_FORMAT_ARGB1555:
+   return le16_to_cpu(drm_format_xrgb_to_argb1555(pix));
+   case DRM_FORMAT_RGB888:
+   case DRM_FORMAT_XRGB:
+   return le32_to_cpu(pix);
+   case DRM_FORMAT_ARGB:
+   return le32_to_cpu(drm_format_xrgb_to_argb(pix));
+   case DRM_FORMAT_XBGR:
+   r

[PATCH v6 2/5] drm/panic: Add a drm panic handler

[Jocelyn Falempe]

This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.

v2
 * Use get_scanout_buffer() instead of the drm client API.
  (Thomas Zimmermann)
 * Add the panic reason to the panic message (Nerdopolis)
 * Add an exclamation mark (Nerdopolis)

v3
 * Rework the drawing functions, to write the pixels line by line and
 to use the drm conversion helper to support other formats.
 (Thomas Zimmermann)

v4
 * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann)
 * Remove the default y to DRM_PANIC config option (Thomas Zimmermann)
 * Add foreground/background color config option
 * Fix the bottom lines not painted if the framebuffer height
   is not a multiple of the font height.
 * Automatically register the device to drm_panic, if the function
   get_scanout_buffer exists. (Thomas Zimmermann)

v5
 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
 * Also add drm_fb_fill() to fill area with background color.
 * Add draw_pixel_xy() API for drivers that can't provide a linear buffer.
 * Add a flush() callback for drivers that needs to synchronize the buffer.
 * Add a void *private field, so drivers can pass private data to
   draw_pixel_xy() and flush().

v6
 * Fix sparse warning for panic_msg and logo

Signed-off-by: Jocelyn Falempe 
---
 drivers/gpu/drm/Kconfig |  22 +++
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/drm_drv.c   |   8 +
 drivers/gpu/drm/drm_panic.c | 368 
 include/drm/drm_drv.h   |  21 ++
 include/drm/drm_panic.h |  96 ++
 6 files changed, 516 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_panic.c
 create mode 100644 include/drm/drm_panic.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index b7abd436455f..6bf7a5b2f288 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -103,6 +103,28 @@ config DRM_KMS_HELPER
help
  CRTC helpers for KMS drivers.
 
+config DRM_PANIC
+   bool "Display a user-friendly message when a kernel panic occurs"
+   depends on DRM && !FRAMEBUFFER_CONSOLE
+   select FONT_SUPPORT
+   help
+ Enable a drm panic handler, which will display a user-friendly message
+ when a kernel panic occurs. It's useful when using a user-space
+ console instead of fbcon.
+ It will only work if your graphic driver supports this feature.
+ To support Hi-DPI Display, you can enable bigger fonts like
+ FONT_TER16x32
+
+config DRM_PANIC_FOREGROUND_COLOR
+   hex "Drm panic screen foreground color, in RGB"
+   depends on DRM_PANIC
+   default 0xff
+
+config DRM_PANIC_BACKGROUND_COLOR
+   hex "Drm panic screen background color, in RGB"
+   depends on DRM_PANIC
+   default 0x00
+
 config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
 bool "Enable refcount backtrace history in the DP MST helpers"
depends on STACKTRACE_SUPPORT
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index b4cb0835620a..100e7cfad3b9 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -73,6 +73,7 @@ drm-$(CONFIG_DRM_PRIVACY_SCREEN) += \
drm_privacy_screen_x86.o
 drm-$(CONFIG_DRM_ACCEL) += ../../accel/drm_accel.o
 obj-$(CONFIG_DRM)  += drm.o
+drm-$(CONFIG_DRM_PANIC) += drm_panic.o
 
 obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
 
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 3c835c99daad..897146fbda25 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -955,6 +956,9 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
goto err_unload;
}
 
+   if (driver->get_scanout_buffer)
+   drm_panic_register(dev);
+
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
 driver->name, driver->major, driver->minor,
 driver->patchlevel, driver->date,
@@ -1001,6 +1005,8 @@ void drm_dev_unregister(struct drm_device *dev)
 
dev->registered = false;
 
+   drm_panic_unregister(dev);
+
drm_client_dev_unregister(dev);
 
if (drm_core_check_feature(dev, DRIVER_MODESET))
@@ -1083,6 +1089,7 @@ static void drm_core_exit(void)
unregister_chrdev(DRM_MAJOR, "drm");
debugfs_remove(drm_debugfs_root);
drm_sysfs_destroy();
+   drm_panic_exit();
idr_destroy(&drm_minors_idr);
drm_connector_ida_destroy();
 }
@@ -1094,6 +1101,7 @@ static int __init drm_core_init(void)
drm_connector_ida_init();
idr_init(&drm_minors_idr);
drm_memcpy_init_early();
+   drm_panic_init();
 
ret = drm_sysfs_init();
if (ret < 0) {
diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
new file mode 100644
index 0

[PATCH v6 5/5] drm/ast: Add drm_panic support

[Jocelyn Falempe]

Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.

Signed-off-by: Jocelyn Falempe 
---
 drivers/gpu/drm/ast/ast_drv.c | 29 +++--
 1 file changed, 27 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 90bcb1eb9cd9..bb49e89dbd3c 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "ast_drv.h"
@@ -48,6 +49,30 @@ module_param_named(modeset, ast_modeset, int, 0400);
  * DRM driver
  */
 
+static int ast_get_scanout_buffer(struct drm_device *dev,
+ struct drm_scanout_buffer *sb)
+{
+   struct drm_plane *plane;
+   struct ast_plane *ast_plane;
+
+   drm_for_each_plane(plane, dev) {
+   if (!plane->state || !plane->state->visible || 
!plane->state->fb ||
+   plane->type != DRM_PLANE_TYPE_PRIMARY)
+   continue;
+   ast_plane = to_ast_plane(plane);
+   if (!ast_plane->vaddr)
+   continue;
+
+   sb->format = plane->state->fb->format;
+   sb->width = plane->state->fb->width;
+   sb->height = plane->state->fb->height;
+   sb->pitch = plane->state->fb->pitches[0];
+   iosys_map_set_vaddr_iomem(&sb->map, ast_plane->vaddr);
+   return 0;
+   }
+   return -ENODEV;
+}
+
 DEFINE_DRM_GEM_FOPS(ast_fops);
 
 static const struct drm_driver ast_driver = {
@@ -62,8 +87,8 @@ static const struct drm_driver ast_driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
-
-   DRM_GEM_SHMEM_DRIVER_OPS
+   .get_scanout_buffer = ast_get_scanout_buffer,
+   DRM_GEM_SHMEM_DRIVER_OPS,
 };
 
 /*
-- 
2.42.0

[PATCH v6 4/5] drm/mgag200: Add drm_panic support

[Jocelyn Falempe]

Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.

v5:
 * Also check that the plane is visible and primary. (Thomas Zimmermann)

Signed-off-by: Jocelyn Falempe 
---
 drivers/gpu/drm/mgag200/mgag200_drv.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c 
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 2fb18b782b05..c79f3d9ee39a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.c
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
@@ -13,10 +13,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "mgag200_drv.h"
@@ -84,6 +86,28 @@ resource_size_t mgag200_probe_vram(void __iomem *mem, 
resource_size_t size)
return offset - 65536;
 }
 
+static int mgag200_get_scanout_buffer(struct drm_device *dev,
+ struct drm_scanout_buffer *sb)
+{
+   struct drm_plane *plane;
+   struct mga_device *mdev = to_mga_device(dev);
+   struct iosys_map map = IOSYS_MAP_INIT_VADDR_IOMEM(mdev->vram);
+
+   /* find the primary and visible plane */
+   drm_for_each_plane(plane, dev) {
+   if (!plane->state || !plane->state->visible || 
!plane->state->fb ||
+   plane->type != DRM_PLANE_TYPE_PRIMARY)
+   continue;
+   sb->format = plane->state->fb->format;
+   sb->width = plane->state->fb->width;
+   sb->height = plane->state->fb->height;
+   sb->pitch = plane->state->fb->pitches[0];
+   sb->map = map;
+   return 0;
+   }
+   return -ENODEV;
+}
+
 /*
  * DRM driver
  */
@@ -99,6 +123,7 @@ static const struct drm_driver mgag200_driver = {
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
+   .get_scanout_buffer = mgag200_get_scanout_buffer,
DRM_GEM_SHMEM_DRIVER_OPS,
 };
 
-- 
2.42.0

[PATCH v6 3/5] drm/simpledrm: Add drm_panic support

[Jocelyn Falempe]

Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.

Signed-off-by: Jocelyn Falempe 
---
 drivers/gpu/drm/tiny/simpledrm.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 34bbbd7b53dd..41eea078294b 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -986,6 +987,19 @@ static struct simpledrm_device 
*simpledrm_device_create(struct drm_driver *drv,
return sdev;
 }
 
+static int simpledrm_get_scanout_buffer(struct drm_device *dev,
+   struct drm_scanout_buffer *sb)
+{
+   struct simpledrm_device *sdev = simpledrm_device_of_dev(dev);
+
+   sb->width = sdev->mode.hdisplay;
+   sb->height = sdev->mode.vdisplay;
+   sb->pitch = sdev->pitch;
+   sb->format = sdev->format;
+   sb->map = sdev->screen_base;
+   return 0;
+}
+
 /*
  * DRM driver
  */
@@ -1001,6 +1015,7 @@ static struct drm_driver simpledrm_driver = {
.minor  = DRIVER_MINOR,
.driver_features= DRIVER_ATOMIC | DRIVER_GEM | DRIVER_MODESET,
.fops   = &simpledrm_fops,
+   .get_scanout_buffer = simpledrm_get_scanout_buffer,
 };
 
 /*
-- 
2.42.0

Re: (subset) [PATCH V2 00/10] rockchip: Add Powkiddy X55

[Heiko Stuebner]

On Mon, 4 Dec 2023 12:57:09 -0600, Chris Morgan wrote:
> From: Chris Morgan 
> 
> Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming
> console.
> 
> Changes since V1:
>  - Corrected a bug with the DRM mode flags for the video driver.
>  - Adjusted panel front and back porch and pixel clock to fix
>issues with display that occurred after correcting DRM mode
>flag bug.
>  - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz.
> 
> [...]

Applied, thanks!

[07/10] clk: rockchip: Mark pclk_usb as critical on rk3568
commit: 721bf080f249ab2adcc4337abe164230bfb8594f
[08/10] clk: rockchip: rk3568: Add PLL rate for 126.4MHz
commit: 685da6972647b486980c0cc8fd6bb5d3863fd6b7

Best regards,
-- 
Heiko Stuebner 

Re: (subset) [PATCH V2 00/10] rockchip: Add Powkiddy X55

[Heiko Stuebner]

On Mon, 4 Dec 2023 12:57:09 -0600, Chris Morgan wrote:
> From: Chris Morgan 
> 
> Add support for the Rockchip RK3566 based Powkiddy X55 handheld gaming
> console.
> 
> Changes since V1:
>  - Corrected a bug with the DRM mode flags for the video driver.
>  - Adjusted panel front and back porch and pixel clock to fix
>issues with display that occurred after correcting DRM mode
>flag bug.
>  - Add a new clk frequency for PLL_VPLL to get panel to run at ~60hz.
> 
> [...]

Applied, thanks!

[09/10] dt-bindings: arm: rockchip: Add Powkiddy X55
commit: b7d755653790b5f5497df8bfb146c38beeb33b74
[10/10] arm64: dts: rockchip: Add Powkiddy X55
commit: 009e2d0c224913eb4f44e9c2efe7a15789fc0c18

Best regards,
-- 
Heiko Stuebner 

Re: [DO NOT MERGE v5 17/37] dt-bindings: interrupt-controller: renesas,sh7751-intc: Add json-schema

[Linus Walleij]

Hi Yoshinori,

thanks for your patch!

On Tue, Dec 5, 2023 at 10:46 AM Yoshinori Sato
 wrote:

> +  renesas,icr-irlm:
> +type: boolean
> +description: If true ICR.IRLM=1

That's a bit hard to understand. I suppose it's something that need to sometimes
be changed for a system so would be good to document it properly.

> +  renesas,ipr-map:
> +$ref: /schemas/types.yaml#/definitions/uint32-array
> +description: |
> +  IRQ to IPR mapping definition.
> +  1st - INTEVT
> +  2nd - Register
> +  3rd - bit index

Isn't this table always the same for a certain SoC, e.g. compatible
"renesas,sh7751-intc"?

Then don't keep it in the device tree, just look it up per-soc from a
table in the driver.

Other than that it looks good to me.

Yours,
Linus Walleij

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Tvrtko Ursulin]

On 05/12/2023 08:50, Nirmoy Das wrote:

Hi Tvrtko,

On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:


On 01/12/2023 15:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.


No complaints per se but I don't see the caller deciding and it is not 
really reducing log level but converting to trace. So commit message 
and patch do not align for me which I think should be improved.



I meant the return value is checked by the caller, gen8_reset_engines(). 
I will resend with a improved commit message.


Ah okay, maybe my bad for not figuring out that possibility. I guess it 
might be passable as is, but yes, clearer commit text would be better.


Trace is good enough - we are not usually interested in seeing those as 
dbg/info/notice?


Regards,

Tvrtko



Thanks,

Nirmoy



Regards,

Tvrtko


Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

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

index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)

  ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
 700, 0, NULL);
  if (ret)
-    gt_err(engine->gt,
-   "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

-   engine->name, request,
-   intel_uncore_read_fw(uncore, reg));
+    GT_TRACE(engine->gt,
+ "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",

+ engine->name, request,
+ intel_uncore_read_fw(uncore, reg));
    return ret;
  }

Re: [DO NOT MERGE v5 14/37] clk: Compatible with narrow registers

[Uwe Kleine-König]

Hello,

On Tue, Dec 05, 2023 at 06:45:33PM +0900, Yoshinori Sato wrote:
> @@ -675,13 +681,17 @@ struct clk_div_table {
>   * CLK_DIVIDER_BIG_ENDIAN - By default little endian register accesses are 
> used
>   *   for the divider register.  Setting this flag makes the register accesses
>   *   big endian.
> + * CLK_DIVIDER_REG_8BIT - by default 32bit register accesses are used for
> + *   the gate register.  Setting this flag makes the register accesses 8bit.
> + * CLK_DIVIDER_REG_16BIT - by default 32bit register accesses are used for
> + *   the gate register.  Setting this flag makes the register accesses 16bit.
>   */
>  struct clk_divider {
>   struct clk_hw   hw;
>   void __iomem*reg;
>   u8  shift;
>   u8  width;
> - u8  flags;
> + u32 flags;
>   const struct clk_div_table  *table;
>   spinlock_t  *lock;
>  };

I wonder why .flags was made bigger here. The two new flag values would
still fit into the u8, right?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [v3 0/6] DRM driver for verisilicon

[Sui Jingfeng]

HI,

This series are very interesting and nice!


On 2023/12/4 20:33, Keith Zhao wrote:

This patch is a drm driver for Starfive Soc JH7110,


'SoC' : System on Chip, no more 'Soc' or 'soc' please.


I am sending Drm driver part and HDMI driver part.



'DRM' or 'drm' nor Drm. DRM: Direct Rendering Manager.

Typically you should only *capitalize* the *first* letter of the first word
in a sentence, while this Drm appears in the middle of this sentence.

Please also improve the English written also, for example:

This series is a DRM driver for Starfive Soc JH7110, which contains (consists 
of)
a KMS driver for the vivante DC8200 display controller and a HDMI transmitter 
driver.




We used GEM framework for buffer management,
and for buffer allocation,we use DMA APIs.

the Starfive HDMI servers as interface between a LCD Controller


'servers' -> 'serve as', because server is a noun.


and a HDMI bus.
A HDMI TX consists of one HDMI transmitter controller
and one HDMI transmitter PHY.
(Sound support is not include in this patch)

This patchset should be applied on next branch.

V1:
Changes since v1:
- Further standardize the yaml file.
- Dts naming convention improved.
- Fix the problem of compiling and loading ko files.
- Use drm new api to automatically manage resources.
- Drop vs_crtc_funcs&vs_plane_funcs, subdivide the plane's help interface.
- Reduce the modifiers unused.
- Optimize the hdmi driver code

V2:
Changes since v2:
- fix the error about checking the yaml file.
- match drm driver GEM DMA API.
- Delete the custom crtc property .
- hdmi use drmm_ new api to automatically manage resources.
- update the modifiers comments.
- enabling KASAN, fix the error during removing module

V3:
Changes since v3:
- Delete the custom plane property.
- Delete the custom fourcc modifiers.
- Adjust the calculation mode of hdmi pixclock.
- Add match data for dc8200 driver.
- Adjust some magic values.
- Add a simple encoder for dsi output.

Keith Zhao (6):
   dt-bindings: display: Add yamls for JH7110 display system
   riscv: dts: starfive: jh7110: display subsystem
   drm/vs: Register DRM device
   drm/vs: Add KMS crtc&plane
   drm/vs: Add hdmi driver
   drm/vs: simple encoder

  .../starfive/starfive,display-subsystem.yaml  |  104 ++
  .../starfive/starfive,dsi-encoder.yaml|   92 ++
  .../starfive/starfive,jh7110-dc8200.yaml  |  113 ++
  .../starfive/starfive,jh7110-inno-hdmi.yaml   |   82 ++
  .../soc/starfive/starfive,jh7110-syscon.yaml  |1 +
  MAINTAINERS   |8 +
  .../jh7110-starfive-visionfive-2.dtsi |  134 ++
  arch/riscv/boot/dts/starfive/jh7110.dtsi  |   49 +
  drivers/gpu/drm/Kconfig   |2 +
  drivers/gpu/drm/Makefile  |1 +
  drivers/gpu/drm/verisilicon/Kconfig   |   21 +
  drivers/gpu/drm/verisilicon/Makefile  |   12 +
  drivers/gpu/drm/verisilicon/starfive_hdmi.c   |  849 
  drivers/gpu/drm/verisilicon/starfive_hdmi.h   |  304 +
  drivers/gpu/drm/verisilicon/vs_crtc.c |  208 +++
  drivers/gpu/drm/verisilicon/vs_crtc.h |   42 +
  drivers/gpu/drm/verisilicon/vs_dc.c   | 1192 +
  drivers/gpu/drm/verisilicon/vs_dc.h   |   67 +
  drivers/gpu/drm/verisilicon/vs_dc_hw.c| 1022 ++
  drivers/gpu/drm/verisilicon/vs_dc_hw.h|  580 
  drivers/gpu/drm/verisilicon/vs_drv.c  |  323 +
  drivers/gpu/drm/verisilicon/vs_drv.h  |   46 +
  drivers/gpu/drm/verisilicon/vs_modeset.c  |   39 +
  drivers/gpu/drm/verisilicon/vs_modeset.h  |   10 +
  drivers/gpu/drm/verisilicon/vs_plane.c|  301 +
  drivers/gpu/drm/verisilicon/vs_plane.h|   39 +
  drivers/gpu/drm/verisilicon/vs_simple_enc.c   |  195 +++
  drivers/gpu/drm/verisilicon/vs_simple_enc.h   |   23 +
  drivers/gpu/drm/verisilicon/vs_type.h |   69 +
  29 files changed, 5928 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,dsi-encoder.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml
  create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
  create mode 100644 drivers/gpu/drm/verisilicon/Makefile
  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
  create mode 100644 dri

Re: [PATCH v2] drm/i915/gt: Convert reset prepare failure log to trace

[Nirmoy Das]

Hi John,

On 12/5/2023 10:10 AM, John Harrison wrote:

On 12/5/2023 00:52, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Convert the log to a trace log for debugging without triggering
unnecessary concerns in CI or for end-users during non-fatal scenarios.
I strongly disagree with this change. The hardware spec for the 
RESET_CTL and GDRST registers are that they will self clear within a 
matter of microseconds. If something is so badly wrong with the 
hardware that it can't even manage to reset



This message is for reset readiness  poll timeout not that the reset is 
failed which doesn't sound so serious if the subsequent attempt managed 
reset the engine.


I couldn't get enough details when this can happen that HW takes very 
long time to set the readiness bit.



then that is something that very much warrants more than a completely 
silent trace event. It most certainly should be flagged as a failure 
in CI.


Just because the driver will retry does not mean that this is not a 
serious error. And if the first attempt failed, why would a subsequent 
attempt succeed?


The patch is not ignoring the failure. If the subsequent attempt fails 
then driver load will fail or it will be wedged if that happens after 
driver load.



Escalating to FLR may have more success, but that is not something 
that i915 currently does.


Do we still need to do FLR if a subsequent engine reset failure ?


Regards,

Nirmoy



John.




v2: Improve commit message(Tvrtko)

Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

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

index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)

  ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
 700, 0, NULL);
  if (ret)
-    gt_err(engine->gt,
-   "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

-   engine->name, request,
-   intel_uncore_read_fw(uncore, reg));
+    GT_TRACE(engine->gt,
+ "%s reset request timed out: {request: %08x, RESET_CTL: 
%08x}\n",

+ engine->name, request,
+ intel_uncore_read_fw(uncore, reg));
    return ret;
  }

Re: [PATCH v4 0/3] drm/panfrost: Fix poweroff and sync IRQs for suspend

[Boris Brezillon]

On Mon,  4 Dec 2023 12:42:12 +0100
AngeloGioacchino Del Regno 
wrote:

> Changes in v4:
>  - Added checks for is_suspended bits in hardirqs
>  - Added GPU suspended bit (and handling of it)
>  - Reordered panfrost_drv_comp_bits entries
>  - Commit description fixes
> 
> Changes in v3:
>  - Removed useless GPU_INT_CLEAR write in suspend path
>  - Changed to clear suspend bits in job/mmu reset path
> 
> This series contains a fast fix for the basic GPU poweroff functionality
> and goes further by implementing interrupt masking and synchronization
> before suspend.
> 
> For more information, please look at the conversation at [1], which
> explains the regression seen with the poweroff commit and the initial
> approaches taken to solve that.
> 
> Cheers!
> 
> [1]: 
> https://lore.kernel.org/all/20231123095320.41433-1-angelogioacchino.delre...@collabora.com/
> 
> AngeloGioacchino Del Regno (3):
>   drm/panfrost: Ignore core_mask for poweroff and disable PWRTRANS irq
>   drm/panfrost: Add gpu_irq, mmu_irq to struct panfrost_device
>   drm/panfrost: Synchronize and disable interrupts before powering off

Queued to drm-misc-next.

Thanks,

Boris

> 
>  drivers/gpu/drm/panfrost/panfrost_device.c |  3 ++
>  drivers/gpu/drm/panfrost/panfrost_device.h | 10 ++
>  drivers/gpu/drm/panfrost/panfrost_gpu.c| 40 --
>  drivers/gpu/drm/panfrost/panfrost_gpu.h|  1 +
>  drivers/gpu/drm/panfrost/panfrost_job.c| 26 +++---
>  drivers/gpu/drm/panfrost/panfrost_job.h|  1 +
>  drivers/gpu/drm/panfrost/panfrost_mmu.c| 32 -
>  drivers/gpu/drm/panfrost/panfrost_mmu.h|  1 +
>  8 files changed, 91 insertions(+), 23 deletions(-)
> 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Nirmoy Das]

Hi Tvrtko,

On 12/5/2023 11:05 AM, Tvrtko Ursulin wrote:


On 05/12/2023 08:50, Nirmoy Das wrote:

Hi Tvrtko,

On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:


On 01/12/2023 15:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.


No complaints per se but I don't see the caller deciding and it is 
not really reducing log level but converting to trace. So commit 
message and patch do not align for me which I think should be improved.



I meant the return value is checked by the caller, 
gen8_reset_engines(). I will resend with a improved commit message.


Ah okay, maybe my bad for not figuring out that possibility. I guess 
it might be passable as is, but yes, clearer commit text would be better.


I sent a v2 already :)




Trace is good enough - we are not usually interested in seeing those 
as dbg/info/notice?



Idea is that all the GT related events are recorded in trace and dmesg 
could be noisy some times.



Regards,

Nirmoy



Regards,

Tvrtko



Thanks,

Nirmoy



Regards,

Tvrtko


Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

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

index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)

  ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
 700, 0, NULL);
  if (ret)
-    gt_err(engine->gt,
-   "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

-   engine->name, request,
-   intel_uncore_read_fw(uncore, reg));
+    GT_TRACE(engine->gt,
+ "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

+ engine->name, request,
+ intel_uncore_read_fw(uncore, reg));
    return ret;
  }

Re: [PATCH] drm/gpuvm: Let drm_gpuvm_bo_put() report when the vm_bo object is destroyed

[Boris Brezillon]

On Tue, 5 Dec 2023 02:46:32 +0100
Danilo Krummrich  wrote:

> On 12/4/23 16:14, Boris Brezillon wrote:
> > Some users need to release resources attached to the vm_bo object when
> > it's destroyed. In Panthor's case, we need to release the pin ref so
> > BO pages can be returned to the system when all GPU mappings are gone.
> > 
> > This could be done through a custom drm_gpuvm::vm_bo_free() hook, but
> > this has all sort of locking implications that would force us to expose
> > a drm_gem_shmem_unpin_locked() helper, not to mention the fact that
> > having a ::vm_bo_free() implementation without a ::vm_bo_alloc() one
> > seems odd. So let's keep things simple, and extend drm_gpuvm_bo_put()
> > to report when the object is destroyed.
> > 
> > Signed-off-by: Boris Brezillon   
> 
> Reviewed-by: Danilo Krummrich 

Queued to drm-misc-next.

> 
> > ---
> >   drivers/gpu/drm/drm_gpuvm.c | 8 ++--
> >   include/drm/drm_gpuvm.h | 2 +-
> >   2 files changed, 7 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
> > index 54f5e8851de5..ae13e2d63637 100644
> > --- a/drivers/gpu/drm/drm_gpuvm.c
> > +++ b/drivers/gpu/drm/drm_gpuvm.c
> > @@ -1502,14 +1502,18 @@ drm_gpuvm_bo_destroy(struct kref *kref)
> >* hold the dma-resv or driver specific GEM gpuva lock.
> >*
> >* This function may only be called from non-atomic context.
> > + *
> > + * Returns: true if vm_bo was destroyed, false otherwise.
> >*/
> > -void
> > +bool
> >   drm_gpuvm_bo_put(struct drm_gpuvm_bo *vm_bo)
> >   {
> > might_sleep();
> >   
> > if (vm_bo)
> > -   kref_put(&vm_bo->kref, drm_gpuvm_bo_destroy);
> > +   return !!kref_put(&vm_bo->kref, drm_gpuvm_bo_destroy);
> > +
> > +   return false;
> >   }
> >   EXPORT_SYMBOL_GPL(drm_gpuvm_bo_put);
> >   
> > diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
> > index f94fec9a8517..7cc41a7d86d5 100644
> > --- a/include/drm/drm_gpuvm.h
> > +++ b/include/drm/drm_gpuvm.h
> > @@ -738,7 +738,7 @@ drm_gpuvm_bo_get(struct drm_gpuvm_bo *vm_bo)
> > return vm_bo;
> >   }
> >   
> > -void drm_gpuvm_bo_put(struct drm_gpuvm_bo *vm_bo);
> > +bool drm_gpuvm_bo_put(struct drm_gpuvm_bo *vm_bo);
> >   
> >   struct drm_gpuvm_bo *
> >   drm_gpuvm_bo_find(struct drm_gpuvm *gpuvm,  
> 

Re: [Intel-gfx] [PATCH] drm/i915/gt: Reduce log severity on reset prepare.

[Tvrtko Ursulin]

On 05/12/2023 10:44, Nirmoy Das wrote:

Hi Tvrtko,

On 12/5/2023 11:05 AM, Tvrtko Ursulin wrote:


On 05/12/2023 08:50, Nirmoy Das wrote:

Hi Tvrtko,

On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:


On 01/12/2023 15:44, Nirmoy Das wrote:

gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.

Let the caller of gen8_engine_reset_prepare() decide if a
failure in gen8_engine_reset_prepare is an error or not.


No complaints per se but I don't see the caller deciding and it is 
not really reducing log level but converting to trace. So commit 
message and patch do not align for me which I think should be improved.



I meant the return value is checked by the caller, 
gen8_reset_engines(). I will resend with a improved commit message.


Ah okay, maybe my bad for not figuring out that possibility. I guess 
it might be passable as is, but yes, clearer commit text would be better.


I sent a v2 already :)




Trace is good enough - we are not usually interested in seeing those 
as dbg/info/notice?



Idea is that all the GT related events are recorded in trace and dmesg 
could be noisy some times.


Although trace does not help on production deployments so we need to be 
sure the fact this timeout is hit is totally un-interesting. I see John 
has some concerns that it may not be so. And I don't have currently a 
view into how frequent they are (timeouts) or which platforms are affected.


Regards,

Tvrtko




Regards,

Nirmoy



Regards,

Tvrtko



Thanks,

Nirmoy



Regards,

Tvrtko


Cc: Tvrtko Ursulin 
Cc: John Harrison 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5591
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gt/intel_reset.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

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

index d5ed904f355d..e6fbc6202c80 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -593,10 +593,10 @@ static int gen8_engine_reset_prepare(struct 
intel_engine_cs *engine)

  ret = __intel_wait_for_register_fw(uncore, reg, mask, ack,
 700, 0, NULL);
  if (ret)
-    gt_err(engine->gt,
-   "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

-   engine->name, request,
-   intel_uncore_read_fw(uncore, reg));
+    GT_TRACE(engine->gt,
+ "%s reset request timed out: {request: %08x, 
RESET_CTL: %08x}\n",

+ engine->name, request,
+ intel_uncore_read_fw(uncore, reg));
    return ret;
  }

[PATCH v4 00/10] Add displays support for bsh-smm-s2/pro boards

[Dario Binacchi]

The series adds drivers for the displays used by bsh-smm-s2/pro boards.
This required applying some patches to the samsung-dsim driver and the
drm_bridge.c module.

Changes in v4:
- Set the reset gpio to low in a single operation
- Remove duplicated code for prepare/unprepare callbacks
- Add 'Reviewed-by; tag of Neil Armstrong

Changes in v3:
- Add 'Reviewed-by' tag of Krzysztof Kozlowski.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Drop power-supply
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.
- Squash patch [09/11] dt-bindings: ili9805: add compatible string for Tianma 
TM041XDHG01
  into [07/11] dt-bindings: display: panel: Add Ilitek ili9805 panel controller.

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the timings of the panel reset
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties
- Adjust the mipi_dsi node based on the latest patches merged into
  the mainline in the dtsi files it includes.
- Added to the series the following patches:
  - 0001 drm/bridge: Fix bridge disable logic
  - 0002 drm/bridge: Fix a use case in the bridge disable logic
  - 0003 samsung-dsim: enter display mode in the enable() callback
  - 0004 drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Dario Binacchi (4):
  drm/bridge: Fix bridge disable logic
  drm/bridge: Fix a use case in the bridge disable logic
  drm: bridge: samsung-dsim: enter display mode in the enable() callback
  drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

Michael Trimarchi (6):
  dt-bindings: display: panel: Add synaptics r63353 panel controller
  drm/panel: Add Synaptics R63353 panel driver
  dt-bindings: display: panel: Add Ilitek ili9805 panel controller
  drm/panel: Add Ilitek ILI9805 panel driver
  drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel
  arm64: dts: imx8mn-bsh-smm-s2/pro: add display setup

 .../display/panel/ilitek,ili9805.yaml |  62 +++
 .../display/panel/synaptics,r63353.yaml   |  61 +++
 MAINTAINERS   |  12 +
 .../freescale/imx8mn-bsh-smm-s2-common.dtsi   |   1 +
 .../freescale/imx8mn-bsh-smm-s2-display.dtsi  | 121 ++
 drivers/gpu/drm/bridge/samsung-dsim.c |  14 +-
 drivers/gpu/drm/drm_bridge.c  |   9 +-
 drivers/gpu/drm/panel/Kconfig |  18 +
 drivers/gpu/drm/panel/Makefile|   2 +
 drivers/gpu/drm/panel/panel-ilitek-ili9805.c  | 406 ++
 .../gpu/drm/panel/panel-synaptics-r63353.c| 363 
 11 files changed, 1062 insertions(+), 7 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
 create mode 100644 
Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mn-bsh-smm-s2-display.dtsi
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c
 create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c

-- 
2.43.0

[PATCH v4 01/10] drm/bridge: Fix bridge disable logic

[Dario Binacchi]

As explained by the comment of the fixed code, we need to find the next
bridge that hasn't set the "pre_enable_prev_first" flag to true. The code,
on the contrary, was doing the opposite.
So, the order of disabling the bridges couldn't be altered as required
by setting the "pre_enable_prev_first" flag to true.

Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter 
bridge init order")
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

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

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 30d66bee0ec6..f66bf4925dd8 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -686,7 +686,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge 
*bridge,
 */
list_for_each_entry_from(next, 
&encoder->bridge_chain,
 chain_node) {
-   if (next->pre_enable_prev_first) {
+   if (!next->pre_enable_prev_first) {
next = list_prev_entry(next, 
chain_node);
limit = next;
break;
-- 
2.43.0

[PATCH v4 02/10] drm/bridge: Fix a use case in the bridge disable logic

[Dario Binacchi]

The patch fixes the code for finding the next bridge with the
"pre_enable_prev_first" flag set to false. In case this condition is
not verified, i. e. there is no subsequent bridge with the flag set to
false, the whole bridge list is traversed, invalidating the "next"
variable.

The use of a new iteration variable (i. e. "iter") ensures that the value
of the "next" variable is not invalidated.

Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter 
bridge init order")
Co-developed-by: Michael Trimarchi 
Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/gpu/drm/drm_bridge.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index f66bf4925dd8..2e5781bf192e 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -662,7 +662,7 @@ void drm_atomic_bridge_chain_post_disable(struct drm_bridge 
*bridge,
  struct drm_atomic_state *old_state)
 {
struct drm_encoder *encoder;
-   struct drm_bridge *next, *limit;
+   struct drm_bridge *iter, *next, *limit;
 
if (!bridge)
return;
@@ -680,14 +680,15 @@ void drm_atomic_bridge_chain_post_disable(struct 
drm_bridge *bridge,
 * was enabled first, so disabled last
 */
limit = next;
+   iter = next;
 
/* Find the next bridge that has NOT requested
 * prev to be enabled first / disabled last
 */
-   list_for_each_entry_from(next, 
&encoder->bridge_chain,
+   list_for_each_entry_from(iter, 
&encoder->bridge_chain,
 chain_node) {
-   if (!next->pre_enable_prev_first) {
-   next = list_prev_entry(next, 
chain_node);
+   if (!iter->pre_enable_prev_first) {
+   next = list_prev_entry(iter, 
chain_node);
limit = next;
break;
}
-- 
2.43.0

[PATCH v4 03/10] drm: bridge: samsung-dsim: enter display mode in the enable() callback

[Dario Binacchi]

The synaptics-r63353 (panel-bridge) can only be configured in command mode.
So, samsung-dsim (bridge) must not be in display mode during the
prepare()/unprepare() of the panel-bridge. Setting the
"pre_enable_prev_first" flag to true allows the prepare() of the
panel-bridge to be called between the pre_enabled() and enabled() of the
bridge. So, the bridge can enter display mode only in the enabled().
The unprepare() of the panel-bridge is instead called between the disable()
and post_disable() of the bridge. So, the disable() must exit the display
mode (i .e. enter command mode) to allow the panel-bridge to receive DSI
commands.

samsung_dsim_atomic_pre_enable   -> command mode
r63353_panel_prepare -> send DSI commands
samsung_dsim_atomic_enable   -> enter display mode

samsung_dsim_atomic_disable  -> exit display mode (command mode)
r63353_panel_unprepare   -> send DSI commands
samsung_dsim_atomic_post_disable

Co-developed-by: Michael Trimarchi 
Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/gpu/drm/bridge/samsung-dsim.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index be5914caa17d..15bf05b2bbe4 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -1494,7 +1494,6 @@ static void samsung_dsim_atomic_pre_enable(struct 
drm_bridge *bridge,
return;
 
samsung_dsim_set_display_mode(dsi);
-   samsung_dsim_set_display_enable(dsi, true);
}
 }
 
@@ -1507,6 +1506,7 @@ static void samsung_dsim_atomic_enable(struct drm_bridge 
*bridge,
samsung_dsim_set_display_mode(dsi);
samsung_dsim_set_display_enable(dsi, true);
} else {
+   samsung_dsim_set_display_enable(dsi, true);
samsung_dsim_set_stop_state(dsi, false);
}
 
@@ -1524,6 +1524,8 @@ static void samsung_dsim_atomic_disable(struct drm_bridge 
*bridge,
if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
samsung_dsim_set_stop_state(dsi, true);
 
+   samsung_dsim_set_display_enable(dsi, false);
+
dsi->state &= ~DSIM_STATE_VIDOUT_AVAILABLE;
 }
 
@@ -1532,7 +1534,8 @@ static void samsung_dsim_atomic_post_disable(struct 
drm_bridge *bridge,
 {
struct samsung_dsim *dsi = bridge_to_dsi(bridge);
 
-   samsung_dsim_set_display_enable(dsi, false);
+   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
+   samsung_dsim_set_stop_state(dsi, true);
 
dsi->state &= ~DSIM_STATE_ENABLED;
pm_runtime_put_sync(dsi->dev);
-- 
2.43.0

[PATCH v4 05/10] dt-bindings: display: panel: Add synaptics r63353 panel controller

[Dario Binacchi]

From: Michael Trimarchi 

Add documentation for "synaptics,r63353" panel.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
Reviewed-by: Krzysztof Kozlowski 

---

(no changes since v3)

Changes in v3:
- Add 'Reviewed-by' tag of Krzysztof Kozlowski.
- Replace "synaptics,r63353" compatible with "syna,r63353", as
  required by vendor-prefixes.yaml.

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties

 .../display/panel/synaptics,r63353.yaml   | 61 +++
 1 file changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml 
b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
new file mode 100644
index ..e5617d125567
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/synaptics,r63353.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synaptics R63353 based MIPI-DSI panels
+
+maintainers:
+  - Michael Trimarchi 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  - sharp,ls068b3sx02
+  - const: syna,r63353
+
+  avdd-supply: true
+  dvdd-supply: true
+  reg: true
+
+required:
+  - compatible
+  - avdd-supply
+  - dvdd-supply
+  - reg
+  - reset-gpios
+  - port
+  - backlight
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "sharp,ls068b3sx02", "syna,r63353";
+reg = <0>;
+avdd-supply = <&avdd_display>;
+dvdd-supply = <&dvdd_display>;
+reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+backlight = <&backlight>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&mipi_dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.43.0

[PATCH v4 06/10] drm/panel: Add Synaptics R63353 panel driver

[Dario Binacchi]

From: Michael Trimarchi 

The LS068B3SX02 panel is based on the Synaptics R63353 Controller.
Add a driver for it.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

Changes in v4:
- Set the reset gpio to low in a single operation
- Remove duplicated code for prepare/unprepare callbacks

Changes in v2:
- Adjust the timings of the panel reset

 MAINTAINERS   |   6 +
 drivers/gpu/drm/panel/Kconfig |   9 +
 drivers/gpu/drm/panel/Makefile|   1 +
 .../gpu/drm/panel/panel-synaptics-r63353.c| 363 ++
 4 files changed, 379 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-synaptics-r63353.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 788be9ab5b73..b82dc141d209 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6874,6 +6874,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/ste,mcde.yaml
 F: drivers/gpu/drm/mcde/
 
+DRM DRIVER FOR SYNAPTICS R63353 PANELS
+M: Michael Trimarchi 
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/synaptics,r63353.yaml
+F: drivers/gpu/drm/panel/panel-synaptics-r63353.c
+
 DRM DRIVER FOR TI DLPC3433 MIPI DSI TO DMD BRIDGE
 M: Jagan Teki 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 99e14dc212ec..d018702be3dc 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -735,6 +735,15 @@ config DRM_PANEL_SITRONIX_ST7789V
  Say Y here if you want to enable support for the Sitronix
  ST7789V controller for 240x320 LCD panels
 
+config DRM_PANEL_SYNAPTICS_R63353
+   tristate "Synaptics R63353-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Synaptics R63353 controller.
+
 config DRM_PANEL_SONY_ACX565AKM
tristate "Sony ACX565AKM panel"
depends on GPIOLIB && OF && SPI
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d10c3de51c6d..f267d932c2b5 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_DRM_PANEL_SHARP_LS060T1SX01) += 
panel-sharp-ls060t1sx01.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += panel-sitronix-st7701.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
 obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
+obj-$(CONFIG_DRM_PANEL_SYNAPTICS_R63353) += panel-synaptics-r63353.o
 obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
 obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
 obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) += 
panel-sony-tulip-truly-nt35521.o
diff --git a/drivers/gpu/drm/panel/panel-synaptics-r63353.c 
b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
new file mode 100644
index ..0a3c2a3d5998
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-synaptics-r63353.c
@@ -0,0 +1,363 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Synaptics R63353 Controller driver
+ *
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define R63353_INSTR(...) { \
+   .len = sizeof((u8[]) {__VA_ARGS__}), \
+   .data = (u8[]){__VA_ARGS__} \
+   }
+
+struct r63353_instr {
+   size_t len;
+   const u8 *data;
+};
+
+static const struct r63353_instr sharp_ls068b3sx02_init[] = {
+   R63353_INSTR(0x51, 0xff),
+   R63353_INSTR(0x53, 0x0c),
+   R63353_INSTR(0x55, 0x00),
+   R63353_INSTR(0x84, 0x00),
+   R63353_INSTR(0x29),
+};
+
+struct r63353_desc {
+   const char *name;
+   const struct r63353_instr *init;
+   const size_t init_length;
+   const struct drm_display_mode *mode;
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct r63353_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct gpio_desc *reset_gpio;
+   struct regulator *dvdd;
+   struct regulator *avdd;
+
+   struct r63353_desc *pdata;
+};
+
+static inline struct r63353_panel *to_r63353_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct r63353_panel, base);
+}
+
+static int r63353_panel_power_on(struct r63353_panel *rpanel)
+{
+   struct mipi_dsi_device *dsi = rpanel->dsi;
+   struct device *dev = &dsi->dev;
+   int ret;
+
+   ret = regulator_enable(rpanel->avdd);
+   if (ret) {
+   dev_err(dev, "Failed to enable avdd regulator (%d)\n", ret);
+   return ret;
+   }
+
+   usleep_range(15000, 25000);
+
+   ret = regulator_enable(rpanel->dvdd);
+   if (ret) {
+   dev_err(dev, "Failed to enable dvdd regulator

[PATCH v4 07/10] dt-bindings: display: panel: Add Ilitek ili9805 panel controller

[Dario Binacchi]

From: Michael Trimarchi 

Add documentation for "ilitek,ili9805" panel.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

(no changes since v3)

Changes in v3:
- Drop power-supply

Changes in v2:
- Add $ref to panel-common.yaml
- Drop port, reset-gpios, and backlight
- Set port and backlight ad required
- Replace additionalProperties with unevaluatedProperties

 .../display/panel/ilitek,ili9805.yaml | 62 +++
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml

diff --git 
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml 
b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
new file mode 100644
index ..f4f91f93f490
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/ilitek,ili9805.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Ilitek ILI9805 based MIPI-DSI panels
+
+maintainers:
+  - Michael Trimarchi 
+
+allOf:
+  - $ref: panel-common.yaml#
+
+properties:
+  compatible:
+items:
+  - enum:
+  - giantplus,gpm1790a0
+  - tianma,tm041xdhg01
+  - const: ilitek,ili9805
+
+  avdd-supply: true
+  dvdd-supply: true
+  reg: true
+
+required:
+  - compatible
+  - avdd-supply
+  - dvdd-supply
+  - reg
+  - reset-gpios
+  - port
+  - backlight
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+
+dsi {
+#address-cells = <1>;
+#size-cells = <0>;
+
+panel@0 {
+compatible = "giantplus,gpm1790a0", "ilitek,ili9805";
+reg = <0>;
+avdd-supply = <&avdd_display>;
+dvdd-supply = <&dvdd_display>;
+reset-gpios = <&r_pio 0 5 GPIO_ACTIVE_LOW>; /* PL05 */
+backlight = <&backlight>;
+
+port {
+panel_in: endpoint {
+remote-endpoint = <&mipi_dsi_out>;
+};
+};
+};
+};
+
+...
-- 
2.43.0

[PATCH v4 04/10] drm: bridge: samsung-dsim: complete the CLKLANE_STOP setting

[Dario Binacchi]

The patch completes the setting of CLKLANE_STOP for the imx8mn and imx8mp
platforms (i. e. not exynos).

Co-developed-by: Michael Trimarchi 
Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 drivers/gpu/drm/bridge/samsung-dsim.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/samsung-dsim.c 
b/drivers/gpu/drm/bridge/samsung-dsim.c
index 15bf05b2bbe4..13f181c99d7e 100644
--- a/drivers/gpu/drm/bridge/samsung-dsim.c
+++ b/drivers/gpu/drm/bridge/samsung-dsim.c
@@ -96,6 +96,7 @@
 #define DSIM_MFLUSH_VS BIT(29)
 /* This flag is valid only for exynos3250/3472/5260/5430 */
 #define DSIM_CLKLANE_STOP  BIT(30)
+#define DSIM_NON_CONTINUOUS_CLKLANEBIT(31)
 
 /* DSIM_ESCMODE */
 #define DSIM_TX_TRIGGER_RSTBIT(4)
@@ -945,8 +946,12 @@ static int samsung_dsim_init_link(struct samsung_dsim *dsi)
 * power consumption.
 */
if (driver_data->has_clklane_stop &&
-   dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS)
+   dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) {
+   if (!samsung_dsim_hw_is_exynos(dsi->plat_data->hw_type))
+   reg |= DSIM_NON_CONTINUOUS_CLKLANE;
+
reg |= DSIM_CLKLANE_STOP;
+   }
samsung_dsim_write(dsi, DSIM_CONFIG_REG, reg);
 
lanes_mask = BIT(dsi->lanes) - 1;
-- 
2.43.0

[PATCH v4 08/10] drm/panel: Add Ilitek ILI9805 panel driver

[Dario Binacchi]

From: Michael Trimarchi 

The GPM1790A0 panel is based on the Ilitek ILI9805 Controller.
Add a driver for it.

Signed-off-by: Michael Trimarchi 
Signed-off-by: Dario Binacchi 

---

Changes in v4:
- Remove duplicated code for prepare/unprepare callbacks

 MAINTAINERS  |   6 +
 drivers/gpu/drm/panel/Kconfig|   9 +
 drivers/gpu/drm/panel/Makefile   |   1 +
 drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 353 +++
 4 files changed, 369 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-ilitek-ili9805.c

diff --git a/MAINTAINERS b/MAINTAINERS
index b82dc141d209..4dccc72a0ed6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6646,6 +6646,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
 F: Documentation/devicetree/bindings/display/ilitek,ili9486.yaml
 F: drivers/gpu/drm/tiny/ili9486.c
 
+DRM DRIVER FOR ILITEK ILI9805 PANELS
+M: Michael Trimarchi 
+S: Maintained
+F: Documentation/devicetree/bindings/display/panel/ilitek,ili9805.yaml
+F: drivers/gpu/drm/panel/panel-ilitek-ili9805.c
+
 DRM DRIVER FOR JADARD JD9365DA-H3 MIPI-DSI LCD PANELS
 M: Jagan Teki 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index d018702be3dc..dad938cf6dec 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -194,6 +194,15 @@ config DRM_PANEL_ILITEK_ILI9341
  QVGA (240x320) RGB panels. support serial & parallel rgb
  interface.
 
+config DRM_PANEL_ILITEK_ILI9805
+   tristate "Ilitek ILI9805-based panels"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y if you want to enable support for panels based on the
+ Ilitek ILI9805 controller.
+
 config DRM_PANEL_ILITEK_ILI9881C
tristate "Ilitek ILI9881C-based panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f267d932c2b5..d94a644d0a6c 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += 
panel-feiyang-fy07024di26a30d
 obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
+obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9881C) += panel-ilitek-ili9881c.o
 obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9882T) += panel-ilitek-ili9882t.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_EJ030NA) += panel-innolux-ej030na.o
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
new file mode 100644
index ..e36984b46e14
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -0,0 +1,353 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 BSH Hausgerate GmbH
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+
+#define ILI9805_EXTCMD_CMD_SET_ENABLE_REG  (0xff)
+#define ILI9805_SETEXTC_PARAMETER1 (0xff)
+#define ILI9805_SETEXTC_PARAMETER2 (0x98)
+#define ILI9805_SETEXTC_PARAMETER3 (0x05)
+
+#define ILI9805_INSTR(_delay, ...) { \
+   .delay = (_delay), \
+   .len = sizeof((u8[]) {__VA_ARGS__}), \
+   .data = (u8[]){__VA_ARGS__} \
+   }
+
+struct ili9805_instr {
+   size_t len;
+   const u8 *data;
+   u32 delay;
+};
+
+struct ili9805_desc {
+   const char *name;
+   const struct ili9805_instr *init;
+   const size_t init_length;
+   const struct drm_display_mode *mode;
+   u32 width_mm;
+   u32 height_mm;
+};
+
+struct ili9805 {
+   struct drm_panelpanel;
+   struct mipi_dsi_device  *dsi;
+   const struct ili9805_desc   *desc;
+
+   struct regulator*dvdd;
+   struct regulator*avdd;
+   struct gpio_desc*reset_gpio;
+};
+
+static const struct ili9805_instr gpm1780a0_init[] = {
+   ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG, 
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+   ILI9805_INSTR(100, 0xFD, 0x0F, 0x10, 0x44, 0x00),
+   ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x00,
+ 0x00, 0x30, 0x00, 0x00, 0x30, 0x00, 0x00),
+   ILI9805_INSTR(0, 0xB8, 0x62),
+   ILI9805_INSTR(0, 0xF1, 0x00),
+   ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+   ILI9805_INSTR(0, 0xF3, 0x60, 0x83, 0x04),
+   ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+   ILI9805_INSTR(0, 0xEB, 0x08, 0x0F),
+   ILI9805_INSTR(0, 0xe0, 0x00, 0x08, 0x0d, 0x0e, 0x0e, 0x0d, 0x0a, 0x08, 
0x04,
+ 0x08, 0

[PATCH v4 09/10] drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panel

[Dario Binacchi]

From: Michael Trimarchi 

Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller.

Add this panel's initialzation sequence and timing to ILI9805 driver.

Signed-off-by: Michael Trimarchi 
Reviewed-by: Neil Armstrong 

Signed-off-by: Dario Binacchi 
---

Changes in v4:
- Add Reviewed-by tag of Neil Armstrong

 drivers/gpu/drm/panel/panel-ilitek-ili9805.c | 53 
 1 file changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c 
b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
index e36984b46e14..5054d1a2b2f5 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9805.c
@@ -87,6 +87,36 @@ static const struct ili9805_instr gpm1780a0_init[] = {
ILI9805_INSTR(0, 0xB9, 0x02, 0x00),
 };
 
+static const struct ili9805_instr tm041xdhg01_init[] = {
+   ILI9805_INSTR(100, ILI9805_EXTCMD_CMD_SET_ENABLE_REG, 
ILI9805_SETEXTC_PARAMETER1,
+ ILI9805_SETEXTC_PARAMETER2, ILI9805_SETEXTC_PARAMETER3),
+   ILI9805_INSTR(100, 0xFD, 0x0F, 0x13, 0x44, 0x00),
+   ILI9805_INSTR(0, 0xf8, 0x18, 0x02, 0x02, 0x18, 0x02, 0x02, 0x30, 0x01,
+ 0x01, 0x30, 0x01, 0x01, 0x30, 0x01, 0x01),
+   ILI9805_INSTR(0, 0xB8, 0x74),
+   ILI9805_INSTR(0, 0xF1, 0x00),
+   ILI9805_INSTR(0, 0xF2, 0x00, 0x58, 0x40),
+   ILI9805_INSTR(0, 0xFC, 0x04, 0x0F, 0x01),
+   ILI9805_INSTR(0, 0xEB, 0x08, 0x0F),
+   ILI9805_INSTR(0, 0xe0, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08, 
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+   ILI9805_INSTR(0, 0xe1, 0x01, 0x0d, 0x15, 0x0e, 0x0f, 0x0f, 0x0b, 0x08, 
0x04,
+ 0x07, 0x0a, 0x0d, 0x0c, 0x15, 0x0f, 0x08),
+   ILI9805_INSTR(10, 0xc1, 0x15, 0x03, 0x03, 0x31),
+   ILI9805_INSTR(10, 0xB1, 0x00, 0x12, 0x14),
+   ILI9805_INSTR(10, 0xB4, 0x02),
+   ILI9805_INSTR(0, 0xBB, 0x14, 0x55),
+   ILI9805_INSTR(0, MIPI_DCS_SET_ADDRESS_MODE, 0x0a),
+   ILI9805_INSTR(0, MIPI_DCS_SET_PIXEL_FORMAT, 0x77),
+   ILI9805_INSTR(0, 0x20),
+   ILI9805_INSTR(0, 0xB0, 0x00),
+   ILI9805_INSTR(0, 0xB6, 0x01),
+   ILI9805_INSTR(0, 0xc2, 0x11),
+   ILI9805_INSTR(0, 0x51, 0xFF),
+   ILI9805_INSTR(0, 0x53, 0x24),
+   ILI9805_INSTR(0, 0x55, 0x00),
+};
+
 static inline struct ili9805 *panel_to_ili9805(struct drm_panel *panel)
 {
return container_of(panel, struct ili9805, panel);
@@ -227,6 +257,20 @@ static const struct drm_display_mode gpm1780a0_timing = {
.vtotal = 480 + 2 + 4 + 10,
 };
 
+static const struct drm_display_mode tm041xdhg01_timing = {
+   .clock = 26227,
+
+   .hdisplay = 480,
+   .hsync_start = 480 + 10,
+   .hsync_end = 480 + 10 + 2,
+   .htotal = 480 + 10 + 2 + 36,
+
+   .vdisplay = 768,
+   .vsync_start = 768 + 2,
+   .vsync_end = 768 + 10 + 4,
+   .vtotal = 768 + 2 + 4 + 10,
+};
+
 static int ili9805_get_modes(struct drm_panel *panel,
  struct drm_connector *connector)
 {
@@ -331,8 +375,17 @@ static const struct ili9805_desc gpm1780a0_desc = {
.height_mm = 65,
 };
 
+static const struct ili9805_desc tm041xdhg01_desc = {
+   .init = tm041xdhg01_init,
+   .init_length = ARRAY_SIZE(tm041xdhg01_init),
+   .mode = &tm041xdhg01_timing,
+   .width_mm = 42,
+   .height_mm = 96,
+};
+
 static const struct of_device_id ili9805_of_match[] = {
{ .compatible = "giantplus,gpm1790a0", .data = &gpm1780a0_desc },
+   { .compatible = "tianma,tm041xdhg01", .data = &tm041xdhg01_desc },
{ }
 };
 MODULE_DEVICE_TABLE(of, ili9805_of_match);
-- 
2.43.0

Re: [PATCH v2 1/2] drm/atomic-helper: rename drm_atomic_helper_check_wb_encoder_state

[kernel test robot]

Hi Dmitry,

kernel test robot noticed the following build warnings:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.7-rc4 next-20231205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-atomic-helper-rename-drm_atomic_helper_check_wb_encoder_state/20231205-103552
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231205023150.1581875-2-dmitry.baryshkov%40linaro.org
patch subject: [PATCH v2 1/2] drm/atomic-helper: rename 
drm_atomic_helper_check_wb_encoder_state
config: i386-buildonly-randconfig-003-20231205 
(https://download.01.org/0day-ci/archive/20231205/202312051810.e0qczpby-...@intel.com/config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231205/202312051810.e0qczpby-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202312051810.e0qczpby-...@intel.com/

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_atomic_helper.c:811: warning: Function parameter or 
>> member 'wb_conn' not described in 
>> 'drm_atomic_helper_check_wb_connector_state'
>> drivers/gpu/drm/drm_atomic_helper.c:811: warning: Excess function parameter 
>> 'connector' description in 'drm_atomic_helper_check_wb_connector_state'


vim +811 drivers/gpu/drm/drm_atomic_helper.c

623369e533e8a5 Daniel Vetter2014-09-16  796  
254fe9c106ed69 Igor Torrente2022-09-05  797  /**
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  798   * 
drm_atomic_helper_check_wb_connector_state() - Check writeback connector state
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  799   * @connector: corresponding 
connector
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  800   * @state: the driver state 
object
254fe9c106ed69 Igor Torrente2022-09-05  801   *
254fe9c106ed69 Igor Torrente2022-09-05  802   * Checks if the writeback 
connector state is valid, and returns an error if it
254fe9c106ed69 Igor Torrente2022-09-05  803   * isn't.
254fe9c106ed69 Igor Torrente2022-09-05  804   *
254fe9c106ed69 Igor Torrente2022-09-05  805   * RETURNS:
254fe9c106ed69 Igor Torrente2022-09-05  806   * Zero for success or -errno
254fe9c106ed69 Igor Torrente2022-09-05  807   */
254fe9c106ed69 Igor Torrente2022-09-05  808  int
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  809  
drm_atomic_helper_check_wb_connector_state(struct drm_writeback_connector 
*wb_conn,
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  810 
   struct drm_atomic_state *state)
254fe9c106ed69 Igor Torrente2022-09-05 @811  {
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  812 struct 
drm_connector_state *conn_state =
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  813 
drm_atomic_get_new_connector_state(state, &wb_conn->base);
254fe9c106ed69 Igor Torrente2022-09-05  814 struct 
drm_writeback_job *wb_job = conn_state->writeback_job;
254fe9c106ed69 Igor Torrente2022-09-05  815 struct 
drm_property_blob *pixel_format_blob;
254fe9c106ed69 Igor Torrente2022-09-05  816 struct drm_framebuffer 
*fb;
254fe9c106ed69 Igor Torrente2022-09-05  817 size_t i, nformats;
254fe9c106ed69 Igor Torrente2022-09-05  818 u32 *formats;
254fe9c106ed69 Igor Torrente2022-09-05  819  
254fe9c106ed69 Igor Torrente2022-09-05  820 if (!wb_job || 
!wb_job->fb)
254fe9c106ed69 Igor Torrente2022-09-05  821 return 0;
254fe9c106ed69 Igor Torrente2022-09-05  822  
254fe9c106ed69 Igor Torrente2022-09-05  823 pixel_format_blob = 
wb_job->connector->pixel_formats_blob_ptr;
254fe9c106ed69 Igor Torrente2022-09-05  824 nformats = 
pixel_format_blob->length / sizeof(u32);
254fe9c106ed69 Igor Torrente2022-09-05  825 formats = 
pixel_format_blob->data;
254fe9c106ed69 Igor Torrente2022-09-05  826 fb = wb_job->fb;
254fe9c106ed69 Igor Torrente2022-09-05  827  
254fe9c106ed69 Igor Torrente2022-09-05  828 for (i = 0; i < 
nformats; i++)
254fe9c106ed69 Igor Torrente2022-09-05  829 if 
(fb->format->format == formats[i])
254fe9c106ed69 Igor Torrente2022-09-05  830 return 
0;
254fe9c106ed69 Igor Torrente2022-09-05  831  
d538670e1a27f5 Dmitry Baryshkov 2023-12-05  832 
drm_dbg_kms(wb_conn->base.dev, "Invalid pixel f

Re: [PATCH 5/6] drm/amdgpu: Auto-validate DMABuf imports in compute VMs

[kernel test robot]

Hi Felix,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20231201]
[cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos/exynos-drm-next 
drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip 
linus/master v6.7-rc3 v6.7-rc2 v6.7-rc1 v6.7-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Felix-Kuehling/drm-amdkfd-Export-DMABufs-from-KFD-using-GEM-handles/20231202-073833
base:   next-20231201
patch link:
https://lore.kernel.org/r/20231201233438.1709981-5-Felix.Kuehling%40amd.com
patch subject: [PATCH 5/6] drm/amdgpu: Auto-validate DMABuf imports in compute 
VMs
config: powerpc-randconfig-001-20231203 
(https://download.01.org/0day-ci/archive/20231205/202312051955.xacucivn-...@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231205/202312051955.xacucivn-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202312051955.xacucivn-...@intel.com/

All errors (new ones prefixed by >>):

   powerpc-linux-ld: drivers/gpu/drm/amd/amdgpu/amdgpu_gem.o: in function 
`amdgpu_gem_object_open':
>> amdgpu_gem.c:(.text.amdgpu_gem_object_open+0x150): undefined reference to 
>> `amdgpu_amdkfd_bo_validate_and_fence'

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH] drm: renesas: shmobile: Call drm_helper_force_disable_all() at shutdown time

[Geert Uytterhoeven]

From: Douglas Anderson 

Based on grepping through the source code, this driver appears to be
missing a call to drm_atomic_helper_shutdown() at system shutdown time.
This is important because drm_helper_force_disable_all() will cause
panels to get disabled cleanly which may be important for their power
sequencing.  Future changes will remove any custom powering off in
individual panel drivers so the DRM drivers need to start getting this
right.

The fact that we should call drm_atomic_helper_shutdown() in the case of
OS shutdown comes straight out of the kernel doc "driver instance
overview" in drm_drv.c.

Suggested-by: Maxime Ripard 
Signed-off-by: Douglas Anderson 
Link: 
https://lore.kernel.org/r/20230901164111.RFT.15.Iaf638a1d4c8b3c307a6192efabb4cbb06b195f15@changeid
[geert: s/drm_helper_force_disable_all/drm_atomic_helper_shutdown/]
[geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
Signed-off-by: Geert Uytterhoeven 
---
Tested on Atmark Techno Armadillo-800-EVA, where the PWM instance
driving the backlight is now stopped on shutdown.
Panel-simple does print two new warnings:

+panel-simple panel: Skipping disable of already disabled panel
+panel-simple panel: Skipping unprepare of already unprepared panel
 reboot: System halted
---
 drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c 
b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
index bd16d4780c6436c3..a15162be26f259a4 100644
--- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
+++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
@@ -171,6 +171,13 @@ static void shmob_drm_remove(struct platform_device *pdev)
drm_kms_helper_poll_fini(ddev);
 }
 
+static void shmob_drm_shutdown(struct platform_device *pdev)
+{
+   struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
+
+   drm_atomic_helper_shutdown(&sdev->ddev);
+}
+
 static int shmob_drm_probe(struct platform_device *pdev)
 {
struct shmob_drm_platform_data *pdata = pdev->dev.platform_data;
@@ -274,6 +281,7 @@ static const struct of_device_id shmob_drm_of_table[] 
__maybe_unused = {
 static struct platform_driver shmob_drm_platform_driver = {
.probe  = shmob_drm_probe,
.remove_new = shmob_drm_remove,
+   .shutdown   = shmob_drm_shutdown,
.driver = {
.name   = "shmob-drm",
.of_match_table = of_match_ptr(shmob_drm_of_table),
-- 
2.34.1

Re: [v3 3/6] drm/vs: Register DRM device

[Dmitry Baryshkov]

On Mon, 4 Dec 2023 at 14:33, Keith Zhao  wrote:
>
> Implement drm device registration interface
>
> Signed-off-by: Keith Zhao 
> ---
>  MAINTAINERS  |   1 +
>  drivers/gpu/drm/Kconfig  |   2 +
>  drivers/gpu/drm/Makefile |   1 +
>  drivers/gpu/drm/verisilicon/Kconfig  |  13 +
>  drivers/gpu/drm/verisilicon/Makefile |   6 +
>  drivers/gpu/drm/verisilicon/vs_drv.c | 316 +++
>  drivers/gpu/drm/verisilicon/vs_drv.h |  42 +++
>  drivers/gpu/drm/verisilicon/vs_modeset.c |  39 +++
>  drivers/gpu/drm/verisilicon/vs_modeset.h |  10 +
>  9 files changed, 430 insertions(+)
>  create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
>  create mode 100644 drivers/gpu/drm/verisilicon/Makefile
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_modeset.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7caaadb83f3f..8dc9ebfe4605 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6887,6 +6887,7 @@ L:dri-devel@lists.freedesktop.org
>  S: Maintained
>  T: git git://anongit.freedesktop.org/drm/drm-misc
>  F: Documentation/devicetree/bindings/display/starfive/
> +F: drivers/gpu/drm/verisilicon/
>
>  DRM DRIVER FOR TI DLPC3433 MIPI DSI TO DMD BRIDGE
>  M: Jagan Teki 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 3eee8636f847..e8d53c2e7c86 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -394,6 +394,8 @@ source "drivers/gpu/drm/solomon/Kconfig"
>
>  source "drivers/gpu/drm/sprd/Kconfig"
>
> +source "drivers/gpu/drm/verisilicon/Kconfig"
> +
>  config DRM_HYPERV
> tristate "DRM Support for Hyper-V synthetic video device"
> depends on DRM && PCI && MMU && HYPERV
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 8e1bde059170..29e04acded06 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -198,3 +198,4 @@ obj-$(CONFIG_DRM_HYPERV) += hyperv/
>  obj-y  += solomon/
>  obj-$(CONFIG_DRM_SPRD) += sprd/
>  obj-$(CONFIG_DRM_LOONGSON) += loongson/
> +obj-$(CONFIG_DRM_VERISILICON) += verisilicon/
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig 
> b/drivers/gpu/drm/verisilicon/Kconfig
> new file mode 100644
> index ..e10fa97635aa
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -0,0 +1,13 @@
> +# SPDX-License-Identifier: GPL-2.0
> +config DRM_VERISILICON
> +   tristate "DRM Support for VeriSilicon"
> +   depends on DRM
> +   select DRM_KMS_HELPER
> +   select DRM_GEM_DMA_HELPER
> +   select CMA
> +   select DMA_CMA
> +   help
> + Choose this option if you have a VeriSilicon soc chipset.
> + This driver provides VeriSilicon kernel mode
> + setting and buffer management. It does not
> + provide 2D or 3D acceleration.
> diff --git a/drivers/gpu/drm/verisilicon/Makefile 
> b/drivers/gpu/drm/verisilicon/Makefile
> new file mode 100644
> index ..d785a1dfaa7f
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +vs_drm-objs := vs_drv.o \
> +  vs_modeset.o
> +
> +obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c 
> b/drivers/gpu/drm/verisilicon/vs_drv.c
> new file mode 100644
> index ..4fb1f29ef84b
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_drv.c
> @@ -0,0 +1,316 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "vs_drv.h"
> +#include "vs_modeset.h"
> +
> +#define DRV_NAME   "verisilicon"
> +#define DRV_DESC   "Verisilicon DRM driver"
> +#define DRV_DATE   "20230516"
> +#define DRV_MAJOR  1
> +#define DRV_MINOR  0
> +
> +static int vs_gem_dumb_create(struct drm_file *file, struct drm_device *dev,
> + struct drm_mode_create_dumb *args)
> +{
> +   struct vs_drm_device *priv = to_vs_drm_private(dev);
> +   unsigned int pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> +
> +   args->pitch = ALIGN(pitch, priv->pitch_alignment);
> +   return drm_gem_dma_dumb_create_internal(file, dev, args);
> +}
> +
> +DEFINE_DRM_GEM_FOPS(vs_drm_fops);
> +
> +static struct drm_driver vs_drm_driver = {
> +   .driver_features= DRIVER_MODESET | DRIVER_ATOMIC | DRIVER_GEM,
> +
> +   DRM_GEM_DMA_DRIVER_OPS_WITH_DUMB_CREATE(vs_gem_dumb_create),
> +
> +   .fops   = &vs_drm_fops,
> +   .name

Re: [PATCH v18 04/26] drm/shmem-helper: Refactor locked/unlocked functions

[Dmitry Osipenko]

On 12/4/23 15:55, Maxime Ripard wrote:
>> Okay, that means s/_locked/_nolock/ in drm_gem_shmem_helpers.{c,h}, I
>> guess.

DRM subsys and majority of kernel uses common _locked postfix. We should
retain the old naming scheme by using _locked() in DRM. It's not
worthwhile changing the name to a much less popular variant for a no
good reason.

Maxime, are you okay with keeping the _locked name?

-- 
Best regards,
Dmitry

Re: Kunit drm_test_check_plane_state: EXPECTATION FAILED at drivers/gpu/drm/tests/drm_plane_helper_test.c:123

[Maxime Ripard]

On Tue, Dec 05, 2023 at 12:05:02PM +0300, Dan Carpenter wrote:
> On Tue, Dec 05, 2023 at 09:37:05AM +0100, Maxime Ripard wrote:
> > Hi Naresh,
> > 
> > Thanks for the report
> > 
> > On Mon, Dec 04, 2023 at 11:05:36PM +0530, Naresh Kamboju wrote:
> > > The Kunit drm_plane_helper failed on all devices running Linux 
> > > next-20231204
> > > 
> > > ## Test Regressions (compared to next-20231201)
> > > * qemu-armv7, kunit and
> > > * x86, kunit
> > >   - drm_test_check_invalid_plane_state_downscaling_invalid
> > >   - drm_test_check_invalid_plane_state_drm_plane_helper
> > >   - drm_test_check_invalid_plane_state_drm_test_check_invalid_plane_state
> > >   - drm_test_check_invalid_plane_state_positioning_invalid
> > >   - drm_test_check_invalid_plane_state_upscaling_invalid
> > >   - drm_test_check_plane_state_clipping_rotate_reflect
> > >   - drm_test_check_plane_state_clipping_simple
> > >   - drm_test_check_plane_state_downscaling
> > >   - drm_test_check_plane_state_drm_test_check_plane_state
> > >   - drm_test_check_plane_state_positioning_simple
> > >   - drm_test_check_plane_state_rounding1
> > >   - drm_test_check_plane_state_rounding2
> > >   - drm_test_check_plane_state_rounding3
> > >   - drm_test_check_plane_state_rounding4
> > >   - drm_test_check_plane_state_upscaling
> > 
> > I found the source of failure to be f1e75da5364e ("drm/atomic: Loosen FB
> > atomic checks").
> > 
> > Fortunately for us, it's already been reverted yesterday for some
> > unrelated reason, so it should be fixed in next-20231205 onward.
> 
> Sorry, that's a bummer that these patches were reverted.  :(  The whole
> episode was a bit unfortunate...
> 
> Qualcom has been working on those patches for a year.  They must not be
> using kunit testing as part of their QC...  It's some kind of
> communication failure on our part.

That's definitely a communication failure, but that's mostly on us :)

The reason these patches were reverted was completely unrelated to the
kunit failures here: it failed the basic requirement we have on
intel-gpu-tools tests and open-source userspace examples for new uAPIs.

So whether or not kunit tests would have passed, these patches were
applied due to inattention and would have been reverted anyway

Maxime


signature.asc
Description: PGP signature

Re: [RFT PATCH v2 1/4] drm/msm/dpu: enable writeback on SM8150

[kernel test robot]

Hi Dmitry,

kernel test robot noticed the following build errors:

[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.7-rc4 next-20231205]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Dmitry-Baryshkov/drm-msm-dpu-enable-writeback-on-SM8150/20231203-083350
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20231203003203.1293087-2-dmitry.baryshkov%40linaro.org
patch subject: [RFT PATCH v2 1/4] drm/msm/dpu: enable writeback on SM8150
config: i386-buildonly-randconfig-001-20231203 
(https://download.01.org/0day-ci/archive/20231205/202312051918.xcpf4xi6-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): 
(https://download.01.org/0day-ci/archive/20231205/202312051918.xcpf4xi6-...@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot 
| Closes: 
https://lore.kernel.org/oe-kbuild-all/202312051918.xcpf4xi6-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c:658:
>> drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h:299:29: error: 
>> 'WB_SDM845_MASK' undeclared here (not in a function); did you mean 
>> 'WB_SM8250_MASK'?
 299 | .features = WB_SDM845_MASK,
 | ^~
 | WB_SM8250_MASK


vim +299 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h

   294  
   295  static const struct dpu_wb_cfg sm8150_wb[] = {
   296  {
   297  .name = "wb_2", .id = WB_2,
   298  .base = 0x65000, .len = 0x2c8,
 > 299  .features = WB_SDM845_MASK,
   300  .format_list = wb2_formats,
   301  .num_formats = ARRAY_SIZE(wb2_formats),
   302  .clk_ctrl = DPU_CLK_CTRL_WB2,
   303  .xin_id = 6,
   304  .vbif_idx = VBIF_RT,
   305  .maxlinewidth = 4096,
   306  .intr_wb_done = DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 4),
   307  },
   308  };
   309  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH RESEND] drm/atomic-helper: rename drm_atomic_helper_check_wb_encoder_state

[Maxime Ripard]

On Tue, Dec 05, 2023 at 03:37:15AM +0200, Dmitry Baryshkov wrote:
> On 04/12/2023 10:38, Maxime Ripard wrote:
> > On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> > > The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> > > encoder for anything other than getting the drm_device instance. The
> > > function's description talks about checking the writeback connector
> > > state, not the encoder state. Moreover, there is no such thing as an
> > > encoder state, encoders generally do not have a state on their own.
> > > 
> > > Drop the first argument and rename the function to
> > > drm_atomic_helper_check_wb_connector_state().
> > > 
> > > Signed-off-by: Dmitry Baryshkov 
> > > ---
> > > 
> > > Resending, no reaction for two months
> > > 
> > > ---
> > >   drivers/gpu/drm/drm_atomic_helper.c   | 10 --
> > >   drivers/gpu/drm/vkms/vkms_writeback.c |  2 +-
> > >   include/drm/drm_atomic_helper.h   |  3 +--
> > >   3 files changed, 6 insertions(+), 9 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > index 2444fc33dd7c..d69591381f00 100644
> > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > @@ -795,8 +795,7 @@ drm_atomic_helper_check_modeset(struct drm_device 
> > > *dev,
> > >   EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > >   /**
> > > - * drm_atomic_helper_check_wb_encoder_state() - Check writeback encoder 
> > > state
> > > - * @encoder: encoder state to check
> > > + * drm_atomic_helper_check_wb_connector_state() - Check writeback 
> > > connector state
> > >* @conn_state: connector state to check
> > >*
> > >* Checks if the writeback connector state is valid, and returns an 
> > > error if it
> > > @@ -806,8 +805,7 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > >* Zero for success or -errno
> > >*/
> > >   int
> > > -drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
> > > -  struct drm_connector_state *conn_state)
> > > +drm_atomic_helper_check_wb_connector_state(struct drm_connector_state 
> > > *conn_state)
> > 
> > AFAIK, all the helpers take the object as first argument, so I'm fine
> > with the name change but it should take a drm_connector too. And ideally
> > a drm_atomic_state pointer instead of drm_connector_state too.
> 
> I think we then might take even further step and pass
> drm_writeback_connector to this function. I'll send this as a part of v2.

... Which is still not the usual function prototype for atomic_check
helpers.

Maxime


signature.asc
Description: PGP signature

Re: [PATCH RESEND] drm/atomic-helper: rename drm_atomic_helper_check_wb_encoder_state

[Dmitry Baryshkov]

On Tue, 5 Dec 2023 at 13:48, Maxime Ripard  wrote:
>
> On Tue, Dec 05, 2023 at 03:37:15AM +0200, Dmitry Baryshkov wrote:
> > On 04/12/2023 10:38, Maxime Ripard wrote:
> > > On Sat, Dec 02, 2023 at 12:07:49AM +0200, Dmitry Baryshkov wrote:
> > > > The drm_atomic_helper_check_wb_encoder_state() function doesn't use
> > > > encoder for anything other than getting the drm_device instance. The
> > > > function's description talks about checking the writeback connector
> > > > state, not the encoder state. Moreover, there is no such thing as an
> > > > encoder state, encoders generally do not have a state on their own.
> > > >
> > > > Drop the first argument and rename the function to
> > > > drm_atomic_helper_check_wb_connector_state().
> > > >
> > > > Signed-off-by: Dmitry Baryshkov 
> > > > ---
> > > >
> > > > Resending, no reaction for two months
> > > >
> > > > ---
> > > >   drivers/gpu/drm/drm_atomic_helper.c   | 10 --
> > > >   drivers/gpu/drm/vkms/vkms_writeback.c |  2 +-
> > > >   include/drm/drm_atomic_helper.h   |  3 +--
> > > >   3 files changed, 6 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > index 2444fc33dd7c..d69591381f00 100644
> > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > @@ -795,8 +795,7 @@ drm_atomic_helper_check_modeset(struct drm_device 
> > > > *dev,
> > > >   EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > > >   /**
> > > > - * drm_atomic_helper_check_wb_encoder_state() - Check writeback 
> > > > encoder state
> > > > - * @encoder: encoder state to check
> > > > + * drm_atomic_helper_check_wb_connector_state() - Check writeback 
> > > > connector state
> > > >* @conn_state: connector state to check
> > > >*
> > > >* Checks if the writeback connector state is valid, and returns an 
> > > > error if it
> > > > @@ -806,8 +805,7 @@ EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
> > > >* Zero for success or -errno
> > > >*/
> > > >   int
> > > > -drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
> > > > -  struct drm_connector_state 
> > > > *conn_state)
> > > > +drm_atomic_helper_check_wb_connector_state(struct drm_connector_state 
> > > > *conn_state)
> > >
> > > AFAIK, all the helpers take the object as first argument, so I'm fine
> > > with the name change but it should take a drm_connector too. And ideally
> > > a drm_atomic_state pointer instead of drm_connector_state too.
> >
> > I think we then might take even further step and pass
> > drm_writeback_connector to this function. I'll send this as a part of v2.
>
> ... Which is still not the usual function prototype for atomic_check
> helpers.

On one hand, you are correct. On the other hand, don't we want to
emphasise that this function is to be called only for
drm_writeback_connector objects?




-- 
With best wishes
Dmitry

Re: [v3 0/6] DRM driver for verisilicon

[Sui Jingfeng]

Hi,

On 2023/12/4 20:33, Keith Zhao wrote:

This patch is a drm driver for Starfive Soc JH7110,
I am sending Drm driver part and HDMI driver part.

We used GEM framework for buffer management,
and for buffer allocation,we use DMA APIs.

the Starfive HDMI servers as interface between a LCD Controller
and a HDMI bus.
A HDMI TX consists of one HDMI transmitter controller
and one HDMI transmitter PHY.
(Sound support is not include in this patch)

This patchset should be applied on next branch.



Please study Thomas's patch[1][2] carefully and write a good cover letter.
Introduce what each single patch does, demonstrate how the whole driver is
divided and organized, and why. And probably keep contact with him if he
would like to curve your driver to a good shape. :-)


[1] 
https://lore.kernel.org/dri-devel/20200715145902.13122-1-tzimmerm...@suse.de/
[2] 
https://lore.kernel.org/dri-devel/20231113091439.17181-1-tzimmerm...@suse.de/



V1:
Changes since v1:
- Further standardize the yaml file.
- Dts naming convention improved.
- Fix the problem of compiling and loading ko files.
- Use drm new api to automatically manage resources.
- Drop vs_crtc_funcs&vs_plane_funcs, subdivide the plane's help interface.
- Reduce the modifiers unused.
- Optimize the hdmi driver code

V2:
Changes since v2:
- fix the error about checking the yaml file.
- match drm driver GEM DMA API.
- Delete the custom crtc property .
- hdmi use drmm_ new api to automatically manage resources.
- update the modifiers comments.
- enabling KASAN, fix the error during removing module

V3:
Changes since v3:
- Delete the custom plane property.
- Delete the custom fourcc modifiers.
- Adjust the calculation mode of hdmi pixclock.
- Add match data for dc8200 driver.
- Adjust some magic values.
- Add a simple encoder for dsi output.

Keith Zhao (6):
   dt-bindings: display: Add yamls for JH7110 display system
   riscv: dts: starfive: jh7110: display subsystem
   drm/vs: Register DRM device
   drm/vs: Add KMS crtc&plane
   drm/vs: Add hdmi driver
   drm/vs: simple encoder

  .../starfive/starfive,display-subsystem.yaml  |  104 ++
  .../starfive/starfive,dsi-encoder.yaml|   92 ++
  .../starfive/starfive,jh7110-dc8200.yaml  |  113 ++
  .../starfive/starfive,jh7110-inno-hdmi.yaml   |   82 ++
  .../soc/starfive/starfive,jh7110-syscon.yaml  |1 +
  MAINTAINERS   |8 +
  .../jh7110-starfive-visionfive-2.dtsi |  134 ++
  arch/riscv/boot/dts/starfive/jh7110.dtsi  |   49 +
  drivers/gpu/drm/Kconfig   |2 +
  drivers/gpu/drm/Makefile  |1 +
  drivers/gpu/drm/verisilicon/Kconfig   |   21 +
  drivers/gpu/drm/verisilicon/Makefile  |   12 +
  drivers/gpu/drm/verisilicon/starfive_hdmi.c   |  849 
  drivers/gpu/drm/verisilicon/starfive_hdmi.h   |  304 +
  drivers/gpu/drm/verisilicon/vs_crtc.c |  208 +++
  drivers/gpu/drm/verisilicon/vs_crtc.h |   42 +
  drivers/gpu/drm/verisilicon/vs_dc.c   | 1192 +
  drivers/gpu/drm/verisilicon/vs_dc.h   |   67 +
  drivers/gpu/drm/verisilicon/vs_dc_hw.c| 1022 ++
  drivers/gpu/drm/verisilicon/vs_dc_hw.h|  580 
  drivers/gpu/drm/verisilicon/vs_drv.c  |  323 +
  drivers/gpu/drm/verisilicon/vs_drv.h  |   46 +
  drivers/gpu/drm/verisilicon/vs_modeset.c  |   39 +
  drivers/gpu/drm/verisilicon/vs_modeset.h  |   10 +
  drivers/gpu/drm/verisilicon/vs_plane.c|  301 +
  drivers/gpu/drm/verisilicon/vs_plane.h|   39 +
  drivers/gpu/drm/verisilicon/vs_simple_enc.c   |  195 +++
  drivers/gpu/drm/verisilicon/vs_simple_enc.h   |   23 +
  drivers/gpu/drm/verisilicon/vs_type.h |   69 +
  29 files changed, 5928 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,display-subsystem.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,dsi-encoder.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-dc8200.yaml
  create mode 100644 
Documentation/devicetree/bindings/display/starfive/starfive,jh7110-inno-hdmi.yaml
  create mode 100644 drivers/gpu/drm/verisilicon/Kconfig
  create mode 100644 drivers/gpu/drm/verisilicon/Makefile
  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.c
  create mode 100644 drivers/gpu/drm/verisilicon/vs_drv.h
  create mode 100644 drivers/gpu/drm/verisilicon/vs_modes

[Bug 218221] Nouveau GSP fail on command cli:0xc1d0000

[bugzilla-daemon]

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

marc barbier (mmarc...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |CODE_FIX

--- Comment #4 from marc barbier (mmarc...@gmail.com) ---
I just compiled rc4 and the errors no longer shows.

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

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

Re: [PATCH] drm: renesas: shmobile: Call drm_helper_force_disable_all() at shutdown time

[Laurent Pinchart]

Hi Geert and Doug,

Thank you for the patch.

On Tue, Dec 05, 2023 at 12:30:02PM +0100, Geert Uytterhoeven wrote:
> From: Douglas Anderson 
> 
> Based on grepping through the source code, this driver appears to be
> missing a call to drm_atomic_helper_shutdown() at system shutdown time.
> This is important because drm_helper_force_disable_all() will cause
> panels to get disabled cleanly which may be important for their power
> sequencing.  Future changes will remove any custom powering off in
> individual panel drivers so the DRM drivers need to start getting this
> right.
> 
> The fact that we should call drm_atomic_helper_shutdown() in the case of
> OS shutdown comes straight out of the kernel doc "driver instance
> overview" in drm_drv.c.
> 
> Suggested-by: Maxime Ripard 
> Signed-off-by: Douglas Anderson 
> Link: 
> https://lore.kernel.org/r/20230901164111.RFT.15.Iaf638a1d4c8b3c307a6192efabb4cbb06b195f15@changeid
> [geert: s/drm_helper_force_disable_all/drm_atomic_helper_shutdown/]
> [geert: shmob_drm_remove() already calls drm_atomic_helper_shutdown]
> Signed-off-by: Geert Uytterhoeven 

Reviewed-by: Laurent Pinchart 

> ---
> Tested on Atmark Techno Armadillo-800-EVA, where the PWM instance
> driving the backlight is now stopped on shutdown.
> Panel-simple does print two new warnings:
> 
> +panel-simple panel: Skipping disable of already disabled panel
> +panel-simple panel: Skipping unprepare of already unprepared panel

Have you investigated where this comes from ?

>  reboot: System halted
> ---
>  drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c 
> b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> index bd16d4780c6436c3..a15162be26f259a4 100644
> --- a/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/renesas/shmobile/shmob_drm_drv.c
> @@ -171,6 +171,13 @@ static void shmob_drm_remove(struct platform_device 
> *pdev)
>   drm_kms_helper_poll_fini(ddev);
>  }
>  
> +static void shmob_drm_shutdown(struct platform_device *pdev)
> +{
> + struct shmob_drm_device *sdev = platform_get_drvdata(pdev);
> +
> + drm_atomic_helper_shutdown(&sdev->ddev);
> +}
> +
>  static int shmob_drm_probe(struct platform_device *pdev)
>  {
>   struct shmob_drm_platform_data *pdata = pdev->dev.platform_data;
> @@ -274,6 +281,7 @@ static const struct of_device_id shmob_drm_of_table[] 
> __maybe_unused = {
>  static struct platform_driver shmob_drm_platform_driver = {
>   .probe  = shmob_drm_probe,
>   .remove_new = shmob_drm_remove,
> + .shutdown   = shmob_drm_shutdown,
>   .driver = {
>   .name   = "shmob-drm",
>   .of_match_table = of_match_ptr(shmob_drm_of_table),

-- 
Regards,

Laurent Pinchart

Re: (subset) [PATCH 00/17] dt-bindings: samsung: add specific compatibles for existing SoC

[Thierry Reding]

On Tue, Nov 28, 2023 at 09:58:41PM +0100, Uwe Kleine-König wrote:
> On Tue, Nov 28, 2023 at 06:49:23PM +0100, Thierry Reding wrote:
> > 
> > On Wed, 08 Nov 2023 11:43:26 +0100, Krzysztof Kozlowski wrote:
> > > Merging
> > > ===
> > > I propose to take entire patchset through my tree (Samsung SoC), because:
> ^^^
> 
> > > 1. Next cycle two new SoCs will be coming (Google GS101 and 
> > > ExynosAutov920), so
> > >they will touch the same lines in some of the DT bindings (not all, 
> > > though).
> > >It is reasonable for me to take the bindings for the new SoCs, to have 
> > > clean
> > >`make dtbs_check` on the new DTS.
> > > 2. Having it together helps me to have clean `make dtbs_check` within my 
> > > tree
> > >on the existing DTS.
> > > 3. No drivers are affected by this change.
> > > 4. I plan to do the same for Tesla FSD and Exynos ARM32 SoCs, thus expect
> > >follow up patchsets.
> > > 
> > > [...]
> > 
> > Applied, thanks!
> > 
> > [12/17] dt-bindings: pwm: samsung: add specific compatibles for existing SoC
> > commit: 5d67b8f81b9d598599366214e3b2eb5f84003c9f
> 
> You didn't honor (or even comment) Krzysztof's proposal to take the
> whole patchset via his tree (marked above). Was there some off-list
> agreement?

I had read all that and then looking at patchwork saw that you had
marked all other patches in the series as "handled-elsewhere" and only
this one was left as "new", so I assumed that, well, everything else was
handled elsewhere and I was supposed to pick this one up...

I'll drop this one.

Thierry


signature.asc
Description: PGP signature

[PATCH 0/4] Support panels used by MT8173 Chromebooks in edp-panel

[Pin-yen Lin]

This series contains 4 patches:
1. Add a new panel delay to support some BOE panels
2. Sort the panel entries as a clean up. This one does not depend on other
   patches in this series and can be merged separately.
3. Add panel entries used by Mediatek MT8173 Chromebooks.
4. Add panels missing data sheets but used to work in older kernel version
   without any specified delays.


Pin-yen Lin (4):
  drm/panel-edp: Add powered_on_to_enable delay
  drm/edp-panel: Sort the panel entries
  drm/edp-panel: Add panels delay entries
  drm/panel-edp: Add some panels with conservative timings

 drivers/gpu/drm/panel/panel-edp.c | 92 ++-
 1 file changed, 91 insertions(+), 1 deletion(-)

-- 
2.43.0.rc2.451.g8631bc7472-goog

[PATCH 1/4] drm/panel-edp: Add powered_on_to_enable delay

[Pin-yen Lin]

Add the support of powered_on_to_enable delay as the minimum time that
needs to have passed between the panel powered on and enable may begin.

This delay is seen in BOE panels as the minimum delay of T3+T4+T5+T6+T8
in the eDP timing diagrams.

Signed-off-by: Pin-yen Lin 
---

 drivers/gpu/drm/panel/panel-edp.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index 825fa2a0d8a5..819fe8115c08 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -70,6 +70,21 @@ struct panel_delay {
 */
unsigned int hpd_absent;
 
+   /**
+* @powered_on_to_enable: Time between panel powered on and enable.
+*
+* The minimum time, in milliseconds, that needs to have passed
+* between when panel powered on and enable may begin.
+*
+* This is (T3+T4+T5+T6+T8)-min on eDP timing diagrams or after the
+* power supply enabled until we can turn the backlight on and see
+* valid data.
+*
+* This doesn't normally need to be set if timings are already met by
+* prepare_to_enable or enable.
+*/
+   unsigned int powered_on_to_enable;
+
/**
 * @prepare_to_enable: Time between prepare and enable.
 *
@@ -216,6 +231,7 @@ struct panel_edp {
bool prepared;
 
ktime_t prepared_time;
+   ktime_t powered_on_time;
ktime_t unprepared_time;
 
const struct panel_desc *desc;
@@ -455,6 +471,8 @@ static int panel_edp_prepare_once(struct panel_edp *p)
 
gpiod_set_value_cansleep(p->enable_gpio, 1);
 
+   p->powered_on_time = ktime_get_boottime();
+
delay = p->desc->delay.hpd_reliable;
if (p->no_hpd)
delay = max(delay, p->desc->delay.hpd_absent);
@@ -579,6 +597,8 @@ static int panel_edp_enable(struct drm_panel *panel)
 
panel_edp_wait(p->prepared_time, p->desc->delay.prepare_to_enable);
 
+   panel_edp_wait(p->powered_on_time, p->desc->delay.powered_on_to_enable);
+
p->enabled = true;
 
return 0;
-- 
2.43.0.rc2.451.g8631bc7472-goog

[PATCH 2/4] drm/edp-panel: Sort the panel entries

[Pin-yen Lin]

Move the order of CMN 0x14e5 to make the list sorted.

Signed-off-by: Pin-yen Lin 
---

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

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index 819fe8115c08..e0a18e17d3a2 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1987,9 +1987,9 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('C', 'M', 'N', 0x142b, &delay_200_500_e80_d50, 
"N140HCA-EAC"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x144f, &delay_200_500_e80_d50, 
"N140HGA-EA1"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x1468, &delay_200_500_e80, 
"N140HGA-EA1"),
-   EDP_PANEL_ENTRY('C', 'M', 'N', 0x14e5, &delay_200_500_e80_d50, 
"N140HGA-EA1"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x14d4, &delay_200_500_e80_d50, 
"N140HCA-EAC"),
EDP_PANEL_ENTRY('C', 'M', 'N', 0x14d6, &delay_200_500_e80_d50, 
"N140BGA-EA4"),
+   EDP_PANEL_ENTRY('C', 'M', 'N', 0x14e5, &delay_200_500_e80_d50, 
"N140HGA-EA1"),
 
EDP_PANEL_ENTRY('H', 'K', 'C', 0x2d5c, &delay_200_500_e200, 
"MB116AN01-2"),
 
-- 
2.43.0.rc2.451.g8631bc7472-goog

[PATCH 3/4] drm/edp-panel: Add panels delay entries

[Pin-yen Lin]

Add panels used by Mediatek MT8173 Chromebooks.

Signed-off-by: Pin-yen Lin 
---

 drivers/gpu/drm/panel/panel-edp.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index e0a18e17d3a2..475257fe1ddc 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1857,6 +1857,13 @@ static const struct panel_delay delay_200_500_p2e80 = {
.prepare_to_enable = 80,
 };
 
+static const struct panel_delay delay_200_500_e50_p2e80 = {
+   .hpd_absent = 200,
+   .unprepare = 500,
+   .enable = 50,
+   .prepare_to_enable = 80,
+};
+
 static const struct panel_delay delay_200_500_p2e100 = {
.hpd_absent = 200,
.unprepare = 500,
@@ -1894,6 +1901,13 @@ static const struct panel_delay delay_200_500_e200 = {
.enable = 200,
 };
 
+static const struct panel_delay delay_200_500_e200_d200 = {
+   .hpd_absent = 200,
+   .unprepare = 500,
+   .enable = 200,
+   .disable = 200,
+};
+
 static const struct panel_delay delay_200_500_e200_d10 = {
.hpd_absent = 200,
.unprepare = 500,
@@ -1907,6 +1921,13 @@ static const struct panel_delay delay_200_150_e200 = {
.enable = 200,
 };
 
+static const struct panel_delay delay_200_500_e50_po2e200 = {
+   .hpd_absent = 200,
+   .unprepare = 500,
+   .enable = 50,
+   .powered_on_to_enable = 200,
+};
+
 #define EDP_PANEL_ENTRY(vend_chr_0, vend_chr_1, vend_chr_2, product_id, 
_delay, _name) \
 { \
.name = _name, \
@@ -1932,6 +1953,7 @@ static const struct panel_delay delay_200_150_e200 = {
  * Sort first by vendor, then by product ID.
  */
 static const struct edp_panel_entry edp_panels[] = {
+   EDP_PANEL_ENTRY('A', 'U', 'O', 0x105c, &delay_200_500_e50, 
"B116XTN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1062, &delay_200_500_e50, 
"B120XAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, &delay_200_500_e50, 
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, &delay_200_500_e50, 
"B133UAN02.1"),
@@ -1948,23 +1970,31 @@ static const struct edp_panel_entry edp_panels[] = {
 &auo_b116xa3_mode),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x635c, &delay_200_500_e50, 
"B116XAN06.3"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x639c, &delay_200_500_e50, 
"B140HAK02.7"),
+   EDP_PANEL_ENTRY('A', 'U', 'O', 0x723c, &delay_200_500_e50, 
"B140XTN07.2"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50, 
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, &delay_200_500_e50, 
"B140XTN07.7"),
 
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0608, &delay_200_500_e50, 
"NT116WHM-N11"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, &delay_200_150_e200, 
"NT116WHM-N21"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0717, &delay_200_500_e50_po2e200, 
"NV133FHM-N42"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, &delay_200_500_e80, 
"NT116WHM-N42"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, &delay_200_500_e200, 
"NT116WHM-N44"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0754, &delay_200_500_e50_po2e200, 
"NV116WHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, &delay_200_500_p2e80, 
"NV116WHM-T01"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, &boe_nv133fhm_n61.delay, 
"NV133FHM-N61"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, &delay_200_500_e200, 
"NT140FHM-N44"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0827, &delay_200_500_e50_p2e80, 
"NT140WHM-N44 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, &boe_nv133fhm_n61.delay, 
"NV133FHM-N62"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, &delay_200_500_e200, 
"NT140WHM-N49"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, &delay_200_500_e50, 
"NT116WHM-N21,836X2"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, &delay_200_500_e50, 
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, &delay_200_500_e80, 
"NV116WHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x095f, &delay_200_500_e50, 
"NE135FBM-N41 v8.1"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x096e, &delay_200_500_e50_po2e200, 
"NV116WHM-T07 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0979, &delay_200_500_e50, 
"NV116WHM-N49 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x098d, &boe_nv110wtm_n61.delay, 
"NV110WTM-N61"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0993, &delay_200_500_e80, 
"NV116WHM-T14 V8.0"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ad, &delay_200_500_e80, 
"NV116WHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ae, &delay_200_500_e200, 
"NT140FHM-N45"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09dd, &delay_200_500_e50, 
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0a5d, &delay_200_500_e50, 
"NV116WHM-N45"),
@@ -1973,6 +2003,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0b56, &delay_200_500_e80, 
"NT140FHM-N47"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0c20, &delay_200_500

[PATCH 4/4] drm/panel-edp: Add some panels with conservative timings

[Pin-yen Lin]

These panels are used by Mediatek MT8173 Chromebooks but we can't find
the corresponding data sheets, and these panels used to work on v4.19
kernel without any specified delays.

Therefore, instead of having them use the default conservative timings,
update them with less-conservative timings from other panels of the same
vendor. The panels should still work under those timings, and we can
save some delays and suppress the warnings.

Signed-off-by: Pin-yen Lin 

---

 drivers/gpu/drm/panel/panel-edp.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-edp.c 
b/drivers/gpu/drm/panel/panel-edp.c
index 475257fe1ddc..55e747715178 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1955,6 +1955,7 @@ static const struct panel_delay delay_200_500_e50_po2e200 
= {
 static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x105c, &delay_200_500_e50, 
"B116XTN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1062, &delay_200_500_e50, 
"B120XAN01.0"),
+   EDP_PANEL_ENTRY('A', 'U', 'O', 0x125c, &delay_200_500_e50, "Unknown"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x145c, &delay_200_500_e50, 
"B116XAB01.4"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1e9b, &delay_200_500_e50, 
"B133UAN02.1"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x1ea5, &delay_200_500_e50, 
"B116XAK01.6"),
@@ -1965,6 +1966,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x403d, &delay_200_500_e50, 
"B140HAN04.0"),
EDP_PANEL_ENTRY2('A', 'U', 'O', 0x405c, &auo_b116xak01.delay, 
"B116XAK01.0",
 &auo_b116xa3_mode),
+   EDP_PANEL_ENTRY('A', 'U', 'O', 0x435c, &delay_200_500_e50, "Unknown"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0x582d, &delay_200_500_e50, 
"B133UAN01.0"),
EDP_PANEL_ENTRY2('A', 'U', 'O', 0x615c, &delay_200_500_e50, 
"B116XAN06.1",
 &auo_b116xa3_mode),
@@ -1974,18 +1976,34 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50, 
"B133UAN01.0"),
EDP_PANEL_ENTRY('A', 'U', 'O', 0xf390, &delay_200_500_e50, 
"B140XTN07.7"),
 
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0607, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0608, &delay_200_500_e50, 
"NT116WHM-N11"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0668, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x068f, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x06e5, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0705, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0715, &delay_200_150_e200, 
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0717, &delay_200_500_e50_po2e200, 
"NV133FHM-N42"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0731, &delay_200_500_e80, 
"NT116WHM-N42"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0741, &delay_200_500_e200, 
"NT116WHM-N44"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0744, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x074c, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0751, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0754, &delay_200_500_e50_po2e200, 
"NV116WHM-N45"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0771, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, &delay_200_500_p2e80, 
"NV116WHM-T01"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0797, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, &boe_nv133fhm_n61.delay, 
"NV133FHM-N61"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d3, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f6, &delay_200_500_e200, 
"NT140FHM-N44"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x07f8, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0813, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0827, &delay_200_500_e50_p2e80, 
"NT140WHM-N44 V8.0"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x082d, &boe_nv133fhm_n61.delay, 
"NV133FHM-N62"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0843, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x08b2, &delay_200_500_e200, 
"NT140WHM-N49"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0848, &delay_200_500_e200, "Unknown"),
+   EDP_PANEL_ENTRY('B', 'O', 'E', 0x0849, &delay_200_500_e200, "Unknown"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09c3, &delay_200_500_e50, 
"NT116WHM-N21,836X2"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x094b, &delay_200_500_e50, 
"NT116WHM-N21"),
EDP_PANEL_ENTRY('B', 'O', 'E', 0x0951, &delay_200_500_e80, 
"NV116WHM-N47"),
@@ -1997,6 +2015,7 @@ static const struct edp_panel_entry edp_panels[] = {
EDP_PANEL_ENTRY('B', 'O', 'E', 0x09ad, &delay_200_500_e80, 
"N

dri-devel@lists.freedesktop.org

[Dmitry Baryshkov]

On Mon, 4 Dec 2023 at 14:33, Keith Zhao  wrote:
>
> add 2 crtcs and 8 planes in vs-drm
>
> Signed-off-by: Keith Zhao 
> ---
>  drivers/gpu/drm/verisilicon/Makefile   |9 +-
>  drivers/gpu/drm/verisilicon/vs_crtc.c  |  208 +
>  drivers/gpu/drm/verisilicon/vs_crtc.h  |   42 +
>  drivers/gpu/drm/verisilicon/vs_dc.c| 1192 
>  drivers/gpu/drm/verisilicon/vs_dc.h|   67 ++
>  drivers/gpu/drm/verisilicon/vs_dc_hw.c | 1022 
>  drivers/gpu/drm/verisilicon/vs_dc_hw.h |  580 
>  drivers/gpu/drm/verisilicon/vs_drv.c   |2 +
>  drivers/gpu/drm/verisilicon/vs_plane.c |  301 ++
>  drivers/gpu/drm/verisilicon/vs_plane.h |   39 +
>  drivers/gpu/drm/verisilicon/vs_type.h  |   69 ++
>  11 files changed, 3528 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_crtc.h
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc.h
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_dc_hw.h
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_plane.h
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_type.h
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile 
> b/drivers/gpu/drm/verisilicon/Makefile
> index d785a1dfaa7f..bf6f2b7ee480 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,6 +1,9 @@
>  # SPDX-License-Identifier: GPL-2.0
>
> -vs_drm-objs := vs_drv.o \
> -  vs_modeset.o
> -
> +vs_drm-objs := vs_dc_hw.o \

Nit: if you move the first object to the next line, you won't have to
touch the first line.

> +   vs_dc.o \
> +   vs_crtc.o \
> +   vs_drv.o \
> +   vs_modeset.o \
> +   vs_plane.o

Keep the empty line, please.

>  obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c 
> b/drivers/gpu/drm/verisilicon/vs_crtc.c
> new file mode 100644
> index ..5581219b1230
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> @@ -0,0 +1,208 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 VeriSilicon Holdings Co., Ltd.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "vs_crtc.h"
> +#include "vs_dc.h"
> +#include "vs_drv.h"
> +
> +static void vs_crtc_atomic_destroy_state(struct drm_crtc *crtc,
> +struct drm_crtc_state *state)
> +{
> +   __drm_atomic_helper_crtc_destroy_state(state);
> +   kfree(to_vs_crtc_state(state));
> +}
> +
> +static void vs_crtc_reset(struct drm_crtc *crtc)
> +{
> +   struct vs_crtc_state *state;
> +
> +   if (crtc->state)
> +   vs_crtc_atomic_destroy_state(crtc, crtc->state);
> +
> +   state = kzalloc(sizeof(*state), GFP_KERNEL);
> +   if (!state)
> +   return;
> +
> +   __drm_atomic_helper_crtc_reset(crtc, &state->base);
> +}
> +
> +static struct drm_crtc_state *
> +vs_crtc_atomic_duplicate_state(struct drm_crtc *crtc)
> +{
> +   struct vs_crtc_state *old_state;
> +   struct vs_crtc_state *state;
> +
> +   if (!crtc->state)
> +   return NULL;
> +
> +   old_state = to_vs_crtc_state(crtc->state);
> +
> +   state = kmemdup(old_state, sizeof(*old_state), GFP_KERNEL);
> +   if (!state)
> +   return NULL;
> +
> +   __drm_atomic_helper_crtc_duplicate_state(crtc, &state->base);
> +
> +   return &state->base;
> +}
> +
> +static int vs_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> +   struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
> +   struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
> +
> +   vs_dc_enable_vblank(dc, true);
> +
> +   return 0;
> +}
> +
> +static void vs_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> +   struct vs_crtc *vs_crtc = to_vs_crtc(crtc);
> +   struct vs_dc *dc = dev_get_drvdata(vs_crtc->dev);
> +
> +   vs_dc_enable_vblank(dc, false);

I always found foo_enable_something(false) to be strange. Could you
please split this into two functions?

> +}
> +
> +static void vs_crtc_atomic_print_state(struct drm_printer *p,
> +  const struct drm_crtc_state *state)
> +{
> +   struct vs_crtc *vs_crtc = to_vs_crtc(state->crtc);
> +
> +   drm_printf(p, "vs crtc State\n");

Please drop this line, it breaks the debugfs/state flow.

> +   drm_printf(p, "\tcolor_formats: %d\n", vs_crtc->color_formats);
> +   drm_printf(p, "\tmax_bpc: %d\n", vs_crtc->max_bpc);
> +}
> +
> +static const struct drm_crtc_funcs vs_crtc_funcs = {
> +   .set_config = drm_atomic_helper_set_config,
> +   .page_flip  = drm_atom

Re: [DO NOT MERGE v5 35/37] sh: RTS7751R2D Plus OF defconfig

[Arnd Bergmann]

On Tue, Dec 5, 2023, at 10:45, Yoshinori Sato wrote:
> Signed-off-by: Yoshinori Sato 
> ---
>  arch/sh/configs/rts7751r2dplus-of_defconfig | 93 +

This is very similar to the landisk config, so it may be
easier to just have one of them that works for both, as well
as future ones.

> +CONFIG_LOG_BUF_SHIFT=14
> +CONFIG_NAMESPACES=y
> +CONFIG_EXPERT=y

You should not normally need to enable CONFIG_EXPERT in a
defconfig. Is there any particular reason for this?

Arnd

Re: [v3 5/6] drm/vs: Add hdmi driver

[Dmitry Baryshkov]

On Mon, 4 Dec 2023 at 14:33, Keith Zhao  wrote:
>
> add hdmi driver as encoder and connect
>
> Signed-off-by: Keith Zhao 
> ---
>  drivers/gpu/drm/verisilicon/Kconfig |   8 +
>  drivers/gpu/drm/verisilicon/Makefile|   1 +
>  drivers/gpu/drm/verisilicon/starfive_hdmi.c | 849 
>  drivers/gpu/drm/verisilicon/starfive_hdmi.h | 304 +++
>  drivers/gpu/drm/verisilicon/vs_drv.c|   3 +
>  drivers/gpu/drm/verisilicon/vs_drv.h|   4 +
>  6 files changed, 1169 insertions(+)
>  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.c
>  create mode 100644 drivers/gpu/drm/verisilicon/starfive_hdmi.h
>
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig 
> b/drivers/gpu/drm/verisilicon/Kconfig
> index e10fa97635aa..122c786e3948 100644
> --- a/drivers/gpu/drm/verisilicon/Kconfig
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -11,3 +11,11 @@ config DRM_VERISILICON
>   This driver provides VeriSilicon kernel mode
>   setting and buffer management. It does not
>   provide 2D or 3D acceleration.
> +
> +config DRM_VERISILICON_STARFIVE_HDMI
> +   bool "Starfive HDMI extensions"
> +   depends on DRM_VERISILICON
> +   help
> +  This selects support for StarFive soc specific extensions
> +  for the Innosilicon HDMI driver. If you want to enable
> +  HDMI on JH7110 based soc, you should select this option.
> diff --git a/drivers/gpu/drm/verisilicon/Makefile 
> b/drivers/gpu/drm/verisilicon/Makefile
> index bf6f2b7ee480..71fadafcee13 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -6,4 +6,5 @@ vs_drm-objs := vs_dc_hw.o \
> vs_drv.o \
> vs_modeset.o \
> vs_plane.o
> +vs_drm-$(CONFIG_DRM_VERISILICON_STARFIVE_HDMI) += starfive_hdmi.o
>  obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> diff --git a/drivers/gpu/drm/verisilicon/starfive_hdmi.c 
> b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
> new file mode 100644
> index ..aa621db0dee0
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/starfive_hdmi.c
> @@ -0,0 +1,849 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2023 StarFive Technology Co., Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "starfive_hdmi.h"
> +#include "vs_drv.h"
> +#include "vs_crtc.h"
> +
> +static const char * const hdmi_clocks[] = {
> +   "sysclk",
> +   "mclk",
> +   "bclk"
> +};
> +
> +static struct starfive_hdmi_encoder *encoder_to_hdmi(struct drm_encoder 
> *encoder)
> +{
> +   return container_of(encoder, struct starfive_hdmi_encoder, encoder);
> +}
> +
> +static struct starfive_hdmi *connector_to_hdmi(struct drm_connector 
> *connector)
> +{
> +   return container_of(connector, struct starfive_hdmi, connector);
> +}
> +
> +static const struct post_pll_config post_pll_cfg_table[] = {
> +   {2520,  1, 80, 13, 3, 1},
> +   {2700,  1, 40, 11, 3, 1},
> +   {3375,  1, 40, 11, 3, 1},
> +   {4900,  1, 20, 1, 3, 3},
> +   {24170, 1, 20, 1, 3, 3},
> +   {29700, 4, 20, 0, 0, 3},
> +   {59400, 4, 20, 0, 0, 0},
> +   { /* sentinel */ }
> +};
> +
> +inline u8 hdmi_readb(struct starfive_hdmi *hdmi, u16 offset)
> +{
> +   return readl_relaxed(hdmi->regs + (offset) * 0x04);
> +}
> +
> +inline void hdmi_writeb(struct starfive_hdmi *hdmi, u16 offset, u32 val)
> +{
> +   writel_relaxed(val, hdmi->regs + (offset) * 0x04);
> +}
> +
> +inline void hdmi_writew(struct starfive_hdmi *hdmi, u16 offset, u32 val)
> +{
> +   writew_relaxed(val & 0xFF, hdmi->regs + (offset) * 0x04);
> +   writew_relaxed((val >> 8) & 0xFF, hdmi->regs + (offset + 1) * 0x04);
> +}
> +
> +inline void hdmi_modb(struct starfive_hdmi *hdmi, u16 offset,
> +u32 msk, u32 val)
> +{
> +   u8 temp = hdmi_readb(hdmi, offset) & ~msk;
> +
> +   temp |= val & msk;
> +   hdmi_writeb(hdmi, offset, temp);
> +}
> +
> +static int starfive_hdmi_enable_clk_deassert_rst(struct device *dev, struct 
> starfive_hdmi *hdmi)
> +{
> +   int ret;
> +
> +   ret = clk_bulk_prepare_enable(hdmi->nclks, hdmi->clk_hdmi);
> +   if (ret) {
> +   dev_err(dev, "failed to enable clocks\n");
> +   return ret;
> +   }
> +
> +   ret = reset_control_deassert(hdmi->tx_rst);
> +   if (ret < 0) {
> +   dev_err(dev, "failed to deassert tx_rst\n");
> +   return ret;
> +   }
> +   return 0;
> +}
> +
> +static void starfive_hdmi_disable_clk_assert_rst(struct device *dev, struct 
> starfive_hdmi *hdmi)
> +{
> +   int ret;
> +
> +   ret = reset_control_assert(hdmi->tx

Re: [DO NOT MERGE v5 10/37] sh: Common PCI Framework driver support.

[Arnd Bergmann]

On Tue, Dec 5, 2023, at 10:45, Yoshinori Sato wrote:
> +
> +#if defined(CONFIG_PCI) && !defined(CONFIG_GENERIC_IOMAP)
> +void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
> +{
> + iounmap(addr);
> +}
> +EXPORT_SYMBOL(pci_iounmap);

This definition does not work for addresses that are
returned by ioport_map(), include pci_iomap() on
IORESOURCE_IO.  However, the definition in lib/pci_iomap.c
should work fine, you just need to #define ARCH_WANTS_GENERIC_PCI_IOUNMAP
to get that.

  Arnd

[PATCH] drm/debugfs: fix potential NULL pointer dereference

[Marek Szyprowski]

encoder->funcs entry might be NULL, so check it first before calling its
methods. This fixes NULL pointer dereference observed on Rasberry Pi
3b/4b boards.

Fixes: caf525ed45b4 ("drm/encoder: register per-encoder debugfs dir")
Signed-off-by: Marek Szyprowski 
---
This fixes the following issue observed on Raspberry Pi 4b:

vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops [vc4])
vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address 0010 
when read
[0010] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in: sha256_arm raspberrypi_hwmon cfg80211(+) hci_uart btbcm 
bluetooth vc4(+) ecdh_generic ecc libaes snd_soc_hdmi_codec snd_soc_core v3d 
drm_shmem_helper ac97_bus snd_pcm_dmaengine snd_pcm genet(+) gpu_sched 
snd_timer snd bcm2711_thermal soundcore drm_dma_helper
CPU: 1 PID: 221 Comm: systemd-udevd Not tainted 6.7.0-rc4-next-20231205 #14267
Hardware name: BCM2711
PC is at drm_debugfs_encoder_add+0x6c/0x98
LR is at 0x0
...
 drm_debugfs_encoder_add from drm_encoder_register_all+0x20/0x60
 drm_encoder_register_all from drm_modeset_register_all+0x34/0x70
 drm_modeset_register_all from drm_dev_register+0x24c/0x28c
 drm_dev_register from vc4_drm_bind+0x21c/0x2d0 [vc4]
 vc4_drm_bind [vc4] from try_to_bring_up_aggregate_device+0x160/0x1bc
 try_to_bring_up_aggregate_device from component_master_add_with_match+0xc4/0xf8
 component_master_add_with_match from vc4_platform_drm_probe+0xa0/0xc0 [vc4]
 vc4_platform_drm_probe [vc4] from platform_probe+0x5c/0xb8
 platform_probe from really_probe+0xc8/0x2dc
 really_probe from __driver_probe_device+0x88/0x19c
 __driver_probe_device from driver_probe_device+0x30/0x104
 driver_probe_device from __driver_attach+0x90/0x174
 __driver_attach from bus_for_each_dev+0x6c/0xb4
 bus_for_each_dev from bus_add_driver+0xcc/0x1cc
 bus_add_driver from driver_register+0x7c/0x118
 driver_register from vc4_drm_register+0x44/0x1000 [vc4]
 vc4_drm_register [vc4] from do_one_initcall+0x40/0x1e0
 do_one_initcall from do_init_module+0x50/0x1e4
 do_init_module from init_module_from_file+0x90/0xbc
 init_module_from_file from sys_finit_module+0x144/0x258
 sys_finit_module from ret_fast_syscall+0x0/0x54
Exception stack(0xf0cf1fa8 to 0xf0cf1ff0)
...
---[ end trace  ]---

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

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 02e7481758c0..f4715a67e340 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -638,7 +638,7 @@ void drm_debugfs_encoder_add(struct drm_encoder *encoder)
debugfs_create_file("bridges", 0444, root, encoder,
&bridges_fops);
 
-   if (encoder->funcs->debugfs_init)
+   if (encoder->funcs && encoder->funcs->debugfs_init)
encoder->funcs->debugfs_init(encoder, root);
 }
 
-- 
2.34.1

Re: [REGRESSION]: nouveau: Asynchronous wait on fence

[Thorsten Leemhuis]

Karol, Lyude, and Daniel:

On 29.11.23 01:37, Owen T. Heisler wrote:
> On 11/21/23 14:23, Owen T. Heisler wrote:
>> On 11/21/23 09:16, Linux regression tracking (Thorsten Leemhuis) wrote:
>>> On 15.11.23 07:19, Owen T. Heisler wrote:
 On 10/31/23 04:18, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 28.10.23 04:46, Owen T. Heisler wrote:
>> #regzbot introduced: d386a4b54607cf6f76e23815c2c9a3abc1d66882
>> #regzbot link:
>> https://gitlab.freedesktop.org/drm/nouveau/-/issues/180
>>
>> 3. Suddenly the secondary Nvidia-connected display turns off and X
>> stops responding to keyboard/mouse input.
> 
>> I am currently testing v6.6 with the culprit commit reverted.
> 
> - v6.6: fails
> - v6.6 with the culprit commit reverted: works
> 
> See  for full
> details including a decoded kernel log.

Not sure about the others, but it's kind of confusing that you update
the issue descriptions all the time and never add a comment to that ticket.

Anyway: Nouveau maintainers, could any of you at least comment on this?
Sure, it's the regression is caused by an old commit (6eaa1f3c59a707 was
merged for v5.14-rc7) and reverting it likely is not a option, but it
nevertheless it would be great if this could be solved somehow.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

Re: [v3 6/6] drm/vs: simple encoder

[Dmitry Baryshkov]

On Mon, 4 Dec 2023 at 14:33, Keith Zhao  wrote:
>
> add simple encoder for dsi bridge

This doesn't look like a proper commit message.

>
> Signed-off-by: Keith Zhao 
> ---
>  drivers/gpu/drm/verisilicon/Makefile|   4 +-
>  drivers/gpu/drm/verisilicon/vs_drv.c|   2 +
>  drivers/gpu/drm/verisilicon/vs_simple_enc.c | 195 
>  drivers/gpu/drm/verisilicon/vs_simple_enc.h |  23 +++
>  4 files changed, 223 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_simple_enc.c
>  create mode 100644 drivers/gpu/drm/verisilicon/vs_simple_enc.h
>
> diff --git a/drivers/gpu/drm/verisilicon/Makefile 
> b/drivers/gpu/drm/verisilicon/Makefile
> index 71fadafcee13..cd5d0a90bcfe 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -5,6 +5,8 @@ vs_drm-objs := vs_dc_hw.o \
> vs_crtc.o \
> vs_drv.o \
> vs_modeset.o \
> -   vs_plane.o
> +   vs_plane.o \
> +   vs_simple_enc.o
> +
>  vs_drm-$(CONFIG_DRM_VERISILICON_STARFIVE_HDMI) += starfive_hdmi.o
>  obj-$(CONFIG_DRM_VERISILICON) += vs_drm.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_drv.c 
> b/drivers/gpu/drm/verisilicon/vs_drv.c
> index d7e5199fe293..946f137ab124 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drv.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drv.c
> @@ -23,6 +23,7 @@
>  #include "vs_drv.h"
>  #include "vs_modeset.h"
>  #include "vs_dc.h"
> +#include "vs_simple_enc.h"
>
>  #define DRV_NAME   "verisilicon"
>  #define DRV_DESC   "Verisilicon DRM driver"
> @@ -217,6 +218,7 @@ static struct platform_driver *drm_sub_drivers[] = {
>  #ifdef CONFIG_DRM_VERISILICON_STARFIVE_HDMI
> &starfive_hdmi_driver,
>  #endif
> +   &simple_encoder_driver,
>  };
>
>  static struct component_match *vs_drm_match_add(struct device *dev)
> diff --git a/drivers/gpu/drm/verisilicon/vs_simple_enc.c 
> b/drivers/gpu/drm/verisilicon/vs_simple_enc.c
> new file mode 100644
> index ..c5a8d82bc469
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_simple_enc.c
> @@ -0,0 +1,195 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 VeriSilicon Holdings Co., Ltd.
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "vs_crtc.h"
> +#include "vs_simple_enc.h"
> +
> +static const struct simple_encoder_priv dsi_priv = {

Please use proper prefix for all the struct and function names.
vs_simple_encoder sounds better. Or vs_dsi_encoder.

> +   .encoder_type = DRM_MODE_ENCODER_DSI
> +};
> +
> +static inline struct simple_encoder *to_simple_encoder(struct drm_encoder 
> *enc)
> +{
> +   return container_of(enc, struct simple_encoder, encoder);
> +}
> +
> +static int encoder_parse_dt(struct device *dev)
> +{
> +   struct simple_encoder *simple = dev_get_drvdata(dev);
> +   unsigned int args[2];
> +
> +   simple->dss_regmap = 
> syscon_regmap_lookup_by_phandle_args(dev->of_node,
> + 
> "starfive,syscon",
> + 2, args);
> +
> +   if (IS_ERR(simple->dss_regmap)) {
> +   return dev_err_probe(dev, PTR_ERR(simple->dss_regmap),
> +"getting the regmap failed\n");
> +   }
> +
> +   simple->offset = args[0];
> +   simple->mask = args[1];
> +
> +   return 0;
> +}
> +
> +void encoder_atomic_enable(struct drm_encoder *encoder,
> +  struct drm_atomic_state *state)
> +{
> +   struct simple_encoder *simple = to_simple_encoder(encoder);
> +
> +   regmap_update_bits(simple->dss_regmap, simple->offset, simple->mask,
> +  simple->mask);
> +}
> +
> +int encoder_atomic_check(struct drm_encoder *encoder,
> +struct drm_crtc_state *crtc_state,
> +struct drm_connector_state *conn_state)
> +{
> +   struct vs_crtc_state *vs_crtc_state = to_vs_crtc_state(crtc_state);
> +   struct drm_connector *connector = conn_state->connector;
> +   int ret = 0;
> +
> +   struct drm_bridge *first_bridge = 
> drm_bridge_chain_get_first_bridge(encoder);
> +   struct drm_bridge_state *bridge_state = ERR_PTR(-EINVAL);
> +
> +   vs_crtc_state->encoder_type = encoder->encoder_type;
> +
> +   if (first_bridge && first_bridge->funcs->atomic_duplicate_state)
> +   bridge_state = drm_atomic_get_bridge_state(crtc_state->state, 
> first_bridge);

Please don't poke into others' playground. This should go into your
DSI bridge's atomic_check() instead.

> +
> +   if (IS_ERR(bridge_state)) {
> +   if (connector->display_info.num_bus_formats)
> +   vs_crtc_state->output_fmt = 
> connector->display_info.bus_formats[0];
> +   e