Re: [PATCH] drm/etnaviv: fix NULL check before some freeing functions is not needed
Am 25.01.21 um 04:27 schrieb Tian Tao: fixed the below warning: drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c:84:2-8: WARNING: NULL check before some freeing functions is not needed. Signed-off-by: Tian Tao Acked-by: Christian König --- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c index b390dd4..d741b1d 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c @@ -80,8 +80,7 @@ static void etnaviv_gem_prime_release(struct etnaviv_gem_object *etnaviv_obj) /* Don't drop the pages for imported dmabuf, as they are not * ours, just free the array we allocated: */ - if (etnaviv_obj->pages) - kvfree(etnaviv_obj->pages); + kvfree(etnaviv_obj->pages); drm_prime_gem_destroy(&etnaviv_obj->base, etnaviv_obj->sgt); } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer with error -12
On Thu, 21 Jan 2021 at 18:27, Christian König wrote: > > I still have no idea what's going on here. > > The KASAN messages from the DC code are completely unrelated. > > Please add the full dmesg to your bug report. > I did it. https://gitlab.freedesktop.org/drm/amd/-/issues/1439#note_776267 -- Best Regards, Mike Gavrilov. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: linux-next: Tree for Jan 22 (amdgpu)
[AMD Public Use] The link error has been fixed by: 5da047444e82 drm/amd/display: fix 64-bit division issue on 32-bit OS Regards, Guchun -Original Message- From: amd-gfx On Behalf Of Randy Dunlap Sent: Saturday, January 23, 2021 2:02 AM To: Stephen Rothwell ; Linux Next Mailing List Cc: amd-...@lists.freedesktop.org; Linux Kernel Mailing List ; dri-devel Subject: Re: linux-next: Tree for Jan 22 (amdgpu) On 1/21/21 11:06 PM, Stephen Rothwell wrote: > Hi all, > > Changes since 20210121: > on i386: ERROR: modpost: "__udivdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! ERROR: modpost: "__divdi3" [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! -- ~Randy ___ amd-gfx mailing list amd-...@lists.freedesktop.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=04%7C01%7Cguchun.chen%40amd.com%7C32b5c3dbae684672163608d8bf82ab0c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637469915239051891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0a61RTCcYsAXilfnxqSzPXxA2q6sIYDKEkMWL6HGJro%3D&reserved=0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][next] drm/amdgpu: Fix masking binary not operator on two mask operations
On Fri, Jan 22, 2021 at 11:00:22PM +0800, Colin King wrote:
> From: Colin Ian King
>
> Currently the ! operator is incorrectly being used to flip bits on
> mask values. Fix this by using the bit-wise ~ operator instead.
>
> Addresses-Coverity: ("Logical vs. bitwise operator")
> Fixes: 3c9a7b7d6e75 ("drm/amdgpu: update mmhub mgcg&ls for mmhub_v2_3")
> Signed-off-by: Colin Ian King
Thanks.
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> index 1961745e89c7..ab9be5ad5a5f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> +++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v2_3.c
> @@ -531,12 +531,12 @@ mmhub_v2_3_update_medium_grain_light_sleep(struct
> amdgpu_device *adev,
>
> if (enable && (adev->cg_flags & AMD_CG_SUPPORT_MC_LS)) {
> data &= ~MM_ATC_L2_CGTT_CLK_CTRL__MGLS_OVERRIDE_MASK;
> - data1 &= !(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> + data1 &= ~(DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
> DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
> DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
> DAGB0_WR_CGTT_CLK_CTRL__LS_OVERRIDE_REGISTER_MASK);
> - data2 &= !(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> + data2 &= ~(DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_MASK |
> DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_WRITE_MASK |
> DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_READ_MASK |
> DAGB0_RD_CGTT_CLK_CTRL__LS_OVERRIDE_RETURN_MASK |
> --
> 2.29.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/amd/display: Skip modeset for front porch change
On 2021-01-21 2:05 p.m., Kazlauskas, Nicholas wrote:
On 2021-01-19 10:50 a.m., Aurabindo Pillai wrote:
[Why]
A seamless transition between modes can be performed if the new incoming
mode has the same timing parameters as the optimized mode on a display
with a
variable vtotal min/max.
Smooth video playback usecases can be enabled with this seamless
transition by
switching to a new mode which has a refresh rate matching the video.
[How]
Skip full modeset if userspace requested a compatible freesync mode
which only
differs in the front porch timing from the current mode.
Signed-off-by: Aurabindo Pillai
Acked-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 233 +++---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 1 +
2 files changed, 198 insertions(+), 36 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 aaef2fb528fd..d66494cdd8c8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -213,6 +213,9 @@ static bool amdgpu_dm_psr_disable_all(struct
amdgpu_display_manager *dm);
static const struct drm_format_info *
amd_get_format_info(const struct drm_mode_fb_cmd2 *cmd);
+static bool
+is_timing_unchanged_for_freesync(struct drm_crtc_state *old_crtc_state,
+ struct drm_crtc_state *new_crtc_state);
/*
* dm_vblank_get_counter
*
@@ -4940,7 +4943,8 @@ static void
fill_stream_properties_from_drm_display_mode(
const struct drm_connector *connector,
const struct drm_connector_state *connector_state,
const struct dc_stream_state *old_stream,
- int requested_bpc)
+ int requested_bpc,
+ bool is_in_modeset)
{
struct dc_crtc_timing *timing_out = &stream->timing;
const struct drm_display_info *info = &connector->display_info;
@@ -4995,19 +4999,28 @@ static void
fill_stream_properties_from_drm_display_mode(
timing_out->hdmi_vic = hv_frame.vic;
}
- timing_out->h_addressable = mode_in->crtc_hdisplay;
- timing_out->h_total = mode_in->crtc_htotal;
- timing_out->h_sync_width =
- mode_in->crtc_hsync_end - mode_in->crtc_hsync_start;
- timing_out->h_front_porch =
- mode_in->crtc_hsync_start - mode_in->crtc_hdisplay;
- timing_out->v_total = mode_in->crtc_vtotal;
- timing_out->v_addressable = mode_in->crtc_vdisplay;
- timing_out->v_front_porch =
- mode_in->crtc_vsync_start - mode_in->crtc_vdisplay;
- timing_out->v_sync_width =
- mode_in->crtc_vsync_end - mode_in->crtc_vsync_start;
- timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ if (is_in_modeset) {
+ timing_out->h_addressable = mode_in->hdisplay;
+ timing_out->h_total = mode_in->htotal;
+ timing_out->h_sync_width = mode_in->hsync_end -
mode_in->hsync_start;
+ timing_out->h_front_porch = mode_in->hsync_start -
mode_in->hdisplay;
+ timing_out->v_total = mode_in->vtotal;
+ timing_out->v_addressable = mode_in->vdisplay;
+ timing_out->v_front_porch = mode_in->vsync_start -
mode_in->vdisplay;
+ timing_out->v_sync_width = mode_in->vsync_end -
mode_in->vsync_start;
+ timing_out->pix_clk_100hz = mode_in->clock * 10;
+ } else {
+ timing_out->h_addressable = mode_in->crtc_hdisplay;
+ timing_out->h_total = mode_in->crtc_htotal;
+ timing_out->h_sync_width = mode_in->crtc_hsync_end -
mode_in->crtc_hsync_start;
+ timing_out->h_front_porch = mode_in->crtc_hsync_start -
mode_in->crtc_hdisplay;
+ timing_out->v_total = mode_in->crtc_vtotal;
+ timing_out->v_addressable = mode_in->crtc_vdisplay;
+ timing_out->v_front_porch = mode_in->crtc_vsync_start -
mode_in->crtc_vdisplay;
+ timing_out->v_sync_width = mode_in->crtc_vsync_end -
mode_in->crtc_vsync_start;
+ timing_out->pix_clk_100hz = mode_in->crtc_clock * 10;
+ }
+
Not sure if I commented on this last time but I don't really understand
what this is_in_modeset logic is supposed to be doing here.
This is so because create_stream_for_link() that ends up calling this
function has two callers, one which is for stream validation in which
the created stream is immediately discarded. The other is during
modeset. Depending on these two cases, we want to copy the right timing
parameters. With this method, major refactor wasn't necessary with the
upper layers.
We should be modifying crtc_vsync_* for the generated modes, no? Not
just the vsync_* parameters.
This is already handled with:
if (!dm_state)
drm_mode_set_crtcinfo(&mode, 0);
if (dm_state && is_fs_vid_mode)
drm_mode_set_crtcinfo(&saved_mode, 0);
timing_out->aspect_ratio = get_aspect_ratio(mode_in);
stream->output_color_space = get_output_color_space(timing_out);
@@ -5227,6 +5240,33 @@ get_highest_refresh_rate_mode(struct
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_object.h
between commit:
41a9c75d0acf ("drm/i915/gem: Move stolen node into GEM object union")
from the drm tree and commit:
5fbc2c2bfa5c ("drm/i915/gem: Add a helper to read data from a GEM object
page")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/gem/i915_gem_object.h
index 5274e9d139b4,ae83737f1d48..
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@@ -548,6 -546,6 +554,8 @@@ i915_gem_object_invalidate_frontbuffer(
__i915_gem_object_invalidate_frontbuffer(obj, origin);
}
+bool i915_gem_object_is_shmem(const struct drm_i915_gem_object *obj);
+
+ int i915_gem_object_read_from_page(struct drm_i915_gem_object *obj, u64
offset, void *dst, int size);
+
#endif
pgpBtmCG2lJtZ.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 --- Comment #22 from Jay Tuckey (jay@tuckey.email) --- @Sebastien that could well be the case. The screen works fine under windows, but it could be that they are working around bad EDID data? Is there any way I can validate if the EDID is bad? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19
https://bugzilla.kernel.org/show_bug.cgi?id=201497 --- Comment #21 from Sebastien Bernard (sbern...@nerim.net) --- The more I think about it, the more it seems to be related only to this monitor. I think the 4.19 kernel closed a bug and is rejectiting the EDID reported by this screen. If someone could validate this EDID is correct, it'll be of great help. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #42 from MajorGonzo (majorgo...@juno.com) --- I made a change a while back. I added: amdgpu.gpu_recovery=1 as a grub parameter. I have no other (of the many suggested) parameters set: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash amdgpu.ppfeaturemask=0xfffd7fff amdgpu.gpu_recovery=1" The feature mask was used to enable reducing the top speed of my video card to reduce heating, and I was using corectrl for that. However, it was something I had to set manually after each boot. Of course, I forgot to do so, and yet it still stopped occurring. So in reality, I don't think I need that anymore, either. Just checked my linux logs grepping for "ring gfx". Before the change, I had multiples each day up to Dec 10th. Since then, I've had 3. Also of note - for the last two, it was when I WASN'T playing. Well, I was playing a game, but I was AFK. It seemed when I returned and did something, it went black then. Lastly, just to confirm, I checked my change log (my own log), and I did, indeed, make that change on 10 Dec. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #41 from Panagiotis Polychronis (panospolychro...@gmail.com) --- (In reply to j.cordoba from comment #40) > (In reply to Randune from comment #39) > > There doesn't appear to be any progress on this bug, does anyone have any > > suggestions with regards on how to fix this issue? > > Try to add iommu=pt as parameter I'm running Linux Kernel 5.10.9 with those kernel parameters "amdgpu.ppfeaturemask=0xbffb amdgpu.noretry=0 amdgpu.lockup_timeout=0 amdgpu.gpu_recovery=1 amdgpu.audio=0 amdgpu.deep_color=1 amd_iommu=on iommu=pt" My graphics card is Radeon 5600XT and i can confirm that this issue still exist :) Meanwhile i looked at https://lists.freedesktop.org/archives/amd-gfx/2021-January/date.html and there are some patches about ring timeout which i think they aren't yet merged for the next Linux Kernel release. Probably Alex Deucher will merge them later. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/6] dt-bindings: display: imx: Add i.MX8qxp/qm DPU binding
On Thu, 21 Jan 2021 15:14:18 +0800, Liu Ying wrote: > This patch adds bindings for i.MX8qxp/qm Display Processing Unit. > > Signed-off-by: Liu Ying > --- > v5->v6: > * Use graph schema. So, drop Rob's R-b tag as review is needed. > > v4->v5: > * No change. > > v3->v4: > * Improve compatible property by using enum instead of oneOf+const. (Rob) > * Add Rob's R-b tag. > > v2->v3: > * No change. > > v1->v2: > * Fix yamllint warnings. > * Require bypass0 and bypass1 clocks for both i.MX8qxp and i.MX8qm, as the > display controller subsystem spec does say that they exist. > * Use new dt binding way to add clocks in the example. > * Trivial tweaks for the example. > > .../bindings/display/imx/fsl,imx8qxp-dpu.yaml | 387 > + > 1 file changed, 387 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/imx/fsl,imx8qxp-dpu.yaml > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #40 from j.cordoba (j.cord...@gmx.net) --- (In reply to Randune from comment #39) > There doesn't appear to be any progress on this bug, does anyone have any > suggestions with regards on how to fix this issue? Try to add iommu=pt as parameter -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Sun, Jan 24, 2021 at 9:24 PM Simon Ser wrote: > On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner < > mario.kleiner...@gmail.com> wrote: > > > But it still needs to be fixed if we want working HDR. I thought > > libdrm copies the definitions from the kernel periodically, so the > > fix should propagate? > > There will always be user-space that sends 1 instead of 0. This > shouldn't fail on more recent kernels or it will be a regression. > Yes, i know, regressing user-space is bad, but in this very specific case a "good" one, if ever. At the moment, it wouldn't regress userspace simply because the kernel doesn't actually check for the correct value in its HDR metadata handling. But the value itself is sent as HDMI HDR metadata to the attached HDR display monitor, so if the monitors firmware checks, it will classify the wrong value of 1 as invalid and disable HDR mode on the display, which is certainly not what a HDR client application wants. And future HDR standards which will actually allocate the value 1 to a different mode of HDR operation will switch to the wrong mode / misinterpret the sent HDR metadata with hillarious results, which is also not in the interest of a HDR client application, or a HDR capable compositor. Iow. if clients continue to use the wrong value 1 then HDR display will break in various ways on correctly implemented HDR displays, but in a mystifying and hard to debug way. The kernel rejecting a wrong setting explicitly and forcing a bug fix in the client would be a blessing in this case. I spent weeks last year, going in circles and hunting ghost bugs related to HDR because much of the HDR stuff, both drivers and monitor firmware seems to be in not a great shape. "Less wrong" would be a big step forward. Especially with the cheaper HDR monitors it is difficult to see when things go wrong, because we don't have good expectations on how proper HDR should look and the lower end HDR displays don't help. -mario ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Generic USB Display driver
Den 24.01.2021 19.38, skrev Lubomir Rintel: > On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote: >> Hi, >> >> A while back I had the idea to turn a Raspberry Pi Zero into a $5 >> USB to HDMI/SDTV/DSI/DPI display adapter. >> >> The reason for calling it 'Generic' is so anyone can make a USB >> display/adapter against this driver, all that's needed is to add a USB >> vid:pid. >> >> Unfortunately I've had some compounding health problems that have >> severally limited the time I can spend in front of a computer. For this >> reason I've decided to keep the gadget driver out-of-tree and focus on >> getting the host driver merged first. >> >> See the wiki[1] for more information and images for the Raspberry Pi >> Zero/4. >> >> One big change this time is that I've followed Peter Stuge's advice to >> not let DRM stuff leak into the USB protocol. This has made the protocol >> easier to understand just from reading the header file. >> >> Noralf. >> >> [1] https://github.com/notro/gud/wiki > > The patch set: > > Tested-by: Lubomir Rintel > > Works like a charm with this board [1], though it didn't impress the girls > as much as I hoped. Code here [2], picture here [3]. > I have wondered what color display resolution it is possible to drive over USB full speed. I can understand that your PoC wasn't that impressive since it doesn't use DMA to drive the SPI bus. The new $4 Raspberry Pi Pico that came out this week looks interesting as a USB interface board for tiny panels. It can drive DPI panels directly, has 2 cores @133MHz, 264K SRAM and USB full speed. Maybe lz4 decompression is even possible. Another good thing is that the board will be around for a long time. Thanks for testing, I have limited bandwith these days so I couldn't do a test on an MCU myself. Noralf. > [1] > https://www.banggood.com/LILYGO-TTGO-T-Display-GD32-RISC-V-32-bit-Core-Minimal-Development-Board-1_14-IPS-p-1652870.html?rmmds=search&cur_warehouse=CN > [2] https://github.com/hackerspace/libopencm3-gf32v-examples/commit/7ef51b31b9 > [3] https://people.freedesktop.org/~lkundrak/lilygo.jpeg > > Had to apply a fix for the drm_connector_enum_list[] ommission I mentioned > elsewhere, and that I've now noticed you've noted previously. > > Take care > Lubo > >> >> >> Noralf Trønnes (3): >> drm/uapi: Add USB connector type >> drm/probe-helper: Check epoch counter in output_poll_execute() >> drm: Add Generic USB Display driver >> >> MAINTAINERS | 8 + >> drivers/gpu/drm/Kconfig | 2 + >> drivers/gpu/drm/Makefile| 1 + >> drivers/gpu/drm/drm_probe_helper.c | 7 +- >> drivers/gpu/drm/gud/Kconfig | 14 + >> drivers/gpu/drm/gud/Makefile| 4 + >> drivers/gpu/drm/gud/gud_connector.c | 722 >> drivers/gpu/drm/gud/gud_drv.c | 620 >> drivers/gpu/drm/gud/gud_internal.h | 148 ++ >> drivers/gpu/drm/gud/gud_pipe.c | 472 ++ >> include/drm/gud.h | 356 ++ >> include/uapi/drm/drm_mode.h | 1 + >> 12 files changed, 2354 insertions(+), 1 deletion(-) >> create mode 100644 drivers/gpu/drm/gud/Kconfig >> create mode 100644 drivers/gpu/drm/gud/Makefile >> create mode 100644 drivers/gpu/drm/gud/gud_connector.c >> create mode 100644 drivers/gpu/drm/gud/gud_drv.c >> create mode 100644 drivers/gpu/drm/gud/gud_internal.h >> create mode 100644 drivers/gpu/drm/gud/gud_pipe.c >> create mode 100644 include/drm/gud.h >> >> -- >> 2.23.0 >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/simple-kms: Drop drm_simple_kms_format_mod_supported.
The check was introduced to make sure that only the
DRM_FORMAT_MOD_LINEAR modifier is accepted by tinydrm.
However, if .format_mod_supported is not hooked up to
drm_simple_kms_format_mod_supported then the core will
simply validate modifiers against the format_modifiers
list passed into drm_simple_display_pipe_init() or
drm_universal_plane_init() and perform the same validation
as drm_simple_kms_format_mod_supported() would have done.
Additionally, if a kms driver / plane does not support
modifiers, it will not reject fb updates with no modifiers/
DRM_FORMAT_MOD_INVALID. This is important, because some
simple drm drivers, e.g., pl111, pass NULL as format_modifiers
list, so modifier support is disabled for these drivers,
userspace would fall back to drmAddFB() without modifiers,
and ergo the current drm_simple_kms_format_mod_supported()
function would reject valid modifier-less fb's.
So this should fix display on non-tinydrm drivers like
pl111, and probably also for non-atomic clients?
The Mesa vc4 gallium driver mentions pl111 as one possible
display driver in render_only mode, so i assume this matters
for some SoC's?
The background for the patch that introduced this was to
fix atomic modesetting in the X-Servers modesetting-ddx,
but with atomic modesetting and format modifiers disabled
in modesetting-ddx (and also current kernels when interacting
with modesetting-ddx), i assume this should fix some panels.
Note that i don't have any of the hw required for testing
this, this is purely based on looking at the code, so this
patch is only compile-tested.
For more reference, this fix was motivated by some discussions
around broken page-flipping on VideoCore6 / RaspberryPi 4
with current Raspbian OS, so the experts may want to weigh
in on that Mesa bug report as well, under the following link:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3601
Fixes: dff906c3f91c ("drm/tinydrm: Advertise that we can do only
DRM_FORMAT_MOD_LINEAR.")
Signed-off-by: Mario Kleiner
Cc: Eric Anholt
Cc: Noralf Trønnes
Cc: Maxime Ripard
---
drivers/gpu/drm/drm_simple_kms_helper.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 743e57c1b44f..5f3e30553172 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -229,13 +229,6 @@ static void drm_simple_kms_plane_cleanup_fb(struct
drm_plane *plane,
pipe->funcs->cleanup_fb(pipe, state);
}
-static bool drm_simple_kms_format_mod_supported(struct drm_plane *plane,
- uint32_t format,
- uint64_t modifier)
-{
- return modifier == DRM_FORMAT_MOD_LINEAR;
-}
-
static const struct drm_plane_helper_funcs drm_simple_kms_plane_helper_funcs =
{
.prepare_fb = drm_simple_kms_plane_prepare_fb,
.cleanup_fb = drm_simple_kms_plane_cleanup_fb,
@@ -250,7 +243,6 @@ static const struct drm_plane_funcs
drm_simple_kms_plane_funcs = {
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
- .format_mod_supported = drm_simple_kms_format_mod_supported,
};
/**
--
2.25.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner wrote: > But it still needs to be fixed if we want working HDR. I thought > libdrm copies the definitions from the kernel periodically, so the > fix should propagate? There will always be user-space that sends 1 instead of 0. This shouldn't fail on more recent kernels or it will be a regression. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Sun, Jan 24, 2021 at 9:15 AM Simon Ser wrote:
> On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner <
> mario.kleiner...@gmail.com> wrote:
>
> > According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> > not 1, but zero, so fix this enum.
> >
> > While this doesn't cause problems in the kernel yet, as the
> > constant isn't actively used by drivers yet, it did create
> > confusion while debugging HDR problems in yours truly, and
> > also potential bugs in userspace components, as the wrong
> > enum propagates to components, e.g., like it did already
> > into intel-gpu-tools (tests/kms_hdr.c) or is used as wrong
> > reference when writing future new userspace HDR components
> > like compositors.
> >
> > Fixes: fbb5d0353c62 ("drm: Add HDR source metadata property")
> > Signed-off-by: Mario Kleiner
> > Cc: Uma Shankar
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
>
> Sadly I think it's too late for this. Some user-space (like Kodi)
> already has copied over the kernel definitions, and libdrm already has
> a release with the wrong value.
>
But it still needs to be fixed if we want working HDR. I thought libdrm
copies the definitions from the kernel periodically, so the fix should
propagate?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 --- Comment #39 from Randune (randyk...@gmail.com) --- There doesn't appear to be any progress on this bug, does anyone have any suggestions with regards on how to fix this issue? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 211277] sometimes crash at s2ram-wake (Ryzen 3500U): amdgpu, drm, commit_tail, amdgpu_dm_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=211277 Jerome C (m...@jeromec.com) changed: What|Removed |Added CC||m...@jeromec.com --- Comment #4 from Jerome C (m...@jeromec.com) --- I too have a Ryzen 5 3500U and random resumes where the screen updates are very slow ( 1 frame change every 1-2 minutes ) which looks like it's crashed and in the kernel logs I see a bunch of "flip_done timed out" and "amdgpu_dm_atomic_commit_tail" errors This never happened for me between 5.4.6 - 5.9.14. I noticed this since 5.10.4 and did never suspended on 5.10.0 - 5.10.3, so my guess it's an issue sometime in 5.10.0 - 5.10.3 Do you have kernel parameter set "init_on_free=1" or in your kernel config "CONFIG_INIT_ON_FREE_DEFAULT_ON=y", if so try changing/setting the kernel parameter "init_on_free=0", so far ( for me and still testing ) it's resumed every time I think it's an issue with amdgpu and kernel paramater "init_on_free=1" or kernel config "CONFIG_INIT_ON_FREE_DEFAULT_ON=y" which zero's memory on free/deallocation. kernel paramter "init_on_alloc=1" or kernel config "CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y" works fine for me -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 3/3] drm: Add Generic USB Display driver
Den 20.01.2021 19.02, skrev Daniel Vetter:
> On Wed, Jan 20, 2021 at 6:11 PM Noralf Trønnes wrote:
>>
>> This adds a generic USB display driver with the intention that it can be
>> used with future USB interfaced low end displays/adapters. The Linux
>> gadget device driver will serve as the canonical device implementation.
>>
>> The following DRM properties are supported:
>> - Plane rotation
>> - Connector TV properties
>>
>> There is also support for backlight brightness exposed as a backlight
>> device.
>>
>> Display modes can be made available to the host driver either as DRM
>> display modes or through EDID. If both are present, EDID is just passed
>> on to userspace.
>>
>> Performance is preferred over color depth, so if the device supports
>> RGB565, DRM_CAP_DUMB_PREFERRED_DEPTH will return 16.
>>
>> If the device transfer buffer can't fit an uncompressed framebuffer
>> update, the update is split up into parts that do fit.
>>
>> Optimal user experience is achieved by providing damage reports either by
>> setting FB_DAMAGE_CLIPS on pageflips or calling DRM_IOCTL_MODE_DIRTYFB.
>>
>> LZ4 compression is used if the device supports it.
>>
>> The driver supports a one bit monochrome transfer format: R1. This is not
>> implemented in the gadget driver. It is added in preparation for future
>> monochrome e-ink displays.
>>
>> The driver is MIT licensed to smooth the path for any BSD port of the
>> driver.
>>
>> v2:
>> - Use devm_drm_dev_alloc() and drmm_mode_config_init()
>> - drm_fbdev_generic_setup: Use preferred_bpp=0, 16 was a copy paste error
>> - The drm_backlight_helper is dropped, copy in the code
>
> I think the backlight is still a bit problematic, since you're using
> kms locks within the backlight callbacks. Other display drivers use
> backlight within their kms locks. This means inconsistent locking
> rules, which upsets lockdep.
>
> Since you're already handling brightness as a special case in many
> places I don't think it's a big shuffle:
> - add a mutex to the connector struct
> - move brightness value to connector struct, out of the connector_state
> - use the new mutex to protect backlight state both from modeset side
> (if needed, I'm not entirely sure about that) and the backlight side
>
It's not enough to store the value I need to send it to the device as
well. Currently I send the entire state each time there's a change. To
continue that I would need to keep a copy of the state that I can use
when brightness changes. Or I can treat backlight as an exception and
add a USB control request just for backlight.
There is some special treatment of the backlight in the driver, but I
would really like to handle the backlight brightness through the atomic
machinery. I want to avoid special treatment of backlight in the USB
protocol.
I can avoid the lockdep problem by letting a worker commit the state and
schedule it from the backlight update callback. I'll do that unless you
see other issues with that approach.
Is it ok to take the connection_mutex lock in the get_brightness
callback to get to the connector state and the brightness value?
i915 takes that lock in intel_backlight_device_update_status() and
intel_backlight_device_get_brightness().
> Some more things below, but in general I'd say Acked-by: Daniel Vetter
> fwiw (probably not so much).
>
Thanks for taking a look, much appreciated.
Noralf.
>> diff --git a/drivers/gpu/drm/gud/gud_connector.c
>> b/drivers/gpu/drm/gud/gud_connector.c
>> new file mode 100644
>> index ..a4b9bbf48e19
>> --- /dev/null
>> +++ b/drivers/gpu/drm/gud/gud_connector.c
>> @@ -0,0 +1,722 @@
>> +// SPDX-License-Identifier: MIT
>> +/*
>> + * Copyright 2020 Noralf Trønnes
>> + */
>> +
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "gud_internal.h"
>> +
>> +struct gud_connector {
>> + struct drm_connector connector;
>> + struct drm_encoder encoder;
>> + struct backlight_device *backlight;
>> +
>> + /* Supported properties */
>> + u16 *properties;
>> + unsigned int num_properties;
>> +
>> + /* Initial gadget tv state if applicable, applied on state reset */
>> + struct drm_tv_connector_state initial_tv_state;
>> +
>> + /*
>> +* Initial gadget backlight brightness if applicable, applied on
>> state reset.
>> +* The value -ENODEV is used to signal no backlight.
>> +*/
>> + int initial_brightness;
>> +
>> + unsigned int num_modes;
>> + size_t edid_len;
>> +};
>> +
>> +static inline struct gud_connector *to_gud_connector(struct drm_connector
>> *connector)
>> +{
>> + return container_of(connector, struct gud_connector, connector);
>> +}
>> +
>> +static int gud_connector_backlight_update_status(struct backlight_device
>> *bd)
>> +{
>> + struct drm_connector *connector = bl_get_data(bd);
>> +
Patch "drm/syncobj: Fix use-after-free" has been added to the 5.10-stable tree
This is a note to let you know that I've just added the patch titled
drm/syncobj: Fix use-after-free
to the 5.10-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-syncobj-fix-use-after-free.patch
and it can be found in the queue-5.10 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From a37eef63bc9e16e06361b539e528058146af80ab Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Tue, 19 Jan 2021 14:03:18 +0100
Subject: drm/syncobj: Fix use-after-free
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
drm_syncobj_find_fence v4")
Reviewed-by: Christian König
Cc: Christian König
Cc: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_syncobj.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -388,19 +388,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(&wait, 0, sizeof(wait));
wait.task = current;
@@ -432,6 +431,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, &wait);
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-5.10/drm-syncobj-fix-use-after-free.patch
queue-5.10/drm-atomic-put-state-on-error-path.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Patch "drm/syncobj: Fix use-after-free" has been added to the 5.4-stable tree
This is a note to let you know that I've just added the patch titled
drm/syncobj: Fix use-after-free
to the 5.4-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-syncobj-fix-use-after-free.patch
and it can be found in the queue-5.4 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
From a37eef63bc9e16e06361b539e528058146af80ab Mon Sep 17 00:00:00 2001
From: Daniel Vetter
Date: Tue, 19 Jan 2021 14:03:18 +0100
Subject: drm/syncobj: Fix use-after-free
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Daniel Vetter
commit a37eef63bc9e16e06361b539e528058146af80ab upstream.
While reviewing Christian's annotation patch I noticed that we have a
user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj
reference before we've completed the waiting.
Of course usually there's nothing bad happening here since userspace
keeps the reference, but we can't rely on userspace to play nice here!
Signed-off-by: Daniel Vetter
Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in
drm_syncobj_find_fence v4")
Reviewed-by: Christian König
Cc: Christian König
Cc: Lionel Landwerlin
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.2+
Link:
https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vet...@ffwll.ch
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/drm_syncobj.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -326,19 +326,18 @@ int drm_syncobj_find_fence(struct drm_fi
return -ENOENT;
*fence = drm_syncobj_fence_get(syncobj);
- drm_syncobj_put(syncobj);
if (*fence) {
ret = dma_fence_chain_find_seqno(fence, point);
if (!ret)
- return 0;
+ goto out;
dma_fence_put(*fence);
} else {
ret = -EINVAL;
}
if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
- return ret;
+ goto out;
memset(&wait, 0, sizeof(wait));
wait.task = current;
@@ -370,6 +369,9 @@ int drm_syncobj_find_fence(struct drm_fi
if (wait.node.next)
drm_syncobj_remove_wait(syncobj, &wait);
+out:
+ drm_syncobj_put(syncobj);
+
return ret;
}
EXPORT_SYMBOL(drm_syncobj_find_fence);
Patches currently in stable-queue which might be from daniel.vet...@ffwll.ch are
queue-5.4/drm-syncobj-fix-use-after-free.patch
queue-5.4/drm-atomic-put-state-on-error-path.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/ingenic: Fix non-OSD mode
Hi Nikolaus,
Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller
a écrit :
Hi Paul,
we observed the same issue on the jz4730 (which is almost identical
to the jz4740 wrt. LCDC) and our solution [1] was simpler.
It leaves the hwdesc f0 and f1 as they are and just takes f1 for
really
programming the first DMA descriptor if there is no OSD.
Disagreed. With your solution, it ends up using priv->f1 plane with
hwdesc_f0. That's very confusing.
We have tested on jz4730 and jz4780.
Could I get a tested-by then? :)
Cheers,
-Paul
Maybe you want to consider that. Then I can officially post it.
[1]
https://github.com/goldelico/letux-kernel/commit/3be1de5fdabf2cc1c17f198ded3328cc6e4b9844
Am 24.01.2021 um 09:55 schrieb Paul Cercueil :
Even though the JZ4740 did not have the OSD mode, it had (according
to
the documentation) two DMA channels, but there is absolutely no
information about how to select the second DMA channel.
Make the ingenic-drm driver work in non-OSD mode by using the
foreground0 plane (which is bound to the DMA0 channel) as the
primary
plane, instead of the foreground1 plane, which is the primary plane
when in OSD mode.
Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
Cc: # v5.8+
Signed-off-by: Paul Cercueil
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index b23011c1c5d9..59ce43862e16 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -554,7 +554,7 @@ static void
ingenic_drm_plane_atomic_update(struct drm_plane *plane,
height = state->src_h >> 16;
cpp = state->fb->format->cpp[0];
- if (priv->soc_info->has_osd && plane->type ==
DRM_PLANE_TYPE_OVERLAY)
+ if (!priv->soc_info->has_osd || plane->type ==
DRM_PLANE_TYPE_OVERLAY)
hwdesc = &priv->dma_hwdescs->hwdesc_f0;
else
hwdesc = &priv->dma_hwdescs->hwdesc_f1;
we just replace this with
if (priv->soc_info->has_osd && plane->type !=
DRM_PLANE_TYPE_OVERLAY)
hwdesc = &priv->dma_hwdescs->hwdesc_f1;
else
hwdesc = &priv->dma_hwdescs->hwdesc_f0;
and the remainder can stay as is.
@@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev,
bool has_components)
const struct jz_soc_info *soc_info;
struct ingenic_drm *priv;
struct clk *parent_clk;
+ struct drm_plane *primary;
struct drm_bridge *bridge;
struct drm_panel *panel;
struct drm_encoder *encoder;
@@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device
*dev, bool has_components)
if (soc_info->has_osd)
priv->ipu_plane = drm_plane_from_index(drm, 0);
- drm_plane_helper_add(&priv->f1, &ingenic_drm_plane_helper_funcs);
+ primary = priv->soc_info->has_osd ? &priv->f1 : &priv->f0;
- ret = drm_universal_plane_init(drm, &priv->f1, 1,
+ drm_plane_helper_add(primary, &ingenic_drm_plane_helper_funcs);
+
+ ret = drm_universal_plane_init(drm, primary, 1,
&ingenic_drm_primary_plane_funcs,
priv->soc_info->formats_f1,
priv->soc_info->num_formats_f1,
@@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev,
bool has_components)
drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs);
- ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->f1,
+ ret = drm_crtc_init_with_planes(drm, &priv->crtc, primary,
NULL, &ingenic_drm_crtc_funcs, NULL);
if (ret) {
dev_err(dev, "Failed to init CRTC: %i\n", ret);
--
2.29.2
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 0/4] Fixes to bridge/panel and ingenic-drm
Hi, Here are three independent fixes. The first one addresses a use-after-free in bridge/panel.c; the second one addresses a use-after-free in the ingenic-drm driver; finally, the third one makes the ingenic-drm driver work again on older Ingenic SoCs. Changes from v2: - patch [1/4] added a FIXME. - patch [2/4] is new. It introduces a drmm_plain_simple_encoder_alloc() macro that will be used in patch [3/4]. - patch [3/4] uses the macro introduced in patch [2/4]. - patch [4/4] is unmodified. Note to linux-stable guys: patch [v2 2/3] will only apply on the current drm-misc-next branch, to fix it for v5.11 and older kernels, use the V1 of that patch. Cheers, -Paul Paul Cercueil (4): drm: bridge/panel: Cleanup connector on bridge detach drm/simple_kms_helper: Add macro drmm_plain_simple_encoder_alloc() drm/ingenic: Register devm action to cleanup encoders drm/ingenic: Fix non-OSD mode drivers/gpu/drm/bridge/panel.c| 12 +++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 26 +++ include/drm/drm_simple_kms_helper.h | 17 +++ 3 files changed, 42 insertions(+), 13 deletions(-) -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Generic USB Display driver
On Wed, Jan 20, 2021 at 06:00:30PM +0100, Noralf Trønnes wrote: > Hi, > > A while back I had the idea to turn a Raspberry Pi Zero into a $5 > USB to HDMI/SDTV/DSI/DPI display adapter. > > The reason for calling it 'Generic' is so anyone can make a USB > display/adapter against this driver, all that's needed is to add a USB > vid:pid. > > Unfortunately I've had some compounding health problems that have > severally limited the time I can spend in front of a computer. For this > reason I've decided to keep the gadget driver out-of-tree and focus on > getting the host driver merged first. > > See the wiki[1] for more information and images for the Raspberry Pi > Zero/4. > > One big change this time is that I've followed Peter Stuge's advice to > not let DRM stuff leak into the USB protocol. This has made the protocol > easier to understand just from reading the header file. Welcome back! I'm happy to see this patch set back on track. I've now started putting together something that would work with GUD on Lilygo T-Display-GD32, but it blew up in my face immediately (I had CONFIG_DEBUG_SPINLOCK turned on): [ 42.064362] usb 1-1.2: new full-speed USB device number 6 using mv-ehci [ 42.228048] usb 1-1.2: New USB device found, idVendor=1d50, idProduct=614d, bcdDevice= 1.00 [ 42.236812] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 42.254298] usb 1-1.2: Product: LCD Display Interface [ 42.259771] usb 1-1.2: Manufacturer: Lubomir Rintel [ 42.266395] usb 1-1.2: SerialNumber: 3736030061294139 [ 42.284771] BUG: spinlock bad magic on CPU#0, kworker/0:0/5 [ 42.290394] 8<--- cut here --- [ 42.293415] Unable to handle kernel NULL pointer dereference at virtual address 031c [ 42.301417] pgd = e351f484 [ 42.304184] [031c] *pgd= [ 42.307826] Internal error: Oops: 15 [#1] PREEMPT SMP ARM [ 42.313250] Modules linked in: [ 42.316208] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.11.0-rc4-00113-g8c3d05f1939a #1274 [ 42.324729] Hardware name: Marvell MMP3 [ 42.328540] Workqueue: usb_hub_wq hub_event [ 42.332759] PC is at spin_dump+0x5c/0x88 [ 42.336556] LR is at spin_dump+0x48/0x88 [ 42.340644] pc : []lr : []psr: 200f0193 [ 42.346895] sp : c810b910 ip : fp : c1107b40 [ 42.352039] r10: c005 r9 : r8 : 001f [ 42.357238] r7 : r6 : 0438 r5 : c14456f8 r4 : 0014 [ 42.363837] r3 : 044c r2 : c1091500 r1 : eefb8540 r0 : 002f [ 42.370351] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment none [ 42.377456] Control: 10c5387d Table: 09f0806a DAC: 0051 [ 42.383286] Process kworker/0:0 (pid: 5, stack limit = 0xda2575c6) [ 42.389392] Stack: (0xc810b910 to 0xc810c000) [ 42.393801] b900: 0005 c14456f8 c14456f8 c058f244 [ 42.401916] b920: a00f0113 c018b1cc c14456f8 c058f244 a00f0113 c0c4e454 0001 [ 42.410117] b940: c058f244 0003 c9d1d800 ca01f000 7fff c058f244 200f0113 0001 [ 42.418267] b960: 0cc0 c810a000 0dc0 c1053148 0023 c9d1d814 c14456f8 [ 42.426399] b980: 0003 fcee162a 0cc0 c9d1d800 [ 42.434607] b9a0: ca01f000 c810a000 0014 c9d1d814 c14452e0 ca01f42c c0669f84 [ 42.442749] b9c0: c0668d98 0dc0 0dc0 c126dd90 0dc0 ca01f24c [ 42.450887] b9e0: 0410 c14456f8 ca01f000 fcee162a c9d1d800 [ 42.459087] ba00: 0001 ca01f000 ca01fac8 0002 c06965e0 [ 42.467220] ba20: c03027b0 c8001600 0001 c810a000 fcee162a fcee162a [ 42.475373] ba40: a00f0113 c9d25880 c0694894 a00f0113 c800 7820 fcee162a [ 42.483470] ba60: 0002 ca01f000 c9ae7800 c810a000 0001 c9d258c0 ca01fac8 [ 42.491685] ba80: 0002 c0694a14 0002 c0d68608 0001 c0186460 [ 42.499882] baa0: c9d65878 c9d25940 c0d51198 0001 36314752 34325241 [ 42.508038] bac0: 0001 c9ae7820 34325258 c9ae7800 c810a000 0022 c0c4e6b8 [ 42.516202] bae0: c98b1a00 fcee162a c9d65878 c9ae7820 c9d65878 c1446198 c9ae7800 c9d65800 [ 42.524347] bb00: 0001 c0d68618 ffed c07eae44 c07ead58 c9ae7820 c18004e0 [ 42.532534] bb20: c18004e8 c1446198 c14ab308 0022 c069f124 c9ae79cc 0001 [ 42.540557] bb40: c9ae78dc c14555b0 c9ae7820 c14ab308 c1446198 c069fba4 0001 [ 42.548847] bb60: c1800494 c14555b0 c069f5bc 0001 c069fb78 c810bbc4 [ 42.556874] bb80: c810a000 0001 c1800494 c14555b0 c069cefc c14555b0 c8a964e4 [ 42.565179] bba0: c8e90d58 fcee162a c9d65934 c9ae7820 c810a000 c9ae7820 c9ae7864 c069f8f4 [ 42.573316] bbc0: c109aed0 c9ae7820 0001 fcee162a c
[PATCH v3 4/4] drm/ingenic: Fix non-OSD mode
Even though the JZ4740 did not have the OSD mode, it had (according to
the documentation) two DMA channels, but there is absolutely no
information about how to select the second DMA channel.
Make the ingenic-drm driver work in non-OSD mode by using the
foreground0 plane (which is bound to the DMA0 channel) as the primary
plane, instead of the foreground1 plane, which is the primary plane
when in OSD mode.
Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
Cc: # v5.8+
Signed-off-by: Paul Cercueil
Acked-by: Daniel Vetter
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index b23011c1c5d9..59ce43862e16 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -554,7 +554,7 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
height = state->src_h >> 16;
cpp = state->fb->format->cpp[0];
- if (priv->soc_info->has_osd && plane->type ==
DRM_PLANE_TYPE_OVERLAY)
+ if (!priv->soc_info->has_osd || plane->type ==
DRM_PLANE_TYPE_OVERLAY)
hwdesc = &priv->dma_hwdescs->hwdesc_f0;
else
hwdesc = &priv->dma_hwdescs->hwdesc_f1;
@@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
const struct jz_soc_info *soc_info;
struct ingenic_drm *priv;
struct clk *parent_clk;
+ struct drm_plane *primary;
struct drm_bridge *bridge;
struct drm_panel *panel;
struct drm_encoder *encoder;
@@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
if (soc_info->has_osd)
priv->ipu_plane = drm_plane_from_index(drm, 0);
- drm_plane_helper_add(&priv->f1, &ingenic_drm_plane_helper_funcs);
+ primary = priv->soc_info->has_osd ? &priv->f1 : &priv->f0;
- ret = drm_universal_plane_init(drm, &priv->f1, 1,
+ drm_plane_helper_add(primary, &ingenic_drm_plane_helper_funcs);
+
+ ret = drm_universal_plane_init(drm, primary, 1,
&ingenic_drm_primary_plane_funcs,
priv->soc_info->formats_f1,
priv->soc_info->num_formats_f1,
@@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs);
- ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->f1,
+ ret = drm_crtc_init_with_planes(drm, &priv->crtc, primary,
NULL, &ingenic_drm_crtc_funcs, NULL);
if (ret) {
dev_err(dev, "Failed to init CRTC: %i\n", ret);
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 3/4] drm/ingenic: Register devm action to cleanup encoders
Since the encoders have been devm-allocated, they will be freed way
before drm_mode_config_cleanup() is called. To avoid use-after-free
conditions, we then must ensure that drm_encoder_cleanup() is called
before the encoders are freed.
v2: Use the new __drmm_simple_encoder_alloc() function
v3: Use the new drmm_plain_simple_encoder_alloc() macro
Fixes: c369cb27c267 ("drm/ingenic: Support multiple panels/bridges")
Cc: # 5.8+
Signed-off-by: Paul Cercueil
---
Notes:
Use the V1 of this patch to fix v5.11 and older kernels. This V3 only
applies on the current drm-misc-next branch.
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 7bb31fbee29d..b23011c1c5d9 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -1014,20 +1014,17 @@ static int ingenic_drm_bind(struct device *dev, bool
has_components)
bridge = devm_drm_panel_bridge_add_typed(dev, panel,
DRM_MODE_CONNECTOR_DPI);
- encoder = devm_kzalloc(dev, sizeof(*encoder), GFP_KERNEL);
- if (!encoder)
- return -ENOMEM;
+ encoder = drmm_plain_simple_encoder_alloc(drm,
DRM_MODE_ENCODER_DPI);
+ if (IS_ERR(encoder)) {
+ ret = PTR_ERR(encoder);
+ dev_err(dev, "Failed to init encoder: %d\n", ret);
+ return ret;
+ }
encoder->possible_crtcs = 1;
drm_encoder_helper_add(encoder,
&ingenic_drm_encoder_helper_funcs);
- ret = drm_simple_encoder_init(drm, encoder,
DRM_MODE_ENCODER_DPI);
- if (ret) {
- dev_err(dev, "Failed to init encoder: %d\n", ret);
- return ret;
- }
-
ret = drm_bridge_attach(encoder, bridge, NULL, 0);
if (ret) {
dev_err(dev, "Unable to attach bridge\n");
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/ingenic: Fix non-OSD mode
Hi Paul,
> Am 24.01.2021 um 10:43 schrieb Paul Cercueil :
>
> Hi Nikolaus,
>
> Le dim. 24 janv. 2021 à 10:30, H. Nikolaus Schaller a
> écrit :
>> Hi Paul,
>> we observed the same issue on the jz4730 (which is almost identical
>> to the jz4740 wrt. LCDC) and our solution [1] was simpler.
>> It leaves the hwdesc f0 and f1 as they are and just takes f1 for really
>> programming the first DMA descriptor if there is no OSD.
>
> Disagreed. With your solution, it ends up using priv->f1 plane with
> hwdesc_f0. That's very confusing.
It is a tradeoff between code simplicity and confusion. Indeed difficult to
decide. Fortunately I don't have to :)
>
>> We have tested on jz4730 and jz4780.
>
> Could I get a tested-by then? :)
I'll test with our tree and test both SoC in the next days and give feedback.
BR and thanks,
Nikolaus
>
> Cheers,
> -Paul
>
>> Maybe you want to consider that. Then I can officially post it.
>> [1]
>> https://github.com/goldelico/letux-kernel/commit/3be1de5fdabf2cc1c17f198ded3328cc6e4b9844
>>> Am 24.01.2021 um 09:55 schrieb Paul Cercueil :
>>> Even though the JZ4740 did not have the OSD mode, it had (according to
>>> the documentation) two DMA channels, but there is absolutely no
>>> information about how to select the second DMA channel.
>>> Make the ingenic-drm driver work in non-OSD mode by using the
>>> foreground0 plane (which is bound to the DMA0 channel) as the primary
>>> plane, instead of the foreground1 plane, which is the primary plane
>>> when in OSD mode.
>>> Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
>>> Cc: # v5.8+
>>> Signed-off-by: Paul Cercueil
>>> Acked-by: Daniel Vetter
>>> ---
>>> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
>>> 1 file changed, 7 insertions(+), 4 deletions(-)
>>> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>> index b23011c1c5d9..59ce43862e16 100644
>>> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
>>> @@ -554,7 +554,7 @@ static void ingenic_drm_plane_atomic_update(struct
>>> drm_plane *plane,
>>> height = state->src_h >> 16;
>>> cpp = state->fb->format->cpp[0];
>>> - if (priv->soc_info->has_osd && plane->type ==
>>> DRM_PLANE_TYPE_OVERLAY)
>>> + if (!priv->soc_info->has_osd || plane->type ==
>>> DRM_PLANE_TYPE_OVERLAY)
>>> hwdesc = &priv->dma_hwdescs->hwdesc_f0;
>>> else
>>> hwdesc = &priv->dma_hwdescs->hwdesc_f1;
>> we just replace this with
>>if (priv->soc_info->has_osd && plane->type !=
>> DRM_PLANE_TYPE_OVERLAY)
>>hwdesc = &priv->dma_hwdescs->hwdesc_f1;
>>else
>>hwdesc = &priv->dma_hwdescs->hwdesc_f0;
>> and the remainder can stay as is.
>>> @@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev, bool
>>> has_components)
>>> const struct jz_soc_info *soc_info;
>>> struct ingenic_drm *priv;
>>> struct clk *parent_clk;
>>> + struct drm_plane *primary;
>>> struct drm_bridge *bridge;
>>> struct drm_panel *panel;
>>> struct drm_encoder *encoder;
>>> @@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device *dev, bool
>>> has_components)
>>> if (soc_info->has_osd)
>>> priv->ipu_plane = drm_plane_from_index(drm, 0);
>>> - drm_plane_helper_add(&priv->f1, &ingenic_drm_plane_helper_funcs);
>>> + primary = priv->soc_info->has_osd ? &priv->f1 : &priv->f0;
>>> - ret = drm_universal_plane_init(drm, &priv->f1, 1,
>>> + drm_plane_helper_add(primary, &ingenic_drm_plane_helper_funcs);
>>> +
>>> + ret = drm_universal_plane_init(drm, primary, 1,
>>>&ingenic_drm_primary_plane_funcs,
>>>priv->soc_info->formats_f1,
>>>priv->soc_info->num_formats_f1,
>>> @@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev, bool
>>> has_components)
>>> drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs);
>>> - ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->f1,
>>> + ret = drm_crtc_init_with_planes(drm, &priv->crtc, primary,
>>> NULL, &ingenic_drm_crtc_funcs, NULL);
>>> if (ret) {
>>> dev_err(dev, "Failed to init CRTC: %i\n", ret);
>>> --
>>> 2.29.2
>> BR and thanks,
>> Nikolaus
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 4/4] drm/ingenic: Fix non-OSD mode
Hi Paul,
we observed the same issue on the jz4730 (which is almost identical
to the jz4740 wrt. LCDC) and our solution [1] was simpler.
It leaves the hwdesc f0 and f1 as they are and just takes f1 for really
programming the first DMA descriptor if there is no OSD.
We have tested on jz4730 and jz4780.
Maybe you want to consider that. Then I can officially post it.
[1]
https://github.com/goldelico/letux-kernel/commit/3be1de5fdabf2cc1c17f198ded3328cc6e4b9844
> Am 24.01.2021 um 09:55 schrieb Paul Cercueil :
>
> Even though the JZ4740 did not have the OSD mode, it had (according to
> the documentation) two DMA channels, but there is absolutely no
> information about how to select the second DMA channel.
>
> Make the ingenic-drm driver work in non-OSD mode by using the
> foreground0 plane (which is bound to the DMA0 channel) as the primary
> plane, instead of the foreground1 plane, which is the primary plane
> when in OSD mode.
>
> Fixes: 3c9bea4ef32b ("drm/ingenic: Add support for OSD mode")
> Cc: # v5.8+
> Signed-off-by: Paul Cercueil
> Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> index b23011c1c5d9..59ce43862e16 100644
> --- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> +++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
> @@ -554,7 +554,7 @@ static void ingenic_drm_plane_atomic_update(struct
> drm_plane *plane,
> height = state->src_h >> 16;
> cpp = state->fb->format->cpp[0];
>
> - if (priv->soc_info->has_osd && plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> + if (!priv->soc_info->has_osd || plane->type ==
> DRM_PLANE_TYPE_OVERLAY)
> hwdesc = &priv->dma_hwdescs->hwdesc_f0;
> else
> hwdesc = &priv->dma_hwdescs->hwdesc_f1;
we just replace this with
if (priv->soc_info->has_osd && plane->type !=
DRM_PLANE_TYPE_OVERLAY)
hwdesc = &priv->dma_hwdescs->hwdesc_f1;
else
hwdesc = &priv->dma_hwdescs->hwdesc_f0;
and the remainder can stay as is.
> @@ -826,6 +826,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> const struct jz_soc_info *soc_info;
> struct ingenic_drm *priv;
> struct clk *parent_clk;
> + struct drm_plane *primary;
> struct drm_bridge *bridge;
> struct drm_panel *panel;
> struct drm_encoder *encoder;
> @@ -940,9 +941,11 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
> if (soc_info->has_osd)
> priv->ipu_plane = drm_plane_from_index(drm, 0);
>
> - drm_plane_helper_add(&priv->f1, &ingenic_drm_plane_helper_funcs);
> + primary = priv->soc_info->has_osd ? &priv->f1 : &priv->f0;
>
> - ret = drm_universal_plane_init(drm, &priv->f1, 1,
> + drm_plane_helper_add(primary, &ingenic_drm_plane_helper_funcs);
> +
> + ret = drm_universal_plane_init(drm, primary, 1,
> &ingenic_drm_primary_plane_funcs,
> priv->soc_info->formats_f1,
> priv->soc_info->num_formats_f1,
> @@ -954,7 +957,7 @@ static int ingenic_drm_bind(struct device *dev, bool
> has_components)
>
> drm_crtc_helper_add(&priv->crtc, &ingenic_drm_crtc_helper_funcs);
>
> - ret = drm_crtc_init_with_planes(drm, &priv->crtc, &priv->f1,
> + ret = drm_crtc_init_with_planes(drm, &priv->crtc, primary,
> NULL, &ingenic_drm_crtc_funcs, NULL);
> if (ret) {
> dev_err(dev, "Failed to init CRTC: %i\n", ret);
> --
> 2.29.2
>
BR and thanks,
Nikolaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/4] drm/simple_kms_helper: Add macro drmm_plain_simple_encoder_alloc()
This performs the same operation as drmm_simple_encoder_alloc(), but only allocates and returns a struct drm_encoder instance. Signed-off-by: Paul Cercueil --- include/drm/drm_simple_kms_helper.h | 17 + 1 file changed, 17 insertions(+) diff --git a/include/drm/drm_simple_kms_helper.h b/include/drm/drm_simple_kms_helper.h index e6dbf3161c2f..f07e70303cfb 100644 --- a/include/drm/drm_simple_kms_helper.h +++ b/include/drm/drm_simple_kms_helper.h @@ -209,4 +209,21 @@ void *__drmm_simple_encoder_alloc(struct drm_device *dev, size_t size, offsetof(type, member), \ encoder_type)) +/** + * drmm_plain_simple_encoder_alloc - Allocate and initialize a drm_encoder + * struct with basic functionality. + * @dev: drm device + * @encoder_type: user visible type of the encoder + * + * This performs the same operation as drmm_simple_encoder_alloc(), but + * only allocates and returns a struct drm_encoder instance. + * + * Returns: + * Pointer to the new drm_encoder struct, or ERR_PTR on failure. + */ +#define drmm_plain_simple_encoder_alloc(dev, encoder_type) \ + ((struct drm_encoder *) \ +__drmm_simple_encoder_alloc(dev, sizeof(struct drm_encoder), \ +0, encoder_type)) + #endif /* __LINUX_DRM_SIMPLE_KMS_HELPER_H */ -- 2.29.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 1/4] drm: bridge/panel: Cleanup connector on bridge detach
If we don't call drm_connector_cleanup() manually in
panel_bridge_detach(), the connector will be cleaned up with the other
DRM objects in the call to drm_mode_config_cleanup(). However, since our
drm_connector is devm-allocated, by the time drm_mode_config_cleanup()
will be called, our connector will be long gone. Therefore, the
connector must be cleaned up when the bridge is detached to avoid
use-after-free conditions.
v2: Cleanup connector only if it was created
v3: Add FIXME
Fixes: 13dfc0540a57 ("drm/bridge: Refactor out the panel wrapper from the
lvds-encoder bridge.")
Cc: # 4.12+
Cc: Andrzej Hajda
Cc: Neil Armstrong
Cc: Laurent Pinchart
Cc: Jonas Karlman
Cc: Jernej Skrabec
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/bridge/panel.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 0ddc37551194..5959e8183cd0 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -87,6 +87,18 @@ static int panel_bridge_attach(struct drm_bridge *bridge,
static void panel_bridge_detach(struct drm_bridge *bridge)
{
+ struct panel_bridge *panel_bridge = drm_bridge_to_panel_bridge(bridge);
+ struct drm_connector *connector = &panel_bridge->connector;
+
+ /*
+* Cleanup the connector if we know it was initialized.
+*
+* FIXME: This wouldn't be needed if the panel_bridge structure was
+* allocated with drmm_kzalloc(). This might be tricky since the
+* drm_device pointer can only be retrieved when the bridge is attached.
+*/
+ if (!!panel_bridge->connector.dev)
+ drm_connector_cleanup(connector);
}
static void panel_bridge_pre_enable(struct drm_bridge *bridge)
--
2.29.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gt: use new tasklet API for execution list
From: Emil Renner Berthing
This converts the driver to use the new tasklet API introduced in
commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
Signed-off-by: Emil Renner Berthing
---
Tested on my Dell XPS 13 9300.
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +--
drivers/gpu/drm/i915/gt/intel_lrc.c | 27 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 4 +--
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 6 ++---
4 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 0b31670343f5..a97a80ca0ba7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1193,7 +1193,7 @@ void intel_engine_flush_submission(struct intel_engine_cs
*engine)
{
struct tasklet_struct *t = &engine->execlists.tasklet;
- if (!t->func)
+ if (!t->callback)
return;
/* Synchronise and wait for the tasklet on another CPU */
@@ -1204,7 +1204,7 @@ void intel_engine_flush_submission(struct intel_engine_cs
*engine)
if (tasklet_trylock(t)) {
/* Must wait for any GPU reset in progress. */
if (__tasklet_is_enabled(t))
- t->func(t->data);
+ t->callback(t);
tasklet_unlock(t);
}
local_bh_enable();
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 26c7d0a50585..20aa0ec09507 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -3194,9 +3194,9 @@ static bool preempt_timeout(const struct intel_engine_cs
*const engine)
* Check the unread Context Status Buffers and manage the submission of new
* contexts to the ELSP accordingly.
*/
-static void execlists_submission_tasklet(unsigned long data)
+static void execlists_submission_tasklet(struct tasklet_struct *t)
{
- struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
+ struct intel_engine_cs * const engine = from_tasklet(engine, t,
execlists.tasklet);
bool timeout = preempt_timeout(engine);
process_csb(engine);
@@ -4401,9 +4401,9 @@ static void execlists_reset_rewind(struct intel_engine_cs
*engine, bool stalled)
spin_unlock_irqrestore(&engine->active.lock, flags);
}
-static void nop_submission_tasklet(unsigned long data)
+static void nop_submission_tasklet(struct tasklet_struct *t)
{
- struct intel_engine_cs * const engine = (struct intel_engine_cs *)data;
+ struct intel_engine_cs * const engine = from_tasklet(engine, t,
execlists.tasklet);
/* The driver is wedged; don't process any more events. */
WRITE_ONCE(engine->execlists.queue_priority_hint, INT_MIN);
@@ -4487,7 +4487,7 @@ static void execlists_reset_cancel(struct intel_engine_cs
*engine)
execlists->queue = RB_ROOT_CACHED;
GEM_BUG_ON(__tasklet_is_enabled(&execlists->tasklet));
- execlists->tasklet.func = nop_submission_tasklet;
+ execlists->tasklet.callback = nop_submission_tasklet;
spin_unlock_irqrestore(&engine->active.lock, flags);
}
@@ -4503,7 +4503,7 @@ static void execlists_reset_finish(struct intel_engine_cs
*engine)
*/
GEM_BUG_ON(!reset_in_progress(execlists));
if (!RB_EMPTY_ROOT(&execlists->queue.rb_root))
- execlists->tasklet.func(execlists->tasklet.data);
+ execlists->tasklet.callback(&execlists->tasklet);
if (__tasklet_enable(&execlists->tasklet))
/* And kick in case we missed a new request submission. */
@@ -5093,7 +5093,7 @@ void intel_execlists_set_default_submission(struct
intel_engine_cs *engine)
{
engine->submit_request = execlists_submit_request;
engine->schedule = i915_schedule;
- engine->execlists.tasklet.func = execlists_submission_tasklet;
+ engine->execlists.tasklet.callback = execlists_submission_tasklet;
engine->reset.prepare = execlists_reset_prepare;
engine->reset.rewind = execlists_reset_rewind;
@@ -5220,8 +5220,7 @@ int intel_execlists_submission_setup(struct
intel_engine_cs *engine)
struct intel_uncore *uncore = engine->uncore;
u32 base = engine->mmio_base;
- tasklet_init(&engine->execlists.tasklet,
-execlists_submission_tasklet, (unsigned long)engine);
+ tasklet_setup(&engine->execlists.tasklet, execlists_submission_tasklet);
timer_setup(&engine->execlists.timer, execlists_timeslice, 0);
timer_setup(&engine->execlists.preempt, execlists_preempt, 0);
@@ -5670,9 +5669,9 @@ static intel_engine_mask_t virtual_submission_mask(struct
virtual_engine *ve)
return mask;
}
-static void virtual_submission_tasklet(unsigned long data)
+static void virtual_submission_tasklet(struct tasklet_struct *t)
{
- struct virtual_engine
Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
From: Lucas Nussbaum
Subject: Re: [PATCH 2/2] drm/vc4: Correct POS1_SCL for hvs5
Date: Sat, 23 Jan 2021 09:05:48 +0100
> On 21/01/21 at 11:57 +0100, Maxime Ripard wrote:
>> From: Dom Cobley
>>
>> Fixes failure with 4096x1080 resolutions
>>
>> [ 284.315379] WARNING: CPU: 1 PID: 901 at
>> drivers/gpu/drm/vc4/vc4_plane.c:981 vc4_plane_mode_set+0x1374/0x13c4
>> [ 284.315385] Modules linked in: ir_rc5_decoder rpivid_hevc(C)
>> bcm2835_codec(C) bcm2835_isp(C) bcm2835_mmal_vchiq(C) bcm2835_gpiomem
>> v4l2_mem2mem videobuf2_dma_contig videobuf2_memops videobuf2_v4l2
>> videobuf2_common videodev mc cdc_acm xpad ir_rc6_decoder rc_rc6_mce
>> gpio_ir_recv fuse
>> [ 284.315509] CPU: 1 PID: 901 Comm: kodi.bin Tainted: G C
>> 5.10.7 #1
>> [ 284.315514] Hardware name: BCM2711
>> [ 284.315518] Backtrace:
>> [ 284.315533] [] (dump_backtrace) from []
>> (show_stack+0x20/0x24)
>> [ 284.315540] r7: r6: r5:6813 r4:c18ecf1c
>> [ 284.315549] [] (show_stack) from []
>> (dump_stack+0xc4/0xf0)
>> [ 284.315558] [] (dump_stack) from []
>> (__warn+0xfc/0x158)
>> [ 284.315564] r9: r8:0009 r7:03d5 r6:0009 r5:c08cc7dc
>> r4:c0fd09b8
>> [ 284.315572] [] (__warn) from []
>> (warn_slowpath_fmt+0x74/0xe4)
>> [ 284.315577] r7:c08cc7dc r6:03d5 r5:c0fd09b8 r4:
>> [ 284.315584] [] (warn_slowpath_fmt) from []
>> (vc4_plane_mode_set+0x1374/0x13c4)
>> [ 284.315589] r8: r7: r6:1000 r5:c404c600 r4:c2e34600
>> [ 284.315596] [] (vc4_plane_mode_set) from []
>> (vc4_plane_atomic_check+0x40/0x1c0)
>> [ 284.315601] r10:0001 r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640
>> r5:c3d636c0
>> [ 284.315605] r4:c2e34600
>> [ 284.315614] [] (vc4_plane_atomic_check) from []
>> (drm_atomic_helper_check_planes+0xec/0x1ec)
>> [ 284.315620] r9:c2e34600 r8:c0e67068 r7:c0fc44e0 r6:c2ce3640 r5:c3d636c0
>> r4:0006
>> [ 284.315627] [] (drm_atomic_helper_check_planes) from
>> [] (drm_atomic_helper_check+0x54/0x9c)
>> [ 284.315633] r9:c2e35400 r8:0006 r7: r6:c2ba7800 r5:c3d636c0
>> r4:
>> [ 284.315641] [] (drm_atomic_helper_check) from []
>> (vc4_atomic_check+0x25c/0x454)
>> [ 284.315645] r7: r6:c2ba7800 r5:0001 r4:c3d636c0
>> [ 284.315652] [] (vc4_atomic_check) from []
>> (drm_atomic_check_only+0x5cc/0x7e0)
>> [ 284.315658] r10:c404c6c8 r9: r8:c472c480 r7:0003 r6:c3d636c0
>> r5:
>> [ 284.315662] r4:003c r3:c08b7a4c
>> [ 284.315670] [] (drm_atomic_check_only) from []
>> (drm_mode_atomic_ioctl+0x758/0xa7c)
>> [ 284.315675] r10:c3d46000 r9:c3d636c0 r8:c2ce8a70 r7:027e3a54 r6:0043
>> r5:c1fbb800
>> [ 284.315679] r4:0281a858
>> [ 284.315688] [] (drm_mode_atomic_ioctl) from []
>> (drm_ioctl_kernel+0xc4/0x108)
>> [ 284.315693] r10:c03864bc r9:c1fbb800 r8:c3d47e64 r7:c089b308 r6:0002
>> r5:c2ba7800
>> [ 284.315697] r4:
>> [ 284.315705] [] (drm_ioctl_kernel) from []
>> (drm_ioctl+0x1e8/0x3a0)
>> [ 284.315711] r9:c1fbb800 r8:00bc r7:c3d47e64 r6:0038 r5:c0e59570
>> r4:0038
>> [ 284.315719] [] (drm_ioctl) from []
>> (sys_ioctl+0x35c/0x914)
>> [ 284.315724] r10:c2d08200 r9: r8:c36fa300 r7:befdd870 r6:c03864bc
>> r5:c36fa301
>> [ 284.315728] r4:c03864bc
>> [ 284.315735] [] (sys_ioctl) from []
>> (ret_fast_syscall+0x0/0x28)
>> [ 284.315739] Exception stack(0xc3d47fa8 to 0xc3d47ff0)
>> [ 284.315745] 7fa0: 027eb750 befdd870 c03864bc
>> befdd870
>> [ 284.315750] 7fc0: 027eb750 befdd870 c03864bc 0036 027e3948 0281a640
>> 0281a850 027e3a50
>> [ 284.315756] 7fe0: b4b64100 befdd844 b4b5ba2c b49c994c
>> [ 284.315762] r10:0036 r9:c3d46000 r8:c0200204 r7:0036 r6:c03864bc
>> r5:befdd870
>> [ 284.315765] r4:027eb750
>>
>> Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5")
>> Signed-off-by: Dom Cobley
>> Signed-off-by: Maxime Ripard
>
> Tested-By: Lucas Nussbaum
Tested-By: Ryutaroh Matsumoto
Thank you very much for all of your work!
Ryutaroh
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 209713] amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
https://bugzilla.kernel.org/show_bug.cgi?id=209713 --- Comment #11 from Oliver Reeh (oli...@diereehs.de) --- The problem is back with kernel 5.10.10. [ 89.664494] WARNING: CPU: 6 PID: 4323 at drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x94/0xc0 [amdgpu] -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix HDMI_STATIC_METADATA_TYPE1 constant.
On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner
wrote:
> According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> not 1, but zero, so fix this enum.
>
> While this doesn't cause problems in the kernel yet, as the
> constant isn't actively used by drivers yet, it did create
> confusion while debugging HDR problems in yours truly, and
> also potential bugs in userspace components, as the wrong
> enum propagates to components, e.g., like it did already
> into intel-gpu-tools (tests/kms_hdr.c) or is used as wrong
> reference when writing future new userspace HDR components
> like compositors.
>
> Fixes: fbb5d0353c62 ("drm: Add HDR source metadata property")
> Signed-off-by: Mario Kleiner
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
Sadly I think it's too late for this. Some user-space (like Kodi)
already has copied over the kernel definitions, and libdrm already has
a release with the wrong value.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
