From: "Ser, Simon" <simon.ser@intel.com> To: "Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com> Cc: "rodrigosiqueiramelo@gmail.com" <rodrigosiqueiramelo@gmail.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>, "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>, "nd@arm.com" <nd@arm.com> Subject: Re: [igt-dev] [PATCH V6 i-g-t 2/6] kms_writeback: Add initial writeback tests Date: Thu, 18 Jul 2019 11:46:11 +0000 [thread overview] Message-ID: <f12fb4326c07e8680950cc17064360bc4707dd9d.camel@intel.com> (raw) In-Reply-To: <20190718111502.GC5942@e110455-lin.cambridge.arm.com> On Thu, 2019-07-18 at 12:15 +0100, Liviu.Dudau@arm.com wrote: > On Thu, Jul 18, 2019 at 09:56:39AM +0000, Ser, Simon wrote: > > On Thu, 2019-07-18 at 10:49 +0100, Liviu.Dudau@arm.com wrote: > > > On Wed, Jul 17, 2019 at 11:46:39AM +0000, Ser, Simon wrote: > > > > Thanks for the clarification! > > > > > > > > On Tue, 2019-07-16 at 16:22 +0100, Liviu.Dudau@arm.com wrote: > > > > > > > > +static void invalid_out_fence(igt_output_t *output, igt_fb_t *valid_fb, igt_fb_t *invalid_fb) > > > > > > > > +{ > > > > > > > > + int i, ret; > > > > > > > > + int32_t out_fence; > > > > > > > > + struct { > > > > > > > > + uint32_t fb_id; > > > > > > > > + bool ptr_valid; > > > > > > > > + int32_t *out_fence_ptr; > > > > > > > > + } invalid_tests[] = { > > > > > > > > + { > > > > > > > > + /* No output buffer, but the WRITEBACK_OUT_FENCE_PTR set. */ > > > > > > > > + .fb_id = 0, > > > > > > > > + .ptr_valid = true, > > > > > > > > + .out_fence_ptr = &out_fence, > > > > > > > > + }, > > > > > > > > + { > > > > > > > > + /* Invalid output buffer. */ > > > > > > > > + .fb_id = invalid_fb->fb_id, > > > > > > > > + .ptr_valid = true, > > > > > > > > + .out_fence_ptr = &out_fence, > > > > > > > > + }, > > > > > > > > > > > > > > This doesn't belong in this function (invalid_out_fence), since this > > > > > > > checks an invalid framebuffer, not an invalid fence. We should probably > > > > > > > move it to writeback_fb_id (and rename that function to test_fb?). > > > > > > > > > > It tries to test that you can't trick the driver to do any work on a fence if > > > > > the framebuffer is invalid, so the set of tests tries: no fb with valid fence, > > > > > invalid fb with valid fence, valid fb but invalid fence and assumes that no > > > > > fb with invalid fence is a NOP anyway. > > > > > > > > Yeah, that makes sense, it's just confusing to put it in a function > > > > named invalid_out_fence. Here the out fence is valid, but the output > > > > buffer isn't, so it should probably be moved away (or this function > > > > should be renamed). > > > > > > Don't want to offend or anything, but this does sound like bikeshedding. You > > > have a couple of parameters that you want to have a test for because they are > > > linked together (output framebuffer and fence) and you go through the > > > combination of possible bad options in the test. Not sure what name we can use > > > for the function, other than maybe 'test_invalid_parameters'? Given that 2/3 > > > tests an invalid out fence, the name was thought to be relevant. > > > > > > Having invalid out buffer test separate into its own test brings no benefits, IMHO. > > > > Well, the issue is that I've been confused when reviewing the patch > > series. I had trouble understanding what the test does and why. I also > > had trouble to identify that do_writeback_test never submits a > > writeback operation (see other e-mail). > > > > A name that is relevant "all the time, most of the time", is not > > relevant at all in my opinion. It just tricks the reader into thinking > > the test does one thing, while it also does something else. > > > > If it would be obvious, I wouldn't mind. But here IMHO it hurts > > readability. So I'd prefer to rename the function. > > I take your comments as a valid point. > > Does "test_invalid_parameters" sound like a good name for the function? Is so, > Rodrigo, can you please use that name in the next revision of the patch? Yes, this name sounds perfectly fine :) > > If you think it's obvious, then maybe it's just me. I'd love to hear > > from others if they have a different opinion. > > > > (As a side note, I agree I have a tendency to bikeshed, I try to mark > > my bikesheddings behind "nit:" flags.) > > I've only said "it sounded like" :) Eheh :P > Best regards, > Liviu > > > > Best regards, > > > Liviu > > > > > > > > > > > + { > > > > > > > > + /* Invalid WRITEBACK_OUT_FENCE_PTR. */ > > > > > > > > + .fb_id = valid_fb->fb_id, > > > > > > > > + .ptr_valid = false, > > > > > > > > + .out_fence_ptr = (int32_t *)0x8, > > > > > > > > + }, > > > > > > > > + }; > > > > > > > > + > > > > > > > > + for (i = 0; i < ARRAY_SIZE(invalid_tests); i++) { > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + invalid_tests[i].fb_id, > > > > > > > > + invalid_tests[i].out_fence_ptr, > > > > > > > > + invalid_tests[i].ptr_valid); > > > > > > > > + igt_assert(ret != 0); > > > > > > > > > > > > > > Maybe we can check for -ret == EINVAL? > > > > > > > > > > > > > > > + } > > > > > > > > +} > > > > > > > > + > > > > > > > > +static void writeback_fb_id(igt_output_t *output, igt_fb_t *valid_fb, igt_fb_t *invalid_fb) > > > > > > > > > > > > > > invalid_fb doesn't seem to be used here. valid_fb seems to be set to > > > > > > > the input framebuffer. It's probably not a good idea to use the same FB > > > > > > > for input and writeback output. > > > > > > > > > > > > > > > +{ > > > > > > > > + > > > > > > > > + int ret; > > > > > > > > + > > > > > > > > + /* Valid output buffer */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + valid_fb->fb_id, NULL, false); > > > > > > > > + igt_assert(ret == 0); > > > > > > > > + > > > > > > > > + /* Invalid object for WRITEBACK_FB_ID */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + output->id, NULL, false); > > > > > > > > + igt_assert(ret == -EINVAL); > > > > > > > > + > > > > > > > > + /* Zero WRITEBACK_FB_ID */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + 0, NULL, false); > > > > > > > > + igt_assert(ret == 0); > > > > > > > > +} > > > > > > > > + > > > > > > > > +igt_main > > > > > > > > +{ > > > > > > > > + igt_display_t display; > > > > > > > > + igt_output_t *output; > > > > > > > > + igt_plane_t *plane; > > > > > > > > + igt_fb_t input_fb; > > > > > > > > + drmModeModeInfo mode; > > > > > > > > + int ret; > > > > > > > > + > > > > > > > > + memset(&display, 0, sizeof(display)); > > > > > > > > + > > > > > > > > + igt_fixture { > > > > > > > > + display.drm_fd = drm_open_driver_master(DRIVER_ANY); > > > > > > > > + igt_display_require(&display, display.drm_fd); > > > > > > > > + > > > > > > > > + kmstest_set_vt_graphics_mode(); > > > > > > > > + > > > > > > > > + igt_display_require(&display, display.drm_fd); > > > > > > > > + > > > > > > > > + igt_require(display.is_atomic); > > > > > > > > + > > > > > > > > + output = kms_writeback_get_output(&display); > > > > > > > > + igt_require(output); > > > > > > > > + > > > > > > > > + if (output->use_override_mode) > > > > > > > > + memcpy(&mode, &output->override_mode, sizeof(mode)); > > > > > > > > + else > > > > > > > > + memcpy(&mode, &output->config.default_mode, sizeof(mode)); > > > > > > > > + > > > > > > > > + plane = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); > > > > > > > > + igt_require(plane); > > > > > > > > > > > > > > Maybe we can assert on this? > > > > > > > > > > > > > > > + ret = igt_create_fb(display.drm_fd, mode.hdisplay, > > > > > > > > + mode.vdisplay, > > > > > > > > + DRM_FORMAT_XRGB8888, > > > > > > > > + igt_fb_mod_to_tiling(0), > > > > > > > > > > > > > > This is supposed to take a modifier. DRM_FORMAT_MOD_LINEAR would be > > > > > > > better to make this clear. > > > > > > > > > > Agree. The patchset pre-dates the modifiers support (or has the same age, I > > > > > forgot) > > > > > > > > > > > > (Applies to other lines of this patch) > > > > > > > > > > > > > > > + &input_fb); > > > > > > > > + igt_assert(ret >= 0); > > > > > > > > + igt_plane_set_fb(plane, &input_fb); > > > > > > > > + } > > > > > > > > + > > > > > > > > + igt_subtest("writeback-pixel-formats") { > > > > > > > > + drmModePropertyBlobRes *formats_blob = get_writeback_formats_blob(output); > > > > > > > > > > > > > > Need to drmModeFreePropertyBlob this. > > > > > > > > > > > > > > > + const char *valid_chars = "0123456 ABCGNRUVXY"; > > > > > > > > + unsigned int i; > > > > > > > > + char *c; > > > > > > > > + > > > > > > > > + /* > > > > > > > > + * We don't have a comprehensive list of formats, so just check > > > > > > > > + * that the blob length is sensible and that it doesn't contain > > > > > > > > + * any outlandish characters > > > > > > > > + */ > > > > > > > > + igt_assert(!(formats_blob->length % 4)); > > > > > > > > + c = formats_blob->data; > > > > > > > > + for (i = 0; i < formats_blob->length; i++) > > > > > > > > + igt_assert_f(strchr(valid_chars, c[i]), > > > > > > > > + "Unexpected character %c\n", c[i]); > > > > > > > > > > > > > > Honestly, I'm not a fan of this check. There's no guarantee that fourcc > > > > > > > codes will be made from ASCII characters, in fact some formats already > > > > > > > have non-printable chars in them. I don't want to have to update this > > > > > > > test when a new fourcc format is added. > > > > > > > > > > Like the comments says, we don't have a full list of formats to check against. > > > > > Suggestions on how to improve are welcome, but I don't think we should delay > > > > > (any longer) the patchset due to this. > > > > > > > > Agreed. > > > > > > > > > Best regards, > > > > > Liviu _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: "Ser, Simon" <simon.ser@intel.com> To: "Liviu.Dudau@arm.com" <Liviu.Dudau@arm.com> Cc: "Latvala, Petri" <petri.latvala@intel.com>, "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>, "igt-dev@lists.freedesktop.org" <igt-dev@lists.freedesktop.org>, "daniel@ffwll.ch" <daniel@ffwll.ch>, "nd@arm.com" <nd@arm.com>, "Brian.Starkey@arm.com" <Brian.Starkey@arm.com> Subject: Re: [igt-dev] [PATCH V6 i-g-t 2/6] kms_writeback: Add initial writeback tests Date: Thu, 18 Jul 2019 11:46:11 +0000 [thread overview] Message-ID: <f12fb4326c07e8680950cc17064360bc4707dd9d.camel@intel.com> (raw) In-Reply-To: <20190718111502.GC5942@e110455-lin.cambridge.arm.com> On Thu, 2019-07-18 at 12:15 +0100, Liviu.Dudau@arm.com wrote: > On Thu, Jul 18, 2019 at 09:56:39AM +0000, Ser, Simon wrote: > > On Thu, 2019-07-18 at 10:49 +0100, Liviu.Dudau@arm.com wrote: > > > On Wed, Jul 17, 2019 at 11:46:39AM +0000, Ser, Simon wrote: > > > > Thanks for the clarification! > > > > > > > > On Tue, 2019-07-16 at 16:22 +0100, Liviu.Dudau@arm.com wrote: > > > > > > > > +static void invalid_out_fence(igt_output_t *output, igt_fb_t *valid_fb, igt_fb_t *invalid_fb) > > > > > > > > +{ > > > > > > > > + int i, ret; > > > > > > > > + int32_t out_fence; > > > > > > > > + struct { > > > > > > > > + uint32_t fb_id; > > > > > > > > + bool ptr_valid; > > > > > > > > + int32_t *out_fence_ptr; > > > > > > > > + } invalid_tests[] = { > > > > > > > > + { > > > > > > > > + /* No output buffer, but the WRITEBACK_OUT_FENCE_PTR set. */ > > > > > > > > + .fb_id = 0, > > > > > > > > + .ptr_valid = true, > > > > > > > > + .out_fence_ptr = &out_fence, > > > > > > > > + }, > > > > > > > > + { > > > > > > > > + /* Invalid output buffer. */ > > > > > > > > + .fb_id = invalid_fb->fb_id, > > > > > > > > + .ptr_valid = true, > > > > > > > > + .out_fence_ptr = &out_fence, > > > > > > > > + }, > > > > > > > > > > > > > > This doesn't belong in this function (invalid_out_fence), since this > > > > > > > checks an invalid framebuffer, not an invalid fence. We should probably > > > > > > > move it to writeback_fb_id (and rename that function to test_fb?). > > > > > > > > > > It tries to test that you can't trick the driver to do any work on a fence if > > > > > the framebuffer is invalid, so the set of tests tries: no fb with valid fence, > > > > > invalid fb with valid fence, valid fb but invalid fence and assumes that no > > > > > fb with invalid fence is a NOP anyway. > > > > > > > > Yeah, that makes sense, it's just confusing to put it in a function > > > > named invalid_out_fence. Here the out fence is valid, but the output > > > > buffer isn't, so it should probably be moved away (or this function > > > > should be renamed). > > > > > > Don't want to offend or anything, but this does sound like bikeshedding. You > > > have a couple of parameters that you want to have a test for because they are > > > linked together (output framebuffer and fence) and you go through the > > > combination of possible bad options in the test. Not sure what name we can use > > > for the function, other than maybe 'test_invalid_parameters'? Given that 2/3 > > > tests an invalid out fence, the name was thought to be relevant. > > > > > > Having invalid out buffer test separate into its own test brings no benefits, IMHO. > > > > Well, the issue is that I've been confused when reviewing the patch > > series. I had trouble understanding what the test does and why. I also > > had trouble to identify that do_writeback_test never submits a > > writeback operation (see other e-mail). > > > > A name that is relevant "all the time, most of the time", is not > > relevant at all in my opinion. It just tricks the reader into thinking > > the test does one thing, while it also does something else. > > > > If it would be obvious, I wouldn't mind. But here IMHO it hurts > > readability. So I'd prefer to rename the function. > > I take your comments as a valid point. > > Does "test_invalid_parameters" sound like a good name for the function? Is so, > Rodrigo, can you please use that name in the next revision of the patch? Yes, this name sounds perfectly fine :) > > If you think it's obvious, then maybe it's just me. I'd love to hear > > from others if they have a different opinion. > > > > (As a side note, I agree I have a tendency to bikeshed, I try to mark > > my bikesheddings behind "nit:" flags.) > > I've only said "it sounded like" :) Eheh :P > Best regards, > Liviu > > > > Best regards, > > > Liviu > > > > > > > > > > > + { > > > > > > > > + /* Invalid WRITEBACK_OUT_FENCE_PTR. */ > > > > > > > > + .fb_id = valid_fb->fb_id, > > > > > > > > + .ptr_valid = false, > > > > > > > > + .out_fence_ptr = (int32_t *)0x8, > > > > > > > > + }, > > > > > > > > + }; > > > > > > > > + > > > > > > > > + for (i = 0; i < ARRAY_SIZE(invalid_tests); i++) { > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + invalid_tests[i].fb_id, > > > > > > > > + invalid_tests[i].out_fence_ptr, > > > > > > > > + invalid_tests[i].ptr_valid); > > > > > > > > + igt_assert(ret != 0); > > > > > > > > > > > > > > Maybe we can check for -ret == EINVAL? > > > > > > > > > > > > > > > + } > > > > > > > > +} > > > > > > > > + > > > > > > > > +static void writeback_fb_id(igt_output_t *output, igt_fb_t *valid_fb, igt_fb_t *invalid_fb) > > > > > > > > > > > > > > invalid_fb doesn't seem to be used here. valid_fb seems to be set to > > > > > > > the input framebuffer. It's probably not a good idea to use the same FB > > > > > > > for input and writeback output. > > > > > > > > > > > > > > > +{ > > > > > > > > + > > > > > > > > + int ret; > > > > > > > > + > > > > > > > > + /* Valid output buffer */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + valid_fb->fb_id, NULL, false); > > > > > > > > + igt_assert(ret == 0); > > > > > > > > + > > > > > > > > + /* Invalid object for WRITEBACK_FB_ID */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + output->id, NULL, false); > > > > > > > > + igt_assert(ret == -EINVAL); > > > > > > > > + > > > > > > > > + /* Zero WRITEBACK_FB_ID */ > > > > > > > > + ret = do_writeback_test(output, DRM_MODE_ATOMIC_ALLOW_MODESET, > > > > > > > > + 0, NULL, false); > > > > > > > > + igt_assert(ret == 0); > > > > > > > > +} > > > > > > > > + > > > > > > > > +igt_main > > > > > > > > +{ > > > > > > > > + igt_display_t display; > > > > > > > > + igt_output_t *output; > > > > > > > > + igt_plane_t *plane; > > > > > > > > + igt_fb_t input_fb; > > > > > > > > + drmModeModeInfo mode; > > > > > > > > + int ret; > > > > > > > > + > > > > > > > > + memset(&display, 0, sizeof(display)); > > > > > > > > + > > > > > > > > + igt_fixture { > > > > > > > > + display.drm_fd = drm_open_driver_master(DRIVER_ANY); > > > > > > > > + igt_display_require(&display, display.drm_fd); > > > > > > > > + > > > > > > > > + kmstest_set_vt_graphics_mode(); > > > > > > > > + > > > > > > > > + igt_display_require(&display, display.drm_fd); > > > > > > > > + > > > > > > > > + igt_require(display.is_atomic); > > > > > > > > + > > > > > > > > + output = kms_writeback_get_output(&display); > > > > > > > > + igt_require(output); > > > > > > > > + > > > > > > > > + if (output->use_override_mode) > > > > > > > > + memcpy(&mode, &output->override_mode, sizeof(mode)); > > > > > > > > + else > > > > > > > > + memcpy(&mode, &output->config.default_mode, sizeof(mode)); > > > > > > > > + > > > > > > > > + plane = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); > > > > > > > > + igt_require(plane); > > > > > > > > > > > > > > Maybe we can assert on this? > > > > > > > > > > > > > > > + ret = igt_create_fb(display.drm_fd, mode.hdisplay, > > > > > > > > + mode.vdisplay, > > > > > > > > + DRM_FORMAT_XRGB8888, > > > > > > > > + igt_fb_mod_to_tiling(0), > > > > > > > > > > > > > > This is supposed to take a modifier. DRM_FORMAT_MOD_LINEAR would be > > > > > > > better to make this clear. > > > > > > > > > > Agree. The patchset pre-dates the modifiers support (or has the same age, I > > > > > forgot) > > > > > > > > > > > > (Applies to other lines of this patch) > > > > > > > > > > > > > > > + &input_fb); > > > > > > > > + igt_assert(ret >= 0); > > > > > > > > + igt_plane_set_fb(plane, &input_fb); > > > > > > > > + } > > > > > > > > + > > > > > > > > + igt_subtest("writeback-pixel-formats") { > > > > > > > > + drmModePropertyBlobRes *formats_blob = get_writeback_formats_blob(output); > > > > > > > > > > > > > > Need to drmModeFreePropertyBlob this. > > > > > > > > > > > > > > > + const char *valid_chars = "0123456 ABCGNRUVXY"; > > > > > > > > + unsigned int i; > > > > > > > > + char *c; > > > > > > > > + > > > > > > > > + /* > > > > > > > > + * We don't have a comprehensive list of formats, so just check > > > > > > > > + * that the blob length is sensible and that it doesn't contain > > > > > > > > + * any outlandish characters > > > > > > > > + */ > > > > > > > > + igt_assert(!(formats_blob->length % 4)); > > > > > > > > + c = formats_blob->data; > > > > > > > > + for (i = 0; i < formats_blob->length; i++) > > > > > > > > + igt_assert_f(strchr(valid_chars, c[i]), > > > > > > > > + "Unexpected character %c\n", c[i]); > > > > > > > > > > > > > > Honestly, I'm not a fan of this check. There's no guarantee that fourcc > > > > > > > codes will be made from ASCII characters, in fact some formats already > > > > > > > have non-printable chars in them. I don't want to have to update this > > > > > > > test when a new fourcc format is added. > > > > > > > > > > Like the comments says, we don't have a full list of formats to check against. > > > > > Suggestions on how to improve are welcome, but I don't think we should delay > > > > > (any longer) the patchset due to this. > > > > > > > > Agreed. > > > > > > > > > Best regards, > > > > > Liviu _______________________________________________ igt-dev mailing list igt-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/igt-dev
next prev parent reply other threads:[~2019-07-18 11:46 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-06-13 2:14 [PATCH V6 i-g-t 0/6] igt: Add support for testing writeback connectors Rodrigo Siqueira 2019-06-13 2:14 ` [igt-dev] " Rodrigo Siqueira 2019-06-13 2:16 ` [PATCH V6 i-g-t 1/6] lib/igt_kms: Add writeback support Brian Starkey 2019-06-13 2:16 ` [Intel-gfx] " Brian Starkey 2019-06-13 14:54 ` Liviu Dudau 2019-06-13 14:54 ` [igt-dev] " Liviu Dudau 2019-06-18 21:56 ` Rodrigo Siqueira 2019-06-18 21:56 ` [igt-dev] " Rodrigo Siqueira 2019-07-03 12:15 ` Ser, Simon 2019-07-03 12:15 ` Ser, Simon 2019-07-09 14:32 ` Rodrigo Siqueira 2019-07-09 14:32 ` Rodrigo Siqueira 2019-07-09 14:42 ` Ser, Simon 2019-07-09 14:42 ` Ser, Simon 2019-07-09 15:07 ` Rodrigo Siqueira 2019-07-09 15:07 ` Rodrigo Siqueira 2019-07-10 8:48 ` Ser, Simon 2019-07-10 8:48 ` Ser, Simon 2019-06-13 2:16 ` [PATCH V6 i-g-t 2/6] kms_writeback: Add initial writeback tests Brian Starkey 2019-06-13 2:16 ` [igt-dev] " Brian Starkey 2019-07-10 11:57 ` Ser, Simon 2019-07-10 11:57 ` Ser, Simon 2019-07-12 2:44 ` Rodrigo Siqueira 2019-07-12 2:44 ` Rodrigo Siqueira 2019-07-12 11:40 ` Ser, Simon 2019-07-12 11:40 ` Ser, Simon 2019-07-17 1:21 ` Rodrigo Siqueira 2019-07-17 1:21 ` Rodrigo Siqueira 2019-07-17 13:00 ` Ser, Simon 2019-07-17 13:00 ` Ser, Simon 2019-07-16 15:22 ` Liviu.Dudau 2019-07-16 15:22 ` Liviu.Dudau 2019-07-17 11:46 ` Ser, Simon 2019-07-17 11:46 ` [Intel-gfx] " Ser, Simon 2019-07-18 9:49 ` Liviu.Dudau 2019-07-18 9:49 ` Liviu.Dudau 2019-07-18 9:56 ` Ser, Simon 2019-07-18 9:56 ` Ser, Simon 2019-07-18 11:15 ` Liviu.Dudau 2019-07-18 11:15 ` Liviu.Dudau 2019-07-18 11:46 ` Ser, Simon [this message] 2019-07-18 11:46 ` Ser, Simon 2019-07-19 1:21 ` Rodrigo Siqueira 2019-07-19 1:21 ` Rodrigo Siqueira 2019-06-13 2:17 ` [PATCH V6 i-g-t 3/6] lib: Add function to hash a framebuffer Brian Starkey 2019-06-13 2:17 ` [Intel-gfx] " Brian Starkey 2019-07-10 15:30 ` [igt-dev] " Ser, Simon 2019-07-10 15:30 ` Ser, Simon 2019-07-10 15:34 ` Ser, Simon 2019-07-10 15:34 ` Ser, Simon 2019-07-12 2:49 ` Rodrigo Siqueira 2019-07-12 2:49 ` Rodrigo Siqueira 2019-07-12 12:17 ` Ser, Simon 2019-07-12 12:17 ` Ser, Simon 2019-07-17 1:25 ` Rodrigo Siqueira 2019-07-17 1:25 ` Rodrigo Siqueira 2019-06-13 2:17 ` [PATCH V6 i-g-t 4/6] kms_writeback: Add writeback-check-output Brian Starkey 2019-06-13 2:17 ` [igt-dev] " Brian Starkey 2019-07-12 12:34 ` Ser, Simon 2019-07-12 12:34 ` Ser, Simon 2019-06-13 2:18 ` [PATCH V6 i-g-t 5/6] lib/igt_kms: Add igt_output_clone_pipe for cloning Brian Starkey 2019-06-13 2:18 ` [igt-dev] " Brian Starkey 2019-07-12 12:54 ` Ser, Simon 2019-07-12 12:54 ` Ser, Simon 2019-07-17 1:47 ` Rodrigo Siqueira 2019-07-17 1:47 ` Rodrigo Siqueira 2019-07-17 13:10 ` Ser, Simon 2019-07-17 13:10 ` Ser, Simon 2019-06-13 2:19 ` [PATCH V6 i-g-t 6/6] kms_writeback: Add tests using a cloned output Brian Starkey 2019-06-13 2:19 ` [igt-dev] " Brian Starkey 2019-06-13 3:38 ` [igt-dev] ✗ Fi.CI.BAT: failure for igt: Add support for testing writeback connectors (rev6) Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=f12fb4326c07e8680950cc17064360bc4707dd9d.camel@intel.com \ --to=simon.ser@intel.com \ --cc=Liviu.Dudau@arm.com \ --cc=igt-dev@lists.freedesktop.org \ --cc=intel-gfx@lists.freedesktop.org \ --cc=nd@arm.com \ --cc=rodrigosiqueiramelo@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.