On Tue, May 01, 2018 at 10:58:02AM +0200, Maarten Lankhorst wrote:
> Hey,
>
> Op 30-04-18 om 16:56 schreef Daniel Vetter:
> > On Mon, Apr 30, 2018 at 04:55:24PM +0200, Daniel Vetter wrote:
> >> On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> >>> Hi Daniel,
> >>>
> >>> (Removing the linux-media mailing list from CC as it is out of scope)
> >>>
> >>> You enquired on IRC whether this patch series passes the igt CRC tests.
> >>>
> >>> # ./kms_pipe_crc_basic --run-subtest read-crc-pipe-A
> >>> IGT-Version: 1.22-gf447f5fc531d (aarch64) (Linux:
> >>> 4.17.0-rc1-00085-g56e849d93cc9 aarch64)
> >>> read-crc-pipe-A: Testing connector LVDS-1 using pipe A
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> >>> function igt_pipe_crc_start, file igt_debugfs.c:764:
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> >>> pipe_crc->crc_fd != -1
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5,
> >>> Input/output error
> >>> Stack trace:
> >>> Subtest read-crc-pipe-A failed.
> >>> **** DEBUG ****
> >>> (kms_pipe_crc_basic:1638) DEBUG: Test requirement passed: !(pipe >=
> >>> data->display.n_pipes)
> >>> (kms_pipe_crc_basic:1638) INFO: read-crc-pipe-A: Testing connector LVDS-1
> >>> using pipe A
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: set_pipe(A)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: Selecting pipe A
> >>> (kms_pipe_crc_basic:1638) DEBUG: Clearing the fb with color
> >>> (0.00,1.00,0.00)
> >>> (kms_pipe_crc_basic:1638) igt-fb-DEBUG:
> >>> igt_create_fb_with_bo_size(width=1024, height=768, format=0x34325258,
> >>> tiling=0x0, size=0)
> >>> (kms_pipe_crc_basic:1638) igt-fb-DEBUG:
> >>> igt_create_fb_with_bo_size(handle=1, pitch=4096)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: Test requirement passed:
> >>> plane_idx >= 0 && plane_idx < pipe->n_planes
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_fb(140)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0: plane_set_size
> >>> (1024x768)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0:
> >>> fb_set_position(0,0)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: A.0:
> >>> fb_set_size(1024x768)
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: commit {
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: LVDS-1: SetCrtc
> >>> pipe A, fb 140, src (0, 0), mode 1024x768
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe A,
> >>> disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> >>> plane 2, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> >>> plane 3, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe A,
> >>> plane 4, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe B,
> >>> disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> >>> plane 1, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> >>> plane 2, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> >>> plane 3, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe B,
> >>> plane 4, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe C,
> >>> disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> >>> plane 1, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> >>> plane 2, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> >>> plane 3, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe C,
> >>> plane 4, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> >>> disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetCrtc pipe D,
> >>> disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> >>> plane 2, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> >>> plane 3, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: SetPlane pipe D,
> >>> plane 4, disabling
> >>> (kms_pipe_crc_basic:1638) igt-kms-DEBUG: display: }
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> >>> '/sys/kernel/debug/dri/0'
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-DEBUG: Opening debugfs directory
> >>> '/sys/kernel/debug/dri/0'
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Test assertion failure
> >>> function igt_pipe_crc_start, file igt_debugfs.c:764:
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Failed assertion:
> >>> pipe_crc->crc_fd != -1
> >>> (kms_pipe_crc_basic:1638) igt-debugfs-CRITICAL: Last errno: 5,
> >>> Input/output error
> >>> (kms_pipe_crc_basic:1638) igt-core-INFO: Stack trace:
> >>> **** END ****
> >>> Subtest read-crc-pipe-A: FAIL (0.061s)
> >>>
> >>> I think the answer is no, but I don't think it's the fault of this patch
> >>> series. Opening the CRC data file returns -EIO because the CRTC is not
> >>> active,
> >>> and I'm trying to find out why that is the case. The debug log shows a
> >>> commit
> >>> that seems strange to me, enabling pipe A and immediately disabling right
> >>> afterwards. After some investigation I believe that this is caused by
> >>> sharing
> >>> primary planes between CRTCs.
> >>>
> >>> The R-Car DU groups CRTCs by two and shares 5 planes between the two
> >>> CRTCs of
> >>> the group. This specific SoC has two groups of two CRTCs, but that's not
> >>> relevant here, so we can ignore pipes C and D.
> >>>
> >>> Pipes A and B thus shared 5 planes that I will number 0 to 4 for
> >>> simplicity.
> >>> The driver sets plane 0 as the primary plane for CRTC A and plane 1 as the
> >>> primary plane for CRTC B. Planes 2, 3 and 4 are created as overlay planes.
> >>>
> >>> When igt iterates over all planes for pipe A, it will first encounter
> >>> plane 0
> >>> that has a framebuffer, and thus enables the pipe. It then iterates over
> >>> plane 1, recognizes it as a primary plane without a framebuffer, and thus
> >>> disables the pipe. Planes 2, 3 and 4 are recognized as overlay planes and
> >>> thus
> >>> don't affect the pipe active state. Pipe B is handled the same way, and
> >>> igt
> >>> disables it twice as planes 0 and 1 are primary.
> >>>
> >>> I don't know if the fault here is with igt that doesn't properly support
> >>> this
> >>> architecture, or with the driver that shouldn't have two primary planes
> >>> available for a CRTC. In the former case, I'm not sure how to fix it, as
> >>> I'm
> >>> not familiar enough with igt to rearchitecture the commit helpers. In the
> >>> latter case, how would you recommend fixing it on the driver side ?
> >> I guess thus far no one did run igt on a chip which did have reassignable
> >> primary planes. The problem here is that it's pretty hard to figure out
> >> which one is the real primary plane, since with possible CRTCs you could
> >> have multiple primary planes on 1 CRTC. There's no property or anything
> >> that explicitly tells you this. Two fixes:
> >>
> >> 1. Change drivers to limit primary planes to 1 crtc. Same for cursor
> >> overlays. There's probably other userspace than igt that gets confused
> >> by this, but this has the ugly downside that we artifically limit plane
> >> usage - if only 1 CRTC is on, we want to use all the available planes
> >> on that one.
> >>
> >> 2. Add some implicit or explicit uapi to allow userspace to figure out
> >> which primary plane is the primary plane for this crtc.
> >>
> >> a) Explicit option: We add a PRIMARY_ID property (and CURSOR_ID prop
> >> while at it) on the CRTC which points at the primary/cursor plane.
> >>
> >> b) Implicit option: We require primary planes are assigned to CRTC in
> >> the
> >> same order as they're created. So first primary plane you encouter
> >> is the one for the first CRTC, 2nd primary plane is the one for the
> >> 2nd CRTC and so on. If we go with this we probably should add a bit
> >> of code to the kernel to check that invariant (by making sure the
> >> primary plane has the corresponding CRTC included in its
> >> possible_crtc mask).
> >>
> >> Either way igt needs to be patched to not treat any primary plane that
> >> could work on a CRTC as the primary plane for that CRTC.
> >>
> >> Personally I'm leaning towards 2b).
> > Adding Maarten and igt-dev.
>
> We should first make the plane array global, instead of per crtc.
>
> That means removing plane->pipe and plane->index.
>
> And pipe_obj->planes and pipe_obj->n_planes need to be gone too. I think it's
> easiest to make
>
> There is one problem. Most of the tests are not aware of the limitations.
> If we make the plane array global it should be possible to make
> a for_each_possible_plane_on_pipe enumerate all planes that could be assigned
> to a certain pipe. We need to sort by z order somehow, but if we then add
> igt_plane_set_pipe() which updates the IGT_PLANE_CRTC_ID property, we should
> be good.
>
> Only thing we don't see is how the default crtc->primary and crtc->cursor are
> assigned. For the calls with COMMIT_LEGACY we need to know the mappings, but
> I don't think the kernel exposes them?
> I guess we could put it in a FIFO way, first enumerated plane with PRIMARY
> type
> is bound to the first crtc, same for cursor.
Solutions for that problem is what I proposed in my mail, since atm the
kernel is indeed not exposing that in any fasion.
> This will hopefully allow legacy tests to keep working, while atomic plane
> aware
> tests will be able to use all planes.
Yeah ..
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
