date:20230607

drm_print.h says DRM_ERROR is deprecated in favor of drm_err().

Reviewed-by: Laurent Pinchart 
Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_bridge.c |  8 
 drivers/gpu/drm/drm_bufs.c   |  8 
 drivers/gpu/drm/drm_client_modeset.c |  4 ++--
 drivers/gpu/drm/drm_context.c|  4 ++--
 drivers/gpu/drm/drm_crtc_helper.c|  8 
 drivers/gpu/drm/drm_debugfs_crc.c|  3 ++-
 drivers/gpu/drm/drm_drv.c| 16 
 drivers/gpu/drm/drm_flip_work.c  |  2 +-
 drivers/gpu/drm/drm_framebuffer.c|  3 ++-
 drivers/gpu/drm/drm_gem.c|  2 +-
 drivers/gpu/drm/drm_gem_dma_helper.c |  2 +-
 drivers/gpu/drm/drm_hashtab.c|  4 ++--
 drivers/gpu/drm/drm_lock.c   | 16 
 drivers/gpu/drm/drm_mipi_dbi.c   |  2 +-
 drivers/gpu/drm/drm_mm.c |  8 
 drivers/gpu/drm/drm_mode_config.c|  2 +-
 drivers/gpu/drm/drm_modes.c  | 26 +-
 drivers/gpu/drm/drm_modeset_helper.c |  2 +-
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_scatter.c|  9 +
 drivers/gpu/drm/drm_vm.c |  2 +-
 21 files changed, 68 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..3d27f08db74d 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -351,11 +351,11 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct 
drm_bridge *bridge,
list_del(>chain_node);
 
 #ifdef CONFIG_OF
-   DRM_ERROR("failed to attach bridge %pOF to encoder %s: %d\n",
- bridge->of_node, encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge %pOF to encoder %s: 
%d\n",
+   bridge->of_node, encoder->name, ret);
 #else
-   DRM_ERROR("failed to attach bridge to encoder %s: %d\n",
- encoder->name, ret);
+   drm_err(encoder->dev, "failed to attach bridge to encoder %s: %d\n",
+   encoder->name, ret);
 #endif
 
return ret;
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 86700560fea2..aa66fe16ea6e 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -1470,15 +1470,15 @@ int drm_legacy_freebufs(struct drm_device *dev, void 
*data,
if (copy_from_user(, >list[i], sizeof(idx)))
return -EFAULT;
if (idx < 0 || idx >= dma->buf_count) {
-   DRM_ERROR("Index %d (of %d max)\n",
- idx, dma->buf_count - 1);
+   drm_err(dev, "Index %d (of %d max)\n",
+   idx, dma->buf_count - 1);
return -EINVAL;
}
idx = array_index_nospec(idx, dma->buf_count);
buf = dma->buflist[idx];
if (buf->file_priv != file_priv) {
-   DRM_ERROR("Process %d freeing buffer not owned\n",
- task_pid_nr(current));
+   drm_err(dev, "Process %d freeing buffer not owned\n",
+   task_pid_nr(current));
return -EINVAL;
}
drm_legacy_free_buffer(dev, buf);
diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index ae19734974b5..e2403b8c6347 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -808,7 +808,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
offsets = kcalloc(connector_count, sizeof(*offsets), GFP_KERNEL);
enabled = kcalloc(connector_count, sizeof(bool), GFP_KERNEL);
if (!crtcs || !modes || !enabled || !offsets) {
-   DRM_ERROR("Memory allocation failed\n");
+   drm_err(client->dev, "Memory allocation failed\n");
ret = -ENOMEM;
goto out;
}
@@ -832,7 +832,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(connectors, connector_count, 
modes,
 offsets, enabled, width, 
height))
-   DRM_ERROR("Unable to find initial modes\n");
+   drm_err(client->dev, "Unable to find initial modes\n");
 
DRM_DEBUG_KMS("picking CRTCs for %dx%d config\n",
  width, height);
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm_context.c
index a0fc779e5e1e..bf1fc8bb97de 100644
--- a/drivers/gpu/drm/drm_context.c
+++ b/drivers/gpu/drm/drm_context.c
@@ -270,7 +270,7 @@ int drm_legacy_setsareactx(struct drm_device *dev, void 
*data,
 static int drm_context_switch(struct drm_device * dev, int

Re: [PATCH v9 0/8] drm: Remove usage of deprecated DRM_* macros

On Tue, 06 Jun 2023 23:19:28 +0530, Laurent Pinchart wrote:
> The idea would be to include the drm_print_deprecated.h header in
> drivers that still use the deprecated macros.

Yeah, what I meant was in a "first pass" kind of sense.

> > Not every file can be seen at a case-by-case basis or by coccinelle
> > as far as I understand its usage. Consider the following:
> > 
> > DRM_INFO is used on line 210 of amd/amdgpu/amdgpu_acpi.c, but the
> > file does not even include drm_print.h directly. It includes the
> > amdgpu.h header, which includes the amdgpu_ring.h header, which
> > finally has the "#include " line.
> > 
> > If a simple find and replace has to be done, then that can be added
> > at the end of the series.
> 
> Maybe a simple grep for the deprecated macros would be enough to
> identify all the files that still use them ?

Hmm, so the drm_print_deprecated.h should be included individually on
all the files, regardless of whether they include drm_print.h directly
or not?

Actually that makes sense, so further inclusion of top-level header
would not automatically include the deprecated macros.

Since this needs some thought, I will be sending v10 without this.
This change can be sent later separately, as it will anyways be a
huge patch, and 10 is already a big enough revision number.

Thanks,
Siddh

[PATCH v10 7/9] drm: Remove usage of deprecated DRM_DEBUG_DRIVER in DRM core

drm_print.h says DRM_DEBUG_DRIVER is deprecated.
Thus, use newer drm_dbg_driver().

Also fix the deprecation comment in drm_print.h which
mentions drm_dbg() instead of drm_dbg_driver().

Reviewed-by: Laurent Pinchart 
Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_mipi_dbi.c | 10 +-
 include/drm/drm_print.h|  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
index 58ff9503a403..ab5dd5933a1a 100644
--- a/drivers/gpu/drm/drm_mipi_dbi.c
+++ b/drivers/gpu/drm/drm_mipi_dbi.c
@@ -70,11 +70,11 @@
 #define MIPI_DBI_DEBUG_COMMAND(cmd, data, len) \
 ({ \
if (!len) \
-   DRM_DEBUG_DRIVER("cmd=%02x\n", cmd); \
+   drm_dbg_driver(NULL, "cmd=%02x\n", cmd); \
else if (len <= 32) \
-   DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, (int)len, data);\
+   drm_dbg_driver(NULL, "cmd=%02x, par=%*ph\n", cmd, (int)len, 
data);\
else \
-   DRM_DEBUG_DRIVER("cmd=%02x, len=%zu\n", cmd, len); \
+   drm_dbg_driver(NULL, "cmd=%02x, len=%zu\n", cmd, len); \
 })
 
 static const u8 mipi_dbi_dcs_read_commands[] = {
@@ -708,7 +708,7 @@ bool mipi_dbi_display_is_on(struct mipi_dbi *dbi)
DCS_POWER_MODE_DISPLAY_NORMAL_MODE | DCS_POWER_MODE_SLEEP_MODE))
return false;
 
-   DRM_DEBUG_DRIVER("Display is ON\n");
+   drm_dbg_driver(NULL, "Display is ON\n");
 
return true;
 }
@@ -1256,7 +1256,7 @@ int mipi_dbi_spi_init(struct spi_device *spi, struct 
mipi_dbi *dbi,
 
mutex_init(>cmdlock);
 
-   DRM_DEBUG_DRIVER("SPI speed: %uMHz\n", spi->max_speed_hz / 100);
+   drm_dbg_driver(NULL, "SPI speed: %uMHz\n", spi->max_speed_hz / 100);
 
return 0;
 }
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 4b8532cf2ae6..2bac5e8fd550 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -589,7 +589,7 @@ void __drm_err(const char *format, ...);
 #define DRM_DEBUG(fmt, ...)\
__drm_dbg(DRM_UT_CORE, fmt, ##__VA_ARGS__)
 
-/* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */
+/* NOTE: this is deprecated in favor of drm_dbg_driver(NULL, ...). */
 #define DRM_DEBUG_DRIVER(fmt, ...) \
__drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
 
-- 
2.39.2

Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS

On Tue, 06 Jun 2023 20:34:19 +0530, Laurent Pinchart wrote:
> Hi Siddh,
> 
> Thank you for the patch.

Anytime :)

> > -   DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(dev, "\n");
> 
> This message is pretty useless, it could be dropped on top of this
> series.

Okay.

> > -   DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(NULL, "\n");
> 
> Same.

Okay.

> > -   DRM_DEBUG_KMS("\n");
> > + drm_dbg_kms(>drm, "\n");
> 
> Same.

Okay.

> With the commit subject fixed,
> 
> Reviewed-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com>

Thanks,
Siddh

[PATCH v9 1/8] Revert "drm: mipi-dsi: Convert logging to drm_* functions."

This reverts commit 1040e424353f5f4d39f6f3aa8723eb3bd6ea6446.

It used an incorrect way to use drm_* functions. Only drm_device ptrs
should be passed, but the mentioned commit passed mipi_dsi_host ptr.
It worked by accident due to macro magic.

Reported-by: Jani Nikula 
Reviewed-by: Jani Nikula 
Signed-off-by: Siddh Raman Pant 
---
 drivers/gpu/drm/drm_mipi_dsi.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 3fd6c733ff4e..a37af4edf394 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -33,7 +33,6 @@
 
 #include 
 #include 
-#include 
 
 #include 
 
@@ -156,18 +155,19 @@ static int mipi_dsi_device_add(struct mipi_dsi_device 
*dsi)
 static struct mipi_dsi_device *
 of_mipi_dsi_device_add(struct mipi_dsi_host *host, struct device_node *node)
 {
+   struct device *dev = host->dev;
struct mipi_dsi_device_info info = { };
int ret;
u32 reg;
 
if (of_alias_from_compatible(node, info.type, sizeof(info.type)) < 0) {
-   drm_err(host, "modalias failure on %pOF\n", node);
+   dev_err(dev, "modalias failure on %pOF\n", node);
return ERR_PTR(-EINVAL);
}
 
ret = of_property_read_u32(node, "reg", );
if (ret) {
-   drm_err(host, "device node %pOF has no valid reg property: 
%d\n",
+   dev_err(dev, "device node %pOF has no valid reg property: %d\n",
node, ret);
return ERR_PTR(-EINVAL);
}
@@ -202,21 +202,22 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
  const struct mipi_dsi_device_info *info)
 {
struct mipi_dsi_device *dsi;
+   struct device *dev = host->dev;
int ret;
 
if (!info) {
-   drm_err(host, "invalid mipi_dsi_device_info pointer\n");
+   dev_err(dev, "invalid mipi_dsi_device_info pointer\n");
return ERR_PTR(-EINVAL);
}
 
if (info->channel > 3) {
-   drm_err(host, "invalid virtual channel: %u\n", info->channel);
+   dev_err(dev, "invalid virtual channel: %u\n", info->channel);
return ERR_PTR(-EINVAL);
}
 
dsi = mipi_dsi_device_alloc(host);
if (IS_ERR(dsi)) {
-   drm_err(host, "failed to allocate DSI device %ld\n",
+   dev_err(dev, "failed to allocate DSI device %ld\n",
PTR_ERR(dsi));
return dsi;
}
@@ -227,7 +228,7 @@ mipi_dsi_device_register_full(struct mipi_dsi_host *host,
 
ret = mipi_dsi_device_add(dsi);
if (ret) {
-   drm_err(host, "failed to add DSI device %d\n", ret);
+   dev_err(dev, "failed to add DSI device %d\n", ret);
kfree(dsi);
return ERR_PTR(ret);
}
-- 
2.39.2

Re: PROBLEM: AMD Ryzen 9 7950X iGPU - Blinking Issue

2023-06-07 Thread Felix Richter

Hi Guys,

so I checked, the kernel I am running has this commit
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

/commit/?id=08da182175db4c7f80850354849d95f2670e8cd9) applied already!

https://github.com/ju6ge/linux/commit/917680e6056aa288cac288d3afd2745d372beb61u

And the bug of display flickering persists with or without the
amdgpu.sg_display=0 variable applied!

Kind regards,
Felix Richter

On 6/5/23 16:11, Alex Deucher wrote:

+ Hamza
This is a known issue. You can workaround it by setting
amdgpu.sg_display=0. It should be issue should be fixed in:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=08da182175db4c7f80850354849d95f2670e8cd9

Alex

Now if this is the desired long term fix I do not know …

Kind regards,
Felix Richter

On 02.05.23 16:12, Linux regression tracking (Thorsten Leemhuis) wrote:

On 02.05.23 15:48, Felix Richter wrote:

On 5/2/23 15:34, Linux regression tracking (Thorsten Leemhuis) wrote:

On 02.05.23 15:13, Alex Deucher wrote:

On Tue, May 2, 2023 at 7:45 AM Linux regression tracking (Thorsten
Leemhuis) wrote:

On 30.04.23 13:44, Felix Richter wrote:

Hi,

I am running into an issue with the integrated GPU of the Ryzen 9
7950X. It seems to be a regression from kernel version 6.1 to 6.2.
The bug materializes in from of my monitor blinking, meaning it
turns full white shortly. This happens very often so that the
system becomes unpleasant to use.

I am running the Archlinux Kernel:
The Issue happens on the bleeding edge kernel: 6.2.13
Switching back to the LTS kernel resolves the issue: 6.1.26

I have two monitors attached to the system. One 42 inch 4k Display
and a 24 inch 1080p Display and am running sway as my desktop.

Let me know if there is more information I could provide to help
narrow down the issue.

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced v6.1..v6.2
#regzbot title drm: amdgpu: system becomes unpleasant to use after
monitor starts blinking and turns full white
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify
when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags
pointing
to the report (the parent of this mail). See page linked in footer for
details.

This sounds exactly like the issue that was fixed in this patch which
is already on it's way to Linus:
https://gitlab.freedesktop.org/agd5f/linux/-/commit/08da182175db4c7f80850354849d95f2670e8cd9

FWIW, you in the flood of emails likely missed that this is the same
thread where you yesterday replied "If the module parameter didn't help
then perhaps you are seeing some other issue. Can you bisect?". That's
why I decided to add this to the tracking. Or am I missing something
obvious here?

/me looks around again and can't see anything, but that doesn't have to
mean anything...

Felix, btw, this guide might help you with the bisection, even if it's
just for kernel compilation:

https://docs.kernel.org/next/admin-guide/quickly-build-trimmed-linux.html

And to indirectly reply to your mail from yesterday[1]. You might want
to ignore the arch linux kernel git repo and just do a bisection between
6.1 and the latest 6.2.y kernel using upstream repos; and if I were you
I'd also try 6.3 or even mainline before that, in case the issue was
fixed already.

[1]
https://lore.kernel.org/all/04749ee4-0728-92fe-bcb0-a7320279e...@felixrichter.tech/

Thanks for the pointers, I'll do a bisection on my desktop from 6.1 to
the newest commit.

FWIW, I wonder what you actually mean with "newest commit" here: a
bisection between 6.1 and mainline HEAD might be a waste of time, *if*
this is something that only happens in 6.2.y (say due to a broken or
incomplete backport)

That was the part I was mostly unsure about … where
to start from.

I was planning to use PKGBUILD scripts from arch to achieve the same
configuration as I would when installing
the package and just rewrite the script to use a local copy of the
source code instead of the repository.
That way I can just use the bisect command, rebuild the package and test
again.

In my experience trying to deal with Linux distro's package managers
creates more trouble than it's worth.

But I probably won't be able to finish it this week, since I am on
vacation starting tomorrow and will not have access to the computer in
question. I will be back next week, by that time the patch Alex is
talking about might
already be in mainline. So if that fixes it, I will notice and let you
know. If not I will do the bisection to figure out what the actual issue
is.

Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem

2023-06-07 Thread Heiko Stübner

Am Mittwoch, 7. Juni 2023, 00:37:53 CEST schrieb Conor Dooley:
> On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote:
> > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu:
> > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote:
> > > >> Add bindings for JH7110 display subsystem which
> > > >> has a display controller verisilicon dc8200
> > > >> and an HDMI interface.
> 
> > > >> +description:
> > > >> +  The StarFive SoC uses the HDMI signal transmiter based on 
> > > >> innosilicon IP
> > > > Is innosilicon the same thing as verisilicon? Also
> > > > s/transmiter/transmitter/, both here and in the title.
> > > 
> > > I think that is not the same, I remember Rockchip has used a HDMI 
> > > transmitter from
> > > 
> > > Innosilicon, and there is a existing driver for that in mainline.
> > 
> > Yep, I think Innosilicon is the company you turn to when you want to save
> > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses
> > Designware hdmi blocks and looking at the history only the rk3036 ever
> > used an Innosilicon block.
> > 
> > Looking at the history, 2016 really was a long time ago :-D.
> > 
> > > So Keith, if that's true, I think it is better to seperate the HDMI 
> > > stuff and reuse existing driver.
> > 
> > I'm not so sure about that - at least from a cursory glance :-) .
> > 
> > The registers do look slightly different and I don't know how much
> > the IP changed between the rk3036-version and the jh7110 version.
> > 
> > At the very least, I know my rk3036 board isn't booting right now, so
> > I can't really provide help for generalizing the rockchip-driver.
> > 
> > At the very least both the binding and driver could drop the "starfive-hdmi"
> > and actually use the Innosilicon in the naming somewhere, so that it's
> > clear for future developers :-)
> 
> Seeing "based on" always makes me a little bit nervous to be honest when
> it comes to using a compatible from the IP. Is it the IP? What version
> is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort
> of "innosilicon,hdmi" would be more future/IP-silliness proof.
> Driver can always be generic & bind against "innosilicon,hdmi" until
> that becomes impossible.


what Connor said makes a lot of sense. Just name the compatible
after the actual implementation - aka "starfive,jh7110-hdmi" .

This is similar to what the rk3036 does with its
"rockchip,rk3036-inno-hdmi". That way you're nicely independent
and future proof.


Heiko

Re: [PATCH 00/30] fbdev: Make userspace interfaces optional

2023-06-07 Thread Geert Uytterhoeven

Hi Thomas,

Thanks for your series!

Over the past few days, I have been giving this some thought, that's
why I am replying only now...

On Mon, Jun 5, 2023 at 4:48 PM Thomas Zimmermann  wrote:
> Add the new config option FB_DEVICE. If enabled, fbdev provides
> traditional userspace interfaces in devfs, sysfs and procfs, such
> as /dev/fb0 or /proc/fb.
>
> Modern Linux distrobutions have adopted DRM drivers for graphics
> output and use fbdev only for the kernel's framebuffer console.
> Userspace has also moved on, with no new fbdev code being written
> and existing support being removed.
>
> OTOH, fbdev provides userspace a way of accessing kernel or I/O
> memory, which might compromise the system's security. See the recent

True, in some form...
The amount of "kernel memory" that can be accessed is controlled by
the fbdev driver (or by the DRM fbdev emulation). Nothing unsafe here.
The I/O memory that can be accessed (if any) is controlled by the
fbdev driver, and the full capabilities (e.g. DMA to random addresses)
exported depend on the actual hardware.

> commit c8687694bb1f ("drm/fbdev-generic: prohibit potential
> out-of-bounds access") for an example. Disabling fbdev userspace

IMHO that's not a good example for the point you're trying to make,
but merely bad bounds checking in kernel copying code...

> interfaces is therefore a useful feature to limit unecessary
> exposure of fbdev code to processes of low privilegues.

This actually depends on the permissions on /dev/fb*...

BTW, I am wondering if it would be possible to write a DRM emulation
layer on top of (basic, e.g. no MMIO, just fb) fbdev?

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: (subset) [RESEND PATCH v2 0/6] Add display support on the stm32f746-disco board

2023-06-07 Thread Neil Armstrong

Hi,

On Wed, 07 Jun 2023 08:31:33 +0200, Dario Binacchi wrote:
> The series adds support for the display on the stm32f746-disco board,
> along with a generic patch that adds the "bpp" parameter to the stm-drm
> module. The intention is to allow users to size, within certain limits,
> the memory footprint required by the framebuffer.
> 
> Changes in v2:
> - Add 'Acked-by' tag of Conor Dooley.
> - Fix build warning reported by kernel test robot.
> - Add 'Reported-by' tag of kernel test robot.
> 
> [...]

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

[4/6] dt-bindings: display: simple: add Rocktech RK043FN48H
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=c42a37a27c777d63961dd634a30f7c887949491a
[5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel
  
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=13cdd12a9f934158f4ec817cf048fcb4384aa9dc

-- 
Neil

Re: [PATCH v9 8/8] drm: Remove usage of deprecated DRM_DEBUG_KMS

2023-06-07 Thread Jani Nikula

On Wed, 07 Jun 2023, Laurent Pinchart  wrote:
> Hi Jani,
>
> On Wed, Jun 07, 2023 at 12:39:44AM +0300, Jani Nikula wrote:
>> On Tue, 06 Jun 2023, Laurent Pinchart wrote:
>> > On Tue, Jun 06, 2023 at 04:15:22PM +0530, Siddh Raman Pant wrote:
>> >> @@ -777,7 +793,7 @@ int drm_client_modeset_probe(struct drm_client_dev 
>> >> *client, unsigned int width,
>> >>   int i, ret = 0;
>> >>   bool *enabled;
>> >>  
>> >> - DRM_DEBUG_KMS("\n");
>> >> + drm_dbg_kms(dev, "\n");
>> >
>> > This message is pretty useless, it could be dropped on top of this
>> > series.
>> 
>> They do debug log the function being called.
>
> I overlooked the fact that ___drm_dbg() prints the caller's function
> name using __builtin_return_address(). It thus has marginally more value
> than I thought. Still, function tracing is best performed with ftrace().

I'm not going to argue this one too much, but it can be quite a step
getting a random bug reporter from providing dmesgs to running ftrace.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

[PATCH v3] drm/i915: Fix a VMA UAF for multi-gt platform

2023-06-07 Thread Nirmoy Das

Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.

Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.

v2: Use gt id to detect multi-tile(Andi)
Fix the incorrect error path.
v3: Add more comment(Andi)
Use the new gt var when possible(Andrzej)

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Sushma Venkatesh Reddy 
Signed-off-by: Nirmoy Das 
Tested-by: Andi Shyti 
Reviewed-by: Andi Shyti 
Reviewed-by: Andrzej Hajda 
---
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 21 +--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 5fb459ea4294..1de9de1e4782 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2692,6 +2692,7 @@ static int
 eb_select_engine(struct i915_execbuffer *eb)
 {
struct intel_context *ce, *child;
+   struct intel_gt *gt;
unsigned int idx;
int err;
 
@@ -2715,10 +2716,17 @@ eb_select_engine(struct i915_execbuffer *eb)
}
}
eb->num_batches = ce->parallel.number_children + 1;
+   gt = ce->engine->gt;
 
for_each_child(ce, child)
intel_context_get(child);
-   intel_gt_pm_get(ce->engine->gt);
+   intel_gt_pm_get(gt);
+   /*
+* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+   if (gt->info.id)
+   intel_gt_pm_get(to_gt(gt->i915));
 
if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
err = intel_context_alloc_state(ce);
@@ -2757,7 +2765,10 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
 
 err:
-   intel_gt_pm_put(ce->engine->gt);
+   if (gt->info.id)
+   intel_gt_pm_put(to_gt(gt->i915));
+
+   intel_gt_pm_put(gt);
for_each_child(ce, child)
intel_context_put(child);
intel_context_put(ce);
@@ -2770,6 +2781,12 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
 
i915_vm_put(eb->context->vm);
+   /*
+* This works in conjunction with eb_select_engine() to prevent
+* i915_vma_parked() from interfering while execbuf validates vmas.
+*/
+   if (eb->gt->info.id)
+   intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
for_each_child(eb->context, child)
intel_context_put(child);
-- 
2.39.0

Re: [PATCH 08/30] fbdev/broadsheetfb: Call device_remove_file() with hardware device

Thomas Zimmermann  writes:

> Call device_remove_file() with the same device that has been used
> for device_create_file(), which is the hardware device stored in
> struct fb_info.device. Prepares fbdev for making struct fb_info.dev
> optional.
>
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 07/30] fbdev/aty128fb: Use hardware device as backlight parent

Thomas Zimmermann  writes:

> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform

2023-06-07 Thread Nirmoy Das




On 6/7/2023 8:20 AM, Andrzej Hajda wrote:



On 06.06.2023 22:27, Nirmoy Das wrote:

Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.

Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.

v2: Use gt id to detect multi-tile(Andi)
 Fix the incorrect error path.

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Sushma Venkatesh Reddy 
Tested-by: Andi Shyti 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12 
  1 file changed, 12 insertions(+)

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

index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
  eb_select_engine(struct i915_execbuffer *eb)
  {
  struct intel_context *ce, *child;
+    struct intel_gt *gt;
  unsigned int idx;
  int err;
  @@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)
  }
  }
  eb->num_batches = ce->parallel.number_children + 1;
+    gt = ce->engine->gt;
    for_each_child(ce, child)
  intel_context_get(child);
  intel_gt_pm_get(ce->engine->gt);


intel_gt_pm_get(gt)



+    /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+ * free VMAs while execbuf ioctl is validating VMAs.
+ */
+    if (gt->info.id)
+    intel_gt_pm_get(to_gt(gt->i915));
    if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {
  err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
  return err;
    err:
+    if (gt->info.id)
+    intel_gt_pm_put(to_gt(gt->i915));
+
  intel_gt_pm_put(ce->engine->gt);


intel_gt_pm_put(gt)


Will change both.


Reviewed-by: Andrzej Hajda 



Thanks,

Nirmoy



Regards
Andrzej


  for_each_child(ce, child)
  intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
  struct intel_context *child;
    i915_vm_put(eb->context->vm);
+    if (eb->gt->info.id)
+    intel_gt_pm_put(to_gt(eb->gt->i915));
  intel_gt_pm_put(eb->gt);
  for_each_child(eb->context, child)
  intel_context_put(child);

Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform

2023-06-07 Thread Nirmoy Das




On 6/6/2023 10:56 PM, Andi Shyti wrote:

Hi Nirmoy,

On Tue, Jun 06, 2023 at 10:27:55PM +0200, Nirmoy Das wrote:

Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.

Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.

v2: Use gt id to detect multi-tile(Andi)
 Fix the incorrect error path.

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Sushma Venkatesh Reddy 
Tested-by: Andi Shyti 
Signed-off-by: Nirmoy Das 

I wonder if we need any Fixes tag here, maybe this:

Fixes: d93939730347 ("drm/i915: Remove the vma refcount")


No, vma refcount is not enough unfortunately. Issue is i915_vma_parked() 
expects only one GT.






---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
  eb_select_engine(struct i915_execbuffer *eb)
  {
struct intel_context *ce, *child;
+   struct intel_gt *gt;
unsigned int idx;
int err;
  
@@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)

}
}
eb->num_batches = ce->parallel.number_children + 1;
+   gt = ce->engine->gt;
  
  	for_each_child(ce, child)

intel_context_get(child);
intel_gt_pm_get(ce->engine->gt);
+   /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+   if (gt->info.id)
+   intel_gt_pm_get(to_gt(gt->i915));
  
  	if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {

err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
  
  err:

+   if (gt->info.id)
+   intel_gt_pm_put(to_gt(gt->i915));
+
intel_gt_pm_put(ce->engine->gt);
for_each_child(ce, child)
intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
  
  	i915_vm_put(eb->context->vm);

+   if (eb->gt->info.id)
+   intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);

I would add a comment up here, just not to scare people when they
see this.



I can add a comment pairing comment mentioning

eb_select_engine().


Reviewed-by: Andi Shyti 



Thanks,

Nirmoy



Andi


for_each_child(eb->context, child)
intel_context_put(child);
--
2.39.0

Re: [PATCH 06/30] fbdev/aty128fb: Reorder backlight and framebuffer init/cleanup

Thomas Zimmermann  writes:

> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 05/30] fbdev/atyfb: Use hardware device as backlight parent

Thomas Zimmermann  writes:

> Use the hardware device in struct fb_info.device as parent of the
> backlight device. Aligns the driver with the rest of the codebase
> and prepares fbdev for making struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 2/9] riscv: dts: starfive: jh7110: add dc controller node

2023-06-07 Thread Krzysztof Kozlowski

On 02/06/2023 09:40, Keith Zhao wrote:
> Add the dc controller and hdmi node for the Starfive JH7110 SoC.
> 
> Signed-off-by: Keith Zhao 
> ---
>  .../jh7110-starfive-visionfive-2.dtsi | 87 +++
>  arch/riscv/boot/dts/starfive/jh7110.dtsi  | 46 ++
>  2 files changed, 133 insertions(+)
> 
> diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi 
> b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> index 1155b97b593d..8dc6c8a15c59 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
> @@ -31,6 +31,21 @@ memory@4000 {
>   reg = <0x0 0x4000 0x1 0x0>;
>   };
>  
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0x0 0x2000>;
> + alignment = <0x0 0x1000>;
> + alloc-ranges = <0x0 0x8000 0x0 0x2000>;
> + linux,cma-default;
> + };
> + };
> +
>   gpio-restart {
>   compatible = "gpio-restart";
>   gpios = < 35 GPIO_ACTIVE_HIGH>;
> @@ -214,6 +229,41 @@ GPOEN_DISABLE,
>   slew-rate = <0>;
>   };
>   };
> +
> + hdmi_pins: hdmi-0 {
> + hdmi-scl-pins {
> + pinmux =  +  GPOEN_SYS_HDMI_DDC_SCL,
> +  GPI_SYS_HDMI_DDC_SCL)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-sda-pins {
> + pinmux =  +  GPOEN_SYS_HDMI_DDC_SDA,
> +  GPI_SYS_HDMI_DDC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-cec-pins {
> + pinmux =  +  GPOEN_SYS_HDMI_CEC_SDA,
> +  GPI_SYS_HDMI_CEC_SDA)>;
> + input-enable;
> + bias-pull-up;
> + };
> +
> + hdmi-hpd-pins {
> + pinmux =  +  GPOEN_ENABLE,
> +  GPI_SYS_HDMI_HPD)>;
> + input-enable;
> + bias-disable; /* external pull-up */
> + };
> + };
> +
>  };
>  
>   {
> @@ -221,3 +271,40 @@  {
>   pinctrl-0 = <_pins>;
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + hdmi_in: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + hdmi_input: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_out_dpi0>;

This does not make any sense. You wrote in bindings that this is display
output, but you call it HDMI input. If this is input, where is your output?

> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + dc_out: port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + dc_out_dpi0: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <_input>;
> + };
> +

Stray blank line.

> + };
> +};
> diff --git a/arch/riscv/boot/dts/starfive/jh7110.dtsi 
> b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> index 9acb5fb1716d..66be6e65a066 100644
> --- a/arch/riscv/boot/dts/starfive/jh7110.dtsi
> +++ b/arch/riscv/boot/dts/starfive/jh7110.dtsi
> @@ -249,6 +249,11 @@ tdm_ext: tdm-ext-clock {
>   #clock-cells = <0>;
>   };
>  
> + display: display-subsystem {
> + compatible = "verisilicon,display-subsystem";

Drop fake nodes which do not represent hardware. Instead, DTS and
bindings should describe real hardware.


> + ports = <_out>;
> + };
> +
>   soc {
>   compatible = "simple-bus";
>   interrupt-parent = <>;
> @@ -570,5 +575,46 @@ voutcrg: clock-controller@295c {
>   #reset-cells = <1>;
>   power-domains = < JH7110_PD_VOUT>;
>   };
> +
> + dc8200: dc8200@2940 {

Node names should be generic. See also explanation and list of examples
in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation

> + compatible = "verisilicon,dc8200";
> + reg = <0x0 0x2940 0x0

Re: [PATCH 04/30] fbdev/atyfb: Reorder backlight and framebuffer init/cleanup

Thomas Zimmermann  writes:

> The driver's backlight code requires the framebuffer to be
> registered. Therefore reorder the init and cleanup calls for
> both data structures.
>
> Signed-off-by: Thomas Zimmermann 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 03/30] backlight/lv5207lp: Compare against struct fb_info.device

Thomas Zimmermann  writes:

> Struct lv5207lp_platform_data refers to a platform device within
> the Linux device hierarchy. The test in lv5207lp_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem

2023-06-07 Thread Krzysztof Kozlowski

On 02/06/2023 09:40, Keith Zhao wrote:
> Add bindings for JH7110 display subsystem which
> has a display controller verisilicon dc8200
> and an HDMI interface.
> 
> Signed-off-by: Keith Zhao 
> ---
>  .../display/verisilicon/starfive-hdmi.yaml|  93 +++
>  .../display/verisilicon/verisilicon-dc.yaml   | 110 ++
>  .../display/verisilicon/verisilicon-drm.yaml  |  42 +++
>  .../devicetree/bindings/vendor-prefixes.yaml  |   2 +
>  MAINTAINERS   |   7 ++
>  5 files changed, 254 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
>  create mode 100644 
> Documentation/devicetree/bindings/display/verisilicon/verisilicon-drm.yaml
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml
> new file mode 100644
> index ..c30b7954a355
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/verisilicon/starfive-hdmi.yaml

Filename matching compatible.

> @@ -0,0 +1,93 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/verisilicon/starfive-hdmi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive HDMI transmiter
> +
> +description:
> +  The StarFive SoC uses the HDMI signal transmiter based on innosilicon IP
> +  to generate HDMI signal from its input and transmit the signal to the 
> screen.
> +
> +maintainers:
> +  - Keith Zhao 
> +  - ShengYang Chen 
> +
> +properties:
> +  compatible:
> +const: starfive,hdmi

Conor already commented on this.

> +
> +  reg:
> +minItems: 1
> +
> +  interrupts:
> +items:
> +  - description: The HDMI hot plug detection interrupt.
> +
> +  clocks:
> +items:
> +  - description: System clock of HDMI module.
> +  - description: Mclk clock of HDMI audio.
> +  - description: Bclk clock of HDMI audio.
> +  - description: Pixel clock generated by HDMI module.
> +
> +  clock-names:
> +items:
> +  - const: sysclk
> +  - const: mclk
> +  - const: bclk
> +  - const: pclk
> +
> +  resets:
> +items:
> +  - description: Reset for HDMI module.
> +
> +  reset-names:
> +items:
> +  - const: hdmi_tx
> +
> +  '#sound-dai-cells':
> +const: 0
> +
> +  port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
> +  Port node with one endpoint connected to a display connector node.

One port, so how do you get data? From where does it come?

> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - clocks
> +  - clock-names
> +  - resets
> +  - reset-names
> +  - '#sound-dai-cells'
> +  - port
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +hdmi: hdmi@2959 {
> +  compatible = "starfive,hdmi";
> +  reg = <0x2959 0x4000>;
> +  interrupts = <99>;
> +  clocks = < 17>,
> +   < 15>,
> +   < 16>,
> +   <_pixelclk>;
> +  clock-names = "sysclk", "mclk","bclk","pclk";
> +  resets = < 9>;
> +  reset-names = "hdmi_tx";
> +  #sound-dai-cells = <0>;
> +  hdmi_in: port {
> +  #address-cells = <1>;
> +  #size-cells = <0>;
> +  hdmi_input: endpoint@0 {
> +reg = <0>;
> +remote-endpoint = <_out_dpi0>;

Mixed up indentation.

> +  };
> +  };
> +};
> diff --git 
> a/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml 
> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml
> new file mode 100644
> index ..1322502c4cde
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/display/verisilicon/verisilicon-dc.yaml

Same problem.

> @@ -0,0 +1,110 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/verisilicon/verisilicon-dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: StarFive display controller
> +
> +description:
> +  The StarFive SoC uses the display controller based on Verisilicon IP
> +  to transfer the image data from a video memory
> +  buffer to an external LCD interface.
> +
> +maintainers:
> +  - Keith Zhao 
> +  - ShengYang Chen 
> +
> +properties:
> +  compatible:
> +const: verisilicon,dc8200
> +
> +  reg:
> +maxItems: 3
> +
> +  interrupts:
> +items:
> +  - description: The interrupt will be generated when DC finish one frame
> +
> +  clocks:
> +items:
> +  - description: Clock for display system noc bus.
> +  - description: Pixel clock for display channel 0.
> +  - description: Pixel clock for display channel 1.
> +  - description: Clock for axi interface of display controller.

Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device

Thomas Zimmermann  writes:

> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---

I agree with what was discussed in this thread, the check fix and rename
could be split in separate patches to make it easier to understand what
is changed. Regardless, feel free to add:

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [PATCH 01/30] backlight/bd6107: Compare against struct fb_info.device

Thomas Zimmermann  writes:

> Struct bd6107_platform_data refers to a platform device within
> the Linux device hierarchy. The test in bd6107_backlight_check_fb()
> compares it against the fbdev device in struct fb_info.dev, which
> is different. Fix the test by comparing to struct fb_info.device.
>
> Fixes a bug in the backlight driver and prepares fbdev for making
> struct fb_info.dev optional.
>
> Signed-off-by: Thomas Zimmermann 
> Cc: Lee Jones 
> Cc: Daniel Thompson 
> Cc: Jingoo Han 
> ---

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

[PATCH] drm/ingenic: Kconfig: select REGMAP and REGMAP_MMIO

Otherwise its failed to pass basic compile test on platform without
REGMAP_MMIO selected by defconfig

make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64el-linux-gnuabi64-

  SYNCinclude/config/auto.conf.cmd
  Checking missing-syscalls for N32
  CALLscripts/checksyscalls.sh
  Checking missing-syscalls for O32
  CALLscripts/checksyscalls.sh
  CALLscripts/checksyscalls.sh
  MODPOST Module.symvers
ERROR: modpost: "__devm_regmap_init_mmio_clk" 
[drivers/gpu/drm/ingenic/ingenic-drm.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:136: Module.symvers] Error 1
make: *** [Makefile:1978: modpost] Error 2

Signed-off-by: Sui Jingfeng 
---
 drivers/gpu/drm/ingenic/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/ingenic/Kconfig b/drivers/gpu/drm/ingenic/Kconfig
index a53f475d33df..7457c0b65034 100644
--- a/drivers/gpu/drm/ingenic/Kconfig
+++ b/drivers/gpu/drm/ingenic/Kconfig
@@ -5,6 +5,8 @@ config DRM_INGENIC
depends on CMA
depends on OF
depends on COMMON_CLK
+   select REGMAP
+   select REGMAP_MMIO
select DRM_BRIDGE
select DRM_PANEL_BRIDGE
select DRM_KMS_HELPER
-- 
2.25.1

Re: [PATCH 0/5] drm/ssd130x: A few enhancements and cleanups

Thomas Zimmermann  writes:

Hello Thomas,

> Hi Javierm,
>
> I've read through the patches and they look correct to me.
>
> Reviewed-by: Thomas Zimmermann 
>

Thanks a lot for your review!

> But I had one question about the page size. You round up to multiples of 
> page_size in several places. That could lead to an out-of-bounds access. 
> Do you need to allocate GEM buffers to be multiples of page_size as well?
>

That's a good point and I would need to have a closer look to the driver
to determine if that's needed or not as well. If that's the case though,
the issue is already present in the driver. We could fix it as follow-up.

> Best regards
> Thomas
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [RESEND PATCH v2 4/6] dt-bindings: display: simple: add Rocktech RK043FN48H

2023-06-07 Thread Raphael Gallais-Pou



On 6/7/23 08:31, Dario Binacchi wrote:
> Add compatible to panel-simple for Rocktech Displays Limited
> RK043FN48H 4.3" 480x272 LCD-TFT panel.
>
> Signed-off-by: Dario Binacchi 
> Acked-by: Conor Dooley 
Reviewed-by: Raphael Gallais-Pou 


Thanks,

Raphaël

Re: [RESEND PATCH v2 3/6] ARM: dts: stm32: support display on stm32f746-disco board

2023-06-07 Thread Jagan Teki

On Wed, Jun 7, 2023 at 12:01 PM Dario Binacchi
 wrote:
>
> Add support to Rocktech RK043FN48H display on stm32f746-disco board.
>
> Signed-off-by: Dario Binacchi 
> ---
>
> (no changes since v1)
>
>  arch/arm/boot/dts/stm32f746-disco.dts | 51 +++
>  1 file changed, 51 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f746-disco.dts 
> b/arch/arm/boot/dts/stm32f746-disco.dts
> index c11616ed5fc6..cda423b6a874 100644
> --- a/arch/arm/boot/dts/stm32f746-disco.dts
> +++ b/arch/arm/boot/dts/stm32f746-disco.dts
> @@ -60,10 +60,41 @@ memory@c000 {
> reg = <0xC000 0x80>;
> };
>
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   linux,cma {
> +   compatible = "shared-dma-pool";
> +   no-map;
> +   size = <0x8>;
> +   linux,dma-default;
> +   };
> +   };

This looks unrelated to display enablement, isn't it?

Jagan.

Re: [PATCH 1/9] dt-bindings: display: Add yamls for JH7110 display subsystem

2023-06-07 Thread Maxime Ripard

On Tue, Jun 06, 2023 at 11:37:53PM +0100, Conor Dooley wrote:
> On Wed, Jun 07, 2023 at 12:22:33AM +0200, Heiko Stübner wrote:
> > Am Dienstag, 6. Juni 2023, 20:41:17 CEST schrieb Shengyu Qu:
> > > > On Fri, Jun 02, 2023 at 03:40:35PM +0800, Keith Zhao wrote:
> > > >> Add bindings for JH7110 display subsystem which
> > > >> has a display controller verisilicon dc8200
> > > >> and an HDMI interface.
> 
> > > >> +description:
> > > >> +  The StarFive SoC uses the HDMI signal transmiter based on 
> > > >> innosilicon IP
> > > > Is innosilicon the same thing as verisilicon? Also
> > > > s/transmiter/transmitter/, both here and in the title.
> > > 
> > > I think that is not the same, I remember Rockchip has used a HDMI 
> > > transmitter from
> > > 
> > > Innosilicon, and there is a existing driver for that in mainline.
> > 
> > Yep, I think Innosilicon is the company you turn to when you want to save
> > a bit of money ;-) . In the bigger SoCs Rockchip most of the time uses
> > Designware hdmi blocks and looking at the history only the rk3036 ever
> > used an Innosilicon block.
> > 
> > Looking at the history, 2016 really was a long time ago :-D.
> > 
> > > So Keith, if that's true, I think it is better to seperate the HDMI 
> > > stuff and reuse existing driver.
> > 
> > I'm not so sure about that - at least from a cursory glance :-) .
> > 
> > The registers do look slightly different and I don't know how much
> > the IP changed between the rk3036-version and the jh7110 version.
> > 
> > At the very least, I know my rk3036 board isn't booting right now, so
> > I can't really provide help for generalizing the rockchip-driver.
> > 
> > At the very least both the binding and driver could drop the "starfive-hdmi"
> > and actually use the Innosilicon in the naming somewhere, so that it's
> > clear for future developers :-)
> 
> Seeing "based on" always makes me a little bit nervous to be honest when
> it comes to using a compatible from the IP. Is it the IP? What version
> is it? etc. Perhaps "starfive,jh7110-hdmi" & falling back to some sort
> of "innosilicon,hdmi" would be more future/IP-silliness proof.
> Driver can always be generic & bind against "innosilicon,hdmi" until
> that becomes impossible.

Given that Neil was saying that there's at least two
generations/revisions/models of an HDMI controller from Innosilicon, I'm
not sure that compatible is enough to reach that goal anyway.

Maxime


signature.asc
Description: PGP signature

Re: [RESEND PATCH v2 4/6] dt-bindings: display: simple: add Rocktech RK043FN48H

2023-06-07 Thread Jagan Teki

On Wed, Jun 7, 2023 at 12:01 PM Dario Binacchi
 wrote:
>
> Add compatible to panel-simple for Rocktech Displays Limited
> RK043FN48H 4.3" 480x272 LCD-TFT panel.
>
> Signed-off-by: Dario Binacchi 
> Acked-by: Conor Dooley 
>
> ---

Reviewed-by: Jagan Teki

Re: [RESEND PATCH v2 5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel

2023-06-07 Thread Jagan Teki

On Wed, Jun 7, 2023 at 12:01 PM Dario Binacchi
 wrote:
>
> Add support for Rocktech RK043FN48H 4.3" (480x272) LCD-TFT panel.
>
> Signed-off-by: Dario Binacchi 
> Reported-by: kernel test robot 
> Closes: 
> https://lore.kernel.org/oe-kbuild-all/202306020343.jntwem0p-...@intel.com/
>
> ---

Reviewed-by: Jagan Teki

Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab


https://cgit.freedesktop.org/amd/drm-amd/


This one has a long time with no update.


On 2023/6/7 14:31, Sui Jingfeng wrote:

Hi,

On 2023/6/7 03:15, Alex Deucher wrote:

Applied.  Thanks!


Where is the official branch of drm/amdgpu, I can't find it on the 
internet.


Sorry for asking this silly question.





Alex

On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng  
wrote:
This patch replace the leading spaces with tab, make them keep 
aligned with

the rest of the config options. No functional change.

Signed-off-by: Sui Jingfeng 
---
  drivers/gpu/drm/amd/display/Kconfig | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig

index 2d8e55e29637..04ccfc70d583 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC
   Choose this option if you want to hit kdgb_break in assert.

  config DRM_AMD_SECURE_DISPLAY
-    bool "Enable secure display support"
-    depends on DEBUG_FS
-    depends on DRM_AMD_DC_FP
-    help
-    Choose this option if you want to
-    support secure display
-
-    This option enables the calculation
-    of crc of specific region via debugfs.
-    Cooperate with specific DMCU FW.
+   bool "Enable secure display support"
+   depends on DEBUG_FS
+   depends on DRM_AMD_DC_FP
+   help
+ Choose this option if you want to support secure display

+ This option enables the calculation of crc of specific 
region via

+ debugfs. Cooperate with specific DMCU FW.

  endmenu
--
2.25.1


--
Jingfeng

[RESEND PATCH v2 5/6] drm/panel: simple: add support for Rocktech RK043FN48H panel

Add support for Rocktech RK043FN48H 4.3" (480x272) LCD-TFT panel.

Signed-off-by: Dario Binacchi 
Reported-by: kernel test robot 
Closes: 
https://lore.kernel.org/oe-kbuild-all/202306020343.jntwem0p-...@intel.com/

---

Changes in v2:
- Fix build warning reported by kernel test robot.
- Add 'Reported-by' tag of kernel test robot.

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

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 065f378bba9d..3b10e78d07d9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3188,6 +3188,32 @@ static const struct panel_desc qishenglong_gopher2b_lcd 
= {
.connector_type = DRM_MODE_CONNECTOR_DPI,
 };
 
+static const struct display_timing rocktech_rk043fn48h_timing = {
+   .pixelclock = { 600, 900, 1200 },
+   .hactive = { 480, 480, 480 },
+   .hback_porch = { 8, 43, 43 },
+   .hfront_porch = { 2, 8, 8 },
+   .hsync_len = { 1, 1, 1 },
+   .vactive = { 272, 272, 272 },
+   .vback_porch = { 2, 12, 12 },
+   .vfront_porch = { 1, 4, 4 },
+   .vsync_len = { 1, 10, 10 },
+   .flags = DISPLAY_FLAGS_VSYNC_LOW | DISPLAY_FLAGS_HSYNC_LOW |
+DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_POSEDGE,
+};
+
+static const struct panel_desc rocktech_rk043fn48h = {
+   .timings = _rk043fn48h_timing,
+   .num_timings = 1,
+   .bpc = 8,
+   .size = {
+   .width = 95,
+   .height = 54,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
 static const struct display_timing rocktech_rk070er9427_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -4218,6 +4244,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "qishenglong,gopher2b-lcd",
.data = _gopher2b_lcd,
+   }, {
+   .compatible = "rocktech,rk043fn48h",
+   .data = _rk043fn48h,
}, {
.compatible = "rocktech,rk070er9427",
.data = _rk070er9427,
-- 
2.32.0

[RESEND PATCH v2 6/6] drm/stm: add an option to change FB bpp

Boards that use the STM32F{4,7} series have limited amounts of RAM. The
added parameter allows users to size, within certain limits, the memory
footprint required by the framebuffer.

Signed-off-by: Dario Binacchi 

---

(no changes since v1)

 drivers/gpu/drm/stm/drv.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 40df7d8c..65be2b442a6a 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -30,6 +30,11 @@
 #define STM_MAX_FB_WIDTH   2048
 #define STM_MAX_FB_HEIGHT  2048 /* same as width to handle orientation */
 
+static uint stm_bpp = 16;
+
+MODULE_PARM_DESC(bpp, "bits-per-pixel (default: 16)");
+module_param_named(bpp, stm_bpp, uint, 0644);
+
 static const struct drm_mode_config_funcs drv_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
@@ -93,6 +98,7 @@ static int drv_load(struct drm_device *ddev)
ddev->mode_config.min_height = 0;
ddev->mode_config.max_width = STM_MAX_FB_WIDTH;
ddev->mode_config.max_height = STM_MAX_FB_HEIGHT;
+   ddev->mode_config.preferred_depth = stm_bpp;
ddev->mode_config.funcs = _mode_config_funcs;
ddev->mode_config.normalize_zpos = true;
 
@@ -203,7 +209,7 @@ static int stm_drm_platform_probe(struct platform_device 
*pdev)
if (ret)
goto err_put;
 
-   drm_fbdev_dma_setup(ddev, 16);
+   drm_fbdev_dma_setup(ddev, stm_bpp);
 
return 0;
 
-- 
2.32.0

[RESEND PATCH v2 4/6] dt-bindings: display: simple: add Rocktech RK043FN48H

Add compatible to panel-simple for Rocktech Displays Limited
RK043FN48H 4.3" 480x272 LCD-TFT panel.

Signed-off-by: Dario Binacchi 
Acked-by: Conor Dooley 

---

Changes in v2:
- Add 'Acked-by' tag of Conor Dooley.

 .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml 
b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 01560fe226dd..bd6a92d2b41c 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -280,6 +280,8 @@ properties:
   - rocktech,rk101ii01d-ct
 # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel
   - rocktech,rk070er9427
+# Rocktech Display Ltd. RK043FN48H 4.3" 480x272 LCD-TFT panel
+  - rocktech,rk043fn48h
 # Samsung 13.3" FHD (1920x1080 pixels) eDP AMOLED panel
   - samsung,atna33xc20
 # Samsung 12.2" (2560x1600 pixels) TFT LCD panel
-- 
2.32.0

[RESEND PATCH v2 3/6] ARM: dts: stm32: support display on stm32f746-disco board

Add support to Rocktech RK043FN48H display on stm32f746-disco board.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 arch/arm/boot/dts/stm32f746-disco.dts | 51 +++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f746-disco.dts 
b/arch/arm/boot/dts/stm32f746-disco.dts
index c11616ed5fc6..cda423b6a874 100644
--- a/arch/arm/boot/dts/stm32f746-disco.dts
+++ b/arch/arm/boot/dts/stm32f746-disco.dts
@@ -60,10 +60,41 @@ memory@c000 {
reg = <0xC000 0x80>;
};
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   linux,cma {
+   compatible = "shared-dma-pool";
+   no-map;
+   size = <0x8>;
+   linux,dma-default;
+   };
+   };
+
aliases {
serial0 = 
};
 
+   backlight: backlight {
+   compatible = "gpio-backlight";
+   gpios = < 3 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   };
+
+   panel_rgb: panel-rgb {
+   compatible = "rocktech,rk043fn48h";
+   backlight = <>;
+   enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
+   status = "okay";
+   port {
+   panel_in_rgb: endpoint {
+   remote-endpoint = <_out_rgb>;
+   };
+   };
+   };
+
usbotg_hs_phy: usb-phy {
#phy-cells = <0>;
compatible = "usb-nop-xceiv";
@@ -99,6 +130,26 @@  {
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-0 = <_pins_a>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   port {
+   ltdc_out_rgb: endpoint {
+   remote-endpoint = <_in_rgb>;
+   };
+   };
+};
+
  {
status = "okay";
vmmc-supply = <_vcard>;
-- 
2.32.0

[RESEND PATCH v2 2/6] ARM: dts: stm32: add pin map for LTDC on stm32f7

Add pin configurations for using LTDC (LCD-tft Display Controller) on
stm32f746-disco board.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 arch/arm/boot/dts/stm32f7-pinctrl.dtsi | 35 ++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f7-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
index 9f65403295ca..f3f90b9bcd61 100644
--- a/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f7-pinctrl.dtsi
@@ -365,6 +365,41 @@ pins2 {
bias-pull-up;
};
};
+
+
+   ltdc_pins_a: ltdc-pins-a-0 {
+   pins {
+   pinmux = , 
/* LCD_B0 */
+,  
/* LCD_B4 */
+, 
/* LCD_VSYNC */
+, 
/* LCD_HSYNC */
+, 
/* LCD_CLK */
+, 
/* LCD_R0 */
+, 
/* LCD_R1 */
+, 
/* LCD_R2 */
+, 
/* LCD_R3 */
+, 
/* LCD_R4 */
+, 
/* LCD_R5 */
+, 
/* LCD_R6 */
+, 
/* LCD_R7 */
+, 
/* LCD_G0 */
+, 
/* LCD_G1 */
+, 
/* LCD_G2 */
+, 
/* LCD_G3 */
+, 
/* LCD_G4 */
+, 
/* LCD_B1 */
+, 
/* LCD_B2 */
+, 
/* LCD_B3 */
+, 
/* LCD_G5 */
+, 
/* LCD_G6 */
+, 
/* LCD_G7 */
+, 
/* LCD_B5 */
+, 
/* LCD_B6 */
+, 
/* LCD_B7 */
+; 
/* LCD_DE */
+   slew-rate = <2>;
+   };
+   };
};
};
 };
-- 
2.32.0

[RESEND PATCH v2 1/6] ARM: dts: stm32: add ltdc support on stm32f746 MCU

Add LTDC (Lcd-tft Display Controller) support.

Signed-off-by: Dario Binacchi 
---

(no changes since v1)

 arch/arm/boot/dts/stm32f746.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index dc868e6da40e..9c4ba0b7f239 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -507,6 +507,16 @@ pwm {
};
};
 
+   ltdc: display-controller@40016800 {
+   compatible = "st,stm32-ltdc";
+   reg = <0x40016800 0x200>;
+   interrupts = <88>, <89>;
+   resets = < STM32F7_APB2_RESET(LTDC)>;
+   clocks = < 1 CLK_LCD>;
+   clock-names = "lcd";
+   status = "disabled";
+   };
+
pwrcfg: power-config@40007000 {
compatible = "st,stm32-power-config", "syscon";
reg = <0x40007000 0x400>;
-- 
2.32.0

[RESEND PATCH v2 0/6] Add display support on the stm32f746-disco board

The series adds support for the display on the stm32f746-disco board,
along with a generic patch that adds the "bpp" parameter to the stm-drm
module. The intention is to allow users to size, within certain limits,
the memory footprint required by the framebuffer.

Changes in v2:
- Add 'Acked-by' tag of Conor Dooley.
- Fix build warning reported by kernel test robot.
- Add 'Reported-by' tag of kernel test robot.

Dario Binacchi (6):
  ARM: dts: stm32: add ltdc support on stm32f746 MCU
  ARM: dts: stm32: add pin map for LTDC on stm32f7
  ARM: dts: stm32: support display on stm32f746-disco board
  dt-bindings: display: simple: add Rocktech RK043FN48H
  drm/panel: simple: add support for Rocktech RK043FN48H panel
  drm/stm: add an option to change FB bpp

 .../bindings/display/panel/panel-simple.yaml  |  2 +
 arch/arm/boot/dts/stm32f7-pinctrl.dtsi| 35 +
 arch/arm/boot/dts/stm32f746-disco.dts | 51 +++
 arch/arm/boot/dts/stm32f746.dtsi  | 10 
 drivers/gpu/drm/panel/panel-simple.c  | 29 +++
 drivers/gpu/drm/stm/drv.c |  8 ++-
 6 files changed, 134 insertions(+), 1 deletion(-)

-- 
2.32.0

Re: [PATCH] drm/amdgpu: display/Kconfig: replace leading spaces with tab


Hi,

On 2023/6/7 03:15, Alex Deucher wrote:

Applied.  Thanks!


Where is the official branch of drm/amdgpu, I can't find it on the internet.

Sorry for asking this silly question.


Alex

On Tue, Jun 6, 2023 at 9:33 AM Sui Jingfeng  wrote:

This patch replace the leading spaces with tab, make them keep aligned with
the rest of the config options. No functional change.

Signed-off-by: Sui Jingfeng 
---
  drivers/gpu/drm/amd/display/Kconfig | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/Kconfig 
b/drivers/gpu/drm/amd/display/Kconfig
index 2d8e55e29637..04ccfc70d583 100644
--- a/drivers/gpu/drm/amd/display/Kconfig
+++ b/drivers/gpu/drm/amd/display/Kconfig
@@ -42,16 +42,13 @@ config DEBUG_KERNEL_DC
   Choose this option if you want to hit kdgb_break in assert.

  config DRM_AMD_SECURE_DISPLAY
-bool "Enable secure display support"
-depends on DEBUG_FS
-depends on DRM_AMD_DC_FP
-help
-Choose this option if you want to
-support secure display
-
-This option enables the calculation
-of crc of specific region via debugfs.
-Cooperate with specific DMCU FW.
+   bool "Enable secure display support"
+   depends on DEBUG_FS
+   depends on DRM_AMD_DC_FP
+   help
+ Choose this option if you want to support secure display

+ This option enables the calculation of crc of specific region via
+ debugfs. Cooperate with specific DMCU FW.

  endmenu
--
2.25.1


--
Jingfeng

Re: [PATCH v2] drm/i915: Fix a VMA UAF for multi-gt platform

2023-06-07 Thread Andrzej Hajda





On 06.06.2023 22:27, Nirmoy Das wrote:

Ensure correct handling of closed VMAs on multi-gt platforms to prevent
Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are
exclusively added to GT0's closed_vma link (gt->closed_vma) and
subsequently freed by i915_vma_parked(), which assumes the entire GPU is
idle. However, on platforms with multiple GTs, such as MTL, GT1 may
remain active while GT0 is idle. This causes GT0 to mistakenly consider
the closed VMAs in its closed_vma list as unnecessary, potentially
leading to Use-After-Free issues if a job for GT1 attempts to access a
freed VMA.

Although we do take a wakeref for GT0 but it happens later, after
evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref
early.

v2: Use gt id to detect multi-tile(Andi)
 Fix the incorrect error path.

Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Thomas Hellström 
Cc: Chris Wilson 
Cc: Andi Shyti 
Cc: Andrzej Hajda 
Cc: Sushma Venkatesh Reddy 
Tested-by: Andi Shyti 
Signed-off-by: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 12 
  1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4d..c2a67435acfa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2683,6 +2683,7 @@ static int
  eb_select_engine(struct i915_execbuffer *eb)
  {
struct intel_context *ce, *child;
+   struct intel_gt *gt;
unsigned int idx;
int err;
  
@@ -2706,10 +2707,16 @@ eb_select_engine(struct i915_execbuffer *eb)

}
}
eb->num_batches = ce->parallel.number_children + 1;
+   gt = ce->engine->gt;
  
  	for_each_child(ce, child)

intel_context_get(child);
intel_gt_pm_get(ce->engine->gt);


intel_gt_pm_get(gt)



+   /* Keep GT0 active on MTL so that i915_vma_parked() doesn't
+* free VMAs while execbuf ioctl is validating VMAs.
+*/
+   if (gt->info.id)
+   intel_gt_pm_get(to_gt(gt->i915));
  
  	if (!test_bit(CONTEXT_ALLOC_BIT, >flags)) {

err = intel_context_alloc_state(ce);
@@ -2748,6 +2755,9 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
  
  err:

+   if (gt->info.id)
+   intel_gt_pm_put(to_gt(gt->i915));
+
intel_gt_pm_put(ce->engine->gt);


intel_gt_pm_put(gt)


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


for_each_child(ce, child)
intel_context_put(child);
@@ -2761,6 +2771,8 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
  
  	i915_vm_put(eb->context->vm);

+   if (eb->gt->info.id)
+   intel_gt_pm_put(to_gt(eb->gt->i915));
intel_gt_pm_put(eb->gt);
for_each_child(eb->context, child)
intel_context_put(child);

Re: [Intel-gfx] [PATCH v2 1/2] vgaarb: various coding style and comments fix