RE: [PATCH v2 4/7] vfio/mdev: Pass in a struct vfio_device * to vfio_dma_rw()
> From: Jason Gunthorpe > Sent: Saturday, April 23, 2022 2:00 AM > > On Fri, Apr 22, 2022 at 01:50:00AM +, Tian, Kevin wrote: > > > From: Jason Gunthorpe > > > Sent: Friday, April 22, 2022 12:29 AM > > > > > > Every caller has a readily available vfio_device pointer, use that instead > > > of passing in a generic struct device. The struct vfio_device already > > > contains the group we need so this avoids complexity, extra refcountings, > > > and a confusing lifecycle model. > > > > Using the same description as last patch leaves the impression that > > the two patches do the exactly same type of change. But this > > patch actually includes one more change to grab a reference on the > > container. This is worth an explanation. > > How about this: > > Every caller has a readily available vfio_device pointer, use that instead > of passing in a generic struct device. Change vfio_dma_rw() to take in the > struct vfio_device and move the container users that would have been held > by vfio_group_get_external_user_from_dev() to vfio_dma_rw() directly, like > vfio_pin/unpin_pages(). > Yes, this is clearer.
[PATCH v2] drm/msm/dp: fix error check return value of irq_of_parse_and_map()
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon
Chipsets")
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
v2: don't print rc, and return -EINVAL rather than 0
---
drivers/gpu/drm/msm/dp/dp_display.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index a42732b67349..c3566e6564b1 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1239,10 +1239,9 @@ int dp_display_request_irq(struct msm_dp *dp_display)
dp = container_of(dp_display, struct dp_display_private, dp_display);
dp->irq = irq_of_parse_and_map(dp->pdev->dev.of_node, 0);
- if (dp->irq < 0) {
- rc = dp->irq;
- DRM_ERROR("failed to get irq: %d\n", rc);
- return rc;
+ if (!dp->irq) {
+ DRM_ERROR("failed to get irq\n");
+ return -EINVAL;
}
rc = devm_request_irq(>pdev->dev, dp->irq,
--
2.25.1
[PATCH v2] drm: msm: fix error check return value of irq_of_parse_and_map()
From: Lv Ruyi
The irq_of_parse_and_map() function returns 0 on failure, and does not
return an negative value.
Reported-by: Zeal Robot
Signed-off-by: Lv Ruyi
---
v2: don't print irq, and return ERR_PTR(-EINVAL)
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 3b92372e7bdf..44e395e59df9 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -570,9 +570,9 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
}
irq = irq_of_parse_and_map(pdev->dev.of_node, 0);
- if (irq < 0) {
- ret = irq;
- DRM_DEV_ERROR(>dev, "failed to get irq: %d\n", ret);
+ if (!irq) {
+ ret = -EINVAL;
+ DRM_DEV_ERROR(>dev, "failed to get irq\n");
goto fail;
}
--
2.25.1
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On 4/23/22 12:55, Arnd Bergmann wrote: On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck wrote: On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote: On 4/22/22 12:16, Arnd Bergmann wrote: On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck wrote: Which machine did you hit this on? Is this on hardware or in qemu? qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. Also, I just noticed that the failure is not always the same. z2 fails to boot from initrd, and sx1 fails to boot completely. That's a lot of machines failing, I hope at least we got the same bugs more than once here. For the I/O space, I found now that PXA was not using the standard virtual I/O address yet, but instead used a NULL-based offset. I'm not entirely happy with this patch, but this is an outline of what I think we need to fix that: https://pastebin.com/3nVgQsEw This one is probably incomplete, at least it breaks sa1100 for now, and it adds a bogus CONFIG_PCI dependency. I'm also not sure in what way the last patch in the series triggers it, rather than the one that removed mach/io.h. I had sx1 booting in qemu at least, with the omap1 multiplatform series only. If you have a custom config for this one, make sure you get the right DEBUG_LL address. I'll do another round of bisects. Here is the bisect for the sx1 boot failure. Odd, I can't reproduce this at all. Do you get any console output at all for this? Is this the plain omap1_defconfig, or something else? No, it is my own sx1 specific configuration. https://github.com/groeck/linux-build-test/blob/master/rootfs/arm/qemu_sx1_defconfig I don't recall where I got it from but ... One thing I keep having to apply myself is this snippet: diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S index 0bfad62ea858..87c695703580 100644 --- a/arch/arm/mm/proc-arm925.S +++ b/arch/arm/mm/proc-arm925.S @@ -441,7 +441,6 @@ __arm925_setup: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ disable write-back on caches explicitly - mcr p15, 7, r0, c15, c0, 0 #endif it does not have CONFIG_CPU_DCACHE_WRITETHROUGH enabled. Guenter adr r5, arm925_crval I don't remember what the story is behind this, but I can't actually manage to boot omap1_defconfig on qemu with the instruction intact. Arnd
Re: [PATCH v5 7/9] drm: vkms: Supports to the case where primary plane doesn't match the CRTC
Hi Pekka,
On 4/20/22 10:13, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:13 -0300
Igor Torrente wrote:
We will break the current assumption that the primary plane has the
Hi,
I'd say "remove" rather than "break". Breaking sounds bad but this is
good. :-)
Yeah, sure. :)
same size and position as CRTC.
...and that the primary plane is the bottom-most in zpos order, or is
even enabled. At least as far as the blending machinery is concerned.
For that we will add CRTC dimension information to `vkms_crtc_state`
and add a opaque black backgound color.
Because now we need to fill the background, we had a loss in
performance with this change. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|::|
| Implementation | Previous | This commit |
|:---:|:-:|:--:|
| frametime range | 5~18 ms | 10~22 ms |
| Average | 8.47 ms | 12.32 ms |
[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
Signed-off-by: Igor Torrente
---
Documentation/gpu/vkms.rst | 3 +--
drivers/gpu/drm/vkms/vkms_composer.c | 32 +++-
drivers/gpu/drm/vkms/vkms_crtc.c | 4
drivers/gpu/drm/vkms/vkms_drv.h | 2 ++
4 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index a49e4ae92653..49db221c0f52 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -121,8 +121,7 @@ There's lots of plane features we could add support for:
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
-- Support when the primary plane isn't exactly matching the output size: blend
- the primary plane into the black background.
+- Add background color KMS property[Good to get started].
- Full alpha blending on all planes.
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c
index cf24015bf90f..f80842227669 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -61,6 +61,15 @@ static bool check_y_limit(struct vkms_frame_info
*frame_info, int y)
return false;
}
+static void fill_background(struct pixel_argb_u16 *backgroud_color,
Hi,
this could be const struct pixel_argb_u16 *. Also a typo: missing n in
backgroud_color.
Oops.
+ struct line_buffer *output_buffer)
+{
+ int i;
+
+ for (i = 0; i < output_buffer->n_pixels; i++)
+ output_buffer->pixels[i] = *backgroud_color;
+}
+
/**
* @wb_frame_info: The writeback frame buffer metadata
* @crtc_state: The crtc state
@@ -78,22 +87,23 @@ static void blend(struct vkms_writeback_job *wb,
struct line_buffer *output_buffer, s64 row_size)
{
struct vkms_plane_state **plane = crtc_state->active_planes;
- struct vkms_frame_info *primary_plane_info = plane[0]->frame_info;
u32 n_active_planes = crtc_state->num_active_planes;
- int y_dst = primary_plane_info->dst.y1;
- int h_dst = drm_rect_height(_plane_info->dst);
- int y_limit = y_dst + h_dst;
+ struct pixel_argb_u16 background_color = (struct pixel_argb_u16) {
+ .a = 0x
+ };
Could be const and shorter, if that fits the kernel style:
const struct pixel_arb_u16 background_color = { .a = 0x };
It fits.
+
+ int crtc_y_limit = crtc_state->crtc_height;
int y, i;
- for (y = y_dst; y < y_limit; y++) {
- plane[0]->format_func(output_buffer, primary_plane_info, y);
+ for (y = 0; y < crtc_y_limit; y++) {
+ fill_background(_color, output_buffer);
/* If there are other planes besides primary, we consider the active
* planes should be in z-order and compose them associatively:
Is "associatively" the right word here?
* ((primary <- overlay) <- cursor)
The example (primary <- overlay) is not generally true with real hardware.
Maybe what you are trying to say is: The active planes are composed in
z-order.
I always forgot to update these comments. Thanks!
*/
- for (i = 1; i < n_active_planes; i++) {
+ for (i = 0; i < n_active_planes; i++) {
if (!check_y_limit(plane[i]->frame_info, y))
continue;
@@ -154,7 +164,7 @@ static int compose_active_planes(struct vkms_writeback_job *active_wb,
As I mentioned on the previous patch, I think the finding of primary
plane (which was generally incorrect) should be removed here.
I will remove this.
if (WARN_ON(check_format_funcs(crtc_state, active_wb)))
return -EINVAL;
- line_width = drm_rect_width(_plane_info->dst);
+ line_width =
[PATCH] drm/radeon: change cac_weights_* to static
Sparse reports these issues
si_dpm.c:332:26: warning: symbol 'cac_weights_pitcairn' was not declared.
Should it be static?
si_dpm.c:1088:26: warning: symbol 'cac_weights_oland' was not declared. Should
it be static?
Both of these variables are only used in si_dpm.c. Single file variables
should be static, so change their storage-class specifiers to static.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/si_dpm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 3add39c1a689..fbf968e3f6d7 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -329,7 +329,7 @@ static const struct si_dte_data dte_data_malta =
true
};
-struct si_cac_config_reg cac_weights_pitcairn[] =
+static struct si_cac_config_reg cac_weights_pitcairn[] =
{
{ 0x0, 0x, 0, 0x8a, SISLANDS_CACCONFIG_CGIND },
{ 0x0, 0x, 16, 0x0, SISLANDS_CACCONFIG_CGIND },
@@ -1085,7 +1085,7 @@ static const struct si_dte_data dte_data_venus_pro =
true
};
-struct si_cac_config_reg cac_weights_oland[] =
+static struct si_cac_config_reg cac_weights_oland[] =
{
{ 0x0, 0x, 0, 0x82, SISLANDS_CACCONFIG_CGIND },
{ 0x0, 0x, 16, 0x4F, SISLANDS_CACCONFIG_CGIND },
--
2.27.0
Re: [PATCH v2 00/48] ARM: PXA multiplatform support
On Sat, Apr 23, 2022 at 1:41 AM Guenter Roeck wrote: > > On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck wrote: > > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck > > > > wrote: > > > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > > Also, I just noticed that the failure is not always the same. > > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > > > That's a lot of machines failing, I hope at least we got the same bugs more > > than once here. > > > > For the I/O space, I found now that PXA was not using the standard > > virtual I/O address yet, but instead used a NULL-based offset. > > > > I'm not entirely happy with this patch, but this is an outline of what > > I think we need to fix that: https://pastebin.com/3nVgQsEw > > This one is probably incomplete, at least it breaks sa1100 for now, > > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > > in what way the last patch in the series triggers it, rather than the > > one that removed mach/io.h. > > > > I had sx1 booting in qemu at least, with the omap1 multiplatform series > > only. > > If you have a custom config for this one, make sure you get the right > > DEBUG_LL address. > > > > > I'll do another round of bisects. > > > > Here is the bisect for the sx1 boot failure. Odd, I can't reproduce this at all. Do you get any console output at all for this? Is this the plain omap1_defconfig, or something else? One thing I keep having to apply myself is this snippet: diff --git a/arch/arm/mm/proc-arm925.S b/arch/arm/mm/proc-arm925.S index 0bfad62ea858..87c695703580 100644 --- a/arch/arm/mm/proc-arm925.S +++ b/arch/arm/mm/proc-arm925.S @@ -441,7 +441,6 @@ __arm925_setup: #ifdef CONFIG_CPU_DCACHE_WRITETHROUGH mov r0, #4 @ disable write-back on caches explicitly - mcr p15, 7, r0, c15, c0, 0 #endif adr r5, arm925_crval I don't remember what the story is behind this, but I can't actually manage to boot omap1_defconfig on qemu with the instruction intact. Arnd
Re: [PATCH] drm/panel: simple: Add missing bus flags for Innolux G070Y2-L01
On Wed, Apr 06, 2022 at 11:36:27AM +0200, Marek Vasut wrote:
> The DE signal is active high on this display, fill in the missing bus_flags.
> This aligns panel_desc with its display_timing .
>
> Fixes: a5d2ade627dca ("drm/panel: simple: Add support for Innolux G070Y2-L01")
> Signed-off-by: Marek Vasut
> Cc: Christoph Fritz
> Cc: Laurent Pinchart
> Cc: Maxime Ripard
> Cc: Sam Ravnborg
> Cc: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/panel/panel-simple.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 65c2a3000e471..18fccb0d47382 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2149,6 +2149,7 @@ static const struct panel_desc innolux_g070y2_l01 = {
> .unprepare = 800,
> },
> .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> --
> 2.35.1
Re: [PATCH v5 6/9] drm: vkms: Refactor the plane composer to accept new formats
I forgot to respond some points from your review.
On 4/23/22 13:04, Igor Torrente wrote:
Hi Pekka,
On 4/20/22 09:36, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:12 -0300
Igor Torrente wrote:
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
Hi,
struct pixel_argb_u16 was added in the previous patch.
I will fix it. Thanks!
possible inputs. It consists of 16 bits fields that represent each of
the channels.
The pixels blend is done using this internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
| Memory consumption (output dimensions) |
|:--:|
| Current | This patch|
|:--:|:-:|
| Width * Heigth | 2 * Width |
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|:--:|
| Implementation | Current | This commit |
|:---:|:-:|::|
| frametime range | 9~22 ms |5~17 ms |
| Average | 11.4 ms |7.8 ms|
[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
V2: Improves the performance drastically, by performing the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
Several security/robustness improvents(Pekka Paalanen).
Removes check_planes_x_bounds function and allows partial
partly off-screen(Pekka Paalanen).
Signed-off-by: Igor Torrente
---
Documentation/gpu/vkms.rst| 4 -
drivers/gpu/drm/vkms/Makefile | 1 +
drivers/gpu/drm/vkms/vkms_composer.c | 318 --
drivers/gpu/drm/vkms/vkms_formats.c | 151
drivers/gpu/drm/vkms/vkms_formats.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c | 3 +
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +
7 files changed, 311 insertions(+), 181 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 973e2d43108b..a49e4ae92653 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -118,10 +118,6 @@ Add Plane Features
There's lots of plane features we could add support for:
-- Clearing primary plane: clear primary plane before plane composition (at the
- start) for correctness of pixel blend ops. It also guarantees alpha channel
- is cleared in the target buffer for stable crc. [Good to get started]
-
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+ vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 95029d2ebcac..cf24015bf90f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
(For this file, I have removed all the minus diff lines from below to
better see the new code.)
@@ -7,204 +7,186 @@
#include
#include
#include
+#include
#include "vkms_drv.h"
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
+ u32 new_color;
+ new_color = (src *
Re: [git pull] drm fixes for 5.18-rc4 (part 2)
The pull request you sent on Sat, 23 Apr 2022 15:18:43 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2022-04-23 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/13bc32bad7059d6c5671e9d037e6e3ed001cc0f4 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH v5 6/9] drm: vkms: Refactor the plane composer to accept new formats
Hi Pekka,
On 4/20/22 09:36, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:12 -0300
Igor Torrente wrote:
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
Hi,
struct pixel_argb_u16 was added in the previous patch.
I will fix it. Thanks!
possible inputs. It consists of 16 bits fields that represent each of
the channels.
The pixels blend is done using this internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
| Memory consumption (output dimensions) |
|:--:|
| Current | This patch|
|:--:|:-:|
| Width * Heigth | 2 * Width |
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT[1] test
`igt@kms_cursor_crc@pipe-a-cursor-512x512-onscreen` ten times:
| Frametime |
|:--:|
| Implementation | Current | This commit |
|:---:|:-:|::|
| frametime range | 9~22 ms |5~17 ms |
| Average | 11.4 ms |7.8 ms|
[1] IGT commit id: bc3f6833a12221a46659535dac06ebb312490eb4
V2: Improves the performance drastically, by performing the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
V5: Minor checkpatch fixes and the removal of TO-DO item(Melissa Wen).
Several security/robustness improvents(Pekka Paalanen).
Removes check_planes_x_bounds function and allows partial
partly off-screen(Pekka Paalanen).
Signed-off-by: Igor Torrente
---
Documentation/gpu/vkms.rst| 4 -
drivers/gpu/drm/vkms/Makefile | 1 +
drivers/gpu/drm/vkms/vkms_composer.c | 318 --
drivers/gpu/drm/vkms/vkms_formats.c | 151
drivers/gpu/drm/vkms/vkms_formats.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c | 3 +
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +
7 files changed, 311 insertions(+), 181 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst
index 973e2d43108b..a49e4ae92653 100644
--- a/Documentation/gpu/vkms.rst
+++ b/Documentation/gpu/vkms.rst
@@ -118,10 +118,6 @@ Add Plane Features
There's lots of plane features we could add support for:
-- Clearing primary plane: clear primary plane before plane composition (at the
- start) for correctness of pixel blend ops. It also guarantees alpha channel
- is cleared in the target buffer for stable crc. [Good to get started]
-
- ARGB format on primary plane: blend the primary plane into background with
translucent alpha.
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+ vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 95029d2ebcac..cf24015bf90f 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
(For this file, I have removed all the minus diff lines from below to
better see the new code.)
@@ -7,204 +7,186 @@
#include
#include
#include
+#include
#include "vkms_drv.h"
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
+ u32 new_color;
+ new_color = (src * 0x + dst * (0x - alpha));
+ return DIV_ROUND_CLOSEST(new_color, 0x);
This looks good.
}
/**
+ *
Re: [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On 4/22/2022 11:25 PM, Dmitry Baryshkov wrote:
On Sat, 23 Apr 2022 at 03:12, Abhinav Kumar wrote:
On 4/22/2022 5:07 PM, Dmitry Baryshkov wrote:
On 23/04/2022 02:45, Kuogee Hsieh wrote:
Current DP driver implementation has adding safe mode done at
dp_hpd_plug_handle() which is expected to be executed under event
thread context.
However there is possible circular locking happen (see blow stack trace)
after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
is executed under drm_thread context.
To break this circular locking, this patch have safe mode added at
dp_connector_get_mode() which is executed under drm thread context.
Therefore no lock acquired required for >mode_config.mutex while
adding fail safe mode since it has been hold by drm thread already.
==
WARNING: possible circular locking dependency detected
5.15.35-lockdep #6 Tainted: GW
--
frecon/429 is trying to acquire lock:
ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
dp_panel_add_fail_safe_mode+0x4c/0xa0
but task is already holding lock:
ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at:
lock_crtcs+0xb4/0x124
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (>commit_lock[i]){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
lock_crtcs+0xb4/0x124
msm_atomic_commit_tail+0x330/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common+0x174/0x1a64
ww_mutex_lock+0xb8/0x278
modeset_lock+0x304/0x4ac
drm_modeset_lock+0x4c/0x7c
drmm_mode_config_init+0x4a8/0xc50
msm_drm_init+0x274/0xac0
msm_drm_bind+0x20/0x2c
try_to_bring_up_master+0x3dc/0x470
__component_add+0x18c/0x3c0
component_add+0x1c/0x28
dp_display_probe+0x954/0xa98
platform_probe+0x124/0x15c
really_probe+0x1b0/0x5f8
__driver_probe_device+0x174/0x20c
driver_probe_device+0x70/0x134
__device_attach_driver+0x130/0x1d0
bus_for_each_drv+0xfc/0x14c
__device_attach+0x1bc/0x2bc
device_initial_probe+0x1c/0x28
bus_probe_device+0x94/0x178
deferred_probe_work_func+0x1a4/0x1f0
process_one_work+0x5d4/0x9dc
worker_thread+0x898/0xccc
kthread+0x2d4/0x3d4
ret_from_fork+0x10/0x20
-> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
ww_acquire_init+0x1c4/0x2c8
drm_modeset_acquire_init+0x44/0xc8
drm_helper_probe_single_connector_modes+0xb0/0x12dc
drm_mode_getconnector+0x5dc/0xfe8
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
-> #0 (>mode_config.mutex){+.+.}-{3:3}:
__lock_acquire+0x2650/0x672c
lock_acquire+0x1b4/0x4ac
__mutex_lock_common+0x174/0x1a64
mutex_lock_nested+0x98/0xac
dp_panel_add_fail_safe_mode+0x4c/0xa0
dp_hpd_plug_handle+0x1f0/0x280
dp_bridge_enable+0x94/0x2b8
drm_atomic_bridge_chain_enable+0x11c/0x168
drm_atomic_helper_commit_modeset_enables+0x500/0x740
msm_atomic_commit_tail+0x3e4/0x748
commit_tail+0x19c/0x278
drm_atomic_helper_commit+0x1dc/0x1f0
drm_atomic_commit+0xc0/0xd8
drm_atomic_helper_set_config+0xb4/0x134
drm_mode_setcrtc+0x688/0x1248
drm_ioctl_kernel+0x1e4/0x338
drm_ioctl+0x3a4/0x684
__arm64_sys_ioctl+0x118/0x154
invoke_syscall+0x78/0x224
el0_svc_common+0x178/0x200
do_el0_svc+0x94/0x13c
el0_svc+0x5c/0xec
el0t_64_sync_handler+0x78/0x108
el0t_64_sync+0x1a4/0x1a8
Signed-off-by: Kuogee Hsieh
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 --
drivers/gpu/drm/msm/dp/dp_panel.c | 23 +--
2 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c
b/drivers/gpu/drm/msm/dp/dp_display.c
index 92cd50f..01453db
Re: [PATCH v5 5/9] drm: vkms: Add fb information to `vkms_writeback_job`
Hi Pekka,
On 4/20/22 08:23, Pekka Paalanen wrote:
On Mon, 4 Apr 2022 17:45:11 -0300
Igor Torrente wrote:
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
Hi,
should this be talking about vkms_frame_info struct instead?
Yes it should. I will fix this. Thanks.
Also adds two new function pointers (`{wb,plane}_format_transform_func`)
are defined to handle format conversion to/from internal format.
These things will allow us, in the future, to have different compositing
and wb format types.
V2: Change the code to get the drm_framebuffer reference and not copy its
contents(Thomas Zimmermann).
V3: Drop the refcount in the wb code(Thomas Zimmermann).
V5: Add {wb,plane}_format_transform_func to vkms_writeback_job
and vkms_plane_state (Pekka Paalanen)
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 31 +--
drivers/gpu/drm/vkms/vkms_plane.c | 10 -
drivers/gpu/drm/vkms/vkms_writeback.c | 20 ++---
4 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 2d946368a561..95029d2ebcac 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info
*primary_plane_info,
struct vkms_frame_info *plane_frame_info,
void *vaddr_out)
{
- struct drm_framebuffer *fb = _frame_info->fb;
+ struct drm_framebuffer *fb = plane_frame_info->fb;
void *vaddr;
void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out,
struct vkms_frame_info *primary_plane_info,
struct vkms_crtc_state *crtc_state)
{
- struct drm_framebuffer *fb = _plane_info->fb;
+ struct drm_framebuffer *fb = primary_plane_info->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
const void *vaddr;
int i;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 2e6342164bef..2704cfb6904b 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -22,13 +22,8 @@
#define NUM_OVERLAY_PLANES 8
-struct vkms_writeback_job {
- struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
- struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
-};
-
struct vkms_frame_info {
- struct drm_framebuffer fb;
+ struct drm_framebuffer *fb;
struct drm_rect src, dst;
struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
@@ -36,6 +31,29 @@ struct vkms_frame_info {
unsigned int cpp;
};
+struct pixel_argb_u16 {
+ u16 a, r, g, b;
+};
+
+struct line_buffer {
+ size_t n_pixels;
+ struct pixel_argb_u16 *pixels;
+};
+
+typedef void
+(*wb_format_transform_func)(struct vkms_frame_info *frame_info,
+ const struct line_buffer *buffer, int y);
+
+typedef void
+(*plane_format_transform_func)(struct line_buffer *buffer,
+ const struct vkms_frame_info *frame_info, int y);
It wasn't immediately obvious to me in which direction these function
types work from their names. The arguments are not wb and plane but
vkms_frame_info and line_buffer in both. The implementations of these
functions would have nothing specific to a wb or a plane either, would
they?
No, there's nothing specific.
Do you think adding {dst_,src_} would be enough?
(*wb_format_transform_func)(struct vkms_frame_info *dst_frame_info,
const struct line_buffer *src_buffer
(*plane_format_transform_func)(struct line_buffer *dst_buffer,
const struct vkms_frame_info *src_frame_info,
What about naming them frame_to_line_func and line_to_frame_func?
Sounds good. I will rename it.
+
+struct vkms_writeback_job {
+ struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
+ struct vkms_frame_info frame_info;
Which frame_info is this? Should the field be called wb_frame_info?
Considering it's already in the writeback_job struct do you think this
necessary?
In other words, what kind of misudertanding do you think can happen if
this variable stay without the `wb_` prefix?
I spent a few minutes trying to find a case, but nothing came to my
mind.
+ wb_format_transform_func format_func;
line_to_frame_func wb_write;
perhaps? The type explains the general type of the function, and the
field name refers to what it is used for.
+};
+
/**
* vkms_plane_state - Driver specific plane state
* @base: base
[PATCH] drm/kmb: remove layer_irqs variable
Sparse reports these issues
kmb_plane.c:21:11: warning: symbol 'layer_irqs' was not declared. Should it be
static?
layer_irq in not used, so remove it.
Signed-off-by: Tom Rix
---
drivers/gpu/drm/kmb/kmb_plane.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/kmb/kmb_plane.c b/drivers/gpu/drm/kmb/kmb_plane.c
index 2735b8eb3537..8fe93d149491 100644
--- a/drivers/gpu/drm/kmb/kmb_plane.c
+++ b/drivers/gpu/drm/kmb/kmb_plane.c
@@ -18,13 +18,6 @@
#include "kmb_plane.h"
#include "kmb_regs.h"
-const u32 layer_irqs[] = {
- LCD_INT_VL0,
- LCD_INT_VL1,
- LCD_INT_GL0,
- LCD_INT_GL1
-};
-
/* Conversion (yuv->rgb) matrix from myriadx */
static const u32 csc_coef_lcd[] = {
1024, 0, 1436,
--
2.27.0
Re: [PATCH AUTOSEL 5.4 11/14] drm/msm: Stop using iommu_present()
On Tue, Apr 19, 2022 at 11:53:23AM -0700, Rob Clark wrote: You might want to drop this one, it seems to be causing some issues on older generations.. I'll be sending another PR shortly with a revert. https://patchwork.freedesktop.org/patch/482453 Dropped, thanks! -- Thanks, Sasha
Re: [PATCH] fbcon: change fbcon_*registered_fb variables to static
On Sat, Apr 23, 2022 at 08:56:18AM -0400, Tom Rix wrote:
> Sparse reports these issues
> fbcon.c:106:16: warning: symbol 'fbcon_registered_fb' was not declared.
> Should it be static?
> fbcon.c:107:5: warning: symbol 'fbcon_num_registered_fb' was not declared.
> Should it be static?
>
> These variables are only used in fbcon.c. Single file use variables should
> be static, so change their storage-class specifiers to static.
>
> Signed-off-by: Tom Rix
Acked-by: Sam Ravnborg
> ---
> drivers/video/fbdev/core/fbcon.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index c4e91715ef00..225ac0fe0143 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -103,8 +103,8 @@ enum {
>
> static struct fbcon_display fb_display[MAX_NR_CONSOLES];
>
> -struct fb_info *fbcon_registered_fb[FB_MAX];
> -int fbcon_num_registered_fb;
> +static struct fb_info *fbcon_registered_fb[FB_MAX];
> +static int fbcon_num_registered_fb;
>
> #define fbcon_for_each_registered_fb(i) \
> for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> --
> 2.27.0
[PATCH] drm/radeon: change cik_default_state table from global to static
Sparse reports these issues
cik_blit_shaders.c:31:11: warning: symbol 'cik_default_state' was not declared.
Should it be static?
cik_blit_shaders.c:246:11: warning: symbol 'cik_default_size' was not declared.
Should it be static?
cik_default_state and cik_default_size are only used in cik.c. Single file
symbols
should be static. So move their definitions to cik_blit_shaders.h and change
their
storage-class-specifier to static.
Remove unneeded cik_blit_shader.c
Signed-off-by: Tom Rix
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/cik_blit_shaders.c | 246 --
drivers/gpu/drm/radeon/cik_blit_shaders.h | 219 ++-
3 files changed, 218 insertions(+), 249 deletions(-)
delete mode 100644 drivers/gpu/drm/radeon/cik_blit_shaders.c
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1045d2c46a76..ea5380e24c3c 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
evergreen.o evergreen_cs.o \
evergreen_hdmi.o radeon_trace_points.o ni.o \
atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \
- radeon_prime.o cik.o cik_blit_shaders.o \
+ radeon_prime.o cik.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
diff --git a/drivers/gpu/drm/radeon/cik_blit_shaders.c
b/drivers/gpu/drm/radeon/cik_blit_shaders.c
deleted file mode 100644
index ff1311806e91..
--- a/drivers/gpu/drm/radeon/cik_blit_shaders.c
+++ /dev/null
@@ -1,246 +0,0 @@
-/*
- * Copyright 2012 Advanced Micro Devices, Inc.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sublicense,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the next
- * paragraph) shall be included in all copies or substantial portions of the
- * Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDER(S) AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- * Alex Deucher
- */
-
-#include
-#include
-#include
-
-const u32 cik_default_state[] =
-{
- 0xc0066900,
- 0x,
- 0x0060, /* DB_RENDER_CONTROL */
- 0x, /* DB_COUNT_CONTROL */
- 0x, /* DB_DEPTH_VIEW */
- 0x002a, /* DB_RENDER_OVERRIDE */
- 0x, /* DB_RENDER_OVERRIDE2 */
- 0x, /* DB_HTILE_DATA_BASE */
-
- 0xc0046900,
- 0x0008,
- 0x, /* DB_DEPTH_BOUNDS_MIN */
- 0x, /* DB_DEPTH_BOUNDS_MAX */
- 0x, /* DB_STENCIL_CLEAR */
- 0x, /* DB_DEPTH_CLEAR */
-
- 0xc0036900,
- 0x000f,
- 0x, /* DB_DEPTH_INFO */
- 0x, /* DB_Z_INFO */
- 0x, /* DB_STENCIL_INFO */
-
- 0xc0016900,
- 0x0080,
- 0x, /* PA_SC_WINDOW_OFFSET */
-
- 0xc00d6900,
- 0x0083,
- 0x, /* PA_SC_CLIPRECT_RULE */
- 0x, /* PA_SC_CLIPRECT_0_TL */
- 0x20002000, /* PA_SC_CLIPRECT_0_BR */
- 0x,
- 0x20002000,
- 0x,
- 0x20002000,
- 0x,
- 0x20002000,
- 0x, /* PA_SC_EDGERULE */
- 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
- 0x000f, /* CB_TARGET_MASK */
- 0x000f, /* CB_SHADER_MASK */
-
- 0xc0226900,
- 0x0094,
- 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
- 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
- 0x8000,
- 0x20002000,
-
[PATCH] fbcon: change fbcon_*registered_fb variables to static
Sparse reports these issues
fbcon.c:106:16: warning: symbol 'fbcon_registered_fb' was not declared. Should
it be static?
fbcon.c:107:5: warning: symbol 'fbcon_num_registered_fb' was not declared.
Should it be static?
These variables are only used in fbcon.c. Single file use variables should
be static, so change their storage-class specifiers to static.
Signed-off-by: Tom Rix
---
drivers/video/fbdev/core/fbcon.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index c4e91715ef00..225ac0fe0143 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -103,8 +103,8 @@ enum {
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
-struct fb_info *fbcon_registered_fb[FB_MAX];
-int fbcon_num_registered_fb;
+static struct fb_info *fbcon_registered_fb[FB_MAX];
+static int fbcon_num_registered_fb;
#define fbcon_for_each_registered_fb(i)\
for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
--
2.27.0
Re: [PATCH v2 3/7] vfio/mdev: Pass in a struct vfio_device * to vfio_pin/unpin_pages()
On Sat, Apr 23, 2022 at 07:15:52AM +0200, Christoph Hellwig wrote: > On Fri, Apr 22, 2022 at 05:56:51PM -0300, Jason Gunthorpe wrote: > > On Fri, Apr 22, 2022 at 08:22:32AM +0200, Christoph Hellwig wrote: > > > Nit: why do some of these patches that don't touch the mdev code > > > mdev in the subject? > > > > I consider these APIs to be 'mdev apis' because only mdev drivers > > should call them. > > I thought we settled on 'emulated IOMMU device' in the VFIO core for > them, leaving mdev just for the odd lifecycle management glue. Yes vfio/emulated ? Jason
[PATCH] drm: rcar-du: Add setting to PnALPHAR register on Gen3
From: LUU HOAI In Gen3, when Alpha blend is enabled in the PnMR register, depending on the initial value of the PnALPHAR register, either channel of DU might be black screen. Therefore, this patch prevents the black screen by setting the PnALPHAR register to all 0. In addition, PnALPHAR register will be released in the R-Car Gen3 Hardware Manual Rev 2.4 (Sep. 2021). Signed-off-by: LUU HOAI Signed-off-by: Biju Das --- This patch is based on [1] [1] https://github.com/renesas-rcar/linux-bsp/commit/fcb34fe338cbde0a64919430733541035f20a784 Not sure this patches has to go with Fixes tag for stable?? Tested the changes on RZ/G2M board root@hihope-rzg2m:/cip-test-scripts# modetest -M rcar-du -w 54:alpha:5 root@hihope-rzg2m:/cip-test-scripts# modetest -M rcar-du -s "93@90:1024x768@AR24" -d -P "54@90:400x300+200+200@XR24" setting mode 1024x768-75Hz@AR24 on connectors 93, crtc 90 testing 400x300@XR24 overlay plane 54 --- drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index 5c1c7bb04f3f..aff39b9253f8 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c @@ -510,6 +510,12 @@ static void rcar_du_plane_setup_format_gen3(struct rcar_du_group *rgrp, rcar_du_plane_write(rgrp, index, PnDDCR4, state->format->edf | PnDDCR4_CODE); + + /* In Gen3, PnALPHAR register need to be set to 0 +* to avoid black screen issue when alpha blend is enable +* on DU module +*/ + rcar_du_plane_write(rgrp, index, PnALPHAR, 0x); } static void rcar_du_plane_setup_format(struct rcar_du_group *rgrp, -- 2.25.1
Re: [PATCH] drm/msm/dp: move add fail safe mode to dp_connector_get_mode()
On Sat, 23 Apr 2022 at 03:12, Abhinav Kumar wrote:
>
>
>
> On 4/22/2022 5:07 PM, Dmitry Baryshkov wrote:
> > On 23/04/2022 02:45, Kuogee Hsieh wrote:
> >> Current DP driver implementation has adding safe mode done at
> >> dp_hpd_plug_handle() which is expected to be executed under event
> >> thread context.
> >>
> >> However there is possible circular locking happen (see blow stack trace)
> >> after edp driver call dp_hpd_plug_handle() from dp_bridge_enable() which
> >> is executed under drm_thread context.
> >>
> >> To break this circular locking, this patch have safe mode added at
> >> dp_connector_get_mode() which is executed under drm thread context.
> >> Therefore no lock acquired required for >mode_config.mutex while
> >> adding fail safe mode since it has been hold by drm thread already.
> >>
> >> ==
> >> WARNING: possible circular locking dependency detected
> >> 5.15.35-lockdep #6 Tainted: GW
> >> --
> >> frecon/429 is trying to acquire lock:
> >> ff808dc3c4e8 (>mode_config.mutex){+.+.}-{3:3}, at:
> >> dp_panel_add_fail_safe_mode+0x4c/0xa0
> >>
> >> but task is already holding lock:
> >> ff808dc441e0 (>commit_lock[i]){+.+.}-{3:3}, at:
> >> lock_crtcs+0xb4/0x124
> >>
> >> which lock already depends on the new lock.
> >>
> >> the existing dependency chain (in reverse order) is:
> >>
> >> -> #3 (>commit_lock[i]){+.+.}-{3:3}:
> >> __mutex_lock_common+0x174/0x1a64
> >> mutex_lock_nested+0x98/0xac
> >> lock_crtcs+0xb4/0x124
> >> msm_atomic_commit_tail+0x330/0x748
> >> commit_tail+0x19c/0x278
> >> drm_atomic_helper_commit+0x1dc/0x1f0
> >> drm_atomic_commit+0xc0/0xd8
> >> drm_atomic_helper_set_config+0xb4/0x134
> >> drm_mode_setcrtc+0x688/0x1248
> >> drm_ioctl_kernel+0x1e4/0x338
> >> drm_ioctl+0x3a4/0x684
> >> __arm64_sys_ioctl+0x118/0x154
> >> invoke_syscall+0x78/0x224
> >> el0_svc_common+0x178/0x200
> >> do_el0_svc+0x94/0x13c
> >> el0_svc+0x5c/0xec
> >> el0t_64_sync_handler+0x78/0x108
> >> el0t_64_sync+0x1a4/0x1a8
> >>
> >> -> #2 (crtc_ww_class_mutex){+.+.}-{3:3}:
> >> __mutex_lock_common+0x174/0x1a64
> >> ww_mutex_lock+0xb8/0x278
> >> modeset_lock+0x304/0x4ac
> >> drm_modeset_lock+0x4c/0x7c
> >> drmm_mode_config_init+0x4a8/0xc50
> >> msm_drm_init+0x274/0xac0
> >> msm_drm_bind+0x20/0x2c
> >> try_to_bring_up_master+0x3dc/0x470
> >> __component_add+0x18c/0x3c0
> >> component_add+0x1c/0x28
> >> dp_display_probe+0x954/0xa98
> >> platform_probe+0x124/0x15c
> >> really_probe+0x1b0/0x5f8
> >> __driver_probe_device+0x174/0x20c
> >> driver_probe_device+0x70/0x134
> >> __device_attach_driver+0x130/0x1d0
> >> bus_for_each_drv+0xfc/0x14c
> >> __device_attach+0x1bc/0x2bc
> >> device_initial_probe+0x1c/0x28
> >> bus_probe_device+0x94/0x178
> >> deferred_probe_work_func+0x1a4/0x1f0
> >> process_one_work+0x5d4/0x9dc
> >> worker_thread+0x898/0xccc
> >> kthread+0x2d4/0x3d4
> >> ret_from_fork+0x10/0x20
> >>
> >> -> #1 (crtc_ww_class_acquire){+.+.}-{0:0}:
> >> ww_acquire_init+0x1c4/0x2c8
> >> drm_modeset_acquire_init+0x44/0xc8
> >> drm_helper_probe_single_connector_modes+0xb0/0x12dc
> >> drm_mode_getconnector+0x5dc/0xfe8
> >> drm_ioctl_kernel+0x1e4/0x338
> >> drm_ioctl+0x3a4/0x684
> >> __arm64_sys_ioctl+0x118/0x154
> >> invoke_syscall+0x78/0x224
> >> el0_svc_common+0x178/0x200
> >> do_el0_svc+0x94/0x13c
> >> el0_svc+0x5c/0xec
> >> el0t_64_sync_handler+0x78/0x108
> >> el0t_64_sync+0x1a4/0x1a8
> >>
> >> -> #0 (>mode_config.mutex){+.+.}-{3:3}:
> >> __lock_acquire+0x2650/0x672c
> >> lock_acquire+0x1b4/0x4ac
> >> __mutex_lock_common+0x174/0x1a64
> >> mutex_lock_nested+0x98/0xac
> >> dp_panel_add_fail_safe_mode+0x4c/0xa0
> >> dp_hpd_plug_handle+0x1f0/0x280
> >> dp_bridge_enable+0x94/0x2b8
> >> drm_atomic_bridge_chain_enable+0x11c/0x168
> >> drm_atomic_helper_commit_modeset_enables+0x500/0x740
> >> msm_atomic_commit_tail+0x3e4/0x748
> >> commit_tail+0x19c/0x278
> >> drm_atomic_helper_commit+0x1dc/0x1f0
> >> drm_atomic_commit+0xc0/0xd8
> >> drm_atomic_helper_set_config+0xb4/0x134
> >> drm_mode_setcrtc+0x688/0x1248
> >> drm_ioctl_kernel+0x1e4/0x338
> >> drm_ioctl+0x3a4/0x684
> >> __arm64_sys_ioctl+0x118/0x154
> >> invoke_syscall+0x78/0x224
> >> el0_svc_common+0x178/0x200
> >> do_el0_svc+0x94/0x13c
> >>
