Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_display.c | 51
include/uapi/drm/drm_fourcc.h| 20 ++
2 files changed, 71 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
lo
Hi,
Here's the kernel counterpart to the Mesa series exposing Y-tiled CCS at:
https://lists.freedesktop.org/archives/mesa-dev/2017-May/156184.html
All the patches are Ville's, I've just rebased and squashed. They depend
on Ben's last modifier-advertisement series, plus the fixup I sent
in reply to
non-generic allocator can pad the stride/size in an acceptable way.
Add explicit halign/valign members which allow a particular format to
have more loose (or strict) alignment requirements than its subsampling.
Signed-off-by: Ville Syrjälä
Signed-off-by: Daniel Stone
---
drivers/gpu/drm
Hi,
On 5 June 2017 at 11:35, Chris Wilson wrote:
> I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It
> struggles with handling reclaim via kswapd (through inconsistency within
> throttle_direct_reclaim() and even then the race between multiple
> allocators makes the two ste
Hi Vidya,
I guess you didn't see my submission of this series a couple of weeks
ago, which included some fixes.
On 7 June 2017 at 11:41, Vidya Srinivas wrote:
> Link: https://patchwork.kernel.org/patch/9637253/
The Patchwork link can be dropped when submitting by mail.
> +static const struct dr
Hi Vidya,
On 7 June 2017 at 11:41, Vidya Srinivas wrote:
> + case I915_FORMAT_MOD_Y_TILED_CCS:
> + if (plane == 1)
> + return 128;
> + /* fall through */
> case I915_FORMAT_MOD_Y_TILED:
> if (IS_GEN2(dev_priv) || HAS_
Hi Vidya,
On 7 June 2017 at 12:40, Vidya Srinivas wrote:
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FORMAT_XRGB, .depth = 24, .num_planes = 2, .cpp =
> { 4, 1, }, .hsub = 16, .vsub = 8, },
> + { .format = DRM_FORMAT_XBGR, .depth = 24, .num_pl
Hi,
On 7 June 2017 at 13:53, Ville Syrjälä wrote:
> On Wed, Jun 07, 2017 at 12:44:47PM +0100, Daniel Stone wrote:
>> /*
>> * We don't require any
>> * CCS block size alignment of the fb under the assumption that the
>> * hardware will handle things correctly o
Hi,
On 7 June 2017 at 16:33, Ville Syrjälä wrote:
> On Wed, Jun 07, 2017 at 03:24:58PM +0100, Daniel Stone wrote:
>> On 7 June 2017 at 13:53, Ville Syrjälä wrote:
>> > Anyways, I'll have to revisit the the offsets[] thing because people
>> > didn't like m
Hi,
On 7 June 2017 at 17:28, Ville Syrjälä wrote:
> On Wed, Jun 07, 2017 at 04:48:06PM +0100, Daniel Stone wrote:
>> It does, and I have correct CCS output (tested by displaying frames
>> either as Y_CCS, or as plain Y; correct display with the former and
>> visibly showing
Hi,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> +static const uint64_t skl_plane_format_modifiers_noccs[] = {
> + I915_FORMAT_MOD_Yf_TILED,
> + I915_FORMAT_MOD_Y_TILED,
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_LINEAR,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
>
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> + } else if (INTEL_GEN(dev_priv) >= 9) {
> intel_primary_formats = skl_primary_formats;
> num_formats = ARRAY_SIZE(skl_primary_formats);
> - modifiers = skl_format_modifiers;
> +
Hi Ben,
On 26 July 2017 at 19:08, Ben Widawsky wrote:
> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> + s
Hi Ben,
On 26 July 2017 at 19:07, Ben Widawsky wrote:
> v2: Drop the 'dev' argument from the hook
> v3: Include the description of the CCS surface layout
This went missing. Vidya's patch has it though.
> +static const struct drm_format_info ccs_formats[] = {
> + { .format = DRM_FO
Hi,
On 26 July 2017 at 19:07, Ben Widawsky wrote:
> Due to hardware limitations we require that the main surface and
> the AUX surface (CCS) be part of the same bo. The hardware also
> makes life hard by not allowing you to provide separate x/y offsets
> for the main and AUX surfaces (excpet with
Hi,
On 2 November 2017 at 18:04, Pandiyan, Dhinakaran
wrote:
> On Thu, 2017-11-02 at 07:27 -0700, Rodrigo Vivi wrote:
>> That's intentional. The idea is to send to linux-firmware only after it
>> passes our CI. So, prepare already in a way that it is easy to just forward
>> when
>> that happens.
Hi Uma,
On 7 November 2017 at 12:06, Uma Shankar wrote:
> This patch series adds properties for plane color features. It adds
> properties for degamma used to linearize data, CSC used for gamut
> conversion, and gamma used to again non-linearize data as per panel
> supported color space. These ca
Hi Uma,
On 10 November 2017 at 08:37, Shankar, Uma wrote:
>>This is missing documentation on how plane colour management interacts with
>>CRTC colour management. Is it a step before CRTC colour management is
>>applied, or does it bypass CRTC colour management, or ... ?
>>
>
> We can have color co
Hi,
On 1 August 2017 at 17:58, Ben Widawsky wrote:
> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
> *dev_priv,
> plane_formats = skl_plane_formats;
> num_plane_formats = ARRAY_SIZE(skl_plane_formats);
> modifiers = skl_p
On 3 August 2017 at 18:21, Ben Widawsky wrote:
> On 17-08-03 12:00:56, Daniel Stone wrote:
>> if (pipe >= PIPE_C || plane >= PLANE_SPRITE1)
>>
>> cf. skl_check_ccs_aux_surface() which rejects CCS on anything other
>> than PRIMARY/SPRITE0.
>>
>> I&#
Hi Jason,
On 4 August 2017 at 01:52, Jason Ekstrand wrote:
> Previously, the test used the old 64x64 convention that Ville introduced
> for CCS tiles and not the current 128x32 Y-tile convention. Also, the
> original scheme for generating the CCS data was over-complicated and
> didn't work corre
If the kernel tells us it's immutable, trying to set it probably isn't
going to succeed.
Fixes a failure seen with the IN_FORMATS property.
Signed-off-by: Daniel Stone
Cc: Daniel Vetter
Cc: Ben Widawsky
---
tests/kms_properties.c | 10 +++---
1 file changed, 7 insertions(+), 3
On 4 August 2017 at 14:38, Daniel Stone wrote:
> If the kernel tells us it's immutable, trying to set it probably isn't
> going to succeed.
>
> Fixes a failure seen with the IN_FORMATS property.
Pushed a v2 which removed most of the list with Daniel Vetter's R-
On 4 August 2017 at 15:00, Lionel Landwerlin
wrote:
> v2: Use previous enum to define the new Gen8 enums (Petri)
>
> Signed-off-by: Lionel Landwerlin
Tested-by: Daniel Stone
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.
On 4 August 2017 at 15:56, Jason Ekstrand wrote:
> On August 4, 2017 2:59:56 AM Daniel Stone wrote:
>>> + width = ALIGN(f.width * 4, 32) / 32;
>>> + height = ALIGN(f.height, 16) / 16;
>>> + f.pit
Due to a mix-up in kernel branches being used, I'd mangled Jason's
original CCS test to hopelessly overallocate the CCS surface size.
Restore it back to its original.
Signed-off-by: Daniel Stone
Cc: Jason Ekstrand
---
tests/kms_ccs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Also try to test CCS on available non-primary planes. However, as there
is not enough bandwidth to scan out both the primary and sprite planes
when using CCS (or even Y-tiled), fall back to linear for the primary
plane when using CCS for a sprite/cursor plane.
Signed-off-by: Daniel Stone
We don't need to align the framebuffer dimensions to the tile size. As
long as the pitch is aligned to the tile width, and the BO dimensions
can fit full tiles of both aligned pitch and aligned height, we don't
need to claim the FB itself is larger.
Signed-off-by: Daniel Stone
In preparation for also testing sprites.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index 50bb2ad6..1a5cdcd4 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -342,13
Make sure the CCS modifier is supported on our plane, before we try to
use it on that plane.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 117 +++-
1 file changed, 116 insertions(+), 1 deletion(-)
diff --git a/tests/kms_ccs.c b/tests
Some subtests were magically doing a for-each-pipe loop. Remove that,
and have all multi-pipe tests actually work across all pipes.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 62 +++--
1 file changed, 20 insertions(+), 42 deletions
Will be used in later patches.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tests/kms_ccs.c b/tests/kms_ccs.c
index c02a0433..50bb2ad6 100644
--- a/tests/kms_ccs.c
+++ b/tests/kms_ccs.c
@@ -48,14 +48,12
Create a new helper for generating and rendering the framebuffer, rather
than doing it inline with applying the configuration. This will be used
later to generate a different plane configuration.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 73
Rather than using TEST_UNCOMPRESSED / TEST_COMPRESSED as alternately
either an int or a bool, change it to a bitfield enum.
This will let us add more parameters later to control framebuffer
generation.
Signed-off-by: Daniel Stone
---
tests/kms_ccs.c | 29 -
1 file
Hi,
On 3 August 2017 at 12:00, Daniel Stone wrote:
> On 1 August 2017 at 17:58, Ben Widawsky wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
>> *dev_priv,
>> plane_formats = skl_plane_formats;
>> num
u get ENOENT if
you pass one handle to wait for, but that handle is 0 (invalid GEM
object ID)?
I couldn't see much else obvious, and it seems like a decent enough
workout of the wait API, so, with these and what Chris suggested:
Acked-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
On 18 August 2017 at 10:21, Daniel Vetter wrote:
> +Recommended IOCTL Return Values
> +===
> +
> +In theory a driver's IOCTL callback is only allowed to return very few error
> +codes. In practice it's good to abuse a few more. This section documents
> common
> +p
On 24 August 2017 at 20:10, wrote:
> Y/Yf somehow dropped out from the SKL+ sprite modifier list. Add them
> in.
There's no 'somehow':
https://lists.freedesktop.org/archives/intel-gfx/2017-August/134932.html
I would prefer to not see this pushed whilst it doesn't actually work.
Cheers,
Daniel
Hi,
On 25 August 2017 at 12:34, Ville Syrjälä wrote:
> On Fri, Aug 25, 2017 at 10:40:28AM +0100, Daniel Stone wrote:
>> On 24 August 2017 at 20:10, wrote:
>> > Y/Yf somehow dropped out from the SKL+ sprite modifier list. Add them
>> > in.
>>
Hi Sagar,
On 28 August 2017 at 10:56, Sagar Arun Kamble wrote:
> This patch makes v9.33 firmware as default firmware for SKL.
> This update includes (since v6.1):
https://01.org/linuxgraphics/downloads/firmware does not include
v9.33, only 6.1.
Please do not push this patch until it has at leas
Hi Daniel,
On 25 August 2017 at 18:17, Daniel Vetter wrote:
> Which of these do we need to cherry-pick over to -next-fixes? There's no
> annotations about that. If the answer is "most" I'm leaning towards
> disabling CCS for 4.14, minimal set would be ideal (and first in the patch
> series).
My
Hi Ville,
On 4 September 2017 at 17:37, Ville Syrjälä
wrote:
> On Thu, Aug 31, 2017 at 04:52:15PM -0300, Gabriel Krisman Bertazi wrote:
>> With this patch the new testcase igt@kms_ccs@pipe-X-invalid-ccs-offset
>> succeeds.
>
> I don't think we actually want to reject overlap. I had a patch for th
Hi Gabriel,
On 31 August 2017 at 07:18, Gabriel Krisman Bertazi
wrote:
> Two scenarios tested:
> - unaligned stripe
> - Stripe too small
'stride' in the commit message please. ;) But it is fine everywhere
through the code.
> @@ -323,7 +326,14 @@ static void generate_fb(data_t *data, struct
Hi Gabriel,
On 31 August 2017 at 06:58, Gabriel Krisman Bertazi
wrote:
> + if (data->flags & TEST_BAD_CCS_HANDLE) {
> + /* Put the CCS buffer on a different BO. */
> + f.handles[0] = gem_create(data->drm_fd, size[0]);
> +
On 31 August 2017 at 06:58, Gabriel Krisman Bertazi
wrote:
> @@ -321,7 +322,13 @@ static void generate_fb(data_t *data, struct igt_fb *fb,
> int ccs_height = ALIGN(height, 16) / 16;
> f.pitches[1] = ALIGN(ccs_width * 1, 128);
> f.modifier[1] = modifi
Hi Gabriel,
On 31 August 2017 at 06:58, Gabriel Krisman Bertazi
wrote:
> @@ -321,16 +325,19 @@ static void generate_fb(data_t *data, struct igt_fb *fb,
> size[1] = f.pitches[1] * ALIGN(ccs_height, 32);
>
> f.handles[0] = gem_create(data->drm_fd, size[0] + size[1]);
inda growing into a bigger series
> already. And of course we need to keep autohell working for probably a
> fairly long time, at least for the tools that distro install.
Yes please. I've taken a couple of passes looking at it, and it seems
fine to me.
Acked-by: Daniel
;t something they are interested in doing.
With a rebase of Ben's GBM branch[0], and my last Weston atomic
series, for Y_CCS this series is:
Tested-by: Daniel Stone
I had to disable Yf_CCS due to complaints about the kernel's idea of
the tiling mode not matching the modifier. Not sure
Hi,
On 5 January 2017 at 08:52, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
>> No matter what we do here, the question remains what to do with
>> Chamelium. Changing the color range is really a workaround for
>> Chamelium, not a fix. Using CEA range is perf
Hi,
On 12 January 2017 at 14:56, Rob Clark wrote:
> On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> wrote:
>> Isn't an implicit offset enough? As in first mask for a specific
>> modifier is for format indexes 0-63, second mask for the same modifier
>> is for 64-127, and so on.
>
> hmm, hadn't t
Hi,
On 12 January 2017 at 17:45, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:04:46PM +0000, Daniel Stone wrote:
>> Implicit is clever but horrible. AFAICT, the only way to do it
>> properly would be to have a nested forwards loop walk when you first
>> hit a modifier,
Hi,
On 12 January 2017 at 18:11, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 05:50:15PM +0000, Daniel Stone wrote:
>> struct drm_plane {
>> struct {
>> uint32_t format;
>> uint64_t modifiers[];
>> } formats[];
>> }
>
> Flipp
Hey,
On 13 January 2017 at 09:37, Ville Syrjälä
wrote:
> On Thu, Jan 12, 2017 at 07:27:03PM +0000, Daniel Stone wrote:
>> It would make sense, but then gbm_surface_create_with_modifiers takes
>> a fixed pixel format and a list of acceptable modifiers (which to me
>> see
Hi,
On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote:
> + * active color format:
> + * This read-only property tells userspace the color format actually used
> + * by the hardware display engine "on the cable" on a connector. The
> chosen
> + * value depends on hardware capabilities
Hi,
On Wed, 10 Jan 2024 at 10:44, Daniel Vetter wrote:
> On Tue, Jan 09, 2024 at 11:12:11PM +, Andri Yngvason wrote:
> > ţri., 9. jan. 2024 kl. 22:32 skrifađi Daniel Stone :
> > > How does userspace determine what's happened without polling? Will it
> > > onl
On Wed, 19 Jun 2024 at 12:31, Ville Syrjala
wrote:
> Export drm_plane_has_format() so that drivers can use it.
Acked-by: Daniel Stone
it series adds support in drm-ci to run tests
> for both GPU and display drivers for MediaTek mt8173/mt8183, Rockchip
> rk3288/rk3399, and Amlogic Meson G12B (A311D) platforms.
>
> Update the expectations file, and skip driver-specific tests and
> tools_test on non-intel platforms.
Tha
Hi,
On Mon, 26 Feb 2024 at 03:21, Lucas De Marchi wrote:
> All of this should be fixed by now: dim is used for applying and pushing
> patches, which has additional checks so that doesn't happen again. Still
> pending confirmation from Daniel Stone if the git server hooks are ready
/HEIGHT caps, which can only declare
> a one size fits all limit for the whole device.
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Vignesh,
On Thu, 5 Sept 2024 at 10:41, Vignesh Raman wrote:
> Uprev IGT to the latest version and deqp-runner
> to v0.20.0. Also update expectation files.
Thanks! This is:
Reviewed-by: Daniel Stone
Don't build XAA when it's not available, or when we don't want it.
Signed-off-by: Daniel Stone
---
configure.ac | 24 +++-
src/legacy/i810/Makefile.am |6 +-
src/legacy/i810/i810.h|4
src/legacy/i810/i810_
Hi,
I've got a MacBookAir4,2 (mid-2011 version with Sandy Bridge), and get
pretty regular deadlocks in DRM. I'm not 100% sure they all have the
same root cause: the most regular one seems to occur under fairly
heavy I/O pressure, whereas this one just randomly happened whilst
running the Clutter t
Does what it says on the box.
Signed-off-by: Daniel Stone
---
configure.ac | 14 ++
src/legacy/i810/Makefile.am |6 +-
src/legacy/i810/i810.h|4
src/legacy/i810/i810_dga.c|2 ++
src/legacy/i810/i810_driver.c | 10
Hi,
On 17 October 2014 01:36, Jiang, Fei wrote:
> Thanks for Emil's suggestion. You are right, we need make sure structure
> size aligned on 8 bytes, which is important for 32bit-64bit compatible case.
While you're at it, please don't use enum as a type inside ioctls, since
the size can vary b
Hi,
On 19 June 2015 at 09:02, Maarten Lankhorst
wrote:
> + if (crtc->state->enable) {
> + intel_mode_from_pipe_config(&crtc->mode,
> + to_intel_crtc_state(crtc->state));
> +
> intel_mode_from_pipe_config(&crt
Hi,
On Thu, 2015-07-02 at 09:23 +0200, Daniel Vetter wrote:
> In
>
> commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
> Author: Daniel Stone
> Date: Fri May 22 13:34:45 2015 +0100
>
> drm/crtc_helper: Replace open-coded CRTC state helpers
>
> error handling co
Hi,
> On 2 Jul 2015, at 2:16 pm, Daniel Vetter wrote:
>
> In
>
> commit 9f658b7b62e7aefc1ee067136126eca3f58cabfd
> Author: Daniel Stone
> Date: Fri May 22 13:34:45 2015 +0100
>
>drm/crtc_helper: Replace open-coded CRTC state helpers
>
> error handling
On Thursday, July 2, 2015, Daniel Vetter wrote:
> Transitional drivers might not have all the state frobbing lined up
> yet. But since the initial code has been merged a lot more state was
> added, so we really need this.
>
> Cc: Daniel Stone >
> Signed-off-by: Daniel Ve
current atomic
> > userspace
> > (weston) works like this already anyway.
> >
> > Cc: Thierry Reding
> > Cc: Maarten Lankhorst
> > Cc: Daniel Stone
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_atomic.c | 22 +
Hi,
On 4 August 2015 at 12:34, Maarten Lankhorst
wrote:
> Commit ec9f932ed41622d120de52a5b525e4d77b9ef17e
> "drm/atomic: Cleanup on error properly in the atomic ioctl."
> cleaned up some error paths, but didn't fix the TEST_ONLY path.
> In the check only case plane->fb shouldn't be updated, and
>
Hi,
On 27 August 2015 at 13:43, Maarten Lankhorst
wrote:
> Op 27-08-15 om 14:19 schreef Daniel Stone:
>> On 4 August 2015 at 12:34, Maarten Lankhorst
>> wrote:
>> An early test precludes TEST_ONLY | PAGE_FLIP_EVENT, so you don't need
>> to mention this in the c
Hi,
On 27 August 2015 at 15:09, Ville Syrjälä wrote:
> On Thu, Aug 27, 2015 at 04:00:05PM +0200, Maarten Lankhorst wrote:
>> Op 27-08-15 om 15:50 schreef Ville Syrjälä:
>> > I don't think so. Speaking for i915, I think we've just rejected legacy
>> > page
>> > flips entirely with the pipe is off
Hi,
On 6 August 2015 at 13:49, Daniel Vetter wrote:
> On Thu, Aug 06, 2015 at 01:19:35PM +0200, Maarten Lankhorst wrote:
>> Op 06-08-15 om 11:47 schreef Daniel Stone:
>> > On 30 July 2015 at 08:03, Maarten Lankhorst
>> > wrote:
>> >> +
On 27 August 2015 at 15:34, Ville Syrjälä wrote:
> On Thu, Aug 27, 2015 at 03:28:53PM +0100, Daniel Stone wrote:
>> On 27 August 2015 at 15:09, Ville Syrjälä
>> wrote:
>> > In the kernel it should amount to
>> > if (!pipe_active)
>> > send_eve
Hi Bob,
On 27 August 2015 at 21:46, Bob Paauwe wrote:
> Extend this to SKL and BXT as it's needed for these platforms as well.
>
> Signed-off-by: Bob Paauwe
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i9
Hi,
On 28 August 2015 at 16:55, Bob Paauwe wrote:
> On Fri, 28 Aug 2015 15:19:04 +0100
> Daniel Stone wrote:
>> For both this and the previous patch, cf. the corresponding patch for
>> HSW/BDW[0], have you ensured these values are sanitised at startup,
>> even if U
parate patch, but with or without:
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 237 +
3 files changed, 239 insertions(+)
create mode 100644 tests/core_prop_blob.c
diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53
Hi,
On 10 September 2015 at 06:57, Daniel Stone wrote:
> Exercises the new blob-creation ioctl, testing lifetimes and behaviour
> of user-created blobs, as well as exercising all the invariant
> conditions we guarantee from modes exposed as blob properties.
>
> v2: Renamed to
Hi Thomas,
On 10 September 2015 at 13:31, Thomas Wood wrote:
> On 10 September 2015 at 07:06, Daniel Stone wrote:
>> On 10 September 2015 at 06:57, Daniel Stone wrote:
>>> Exercises the new blob-creation ioctl, testing lifetimes and behaviour
>>> of user-created b
} else {
> any_ms = true;
The change from only setting any_ms if needs_modeset() is true, to
always if we can't do a fastset, seems correct but maybe a bit subtle.
Was that intended? At the moment it does look like it'll widen the net
a little bit, but I _sus
Hi all,
Another respin of the blob/atomic tests.
Pretty minor changes compared to the last round this time; this introduces
the new drm_ioctl_err macro, and moves some of the asserts into macros
rather than helper functions, so we can pin the failures at the exact
callsite, rather than just in a h
Change m >= n patterns to igt_assert_lte(n, m), and ditto for strict
greater-than.
Signed-off-by: Daniel Stone
---
lib/igt.cocci | 12
1 file changed, 12 insertions(+)
diff --git a/lib/igt.cocci b/lib/igt.cocci
index 3aee72f..b4f8ee4 100644
--- a/lib/igt.cocci
+++ b/lib/igt.co
Use do_ioctl and do_ioctl_err where possible.
Signed-off-by: Daniel Stone
---
lib/igt.cocci | 18 ++
1 file changed, 18 insertions(+)
diff --git a/lib/igt.cocci b/lib/igt.cocci
index b4f8ee4..10abd21 100644
--- a/lib/igt.cocci
+++ b/lib/igt.cocci
@@ -213,3 +213,21 @@ expression
do_ioctl demands that the ioctl returns success; add a variant named
do_ioctl_err, which expects the ioctl to fail, and demands a particular
result.
Signed-off-by: Daniel Stone
---
lib/drmtest.h | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.h
Skip open-coding and assert that fds are valid.
Signed-off-by: Daniel Stone
---
lib/igt_core.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index 9a5d9c5..8f93e8e 100644
--- a/lib/igt_core.h
+++ b/lib/igt_core.h
@@ -507,6 +507,17 @@ void
Similar to igt_assert_eq_*(), add variants for non-equality of types
other than int.
Signed-off-by: Daniel Stone
---
lib/igt_core.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index f8bfbf0..9a5d9c5 100644
--- a/lib/igt_core.h
return 0/errno.
v5: Use do_ioctl_err and igt_assert_fd.
Use igt_assert_*() helper macros rather than direct igt_assert().
Signed-off-by: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/core_prop_blob.c | 228
Exercises the new blob-creation ioctl, testing lifetimes and behaviour
of user-created blobs, as well as exercising all the invariant
conditions we guarantee from modes exposed as blob properties.
Signed-off-by: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1
Hi,
On 21 April 2015 at 16:03, Micah Fedke wrote:
> + * drm_open_any_any:
> + *
> + * Literally the worst-named function I've ever written.
And I stand by this. This is really an RFC, partly to find out whether
it would be better to find a new name for these functions (open a
modeset-capable DRM
Exercises the new blob-creation ioctl, testing lifetimes and behaviour
of user-created blobs, as well as exercising all the invariant
conditions we guarantee from modes exposed as blob properties.
Signed-off-by: Daniel Stone
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1
Hi,
On 12 May 2015 at 14:16, Daniel Vetter wrote:
> On Tue, May 12, 2015 at 02:06:39PM +0200, Maarten Lankhorst wrote:
>> Op 11-05-15 om 19:11 schreef Daniel Vetter:
>> > On Mon, May 11, 2015 at 04:24:40PM +0200, Maarten Lankhorst wrote:
>> >> @@ -6079,26 +6059,29 @@ void intel_crtc_control(struc
Hi,
On Tue, 12 May, 2015 at 4:36 PM, Thomas Wood
wrote:
On 9 May 2015 at 15:57, Daniel Stone wrote:
Exercises the new blob-creation ioctl, testing lifetimes and
behaviour
of user-created blobs, as well as exercising all the invariant
conditions we guarantee from modes exposed as blob
Hi,
On 12 May 2015 at 17:57, Daniel Vetter wrote:
> On Tue, May 12, 2015 at 04:07:14PM +0200, Maarten Lankhorst wrote:
>> Op 12-05-15 om 12:03 schreef Daniel Vetter:
>> > On Mon, May 11, 2015 at 4:25 PM, Maarten Lankhorst
>> > wrote:
>> >> @@ -11953,16 +11930,14 @@ check_shared_dpll_state(struct
201 - 300 of 323 matches
Mail list logo
