Re: [PATCH v2 6/8] drm/vmwgfx: Rename dummy to is_iomem
Am 31.01.23 um 04:35 schrieb Zack Rusin:
From: Zack Rusin
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.
Signed-off-by: Zack Rusin
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1082218a1cfc..e83286e08837 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private
*dev_priv,
SVGAGBCursorHeader *header;
SVGAGBAlphaCursorHeader *alpha_header;
const u32 image_size = width * height * sizeof(*image);
- bool dummy;
+ bool is_iomem;
- header = ttm_kmap_obj_virtual(&vps->cursor.map, &dummy);
+ header = ttm_kmap_obj_virtual(&vps->cursor.map, &is_iomem);
alpha_header = &header->header.alphaHeader;
memset(header, 0, sizeof(*header));
@@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
*/
static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
{
- bool dummy;
+ bool is_iomem;
if (vps->surf) {
if (vps->surf_mapped)
return vmw_bo_map_and_cache(vps->surf->res.backup);
return vps->surf->snooper.image;
} else if (vps->bo)
- return ttm_kmap_obj_virtual(&vps->bo->map, &dummy);
+ return ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem);
return NULL;
}
@@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
SVGA3dCopyBox *box;
unsigned box_count;
void *virtual;
- bool dummy;
+ bool is_iomem;
struct vmw_dma_cmd {
SVGA3dCmdHeader header;
SVGA3dCmdSurfaceDMA dma;
@@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (unlikely(ret != 0))
goto err_unreserve;
- virtual = ttm_kmap_obj_virtual(&map, &dummy);
+ virtual = ttm_kmap_obj_virtual(&map, &is_iomem);
if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch == image_pitch) {
memcpy(srf->snooper.image, virtual,
@@ -658,14 +658,14 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
{
struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
- bool dummy;
+ bool is_iomem;
if (vps->surf_mapped) {
vmw_bo_unmap(vps->surf->res.backup);
vps->surf_mapped = false;
}
- if (vps->bo && ttm_kmap_obj_virtual(&vps->bo->map, &dummy)) {
+ if (vps->bo && ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem)) {
const int ret = ttm_bo_reserve(&vps->bo->base, true, false,
NULL);
if (likely(ret == 0)) {
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [PATCH v3 0/3] drm/rockchip: dw_hdmi: Add 4k@30 support
Heiko, Sandy, Ok to apply these patches? Sascha On Wed, Jan 18, 2023 at 02:22:10PM +0100, Sascha Hauer wrote: > It's been some time since I last sent this series. This version fixes > a regression Dan Johansen reported. The reason turned out to be simple, > I used the YUV420 register values instead of the RGB ones. > > I realized that we cannot achieve several modes offered by my monitor > as these require pixelclocks that are slightly below the standard > pixelclocks. As these are lower than the standard clock rates the PLL > driver offers the clk driver falls back to a way lower frequency > which results in something the monitor can't display, so this series > now contains a patch to discard these unachievable modes. > > Sascha > > Changes since v2: > - Use correct register values for mpll_cfg > - Add patch to discard modes we cannot achieve > > Changes since v1: > - Allow non standard clock rates only on Synopsys phy as suggested by > Robin Murphy > > Sascha Hauer (3): > drm/rockchip: dw_hdmi: relax mode_valid hook > drm/rockchip: dw_hdmi: Add support for 4k@30 resolution > drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks > > drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 40 - > 1 file changed, 32 insertions(+), 8 deletions(-) > > -- > 2.30.2 > > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH v3 1/2] drm/panel: boe-tv101wum-nl6: Remove extra delay
Il 31/01/23 02:59, xinlei@mediatek.com ha scritto: From: Xinlei Lee Reduce the delay after LCM reset by removing an extra delay in the initialization commands array. The required delay of at least 6ms after reset is guaranteed by boe_panel_prepare(). Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH v3 2/2] drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence
Il 31/01/23 02:59, xinlei@mediatek.com ha scritto: From: Xinlei Lee For "boe,tv105wum-nw0" this special panel, it is stipulated in the panel spec that MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high. Signed-off-by: Xinlei Lee Reviewed-by: AngeloGioacchino Del Regno
Re: [PATCH] [v2] accel: fix CONFIG_DRM dependencies
On Sat, Jan 28, 2023 at 12:15 AM Arnd Bergmann wrote:
>
> From: Arnd Bergmann
>
> At the moment, accel drivers can be built-in even with CONFIG_DRM=m,
> but this causes a link failure:
>
> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init':
> ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc'
> x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to
> `drmm_kmalloc'
> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove':
> ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister'
> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe':
> ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc'
>
> The problem is that DRM_ACCEL is a 'bool' symbol symbol, so driver that
> only depend on DRM_ACCEL but not also on DRM do not see the restriction
> to =m configs.
>
> To ensure that each accel driver has an implied dependency on CONFIG_DRM,
> enclose the entire Kconfig file in an if/endif check.
>
> Fixes: 8bf4889762a8 ("drivers/accel: define kconfig and register a new major")
> Signed-off-by: Arnd Bergmann
> ---
> v2: rearrage the DRM dependency rather than requiring DRM to be built-in
> ---
> drivers/accel/Kconfig | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
> index 834863902e16..c437206aa3f1 100644
> --- a/drivers/accel/Kconfig
> +++ b/drivers/accel/Kconfig
> @@ -6,9 +6,10 @@
> # as, but not limited to, Machine-Learning and Deep-Learning acceleration
> # devices
> #
> +if DRM
> +
> menuconfig DRM_ACCEL
> bool "Compute Acceleration Framework"
> - depends on DRM
> help
> Framework for device drivers of compute acceleration devices, such
> as, but not limited to, Machine-Learning and Deep-Learning
> @@ -25,3 +26,5 @@ menuconfig DRM_ACCEL
>
> source "drivers/accel/habanalabs/Kconfig"
> source "drivers/accel/ivpu/Kconfig"
> +
> +endif
> --
> 2.39.0
>
This patch is:
Reviewed-by: Oded Gabbay
Re: [PATCH v4 1/2] drm/simpledrm: Allow physical width and height configuration via panel node
Am 26.01.23 um 19:24 schrieb Rayyan Ansari:
Parse the width-mm and height-mm devicetree properties of the panel node,
and use this to set the DRM Display Mode instead of calculating it
based on a hardcoded DPI.
Signed-off-by: Rayyan Ansari
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/simpledrm.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 162eb44dcba8..f8b18441cfcb 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -599,16 +599,12 @@ static const struct drm_mode_config_funcs
simpledrm_mode_config_funcs = {
*/
static struct drm_display_mode simpledrm_mode(unsigned int width,
- unsigned int height)
+ unsigned int height,
+ unsigned int width_mm,
+ unsigned int height_mm)
{
- /*
-* Assume a monitor resolution of 96 dpi to
-* get a somewhat reasonable screen size.
-*/
const struct drm_display_mode mode = {
- DRM_MODE_INIT(60, width, height,
- DRM_MODE_RES_MM(width, 96ul),
- DRM_MODE_RES_MM(height, 96ul))
+ DRM_MODE_INIT(60, width, height, width_mm, height_mm)
};
return mode;
@@ -622,6 +618,8 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
struct simpledrm_device *sdev;
struct drm_device *dev;
int width, height, stride;
+ int width_mm = 0, height_mm = 0;
+ struct device_node *panel_node;
const struct drm_format_info *format;
struct resource *res, *mem;
void __iomem *screen_base;
@@ -676,6 +674,13 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
format = simplefb_get_format_of(dev, of_node);
if (IS_ERR(format))
return ERR_CAST(format);
+
+ panel_node = of_parse_phandle(of_node, "panel", 0);
+ if (panel_node) {
+ simplefb_read_u32_of(dev, panel_node, "width-mm",
&width_mm);
+ simplefb_read_u32_of(dev, panel_node, "height-mm",
&height_mm);
+ of_node_put(panel_node);
+ }
} else {
drm_err(dev, "no simplefb configuration found\n");
return ERR_PTR(-ENODEV);
@@ -686,7 +691,16 @@ static struct simpledrm_device
*simpledrm_device_create(struct drm_driver *drv,
return ERR_PTR(-EINVAL);
}
- sdev->mode = simpledrm_mode(width, height);
+ /*
+* Assume a monitor resolution of 96 dpi if physical dimensions
+* are not specified to get a somewhat reasonable screen size.
+*/
+ if (!width_mm)
+ width_mm = DRM_MODE_RES_MM(width, 96ul);
+ if (!height_mm)
+ height_mm = DRM_MODE_RES_MM(height, 96ul);
+
+ sdev->mode = simpledrm_mode(width, height, width_mm, height_mm);
sdev->format = format;
sdev->pitch = stride;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [RFC PATCH v2 00/18] Add DRM CRTC 3D LUT interface
On Mon, 9 Jan 2023 14:38:09 -0100
Melissa Wen wrote:
> On 01/09, Melissa Wen wrote:
> > Hi,
> >
> > After collecting comments in different places, here is a second version
> > of the work on adding DRM CRTC 3D LUT support to the current DRM color
> > mgmt interface. In comparison to previous proposals [1][2][3], here we
> > add 3D LUT before gamma 1D LUT, but also a shaper 1D LUT before 3D LUT,
> > that means the following DRM CRTC color correction pipeline:
> >
> > Blend -> Degamma 1D LUT -> CTM -> Shaper 1D LUT -> 3D LUT -> Gamma 1D LUT
Hi Melissa,
that makes sense to me, for CRTCs. It would be really good to have that
as a diagram in the KMS UAPI documentation.
If someone wants to add a 3D LUT to KMS planes as well, then I'm not
sure if it should be this order or swapped. I will probably have an
opinion about that once Weston is fully HDR capable and has been tried
in the wild for a while with the HDR color operations fine-tuned based
on community feedback. IOW, not for a long time. The YUV to RGB
conversion factors in there as well.
> >
> > and we also add a DRM CRTC LUT3D_MODE property, based on Alex Hung
> > proposal for pre-blending 3D LUT [4] (Thanks!), instead of just a
> > LUT3D_SIZE, that allows userspace to use different supported settings of
> > 3D LUT, fitting VA-API and new color API better. In this sense, I
> > adjusted the pre-blending proposal for post-blending usage.
> >
> > Patches 1-6 targets the addition of shaper LUT and 3D LUT properties to
> > the current DRM CRTC color mgmt pipeline. Patch 6 can be considered an
> > extra/optional patch to define a default value for LUT3D_MODE, inspired
> > by what we do for the plane blend mode property (pre-multiplied).
> >
> > Patches 7-18 targets AMD display code to enable shaper and 3D LUT usage
> > on DCN 301 (our HW case). Patches 7-9 performs code cleanups on current
> > AMD DM colors code, patch 10 updates AMD stream in case of user 3D LUT
> > changes, patch 11/12 rework AMD MPC 3D LUT resource handling by context
> > for DCN 301 (easily extendible to other DCN families). Finally, from
> > 13-18, we wire up SHAPER LUT, LUT3D and LUT3D MODE to AMD display
> > driver, exposing modes supported by HW and programming user shaper and
> > 3D LUT accordingly.
> >
> > Our target userspace is Gamescope/SteamOS.
> >
> > Basic IGT tests were based on [5][6] and are available here (in-progress):
> > https://gitlab.freedesktop.org/mwen/igt-gpu-tools/-/commits/crtc-lut3d-api
> >
> > [1]
> > https://lore.kernel.org/all/20201221015730.28333-1-laurent.pinchart+rene...@ideasonboard.com/
> > [2]
> > https://github.com/vsyrjala/linux/commit/4d28e8ddf2a076f30f9e5bdc17cbb4656fe23e69
> > [3] https://lore.kernel.org/amd-gfx/20220619223104.667413-1-m...@igalia.com/
> > [4]
> > https://lore.kernel.org/dri-devel/20221004211451.1475215-1-alex.h...@amd.com/
> > [5] https://patchwork.freedesktop.org/series/90165/
> > [6] https://patchwork.freedesktop.org/series/109402/
> > [VA_API]
> > http://intel.github.io/libva/structVAProcFilterParameterBuffer3DLUT.html
> > [KMS_pipe_API] https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/11
> >
> > Let me know your thoughts.
>
> +Simon Ser, +Pekka Paalanen who might also be interested in this series.
Unfortunately I don't have the patch emails to reply to, so here's a
messy bunch of comments. I'll concentrate on the UAPI design as always.
+/*
+ * struct drm_mode_lut3d_mode - 3D LUT mode information.
+ * @lut_size: number of valid points on every dimension of 3D LUT.
+ * @lut_stride: number of points on every dimension of 3D LUT.
+ * @bit_depth: number of bits of RGB. If color_mode defines entries with higher
+ * bit_depth the least significant bits will be truncated.
+ * @color_format: fourcc values, ex. DRM_FORMAT_XRGB16161616 or
DRM_FORMAT_XBGR16161616.
+ * @flags: flags for hardware-sepcific features
+ */
+struct drm_mode_lut3d_mode {
+ __u16 lut_size;
+ __u16 lut_stride[3];
+ __u16 bit_depth;
+ __u32 color_format;
+ __u32 flags;
+};
Why is lut_stride an array of 3, but lut_size is not?
What is the color_mode the comment is referring to?
What is "number of bits of RGB"? Input precision? Output precision?
Integer or floating point?
Flags cannot be hardware specific, because it makes the whole KMS UAPI
hardware specific. That won't work. You have to have driver-agnostic
definitions for all possible flags.
Why is this the whole first patch? There is no documentation for the
UAPI on how this struct works, so I cannot review this. Explaining just
the individual fields is not enough to understand it. Is this something
the kernel fills in and is read-only to userspace? Is userspace filling
this in?
+ * “LUT3D”:
+ * Blob property to set the 3D LUT mapping pixel data after the color
+ * transformation matrix and before gamma 1D lut correction. The
+ * data is interpreted as an array of &struct drm_color_lut elements.
+ * Hardware might choos
RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Hi Piccoli,
Please ignore my request of full dmesg log. I can reproduce the issue and get
the same failure callstack by returning early with an error code prior to
amdgpu_device_init_schedulers.
Regards,
Guchun
-Original Message-
From: Chen, Guchun
Sent: Tuesday, January 31, 2023 2:37 PM
To: Alex Deucher ; Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
; dri-devel@lists.freedesktop.org; Tuikov, Luben
; Limonciello, Mario ;
kernel-...@igalia.com; Deucher, Alexander ; Koenig,
Christian
Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
Hi Piccoli,
I agree with Alex's point, using ring->sched.name for such check is not a good
way. BTW, can you please attach a full dmesg long in bad case to help me
understand more?
Regards,
Guchun
-Original Message-
From: Alex Deucher
Sent: Tuesday, January 31, 2023 6:30 AM
To: Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
; Pan, Xinhui ;
dri-devel@lists.freedesktop.org; Tuikov, Luben ;
Limonciello, Mario ; kernel-...@igalia.com; Deucher,
Alexander ; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
wrote:
>
> + Luben
>
> (sorry, missed that in the first submission).
>
> On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
> > Currently amdgpu calls drm_sched_fini() from the fence driver sw
> > fini routine - such function is expected to be called only after the
> > respective init function - drm_sched_init() - was executed successfully.
> >
> > Happens that we faced a driver probe failure in the Steam Deck
> > recently, and the function drm_sched_fini() was called even without
> > its counter-part had been previously called, causing the following oops:
> >
> > amdgpu: probe of :04:00.0 failed with error -110
> > BUG: kernel NULL pointer dereference, address: 0090 PGD
> > 0 P4D 0
> > Oops: 0002 [#1] PREEMPT SMP NOPTI
> > CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
> > #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
> > RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
> >
> > amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
> > amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
> > amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
> > devm_drm_dev_init_release+0x49/0x70
> > [...]
> >
> > To prevent that, check if the drm_sched was properly initialized for
> > a given ring before calling its fini counter-part.
> >
> > Notice ideally we'd use sched.ready for that; such field is set as
> > the latest thing on drm_sched_init(). But amdgpu seems to "override"
> > the meaning of such field - in the above oops for example, it was a
> > GFX ring causing the crash, and the sched.ready field was set to
> > true in the ring init routine, regardless of the state of the DRM
> > scheduler. Hence, we ended-up using another sched field.
> >> > Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
> >> > driver fini in s3 test (v2)")
> > Cc: Andrey Grodzovsky
> > Cc: Guchun Chen
> > Cc: Mario Limonciello
> > Signed-off-by: Guilherme G. Piccoli
> > ---
> >
> >
> > Hi folks, first of all thanks in advance for reviews / comments!
> > Notice that I've used the Fixes tag more in the sense to bring it to
> > stable, I didn't find a good patch candidate that added the call to
> > drm_sched_fini(), was reaching way too old commits...so
> > 067f44c8b459 seems a good candidate - or maybe not?
> >
> > Now, with regards sched.ready, spent a bit of time to figure what
> > was happening...would be feasible maybe to stop using that to mark
> > some kind ring status? I think it should be possible to add a flag
> > to the ring structure for that, and free sched.ready from being
> > manipulate by the amdgpu driver, what's your thoughts on that?
It's been a while, but IIRC, we used to have a ring->ready field in the driver
which at some point got migrated out of the driver into the GPU scheduler and
the driver side code never got cleaned up. I think we should probably just
drop the driver messing with that field and leave it up to the drm scheduler.
Alex
> >
> > I could try myself, but first of course I'd like to raise the
> > "temperature" on this topic and check if somebody is already working
> > on that.
> >
> > Cheers,
> >
> > Guilherme
> >
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > index 00444203220d..e154eb8241fb 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
> > @@ -618,7 +618,13 @@ void amdgpu_fence_driver_sw_fini(struct amdgpu_device
> > *adev)
> > if (!ring || !ring->fen
Re: [PATCH] [v2] accel: fix CONFIG_DRM dependencies
On 31.01.2023 09:53, Oded Gabbay wrote:
> On Sat, Jan 28, 2023 at 12:15 AM Arnd Bergmann wrote:
>>
>> From: Arnd Bergmann
>>
>> At the moment, accel drivers can be built-in even with CONFIG_DRM=m,
>> but this causes a link failure:
>>
>> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_dev_init':
>> ivpu_drv.c:(.text+0x1535): undefined reference to `drmm_kmalloc'
>> x86_64-linux-ld: ivpu_drv.c:(.text+0x1562): undefined reference to
>> `drmm_kmalloc'
>> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_remove':
>> ivpu_drv.c:(.text+0x1faa): undefined reference to `drm_dev_unregister'
>> x86_64-linux-ld: drivers/accel/ivpu/ivpu_drv.o: in function `ivpu_probe':
>> ivpu_drv.c:(.text+0x1fef): undefined reference to `__devm_drm_dev_alloc'
>>
>> The problem is that DRM_ACCEL is a 'bool' symbol symbol, so driver that
>> only depend on DRM_ACCEL but not also on DRM do not see the restriction
>> to =m configs.
>>
>> To ensure that each accel driver has an implied dependency on CONFIG_DRM,
>> enclose the entire Kconfig file in an if/endif check.
>>
>> Fixes: 8bf4889762a8 ("drivers/accel: define kconfig and register a new
>> major")
>> Signed-off-by: Arnd Bergmann
>> ---
>> v2: rearrage the DRM dependency rather than requiring DRM to be built-in
>> ---
>> drivers/accel/Kconfig | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig
>> index 834863902e16..c437206aa3f1 100644
>> --- a/drivers/accel/Kconfig
>> +++ b/drivers/accel/Kconfig
>> @@ -6,9 +6,10 @@
>> # as, but not limited to, Machine-Learning and Deep-Learning acceleration
>> # devices
>> #
>> +if DRM
>> +
>> menuconfig DRM_ACCEL
>> bool "Compute Acceleration Framework"
>> - depends on DRM
>> help
>> Framework for device drivers of compute acceleration devices, such
>> as, but not limited to, Machine-Learning and Deep-Learning
>> @@ -25,3 +26,5 @@ menuconfig DRM_ACCEL
>>
>> source "drivers/accel/habanalabs/Kconfig"
>> source "drivers/accel/ivpu/Kconfig"
>> +
>> +endif
>> --
>> 2.39.0
>>
> This patch is:
> Reviewed-by: Oded Gabbay
Applied to drm-misc-next.
Thanks.
Re: [PATCH 1/2] accep/ivpu: PM: remove broken ivpu_dbg() statements
Applied to drm-misc-next.
Thanks.
On 26.01.2023 17:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When CONFIG_PM is disabled, the driver fails to build:
>
> drivers/accel/ivpu/ivpu_pm.c: In function 'ivpu_rpm_get':
> drivers/accel/ivpu/ivpu_pm.c:240:84: error: 'struct dev_pm_info' has no
> member named 'usage_count'
> 240 | ivpu_dbg(vdev, RPM, "rpm_get count %d\n",
> atomic_read(&vdev->drm.dev->power.usage_count));
> |
> ^
> include/linux/dynamic_debug.h:223:29: note: in definition of macro
> '__dynamic_func_call_cls'
> 223 | func(&id, ##__VA_ARGS__); \
> | ^~~
> include/linux/dynamic_debug.h:249:9: note: in expansion of macro
> '_dynamic_func_call_cls'
> 249 | _dynamic_func_call_cls(_DPRINTK_CLASS_DFLT, fmt, func,
> ##__VA_ARGS__)
> | ^~
> include/linux/dynamic_debug.h:272:9: note: in expansion of macro
> '_dynamic_func_call'
> 272 | _dynamic_func_call(fmt, __dynamic_dev_dbg, \
> | ^~
> include/linux/dev_printk.h:155:9: note: in expansion of macro
> 'dynamic_dev_dbg'
> 155 | dynamic_dev_dbg(dev, dev_fmt(fmt), ##__VA_ARGS__)
> | ^~~
> drivers/accel/ivpu/ivpu_drv.h:65:17: note: in expansion of macro 'dev_dbg'
>65 | dev_dbg((vdev)->drm.dev, "[%s] " fmt, #type, ##args);
> \
> | ^~~
> drivers/accel/ivpu/ivpu_pm.c:240:9: note: in expansion of macro 'ivpu_dbg'
> 240 | ivpu_dbg(vdev, RPM, "rpm_get count %d\n",
> atomic_read(&vdev->drm.dev->power.usage_count));
> | ^~~~
>
> It would be possible to rework these statements to only conditionally print
> the reference counter, or to make the driver depend on CONFIG_PM, but my
> impression is that these are not actually needed at all if the driver
> generally
> works, or they could be put back when required. Just remove all four of these
> to make the driver build in all configurations.
>
> Fixes: 852be13f3bd3 ("accel/ivpu: Add PM support")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/accel/ivpu/ivpu_pm.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_pm.c b/drivers/accel/ivpu/ivpu_pm.c
> index 553bcbd787b3..a880f1dd857e 100644
> --- a/drivers/accel/ivpu/ivpu_pm.c
> +++ b/drivers/accel/ivpu/ivpu_pm.c
> @@ -237,8 +237,6 @@ int ivpu_rpm_get(struct ivpu_device *vdev)
> {
> int ret;
>
> - ivpu_dbg(vdev, RPM, "rpm_get count %d\n",
> atomic_read(&vdev->drm.dev->power.usage_count));
> -
> ret = pm_runtime_resume_and_get(vdev->drm.dev);
> if (!drm_WARN_ON(&vdev->drm, ret < 0))
> vdev->pm->suspend_reschedule_counter = PM_RESCHEDULE_LIMIT;
> @@ -248,8 +246,6 @@ int ivpu_rpm_get(struct ivpu_device *vdev)
>
> void ivpu_rpm_put(struct ivpu_device *vdev)
> {
> - ivpu_dbg(vdev, RPM, "rpm_put count %d\n",
> atomic_read(&vdev->drm.dev->power.usage_count));
> -
> pm_runtime_mark_last_busy(vdev->drm.dev);
> pm_runtime_put_autosuspend(vdev->drm.dev);
> }
> @@ -314,16 +310,10 @@ void ivpu_pm_enable(struct ivpu_device *vdev)
> pm_runtime_allow(dev);
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> -
> - ivpu_dbg(vdev, RPM, "Enable RPM count %d\n",
> atomic_read(&dev->power.usage_count));
> }
>
> void ivpu_pm_disable(struct ivpu_device *vdev)
> {
> - struct device *dev = vdev->drm.dev;
> -
> - ivpu_dbg(vdev, RPM, "Disable RPM count %d\n",
> atomic_read(&dev->power.usage_count));
> -
> pm_runtime_get_noresume(vdev->drm.dev);
> pm_runtime_forbid(vdev->drm.dev);
> }
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Fri, 6 Jan 2023 23:49:34 +0200 Dmitry Baryshkov wrote: > On Fri, 6 Jan 2023 at 20:41, Daniel Vetter wrote: > > > > On Fri, Jan 06, 2023 at 05:43:23AM +0200, Dmitry Baryshkov wrote: > > > On Fri, 6 Jan 2023 at 02:38, Jessica Zhang > > > wrote: > > > > > > > > > > > > > > > > On 1/5/2023 3:33 AM, Daniel Vetter wrote: > > > > > On Wed, Jan 04, 2023 at 03:40:33PM -0800, Jessica Zhang wrote: > > > > >> Introduce and add support for a solid_fill property. When the > > > > >> solid_fill > > > > >> property is set, and the framebuffer is set to NULL, memory fetch > > > > >> will be > > > > >> disabled. > > > > >> > > > > >> In addition, loosen the NULL FB checks within the atomic commit > > > > >> callstack > > > > >> to allow a NULL FB when the solid_fill property is set and add FB > > > > >> checks > > > > >> in methods where the FB was previously assumed to be non-NULL. > > > > >> > > > > >> Finally, have the DPU driver use drm_plane_state.solid_fill and > > > > >> instead of > > > > >> dpu_plane_state.color_fill, and add extra checks in the DPU atomic > > > > >> commit > > > > >> callstack to account for a NULL FB in cases where solid_fill is set. > > > > >> > > > > >> Some drivers support hardware that have optimizations for solid fill > > > > >> planes. This series aims to expose these capabilities to userspace as > > > > >> some compositors have a solid fill flag (ex. SOLID_COLOR in the > > > > >> Android > > > > >> hardware composer HAL) that can be set by apps like the Android Gears > > > > >> app. > > > > >> > > > > >> Userspace can set the solid_fill property to a blob containing the > > > > >> appropriate version number and solid fill color (in RGB323232 > > > > >> format) and > > > > >> setting the framebuffer to NULL. > > > > >> > > > > >> Note: Currently, there's only one version of the solid_fill blob > > > > >> property. > > > > >> However if other drivers want to support a similar feature, but > > > > >> require > > > > >> more than just the solid fill color, they can extend this feature by > > > > >> creating additional versions of the drm_solid_fill struct. > > > > >> > > > > >> Changes in V2: > > > > >> - Dropped SOLID_FILL_FORMAT property (Simon) > > > > >> - Switched to implementing solid_fill property as a blob (Simon, > > > > >> Dmitry) > > > > >> - Changed to checks for if solid_fill_blob is set (Dmitry) > > > > >> - Abstracted (plane_state && !solid_fill_blob) checks to helper > > > > >> method > > > > >>(Dmitry) > > > > >> - Removed DPU_PLANE_COLOR_FILL_FLAG > > > > >> - Fixed whitespace and indentation issues (Dmitry) > > > > > > > > > > Now that this is a blob, I do wonder again whether it's not cleaner > > > > > to set > > > > > the blob as the FB pointer. Or create some kind other kind of special > > > > > data > > > > > source objects (because solid fill is by far not the only such thing). > > > > > > > > > > We'd still end up in special cases like when userspace that doesn't > > > > > understand solid fill tries to read out such a framebuffer, but these > > > > > cases already exist anyway for lack of priviledges. > > > > > > > > > > So I still think that feels like the more consistent way to integrate > > > > > this > > > > > feature. Which doesn't mean it has to happen like that, but the > > > > > patches/cover letter should at least explain why we don't do it like > > > > > this. > > > > > > > > Hi Daniel, > > > > > > > > IIRC we were facing some issues with this check [1] when trying to set > > > > FB to a PROP_BLOB instead. Which is why we went with making it a > > > > separate property instead. Will mention this in the cover letter. > > > > > > What kind of issues? Could you please describe them? > > > > We switched from bitmask to enum style for prop types, which means it's > > not possible to express with the current uapi a property which accepts > > both an object or a blob. > > > > Which yeah sucks a bit ... > > > > But! > > > > blob properties are kms objects (like framebuffers), so it should be > > possible to stuff a blob into an object property as-is. Of course you need > > to update the validation code to make sure we accept either an fb or a > > blob for the internal representation. But that kind of split internally is > > required no matter what I think. > > I checked your idea and notes from Jessica. So while we can pass blobs > to property objects, the prop_fb_id is created as an object property > with the type DRM_MODE_OBJECT_FB. Passing DRM_MODE_OBJECT_BLOB would > fail a check in drm_property_change_valid_get() -> > __drm_mode_object_find(). And I don't think that we should break the > existing validation code for this special case. > > If you insist on using FB_ID for passing solid_fill information, I'd > ask you to reconsider using a 1x1 framebuffer. It would be fully > compatible with the existing userspace, which can then treat it > seamlessly. Hi, indeed, what about simply using a 1x1 framebuffer for real
Re: [PATCH 2/2] drm/ttm: revert "stop allocating dummy resources during BO creation"
On Wed, 25 Jan 2023 at 16:24, Matthew Auld
wrote:
>
> On Wed, 25 Jan 2023 at 16:15, Christian König
> wrote:
> >
> > Am 25.01.23 um 17:13 schrieb Matthew Auld:
> > > On Wed, 25 Jan 2023 at 15:50, Christian König
> > > wrote:
> > >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9.
> > >>
> > >> It seems to still breka i915.
> > > We also need to revert the third patch:
> > >
> > > b49323aa35d5 drm/ttm: prevent moving of pinned BOs
> > >
> > > It introduces the side effect of no longer calling tt_create(true) in
> > > ttm_bo_validate(), and I'm 99% sure that will break object clearing.
> > > We rely on having a ttm_tt for the initial dummy placement, with
> > > FLAG_ZERO_ALLOC set if clear is needed. Also I'm not sure who even
> > > creates the ttm_tt now, if ttm_bo_validate() doesn't, and we don't
> > > have the dummy move, like with this patch.
> >
> > Oh, yes of course. Can I add your Acked-by to reverting all three?
>
> Yeah, feel free to add. I can then resend your series with the extra
> stuff we need for i915.
https://patchwork.freedesktop.org/series/113484/
CI appears to be happy now. Feel free to merge the series.
>
> >
> > Thanks,
> > Christian.
> >
> > >
> > >> Signed-off-by: Christian König
> > >> ---
> > >> drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
> > >> 1 file changed, 7 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> > >> index 33471e363ff4..9baccb2f6e99 100644
> > >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> > >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> > >> @@ -957,6 +957,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> > >> struct ttm_buffer_object *bo,
> > >> struct sg_table *sg, struct dma_resv *resv,
> > >> void (*destroy) (struct ttm_buffer_object *))
> > >> {
> > >> + static const struct ttm_place sys_mem = { .mem_type =
> > >> TTM_PL_SYSTEM };
> > >> int ret;
> > >>
> > >> kref_init(&bo->kref);
> > >> @@ -973,6 +974,12 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> > >> struct ttm_buffer_object *bo,
> > >> bo->base.resv = &bo->base._resv;
> > >> atomic_inc(&ttm_glob.bo_count);
> > >>
> > >> + ret = ttm_resource_alloc(bo, &sys_mem, &bo->resource);
> > >> + if (unlikely(ret)) {
> > >> + ttm_bo_put(bo);
> > >> + return ret;
> > >> + }
> > >> +
> > >> /*
> > >> * For ttm_bo_type_device buffers, allocate
> > >> * address space from the device.
> > >> --
> > >> 2.34.1
> > >>
> >
Re: [PATCH v4 0/2] SimpleDRM: allow configuring physical width and height
Hi, thanks a lot. I've added your patches to drm-misc-next. They should be in Linux v6.4. Best regards Thomas Am 26.01.23 um 19:24 schrieb Rayyan Ansari: Hello, The following patches: - Add support for configuring the width-mm and height-mm DRM mode properties in the SimpleDRM driver via Device Tree - Document these two new Device Tree properties This is useful for allowing interfaces such as Phosh to calculate proper scaling values and for early boot code knowing if hi-dpi rendering is necessary. Changes since v3: - Use panel node Rayyan Ansari (2): drm/simpledrm: Allow physical width and height configuration via panel node dt-bindings: display: simple-framebuffer: Document the panel node .../bindings/display/simple-framebuffer.yaml | 9 ++ drivers/gpu/drm/tiny/simpledrm.c | 32 +-- 2 files changed, 32 insertions(+), 9 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH 1/5] drm/amd/amdgpu revert "implement tdr advanced mode"
A later bad compute job can block a good gfx job
The gang submit/barrier approach makes sure that only one application at
a time can use the gfx/compute block.
So when application B makes a compute submission while a GFX submission
of application A is still running we will wait for that GFX submission
to complete before B is allowed to access the hardware.
Two submissions to the same engine will wait in the hardware for the
first submission to fully complete before the second is started.
This way neither concurrent submissions to different engines
(compute/gfx) nor subsequent submissions to the same engine let
different applications access the hardware at the same time.
It's essentially the same requirement we have for gang submit and that
is now well tested and in production for a couple of month. So we
already know that the approach works.
Regards,
Christian.
Am 28.01.23 um 09:28 schrieb Yin, ZhenGuo (Chris):
Hi, Christian
A later bad compute job can block a good gfx job, so the original TDR
design find a wrong guilty job(good gfx job).
Advanced TDR re-submits jobs in order to find the real guilty job(bad
compute job).
After reverting this commit, how does the new gang-submit promise the
isolation between compute jobs and gfx jobs?
On 10/26/2022 11:35 PM, Christian König wrote:
This reverts commit e6c6338f393b74ac0b303d567bb918b44ae7ad75.
This feature basically re-submits one job after another to
figure out which one was the one causing a hang.
This is obviously incompatible with gang-submit which requires
that multiple jobs run at the same time. It's also absolutely
not helpful to crash the hardware multiple times if a clean
recovery is desired.
For testing and debugging environments we should rather disable
recovery alltogether to be able to inspect the state with a hw
debugger.
Additional to that the sw implementation is clearly buggy and causes
reference count issues for the hardware fence.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 103 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/scheduler/sched_main.c | 58 ++--
include/drm/gpu_scheduler.h | 3 -
4 files changed, 10 insertions(+), 156 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6f958603c8cc..d4584e577b51 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -5070,94 +5070,6 @@ static int
amdgpu_device_suspend_display_audio(struct amdgpu_device *adev)
return 0;
}
-static void amdgpu_device_recheck_guilty_jobs(
- struct amdgpu_device *adev, struct list_head *device_list_handle,
- struct amdgpu_reset_context *reset_context)
-{
- int i, r = 0;
-
- for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
- struct amdgpu_ring *ring = adev->rings[i];
- int ret = 0;
- struct drm_sched_job *s_job;
-
- if (!ring || !ring->sched.thread)
- continue;
-
- s_job = list_first_entry_or_null(&ring->sched.pending_list,
- struct drm_sched_job, list);
- if (s_job == NULL)
- continue;
-
- /* clear job's guilty and depend the folowing step to decide
the real one */
- drm_sched_reset_karma(s_job);
- drm_sched_resubmit_jobs_ext(&ring->sched, 1);
-
- if (!s_job->s_fence->parent) {
- DRM_WARN("Failed to get a HW fence for job!");
- continue;
- }
-
- ret = dma_fence_wait_timeout(s_job->s_fence->parent, false,
ring->sched.timeout);
- if (ret == 0) { /* timeout */
- DRM_ERROR("Found the real bad job! ring:%s, job_id:%llx\n",
- ring->sched.name, s_job->id);
-
-
- amdgpu_fence_driver_isr_toggle(adev, true);
-
- /* Clear this failed job from fence array */
- amdgpu_fence_driver_clear_job_fences(ring);
-
- amdgpu_fence_driver_isr_toggle(adev, false);
-
- /* Since the job won't signal and we go for
- * another resubmit drop this parent pointer
- */
- dma_fence_put(s_job->s_fence->parent);
- s_job->s_fence->parent = NULL;
-
- /* set guilty */
- drm_sched_increase_karma(s_job);
- amdgpu_reset_prepare_hwcontext(adev, reset_context);
-retry:
- /* do hw reset */
- if (amdgpu_sriov_vf(adev)) {
- amdgpu_virt_fini_data_exchange(adev);
- r = amdgpu_device_reset_sriov(adev, false);
- if (r)
- adev->asic_reset_res = r;
- } else {
- clear_bit(AMDGPU_SKIP_HW_RESET,
- &reset_context->flags);
- r = amdgpu_do_asic_reset(device_list_handle,
- reset_context);
- if (r && r == -EAGAIN)
-
RE: Amdgpu module is references even after unbinding the vtcon
[AMD Official Use Only - General] Hi Christian, I was not able to check about the handover from fbdev to gdm as I was having issues with setting it up proper driver in the environment with display. Regarding exporting DMA-buf, when the X starts it acquires file descriptor for the buffer with creating new handle and when closing the file descriptor it successfully releases the dma buffer that was exported as it is tha last handle on the underlying object. BR, Danijel >-Original Message- >From: Christian König >Sent: Thursday, January 26, 2023 3:12 PM >To: Slivka, Danijel ; Thomas Zimmermann > >Cc: Deucher, Alexander ; dri-devel de...@lists.freedesktop.org>; Sharma, Shashank > >Subject: Re: Amdgpu module is references even after unbinding the vtcon > >Hi Danijel, > >can you also double check that GDM/X is still capable of acquiring a DMA-buf >file descriptor for the buffer (e.g. that we have a DMA-buf handle for it while >they are started). > >And that handover from fbdev to GDM/X is flicker free? > >Thanks, >Christian. > >Am 26.01.23 um 14:44 schrieb Slivka, Danijel: >> [AMD Official Use Only - General] >> >> Hi Christian, >> >> I have tested the proposed patch, the issue is not reproducible and >everything else seems to work fine. >> >> BR, >> Danijel >> >>> -Original Message- >>> From: Christian König >>> Sent: Thursday, January 26, 2023 1:20 PM >>> To: Slivka, Danijel ; Thomas Zimmermann >>> >>> Cc: Deucher, Alexander ; dri-devel >> de...@lists.freedesktop.org>; Sharma, Shashank >>> >>> Subject: Re: Amdgpu module is references even after unbinding the >>> vtcon >>> >>> Am 26.01.23 um 10:49 schrieb Slivka, Danijel: [AMD Official Use Only - General] Hi Thomas, I have checked what you mentioned. When loading amdgpu we call drm_client_init() during fbdev setup [1], the >>> refcnt for drm_kms_helper increases from 3 -> 4. When we unbind vtcon, refcnt for drm_kms_helper drops 4 -> 3, but the >>> drm_client_release() [2] is not called. The drm_client_release() is called only when unloading the amdgpu >driver. Is this expected? >>> Yes, the client can't be released because it is possible that the >>> vtcon is bound to this fbdev again. >>> >>> Please test the handle work around I've send around internally. At >>> least for me that approach seems to work. >>> >>> Regards, >>> Christian. >>> There is a comment for drm_client_release with regards to fbdev : * This function should only be called from the unregister callback. An >exception * is fbdev which cannot free the buffer if userspace has open file >descriptors. Could this be relevant for our use case, although as Application/X/GDM are >>> stopped at that point and no fd should be open. Thank you, BR, Danijel > -Original Message- > From: Thomas Zimmermann > Sent: Wednesday, January 25, 2023 8:48 PM > To: Christian König > Cc: Deucher, Alexander ; Slivka, Danijel > ; dri-devel > ; Sharma, Shashank > > Subject: Re: Amdgpu module is references even after unbinding the > vtcon > > Hi Christian > > Am 24.01.23 um 15:12 schrieb Christian König: >> Hi Thomas, >> >> we ran into a problem with the general fbcon/fbdev implementation >> and though that you might have some idea. >> >> What happens is the following: >> 1. We load amdgpu and get our normal fbcon. >> 2. fbcon allocates a dump BO as backing store for the console. >> 3. GDM/X/Applications start, new framebuffers are created BOs >> imported, exported etc... >> 4. Somehow X or GDM iterated over all the framebuffer objects the >> kernels knows about and export them as DMA-buf. >> 5. Application/X/GDM are stopped, handles closed, framebuffers >> released etc... >> 6. We unbind vtcon. >> >> At this point the amdgpu module usually has a reference count of 0 >> and can be unloaded, but since GDM/X/Whoever iterated over all the >> known framebuffers and exported them as DMA-buf (for whatever >> reason >> idk) we now still have an exported DMA-buf and with it a reference >> to the >>> module. >> Any idea how we could prevent that? > Here's another stab in the dark. > > The big difference between old-style fbdev and the new one is that > the old fbdev setup (e.g., radeon) allocates a GEM object and puts > together the fbdev data structures from the BO in a fairly hackish > way. The new style uses an in-kernel client with a file to allocate > the BO via dumb buffers; and holds a reference to the DRM module. > > Maybe the reference comes from the in-kernel DRM client itself. [1] > Check if the client resources get released [2] when you unbind vtcon. > > Best regards > Thomas > > [1] > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ > cl >>
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen wrote: > indeed, what about simply using a 1x1 framebuffer for real? Why was that > approach rejected? Ideally we don't want to allocate any GPU memory for the solid-fill stuff. And if we special-case 1x1 FB creation to not be backed by real GPU memory then we hit several situations where user-space expects a real FB but there isn't: for instance, GETFB2 converts from FB object ID to GEM handles. Even if we make GETFB2 fail and accept that this breaks user-space, then there is no way for user-space to recover the FB color for flicker-free transitions and such. This is all purely from a uAPI PoV, completely ignoring the potential issues with the internal kernel abstractions which might not be suitable for this either.
Re: [PATCH v6 00/10] drm: Remove usage of deprecated DRM_* macros
On Mon, 9 Jan 2023 at 18:30:25 +0530, Siddh Raman Pant wrote: > This patchset aims to remove usages of deprecated DRM_* macros from the > files residing in drivers/gpu/drm root. > > In process, I found out that NULL as first argument of drm_dbg_* wasn't > working, but it was listed as the alternative in deprecation comment, > so I fixed that before removing usages of DRM_DEBUG_* macros. Courtesy > discussion on v1, I added support for NULL in drm_()* macros too. > > This patchset should be applied in order as changes might be dependent. > > Please review and let me know if any errors are there, and hopefully > this gets accepted. > > --- > v5 -> v6: > - Move drm_device to default case in _Generic as it is the default behaviour. > - Fix incorrect const drm_device handling in _Generic. > - Minor positioning / comment changes. > > [...] > > Siddh Raman Pant (10): > drm/print: Fix and add support for NULL as first argument in drm_* > macros > drm: Remove usage of deprecated DRM_INFO > drm: Remove usage of deprecated DRM_NOTE > drm: Remove usage of deprecated DRM_ERROR > drm: Remove usage of deprecated DRM_DEBUG > drm: Remove usage of deprecated DRM_DEBUG_DRIVER > drm: Remove usage of deprecated DRM_DEBUG_KMS > drm: Remove usage of deprecated DRM_DEBUG_PRIME > drm/drm_blend: Remove usage of deprecated DRM_DEBUG_ATOMIC > drm/drm_lease: Remove usage of deprecated DRM_DEBUG_LEASE > > [...] Hello, Please review these patches, which I sent more than 2 weeks ago. Note that the last three patches have been already merged. Lore link is: https://lore.kernel.org/dri-devel/cover.1673269059.git.c...@siddh.me/ Thanks, Siddh
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Am 31.01.23 um 10:17 schrieb Chen, Guchun:
Hi Piccoli,
Please ignore my request of full dmesg log. I can reproduce the issue and get
the same failure callstack by returning early with an error code prior to
amdgpu_device_init_schedulers.
Regards,
Guchun
-Original Message-
From: Chen, Guchun
Sent: Tuesday, January 31, 2023 2:37 PM
To: Alex Deucher ; Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui ;
dri-devel@lists.freedesktop.org; Tuikov, Luben ; Limonciello, Mario
; kernel-...@igalia.com; Deucher, Alexander
; Koenig, Christian
Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
Hi Piccoli,
I agree with Alex's point, using ring->sched.name for such check is not a good
way. BTW, can you please attach a full dmesg long in bad case to help me
understand more?
Regards,
Guchun
-Original Message-
From: Alex Deucher
Sent: Tuesday, January 31, 2023 6:30 AM
To: Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun ; Pan, Xinhui
; dri-devel@lists.freedesktop.org; Tuikov, Luben ;
Limonciello, Mario ; kernel-...@igalia.com; Deucher, Alexander
; Koenig, Christian
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
wrote:
+ Luben
(sorry, missed that in the first submission).
On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
Currently amdgpu calls drm_sched_fini() from the fence driver sw
fini routine - such function is expected to be called only after the
respective init function - drm_sched_init() - was executed successfully.
Happens that we faced a driver probe failure in the Steam Deck
recently, and the function drm_sched_fini() was called even without
its counter-part had been previously called, causing the following oops:
amdgpu: probe of :04:00.0 failed with error -110
BUG: kernel NULL pointer dereference, address: 0090 PGD
0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
#338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
devm_drm_dev_init_release+0x49/0x70
[...]
To prevent that, check if the drm_sched was properly initialized for
a given ring before calling its fini counter-part.
Notice ideally we'd use sched.ready for that; such field is set as
the latest thing on drm_sched_init(). But amdgpu seems to "override"
the meaning of such field - in the above oops for example, it was a
GFX ring causing the crash, and the sched.ready field was set to
true in the ring init routine, regardless of the state of the DRM scheduler.
Hence, we ended-up using another sched field.
Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
driver fini in s3 test (v2)")
Cc: Andrey Grodzovsky
Cc: Guchun Chen
Cc: Mario Limonciello
Signed-off-by: Guilherme G. Piccoli
---
Hi folks, first of all thanks in advance for reviews / comments!
Notice that I've used the Fixes tag more in the sense to bring it to
stable, I didn't find a good patch candidate that added the call to
drm_sched_fini(), was reaching way too old commits...so
067f44c8b459 seems a good candidate - or maybe not?
Now, with regards sched.ready, spent a bit of time to figure what
was happening...would be feasible maybe to stop using that to mark
some kind ring status? I think it should be possible to add a flag
to the ring structure for that, and free sched.ready from being
manipulate by the amdgpu driver, what's your thoughts on that?
It's been a while, but IIRC, we used to have a ring->ready field in the driver
which at some point got migrated out of the driver into the GPU scheduler and the
driver side code never got cleaned up. I think we should probably just drop the
driver messing with that field and leave it up to the drm scheduler.
To use ring->ready is not a good idea since this doesn't specify if the
scheduler was initialized, but rather if bringup of the engine worked.
It's perfectly possible that the scheduler was initialized, but then the
IB test failed later on.
I strongly suggest to use scheduler->ops instead since those are set
during init and mandatory for correct operation.
Christian.
Alex
I could try myself, but first of course I'd like to raise the
"temperature" on this topic and check if somebody is already working
on that.
Cheers,
Guilherme
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
index 00444203220d..e154eb8241fb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tue, 31 Jan 2023 10:06:39 + Simon Ser wrote: > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > wrote: > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > approach rejected? > > Ideally we don't want to allocate any GPU memory for the solid-fill > stuff. And if we special-case 1x1 FB creation to not be backed by real > GPU memory then we hit several situations where user-space expects a > real FB but there isn't: for instance, GETFB2 converts from FB object > ID to GEM handles. Even if we make GETFB2 fail and accept that this > breaks user-space, then there is no way for user-space to recover the > FB color for flicker-free transitions and such. > > This is all purely from a uAPI PoV, completely ignoring the potential > issues with the internal kernel abstractions which might not be suitable > for this either. I mean a real 1x1 buffer: a dumb buffer. It would be absolutely compatible with anything existing, because it is a real FB. As a dumb buffer it would be trivial to write into and read out. As 1x1 it would be tiny (one page?). Even if something needs to raw-access uncached memory over 33 MHz PCI bus or whatever the worst case is, it's just one pixel, so it's fast enough, right? And it only needs to be read once when set, like USB display drivers do. The driver does not need to manually apply any color operations, because none are supported in this special case. One can put all these limitations and even pixel format in the plane property that tells userspace that a 1x1 FB works here. To recap, the other alternatives under discussion I see right now are: - this proposal of dedicated fill color property - stuffing something new into FB_ID property There is also the question of other kinds of plane content sources like live camera feeds where userspace won't be shovelling each frame individually like we do now. 1x1 dumb buffer is not as small and lean as a dedicated fill color property, but the UAPI design questions seem to be much less. What's the best trade-off and for whom? Thanks, pq pgp3vQ9YxUOiq.pgp Description: OpenPGP digital signature
Re: [PATCH v2 02/27] drm/msm/dpu: rename struct dpu_hw_pipe to dpu_hw_sspp
On 27/01/2023 00:55, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
For all hardware blocks except SSPP the corresponding struct is named
after the block. Rename dpu_hw_pipe (SSPP structure) to dpu_hw_sspp.
Signed-off-by: Dmitry Baryshkov
Idea seems okay but then we should also rename dpu_hw_pipe_cfg to
dpu_hw_sspp_cfg.
I'll have to think about it. I ended up reusing the dpu_hw_pipe_cfg to
describe a single rectangle configuration (iow, one for rect0, one for
rect1). Let me check if I can make it more obvious.
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 42 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 42 ++---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 2 +-
3 files changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index 691c471b08c2..93f01f767fd8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -136,7 +136,7 @@
#define TS_CLK 1920
-static int _sspp_subblk_offset(struct dpu_hw_pipe *ctx,
+static int _sspp_subblk_offset(struct dpu_hw_sspp *ctx,
int s_id,
u32 *idx)
{
@@ -168,7 +168,7 @@ static int _sspp_subblk_offset(struct dpu_hw_pipe
*ctx,
return rc;
}
-static void dpu_hw_sspp_setup_multirect(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_multirect(struct dpu_hw_sspp *ctx,
enum dpu_sspp_multirect_index index,
enum dpu_sspp_multirect_mode mode)
{
@@ -197,7 +197,7 @@ static void dpu_hw_sspp_setup_multirect(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_MULTIRECT_OPMODE + idx, mode_mask);
}
-static void _sspp_setup_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -218,7 +218,7 @@ static void _sspp_setup_opmode(struct dpu_hw_pipe
*ctx,
DPU_REG_WRITE(&ctx->hw, SSPP_VIG_OP_MODE + idx, opmode);
}
-static void _sspp_setup_csc10_opmode(struct dpu_hw_pipe *ctx,
+static void _sspp_setup_csc10_opmode(struct dpu_hw_sspp *ctx,
u32 mask, u8 en)
{
u32 idx;
@@ -239,7 +239,7 @@ static void _sspp_setup_csc10_opmode(struct
dpu_hw_pipe *ctx,
/*
* Setup source pixel format, flip,
*/
-static void dpu_hw_sspp_setup_format(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_format(struct dpu_hw_sspp *ctx,
const struct dpu_format *fmt, u32 flags,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -356,7 +356,7 @@ static void dpu_hw_sspp_setup_format(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_UBWC_ERROR_STATUS + idx, BIT(31));
}
-static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_pe_config(struct dpu_hw_sspp *ctx,
struct dpu_hw_pixel_ext *pe_ext)
{
struct dpu_hw_blk_reg_map *c;
@@ -414,7 +414,7 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_pipe *ctx,
tot_req_pixels[3]);
}
-static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_pipe *ctx,
+static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *sspp,
void *scaler_cfg)
{
@@ -430,7 +430,7 @@ static void _dpu_hw_sspp_setup_scaler3(struct
dpu_hw_pipe *ctx,
sspp->layout.format);
}
-static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_pipe *ctx)
+static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
{
u32 idx;
@@ -443,7 +443,7 @@ static u32 _dpu_hw_sspp_get_scaler3_ver(struct
dpu_hw_pipe *ctx)
/*
* dpu_hw_sspp_setup_rects()
*/
-static void dpu_hw_sspp_setup_rects(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_rects(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *cfg,
enum dpu_sspp_multirect_index rect_index)
{
@@ -512,7 +512,7 @@ static void dpu_hw_sspp_setup_rects(struct
dpu_hw_pipe *ctx,
DPU_REG_WRITE(c, SSPP_SRC_YSTRIDE1 + idx, ystride1);
}
-static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_sourceaddress(struct dpu_hw_sspp *ctx,
struct dpu_hw_pipe_cfg *cfg,
enum dpu_sspp_multirect_index rect_mode)
{
@@ -539,7 +539,7 @@ static void dpu_hw_sspp_setup_sourceaddress(struct
dpu_hw_pipe *ctx,
}
}
-static void dpu_hw_sspp_setup_csc(struct dpu_hw_pipe *ctx,
+static void dpu_hw_sspp_setup_csc(struct dpu_hw_sspp *ctx,
const struct dpu_csc_cfg *data)
{
u32 idx;
@@ -556,7 +556,7 @@ static void dpu_hw_sspp_setup_csc(struct
dpu_hw_pipe *ctx,
dpu_hw_csc_setup(&ctx->hw, idx, data, csc10);
}
-static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_pipe *ctx, u32
color, enum
+static void dpu_hw_sspp_setup_solidfill(struct dpu_hw_sspp *ctx, u32
color, enum
dpu_sspp_multirect_index rect_index)
{
u32 idx;
@@ -571,7 +571,7 @@ static void dpu_hw_ss
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen wrote: > On Tue, 31 Jan 2023 10:06:39 + > Simon Ser wrote: > > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > > wrote: > > > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > > approach rejected? > > > > Ideally we don't want to allocate any GPU memory for the solid-fill > > stuff. And if we special-case 1x1 FB creation to not be backed by real > > GPU memory then we hit several situations where user-space expects a > > real FB but there isn't: for instance, GETFB2 converts from FB object > > ID to GEM handles. Even if we make GETFB2 fail and accept that this > > breaks user-space, then there is no way for user-space to recover the > > FB color for flicker-free transitions and such. > > > > This is all purely from a uAPI PoV, completely ignoring the potential > > issues with the internal kernel abstractions which might not be suitable > > for this either. > > I mean a real 1x1 buffer: a dumb buffer. > > It would be absolutely compatible with anything existing, because it is > a real FB. As a dumb buffer it would be trivial to write into and read > out. As 1x1 it would be tiny (one page?). Even if something needs to > raw-access uncached memory over 33 MHz PCI bus or whatever the worst > case is, it's just one pixel, so it's fast enough, right? And it only > needs to be read once when set, like USB display drivers do. The driver > does not need to manually apply any color operations, because none are > supported in this special case. > > One can put all these limitations and even pixel format in the plane > property that tells userspace that a 1x1 FB works here. > > To recap, the other alternatives under discussion I see right now are: > > - this proposal of dedicated fill color property > - stuffing something new into FB_ID property > > There is also the question of other kinds of plane content sources like > live camera feeds where userspace won't be shovelling each frame > individually like we do now. > > 1x1 dumb buffer is not as small and lean as a dedicated fill color > property, but the UAPI design questions seem to be much less. What's > the best trade-off and for whom? By "real memory" yes I mean the 1 page. Using a real buffer also brings back other discussions, e.g. the one about which pixel formats to accept.
Re: [PATCH v2 06/27] drm/msm/dpu: move pipe_hw to dpu_plane_state
On 30/01/2023 23:51, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
In preparation to adding fully virtualized planes, move struct
dpu_hw_sspp instance from struct dpu_plane to struct dpu_plane_state, as
it will become a part of state (allocated during atomic check) rather
than part of a plane (allocated during boot).
I was thinking about a couple of things about this patch:
1) Since we are moving away from using "pipe" and using "sspp", perhaps
we can rename pipe_hw to hw_sspp in the below struct
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -35,6 +35,8 @@ struct dpu_plane_state {
uint32_t multirect_mode;
bool pending;
+ struct dpu_hw_pipe *hw_sspp;
+
Ack
u64 plane_fetch_bw;
u64 plane_clk;
};
2) I still dont see any comment as promised in v1 about why we are doing
this in dpu_plane_reset().
https://patchwork.freedesktop.org/patch/473155/?series=99909&rev=1#comment_875365
I think what we need to mention is that the dpu_plane_reset() is the one
which allocates the plane state today and hence pipe_hw can only be
assigned there.
Ack
Rest LGTM.
--
With best wishes
Dmitry
Re: [PATCH] drivers: Restore alignment and newline in Makefile
On Tue, Jan 24, 2023 at 11:41:45AM +0100, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE)+= hte/
> -obj-$(CONFIG_DRM_ACCEL) += accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL) += accel/
> --
> 2.34.1
>
Acked-by: Greg Kroah-Hartman
Re: [PATCH] drivers: Restore alignment and newline in Makefile
On Tue, Jan 24, 2023 at 12:42 PM Geert Uytterhoeven
wrote:
>
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE) += hte/
> -obj-$(CONFIG_DRM_ACCEL)+= accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL)+= accel/
> --
> 2.34.1
>
Reviewed-by: Oded Gabbay
Re: [PATCH v2 10/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index f7f81ab08fa2..176cd6dc9a69 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -415,19 +415,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx)
|| !scaler3_cfg)
Do we need to check for !format ?
We don't have since the calling sequence ensures that it is not NULL,
but let's check for it since it's a different module.
return;
dpu_hw_setup_scaler3(&ctx->hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index f5aae563741a..c713343378aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
- * @ctx: Pointer to pipe context
- * @pipe_cfg: Pointer to pipe configuration
* @scaler_cfg: Pointer to scaler configuration
This doc needs to be fixed from scaler_cfg to scaler3_cfg
+ * @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 172a2c012917..cbff4dea8662 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct
dpu_sw_pipe *pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- &scaler3_cfg);
+ &scaler3_cfg,
+ fmt);
}
/**
--
With best wishes
Dmitry
Re: [PATCH v2 10/27] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
On 31/01/2023 14:10, Dmitry Baryshkov wrote:
On 31/01/2023 07:13, Abhinav Kumar wrote:
On 12/29/2022 11:18 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 7 +++
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 4 ++--
3 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
index f7f81ab08fa2..176cd6dc9a69 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c
@@ -415,19 +415,18 @@ static void dpu_hw_sspp_setup_pe_config(struct
dpu_hw_sspp *ctx,
}
static void _dpu_hw_sspp_setup_scaler3(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *sspp,
- void *scaler_cfg)
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format)
{
u32 idx;
- struct dpu_hw_scaler3_cfg *scaler3_cfg = scaler_cfg;
- if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx) || !sspp
+ if (_sspp_subblk_offset(ctx, DPU_SSPP_SCALER_QSEED3, &idx)
|| !scaler3_cfg)
Do we need to check for !format ?
We don't have since the calling sequence ensures that it is not NULL,
but let's check for it since it's a different module.
On the other hand, dpu_hw_setup_scaler3() properly handles the !format
case and programs the rest of the scaler setup. So in the end I'll skip
this check.
return;
dpu_hw_setup_scaler3(&ctx->hw, scaler3_cfg, idx,
ctx->cap->sblk->scaler_blk.version,
- sspp->layout.format);
+ format);
}
static u32 _dpu_hw_sspp_get_scaler3_ver(struct dpu_hw_sspp *ctx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
index f5aae563741a..c713343378aa 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h
@@ -317,13 +317,12 @@ struct dpu_hw_sspp_ops {
/**
* setup_scaler - setup scaler
- * @ctx: Pointer to pipe context
- * @pipe_cfg: Pointer to pipe configuration
* @scaler_cfg: Pointer to scaler configuration
This doc needs to be fixed from scaler_cfg to scaler3_cfg
+ * @format: pixel format parameters
*/
void (*setup_scaler)(struct dpu_hw_sspp *ctx,
- struct dpu_hw_pipe_cfg *pipe_cfg,
- void *scaler_cfg);
+ struct dpu_hw_scaler3_cfg *scaler3_cfg,
+ const struct dpu_format *format);
/**
* get_scaler_ver - get scaler h/w version
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 172a2c012917..cbff4dea8662 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -677,8 +677,8 @@ static void _dpu_plane_setup_scaler(struct
dpu_sw_pipe *pipe,
if (pipe_hw->ops.setup_scaler &&
pipe->multirect_index != DPU_SSPP_RECT_1)
pipe_hw->ops.setup_scaler(pipe_hw,
- pipe_cfg,
- &scaler3_cfg);
+ &scaler3_cfg,
+ fmt);
}
/**
--
With best wishes
Dmitry
Re: linux-next: manual merge of the usb tree with the drm-intel-fixes tree
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the usb tree got a conflict in:
>
> drivers/gpu/drm/i915/gt/intel_engine_cs.c
>
> between commit:
>
> 5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
>
> from the drm-intel-fixes tree and commit:
>
> 4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes() for
> broader use")
>
> from the usb tree.
>
> I fixed it up (the former removed the code changed by the latter)
Hmm... Currently I see that 20230127002842.3169194-4-john.c.harri...@intel.com
moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
Is there any new series beside the above mentioned that touches that file and
actually _removes_ that code?
> and
> can carry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v12 02/14] drm/msm/disp/dpu: get timing engine status from intf status register
On 30/01/2023 17:11, Vinod Polimera wrote:
Recommended way of reading the interface timing gen status is via
status register. Timing gen status register will give a reliable status
of the interface especially during ON/OFF transitions. This support was
added from DPU version 5.0.0.
Signed-off-by: Vinod Polimera
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +++-
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +++-
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index cf053e8..ce6e9e6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -78,9 +78,11 @@
#define INTF_SDM845_MASK (0)
-#define INTF_SC7180_MASK BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE)
+#define INTF_SC7180_MASK \
+ (BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) |
BIT(DPU_INTF_STATUS_SUPPORTED))
-#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN)
+#define INTF_SC7280_MASK \
+ (INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN))
Not necessary anymore.
With that fixed:
Reviewed-by: Dmitry Baryshkov
#define IRQ_SDM845_MASK (BIT(MDP_SSPP_TOP0_INTR) | \
BIT(MDP_SSPP_TOP0_INTR2) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index ddab9ca..08cd1a1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -213,17 +213,19 @@ enum {
/**
* INTF sub-blocks
- * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
- * pixel data arrives to this INTF
- * @DPU_INTF_TE INTF block has TE configuration support
- * @DPU_DATA_HCTL_ENAllows data to be transferred at different rate
-than video timing
+ * @DPU_INTF_INPUT_CTRL Supports the setting of pp block from which
+ * pixel data arrives to this INTF
+ * @DPU_INTF_TE INTF block has TE configuration support
+ * @DPU_DATA_HCTL_ENAllows data to be transferred at different
rate
+ * than video timing
+ * @DPU_INTF_STATUS_SUPPORTED INTF block has INTF_STATUS register
* @DPU_INTF_MAX
*/
enum {
DPU_INTF_INPUT_CTRL = 0x1,
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
+ DPU_INTF_STATUS_SUPPORTED,
DPU_INTF_MAX
};
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 7ce66bf..84ee2ef 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -62,6 +62,7 @@
#define INTF_LINE_COUNT 0x0B0
#define INTF_MUX 0x25C
+#define INTF_STATUS 0x26C
#define INTF_CFG_ACTIVE_H_EN BIT(29)
#define INTF_CFG_ACTIVE_V_EN BIT(30)
@@ -297,8 +298,13 @@ static void dpu_hw_intf_get_status(
struct intf_status *s)
{
struct dpu_hw_blk_reg_map *c = &intf->hw;
+ unsigned long cap = intf->cap->features;
+
+ if (cap & BIT(DPU_INTF_STATUS_SUPPORTED))
+ s->is_en = DPU_REG_READ(c, INTF_STATUS) & BIT(0);
+ else
+ s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
- s->is_en = DPU_REG_READ(c, INTF_TIMING_ENGINE_EN);
s->is_prog_fetch_en = !!(DPU_REG_READ(c, INTF_CONFIG) & BIT(31));
if (s->is_en) {
s->frame_count = DPU_REG_READ(c, INTF_FRAME_COUNT);
--
With best wishes
Dmitry
Re: [PATCH v12 00/14] Add PSR support for eDP
On 30/01/2023 17:11, Vinod Polimera wrote: Changes in v2: - Use dp bridge to set psr entry/exit instead of dpu_enocder. - Don't modify whitespaces. - Set self refresh aware from atomic_check. - Set self refresh aware only if psr is supported. - Provide a stub for msm_dp_display_set_psr. - Move dp functions to bridge code. Changes in v3: - Change callback names to reflect atomic interfaces. - Move bridge callback change to separate patch as suggested by Dmitry. - Remove psr function declaration from msm_drv.h. - Set self_refresh_aware flag only if psr is supported. - Modify the variable names to simpler form. - Define bit fields for PSR settings. - Add comments explaining the steps to enter/exit psr. - Change DRM_INFO to drm_dbg_db. Changes in v4: - Move the get crtc functions to drm_atomic. - Add atomic functions for DP bridge too. - Add ternary operator to choose eDP or DP ops. - Return true/false instead of 1/0. - mode_valid missing in the eDP bridge ops. - Move the functions to get crtc into drm_atomic.c. - Fix compilation issues. - Remove dpu_assign_crtc and get crtc from drm_enc instead of dpu_enc. - Check for crtc state enable while reserving resources. Changes in v5: - Move the mode_valid changes into a different patch. - Complete psr_op_comp only when isr is set. - Move the DP atomic callback changes to a different patch. - Get crtc from drm connector state crtc. - Move to separate patch for check for crtc state enable while reserving resources. Changes in v6: - Remove crtc from dpu_encoder_virt struct. - fix crtc check during vblank toggle crtc. - Misc changes. Changes in v7: - Add fix for underrun issue on kasan build. Changes in v8: - Drop the enc spinlock as it won't serve any purpose in protetcing conn state.(Dmitry/Doug) Changes in v9: - Update commit message and fix alignment using spaces.(Marijn) - Misc changes.(Marijn) Changes in v10: - Get crtc cached in dpu_enc during obj init.(Dmitry) Changes in v11: - Remove crtc cached in dpu_enc during obj init. - Update dpu_enc crtc state on crtc enable/disable during self refresh. Changes in v12: - Update sc7180 intf mask to get intf timing gen status based on DPU_INTF_STATUS_SUPPORTED bit.(Dmitry) - Remove "clear active interface in the datapath cleanup" change as it is already included. - Move core changes to top of the series.(Dmitry) Unfortunately they still are not at the top. Sankeerth Billakanti (1): drm/msm/dp: disable self_refresh_aware after entering psr Vinod Polimera (13): drm/msm/disp/dpu: check for crtc enable rather than crtc active to release shared resources drm/msm/disp/dpu: get timing engine status from intf status register drm/msm/disp/dpu: wait for extra vsync till timing engine status is disabled drm/msm/disp/dpu: reset the datapath after timing engine disable drm: add helper functions to retrieve old and new crtc drm/msm/dp: use atomic callbacks for DP bridge ops drm/msm/dp: Add basic PSR support for eDP drm/msm/dp: use the eDP bridge ops to validate eDP modes drm/bridge: use atomic enable/disable callbacks for panel bridge drm/bridge: add psr support for panel bridge callbacks drm/msm/disp/dpu: use atomic enable/disable callbacks for encoder functions drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver drm/msm/disp/dpu: update dpu_enc crtc state on crtc enable/disable during self refresh drivers/gpu/drm/bridge/panel.c | 68 +++- drivers/gpu/drm/drm_atomic.c | 60 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 40 - drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 26 ++- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 22 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 12 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 2 +- drivers/gpu/drm/msm/dp/dp_catalog.c| 80 + drivers/gpu/drm/msm/dp/dp_catalog.h| 4 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 80 + drivers/gpu/drm/msm/dp/dp_ctrl.h | 3 + drivers/gpu/drm/msm/dp/dp_display.c| 36 ++-- drivers/gpu/drm/msm/dp/dp_display.h| 2 + drivers/gpu/drm/msm/dp/dp_drm.c| 194 - drivers/gpu/drm/msm/dp/dp_drm.h| 9 +- drivers/gpu/drm/msm/dp/dp_link.c | 36 drivers/gpu/drm/msm/dp/dp_panel.c | 22 +++ drivers/gpu/drm/msm/dp/dp_panel.h | 6 + drivers/gpu/drm/msm/dp/dp_reg.h| 27 +++ include/drm/drm_atomic.h | 7 + 22 files changed, 706 insertions(+)
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > Hi, > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > wrote: > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard wrote: > > > > > > > > > > Hi, > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > endpoint number, find the connected node and return either > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > I'm not sure that using a device managed helper is the right choice > > > > > here. The bridge will stay longer than the backing device so it will > > > > > create a use-after-free. You should probably use a DRM-managed action > > > > > here instead. > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we found > > > > the panel or bridge - am I correct? > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > which we cannot find drm_device pointer (as drm_device pointer is > > > mandatory for using DRM-managed action). > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > You shouldn't call that function from attach anyway: > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > True, If I remember we have bridges earlier to find the downstream > bridge/panels from the bridge ops and attach the hook, if that is the > case maybe we can use this DRM-managed action as we can get the > drm_device pointer from the bridge pointer. I'm not quite sure what you mean. You shouldn't retrieve the bridge from the attach hook but from the probe / bind ones. If that's not working for you, this is a bug in the documentation we should address. > So, what is the best we can do here, add any TODO comment to follow up > the same in the future or something else, please let me know? Make it work in a safe way, as described in the documentation? Maxime
Re: [PATCH v12 09/14] drm/msm/dp: disable self_refresh_aware after entering psr
On 30/01/2023 17:11, Vinod Polimera wrote: From: Sankeerth Billakanti Updated frames get queued if self_refresh_aware is set when the sink is in psr. To support bridge enable and avoid queuing of update frames, reset the self_refresh_aware state after entering psr. Signed-off-by: Sankeerth Billakanti Signed-off-by: Vinod Polimera --- drivers/gpu/drm/msm/dp/dp_drm.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) As I stated in v11's discussion, I do not like the way this change plays with the self_refresh_aware. Please find another way to work around the timing issue (let's probably continue the discussion back in v11). -- With best wishes Dmitry
Re: [RFC PATCH v3 0/3] Support for Solid Fill Planes
On Tue, 31 Jan 2023 11:21:18 + Simon Ser wrote: > On Tuesday, January 31st, 2023 at 12:13, Pekka Paalanen > wrote: > > > On Tue, 31 Jan 2023 10:06:39 + > > Simon Ser wrote: > > > > > On Tuesday, January 31st, 2023 at 10:25, Pekka Paalanen > > > wrote: > > > > > > > indeed, what about simply using a 1x1 framebuffer for real? Why was that > > > > approach rejected? > > > > > > Ideally we don't want to allocate any GPU memory for the solid-fill > > > stuff. And if we special-case 1x1 FB creation to not be backed by real > > > GPU memory then we hit several situations where user-space expects a > > > real FB but there isn't: for instance, GETFB2 converts from FB object > > > ID to GEM handles. Even if we make GETFB2 fail and accept that this > > > breaks user-space, then there is no way for user-space to recover the > > > FB color for flicker-free transitions and such. > > > > > > This is all purely from a uAPI PoV, completely ignoring the potential > > > issues with the internal kernel abstractions which might not be suitable > > > for this either. > > > > I mean a real 1x1 buffer: a dumb buffer. > > > > It would be absolutely compatible with anything existing, because it is > > a real FB. As a dumb buffer it would be trivial to write into and read > > out. As 1x1 it would be tiny (one page?). Even if something needs to > > raw-access uncached memory over 33 MHz PCI bus or whatever the worst > > case is, it's just one pixel, so it's fast enough, right? And it only > > needs to be read once when set, like USB display drivers do. The driver > > does not need to manually apply any color operations, because none are > > supported in this special case. > > > > One can put all these limitations and even pixel format in the plane > > property that tells userspace that a 1x1 FB works here. > > > > To recap, the other alternatives under discussion I see right now are: > > > > - this proposal of dedicated fill color property > > - stuffing something new into FB_ID property > > > > There is also the question of other kinds of plane content sources like > > live camera feeds where userspace won't be shovelling each frame > > individually like we do now. > > > > 1x1 dumb buffer is not as small and lean as a dedicated fill color > > property, but the UAPI design questions seem to be much less. What's > > the best trade-off and for whom? > > By "real memory" yes I mean the 1 page. > > Using a real buffer also brings back other discussions, e.g. the one about > which pixel formats to accept. Yeah, which is why I wrote: "One can put all these limitations and even pixel format in the plane property". It doesn't even need to be a variable in the UAPI, it can be hardcoded in the UAPI doc. Please, do not understand this as me strongly advocating for the real FB approach! I just don't want that option to be misunderstood. I don't really care which design is chosen, but I do care about documenting why other designs were rejected. If the rejection reasons were false, they should be revised, even if the decision does not change. Thanks, pq pgpszxg8fCqxd.pgp Description: OpenPGP digital signature
Re: [PATCH] drivers: Restore alignment and newline in Makefile
Applied to drm-misc-next.
Thanks.
On 24.01.2023 11:41, Geert Uytterhoeven wrote:
> The introduction of drivers/accel/ broke alignment, and removed the
> newline at the end of the file. Fix all of that.
>
> Fixes: 35b137630f08d913 ("accel/ivpu: Introduce a new DRM driver for Intel
> VPU")
> Signed-off-by: Geert Uytterhoeven
> ---
> drivers/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/Makefile b/drivers/Makefile
> index f0972e2226c97cb5..9ea6eb3b5d7b7f17 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -189,4 +189,4 @@ obj-$(CONFIG_COUNTER) += counter/
> obj-$(CONFIG_MOST) += most/
> obj-$(CONFIG_PECI) += peci/
> obj-$(CONFIG_HTE)+= hte/
> -obj-$(CONFIG_DRM_ACCEL) += accel/
> \ No newline at end of file
> +obj-$(CONFIG_DRM_ACCEL) += accel/
Re: [PATCH v12 13/14] drm/msm/disp/dpu: add PSR support for eDP interface in dpu driver
On 30/01/2023 17:11, Vinod Polimera wrote:
Enable PSR on eDP interface using drm self-refresh librabry.
This patch uses a trigger from self-refresh library to enter/exit
into PSR, when there are no updates from framework.
Signed-off-by: Kalyan Thota
Signed-off-by: Vinod Polimera
Reviewed-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 13 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 14 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +-
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index f29a339..60e5984 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "dpu_kms.h"
#include "dpu_hw_lm.h"
@@ -1021,6 +1022,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
DRM_DEBUG_KMS("crtc%d\n", crtc->base.id);
+ if (old_crtc_state->self_refresh_active)
+ return;
+
I have been looking at the crtc_needs_disable(). It explicitly mentions
that 'We also need to run through the crtc_funcs->disable() function
[..] if it's transitioning to self refresh mode...'. Don't we need to
perform some cleanup here (like disabling the vblank irq handling,
freeing the bandwidth, etc)?
/* Disable/save vblank irq handling */
drm_crtc_vblank_off(crtc);
@@ -1577,7 +1581,7 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev, struct drm_plane *plane,
{
struct drm_crtc *crtc = NULL;
struct dpu_crtc *dpu_crtc = NULL;
- int i;
+ int i, ret;
dpu_crtc = kzalloc(sizeof(*dpu_crtc), GFP_KERNEL);
if (!dpu_crtc)
@@ -1614,6 +1618,13 @@ struct drm_crtc *dpu_crtc_init(struct drm_device *dev,
struct drm_plane *plane,
/* initialize event handling */
spin_lock_init(&dpu_crtc->event_lock);
+ ret = drm_self_refresh_helper_init(crtc);
+ if (ret) {
+ DPU_ERROR("Failed to initialize %s with self-refresh helpers
%d\n",
+ crtc->name, ret);
+ return ERR_PTR(ret);
+ }
+
DRM_DEBUG_KMS("%s: successfully initialized crtc\n", dpu_crtc->name);
return crtc;
}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 01b7509..450abb1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -12,6 +12,7 @@
#include
#include
+#include
#include
#include
#include
@@ -1212,11 +1213,24 @@ static void dpu_encoder_virt_atomic_disable(struct
drm_encoder *drm_enc,
struct drm_atomic_state *state)
{
struct dpu_encoder_virt *dpu_enc = NULL;
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_state = NULL;
int i = 0;
dpu_enc = to_dpu_encoder_virt(drm_enc);
DPU_DEBUG_ENC(dpu_enc, "\n");
+ crtc = drm_atomic_get_old_crtc_for_encoder(state, drm_enc);
+ if (crtc)
+ old_state = drm_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+* The encoder is already disabled if self refresh mode was set earlier,
+* in the old_state for the corresponding crtc.
+*/
+ if (old_state && old_state->self_refresh_active)
+ return;
+
Again the same question here, doesn't crtc_needs_disable() take care of
this clause? I might be missing something in the PSR state transitions.
Could you please add some explanation here?
mutex_lock(&dpu_enc->enc_lock);
dpu_enc->enabled = false;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index a683bd9..681dd2e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -491,7 +491,7 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms
*kms,
return;
}
- if (!crtc->state->active) {
+ if (!drm_atomic_crtc_effectively_active(crtc->state)) {
DPU_DEBUG("[crtc:%d] not active\n", crtc->base.id);
return;
}
--
With best wishes
Dmitry
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote: > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > > Hi, > > > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > > wrote: > > > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > > endpoint number, find the connected node and return either > > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > > > I'm not sure that using a device managed helper is the right choice > > > > > > here. The bridge will stay longer than the backing device so it will > > > > > > create a use-after-free. You should probably use a DRM-managed > > > > > > action > > > > > > here instead. > > > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we found > > > > > the panel or bridge - am I correct? > > > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > > which we cannot find drm_device pointer (as drm_device pointer is > > > > mandatory for using DRM-managed action). > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > > > You shouldn't call that function from attach anyway: > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > > > True, If I remember we have bridges earlier to find the downstream > > bridge/panels from the bridge ops and attach the hook, if that is the > > case maybe we can use this DRM-managed action as we can get the > > drm_device pointer from the bridge pointer. > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from > the attach hook but from the probe / bind ones. If that's not working > for you, this is a bug in the documentation we should address. Something like this, afterward the design has updated to move the panel or bridge found to be in host attach. https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911 > > > So, what is the best we can do here, add any TODO comment to follow up > > the same in the future or something else, please let me know? > > Make it work in a safe way, as described in the documentation? Yeah, it is a clear deadlock. It is not possible to use DM-managed action helper in host attach as there is no drm_device pointer and we cannot move panel or bridge finding out of host attach as per design documentation. I'm thinking of go-ahead with adding TODO for adding the safe way with an existing patch. Please let me know. Thanks, Jagan.
RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
Hi Christian,
Do you think if it makes sense that we can set 'ring->sched.ready' to be true
in each ring init, even if before executing/setting up drm_sched_init in
amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler
structure.
Regards,
Guchun
-Original Message-
From: Koenig, Christian
Sent: Tuesday, January 31, 2023 6:59 PM
To: Chen, Guchun ; Alex Deucher ;
Guilherme G. Piccoli
Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
; dri-devel@lists.freedesktop.org; Tuikov, Luben
; Limonciello, Mario ;
kernel-...@igalia.com; Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched
init/fini
Am 31.01.23 um 10:17 schrieb Chen, Guchun:
> Hi Piccoli,
>
> Please ignore my request of full dmesg log. I can reproduce the issue and get
> the same failure callstack by returning early with an error code prior to
> amdgpu_device_init_schedulers.
>
> Regards,
> Guchun
>
> -Original Message-
> From: Chen, Guchun
> Sent: Tuesday, January 31, 2023 2:37 PM
> To: Alex Deucher ; Guilherme G. Piccoli
>
> Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
> ; dri-devel@lists.freedesktop.org; Tuikov, Luben
> ; Limonciello, Mario
> ; kernel-...@igalia.com; Deucher, Alexander
> ; Koenig, Christian
>
> Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> drm_sched init/fini
>
> Hi Piccoli,
>
> I agree with Alex's point, using ring->sched.name for such check is not a
> good way. BTW, can you please attach a full dmesg long in bad case to help me
> understand more?
>
> Regards,
> Guchun
>
> -Original Message-
> From: Alex Deucher
> Sent: Tuesday, January 31, 2023 6:30 AM
> To: Guilherme G. Piccoli
> Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
> ; Pan, Xinhui ;
> dri-devel@lists.freedesktop.org; Tuikov, Luben ;
> Limonciello, Mario ; kernel-...@igalia.com;
> Deucher, Alexander ; Koenig, Christian
>
> Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> drm_sched init/fini
>
> On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
> wrote:
>> + Luben
>>
>> (sorry, missed that in the first submission).
>>
>> On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
>>> Currently amdgpu calls drm_sched_fini() from the fence driver sw
>>> fini routine - such function is expected to be called only after the
>>> respective init function - drm_sched_init() - was executed successfully.
>>>
>>> Happens that we faced a driver probe failure in the Steam Deck
>>> recently, and the function drm_sched_fini() was called even without
>>> its counter-part had been previously called, causing the following oops:
>>>
>>> amdgpu: probe of :04:00.0 failed with error -110
>>> BUG: kernel NULL pointer dereference, address: 0090 PGD
>>> 0 P4D 0
>>> Oops: 0002 [#1] PREEMPT SMP NOPTI
>>> CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
>>> #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
>>> RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
>>>
>>> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
>>> amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
>>> amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
>>> devm_drm_dev_init_release+0x49/0x70
>>> [...]
>>>
>>> To prevent that, check if the drm_sched was properly initialized for
>>> a given ring before calling its fini counter-part.
>>>
>>> Notice ideally we'd use sched.ready for that; such field is set as
>>> the latest thing on drm_sched_init(). But amdgpu seems to "override"
>>> the meaning of such field - in the above oops for example, it was a
>>> GFX ring causing the crash, and the sched.ready field was set to
>>> true in the ring init routine, regardless of the state of the DRM
>>> scheduler. Hence, we ended-up using another sched field.
> Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
> driver fini in s3 test (v2)")
>>> Cc: Andrey Grodzovsky
>>> Cc: Guchun Chen
>>> Cc: Mario Limonciello
>>> Signed-off-by: Guilherme G. Piccoli
>>> ---
>>>
>>>
>>> Hi folks, first of all thanks in advance for reviews / comments!
>>> Notice that I've used the Fixes tag more in the sense to bring it to
>>> stable, I didn't find a good patch candidate that added the call to
>>> drm_sched_fini(), was reaching way too old commits...so
>>> 067f44c8b459 seems a good candidate - or maybe not?
>>>
>>> Now, with regards sched.ready, spent a bit of time to figure what
>>> was happening...would be feasible maybe to stop using that to mark
>>> some kind ring status? I think it should be possible to add a flag
>>> to the ring structure for that, and free sched.ready from being
>>> manipulate by the amdgpu driver, what's your thoughts on that?
> It's been a while, but IIRC, we used to have a ring->ready field in the
> driver which at some point got migrated out of the driver into the GPU
> scheduler and the driver side code never got
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote: > On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote: > > > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote: > > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote: > > > > > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote: > > > > > Hi, > > > > > > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki > > > > > wrote: > > > > > > > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard > > > > > > wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote: > > > > > > > > Add devm OF helper to return the next DSI bridge in the chain. > > > > > > > > > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge, this > > > > > > > > helper uses the dsi specific panel_or_bridge helper to find the > > > > > > > > next DSI device in the pipeline. > > > > > > > > > > > > > > > > Helper lookup a given child DSI node or a DT node's port and > > > > > > > > endpoint number, find the connected node and return either > > > > > > > > the associated struct drm_panel or drm_bridge device. > > > > > > > > > > > > > > I'm not sure that using a device managed helper is the right > > > > > > > choice > > > > > > > here. The bridge will stay longer than the backing device so it > > > > > > > will > > > > > > > create a use-after-free. You should probably use a DRM-managed > > > > > > > action > > > > > > > here instead. > > > > > > > > > > > > Thanks for the comments. If I understand correctly we can use > > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we > > > > > > found > > > > > > the panel or bridge - am I correct? > > > > > > > > > > Look like it is not possible to use DRM-managed action helper here as > > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook in > > > > > which we cannot find drm_device pointer (as drm_device pointer is > > > > > mandatory for using DRM-managed action). > > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545 > > > > > > > > > > Please check and correct me if I mentioned any incorrect details. > > > > > > > > You shouldn't call that function from attach anyway: > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges > > > > > > True, If I remember we have bridges earlier to find the downstream > > > bridge/panels from the bridge ops and attach the hook, if that is the > > > case maybe we can use this DRM-managed action as we can get the > > > drm_device pointer from the bridge pointer. > > > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from > > the attach hook but from the probe / bind ones. If that's not working > > for you, this is a bug in the documentation we should address. > > Something like this, afterward the design has updated to move the > panel or bridge found to be in host attach. > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911 What are you pointing to exactly, it's not a MIPI-DSI host attach, that's a bridge attach, you have access to the DRM device there. > > > > > So, what is the best we can do here, add any TODO comment to follow up > > > the same in the future or something else, please let me know? > > > > Make it work in a safe way, as described in the documentation? > > Yeah, it is a clear deadlock. It is not possible to use DM-managed > action helper in host attach as there is no drm_device pointer and we > cannot move panel or bridge finding out of host attach as per design > documentation. I'm thinking of go-ahead with adding TODO for adding > the safe way with an existing patch. Please let me know. I've been telling you for three mails now that it's not acceptable. So, again, no, it's not acceptable. Do something else and follow the documentation instead. Maxime
Re: [PATCH 2/2] accel/ivpu: avoid duplciate assignment
Applied to drm-misc-next. Thanks.
On 26.01.2023 17:37, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With extra warnings enabled, gcc warns about two assignments
> of the same .mmap callback:
>
> In file included from drivers/accel/ivpu/ivpu_drv.c:10:
> include/drm/drm_accel.h:31:27: error: initialized field overwritten
> [-Werror=override-init]
>31 | .mmap = drm_gem_mmap
> | ^~~~
> drivers/accel/ivpu/ivpu_drv.c:360:9: note: in expansion of macro
> 'DRM_ACCEL_FOPS'
> 360 | DRM_ACCEL_FOPS,
> | ^~
>
> Remove the unused local assignment.
>
> Fixes: 20709aa9435b ("accel: Add .mmap to DRM_ACCEL_FOPS")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/accel/ivpu/ivpu_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/accel/ivpu/ivpu_drv.c b/drivers/accel/ivpu/ivpu_drv.c
> index 2bc2f1b90671..a29e8ee0dce6 100644
> --- a/drivers/accel/ivpu/ivpu_drv.c
> +++ b/drivers/accel/ivpu/ivpu_drv.c
> @@ -356,7 +356,6 @@ int ivpu_shutdown(struct ivpu_device *vdev)
>
> static const struct file_operations ivpu_fops = {
> .owner = THIS_MODULE,
> - .mmap = drm_gem_mmap,
> DRM_ACCEL_FOPS,
> };
>
Re: [PATCH v2 1/4] memcg: Track exported dma-buffers
On 25/01/2023 20:04, T.J. Mercier wrote: On Wed, Jan 25, 2023 at 9:31 AM Tvrtko Ursulin wrote: Hi, On 25/01/2023 11:52, Michal Hocko wrote: On Tue 24-01-23 19:46:28, Shakeel Butt wrote: On Tue, Jan 24, 2023 at 03:59:58PM +0100, Michal Hocko wrote: On Mon 23-01-23 19:17:23, T.J. Mercier wrote: When a buffer is exported to userspace, use memcg to attribute the buffer to the allocating cgroup until all buffer references are released. Is there any reason why this memory cannot be charged during the allocation (__GFP_ACCOUNT used)? Also you do charge and account the memory but underlying pages do not know about their memcg (this is normally done with commit_charge for user mapped pages). This would become a problem if the memory is migrated for example. I don't think this is movable memory. This also means that you have to maintain memcg reference outside of the memcg proper which is not really nice either. This mimicks tcp kmem limit implementation which I really have to say I am not a great fan of and this pattern shouldn't be coppied. I think we should keep the discussion on technical merits instead of personal perference. To me using skmem like interface is totally fine but the pros/cons need to be very explicit and the clear reasons to select that option should be included. I do agree with that. I didn't want sound to be personal wrt tcp kmem accounting but the overall code maintenance cost is higher because of how tcp take on accounting differs from anything else in the memcg proper. I would prefer to not grow another example like that. To me there are two options: 1. Using skmem like interface as this patch series: The main pros of this option is that it is very simple. Let me list down the cons of this approach: a. There is time window between the actual memory allocation/free and the charge and uncharge and [un]charge happen when the whole memory is allocated or freed. I think for the charge path that might not be a big issue but on the uncharge, this can cause issues. The application and the potential shrinkers have freed some of this dmabuf memory but until the whole dmabuf is freed, the memcg uncharge will not happen. This can consequences on reclaim and oom behavior of the application. b. Due to the usage model i.e. a central daemon allocating the dmabuf memory upfront, there is a requirement to have a memcg charge transfer functionality to transfer the charge from the central daemon to the client applications. This does introduce complexity and avenues of weird reclaim and oom behavior. 2. Allocate and charge the memory on page fault by actual user In this approach, the memory is not allocated upfront by the central daemon but rather on the page fault by the client application and the memcg charge happen at the same time. The only cons I can think of is this approach is more involved and may need some clever tricks to track the page on the free patch i.e. we to decrement the dmabuf memcg stat on free path. Maybe a page flag. The pros of this approach is there is no need have a charge transfer functionality and the charge/uncharge being closely tied to the actual memory allocation and free. Personally I would prefer the second approach but I don't want to just block this work if the dmabuf folks are ok with the cons mentioned of the first approach. I am not familiar with dmabuf internals to judge complexity on their end but I fully agree that charge-when-used is much more easier to reason about and it should have less subtle surprises. Disclaimer that I don't seem to see patches 3&4 on dri-devel so maybe I am missing something, but in principle yes, I agree that the 2nd option (charge the user, not exporter) should be preferred. Thing being that at export time there may not be any backing store allocated, plus if the series is restricting the charge transfer to just Android clients then it seems it has the potential to miss many other use cases. At least needs to outline a description on how the feature will be useful outside Android. There is no restriction like that. It's available to anybody who wants to call dma_buf_charge_transfer if they actually have a need for that, which I don't really expect to be common since most users/owners of the buffers will be the ones causing the export in the first place. It's just not like that on Android with the extra allocator process in the middle most of the time. Yeah I used the wrong term "restrict", apologies. What I meant was, if the idea was to allow spotting memory leaks, with the charge transfer being optional and in the series only wired up for Android Binder, then it obviously only fully works for that one case. So a step back.. .. For instance, it is not feasible to transfer the charge when dmabuf is attached, or imported? That would attribute the usage to the user/importer so give better visibility on who is actually causing the memory leak. Further more, if above is feasible, then could it al
Re: [RESEND PATCH v11 02/18] drm: bridge: panel: Add devm_drm_of_dsi_get_bridge helper
On Tue, Jan 31, 2023 at 7:29 PM Maxime Ripard wrote:
>
> On Tue, Jan 31, 2023 at 07:17:50PM +0530, Jagan Teki wrote:
> > On Tue, Jan 31, 2023 at 6:16 PM Maxime Ripard wrote:
> > >
> > > On Mon, Jan 30, 2023 at 06:54:54PM +0530, Jagan Teki wrote:
> > > > On Mon, Jan 30, 2023 at 6:26 PM Maxime Ripard wrote:
> > > > >
> > > > > On Fri, Jan 27, 2023 at 11:09:26PM +0530, Jagan Teki wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Thu, Jan 26, 2023 at 8:48 PM Jagan Teki
> > > > > > wrote:
> > > > > > >
> > > > > > > On Thu, Jan 26, 2023 at 5:42 PM Maxime Ripard
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > On Mon, Jan 23, 2023 at 08:41:56PM +0530, Jagan Teki wrote:
> > > > > > > > > Add devm OF helper to return the next DSI bridge in the chain.
> > > > > > > > >
> > > > > > > > > Unlike general bridge return helper devm_drm_of_get_bridge,
> > > > > > > > > this
> > > > > > > > > helper uses the dsi specific panel_or_bridge helper to find
> > > > > > > > > the
> > > > > > > > > next DSI device in the pipeline.
> > > > > > > > >
> > > > > > > > > Helper lookup a given child DSI node or a DT node's port and
> > > > > > > > > endpoint number, find the connected node and return either
> > > > > > > > > the associated struct drm_panel or drm_bridge device.
> > > > > > > >
> > > > > > > > I'm not sure that using a device managed helper is the right
> > > > > > > > choice
> > > > > > > > here. The bridge will stay longer than the backing device so it
> > > > > > > > will
> > > > > > > > create a use-after-free. You should probably use a DRM-managed
> > > > > > > > action
> > > > > > > > here instead.
> > > > > > >
> > > > > > > Thanks for the comments. If I understand correctly we can use
> > > > > > > drmm_panel_bridge_add instead devm_drm_panel_bridge_add once we
> > > > > > > found
> > > > > > > the panel or bridge - am I correct?
> > > > > >
> > > > > > Look like it is not possible to use DRM-managed action helper here
> > > > > > as
> > > > > > devm_drm_of_dsi_get_bridge is calling from the DSI host attach hook
> > > > > > in
> > > > > > which we cannot find drm_device pointer (as drm_device pointer is
> > > > > > mandatory for using DRM-managed action).
> > > > > > https://github.com/openedev/kernel/blob/imx8mm-dsi-v12/drivers/gpu/drm/bridge/samsung-dsim.c#L1545
> > > > > >
> > > > > > Please check and correct me if I mentioned any incorrect details.
> > > > >
> > > > > You shouldn't call that function from attach anyway:
> > > > > https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html#special-care-with-mipi-dsi-bridges
> > > >
> > > > True, If I remember we have bridges earlier to find the downstream
> > > > bridge/panels from the bridge ops and attach the hook, if that is the
> > > > case maybe we can use this DRM-managed action as we can get the
> > > > drm_device pointer from the bridge pointer.
> > >
> > > I'm not quite sure what you mean. You shouldn't retrieve the bridge from
> > > the attach hook but from the probe / bind ones. If that's not working
> > > for you, this is a bug in the documentation we should address.
> >
> > Something like this, afterward the design has updated to move the
> > panel or bridge found to be in host attach.
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/bridge/nwl-dsi.c?h=v5.10#n911
>
> What are you pointing to exactly, it's not a MIPI-DSI host attach,
> that's a bridge attach, you have access to the DRM device there.
Yes, what I'm saying here is we can have the option to use a DRM
device pointer so finding the panel or bridge by using a DRM-managed
action helper can be possible rather than host attach.
Something like this,
struct drm_bridge *drmm_of_dsi_get_bridge(struct drm_device *drm,
struct device_node *np,
u32 port, u32 endpoint)
{
struct drm_bridge *bridge;
struct drm_panel *panel;
int ret;
ret = drm_of_dsi_find_panel_or_bridge(np, port, endpoint,
&panel, &bridge);
if (ret)
return ERR_PTR(ret);
if (panel)
bridge = drmm_panel_bridge_add(drm, panel);
return bridge;
}
static int nwl_dsi_bridge_attach(struct drm_bridge *bridge, enum
drm_bridge_attach_flags flags)
{
struct nwl_dsi *dsi = bridge_to_dsi(bridge);
struct drm_bridge *bridge;
int ret;
bridge = drmm_of_dsi_get_bridge(bridge->dev, dsi->dev->of_node, 1, 0);
if (IS_ERR(bridge))
ret = PTR_ERR(dsi->out_bridge);
return drm_bridge_attach(bridge->encoder, dsi->panel_bridge,
bridge, flags);
}
static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = {
.attach = nwl_dsi_bridge_attach,
};
>
> > >
> > > > So, what is the best we can do here, add any TODO comment to follow up
> > > > the same in the future or something else, please let me
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On 31/01/2023 10:58, Chen, Guchun wrote: > Hi Christian, > > Do you think if it makes sense that we can set 'ring->sched.ready' to be true > in each ring init, even if before executing/setting up drm_sched_init in > amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler > structure. > > Regards, > Guchun > Hi folks, thanks a lot for the feedback so far, much appreciated! I'm feeling a bit confused specially since there seems to be 2 orthogonal (yet related) topics being discussed; let me try to summarize my understanding and we can then further discuss better: (a) The first problem is the one addressed in the patch - how to prevent drm_sched_fini() to get called if drm_sched_init() wasn't called? I've proposed sched.name, seems Christian prefers sched.ops, correct? (b) We can't use sched.ready, which would make sense...but amdgpu overrides its meaning, the driver manipulates this value for its own purposes of tracking ring init, or something like that. This is the tangential topic: what should we do here? My understanding of Alex's message is that we could have a "ready" field in the ring structure and stop messing with sched.ready - does it make sense Alex? Guchun / Christian, does it also make sense for you? Regarding (a), I could re-submit having s/sched.name/sched.ops, no biggies, I tested both to be fair, before sending...I just chose name but any field that is proper initialized on drm_sched_init() would work. Thanks, Guilherme
Re: [PATCH] drm/amd/display: Trivial swizzle-related code clean-ups
On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> This is a very trivial code clean-up related to commit 5468c36d6285
> ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> added a validation on driver probe to prevent invalid TMDS modes, but one
> of the fake properties (swizzle) ended-up causing a warning on driver
> probe; was reported here:
> https://gitlab.freedesktop.org/drm/amd/-/issues/2264.
>
> It was fixed by commit 105a8b8698e2 ("drm/amd/display: patch cases with
> unknown plane state to prevent warning"), but the validation code had
> a double variable assignment, which we hereby remove. Also, the fix relies
> in the dcn2{0,1}patch_unknown_plane_state() callbacks, so while at it we
> took the opportunity to perform a small code clean-up in such routines.
>
> Cc: Aurabindo Pillai
> Cc: Daniel Wheeler
> Cc: Fangzhi Zuo
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Mark Broadworth
> Cc: Melissa Wen
> Cc: Rodrigo Siqueira
> Cc: Sung Joon Kim
> Cc: Swapnil Patel
> Signed-off-by: Guilherme G. Piccoli
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8 ++--
> drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 ++
> 3 files changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 86a2f7f58550..e71e94663d14 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -6336,7 +6336,6 @@ static enum dc_status
> dm_validate_stream_and_context(struct dc *dc,
> dc_plane_state->plane_size.surface_size.width = stream->src.width;
> dc_plane_state->plane_size.chroma_size.height = stream->src.height;
> dc_plane_state->plane_size.chroma_size.width = stream->src.width;
> - dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> dc_plane_state->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB;
> dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> dc_plane_state->rotation = ROTATION_ANGLE_0;
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> index 531f405d2554..3af24ef9cb2d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> @@ -2225,14 +2225,10 @@ enum dc_status dcn20_patch_unknown_plane_state(struct
> dc_plane_state *plane_stat
> enum surface_pixel_format surf_pix_format = plane_state->format;
> unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
>
> - enum swizzle_mode_values swizzle = DC_SW_LINEAR;
> -
> + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_S;
> if (bpp == 64)
> - swizzle = DC_SW_64KB_D;
> - else
> - swizzle = DC_SW_64KB_S;
> + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_D;
>
> - plane_state->tiling_info.gfx9.swizzle = swizzle;
> return DC_OK;
> }
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> index fbcf0afeae0d..8f9244fe5c86 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> @@ -1393,15 +1393,13 @@ static uint32_t read_pipe_fuses(struct dc_context
> *ctx)
>
> static enum dc_status dcn21_patch_unknown_plane_state(struct dc_plane_state
> *plane_state)
> {
> - enum dc_status result = DC_OK;
> -
> if (plane_state->ctx->dc->debug.disable_dcc == DCC_ENABLE) {
> plane_state->dcc.enable = 1;
> /* align to our worst case block width */
> plane_state->dcc.meta_pitch = ((plane_state->src_rect.width +
> 1023) / 1024) * 1024;
> }
> - result = dcn20_patch_unknown_plane_state(plane_state);
> - return result;
> +
> + return dcn20_patch_unknown_plane_state(plane_state);
> }
>
> static const struct resource_funcs dcn21_res_pool_funcs = {
Re: [PATCHv2] fbcon: Check font dimension limits
On Sun, Jan 29, 2023 at 04:17:40PM +0100, Samuel Thibault wrote:
> blit_x and blit_y are u32, so fbcon currently cannot support fonts
> larger than 32x32.
>
> The 32x32 case also needs shifting an unsigned int, to properly set bit
> 31, otherwise we get "UBSAN: shift-out-of-bounds in fbcon_set_font",
> as reported on:
>
> http://lore.kernel.org/all/ia1pr07mb98308653e259a6f2ce94a4afab...@ia1pr07mb9830.namprd07.prod.outlook.com
> Kernel Branch: 6.2.0-rc5-next-20230124
> Kernel config:
> https://drive.google.com/file/d/1F-LszDAizEEH0ZX0HcSR06v5q8FPl2Uv/view?usp=sharing
> Reproducer:
> https://drive.google.com/file/d/1mP1jcLBY7vWCNM60OMf-ogw-urQRjNrm/view?usp=sharing
>
> Reported-by: Sanan Hasanov
> Signed-off-by: Samuel Thibault
> Fixes: 2d2699d98492 ("fbcon: font setting should check limitation of driver")
> Cc: sta...@vger.kernel.org
Reviewed-by: Greg Kroah-Hartman
[PATCH AUTOSEL 6.1 18/20] drm/amd/display: Fix timing not changning when freesync video is enabled
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why&How]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue is fixed by ensuring that when a non freesync video mode is
set, we reset the freesync status on the crtc.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Aurabindo Pillai
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index e10f1f15c9c4..15b408e3a705 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -8788,6 +8788,13 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
if (!dm_old_crtc_state->stream)
goto skip_modeset;
+ /* Unset freesync video if it was active before */
+ if (dm_old_crtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_FIXED) {
+ dm_new_crtc_state->freesync_config.state =
VRR_STATE_INACTIVE;
+ dm_new_crtc_state->freesync_config.fixed_refresh_in_uhz
= 0;
+ }
+
+ /* Now check if we should set freesync video mode */
if (amdgpu_freesync_vid_mode && dm_new_crtc_state->stream &&
is_timing_unchanged_for_freesync(new_crtc_state,
old_crtc_state)) {
--
2.39.0
[PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
From: Dave Airlie [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 15b408e3a705..d756a606b5e2 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, bool lock_and_validation_needed = false; struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct drm_dp_mst_topology_mgr *mgr; + struct drm_dp_mst_topology_state *mst_state; struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif -- 2.39.0
[PATCH AUTOSEL 5.15 11/12] drm/amd/display: Fix timing not changning when freesync video is enabled
From: Aurabindo Pillai
[ Upstream commit 4b069553246f993c4221e382d0d0ae34f5ba730e ]
[Why&How]
Switching between certain modes that are freesync video modes and those
are not freesync video modes result in timing not changing as seen by
the monitor due to incorrect timing being driven.
The issue is fixed by ensuring that when a non freesync video mode is
set, we reset the freesync status on the crtc.
Reviewed-by: Nicholas Kazlauskas
Acked-by: Alan Liu
Signed-off-by: Aurabindo Pillai
Tested-by: Daniel Wheeler
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 409739ee5ba0..ee238a16572e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -10140,6 +10140,13 @@ static int dm_update_crtc_state(struct
amdgpu_display_manager *dm,
if (!dm_old_crtc_state->stream)
goto skip_modeset;
+ /* Unset freesync video if it was active before */
+ if (dm_old_crtc_state->freesync_config.state ==
VRR_STATE_ACTIVE_FIXED) {
+ dm_new_crtc_state->freesync_config.state =
VRR_STATE_INACTIVE;
+ dm_new_crtc_state->freesync_config.fixed_refresh_in_uhz
= 0;
+ }
+
+ /* Now check if we should set freesync video mode */
if (amdgpu_freesync_vid_mode && dm_new_crtc_state->stream &&
is_timing_unchanged_for_freesync(new_crtc_state,
old_crtc_state)) {
--
2.39.0
[PATCH AUTOSEL 5.15 12/12] amdgpu: fix build on non-DCN platforms.
From: Dave Airlie [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] This fixes the build here locally on my 32-bit arm build. Signed-off-by: Dave Airlie Signed-off-by: Sasha Levin --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index ee238a16572e..0f0dd9b0d84a 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -10769,6 +10769,8 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, bool lock_and_validation_needed = false; struct dm_crtc_state *dm_old_crtc_state; #if defined(CONFIG_DRM_AMD_DC_DCN) + struct drm_dp_mst_topology_mgr *mgr; + struct drm_dp_mst_topology_state *mst_state; struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif -- 2.39.0
Re: [PATCH v5] drm/mediatek: Add support for AR30 and BA30
Hi Chun-Kuang,
Thanks for the review! Will try to have a new patch out later today.
Re MT8195 RDMA: Yes, the MT8195 RDMA has a 10 bit mode, but I left
this unimplemented because I have no means of testing it
unfortunately; ChromeOS does not use this hardware.
I also wanted to mention, I think this patch might conflict with the
in-flight ovl-adaptor patch. Is there a protocol for a situation like
this?
Regards,
Justin
On Mon, Jan 30, 2023 at 7:28 PM Chun-Kuang Hu wrote:
>
> Hi, Justin:
>
> Justin Green 於 2023年1月31日 週二 上午4:36寫道：
> >
> > Add support for AR30 and BA30 pixel formats to the Mediatek DRM driver.
> >
> > Tested using "modetest -P" on an MT8195.
> >
> > Signed-off-by: Justin Green
> > ---
> > v2:
> > * Rebase and resolve merge conflicts with the AFBC patch.
> > v3:
> > * Moved 10-bit support detection to mtk_disk_ovl.c
> > v4:
> > * Moved formats to mtk_disp_ovl.c and mtk_disp_rdma.c
> > v5:
> > * Minor style adjustments per checkpatch.pl
> >
> > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
> > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 75 +
> > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 27
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++
> > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 ++
> > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 28 +++-
> > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +-
> > 8 files changed, 146 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > index 33e61a136bbc..6ad22ce75b81 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
> > @@ -96,6 +96,8 @@ void mtk_ovl_register_vblank_cb(struct device *dev,
> > void mtk_ovl_unregister_vblank_cb(struct device *dev);
> > void mtk_ovl_enable_vblank(struct device *dev);
> > void mtk_ovl_disable_vblank(struct device *dev);
> > +const u32 *mtk_ovl_get_formats(struct device *dev);
> > +size_t mtk_ovl_get_num_formats(struct device *dev);
> >
> > void mtk_rdma_bypass_shadow(struct device *dev);
> > int mtk_rdma_clk_enable(struct device *dev);
> > @@ -122,4 +124,6 @@ void mtk_mdp_rdma_start(struct device *dev, struct
> > cmdq_pkt *cmdq_pkt);
> > void mtk_mdp_rdma_stop(struct device *dev, struct cmdq_pkt *cmdq_pkt);
> > void mtk_mdp_rdma_config(struct device *dev, struct mtk_mdp_rdma_cfg *cfg,
> > struct cmdq_pkt *cmdq_pkt);
> > +const u32 *mtk_rdma_get_formats(struct device *dev);
> > +size_t mtk_rdma_get_num_formats(struct device *dev);
> > #endif
> > diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > index 84daeaffab6a..1db70a77560f 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> > @@ -41,6 +41,7 @@
> > #define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
> > #define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
> > #define DISP_REG_OVL_ADDR_MT2701 0x0040
> > +#define DISP_REG_OVL_CLRFMT_EXT0x02D0
> > #define DISP_REG_OVL_ADDR_MT8173 0x0f40
> > #define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 *
> > (n))
> > #define DISP_REG_OVL_HDR_ADDR(ovl, n) ((ovl)->data->addr + 0x20 *
> > (n) + 0x04)
> > @@ -61,11 +62,45 @@
> > 0 : OVL_CON_CLRFMT_RGB)
> > #define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
> > OVL_CON_CLRFMT_RGB : 0)
> > +#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl) (depth << 4 * (ovl))
> > +#define OVL_CON_CLRFMT_8_BIT 0x00
> > +#define OVL_CON_CLRFMT_10_BIT 0x01
> > #defineOVL_CON_AEN BIT(8)
> > #defineOVL_CON_ALPHA 0xff
> > #defineOVL_CON_VIRT_FLIP BIT(9)
> > #defineOVL_CON_HORZ_FLIP BIT(10)
> >
> > +static const u32 formats_mt8173[] = {
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_RGB565,
> > + DRM_FORMAT_UYVY,
> > + DRM_FORMAT_YUYV,
> > +};
> > +
> > +static const u32 formats_mt8195[] = {
> > + DRM_FORMAT_XRGB,
> > + DRM_FORMAT_ARGB,
> > + DRM_FORMAT_ARGB2101010,
> > + DRM_FORMAT_BGRX,
> > + DRM_FORMAT_BGRA,
> > + DRM_FORMAT_BGRA1010102,
> > + DRM_FORMAT_ABGR,
> > + DRM_FORMAT_XBGR,
> > + DRM_FORMAT_RGB888,
> > + DRM_FORMAT_BGR888,
> > + DRM_FORMAT_RGB565,
> > +
[PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
Atm, drm_dp_remove_payload() uses the same payload state to both get the
vc_start_slot required for the payload removal DPCD message and to
deduct time_slots from vc_start_slot of all payloads after the one being
removed.
The above isn't always correct, as vc_start_slot must be the up-to-date
version contained in the new payload state, but time_slots must be the
one used when the payload was previously added, contained in the old
payload state. The new payload's time_slots can change vs. the old one
if the current atomic commit changes the corresponding mode.
This patch let's drivers pass the old and new payload states to
drm_dp_remove_payload(), but keeps these the same for now in all drivers
not to change the behavior. A follow-up i915 patch will pass in that
driver the correct old and new states to the function.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: Ben Skeggs
Cc: Karol Herbst
Cc: Harry Wentland
Cc: Alex Deucher
Cc: Wayne Lin
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
include/drm/display/drm_dp_mst_helper.h | 3 ++-
5 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
index a50319fc42b11..180d3893b68da 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
@@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
if (enable)
drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
else
- drm_dp_remove_payload(mst_mgr, mst_state, payload);
+ drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
/* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
* AUX message. The sequence is slot 1-63 allocated sequence for each
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 847c10aa2098c..1990ff5dc7ddd 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
* drm_dp_remove_payload() - Remove an MST payload
* @mgr: Manager to use.
* @mst_state: The MST atomic state
- * @payload: The payload to write
+ * @old_payload: The payload with its old state
+ * @new_payload: The payload to write
*
* Removes a payload from an MST topology if it was successfully assigned a
start slot. Also updates
* the starting time slots of all other payloads which would have been shifted
towards the start of
@@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
*/
void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_topology_state *mst_state,
- struct drm_dp_mst_atomic_payload *payload)
+ const struct drm_dp_mst_atomic_payload *old_payload,
+ struct drm_dp_mst_atomic_payload *new_payload)
{
struct drm_dp_mst_atomic_payload *pos;
bool send_remove = false;
/* We failed to make the payload, so nothing to do */
- if (payload->vc_start_slot == -1)
+ if (new_payload->vc_start_slot == -1)
return;
mutex_lock(&mgr->lock);
- send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
mgr->mst_primary);
+ send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
mgr->mst_primary);
mutex_unlock(&mgr->lock);
if (send_remove)
- drm_dp_destroy_payload_step1(mgr, mst_state, payload);
+ drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
else
drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
sending remove\n",
- payload->vcpi);
+ new_payload->vcpi);
list_for_each_entry(pos, &mst_state->payloads, next) {
- if (pos != payload && pos->vc_start_slot >
payload->vc_start_slot)
- pos->vc_start_slot -= payload->time_slots;
+ if (pos != new_payload && pos->vc_start_slot >
new_payload->vc_start_slot)
+ pos->vc_start_slot -= old_payload->time_slots;
}
- payload->vc_start_slot = -1;
+ new_payload->vc_start_slot = -1;
mgr->payload_count--;
- mgr->next_start_slot -= payload->time_slots;
+ mgr->next_start_slot -= old_payload->time_slots;
- if (payload->delete)
- drm_dp_mst_put_port_malloc(payload->port
[PATCH v2 03/17] drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()
Add a function to get the old MST topology state, required by a
follow-up i915 patch.
While at it clarify the code comment of
drm_atomic_get_new_mst_topology_state() and add _new prefix
to the new state pointer to remind about its difference from the old
state.
v2: Use old_/new_ prefixes for the state pointers. (Ville)
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: sta...@vger.kernel.org # 6.1
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 33 ---
include/drm/display/drm_dp_mst_helper.h | 3 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 1990ff5dc7ddd..38dab76ae69ea 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5364,28 +5364,53 @@ struct drm_dp_mst_topology_state
*drm_atomic_get_mst_topology_state(struct drm_a
}
EXPORT_SYMBOL(drm_atomic_get_mst_topology_state);
+/**
+ * drm_atomic_get_old_mst_topology_state: get old MST topology state in atomic
state, if any
+ * @state: global atomic state
+ * @mgr: MST topology manager, also the private object in this case
+ *
+ * This function wraps drm_atomic_get_old_private_obj_state() passing in the
MST atomic
+ * state vtable so that the private object state returned is that of a MST
+ * topology object.
+ *
+ * Returns:
+ *
+ * The old MST topology state, or NULL if there's no topology state for this
MST mgr
+ * in the global atomic state
+ */
+struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr)
+{
+ struct drm_private_state *old_priv_state =
+ drm_atomic_get_old_private_obj_state(state, &mgr->base);
+
+ return old_priv_state ? to_dp_mst_topology_state(old_priv_state) : NULL;
+}
+EXPORT_SYMBOL(drm_atomic_get_old_mst_topology_state);
+
/**
* drm_atomic_get_new_mst_topology_state: get new MST topology state in atomic
state, if any
* @state: global atomic state
* @mgr: MST topology manager, also the private object in this case
*
- * This function wraps drm_atomic_get_priv_obj_state() passing in the MST
atomic
+ * This function wraps drm_atomic_get_new_private_obj_state() passing in the
MST atomic
* state vtable so that the private object state returned is that of a MST
* topology object.
*
* Returns:
*
- * The MST topology state, or NULL if there's no topology state for this MST
mgr
+ * The new MST topology state, or NULL if there's no topology state for this
MST mgr
* in the global atomic state
*/
struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr)
{
- struct drm_private_state *priv_state =
+ struct drm_private_state *new_priv_state =
drm_atomic_get_new_private_obj_state(state, &mgr->base);
- return priv_state ? to_dp_mst_topology_state(priv_state) : NULL;
+ return new_priv_state ? to_dp_mst_topology_state(new_priv_state) : NULL;
}
EXPORT_SYMBOL(drm_atomic_get_new_mst_topology_state);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index f5eb9aa152b14..32c764fb9cb56 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -868,6 +868,9 @@ struct drm_dp_mst_topology_state *
drm_atomic_get_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_topology_state *
+drm_atomic_get_old_mst_topology_state(struct drm_atomic_state *state,
+ struct drm_dp_mst_topology_mgr *mgr);
+struct drm_dp_mst_topology_state *
drm_atomic_get_new_mst_topology_state(struct drm_atomic_state *state,
struct drm_dp_mst_topology_mgr *mgr);
struct drm_dp_mst_atomic_payload *
--
2.37.1
[PATCH v2 05/17] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()
Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology().
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..8787df19f428b 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4772,7 +4772,7 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
list_for_each_entry(payload, &state->payloads, next) {
char name[14];
- if (payload->vcpi != i || payload->delete)
+ if (payload->vcpi != i + 1 || payload->delete)
continue;
fetch_monitor_name(mgr, payload->port, name,
sizeof(name));
--
2.37.1
[PATCH v2 12/17] drm/display/dp_mst: Add helpers to query payload allocation properties
Add helper functions to query the virtual channel and time slots for a
payload and the current payload count and total allocated time slots in
an MST topology. These are needed by a follow-up i915 patch verifying
the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 36 +++
include/drm/display/drm_dp_mst_helper.h | 21 +++
2 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index f2081f3fad0da..47605f67578ad 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3448,6 +3448,42 @@ bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state
}
EXPORT_SYMBOL(drm_dp_mst_has_payload_alloc_errors);
+/**
+ * drm_dp_mst_payload_vchannel - Return the DP virtual channel for a payload
+ * @mst_state: The MST atomic state containing @payload
+ * @payload: The payload to get the virtual channel for
+ *
+ * Return the DP virtual channel for @payload. The virtual channel is a
+ * contiguous range of MST Transmission Units on the DP main lanes between
+ * the source DPTX and the first downstream MST hub DPRX. Accordingly the
+ * channel is determined by the payload's position on the payload list
+ * ordered by VC start slot.
+ *
+ * Returns the 0-based virtual channel of @payload if it's in @mst_state with
+ * its time slots being allocated, or -1 otherwise.
+ */
+int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
+ const struct drm_dp_mst_atomic_payload *payload)
+{
+ struct drm_dp_mst_atomic_payload *pos;
+ int vc = 0;
+ bool found = false;
+
+ list_for_each_entry(pos, &mst_state->payloads, next) {
+ if (pos->vc_start_slot == -1)
+ continue;
+
+ if (pos == payload)
+ found = true;
+
+ if (pos->vc_start_slot < payload->vc_start_slot)
+ vc++;
+ }
+
+ return found ? vc : -1;
+}
+EXPORT_SYMBOL(drm_dp_mst_payload_vchannel);
+
static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 53b251b264e89..bb7c595096fed 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -846,6 +846,27 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
+int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
+ const struct drm_dp_mst_atomic_payload
*payload);
+
+static inline int
+drm_dp_mst_payload_count(const struct drm_dp_mst_topology_state *mst_state)
+{
+ return mst_state->mgr->payload_count;
+}
+
+static inline int
+drm_dp_mst_allocated_time_slots(const struct drm_dp_mst_topology_state
*mst_state)
+{
+ return drm_dp_mst_payload_count(mst_state) ?
+ mst_state->mgr->next_start_slot - mst_state->start_slot : 0;
+}
+
+static inline int
+drm_dp_mst_payload_time_slots(const struct drm_dp_mst_atomic_payload *payload)
+{
+ return payload->time_slots;
+}
int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
--
2.37.1
[PATCH v2 09/17] drm/display/dp_mst: Add a helper to verify the MST payload state
Add a function drivers can use to verify the MST payload state tracking
and compare this to the sink's payload table.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 169 ++
include/drm/display/drm_dp.h | 3 +
include/drm/display/drm_dp_mst_helper.h | 3 +
3 files changed, 175 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 0c04b96ae614c..e57dd16955d52 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4847,6 +4847,175 @@ void drm_dp_mst_dump_topology(struct seq_file *m,
}
EXPORT_SYMBOL(drm_dp_mst_dump_topology);
+static bool verify_mst_payload_state(struct drm_dp_mst_topology_state
*mst_state)
+{
+ struct drm_dp_mst_topology_mgr *mgr = mst_state->mgr;
+ struct drm_dp_mst_atomic_payload *payload;
+ int payload_count = 0;
+ u64 time_slot_mask = 0;
+ u32 vcpi_mask = 0;
+ int last_set;
+
+ if (BITS_PER_TYPE(time_slot_mask) < mst_state->total_avail_slots)
+ return false;
+
+ list_for_each_entry(payload, &mst_state->payloads, next) {
+ u64 mask;
+
+ if (payload->vc_start_slot == -1)
+ continue;
+
+ if (!payload->time_slots)
+ return false;
+
+ if (payload->vc_start_slot < mst_state->start_slot)
+ return false;
+
+ if (payload->vc_start_slot + payload->time_slots -
mst_state->start_slot >
+ mst_state->total_avail_slots)
+ return false;
+
+ mask = GENMASK_ULL(payload->vc_start_slot + payload->time_slots
- 1,
+ payload->vc_start_slot);
+
+ if (time_slot_mask & mask)
+ return false;
+
+ time_slot_mask |= mask;
+
+ if (payload->vcpi < 1 ||
+ payload->vcpi & ~DP_PAYLOAD_ID_MASK ||
+ payload->vcpi > BITS_PER_TYPE(vcpi_mask))
+ return false;
+ if (BIT(payload->vcpi - 1) & vcpi_mask)
+ return false;
+ vcpi_mask |= BIT(payload->vcpi - 1);
+
+ payload_count++;
+ }
+
+ if (payload_count != mgr->payload_count)
+ return false;
+
+ last_set = fls64(time_slot_mask);
+
+ if (last_set &&
+ GENMASK_ULL(last_set - 1, mst_state->start_slot) != time_slot_mask)
+ return false;
+
+ if (max(mst_state->start_slot, mgr->next_start_slot) !=
+ max_t(int, mst_state->start_slot, last_set))
+ return false;
+
+ return true;
+}
+
+static int get_payload_table_vcpi(const u8 *table, int slot)
+{
+ if (slot == 0)
+ return FIELD_GET(DP_PAYLOAD_ID_SLOT0_5_0_MASK, table[0]) |
+ (FIELD_GET(DP_PAYLOAD_ID_SLOT0_6, table[1]) << 6);
+ else
+ return FIELD_GET(DP_PAYLOAD_ID_MASK, table[slot]);
+}
+
+static bool verify_mst_payload_table(struct drm_dp_mst_topology_state
*mst_state,
+const u8 *payload_table)
+{
+ struct drm_dp_mst_topology_mgr *mgr = mst_state->mgr;
+ struct drm_dp_mst_atomic_payload *payload;
+ int i;
+
+ list_for_each_entry(payload, &mst_state->payloads, next) {
+ if (payload->vc_start_slot == -1)
+ continue;
+
+ if (payload->vc_start_slot + payload->time_slots >
DP_PAYLOAD_TABLE_SIZE)
+ return false;
+
+ for (i = 0; i < payload->time_slots; i++)
+ if (get_payload_table_vcpi(payload_table,
+ payload->vc_start_slot + i)
!= payload->vcpi)
+ return false;
+ }
+
+ for (i = max(mgr->next_start_slot, mst_state->start_slot);
+i < DP_PAYLOAD_TABLE_SIZE;
+i++) {
+ if (get_payload_table_vcpi(payload_table, i) != 0)
+ return false;
+ }
+
+ return true;
+}
+
+static void print_mst_payload_state(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_topology_state *mst_state,
+ const u8 *payload_table)
+{
+ struct drm_dp_mst_atomic_payload *payload;
+ int i = 0;
+
+ drm_dbg(mgr->dev,
+ "Payload state: start_slot %d total_avail_slots %d
next_start_slot %d payload_count %d\n",
+ mst_state->start_slot, mst_state->total_avail_slots,
+ mgr->next_start_slot, mgr->payload_count);
+
+ list_for_each_entry(payload, &mst_state->payloads, next) {
+ drm_dbg(mgr->dev,
+
[PATCH v2 13/17] drm/display/dp_mst: Export the DP_PAYLOAD_TABLE_SIZE definition
In a follow-up workaround for a payload allocation problem the driver
uses DP_PAYLOAD_TABLE_SIZE to determine when the workaround is needed,
so export the definition.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 --
include/drm/display/drm_dp.h | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 47605f67578ad..d0e929df7d088 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -4771,8 +4771,6 @@ static void drm_dp_mst_dump_mstb(struct seq_file *m,
}
}
-#define DP_PAYLOAD_TABLE_SIZE 64
-
static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr *mgr,
char *buf)
{
diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
index bcc5183188a68..8f18f66ff5bc3 100644
--- a/include/drm/display/drm_dp.h
+++ b/include/drm/display/drm_dp.h
@@ -932,6 +932,8 @@
# define DP_PAYLOAD_ID_SLOT0_6 (1 << 7)
# define DP_PAYLOAD_ID_MASK0x7f
+#define DP_PAYLOAD_TABLE_SIZE 64
+
/* Source Device-specific */
#define DP_SOURCE_OUI 0x300
--
2.37.1
[PATCH v2 15/17] drm/dp: Add a quirk for a DELL P2715Q MST payload allocation problem
The DELL P2715Q monitor's MST hub has a payload allocation problem,
where the VCPI used to reserve the last two time slots (at position
0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for
later payload configurations. To work around the problem in a follow-up
patch the driver needs to reset the payload table after all payloads
have been freed; add a quirk the driver can use to detect the monitor
and apply the WA if needed.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 ++
include/drm/display/drm_dp_helper.h | 8
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index 16565a0a5da6d..e2cf4b4fe11ea 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -2244,6 +2244,8 @@ static const struct dpcd_quirk dpcd_quirk_list[] = {
{ OUI(0x90, 0xCC, 0x24), DEVICE_ID_ANY, true,
BIT(DP_DPCD_QUIRK_DSC_WITHOUT_VIRTUAL_DPCD) },
/* Apple MacBookPro 2017 15 inch eDP Retina panel reports too low
DP_MAX_LINK_RATE */
{ OUI(0x00, 0x10, 0xfa), DEVICE_ID(101, 68, 21, 101, 98, 97), false,
BIT(DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS) },
+ /* DELL P2715Q MST payload table must be reset after the two last
payload slots get allocated. */
+ { OUI(0x00, 0xe0, 0x4c), DEVICE_ID('D', 'p', '1', '.', '2', 0), true,
BIT(DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA) },
};
#undef OUI
diff --git a/include/drm/display/drm_dp_helper.h
b/include/drm/display/drm_dp_helper.h
index ab55453f2d2cd..fcd445921ec9d 100644
--- a/include/drm/display/drm_dp_helper.h
+++ b/include/drm/display/drm_dp_helper.h
@@ -620,6 +620,14 @@ enum drm_dp_quirk {
* the DP_MAX_LINK_RATE register reporting a lower max multiplier.
*/
DP_DPCD_QUIRK_CAN_DO_MAX_LINK_RATE_3_24_GBPS,
+ /**
+* @DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA:
+*
+* An bug in the MST branch device's payload allocation logic requires
+* the payload table to be reset after its last two payload slots get
+* allocated.
+*/
+ DP_DPCD_QUIRK_MST_PAYLOAD_TABLE_RESET_WA,
};
/**
--
2.37.1
[PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for payload allocation errors
Add a way for drivers to query if allocating time slots for any payloads
in a given MST topology failed. This is needed by a follow-up i915 patch
verifying the SW vs. HW state of the MST topology.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 35 ---
include/drm/display/drm_dp_mst_helper.h | 3 ++
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index e57dd16955d52..f2081f3fad0da 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3306,15 +3306,14 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_atomic_payload *payload)
{
struct drm_dp_mst_port *port;
- int ret;
+ int ret = 0;
port = drm_dp_mst_topology_get_port_validated(mgr, payload->port);
if (!port) {
drm_dbg_kms(mgr->dev,
"VCPI %d for port %p not in topology, not creating
a payload\n",
payload->vcpi, payload->port);
- payload->vc_start_slot = -1;
- return 0;
+ goto alloc_fail;
}
if (mgr->payload_count == 0)
@@ -3327,14 +3326,21 @@ int drm_dp_add_payload_part1(struct
drm_dp_mst_topology_mgr *mgr,
if (ret < 0) {
drm_warn(mgr->dev, "Failed to create MST payload for port %p:
%d\n",
payload->port, ret);
- payload->vc_start_slot = -1;
- return ret;
+ goto alloc_fail;
}
+ payload->alloc_failed = false;
+
mgr->payload_count++;
mgr->next_start_slot += payload->time_slots;
return 0;
+
+alloc_fail:
+ payload->vc_start_slot = -1;
+ payload->alloc_failed = true;
+
+ return ret;
}
EXPORT_SYMBOL(drm_dp_add_payload_part1);
@@ -3423,6 +3429,25 @@ int drm_dp_add_payload_part2(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_add_payload_part2);
+/**
+ * drm_dp_mst_has_payload_alloc_errors - Query for payload allocation errors
+ * @mst_state: The MST atomic state
+ *
+ * Returns %true if the allocation of any of the payloads in @mst_state
+ * failed, %false otherwise.
+ */
+bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state)
+{
+ struct drm_dp_mst_atomic_payload *pos;
+
+ list_for_each_entry(pos, &mst_state->payloads, next)
+ if (pos->alloc_failed)
+ return true;
+
+ return false;
+}
+EXPORT_SYMBOL(drm_dp_mst_has_payload_alloc_errors);
+
static int drm_dp_send_dpcd_read(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port,
int offset, int size, u8 *bytes)
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index 44c6710ebf315..53b251b264e89 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -568,6 +568,8 @@ struct drm_dp_mst_atomic_payload {
bool delete : 1;
/** @dsc_enabled: Whether or not this payload has DSC enabled */
bool dsc_enabled : 1;
+ /** @alloc_failed: Whether or not allocating this payload failed */
+ bool alloc_failed : 1;
/** @next: The list node for this payload */
struct list_head next;
@@ -843,6 +845,7 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_topology_state *mst_state,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
+bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr);
--
2.37.1
[PATCH v2 14/17] drm/display/dp_mst: Factor out a helper to reset the payload table
A follow-up patch adds a workaround for a payload allocation problem in
a DELL monitor. For this the driver needs to reset the payload table in
the monitor's MST hub, factor out a helper to do this.
While at it use DP_PAYLOAD_TABLE_SIZE in the reset command, instead of
open coding it.
Cc: Lyude Paul
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/display/drm_dp_mst_topology.c | 8 +++-
include/drm/display/drm_dp_mst_helper.h | 1 +
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index d0e929df7d088..eb170389cf9bc 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3429,6 +3429,12 @@ int drm_dp_add_payload_part2(struct
drm_dp_mst_topology_mgr *mgr,
}
EXPORT_SYMBOL(drm_dp_add_payload_part2);
+int drm_dp_mst_reset_payload_table(struct drm_dp_mst_topology_mgr *mgr)
+{
+ return drm_dp_dpcd_write_payload(mgr, 0, 0, DP_PAYLOAD_TABLE_SIZE - 1);
+}
+EXPORT_SYMBOL(drm_dp_mst_reset_payload_table);
+
/**
* drm_dp_mst_has_payload_alloc_errors - Query for payload allocation errors
* @mst_state: The MST atomic state
@@ -3699,7 +3705,7 @@ int drm_dp_mst_topology_mgr_set_mst(struct
drm_dp_mst_topology_mgr *mgr, bool ms
goto out_unlock;
/* Write reset payload */
- drm_dp_dpcd_write_payload(mgr, 0, 0, 0x3f);
+ drm_dp_mst_reset_payload_table(mgr);
queue_work(system_long_wq, &mgr->work);
diff --git a/include/drm/display/drm_dp_mst_helper.h
b/include/drm/display/drm_dp_mst_helper.h
index bb7c595096fed..2d15399df2950 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -845,6 +845,7 @@ void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr
*mgr,
struct drm_dp_mst_topology_state *mst_state,
const struct drm_dp_mst_atomic_payload *old_payload,
struct drm_dp_mst_atomic_payload *new_payload);
+int drm_dp_mst_reset_payload_table(struct drm_dp_mst_topology_mgr *mgr);
bool drm_dp_mst_has_payload_alloc_errors(const struct
drm_dp_mst_topology_state *mst_state);
int drm_dp_mst_payload_vchannel(const struct drm_dp_mst_topology_state
*mst_state,
const struct drm_dp_mst_atomic_payload
*payload);
--
2.37.1
Re: [PATCH v2 1/8] drm/vmwgfx: Use the common gem mmap instead of the custom code
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Before vmwgfx supported gem it needed to implement the entire mmap logic
explicitly. With GEM support that's not needed and the generic code
can be used by simply setting the vm_ops to vmwgfx specific ones on the
gem object itself.
Removes a lot of code from vmwgfx without any functional difference.
Signed-off-by: Zack Rusin
Reviewed-by: Thomas Zimmermann
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 6 --
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 8 ++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 ---
5 files changed, 10 insertions(+), 118 deletions(-)
delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 2a644f035597..e94479d9cd5b 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o vmwgfx_drv.o \
vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_ttm_buffer.o \
- vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
+ vmwgfx_cmd.o vmwgfx_irq.o vmwgfx_ldu.o \
vmwgfx_overlay.o vmwgfx_gmrid_manager.o vmwgfx_fence.o \
vmwgfx_bo.o vmwgfx_scrn.o vmwgfx_context.o \
vmwgfx_surface.o vmwgfx_prime.o vmwgfx_mob.o vmwgfx_shader.o \
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index bd02cb0e6837..e0c2e3748015 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1566,7 +1566,7 @@ static const struct file_operations vmwgfx_driver_fops = {
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = vmw_unlocked_ioctl,
- .mmap = vmw_mmap,
+ .mmap = drm_gem_mmap,
.poll = drm_poll,
.read = drm_read,
#if defined(CONFIG_COMPAT)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5acbf5849b27..4dfa5044a9e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -1053,12 +1053,6 @@ vmw_is_cursor_bypass3_enabled(const struct vmw_private
*dev_priv)
return (vmw_fifo_caps(dev_priv) & SVGA_FIFO_CAP_CURSOR_BYPASS_3) != 0;
}
-/**
- * TTM glue - vmwgfx_ttm_glue.c
- */
-
-extern int vmw_mmap(struct file *filp, struct vm_area_struct *vma);
-
/**
* TTM buffer object driver - vmwgfx_ttm_buffer.c
*/
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
index ce609e7d758f..ba4ddd9f7a7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
@@ -103,6 +103,13 @@ static struct sg_table *vmw_gem_object_get_sg_table(struct
drm_gem_object *obj)
return drm_prime_pages_to_sg(obj->dev, vmw_tt->dma_ttm.pages,
vmw_tt->dma_ttm.num_pages);
}
+static const struct vm_operations_struct vmw_vm_ops = {
+ .pfn_mkwrite = vmw_bo_vm_mkwrite,
+ .page_mkwrite = vmw_bo_vm_mkwrite,
+ .fault = vmw_bo_vm_fault,
+ .open = ttm_bo_vm_open,
+ .close = ttm_bo_vm_close,
+};
static const struct drm_gem_object_funcs vmw_gem_object_funcs = {
.free = vmw_gem_object_free,
@@ -115,6 +122,7 @@ static const struct drm_gem_object_funcs
vmw_gem_object_funcs = {
.vmap = drm_gem_ttm_vmap,
.vunmap = drm_gem_ttm_vunmap,
.mmap = drm_gem_ttm_mmap,
+ .vm_ops = &vmw_vm_ops,
};
/**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
deleted file mode 100644
index 265f7c48d856..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c
+++ /dev/null
@@ -1,110 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0 OR MIT
-/**
- *
- * Copyright 2009-2011 VMware, Inc., Palo Alto, CA., USA
- *
- * 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, sub license, 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
RE: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN platforms.
[AMD Official Use Only - General] > -Original Message- > From: Sasha Levin > Sent: Tuesday, January 31, 2023 10:00 AM > To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org > Cc: Dave Airlie ; Sasha Levin ; > Wentland, Harry ; Li, Sun peng (Leo) > ; Siqueira, Rodrigo ; > Deucher, Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com; dan...@ffwll.ch; Li, Roman ; > Wang, Chao-kai (Stylon) ; Pillai, Aurabindo > ; Zuo, Jerry ; amd- > g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org > Subject: [PATCH AUTOSEL 6.1 20/20] amdgpu: fix build on non-DCN > platforms. > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1.x and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 15b408e3a705..d756a606b5e2 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -9411,6 +9411,8 @@ static int amdgpu_dm_atomic_check(struct > drm_device *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state, *dm_new_crtc_state; #if > defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; #endif > > -- > 2.39.0
Re: [PATCH v2 2/6] drm/debugfs: Make drm_device use the struct drm_debugfs_files
Hi Maíra,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on drm-intel/for-linux-next drm-tip/drm-tip
next-20230131]
[cannot apply to drm-intel/for-linux-next-fixes linus/master v6.2-rc6]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Ma-ra-Canal/drm-debugfs-Introduce-wrapper-for-debugfs-list/20230130-203549
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230130123008.287141-3-mcanal%40igalia.com
patch subject: [PATCH v2 2/6] drm/debugfs: Make drm_device use the struct
drm_debugfs_files
config: arc-randconfig-r043-20230129
(https://download.01.org/0day-ci/archive/20230201/202302010102.zlw3vtyi-...@intel.com/config)
compiler: arceb-elf-gcc (GCC) 12.1.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https://github.com/intel-lab-lkp/linux/commit/776660a442d9112d8fbc06b0b8b0b77852b18fca
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ma-ra-Canal/drm-debugfs-Introduce-wrapper-for-debugfs-list/20230130-203549
git checkout 776660a442d9112d8fbc06b0b8b0b77852b18fca
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1
O=build_dir ARCH=arc SHELL=/bin/bash drivers/gpu/drm/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/gpu/drm/drm_drv.c: In function 'drm_dev_init_release':
>> drivers/gpu/drm/drm_drv.c:602:9: error: implicit declaration of function
>> 'drm_debugfs_files_destroy'; did you mean 'drm_debugfs_list_destroy'?
>> [-Werror=implicit-function-declaration]
602 | drm_debugfs_files_destroy(dev->debugfs_files);
| ^
| drm_debugfs_list_destroy
drivers/gpu/drm/drm_drv.c: In function 'drm_dev_init':
>> drivers/gpu/drm/drm_drv.c:650:30: error: implicit declaration of function
>> 'drm_debugfs_files_init'; did you mean 'drm_debugfs_list_init'?
>> [-Werror=implicit-function-declaration]
650 | dev->debugfs_files = drm_debugfs_files_init();
| ^~
| drm_debugfs_list_init
>> drivers/gpu/drm/drm_drv.c:650:28: warning: assignment to 'struct
>> drm_debugfs_files *' from 'int' makes pointer from integer without a cast
>> [-Wint-conversion]
650 | dev->debugfs_files = drm_debugfs_files_init();
|^
cc1: some warnings being treated as errors
vim +602 drivers/gpu/drm/drm_drv.c
562
563 /**
564 * DOC: component helper usage recommendations
565 *
566 * DRM drivers that drive hardware where a logical device consists of a
pile of
567 * independent hardware blocks are recommended to use the
:ref:`component helper
568 * library`. For consistency and better options for code
reuse the
569 * following guidelines apply:
570 *
571 * - The entire device initialization procedure should be run from the
572 *&component_master_ops.master_bind callback, starting with
573 *devm_drm_dev_alloc(), then binding all components with
574 *component_bind_all() and finishing with drm_dev_register().
575 *
576 * - The opaque pointer passed to all components through
component_bind_all()
577 *should point at &struct drm_device of the device instance, not
some driver
578 *specific private structure.
579 *
580 * - The component helper fills the niche where further
standardization of
581 *interfaces is not practical. When there already is, or will be, a
582 *standardized interface like &drm_bridge or &drm_panel, providing
its own
583 *functions to find such components at driver load time, like
584 *drm_of_find_panel_or_bridge(), then the component helper should
not be
585 *used.
586 */
587
588 static void drm_dev_init_release(struct drm_device *dev, void *res)
589 {
590 drm_legacy_ctxbitmap_cleanup(dev);
591 drm_legacy_remove_map_hash(dev);
592
Re: [PATCH] drm/amdgpu: Fix a typo ("boradcast")
Applied. Thanks! On Sun, Jan 29, 2023 at 10:18 AM Jonathan Neuschäfer wrote: > > Spell it as "broadcast". > > Signed-off-by: Jonathan Neuschäfer > --- > drivers/gpu/drm/amd/amdgpu/df_v1_7.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > index b991609f46c10..5dfab8021 100644 > --- a/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > +++ b/drivers/gpu/drm/amd/amdgpu/df_v1_7.c > @@ -94,7 +94,7 @@ static void df_v1_7_update_medium_grain_clock_gating(struct > amdgpu_device *adev, > WREG32_SOC15(DF, 0, mmDF_PIE_AON0_DfGlobalClkGater, tmp); > } > > - /* Exit boradcast mode */ > + /* Exit broadcast mode */ > adev->df.funcs->enable_broadcast_mode(adev, false); > } > > -- > 2.39.0 >
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915
+Suraj who is also working on HDCP related code that even can conflict
wit this.
On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> From: Sean Paul
First of all, Sean, please accept my public apologies here. I just noticed
now that you had pinged me 9 *months* ago!
I noticed while taking a look to the history to refresh my mind around
this series.
>
> Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> helpers, use it in the i915 driver.
>
> The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> however there are a few helper hooks which are connector-specific and
> need to be partially or fully implemented in the intel_dp_hdcp.c or
> intel_hdmi.c.
so far so good! we need to do this soon.
>
> We'll leave most of the HDCP 2.x code alone since we don't have another
> implementation of HDCP 2.x to use as reference for what should and
> should not live in the drm helpers. The helper will call the overly
> general enable/disable/is_capable HDCP 2.x callbacks and leave the
> interesting stuff for the driver. Once we have another HDCP 2.x
> implementation, we should do a similar migration.
I believe this part is the part that I start to get lost when
trying to review it.
Mark told me in irc that it is really hard to split this patch,
but do we really need to have the hdcp 1.x changes along with the
2.x? I start to get lost in the review when I see the changes around
the hdcp2_capable...
So, it would be really really good if we can split this patch.
>
> Acked-by: Jani Nikula
> Signed-off-by: Sean Paul
> Signed-off-by: Mark Yacoub
Cc: Suraj Kandpal
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-8-s...@poorly.run
> #v1
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-8-s...@poorly.run
> #v2
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-8-s...@poorly.run
> #v3
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-8-s...@poorly.run
> #v4
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-8-s...@poorly.run
> #v5
>
> Changes in v2:
> -Fix mst helper function pointer reported by 0-day
> Changes in v3:
> -Add forward declaration for drm_atomic_state in intel_hdcp.h identified
> by 0-day
> Changes in v4:
> -None
> Changes in v5:
> -None
> Changes in v6:
> -Rebased.
>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
> .../drm/i915/display/intel_display_debugfs.c | 6 +-
> .../drm/i915/display/intel_display_types.h| 60 +-
> drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 348 +++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
> drivers/gpu/drm/i915/display/intel_hdcp.c | 952 +++---
> drivers/gpu/drm/i915/display/intel_hdcp.h | 31 +-
> drivers/gpu/drm/i915/display/intel_hdmi.c | 270 ++---
> 8 files changed, 445 insertions(+), 1270 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 69ecf2a3d6c6..a4397f066a3e 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -28,6 +28,7 @@
> #include
>
> #include
> +#include
> #include
>
> #include "i915_drv.h"
> @@ -2909,6 +2910,10 @@ static void intel_enable_ddi(struct intel_atomic_state
> *state,
>const struct intel_crtc_state *crtc_state,
>const struct drm_connector_state *conn_state)
> {
> + struct intel_connector *connector =
> + to_intel_connector(conn_state->connector);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> +
> drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
>
> if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> @@ -2925,12 +2930,10 @@ static void intel_enable_ddi(struct
> intel_atomic_state *state,
> else
> intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
>
> - /* Enable hdcp if it's desired */
> - if (conn_state->content_protection ==
> - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> - crtc_state,
> - (u8)conn_state->hdcp_content_type);
> + if (connector->hdcp_helper_data)
> + drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
> + &state->base,
> + &dig_port->hdcp_mutex);
> }
>
> static void intel_disable_ddi_dp(struct intel_atomic_state *state,
> @@ -2976,7 +2979,14 @@ static void intel_disable_ddi(struct
> intel_atomic_state *state,
> const struct intel_crtc_state *old_crtc_state,
> const struct drm_connector_state *old_conn_state)
> {
> - intel_hdcp_disable(to_intel
Re: [PATCH] drm/amdgpu/display: remove duplicate include header in files
Applied. Thanks! Alex On Fri, Jan 27, 2023 at 8:39 PM wrote: > > From: ye xingchen > > opp.h is included more than once. > > Signed-off-by: ye xingchen > --- > drivers/gpu/drm/amd/display/dc/core/dc_link.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > index 6475664baa8a..1a2ab934b4bd 100644 > --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c > +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c > @@ -46,7 +46,6 @@ > #include "dpcd_defs.h" > #include "dmcu.h" > #include "dsc.h" > -#include "opp.h" > #include "hw/clk_mgr.h" > #include "dce/dmub_psr.h" > #include "dmub/dmub_srv.h" > -- > 2.25.1
Re: [PATCH] drm/amd/display: reduce else-if to else in dcn10_blank_pixel_data()
Applied. Thanks!
On Thu, Jan 26, 2023 at 8:38 PM Tom Rix wrote:
>
> checkpatch reports
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 2895. [multiCondition]
> } else if (blank) {
> ^
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2895:6: note: first
> condition
> if (!blank) {
> ^
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:2902:13: note: else
> if condition is opposite to first condition
> } else if (blank) {
>
> It is not necessary to explicitly the check != condition, an else is simplier.
>
> Fixes: aa5a57773042 ("drm/amd/display: Vari-bright looks disabled near end of
> MM14")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> index bb155734ac93..f735ae5e045f 100644
> --- a/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> +++ b/drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c
> @@ -2899,7 +2899,7 @@ void dcn10_blank_pixel_data(
> dc->hwss.set_pipe(pipe_ctx);
>
> stream_res->abm->funcs->set_abm_level(stream_res->abm, stream->abm_level);
> }
> - } else if (blank) {
> + } else {
> dc->hwss.set_abm_immediate_disable(pipe_ctx);
> if (stream_res->tg->funcs->set_blank) {
> stream_res->tg->funcs->wait_for_state(stream_res->tg,
> CRTC_STATE_VBLANK);
> --
> 2.26.3
>
[linux-next:master] BUILD REGRESSION 80bd9028fecadae4e8e3a278cd32d74badc2a6e0
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 80bd9028fecadae4e8e3a278cd32d74badc2a6e0 Add linux-next specific files for 20230131 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301301801.y5o08tqx-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301302110.metnwkbd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301310227.semvyeta-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301310939.tagcoezb-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/riscv/uabi.rst:24: WARNING: Enumerated list ends without a blank line; unexpected unindent. ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! arch/arm64/kvm/arm.c:2206: warning: expecting prototype for Initialize Hyp(). Prototype was for kvm_arm_init() instead drivers/clk/qcom/gcc-sa8775p.c:313:32: warning: unused variable 'gcc_parent_map_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:318:37: warning: unused variable 'gcc_parent_data_10' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:333:32: warning: unused variable 'gcc_parent_map_12' [-Wunused-const-variable] drivers/clk/qcom/gcc-sa8775p.c:338:37: warning: unused variable 'gcc_parent_data_12' [-Wunused-const-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:148:6: warning: no previous prototype for 'link_dp_trace_set_edp_power_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:158:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweron_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/accessories/link_dp_trace.c:163:10: warning: no previous prototype for 'link_dp_trace_get_edp_poweroff_timestamp' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1295:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:279:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1585:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] drivers/gpu/host1x/dev.c:520:6: warning: variable 'syncpt_irq' is uninitialized when used here [-Wuninitialized] ftrace-ops.c:(.init.text+0x2cb): undefined reference to `__udivdi3' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/nvmem/imx-ocotp.c:599:21: sparse: sparse: symbol 'imx_ocotp_layout' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:106:40: sparse: sparse: symbol 'tsens_9607_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:26:40: sparse: sparse: symbol 'tsens_8916_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:42:40: sparse: sparse: symbol 'tsens_8939_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:62:40: sparse: sparse: symbol 'tsens_8974_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v0_1.c:84:40: sparse: sparse: symbol 'tsens_8974_backup_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:24:40: sparse: sparse: symbol 'tsens_qcs404_nvmem' was not declared. Should it be static? drivers/thermal/qcom/tsens-v1.c:45:40: sparse: sparse: symbol 'tsens_8976_nvmem' was not declared. Should it be static? Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweroff_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_get_edp_poweron_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-accessories-link_dp_trace.c:warning:no-previous-prototype-for-link_dp_trace_set_edp_power_timestamp | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:vari
Re: [PATCH] drm/amd/display: reduce else-if to else in dcn32_calculate_dlg_params()
Applied. Thanks!
Alex
On Thu, Jan 26, 2023 at 3:50 PM Tom Rix wrote:
>
> cppcheck reports
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: style:
> Expression is always true because 'else if' condition is opposite to
> previous condition at line 1396. [multiCondition]
>} else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
>^
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1396:69: note: first
> condition
>if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type !=
> SUBVP_PHANTOM) {
> ^
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c:1403:76: note: else if
> condition is opposite to first condition
>} else if (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
>
> It is not necessary to explicitly the check != condition, an else is simplier.
>
> Fixes: 238debcaebe4 ("drm/amd/display: Use DML for MALL SS and Subvp
> allocation calculations")
> Signed-off-by: Tom Rix
> ---
> drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> b/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> index 0dc1a03999b6..c96cbd88e20d 100644
> --- a/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> +++ b/drivers/gpu/drm/amd/display/dc/dml/dcn32/dcn32_fpu.c
> @@ -1400,7 +1400,7 @@ static void dcn32_calculate_dlg_params(struct dc *dc,
> struct dc_state *context,
> /* SS PSR On: all active surfaces
> part of streams not supporting PSR stored in MALL */
>
> context->bw_ctx.bw.dcn.mall_ss_psr_active_size_bytes +=
> context->res_ctx.pipe_ctx[i].surface_size_in_mall_bytes;
> }
> - } else if
> (context->res_ctx.pipe_ctx[i].stream->mall_stream_config.type ==
> SUBVP_PHANTOM) {
> + } else {
> /* SUBVP: phantom surfaces only stored in
> MALL */
> context->bw_ctx.bw.dcn.mall_subvp_size_bytes
> += context->res_ctx.pipe_ctx[i].surface_size_in_mall_bytes;
> }
> --
> 2.26.3
>
Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915
+Suraj
On Tue, Jan 31, 2023 at 12:16:44PM -0500, Rodrigo Vivi wrote:
>
> +Suraj who is also working on HDCP related code that even can conflict
> wit this.
>
> On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote:
> > From: Sean Paul
>
> First of all, Sean, please accept my public apologies here. I just noticed
> now that you had pinged me 9 *months* ago!
> I noticed while taking a look to the history to refresh my mind around
> this series.
>
> >
> > Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> > helpers, use it in the i915 driver.
> >
> > The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> > however there are a few helper hooks which are connector-specific and
> > need to be partially or fully implemented in the intel_dp_hdcp.c or
> > intel_hdmi.c.
>
> so far so good! we need to do this soon.
>
> >
> > We'll leave most of the HDCP 2.x code alone since we don't have another
> > implementation of HDCP 2.x to use as reference for what should and
> > should not live in the drm helpers. The helper will call the overly
> > general enable/disable/is_capable HDCP 2.x callbacks and leave the
> > interesting stuff for the driver. Once we have another HDCP 2.x
> > implementation, we should do a similar migration.
>
> I believe this part is the part that I start to get lost when
> trying to review it.
>
> Mark told me in irc that it is really hard to split this patch,
> but do we really need to have the hdcp 1.x changes along with the
> 2.x? I start to get lost in the review when I see the changes around
> the hdcp2_capable...
>
> So, it would be really really good if we can split this patch.
>
> >
> > Acked-by: Jani Nikula
> > Signed-off-by: Sean Paul
> > Signed-off-by: Mark Yacoub
>
> Cc: Suraj Kandpal
>
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210913175747.47456-8-s...@poorly.run
> > #v1
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20210915203834.1439-8-s...@poorly.run
> > #v2
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211001151145.55916-8-s...@poorly.run
> > #v3
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20211105030434.2828845-8-s...@poorly.run
> > #v4
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20220411204741.1074308-8-s...@poorly.run
> > #v5
> >
> > Changes in v2:
> > -Fix mst helper function pointer reported by 0-day
> > Changes in v3:
> > -Add forward declaration for drm_atomic_state in intel_hdcp.h identified
> > by 0-day
> > Changes in v4:
> > -None
> > Changes in v5:
> > -None
> > Changes in v6:
> > -Rebased.
> >
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 32 +-
> > .../drm/i915/display/intel_display_debugfs.c | 6 +-
> > .../drm/i915/display/intel_display_types.h| 60 +-
> > drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 348 +++
> > drivers/gpu/drm/i915/display/intel_dp_mst.c | 16 +-
> > drivers/gpu/drm/i915/display/intel_hdcp.c | 952 +++---
> > drivers/gpu/drm/i915/display/intel_hdcp.h | 31 +-
> > drivers/gpu/drm/i915/display/intel_hdmi.c | 270 ++---
> > 8 files changed, 445 insertions(+), 1270 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 69ecf2a3d6c6..a4397f066a3e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -28,6 +28,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> >
> > #include "i915_drv.h"
> > @@ -2909,6 +2910,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> > const struct intel_crtc_state *crtc_state,
> > const struct drm_connector_state *conn_state)
> > {
> > + struct intel_connector *connector =
> > + to_intel_connector(conn_state->connector);
> > + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > +
> > drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
> >
> > if (!intel_crtc_is_bigjoiner_slave(crtc_state))
> > @@ -2925,12 +2930,10 @@ static void intel_enable_ddi(struct
> > intel_atomic_state *state,
> > else
> > intel_enable_ddi_dp(state, encoder, crtc_state, conn_state);
> >
> > - /* Enable hdcp if it's desired */
> > - if (conn_state->content_protection ==
> > - DRM_MODE_CONTENT_PROTECTION_DESIRED)
> > - intel_hdcp_enable(to_intel_connector(conn_state->connector),
> > - crtc_state,
> > - (u8)conn_state->hdcp_content_type);
> > + if (connector->hdcp_helper_data)
> > + drm_hdcp_helper_atomic_commit(connector->hdcp_helper_data,
> > + &state->base,
> > + &dig_port->hdcp_mutex);
> > }
> >
> > static void intel_disable_ddi_dp(struct intel_atomic_state *sta
Re: [PATCH] drm/amd/display: Trivial swizzle-related code clean-ups
Applied. Thanks!
Alex
On Tue, Jan 31, 2023 at 9:40 AM Harry Wentland wrote:
>
> On 1/30/23 14:56, Guilherme G. Piccoli wrote:
> > This is a very trivial code clean-up related to commit 5468c36d6285
> > ("drm/amd/display: Filter Invalid 420 Modes for HDMI TMDS"). This commit
> > added a validation on driver probe to prevent invalid TMDS modes, but one
> > of the fake properties (swizzle) ended-up causing a warning on driver
> > probe; was reported here:
> > https://gitlab.freedesktop.org/drm/amd/-/issues/2264.
> >
> > It was fixed by commit 105a8b8698e2 ("drm/amd/display: patch cases with
> > unknown plane state to prevent warning"), but the validation code had
> > a double variable assignment, which we hereby remove. Also, the fix relies
> > in the dcn2{0,1}patch_unknown_plane_state() callbacks, so while at it we
> > took the opportunity to perform a small code clean-up in such routines.
> >
> > Cc: Aurabindo Pillai
> > Cc: Daniel Wheeler
> > Cc: Fangzhi Zuo
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Mark Broadworth
> > Cc: Melissa Wen
> > Cc: Rodrigo Siqueira
> > Cc: Sung Joon Kim
> > Cc: Swapnil Patel
> > Signed-off-by: Guilherme G. Piccoli
>
> Reviewed-by: Harry Wentland
>
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 -
> > drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 8 ++--
> > drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 6 ++
> > 3 files changed, 4 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 86a2f7f58550..e71e94663d14 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -6336,7 +6336,6 @@ static enum dc_status
> > dm_validate_stream_and_context(struct dc *dc,
> > dc_plane_state->plane_size.surface_size.width = stream->src.width;
> > dc_plane_state->plane_size.chroma_size.height = stream->src.height;
> > dc_plane_state->plane_size.chroma_size.width = stream->src.width;
> > - dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> > dc_plane_state->format = SURFACE_PIXEL_FORMAT_GRPH_ARGB;
> > dc_plane_state->tiling_info.gfx9.swizzle = DC_SW_UNKNOWN;
> > dc_plane_state->rotation = ROTATION_ANGLE_0;
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > index 531f405d2554..3af24ef9cb2d 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c
> > @@ -2225,14 +2225,10 @@ enum dc_status
> > dcn20_patch_unknown_plane_state(struct dc_plane_state *plane_stat
> > enum surface_pixel_format surf_pix_format = plane_state->format;
> > unsigned int bpp = resource_pixel_format_to_bpp(surf_pix_format);
> >
> > - enum swizzle_mode_values swizzle = DC_SW_LINEAR;
> > -
> > + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_S;
> > if (bpp == 64)
> > - swizzle = DC_SW_64KB_D;
> > - else
> > - swizzle = DC_SW_64KB_S;
> > + plane_state->tiling_info.gfx9.swizzle = DC_SW_64KB_D;
> >
> > - plane_state->tiling_info.gfx9.swizzle = swizzle;
> > return DC_OK;
> > }
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > index fbcf0afeae0d..8f9244fe5c86 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c
> > @@ -1393,15 +1393,13 @@ static uint32_t read_pipe_fuses(struct dc_context
> > *ctx)
> >
> > static enum dc_status dcn21_patch_unknown_plane_state(struct
> > dc_plane_state *plane_state)
> > {
> > - enum dc_status result = DC_OK;
> > -
> > if (plane_state->ctx->dc->debug.disable_dcc == DCC_ENABLE) {
> > plane_state->dcc.enable = 1;
> > /* align to our worst case block width */
> > plane_state->dcc.meta_pitch = ((plane_state->src_rect.width +
> > 1023) / 1024) * 1024;
> > }
> > - result = dcn20_patch_unknown_plane_state(plane_state);
> > - return result;
> > +
> > + return dcn20_patch_unknown_plane_state(plane_state);
> > }
> >
> > static const struct resource_funcs dcn21_res_pool_funcs = {
>
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 5:58 AM Christian König
wrote:
>
> Am 31.01.23 um 10:17 schrieb Chen, Guchun:
> > Hi Piccoli,
> >
> > Please ignore my request of full dmesg log. I can reproduce the issue and
> > get the same failure callstack by returning early with an error code prior
> > to amdgpu_device_init_schedulers.
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Chen, Guchun
> > Sent: Tuesday, January 31, 2023 2:37 PM
> > To: Alex Deucher ; Guilherme G. Piccoli
> >
> > Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Pan, Xinhui
> > ; dri-devel@lists.freedesktop.org; Tuikov, Luben
> > ; Limonciello, Mario ;
> > kernel-...@igalia.com; Deucher, Alexander ;
> > Koenig, Christian
> > Subject: RE: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> > drm_sched init/fini
> >
> > Hi Piccoli,
> >
> > I agree with Alex's point, using ring->sched.name for such check is not a
> > good way. BTW, can you please attach a full dmesg long in bad case to help
> > me understand more?
> >
> > Regards,
> > Guchun
> >
> > -Original Message-
> > From: Alex Deucher
> > Sent: Tuesday, January 31, 2023 6:30 AM
> > To: Guilherme G. Piccoli
> > Cc: amd-...@lists.freedesktop.org; ker...@gpiccoli.net; Chen, Guchun
> > ; Pan, Xinhui ;
> > dri-devel@lists.freedesktop.org; Tuikov, Luben ;
> > Limonciello, Mario ; kernel-...@igalia.com;
> > Deucher, Alexander ; Koenig, Christian
> >
> > Subject: Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching
> > drm_sched init/fini
> >
> > On Mon, Jan 30, 2023 at 4:51 PM Guilherme G. Piccoli
> > wrote:
> >> + Luben
> >>
> >> (sorry, missed that in the first submission).
> >>
> >> On 30/01/2023 18:45, Guilherme G. Piccoli wrote:
> >>> Currently amdgpu calls drm_sched_fini() from the fence driver sw
> >>> fini routine - such function is expected to be called only after the
> >>> respective init function - drm_sched_init() - was executed successfully.
> >>>
> >>> Happens that we faced a driver probe failure in the Steam Deck
> >>> recently, and the function drm_sched_fini() was called even without
> >>> its counter-part had been previously called, causing the following oops:
> >>>
> >>> amdgpu: probe of :04:00.0 failed with error -110
> >>> BUG: kernel NULL pointer dereference, address: 0090 PGD
> >>> 0 P4D 0
> >>> Oops: 0002 [#1] PREEMPT SMP NOPTI
> >>> CPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli
> >>> #338 Hardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022
> >>> RIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched] [...] Call Trace:
> >>>
> >>> amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]
> >>> amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]
> >>> amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
> >>> devm_drm_dev_init_release+0x49/0x70
> >>> [...]
> >>>
> >>> To prevent that, check if the drm_sched was properly initialized for
> >>> a given ring before calling its fini counter-part.
> >>>
> >>> Notice ideally we'd use sched.ready for that; such field is set as
> >>> the latest thing on drm_sched_init(). But amdgpu seems to "override"
> >>> the meaning of such field - in the above oops for example, it was a
> >>> GFX ring causing the crash, and the sched.ready field was set to
> >>> true in the ring init routine, regardless of the state of the DRM
> >>> scheduler. Hence, we ended-up using another sched field.
> > Fixes: 067f44c8b459 ("drm/amdgpu: avoid over-handle of fence
> > driver fini in s3 test (v2)")
> >>> Cc: Andrey Grodzovsky
> >>> Cc: Guchun Chen
> >>> Cc: Mario Limonciello
> >>> Signed-off-by: Guilherme G. Piccoli
> >>> ---
> >>>
> >>>
> >>> Hi folks, first of all thanks in advance for reviews / comments!
> >>> Notice that I've used the Fixes tag more in the sense to bring it to
> >>> stable, I didn't find a good patch candidate that added the call to
> >>> drm_sched_fini(), was reaching way too old commits...so
> >>> 067f44c8b459 seems a good candidate - or maybe not?
> >>>
> >>> Now, with regards sched.ready, spent a bit of time to figure what
> >>> was happening...would be feasible maybe to stop using that to mark
> >>> some kind ring status? I think it should be possible to add a flag
> >>> to the ring structure for that, and free sched.ready from being
> >>> manipulate by the amdgpu driver, what's your thoughts on that?
> > It's been a while, but IIRC, we used to have a ring->ready field in the
> > driver which at some point got migrated out of the driver into the GPU
> > scheduler and the driver side code never got cleaned up. I think we should
> > probably just drop the driver messing with that field and leave it up to
> > the drm scheduler.
>
> To use ring->ready is not a good idea since this doesn't specify if the
> scheduler was initialized, but rather if bringup of the engine worked.
ring->ready no longer exists. It was moved into the scheduler and the
driver side never got cleaned up. Also, we set ring->sched.ready =
true once the rings
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 9:32 AM Guilherme G. Piccoli wrote: > > On 31/01/2023 10:58, Chen, Guchun wrote: > > Hi Christian, > > > > Do you think if it makes sense that we can set 'ring->sched.ready' to be > > true in each ring init, even if before executing/setting up drm_sched_init > > in amdgpu_device_init_schedulers? As 'ready' is a member of gpu scheduler > > structure. > > > > Regards, > > Guchun > > > > Hi folks, thanks a lot for the feedback so far, much appreciated! > > I'm feeling a bit confused specially since there seems to be 2 > orthogonal (yet related) topics being discussed; let me try to summarize > my understanding and we can then further discuss better: > > (a) The first problem is the one addressed in the patch - how to prevent > drm_sched_fini() to get called if drm_sched_init() wasn't called? > > I've proposed sched.name, seems Christian prefers sched.ops, correct? > > > (b) We can't use sched.ready, which would make sense...but amdgpu > overrides its meaning, the driver manipulates this value for its own > purposes of tracking ring init, or something like that. > > This is the tangential topic: what should we do here? My understanding > of Alex's message is that we could have a "ready" field in the ring > structure and stop messing with sched.ready - does it make sense Alex? Yes, I think so. The tricky part will be figuring out which current sched.ready checks are checking for the scheduler being ready vs. whether the ring itself is ready. > > Guchun / Christian, does it also make sense for you? > > > Regarding (a), I could re-submit having s/sched.name/sched.ops, no > biggies, I tested both to be fair, before sending...I just chose name > but any field that is proper initialized on drm_sched_init() would work. Yeah, I think ops is fine. You could even use sched.ready after we clean up the use of that in the driver. There are already a bunch of places where we check sched.ready to check if the scheduler really is ready. Alex > > Thanks, > > > Guilherme
Re: [PATCH v2 7/8] drm/vmwgfx: Abstract placement selection
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Problem with explicit placement selection in vmwgfx is that by the time
the buffer object needs to be validated the information about which
placement was supposed to be used is lost. To workaround this the driver
had a bunch of state in various places e.g. as_mob or cpu_blit to
somehow convey the information on which placement was intended.
Fix it properly by allowing the buffer objects to hold their preferred
placement so it can be reused whenever needed. This makes the entire
validation pipeline a lot easier both to understand and maintain.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 145 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 25 +-
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 9 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 11 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 35 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 5 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 21 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 11 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 13 +-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 15 +-
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 304 ++
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 47 ---
drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 74 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 6 +-
22 files changed, 312 insertions(+), 456 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index c6dc733f6d45..d8f6ccecf4bf 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -135,11 +135,17 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private
*dev_priv,
goto out_unreserve;
}
- ret = ttm_bo_validate(bo, &vmw_vram_gmr_placement, &ctx);
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_GMR | VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_GMR);
+ ret = ttm_bo_validate(bo, &buf->placement, &ctx);
if (likely(ret == 0) || ret == -ERESTARTSYS)
goto out_unreserve;
- ret = ttm_bo_validate(bo, &vmw_vram_placement, &ctx);
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_VRAM);
+ ret = ttm_bo_validate(bo, &buf->placement, &ctx);
out_unreserve:
if (!ret)
@@ -190,17 +196,8 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
{
struct ttm_operation_ctx ctx = {interruptible, false };
struct ttm_buffer_object *bo = &buf->base;
- struct ttm_placement placement;
- struct ttm_place place;
int ret = 0;
- place = vmw_vram_placement.placement[0];
- place.lpfn = PFN_UP(bo->resource->size);
- placement.num_placement = 1;
- placement.placement = &place;
- placement.num_busy_placement = 1;
- placement.busy_placement = &place;
-
vmw_execbuf_release_pinned_bo(dev_priv);
ret = ttm_bo_reserve(bo, interruptible, false, NULL);
if (unlikely(ret != 0))
@@ -216,14 +213,21 @@ int vmw_bo_pin_in_start_of_vram(struct vmw_private
*dev_priv,
bo->resource->start > 0 &&
buf->base.pin_count == 0) {
ctx.interruptible = false;
- (void) ttm_bo_validate(bo, &vmw_sys_placement, &ctx);
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_SYS,
+VMW_BO_DOMAIN_SYS);
+ (void)ttm_bo_validate(bo, &buf->placement, &ctx);
}
+ vmw_bo_placement_set(buf,
+VMW_BO_DOMAIN_VRAM,
+VMW_BO_DOMAIN_VRAM);
+ buf->places[0].lpfn = PFN_UP(bo->resource->size);
if (buf->base.pin_count > 0)
- ret = ttm_resource_compat(bo->resource, &placement)
+ ret = ttm_resource_compat(bo->resource, &buf->placement)
? 0 : -EINVAL;
else
- ret = ttm_bo_validate(bo, &placement, &ctx);
+ ret = ttm_bo_validate(bo, &buf->placement, &ctx);
/* For some reason we didn't end up at the start of vram */
WARN_ON(ret == 0 && bo->resource->start != 0);
@@ -431,7 +435,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv,
Re: [PATCH v2 6/8] drm/vmwgfx: Rename dummy to is_iomem
From: Martin Krastev
LGTM
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Rename dummy to is_iomem because that's what it is even if we're not
activelly using it. Makes the code easier to read.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1082218a1cfc..e83286e08837 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -153,9 +153,9 @@ static void vmw_cursor_update_mob(struct vmw_private
*dev_priv,
SVGAGBCursorHeader *header;
SVGAGBAlphaCursorHeader *alpha_header;
const u32 image_size = width * height * sizeof(*image);
- bool dummy;
+ bool is_iomem;
- header = ttm_kmap_obj_virtual(&vps->cursor.map, &dummy);
+ header = ttm_kmap_obj_virtual(&vps->cursor.map, &is_iomem);
alpha_header = &header->header.alphaHeader;
memset(header, 0, sizeof(*header));
@@ -185,13 +185,13 @@ static u32 vmw_du_cursor_mob_size(u32 w, u32 h)
*/
static u32 *vmw_du_cursor_plane_acquire_image(struct vmw_plane_state *vps)
{
- bool dummy;
+ bool is_iomem;
if (vps->surf) {
if (vps->surf_mapped)
return vmw_bo_map_and_cache(vps->surf->res.backup);
return vps->surf->snooper.image;
} else if (vps->bo)
- return ttm_kmap_obj_virtual(&vps->bo->map, &dummy);
+ return ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem);
return NULL;
}
@@ -364,7 +364,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
SVGA3dCopyBox *box;
unsigned box_count;
void *virtual;
- bool dummy;
+ bool is_iomem;
struct vmw_dma_cmd {
SVGA3dCmdHeader header;
SVGA3dCmdSurfaceDMA dma;
@@ -424,7 +424,7 @@ void vmw_kms_cursor_snoop(struct vmw_surface *srf,
if (unlikely(ret != 0))
goto err_unreserve;
- virtual = ttm_kmap_obj_virtual(&map, &dummy);
+ virtual = ttm_kmap_obj_virtual(&map, &is_iomem);
if (box->w == VMW_CURSOR_SNOOP_WIDTH && cmd->dma.guest.pitch == image_pitch) {
memcpy(srf->snooper.image, virtual,
@@ -658,14 +658,14 @@ vmw_du_cursor_plane_cleanup_fb(struct drm_plane *plane,
{
struct vmw_cursor_plane *vcp = vmw_plane_to_vcp(plane);
struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
- bool dummy;
+ bool is_iomem;
if (vps->surf_mapped) {
vmw_bo_unmap(vps->surf->res.backup);
vps->surf_mapped = false;
}
- if (vps->bo && ttm_kmap_obj_virtual(&vps->bo->map, &dummy)) {
+ if (vps->bo && ttm_kmap_obj_virtual(&vps->bo->map, &is_iomem)) {
const int ret = ttm_bo_reserve(&vps->bo->base, true, false,
NULL);
if (likely(ret == 0)) {
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On 31/01/2023 14:52, Alex Deucher wrote: > [...] >> (b) We can't use sched.ready, which would make sense...but amdgpu >> overrides its meaning, the driver manipulates this value for its own >> purposes of tracking ring init, or something like that. >> >> This is the tangential topic: what should we do here? My understanding >> of Alex's message is that we could have a "ready" field in the ring >> structure and stop messing with sched.ready - does it make sense Alex? > > Yes, I think so. The tricky part will be figuring out which current > sched.ready checks are checking for the scheduler being ready vs. > whether the ring itself is ready. > Thanks, makes sense! $ grep -nr "sched.ready" drivers/gpu/drm/amd/ | wc -l 83 Maybe not super tough, I hope heh >> >> Guchun / Christian, does it also make sense for you? >> >> >> Regarding (a), I could re-submit having s/sched.name/sched.ops, no >> biggies, I tested both to be fair, before sending...I just chose name >> but any field that is proper initialized on drm_sched_init() would work. > > Yeah, I think ops is fine. You could even use sched.ready after we > clean up the use of that in the driver. There are already a bunch of > places where we check sched.ready to check if the scheduler really is > ready. Hmm..unfortunately, doesn't work. This was a case in which sched.ready was set to true in the ring init routine, but scheduler wasn't properly initialized. So, a different key for comparison is required..I'll re-submit with sched.ops. After a potential rework of the driver to get rid of sched.ready manipulation, then it could be fixed to properly use this flag...makes sense to you? Tnx again for the prompt review! Cheers, Guilherme
Re: linux-next: manual merge of the usb tree with the drm-intel-fixes tree
On 1/31/2023 04:44, Andy Shevchenko wrote:
On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the usb tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_cs.c
between commit:
5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists")
from the drm-intel-fixes tree and commit:
4d70c74659d9 ("i915: Move list_count() to list.h as list_count_nodes() for
broader use")
from the usb tree.
I fixed it up (the former removed the code changed by the latter)
Hmm... Currently I see that 20230127002842.3169194-4-john.c.harri...@intel.com
moves the code to the drivers/gpu/drm/i915/gt/intel_execlists_submission.c.
Is there any new series beside the above mentioned that touches that file and
actually _removes_ that code?
As long as the removal is limited to list_count/list_count_nodes, that's
fine. I only moved it from one file to another because the one and only
function that was using it was being moved to the other file. If someone
else has found a use for the same and wants to move it to a more common
place then great. I assume there was no conflict happening in the i915
specific code.
John.
and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
Re: [PATCH] drm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini
On Tue, Jan 31, 2023 at 1:23 PM Guilherme G. Piccoli wrote: > > On 31/01/2023 14:52, Alex Deucher wrote: > > [...] > >> (b) We can't use sched.ready, which would make sense...but amdgpu > >> overrides its meaning, the driver manipulates this value for its own > >> purposes of tracking ring init, or something like that. > >> > >> This is the tangential topic: what should we do here? My understanding > >> of Alex's message is that we could have a "ready" field in the ring > >> structure and stop messing with sched.ready - does it make sense Alex? > > > > Yes, I think so. The tricky part will be figuring out which current > > sched.ready checks are checking for the scheduler being ready vs. > > whether the ring itself is ready. > > > > Thanks, makes sense! > > $ grep -nr "sched.ready" drivers/gpu/drm/amd/ | wc -l > 83 > > Maybe not super tough, I hope heh > > >> > >> Guchun / Christian, does it also make sense for you? > >> > >> > >> Regarding (a), I could re-submit having s/sched.name/sched.ops, no > >> biggies, I tested both to be fair, before sending...I just chose name > >> but any field that is proper initialized on drm_sched_init() would work. > > > > Yeah, I think ops is fine. You could even use sched.ready after we > > clean up the use of that in the driver. There are already a bunch of > > places where we check sched.ready to check if the scheduler really is > > ready. > > Hmm..unfortunately, doesn't work. This was a case in which sched.ready > was set to true in the ring init routine, but scheduler wasn't properly > initialized. So, a different key for comparison is required..I'll > re-submit with sched.ops. > > After a potential rework of the driver to get rid of sched.ready > manipulation, then it could be fixed to properly use this flag...makes > sense to you? Yeah, sounds good. Thanks! Alex > > Tnx again for the prompt review! > Cheers, > > > Guilherme
Re: [PATCH v2 8/8] drm/vmwgfx: Stop using raw ttm_buffer_object's
From: Martin Krastev
LGTM!
Reviewed-by: Martin Krastev
Regards,
Martin
On 31.01.23 г. 5:35 ч., Zack Rusin wrote:
From: Zack Rusin
Various bits of the driver used raw ttm_buffer_object instead of the
driver specific vmw_bo object. All those places used to duplicate
the mapped bo caching policy of vmw_bo.
Instead of duplicating all of that code and special casing various
functions to work both with vmw_bo and raw ttm_buffer_object's unify
the buffer object handling code.
As part of that work fix the naming of bo's, e.g. insted of generic
backup use 'guest_memory' because that's what it really is.
All of it makes the driver easier to maintain and the code easier to
read. Saves 100+ loc as well.
Signed-off-by: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 204 +---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 60 ++---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 44 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 16 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 51 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 53 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 37 +--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 105 -
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 6 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 38 +--
drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 51 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 220 +-
drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 7 +-
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 49 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 98
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 66 ++
drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 62 +++--
27 files changed, 566 insertions(+), 691 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index d8f6ccecf4bf..63486802c8fd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
@@ -32,6 +32,12 @@
#include
+static void vmw_bo_release(struct vmw_bo *vbo)
+{
+ vmw_bo_unmap(vbo);
+ drm_gem_object_release(&vbo->tbo.base);
+}
+
/**
* vmw_bo_free - vmw_bo destructor
*
@@ -43,26 +49,10 @@ static void vmw_bo_free(struct ttm_buffer_object *bo)
WARN_ON(vbo->dirty);
WARN_ON(!RB_EMPTY_ROOT(&vbo->res_tree));
- vmw_bo_unmap(vbo);
- drm_gem_object_release(&bo->base);
+ vmw_bo_release(vbo);
kfree(vbo);
}
-/**
- * bo_is_vmw - check if the buffer object is a &vmw_bo
- * @bo: ttm buffer object to be checked
- *
- * Uses destroy function associated with the object to determine if this is
- * a &vmw_bo.
- *
- * Returns:
- * true if the object is of &vmw_bo type, false if not.
- */
-static bool bo_is_vmw(struct ttm_buffer_object *bo)
-{
- return bo->destroy == &vmw_bo_free;
-}
-
/**
* vmw_bo_pin_in_placement - Validate a buffer to placement.
*
@@ -79,7 +69,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
*dev_priv,
bool interruptible)
{
struct ttm_operation_ctx ctx = {interruptible, false };
- struct ttm_buffer_object *bo = &buf->base;
+ struct ttm_buffer_object *bo = &buf->tbo;
int ret;
vmw_execbuf_release_pinned_bo(dev_priv);
@@ -88,7 +78,7 @@ static int vmw_bo_pin_in_placement(struct vmw_private
*dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->base.pin_count > 0)
+ if (buf->tbo.pin_count > 0)
ret = ttm_resource_compat(bo->resource, placement)
? 0 : -EINVAL;
else
@@ -120,7 +110,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
bool interruptible)
{
struct ttm_operation_ctx ctx = {interruptible, false };
- struct ttm_buffer_object *bo = &buf->base;
+ struct ttm_buffer_object *bo = &buf->tbo;
int ret;
vmw_execbuf_release_pinned_bo(dev_priv);
@@ -129,7 +119,7 @@ int vmw_bo_pin_in_vram_or_gmr(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
goto err;
- if (buf->base.pin_count > 0) {
+ if (buf->tbo.pin_count > 0) {
ret = ttm_resource_compat(bo->resource, &vmw_vram_gmr_placement)
? 0 : -EINVAL;
goto out_un
Re: [PATCH v2 0/8] drm/vmwgfx: Refactor the buffer object code
Hi, I cannot comment much on the internal workings of the vmwgfx driver, but feel free to add Acked-by: Thomas Zimmermann to the patches that don't already have my r-b. Best regards Thomas Am 31.01.23 um 04:35 schrieb Zack Rusin: From: Zack Rusin v2: Fix all the issues which Thomas pointed out in the initial review and split the "simplify fb pinning" change into two commits with the second one being just the rename. The series refactors the buffer object code to make more alike the other ttm drivers. The placement becomes a property of the bo which makes it a lot easier to correctly validate based on the current usage. vmwgfx tends to do more validation due to forced moves, because the buffer placement sometimes need to change due to userspace commands, i.e. some commands e.g. SURFACE_DMA implies GMR's which are really deprecated in favor of MOB's, but the x11 driver still uses GMR's so buffers tend to flip between GMR's and MOB's a bit when running on X11. The functionality remains largely unchanged, but the LOC are reduced by about 400 and the groundwork is done for adding prime support with SG ttm buffers. Zack Rusin (8): drm/vmwgfx: Use the common gem mmap instead of the custom code drm/vmwgfx: Remove the duplicate bo_free function drm/vmwgfx: Rename vmw_buffer_object to vmw_bo drm/vmwgfx: Simplify fb pinning drm/vmwgfx: Cleanup the vmw bo usage in the cursor paths drm/vmwgfx: Rename dummy to is_iomem drm/vmwgfx: Abstract placement selection drm/vmwgfx: Stop using raw ttm_buffer_object's drivers/gpu/drm/vmwgfx/Makefile | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 392 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.h| 203 + drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 14 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c| 53 +-- drivers/gpu/drm/vmwgfx/vmwgfx_context.c | 36 +- drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c | 65 +-- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 26 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 245 +++ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 102 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 89 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 230 -- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 43 +- drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 57 ++- drivers/gpu/drm/vmwgfx/vmwgfx_mob.c | 45 +- drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 20 +- drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c| 68 ++- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 243 +-- drivers/gpu/drm/vmwgfx/vmwgfx_resource_priv.h | 10 +- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 53 +-- drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 65 +-- drivers/gpu/drm/vmwgfx/vmwgfx_so.c| 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 323 ++- drivers/gpu/drm/vmwgfx/vmwgfx_streamoutput.c | 20 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 111 ++--- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 116 +- drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 110 - drivers/gpu/drm/vmwgfx/vmwgfx_va.c| 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_validation.c| 150 +++ drivers/gpu/drm/vmwgfx/vmwgfx_validation.h| 10 +- 31 files changed, 1248 insertions(+), 1667 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_bo.h delete mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev OpenPGP_signature Description: OpenPGP digital signature
[PATCH v3 2/6] drm/debugfs: Make drm_device use the struct drm_debugfs_files
The struct drm_debugfs_files encapsulates all the debugfs-related
objects, so that they can be initialized and destroyed with two helpers.
Therefore, make the struct drm_device use the struct drm_debugfs_files
instead of instantiating the debugfs list and mutex separated.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 10 +-
drivers/gpu/drm/drm_drv.c | 7 ---
include/drm/drm_device.h | 12 +++-
3 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 8658d3929ea5..aa83f230c402 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -263,7 +263,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
+ list_for_each_entry_safe(entry, tmp, &dev->debugfs_files->list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
list_del(&entry->list);
@@ -280,7 +280,7 @@ void drm_debugfs_late_register(struct drm_device *dev)
if (!minor)
return;
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_list, list) {
+ list_for_each_entry_safe(entry, tmp, &dev->debugfs_files->list, list) {
debugfs_create_file(entry->file.name, 0444,
minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
list_del(&entry->list);
@@ -357,9 +357,9 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.data = data;
entry->dev = dev;
- mutex_lock(&dev->debugfs_mutex);
- list_add(&entry->list, &dev->debugfs_list);
- mutex_unlock(&dev->debugfs_mutex);
+ mutex_lock(&dev->debugfs_files->mutex);
+ list_add(&entry->list, &dev->debugfs_files->list);
+ mutex_unlock(&dev->debugfs_files->mutex);
}
EXPORT_SYMBOL(drm_debugfs_add_file);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index c6eb8972451a..50812cbe1d81 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -598,7 +599,7 @@ static void drm_dev_init_release(struct drm_device *dev,
void *res)
mutex_destroy(&dev->clientlist_mutex);
mutex_destroy(&dev->filelist_mutex);
mutex_destroy(&dev->struct_mutex);
- mutex_destroy(&dev->debugfs_mutex);
+ drm_debugfs_files_destroy(dev->debugfs_files);
drm_legacy_destroy_members(dev);
}
@@ -639,14 +640,14 @@ static int drm_dev_init(struct drm_device *dev,
INIT_LIST_HEAD(&dev->filelist_internal);
INIT_LIST_HEAD(&dev->clientlist);
INIT_LIST_HEAD(&dev->vblank_event_list);
- INIT_LIST_HEAD(&dev->debugfs_list);
spin_lock_init(&dev->event_lock);
mutex_init(&dev->struct_mutex);
mutex_init(&dev->filelist_mutex);
mutex_init(&dev->clientlist_mutex);
mutex_init(&dev->master_mutex);
- mutex_init(&dev->debugfs_mutex);
+
+ dev->debugfs_files = drm_debugfs_files_init();
ret = drmm_add_action_or_reset(dev, drm_dev_init_release, NULL);
if (ret)
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 7cf4afae2e79..77290f4a06ff 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -16,6 +16,7 @@ struct drm_vblank_crtc;
struct drm_vma_offset_manager;
struct drm_vram_mm;
struct drm_fb_helper;
+struct drm_debugfs_files;
struct inode;
@@ -312,19 +313,12 @@ struct drm_device {
struct drm_fb_helper *fb_helper;
/**
-* @debugfs_mutex:
-*
-* Protects &debugfs_list access.
-*/
- struct mutex debugfs_mutex;
-
- /**
-* @debugfs_list:
+* @debugfs_files:
*
* List of debugfs files to be created by the DRM device. The files
* must be added during drm_dev_register().
*/
- struct list_head debugfs_list;
+ struct drm_debugfs_files *debugfs_files;
/* Everything below here is for legacy driver, never use! */
/* private: */
--
2.39.1
[PATCH v3 0/6] drm/debugfs: Make the debugfs structure more generic
This series is the first step to introduce a debugfs structure to KMS objects and it is inspired by the feedback provided in [1]. Thanks, Jani and Daniel for all the feedback provided! This first step is making the current API more generic and preparing it to receive the KMS objects in the future. Moreover, this will help to avoid copypasting when expanding the API. Make the debug structure more generic by: - Passing the right pointer to the functions as an explicit parameter. So, the show function signature should be int show(struct seq_file *m, struct drm_device *dev, void *data) Note that with this approach, the show callback doesn't need to use the struct drm_debugfs_entry anymore. - Switch the pointer in struct drm_debugfs_entry to void *, so that, in the future, the struct drm_debugfs_entry can receive different types of DRM objects (struct drm_device, struct drm_connector, struct drm_crtc...). - Switch the show callback pointer to void * and cast it in the show callback wrapper. This way in the future we can create different callback wrappers and cast each one to the proper function signature. - Add a struct wrapper for debugfs_list and debugfs_mutex, and also create helpers to init the list, destroy the list, register the list's files and add files to the list. v1 -> v2: https://lore.kernel.org/dri-devel/20230116102815.95063-1-mca...@igalia.com/T/ - Use forward declaration instead of the header (Jani Nikula). - Make the struct drm_debugfs_files a pointer in struct drm_device (Jani Nikula). - Change the parameter order of `drm_debugfs_files_add` (Jani Nikula). - s/struct drm_debugfs_list/struct drm_debugfs_files (Jani Nikula). v2 -> v3: https://lore.kernel.org/dri-devel/20230130123008.287141-1-mca...@igalia.com/T/ - Fix compilation errors for CONFIG_DEBUG_FS=n (kernel test robot). [1] https://lore.kernel.org/dri-devel/2023073748.752659-1-mca...@igalia.com/T/ Best Regards, - Maíra Canal Maíra Canal (6): drm/debugfs: Introduce wrapper for debugfs list drm/debugfs: Make drm_device use the struct drm_debugfs_files drm/debugfs: Create wrapper to add files to debugfs list drm/debugfs: Create wrapper to register debugfs drm/debugfs: Make the show callback pass the pointer to the right object drm/debugfs: Make the struct drm_debugfs_entry independent of DRM device drivers/gpu/drm/arm/hdlcd_drv.c | 8 +-- drivers/gpu/drm/drm_atomic.c | 4 +- drivers/gpu/drm/drm_client.c | 5 +- drivers/gpu/drm/drm_debugfs.c | 81 +-- drivers/gpu/drm/drm_drv.c | 7 ++- drivers/gpu/drm/drm_framebuffer.c | 4 +- drivers/gpu/drm/drm_gem_vram_helper.c | 5 +- drivers/gpu/drm/drm_internal.h| 12 drivers/gpu/drm/gud/gud_drv.c | 5 +- drivers/gpu/drm/v3d/v3d_debugfs.c | 16 ++ drivers/gpu/drm/vc4/vc4_bo.c | 4 +- drivers/gpu/drm/vc4/vc4_debugfs.c | 6 +- drivers/gpu/drm/vc4/vc4_hdmi.c| 6 +- drivers/gpu/drm/vc4/vc4_hvs.c | 8 +-- drivers/gpu/drm/vc4/vc4_v3d.c | 4 +- drivers/gpu/drm/vkms/vkms_drv.c | 4 +- include/drm/drm_debugfs.h | 34 --- include/drm/drm_device.h | 12 +--- 18 files changed, 120 insertions(+), 105 deletions(-) -- 2.39.1
[PATCH v3 1/6] drm/debugfs: Introduce wrapper for debugfs list
Introduce a struct wrapper for all the debugfs-related stuff: the list
of debugfs files and the mutex that protects it. This will make it
easier to initialize all the debugfs list in a DRM object and will
create a good abstraction for a possible implementation of the debugfs
infrastructure for KMS objects.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 18 ++
drivers/gpu/drm/drm_internal.h | 12
include/drm/drm_debugfs.h | 16
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4f643a490dc3..8658d3929ea5 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -218,6 +218,24 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
}
EXPORT_SYMBOL(drm_debugfs_create_files);
+struct drm_debugfs_files *drm_debugfs_files_init(void)
+{
+ struct drm_debugfs_files *debugfs_files;
+
+ debugfs_files = kzalloc(sizeof(*debugfs_files), GFP_KERNEL);
+
+ INIT_LIST_HEAD(&debugfs_files->list);
+ mutex_init(&debugfs_files->mutex);
+
+ return debugfs_files;
+}
+
+void drm_debugfs_files_destroy(struct drm_debugfs_files *debugfs_files)
+{
+ mutex_destroy(&debugfs_files->mutex);
+ kfree(debugfs_files);
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index ed2103ee272c..f1c8766ed828 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -23,6 +23,7 @@
#include
+#include
#include
#include
@@ -183,6 +184,8 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
drm_device *dev,
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
+struct drm_debugfs_files *drm_debugfs_files_init(void);
+void drm_debugfs_files_destroy(struct drm_debugfs_files *debugfs_files);
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root);
void drm_debugfs_cleanup(struct drm_minor *minor);
@@ -193,6 +196,15 @@ void drm_debugfs_crtc_add(struct drm_crtc *crtc);
void drm_debugfs_crtc_remove(struct drm_crtc *crtc);
void drm_debugfs_crtc_crc_add(struct drm_crtc *crtc);
#else
+static inline struct drm_debugfs_files *drm_debugfs_files_init(void)
+{
+ return NULL;
+}
+
+static inline void drm_debugfs_files_destroy(struct drm_debugfs_files
*debugfs_files)
+{
+}
+
static inline int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 7616f457ce70..423aa3de506a 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -32,6 +32,8 @@
#ifndef _DRM_DEBUGFS_H_
#define _DRM_DEBUGFS_H_
+#include
+#include
#include
#include
/**
@@ -79,6 +81,20 @@ struct drm_info_node {
struct dentry *dent;
};
+/**
+ * struct drm_debugfs_files - Encapsulates the debugfs list and its mutex
+ *
+ * This structure represents the debugfs list of files and is encapsulated
+ * with a mutex to protect the access of the list.
+ */
+struct drm_debugfs_files {
+ /** @list: List of debugfs files to be created by the DRM object. */
+ struct list_head list;
+
+ /** @mutex: Protects &list access. */
+ struct mutex mutex;
+};
+
/**
* struct drm_debugfs_info - debugfs info list entry
*
--
2.39.1
[PATCH v3 3/6] drm/debugfs: Create wrapper to add files to debugfs list
Create a helper to encapsulate the code that adds a new debugfs file to
a linked list related to a object. Moreover, the helper also provides
more flexibily, as the parameter is a struct drm_debugfs_files.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index aa83f230c402..0e3f3ffa9f88 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -236,6 +236,13 @@ void drm_debugfs_files_destroy(struct drm_debugfs_files
*debugfs_files)
kfree(debugfs_files);
}
+static void drm_debugfs_files_add(struct drm_debugfs_files *debugfs_files,
struct list_head *entry)
+{
+ mutex_lock(&debugfs_files->mutex);
+ list_add(entry, &debugfs_files->list);
+ mutex_unlock(&debugfs_files->mutex);
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
@@ -357,9 +364,7 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.data = data;
entry->dev = dev;
- mutex_lock(&dev->debugfs_files->mutex);
- list_add(&entry->list, &dev->debugfs_files->list);
- mutex_unlock(&dev->debugfs_files->mutex);
+ drm_debugfs_files_add(dev->debugfs_files, &entry->list);
}
EXPORT_SYMBOL(drm_debugfs_add_file);
--
2.39.1
[PATCH v3 4/6] drm/debugfs: Create wrapper to register debugfs
Create a helper to encapsulate the code that creates a new debugfs files
from a linked list related to an object. Moreover, the helper also
provides more flexibily on the type of the object.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 0e3f3ffa9f88..b4d2e7dd87f5 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -243,11 +243,21 @@ static void drm_debugfs_files_add(struct
drm_debugfs_files *debugfs_files, struc
mutex_unlock(&debugfs_files->mutex);
}
+static void drm_debugfs_register(struct drm_minor *minor, struct
drm_debugfs_files *debugfs_files)
+{
+ struct drm_debugfs_entry *entry, *tmp;
+
+ list_for_each_entry_safe(entry, tmp, &debugfs_files->list, list) {
+ debugfs_create_file(entry->file.name, 0444,
+ minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
+ list_del(&entry->list);
+ }
+}
+
int drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
- struct drm_debugfs_entry *entry, *tmp;
char name[64];
INIT_LIST_HEAD(&minor->debugfs_list);
@@ -270,11 +280,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_files->list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
- list_del(&entry->list);
- }
+ drm_debugfs_register(minor, dev->debugfs_files);
return 0;
}
@@ -282,16 +288,11 @@ int drm_debugfs_init(struct drm_minor *minor, int
minor_id,
void drm_debugfs_late_register(struct drm_device *dev)
{
struct drm_minor *minor = dev->primary;
- struct drm_debugfs_entry *entry, *tmp;
if (!minor)
return;
- list_for_each_entry_safe(entry, tmp, &dev->debugfs_files->list, list) {
- debugfs_create_file(entry->file.name, 0444,
- minor->debugfs_root, entry,
&drm_debugfs_entry_fops);
- list_del(&entry->list);
- }
+ drm_debugfs_register(minor, dev->debugfs_files);
}
int drm_debugfs_remove_files(const struct drm_info_list *files, int count,
--
2.39.1
[PATCH v3 5/6] drm/debugfs: Make the show callback pass the pointer to the right object
Currently, the drivers need to access the struct drm_debugfs_entry to
get the proper device on the show callback. There is no need for such
thing, as you can wrap the show callback in order to provide to the
driver the proper parameters: the struct seq_file, the struct drm_device
and the driver-specific data stored in the struct drm_debugfs_info.
Therefore, make the show callback pass the pointer to the right object
in the parameters, which makes the API more type-safe.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 ++--
drivers/gpu/drm/drm_atomic.c | 4 +---
drivers/gpu/drm/drm_client.c | 5 ++---
drivers/gpu/drm/drm_debugfs.c | 25 -
drivers/gpu/drm/drm_framebuffer.c | 4 +---
drivers/gpu/drm/drm_gem_vram_helper.c | 5 ++---
drivers/gpu/drm/gud/gud_drv.c | 5 ++---
drivers/gpu/drm/v3d/v3d_debugfs.c | 16
drivers/gpu/drm/vc4/vc4_bo.c | 4 +---
drivers/gpu/drm/vc4/vc4_debugfs.c | 6 ++
drivers/gpu/drm/vc4/vc4_hdmi.c| 6 ++
drivers/gpu/drm/vc4/vc4_hvs.c | 8 ++--
drivers/gpu/drm/vc4/vc4_v3d.c | 4 +---
drivers/gpu/drm/vkms/vkms_drv.c | 4 +---
include/drm/drm_debugfs.h | 14 --
15 files changed, 43 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
index e3507dd6f82a..b70bc7b11764 100644
--- a/drivers/gpu/drm/arm/hdlcd_drv.c
+++ b/drivers/gpu/drm/arm/hdlcd_drv.c
@@ -193,10 +193,8 @@ static int hdlcd_setup_mode_config(struct drm_device *drm)
}
#ifdef CONFIG_DEBUG_FS
-static int hdlcd_show_underrun_count(struct seq_file *m, void *arg)
+static int hdlcd_show_underrun_count(struct seq_file *m, struct drm_device
*drm, void *arg)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *drm = entry->dev;
struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
seq_printf(m, "underrun : %d\n",
atomic_read(&hdlcd->buffer_underrun_count));
@@ -206,10 +204,8 @@ static int hdlcd_show_underrun_count(struct seq_file *m,
void *arg)
return 0;
}
-static int hdlcd_show_pxlclock(struct seq_file *m, void *arg)
+static int hdlcd_show_pxlclock(struct seq_file *m, struct drm_device *drm,
void *arg)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *drm = entry->dev;
struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
unsigned long clkrate = clk_get_rate(hdlcd->clk);
unsigned long mode_clock = hdlcd->crtc.mode.crtc_clock * 1000;
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5457c02ca1ab..38f140481fcc 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1754,10 +1754,8 @@ void drm_state_dump(struct drm_device *dev, struct
drm_printer *p)
EXPORT_SYMBOL(drm_state_dump);
#ifdef CONFIG_DEBUG_FS
-static int drm_state_info(struct seq_file *m, void *data)
+static int drm_state_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
__drm_state_dump(dev, &p, true);
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 009e7b10455c..ec2e6bc3515d 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -488,10 +488,9 @@ int drm_client_framebuffer_flush(struct drm_client_buffer
*buffer, struct drm_re
EXPORT_SYMBOL(drm_client_framebuffer_flush);
#ifdef CONFIG_DEBUG_FS
-static int drm_client_debugfs_internal_clients(struct seq_file *m, void *data)
+static int drm_client_debugfs_internal_clients(struct seq_file *m, struct
drm_device *dev,
+ void *data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_printer p = drm_seq_file_printer(m);
struct drm_client_dev *client;
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b4d2e7dd87f5..21f01c7d0ab1 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -49,10 +49,8 @@
* Initialization, etc.
**/
-static int drm_name_info(struct seq_file *m, void *data)
+static int drm_name_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *entry = m->private;
- struct drm_device *dev = entry->dev;
struct drm_master *master;
mutex_lock(&dev->master_mutex);
@@ -70,10 +68,8 @@ static int drm_name_info(struct seq_file *m, void *data)
return 0;
}
-static int drm_clients_info(struct seq_file *m, void *data)
+static int drm_clients_info(struct seq_file *m, struct drm_device *dev, void
*data)
{
- struct drm_debugfs_entry *ent
[PATCH v3 6/6] drm/debugfs: Make the struct drm_debugfs_entry independent of DRM device
In order to turn the API more expansible to other DRM objects, such as
the struct drm_connector, make the struct drm_debugfs_entry hold a void
pointer and cast the void pointer to the struct drm_device when needed.
Signed-off-by: Maíra Canal
---
drivers/gpu/drm/drm_debugfs.c | 4 ++--
include/drm/drm_debugfs.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 21f01c7d0ab1..f12c3fdf61bb 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -141,7 +141,7 @@ static int drm_debugfs_dev_show(struct seq_file *m, void
*unused)
struct drm_debugfs_entry *entry = m->private;
int (*show)(struct seq_file *, struct drm_device *, void *) =
entry->file.show;
- return show(m, entry->dev, entry->file.data);
+ return show(m, entry->object, entry->file.data);
}
static int drm_debugfs_open(struct inode *inode, struct file *file)
@@ -362,7 +362,7 @@ void drm_debugfs_add_file(struct drm_device *dev, const
char *name,
entry->file.name = name;
entry->file.show = show;
entry->file.data = data;
- entry->dev = dev;
+ entry->object = dev;
drm_debugfs_files_add(dev->debugfs_files, &entry->list);
}
diff --git a/include/drm/drm_debugfs.h b/include/drm/drm_debugfs.h
index 0fb7ad5f6893..4ab0557f55e0 100644
--- a/include/drm/drm_debugfs.h
+++ b/include/drm/drm_debugfs.h
@@ -130,8 +130,8 @@ struct drm_debugfs_info {
* drm_debugfs_info on a &struct drm_device.
*/
struct drm_debugfs_entry {
- /** @dev: &struct drm_device for this node. */
- struct drm_device *dev;
+ /** @object: The DRM object that owns this node. */
+ void *object;
/** @file: Template for this node. */
struct drm_debugfs_info file;
--
2.39.1
[PATCH 0/2 v6] drm/mediatek: Add support for 10-bit overlays
This patch series adds support for 10-bit overlays to the Mediatek DRM driver. Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and lay the groundwork for supporting more 10-bit formats on more devices. 1. Refactor plane initialization logic to allow individual DDP components to provide their supported pixel formats. 2. Add AR30 and BA30 support to the MT8195 overlay driver. Version history: v6: * Refactor patch into patch series. * Add formats directly to private data. v5: * Removed some dead defines. * Refactored mtk_ovl_set_afbc(). v4: * Move modifier validation to format_mod_supported function. * Add modifiers to drm_universal_plane_init() call. * Make comparisons to DRM_FORMAT_MOD_LINEAR explicit rather than relying on DRM_FORMAT_LINEAR being equal to 0. * Gate AFBC control bit writes on device compatibility. v3: * Replaced pitch bitshift math with union based approach. * Refactored overlay register writes to shared code between non-AFBC and AFBC. * Minor code cleanups. v2: * Marked mtk_ovl_set_afbc as static. * Reflowed some lines to fit column limit. Justin Green (2): drm/mediatek: Refactor pixel format logic drm/mediatek: Add support for AR30 and BA30 overlays drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 + drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 89 + drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 + drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 + drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ++ drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +- 8 files changed, 168 insertions(+), 18 deletions(-) -- 2.39.1.456.gfc5497dd1b-goog
[PATCH 2/2] drm/mediatek: Add support for AR30 and BA30 overlays
Add support for overlays with pixel formats AR30 and BA30 on MT8195.
Tested using "modetest -P" on an MT8195 device.
Signed-off-by: Justin Green
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 49 -
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 8743c8047dc9..cd2f9a156456 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -41,6 +41,7 @@
#define DISP_REG_OVL_RDMA_CTRL(n) (0x00c0 + 0x20 * (n))
#define DISP_REG_OVL_RDMA_GMC(n) (0x00c8 + 0x20 * (n))
#define DISP_REG_OVL_ADDR_MT2701 0x0040
+#define DISP_REG_OVL_CLRFMT_EXT0x02D0
#define DISP_REG_OVL_ADDR_MT8173 0x0f40
#define DISP_REG_OVL_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n))
#define DISP_REG_OVL_HDR_ADDR(ovl, n) ((ovl)->data->addr + 0x20 * (n)
+ 0x04)
@@ -61,6 +62,10 @@
0 : OVL_CON_CLRFMT_RGB)
#define OVL_CON_CLRFMT_RGB888(ovl) ((ovl)->data->fmt_rgb565_is_0 ? \
OVL_CON_CLRFMT_RGB : 0)
+#define OVL_CON_CLRFMT_BIT_DEPTH_MASK(ovl) (0xFF << 4 * (ovl))
+#define OVL_CON_CLRFMT_BIT_DEPTH(depth, ovl) (depth << 4 * (ovl))
+#define OVL_CON_CLRFMT_8_BIT 0x00
+#define OVL_CON_CLRFMT_10_BIT 0x01
#defineOVL_CON_AEN BIT(8)
#defineOVL_CON_ALPHA 0xff
#defineOVL_CON_VIRT_FLIP BIT(9)
@@ -80,6 +85,22 @@ static const u32 mt8173_formats[] = {
DRM_FORMAT_YUYV,
};
+static const u32 mt8195_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ARGB2101010,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_BGRA1010102,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+};
+
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
@@ -218,6 +239,27 @@ static void mtk_ovl_set_afbc(struct mtk_disp_ovl *ovl,
struct cmdq_pkt *cmdq_pkt
DISP_REG_OVL_DATAPATH_CON, OVL_LAYER_AFBC_EN(idx));
}
+static void mtk_ovl_set_bit_depth(struct device *dev, int idx, u32 format,
+ struct cmdq_pkt *cmdq_pkt)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+ unsigned int reg;
+ unsigned int bit_depth = OVL_CON_CLRFMT_8_BIT;
+
+ reg = readl(ovl->regs + DISP_REG_OVL_CLRFMT_EXT);
+ reg &= ~OVL_CON_CLRFMT_BIT_DEPTH_MASK(idx);
+
+ if (format == DRM_FORMAT_RGBA1010102 ||
+ format == DRM_FORMAT_BGRA1010102 ||
+ format == DRM_FORMAT_ARGB2101010)
+ bit_depth = OVL_CON_CLRFMT_10_BIT;
+
+ reg |= OVL_CON_CLRFMT_BIT_DEPTH(bit_depth, idx);
+
+ mtk_ddp_write(cmdq_pkt, reg, &ovl->cmdq_reg,
+ ovl->regs, DISP_REG_OVL_CLRFMT_EXT);
+}
+
void mtk_ovl_config(struct device *dev, unsigned int w,
unsigned int h, unsigned int vrefresh,
unsigned int bpc, struct cmdq_pkt *cmdq_pkt)
@@ -332,9 +374,11 @@ static unsigned int ovl_fmt_convert(struct mtk_disp_ovl
*ovl, unsigned int fmt)
return OVL_CON_CLRFMT_ARGB;
case DRM_FORMAT_BGRX:
case DRM_FORMAT_BGRA:
+ case DRM_FORMAT_BGRA1010102:
return OVL_CON_CLRFMT_ARGB | OVL_CON_BYTE_SWAP;
case DRM_FORMAT_XRGB:
case DRM_FORMAT_ARGB:
+ case DRM_FORMAT_ARGB2101010:
return OVL_CON_CLRFMT_RGBA;
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
@@ -418,6 +462,7 @@ void mtk_ovl_layer_config(struct device *dev, unsigned int
idx,
&ovl->cmdq_reg, ovl->regs,
DISP_REG_OVL_PITCH_MSB(idx));
}
+ mtk_ovl_set_bit_depth(dev, idx, fmt, cmdq_pkt);
mtk_ovl_layer_on(dev, idx, cmdq_pkt);
}
@@ -583,8 +628,8 @@ static const struct mtk_disp_ovl_data
mt8195_ovl_driver_data = {
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
.supports_afbc = true,
- .formats = mt8173_formats,
- .num_formats = ARRAY_SIZE(mt8173_formats),
+ .formats = mt8195_formats,
+ .num_formats = ARRAY_SIZE(mt8195_formats),
};
static const struct of_device_id mtk_disp_ovl_driver_dt_match[] = {
--
2.39.1.456.gfc5497dd1b-goog
[PATCH 1/2] drm/mediatek: Refactor pixel format logic
Add an DDP component interface for querying pixel format support and move list
of supported pixel formats into DDP components instead of mtk_drm_plane.c
Tested by running Chrome on an MT8195.
Signed-off-by: Justin Green
edit1
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 ++
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 44 +
drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 ++
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ---
drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +-
8 files changed, 123 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
index 33e61a136bbc..0df6a06defb8 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_disp_drv.h
@@ -96,6 +96,8 @@ void mtk_ovl_register_vblank_cb(struct device *dev,
void mtk_ovl_unregister_vblank_cb(struct device *dev);
void mtk_ovl_enable_vblank(struct device *dev);
void mtk_ovl_disable_vblank(struct device *dev);
+const u32 *mtk_ovl_get_formats(struct device *dev);
+size_t mtk_ovl_get_num_formats(struct device *dev);
void mtk_rdma_bypass_shadow(struct device *dev);
int mtk_rdma_clk_enable(struct device *dev);
@@ -115,6 +117,8 @@ void mtk_rdma_register_vblank_cb(struct device *dev,
void mtk_rdma_unregister_vblank_cb(struct device *dev);
void mtk_rdma_enable_vblank(struct device *dev);
void mtk_rdma_disable_vblank(struct device *dev);
+const u32 *mtk_rdma_get_formats(struct device *dev);
+size_t mtk_rdma_get_num_formats(struct device *dev);
int mtk_mdp_rdma_clk_enable(struct device *dev);
void mtk_mdp_rdma_clk_disable(struct device *dev);
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
index 84daeaffab6a..8743c8047dc9 100644
--- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
+++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
@@ -66,6 +66,20 @@
#defineOVL_CON_VIRT_FLIP BIT(9)
#defineOVL_CON_HORZ_FLIP BIT(10)
+static const u32 mt8173_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_BGRX,
+ DRM_FORMAT_BGRA,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_BGR888,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_YUYV,
+};
+
struct mtk_disp_ovl_data {
unsigned int addr;
unsigned int gmc_bits;
@@ -73,6 +87,8 @@ struct mtk_disp_ovl_data {
bool fmt_rgb565_is_0;
bool smi_id_en;
bool supports_afbc;
+ const u32 *formats;
+ size_t num_formats;
};
/*
@@ -138,6 +154,20 @@ void mtk_ovl_disable_vblank(struct device *dev)
writel_relaxed(0x0, ovl->regs + DISP_REG_OVL_INTEN);
}
+const u32 *mtk_ovl_get_formats(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ return ovl->data->formats;
+}
+
+size_t mtk_ovl_get_num_formats(struct device *dev)
+{
+ struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
+
+ return ovl->data->num_formats;
+}
+
int mtk_ovl_clk_enable(struct device *dev)
{
struct mtk_disp_ovl *ovl = dev_get_drvdata(dev);
@@ -495,6 +525,8 @@ static const struct mtk_disp_ovl_data
mt2701_ovl_driver_data = {
.gmc_bits = 8,
.layer_nr = 4,
.fmt_rgb565_is_0 = false,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
@@ -502,6 +534,8 @@ static const struct mtk_disp_ovl_data
mt8173_ovl_driver_data = {
.gmc_bits = 8,
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
@@ -509,6 +543,8 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_driver_data = {
.gmc_bits = 10,
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
@@ -516,6 +552,8 @@ static const struct mtk_disp_ovl_data
mt8183_ovl_2l_driver_data = {
.gmc_bits = 10,
.layer_nr = 2,
.fmt_rgb565_is_0 = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
@@ -524,6 +562,8 @@ static const struct mtk_disp_ovl_data
mt8192_ovl_driver_data = {
.layer_nr = 4,
.fmt_rgb565_is_0 = true,
.smi_id_en = true,
+ .formats = mt8173_formats,
+ .num_formats = ARRAY_SIZE(mt8173_formats),
};
static const struct mtk_disp_ovl_data mt8192_ovl
Re: [PATCH 0/2 v6] drm/mediatek: Add support for 10-bit overlays
My apologies, I accidentally mangled the version history. It should actually read: v2: * Rebase and resolve merge conflicts with the AFBC patch. v3: * Moved 10-bit support detection to mtk_disk_ovl.c v4: * Moved formats to mtk_disp_ovl.c and mtk_disp_rdma.c v5: * Minor style adjustments per checkpatch.pl v6: * Refactor patch into patch series. * Add formats directly to private data. On Tue, Jan 31, 2023 at 3:08 PM Justin Green wrote: > > This patch series adds support for 10-bit overlays to the Mediatek DRM driver. > Specifically, we add support for AR30 and BA30 overlays on MT8195 devices and > lay the groundwork for supporting more 10-bit formats on more devices. > > 1. Refactor plane initialization logic to allow individual DDP components to > provide their supported pixel formats. > > 2. Add AR30 and BA30 support to the MT8195 overlay driver. > > > Version history: > v6: > * Refactor patch into patch series. > * Add formats directly to private data. > > v5: > * Removed some dead defines. > * Refactored mtk_ovl_set_afbc(). > > v4: > * Move modifier validation to format_mod_supported function. > * Add modifiers to drm_universal_plane_init() call. > * Make comparisons to DRM_FORMAT_MOD_LINEAR explicit rather than relying on > DRM_FORMAT_LINEAR being equal to 0. > * Gate AFBC control bit writes on device compatibility. > > v3: > * Replaced pitch bitshift math with union based approach. > * Refactored overlay register writes to shared code between non-AFBC and > AFBC. > * Minor code cleanups. > > v2: > * Marked mtk_ovl_set_afbc as static. > * Reflowed some lines to fit column limit. > > > Justin Green (2): > drm/mediatek: Refactor pixel format logic > drm/mediatek: Add support for AR30 and BA30 overlays > > drivers/gpu/drm/mediatek/mtk_disp_drv.h | 4 + > drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 89 + > drivers/gpu/drm/mediatek/mtk_disp_rdma.c| 38 + > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 4 + > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 20 + > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 24 ++ > drivers/gpu/drm/mediatek/mtk_drm_plane.h| 3 +- > 8 files changed, 168 insertions(+), 18 deletions(-) > > -- > 2.39.1.456.gfc5497dd1b-goog >
Re: [PATCH AUTOSEL 5.15 12/12] amdgpu: fix build on non-DCN platforms.
On Tue, Jan 31, 2023 at 10:01 AM Sasha Levin wrote: > > From: Dave Airlie > > [ Upstream commit f439a959dcfb6b39d6fd4b85ca1110a1d1de1587 ] > > This fixes the build here locally on my 32-bit arm build. > > Signed-off-by: Dave Airlie > Signed-off-by: Sasha Levin This patch is only applicable to kernel 6.1 and newer. Alex > --- > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index ee238a16572e..0f0dd9b0d84a 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -10769,6 +10769,8 @@ static int amdgpu_dm_atomic_check(struct drm_device > *dev, > bool lock_and_validation_needed = false; > struct dm_crtc_state *dm_old_crtc_state; > #if defined(CONFIG_DRM_AMD_DC_DCN) > + struct drm_dp_mst_topology_mgr *mgr; > + struct drm_dp_mst_topology_state *mst_state; > struct dsc_mst_fairness_vars vars[MAX_PIPES]; > #endif > > -- > 2.39.0 >
Re: [PATCH] dma-buf: Add "dma-buf" to title of documentation
Jonathan Neuschäfer writes: > To make it easier to find the dma-buf documentation when looking through > tables-of-contents etc., put the name "dma-buf" in the title. > > Signed-off-by: Jonathan Neuschäfer > --- > Documentation/driver-api/dma-buf.rst | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/driver-api/dma-buf.rst > b/Documentation/driver-api/dma-buf.rst > index 622b8156d2127..61b6f42ed0f18 100644 > --- a/Documentation/driver-api/dma-buf.rst > +++ b/Documentation/driver-api/dma-buf.rst > @@ -1,5 +1,5 @@ > -Buffer Sharing and Synchronization > -== > +Buffer Sharing and Synchronization (dma-buf) > + Applied, thanks. jon
Re: [PATCH] drm/panel: boe-tv101wum-nl6: Ensure DSI writes succeed during disable
Hi,
On Thu, Jan 26, 2023 at 4:52 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 18, 2023 at 1:34 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Thu, Jan 5, 2023 at 7:01 PM Stephen Boyd wrote:
> > >
> > > The unprepare sequence has started to fail after moving to panel bridge
> > > code in the msm drm driver (commit 007ac0262b0d ("drm/msm/dsi: switch to
> > > DRM_PANEL_BRIDGE")). You'll see messages like this in the kernel logs:
> > >
> > >panel-boe-tv101wum-nl6 ae94000.dsi.0: failed to set panel off: -22
> > >
> > > This is because boe_panel_enter_sleep_mode() needs an operating DSI link
> > > to set the panel into sleep mode. Performing those writes in the
> > > unprepare phase of bridge ops is too late, because the link has already
> > > been torn down by the DSI controller in post_disable, i.e. the PHY has
> > > been disabled, etc. See dsi_mgr_bridge_post_disable() for more details
> > > on the DSI .
> > >
> > > Split the unprepare function into a disable part and an unprepare part.
> > > For now, just the DSI writes to enter sleep mode are put in the disable
> > > function. This fixes the panel off routine and keeps the panel happy.
> > >
> > > My Wormdingler has an integrated touchscreen that stops responding to
> > > touch if the panel is only half disabled too. This patch fixes it. And
> > > finally, this saves power when the screen is off because without this
> > > fix the regulators for the panel are left enabled when nothing is being
> > > displayed on the screen.
> > >
> > > Fixes: 007ac0262b0d ("drm/msm/dsi: switch to DRM_PANEL_BRIDGE")
> > > Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi
> > > video mode panel")
> > > Cc: yangcong
> > > Cc: Douglas Anderson
> > > Cc: Jitao Shi
> > > Cc: Sam Ravnborg
> > > Cc: Rob Clark
> > > Cc: Dmitry Baryshkov
> > > Signed-off-by: Stephen Boyd
> > > ---
> > > drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c | 16
> > > 1 file changed, 12 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > index 857a2f0420d7..c924f1124ebc 100644
> > > --- a/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > +++ b/drivers/gpu/drm/panel/panel-boe-tv101wum-nl6.c
> > > @@ -1193,14 +1193,11 @@ static int boe_panel_enter_sleep_mode(struct
> > > boe_panel *boe)
> > > return 0;
> > > }
> > >
> > > -static int boe_panel_unprepare(struct drm_panel *panel)
> > > +static int boe_panel_disable(struct drm_panel *panel)
> > > {
> > > struct boe_panel *boe = to_boe_panel(panel);
> > > int ret;
> > >
> > > - if (!boe->prepared)
> > > - return 0;
> > > -
> > > ret = boe_panel_enter_sleep_mode(boe);
> > > if (ret < 0) {
> > > dev_err(panel->dev, "failed to set panel off: %d\n", ret);
> > > @@ -1209,6 +1206,16 @@ static int boe_panel_unprepare(struct drm_panel
> > > *panel)
> > >
> > > msleep(150);
> > >
> > > + return 0;
> > > +}
> > > +
> > > +static int boe_panel_unprepare(struct drm_panel *panel)
> > > +{
> > > + struct boe_panel *boe = to_boe_panel(panel);
> > > +
> > > + if (!boe->prepared)
> > > + return 0;
> > > +
> > > if (boe->desc->discharge_on_disable) {
> > > regulator_disable(boe->avee);
> > > regulator_disable(boe->avdd);
> > > @@ -1528,6 +1535,7 @@ static enum drm_panel_orientation
> > > boe_panel_get_orientation(struct drm_panel *pa
> > > }
> > >
> > > static const struct drm_panel_funcs boe_panel_funcs = {
> > > + .disable = boe_panel_disable,
> > > .unprepare = boe_panel_unprepare,
> > > .prepare = boe_panel_prepare,
> > > .enable = boe_panel_enable,
> >
> > As mentioned by Stephen, my initial reaction was that this felt
> > asymmetric. We were moving some stuff from unprepare() to disable()
> > and it felt like that would mean we would also need to move something
> > from prepare() to enable. Initially I thought maybe that "something"
> > was all of boe_panel_init_dcs_cmd() but I guess that didn't work.
> >
> > I don't truly have a reason that this _has_ to be symmetric. I was
> > initially worried that there might be some place where we call
> > pre_enable(), then never call enable() / disable(), and then call
> > post_disable(). That could have us in a bad state because we'd never
> > enter sleep mode / turn the display off. However (as I think I've
> > discovered before and just forgot), I don't think this is possible
> > because we always call pre-enable() and enable() together. Also, as
> > mentioned by Sam, we're about to fully shut the panel's power off so
> > (unless it's on a shared rail) it probably doesn't really matter.
> >
> > Thus, I'd be OK with:
> >
> > Reviewed-by: Douglas Anderson
> >
> > I'm also happy to land this (adding Cc: stable) to drm-misc-fixes if
> > nobody has any objections (also happy i
[PATCH] drm/i915/guc: Improve debug message on context reset notification
Just recently we switched over to new GuC oriented log macros but in
the meantime yet another message was added that we missed to update.
While around improve that new message by adding engine name and use
existing helpers to check for context state.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 53f3ed3244d5..be495e657d66 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -4660,9 +4660,10 @@ static void guc_handle_context_reset(struct intel_guc
*guc,
{
trace_intel_context_reset(ce);
- drm_dbg(&guc_to_gt(guc)->i915->drm, "Got GuC reset of 0x%04X, exiting =
%d, banned = %d\n",
- ce->guc_id.id, test_bit(CONTEXT_EXITING, &ce->flags),
- test_bit(CONTEXT_BANNED, &ce->flags));
+ guc_dbg(guc, "Got context reset notification: 0x%04X on %s, exiting =
%s, banned = %s\n",
+ ce->guc_id.id, ce->engine->name,
+ str_yes_no(intel_context_is_exiting(ce)),
+ str_yes_no(intel_context_is_banned(ce)));
if (likely(intel_context_is_schedulable(ce))) {
capture_error_state(guc, ce);
--
2.25.1
[RFT PATCH v2 1/3] drm/bridge: tc358762: Set pre_enable_prev_first
Set the "pre_enable_prev_first" as provided by commit 4fb912e5e190
("drm/bridge: Introduce pre_enable_prev_first to alter bridge init
order"). This should allow us to revert commit ec7981e6c614
("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") and
commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time").
Cc: Dave Stevenson
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Signed-off-by: Douglas Anderson
---
(no changes since v1)
drivers/gpu/drm/bridge/tc358762.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/tc358762.c
b/drivers/gpu/drm/bridge/tc358762.c
index 0b6a28436885..77f7f7f54757 100644
--- a/drivers/gpu/drm/bridge/tc358762.c
+++ b/drivers/gpu/drm/bridge/tc358762.c
@@ -229,6 +229,7 @@ static int tc358762_probe(struct mipi_dsi_device *dsi)
ctx->bridge.funcs = &tc358762_bridge_funcs;
ctx->bridge.type = DRM_MODE_CONNECTOR_DPI;
ctx->bridge.of_node = dev->of_node;
+ ctx->bridge.pre_enable_prev_first = true;
drm_bridge_add(&ctx->bridge);
--
2.39.1.456.gfc5497dd1b-goog
[RFT PATCH v2 3/3] drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on()
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time") the error handling with regards to dsi_mgr_bridge_power_on()
got a bit worse. Specifically if we failed to power the bridge on then
nothing would really notice. The modeset function couldn't return an
error and thus we'd blindly go forward and try to do the pre-enable.
In commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time
for parade-ps8640") we added a special case to move the powerup back
to pre-enable time for ps8640. When we did that, we didn't try to
recover the old/better error handling just for ps8640.
In the patch ("drm/msm/dsi: Stop unconditionally powering up DSI hosts
at modeset") we've now moved the powering up back to exclusively being
during pre-enable. That means we can add the better error handling
back in, so let's do it. To do so we'll add a new function
dsi_mgr_bridge_power_off() that's matches how errors were handled
prior to commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to
modeset time").
NOTE: Now that we have dsi_mgr_bridge_power_off(), it feels as if we
should be calling it in dsi_mgr_bridge_post_disable(). That would make
some sense, but doing so would change the current behavior and thus
should be a separate patch. Specifically:
* dsi_mgr_bridge_post_disable() always calls dsi_mgr_phy_disable()
even in the slave-DSI case of bonded DSI. We'd need to add special
handling for this if it's truly needed.
* dsi_mgr_bridge_post_disable() calls msm_dsi_phy_pll_save_state()
midway through the poweroff.
* dsi_mgr_bridge_post_disable() has a different order of some of the
poweroffs / IRQ disables.
For now we'll leave dsi_mgr_bridge_post_disable() alone.
Signed-off-by: Douglas Anderson
---
Changes in v2:
- ("More properly handle errors...") new for v2.
drivers/gpu/drm/msm/dsi/dsi_manager.c | 32 ++-
1 file changed, 26 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 2197a54b9b96..28b8012a21f2 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -228,7 +228,7 @@ static void msm_dsi_manager_set_split_display(u8 id)
}
}
-static void dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
+static int dsi_mgr_bridge_power_on(struct drm_bridge *bridge)
{
int id = dsi_mgr_bridge_get_id(bridge);
struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
@@ -268,14 +268,31 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge
*bridge)
if (is_bonded_dsi && msm_dsi1)
msm_dsi_host_enable_irq(msm_dsi1->host);
- return;
+ return 0;
host1_on_fail:
msm_dsi_host_power_off(host);
host_on_fail:
dsi_mgr_phy_disable(id);
phy_en_fail:
- return;
+ return ret;
+}
+
+static void dsi_mgr_bridge_power_off(struct drm_bridge *bridge)
+{
+ int id = dsi_mgr_bridge_get_id(bridge);
+ struct msm_dsi *msm_dsi = dsi_mgr_get_dsi(id);
+ struct msm_dsi *msm_dsi1 = dsi_mgr_get_dsi(DSI_1);
+ struct mipi_dsi_host *host = msm_dsi->host;
+ bool is_bonded_dsi = IS_BONDED_DSI();
+
+ msm_dsi_host_disable_irq(host);
+ if (is_bonded_dsi && msm_dsi1) {
+ msm_dsi_host_disable_irq(msm_dsi1->host);
+ msm_dsi_host_power_off(msm_dsi1->host);
+ }
+ msm_dsi_host_power_off(host);
+ dsi_mgr_phy_disable(id);
}
static void dsi_mgr_bridge_pre_enable(struct drm_bridge *bridge)
@@ -295,7 +312,11 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
- dsi_mgr_bridge_power_on(bridge);
+ ret = dsi_mgr_bridge_power_on(bridge);
+ if (ret) {
+ dev_err(&msm_dsi->pdev->dev, "Power on failed: %d\n", ret);
+ return;
+ }
ret = msm_dsi_host_enable(host);
if (ret) {
@@ -316,8 +337,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
host1_en_fail:
msm_dsi_host_disable(host);
host_en_fail:
-
- return;
+ dsi_mgr_bridge_power_off(bridge);
}
void msm_dsi_manager_tpg_enable(void)
--
2.39.1.456.gfc5497dd1b-goog
[RFT PATCH v2 2/3] drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset
time"), we moved powering up DSI hosts to modeset time. This wasn't
because it was an elegant design, but there were no better options.
That commit actually ended up breaking ps8640, and thus was born
commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for
parade-ps8640") as a temporary hack to un-break ps8640 by moving it to
the old way of doing things. It turns out that ps8640 _really_ doesn't
like its pre_enable() function to be called after
dsi_mgr_bridge_power_on(). Specifically (from experimentation, not
because I have any inside knowledge), it looks like the assertion of
"RST#" in the ps8640 runtime resume handler seems like it's not
allowed to happen after dsi_mgr_bridge_power_on()
Recently, Dave Stevenson's series landed allowing bridges some control
over pre_enable ordering. The meaty commit for our purposes is commit
4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter
bridge init order"). As documented by that series, if a bridge doesn't
set "pre_enable_prev_first" then we should use the old ordering.
Now that we have the commit ("drm/bridge: tc358762: Set
pre_enable_prev_first") we can go back to the old ordering, which also
allows us to remove the ps8640 special case.
One last note is that even without reverting commit 7d8e9a90509f
("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_
revert the ps8640 special case and try it out then it doesn't seem to
fail anymore. I spent time bisecting / debugging this and it turns out
to be mostly luck, so we still want this patch to make sure it's
solid. Specifically the reason it sorta works these days is because
we implemented wait_hpd_asserted() in ps8640 now, plus the magic of
"pm_runtime" autosuspend. The fact that we have wait_hpd_asserted()
implemented means that we actually power the bridge chip up just a wee
bit earlier and then the bridge happens to stay on because of
autosuspend and thus ends up powered before dsi_mgr_bridge_power_on().
Cc: Dave Stevenson
Cc: Dmitry Baryshkov
Cc: Abhinav Kumar
Signed-off-by: Douglas Anderson
---
Changes in v2:
- Don't fold dsi_mgr_bridge_power_on() back into dsi_mgr_bridge_pre_enable()
drivers/gpu/drm/msm/dsi/dsi_manager.c | 38 +--
1 file changed, 1 insertion(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 1bbac72dad35..2197a54b9b96 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -34,32 +34,6 @@ static struct msm_dsi_manager msm_dsim_glb;
#define IS_SYNC_NEEDED() (msm_dsim_glb.is_sync_needed)
#define IS_MASTER_DSI_LINK(id) (msm_dsim_glb.master_dsi_link_id == id)
-#ifdef CONFIG_OF
-static bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge);
-
- /*
-* If the next bridge in the chain is the Parade ps8640 bridge chip
-* then don't power on early since it seems to violate the expectations
-* of the firmware that the bridge chip is running.
-*
-* NOTE: this is expected to be a temporary special case. It's expected
-* that we'll eventually have a framework that allows the next level
-* bridge to indicate whether it needs us to power on before it or
-* after it. When that framework is in place then we'll use it and
-* remove this special case.
-*/
- return !(next_bridge && next_bridge->of_node &&
-of_device_is_compatible(next_bridge->of_node,
"parade,ps8640"));
-}
-#else
-static inline bool dsi_mgr_power_on_early(struct drm_bridge *bridge)
-{
- return true;
-}
-#endif
-
static inline struct msm_dsi *dsi_mgr_get_dsi(int id)
{
return msm_dsim_glb.dsi[id];
@@ -265,12 +239,6 @@ static void dsi_mgr_bridge_power_on(struct drm_bridge
*bridge)
int ret;
DBG("id=%d", id);
- if (!msm_dsi_device_connected(msm_dsi))
- return;
-
- /* Do nothing with the host if it is slave-DSI in case of bonded DSI */
- if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
- return;
ret = dsi_mgr_phy_enable(id, phy_shared_timings);
if (ret)
@@ -327,8 +295,7 @@ static void dsi_mgr_bridge_pre_enable(struct drm_bridge
*bridge)
if (is_bonded_dsi && !IS_MASTER_DSI_LINK(id))
return;
- if (!dsi_mgr_power_on_early(bridge))
- dsi_mgr_bridge_power_on(bridge);
+ dsi_mgr_bridge_power_on(bridge);
ret = msm_dsi_host_enable(host);
if (ret) {
@@ -438,9 +405,6 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge
*bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_bonded_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
-
- if (dsi_mgr_power_on_early(br
[PATCH] drm/i915/huc: Add and use HuC oriented print macros
Like we did it for GuC, introduce some helper print macros for
HuC to have unified format of messages that also include GT#.
While around improve some messages and use %pe if possible.
Signed-off-by: Michal Wajdeczko
Cc: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 ++
1 file changed, 23 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
index 410905da8e97..834e3b5b8f4b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
@@ -6,6 +6,7 @@
#include
#include "gt/intel_gt.h"
+#include "gt/intel_gt_print.h"
#include "intel_guc_reg.h"
#include "intel_huc.h"
#include "i915_drv.h"
@@ -13,6 +14,15 @@
#include
#include
+#define huc_printk(_huc, _level, _fmt, ...) \
+ gt_##_level(huc_to_gt(_huc), "HuC: " _fmt, ##__VA_ARGS__)
+#define huc_err(_huc, _fmt, ...) huc_printk((_huc), err, _fmt,
##__VA_ARGS__)
+#define huc_warn(_huc, _fmt, ...) huc_printk((_huc), warn, _fmt,
##__VA_ARGS__)
+#define huc_notice(_huc, _fmt, ...)huc_printk((_huc), notice, _fmt,
##__VA_ARGS__)
+#define huc_info(_huc, _fmt, ...) huc_printk((_huc), info, _fmt,
##__VA_ARGS__)
+#define huc_dbg(_huc, _fmt, ...) huc_printk((_huc), dbg, _fmt,
##__VA_ARGS__)
+#define huc_probe_error(_huc, _fmt, ...) huc_printk((_huc), probe_error, _fmt,
##__VA_ARGS__)
+
/**
* DOC: HuC
*
@@ -107,11 +117,9 @@ static enum hrtimer_restart
huc_delayed_load_timer_callback(struct hrtimer *hrti
if (!intel_huc_is_authenticated(huc)) {
if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_GSC)
- drm_notice(&huc_to_gt(huc)->i915->drm,
- "timed out waiting for MEI GSC init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI GSC\n");
else if (huc->delayed_load.status == INTEL_HUC_WAITING_ON_PXP)
- drm_notice(&huc_to_gt(huc)->i915->drm,
- "timed out waiting for MEI PXP init to load
HuC\n");
+ huc_notice(huc, "load timed out waiting for MEI PXP\n");
else
MISSING_CASE(huc->delayed_load.status);
@@ -174,8 +182,7 @@ static int gsc_notifier(struct notifier_block *nb, unsigned
long action, void *d
case BUS_NOTIFY_DRIVER_NOT_BOUND: /* mei driver fails to be bound */
case BUS_NOTIFY_UNBIND_DRIVER: /* mei driver about to be unbound */
- drm_info(&huc_to_gt(huc)->i915->drm,
-"mei driver not bound, disabling HuC load\n");
+ huc_info(huc, "MEI driver not bound, disabling load\n");
gsc_init_error(huc);
break;
}
@@ -193,8 +200,7 @@ void intel_huc_register_gsc_notifier(struct intel_huc *huc,
struct bus_type *bus
huc->delayed_load.nb.notifier_call = gsc_notifier;
ret = bus_register_notifier(bus, &huc->delayed_load.nb);
if (ret) {
- drm_err(&huc_to_gt(huc)->i915->drm,
- "failed to register GSC notifier\n");
+ huc_err(huc, "failed to register GSC notifier %pe\n",
ERR_PTR(ret));
huc->delayed_load.nb.notifier_call = NULL;
gsc_init_error(huc);
}
@@ -306,29 +312,25 @@ static int check_huc_loading_mode(struct intel_huc *huc)
GSC_LOADS_HUC;
if (fw_needs_gsc != hw_uses_gsc) {
- drm_err(>->i915->drm,
- "mismatch between HuC FW (%s) and HW (%s) load modes\n",
- HUC_LOAD_MODE_STRING(fw_needs_gsc),
- HUC_LOAD_MODE_STRING(hw_uses_gsc));
+ huc_err(huc, "mismatch between FW (%s) and HW (%s) load
modes\n",
+ HUC_LOAD_MODE_STRING(fw_needs_gsc),
HUC_LOAD_MODE_STRING(hw_uses_gsc));
return -ENOEXEC;
}
/* make sure we can access the GSC via the mei driver if we need it */
if (!(IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_INTEL_MEI_GSC)) &&
fw_needs_gsc) {
- drm_info(>->i915->drm,
-"Can't load HuC due to missing MEI modules\n");
+ huc_info(huc, "can't load due to missing MEI modules\n");
return -EIO;
}
- drm_dbg(>->i915->drm, "GSC loads huc=%s\n", str_yes_no(fw_needs_gsc));
+ huc_dbg(huc, "loaded by GSC = %s\n", str_yes_no(fw_needs_gsc));
return 0;
}
int intel_huc_init(struct intel_huc *huc)
{
- struct drm_i915_private *i915 = huc_to_gt(huc)->i915;
int err;
err = check_huc_loading_mode(huc);
@@ -345,7 +347,7 @@ int intel_huc_init(struct intel_huc *huc)
out:
intel_uc_fw_change_status(&huc->fw, INTEL_UC_FIRMWARE_INIT_FAIL);
- drm_info(&i915->drm, "HuC init failed with %d\n
[PATCH 1/2] backlight: hx8357: switch to using gpiod API
Switch the driver from legacy gpio API that is deprecated to the newer
gpiod API that respects line polarities described in ACPI/DT.
This makes driver use standard property name for the reset gpio
("reset-gpios" vs "gpios-reset"), however there is a quirk in gpiolib
to also recognize the legacy name and keep compatibility with older
DTSes.
Signed-off-by: Dmitry Torokhov
---
All preparation gpiolib work to handle legacy names and polarity quirks
has landed in mainline...
drivers/video/backlight/hx8357.c | 82 ++--
1 file changed, 37 insertions(+), 45 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index 9b50bc96e00f..a93e14adb846 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -6,11 +6,12 @@
*/
#include
+#include
+#include
#include
#include
#include
#include
-#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -83,8 +84,8 @@
#define HX8369_SET_GAMMA_CURVE_RELATED 0xe0
struct hx8357_data {
- unsignedim_pins[HX8357_NUM_IM_PINS];
- unsignedreset;
+ struct gpio_desc*im_pins[HX8357_NUM_IM_PINS];
+ struct gpio_desc*reset;
struct spi_device *spi;
int state;
booluse_im_pins;
@@ -321,11 +322,11 @@ static void hx8357_lcd_reset(struct lcd_device *lcdev)
struct hx8357_data *lcd = lcd_get_data(lcdev);
/* Reset the screen */
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 0);
+ gpiod_set_value_cansleep(lcd->reset, 1);
usleep_range(1, 12000);
- gpio_set_value(lcd->reset, 1);
+ gpiod_set_value_cansleep(lcd->reset, 0);
/* The controller needs 120ms to recover from reset */
msleep(120);
@@ -341,9 +342,9 @@ static int hx8357_lcd_init(struct lcd_device *lcdev)
* wires
*/
if (lcd->use_im_pins) {
- gpio_set_value_cansleep(lcd->im_pins[0], 1);
- gpio_set_value_cansleep(lcd->im_pins[1], 0);
- gpio_set_value_cansleep(lcd->im_pins[2], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[0], 1);
+ gpiod_set_value_cansleep(lcd->im_pins[1], 0);
+ gpiod_set_value_cansleep(lcd->im_pins[2], 1);
}
ret = hx8357_spi_write_array(lcdev, hx8357_seq_power,
@@ -601,48 +602,39 @@ static int hx8357_probe(struct spi_device *spi)
if (!match || !match->data)
return -EINVAL;
- lcd->reset = of_get_named_gpio(spi->dev.of_node, "gpios-reset", 0);
- if (!gpio_is_valid(lcd->reset)) {
- dev_err(&spi->dev, "Missing dt property: gpios-reset\n");
- return -EINVAL;
- }
-
- ret = devm_gpio_request_one(&spi->dev, lcd->reset,
- GPIOF_OUT_INIT_HIGH,
- "hx8357-reset");
+ lcd->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
- dev_err(&spi->dev,
- "failed to request gpio %d: %d\n",
- lcd->reset, ret);
- return -EINVAL;
+ dev_err(&spi->dev, "failed to request reset gpio: %d\n", ret);
+ return ret;
}
- if (of_find_property(spi->dev.of_node, "im-gpios", NULL)) {
- lcd->use_im_pins = 1;
-
- for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
- lcd->im_pins[i] = of_get_named_gpio(spi->dev.of_node,
- "im-gpios", i);
- if (lcd->im_pins[i] == -EPROBE_DEFER) {
- dev_info(&spi->dev, "GPIO requested is not here
yet, deferring the probe\n");
- return -EPROBE_DEFER;
- }
- if (!gpio_is_valid(lcd->im_pins[i])) {
- dev_err(&spi->dev, "Missing dt property:
im-gpios\n");
- return -EINVAL;
+ gpiod_set_consumer_name(lcd->reset, "hx8357-reset");
+
+ for (i = 0; i < HX8357_NUM_IM_PINS; i++) {
+ lcd->im_pins[i] = devm_gpiod_get_index(&spi->dev,
+ "im", i, GPIOD_OUT_LOW);
+ ret = PTR_ERR_OR_ZERO(lcd->im_pins[i]);
+ if (ret) {
+ if (ret == -ENOENT) {
+ if (i == 0)
+ break;
+ dev_err(&spi->dev, "Missing im gpios[%d]\n", i);
+ ret = -EINVAL;
+ } if (ret == -EPROBE_DEFER) {
+ dev_info(&spi->dev
[PATCH 2/2] backlight: hx8357: stop using of-specific APIs
There is no need for this driver to be OF-specific, so switch it to
use device_get_match_data() and stop including various of-related
headers.
Signed-off-by: Dmitry Torokhov
---
drivers/video/backlight/hx8357.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/video/backlight/hx8357.c b/drivers/video/backlight/hx8357.c
index a93e14adb846..2e162a70c1ce 100644
--- a/drivers/video/backlight/hx8357.c
+++ b/drivers/video/backlight/hx8357.c
@@ -10,8 +10,8 @@
#include
#include
#include
-#include
-#include
+#include
+#include
#include
#define HX8357_NUM_IM_PINS 3
@@ -581,11 +581,15 @@ MODULE_DEVICE_TABLE(of, hx8357_dt_ids);
static int hx8357_probe(struct spi_device *spi)
{
+ int (*lcd_init_fn)(struct lcd_device *);
struct lcd_device *lcdev;
struct hx8357_data *lcd;
- const struct of_device_id *match;
int i, ret;
+ lcd_init_fn = device_get_match_data(&spi->dev);
+ if (!lcd_init_fn)
+ return -EINVAL;
+
lcd = devm_kzalloc(&spi->dev, sizeof(*lcd), GFP_KERNEL);
if (!lcd)
return -ENOMEM;
@@ -598,10 +602,6 @@ static int hx8357_probe(struct spi_device *spi)
lcd->spi = spi;
- match = of_match_device(hx8357_dt_ids, &spi->dev);
- if (!match || !match->data)
- return -EINVAL;
-
lcd->reset = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW);
ret = PTR_ERR_OR_ZERO(lcd->reset);
if (ret) {
@@ -647,7 +647,7 @@ static int hx8357_probe(struct spi_device *spi)
hx8357_lcd_reset(lcdev);
- ret = ((int (*)(struct lcd_device *))match->data)(lcdev);
+ ret = lcd_init_fn(lcdev);
if (ret) {
dev_err(&spi->dev, "Couldn't initialize panel\n");
return ret;
--
2.39.1.456.gfc5497dd1b-goog
Re: [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()
On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote:
> Atm, drm_dp_remove_payload() uses the same payload state to both get the
> vc_start_slot required for the payload removal DPCD message and to
> deduct time_slots from vc_start_slot of all payloads after the one being
> removed.
>
> The above isn't always correct, as vc_start_slot must be the up-to-date
> version contained in the new payload state, but time_slots must be the
> one used when the payload was previously added, contained in the old
> payload state. The new payload's time_slots can change vs. the old one
> if the current atomic commit changes the corresponding mode.
>
> This patch let's drivers pass the old and new payload states to
> drm_dp_remove_payload(), but keeps these the same for now in all drivers
> not to change the behavior. A follow-up i915 patch will pass in that
> driver the correct old and new states to the function.
Oh wow, this was definitely a mistake on my part, thanks for catching this!
TBH, I think this behavior is correct so (now that I actually have a setup
capable of testing amdgpu's MST fully thanks to gitlab issue 2171…) if you'd
like to change it on other drivers as well I can test it fully. Or feel free
to leave it to me, shouldn't be too difficult I think :).
For 0-2:
Reviewed-by: Lyude Paul
>
> Cc: Lyude Paul
> Cc: Ville Syrjälä
> Cc: Ben Skeggs
> Cc: Karol Herbst
> Cc: Harry Wentland
> Cc: Alex Deucher
> Cc: Wayne Lin
> Cc: sta...@vger.kernel.org # 6.1
> Cc: dri-devel@lists.freedesktop.org
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> .../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +-
> drivers/gpu/drm/display/drm_dp_mst_topology.c | 26 ++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 ++-
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
> include/drm/display/drm_dp_mst_helper.h | 3 ++-
> 5 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> index a50319fc42b11..180d3893b68da 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c
> @@ -208,7 +208,7 @@ bool dm_helpers_dp_mst_write_payload_allocation_table(
> if (enable)
> drm_dp_add_payload_part1(mst_mgr, mst_state, payload);
> else
> - drm_dp_remove_payload(mst_mgr, mst_state, payload);
> + drm_dp_remove_payload(mst_mgr, mst_state, payload, payload);
>
> /* mst_mgr->->payloads are VC payload notify MST branch using DPCD or
>* AUX message. The sequence is slot 1-63 allocated sequence for each
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index 847c10aa2098c..1990ff5dc7ddd 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> @@ -3342,7 +3342,8 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> * drm_dp_remove_payload() - Remove an MST payload
> * @mgr: Manager to use.
> * @mst_state: The MST atomic state
> - * @payload: The payload to write
> + * @old_payload: The payload with its old state
> + * @new_payload: The payload to write
> *
> * Removes a payload from an MST topology if it was successfully assigned a
> start slot. Also updates
> * the starting time slots of all other payloads which would have been
> shifted towards the start of
> @@ -3350,36 +3351,37 @@ EXPORT_SYMBOL(drm_dp_add_payload_part1);
> */
> void drm_dp_remove_payload(struct drm_dp_mst_topology_mgr *mgr,
> struct drm_dp_mst_topology_state *mst_state,
> -struct drm_dp_mst_atomic_payload *payload)
> +const struct drm_dp_mst_atomic_payload *old_payload,
> +struct drm_dp_mst_atomic_payload *new_payload)
> {
> struct drm_dp_mst_atomic_payload *pos;
> bool send_remove = false;
>
> /* We failed to make the payload, so nothing to do */
> - if (payload->vc_start_slot == -1)
> + if (new_payload->vc_start_slot == -1)
> return;
>
> mutex_lock(&mgr->lock);
> - send_remove = drm_dp_mst_port_downstream_of_branch(payload->port,
> mgr->mst_primary);
> + send_remove = drm_dp_mst_port_downstream_of_branch(new_payload->port,
> mgr->mst_primary);
> mutex_unlock(&mgr->lock);
>
> if (send_remove)
> - drm_dp_destroy_payload_step1(mgr, mst_state, payload);
> + drm_dp_destroy_payload_step1(mgr, mst_state, new_payload);
> else
> drm_dbg_kms(mgr->dev, "Payload for VCPI %d not in topology, not
> sending remove\n",
> - payload->vcpi);
> + new_payload->vcpi);
>
> list_for_each_entry(pos, &mst_state->payloads, next) {
> - if (pos != payload &&
Re: [PATCH] dt-bindings: display: msm: Drop type from 'memory-region'
On Wed, 25 Jan 2023 16:13:56 -0600, Rob Herring wrote: > 'memory-region' is a common property and already has a type. > > Signed-off-by: Rob Herring > --- > Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied, thanks!
