/HEIGHT caps, which can only declare
> a one size fits all limit for the whole device.
Acked-by: Daniel Stone
Cheers,
Daniel
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
>
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
> > > only cha
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
On Wed, 23 Mar 2022 at 15:14, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 11:04 AM Daniel Stone wrote:
> > That's not what anyone's saying here ...
> >
> > No-one's demanding AMD publish RTL, or internal design docs, or
> > hardware specs, or URLs to JIR
Hi Alex,
On Wed, 23 Mar 2022 at 14:42, Alex Deucher wrote:
> On Wed, Mar 23, 2022 at 10:00 AM Daniel Stone wrote:
> > On Wed, 23 Mar 2022 at 08:19, Christian König
> > wrote:
> > > Well the key point is it's not about you to judge that.
> > >
> > >
On Wed, 23 Mar 2022 at 08:19, Christian König wrote:
> Am 23.03.22 um 09:10 schrieb Paul Menzel:
> > Sorry, I disagree. The motivation needs to be part of the commit
> > message. For example see recent discussion on the LWN article
> > *Donenfeld: Random number generator enhancements for Linux
tained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Daniel Stone
Hi Matthew,
On Mon, 6 Dec 2021 at 13:32, Matthew Auld wrote:
> Enable accelerated moves and clearing on DG2. On such HW we have minimum page
> size restrictions when accessing LMEM from the GTT, where we now have to use
> 64K
> GTT pages or larger. With the ppGTT the page-table also has a
Hi Tvrtko,
Thanks for typing this up!
On Thu, 15 Jul 2021 at 10:18, Tvrtko Ursulin
wrote:
> +Mandatory fully standardised keys
> +-
> +
> +- drm-driver:
> +
> +String shall contain a fixed string uniquely identified the driver handling
> +the device in question.
Hi,
On Wed, 23 Jun 2021 at 17:20, Daniel Vetter wrote:
> +*
> +* IMPLICIT SYNCHRONIZATION RULES:
> +*
> +* Drivers which support implicit synchronization of buffer access as
> +* e.g. exposed in `Implicit Fence Poll Support`_ should follow the
> +*
Hi,
On Wed, 26 May 2021 at 13:46, Christian König wrote:
> Am 26.05.21 um 13:31 schrieb Daniel Stone:
> > How would we insert a syncobj+val into a resv though? Like, if we pass
> > an unmaterialised syncobj+val here to insert into the resv, then an
> > implicit-only med
Hi Christian,
On Wed, 26 May 2021 at 12:02, Christian König wrote:
> Am 25.05.21 um 23:17 schrieb Jason Ekstrand:
> > This new IOCTL solves this problem by allowing us to get a snapshot of
> > the implicit synchronization state of a given dma-buf in the form of a
> > sync file. It's effectively
On Fri, 21 May 2021 at 14:09, Christian König wrote:
> Am 21.05.21 um 14:54 schrieb Daniel Stone:
> > If you're curious, the interface definitions are in the csf/ directory
> > in the 'Bifrost kernel driver' r30p0 download you can get from the Arm
> > developer site. Un
On Fri, 21 May 2021 at 13:28, Christian König wrote:
> Am 21.05.21 um 14:22 schrieb Daniel Stone:
> > Yeah, the 'second-generation Valhall' GPUs coming later this year /
> > early next year are starting to get pretty weird. Firmware-mediated
> > job scheduling out of multi
Hi,
On Fri, 21 May 2021 at 10:10, Daniel Vetter wrote:
> Currently this has no practial relevance I think because there's not
> many who can pull off a setup with panfrost and another gpu in the
> same system. But the rules are that if you're setting an exclusive
> fence, indicating a gpu write
Hi,
On Tue, 18 May 2021 at 10:09, Tvrtko Ursulin
wrote:
> I was just wondering if stat(2) and a chrdev major check would be a
> solid criteria to more efficiently (compared to parsing the text
> content) detect drm files while walking procfs.
Maybe I'm missing something, but is the per-PID walk
Hi,
On Tue, 11 May 2021 at 15:34, Daniel Vetter wrote:
> On Thu, May 06, 2021 at 10:30:45AM -0700, Matthew Brost wrote:
> > +No major changes are required to the uAPI for basic GuC submission. The
> > only
> > +change is a new scheduler attribute:
> > I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
>
On Tue, 16 Mar 2021 at 21:35, Daniel Vetter wrote:
> On Tue, Mar 9, 2021 at 10:14 AM Pekka Paalanen
> wrote:
> > On Mon, 8 Mar 2021 16:52:58 -0800
> > "Navare, Manasi" wrote:
> > > Hmm well after the actual real commit, since the second crtc is stolen
> > > even though it is not being used for
On Wed, 10 Feb 2021 at 15:07, Ville Syrjälä
wrote:
> On Wed, Feb 10, 2021 at 01:38:45PM +, Simon Ser wrote:
> > The WARN_ON only happens if allow_modeset == false. If allow_modeset ==
> > true,
> > then the driver is allowed to steal an unrelated pipe.
> >
> > Maybe i915 is stealing a pipe
Hi,
On Wed, 25 Nov 2020 at 18:06, Jason Gunthorpe wrote:
> On Wed, Nov 25, 2020 at 05:28:32PM +0100, Daniel Vetter wrote:
> > Apologies again, this shouldn't have been included. But at least I
> > have an idea now why this patch somehow was included in the git
> > send-email. Lovely interface
Hi,
On Fri, 25 Sep 2020 at 09:46, Daniel Vetter wrote:
> Hopefully we'll have the drm crash recorder RSN, but meanwhile
> compositors would like to know a bit better why they get an EBUSY.
Thanks a lot, this is super helpful! Both patches are:
Reviewed-by: Daniel Stone
Cheers,
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> +* For commits that allow modesets drivers can add other CRTCs to the
> +* atomic
Hi,
On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
> > I think we need a guarantee that this never happens if ALLOW_MODESET
> > is always used in blocking mode, plus in future a cap we can use to
> > detect tha
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore
Hi all,
On Wed, 15 Jul 2020 at 12:57, Daniel Vetter wrote:
> On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
> > On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> > wrote:
> > > Yes, this is used as part of the Android stack on Chrome OS (need to
> &
Hi,
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
wrote:
> On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> wrote:
> > Maybe now is the time to ask: are you using sw_sync outside of
> > validation?
>
> Yes, this is used as part of the Android stack on Chrome OS (need to
> see if ChromeOS
Hi,
On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen
wrote:
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that
On Thu, 9 Jul 2020 at 09:05, Daniel Vetter wrote:
> On Thu, Jul 09, 2020 at 08:36:43AM +0100, Daniel Stone wrote:
> > On Tue, 7 Jul 2020 at 21:13, Daniel Vetter wrote:
> > > Comes up every few years, gets somewhat tedious to discuss, let's
> > > write this down once
icitly
encode the carrot of dma-fence's positive guarantees, rather than just
the stick of 'don't do this'. ;) Either way, this is:
Acked-by: Daniel Stone
> What I'm not sure about is whether the text should be more explicit in
> flat out mandating the amdkfd eviction fences for long run
Hi,
On Wed, 8 Jul 2020 at 16:13, Daniel Vetter wrote:
> On Wed, Jul 8, 2020 at 4:57 PM Christian König
> wrote:
> > Could we merge this controlled by a separate config option?
> >
> > This way we could have the checks upstream without having to fix all the
> > stuff before we do this?
>
>
Hi,
Jumping in after a couple of weeks where I've paged most everything
out of my brain ...
On Fri, 19 Jun 2020 at 10:43, Daniel Vetter wrote:
> On Fri, Jun 19, 2020 at 10:13:35AM +0100, Chris Wilson wrote:
> > > The proposed patches might very well encode the wrong contract, that's
> > > all up
Hi,
On Thu, 11 Jun 2020 at 09:44, Dave Airlie wrote:
> On Thu, 11 Jun 2020 at 18:01, Chris Wilson wrote:
> > Introducing a global lockmap that cannot capture the rules correctly,
>
> Can you document the rules all drivers should be following then,
> because from here it looks to get refactored
On Thu, 14 May 2020 at 08:25, Daniel Vetter wrote:
> On Thu, May 14, 2020 at 9:18 AM Daniel Stone wrote:
> > On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > I'd be very much in favour of putting the blocking down in the kernel
> > at least until the kernel can give
Hi,
On Thu, 14 May 2020 at 08:08, Daniel Vetter wrote:
> > Did anything happen with this?
>
> Nope. There's an igt now that fails with this, and I'm not sure
> whether changing the igt is the right idea or not.
>
> I'm kinda now thinking about changing this to instead document under
> which
On Wed, 8 Apr 2020 at 17:24, Daniel Vetter wrote:
> Resending because last attempt failed CI and meanwhile the results are
> lost :-/
Did anything happen with this?
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Hi Jan,
On Fri, 28 Feb 2020 at 10:09, Jan Engelhardt wrote:
> On Friday 2020-02-28 08:59, Daniel Stone wrote:
> >I believe that in January, we had $2082 of network cost (almost
> >entirely egress; ingress is basically free) and $1750 of
> >cloud-storage cost (almost all
On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
wrote:
> On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > Yeah, changes on vulkan drivers or backend compilers should be
> > fairly
> > sandboxed.
> >
> > We also have tools that only work for intel stuff, that should never
> > trigger
On Fri, 28 Feb 2020 at 08:48, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> > The last I looked, Google GCP / Amazon AWS / Azure were all pretty
> > comparable in terms of what you get and what you pay for them.
> > Obviously providers like Packet
On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> b) we probably need to take a large step back here.
>
> Look at this from a sponsor POV, why would I give X.org/fd.o
> sponsorship money that they are just giving straight to google to pay
> for hosting credits? Google are profiting in some minor
Hi Matt,
On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote:
> We're paying 75K USD for the bandwidth to transfer data from the
> GitLab cloud instance. i.e., for viewing the https site, for
> cloning/updating git repos, and for downloading CI artifacts/images to
> the testing machines (AFAIU).
I
Hi,
On Tue, 25 Feb 2020 at 07:17, Pankaj Bharadiya
wrote:
> @@ -415,18 +415,26 @@ skl_program_scaler(struct intel_plane *plane,
> u16 y_vphase, uv_rgb_vphase;
> int hscale, vscale;
> const struct drm_plane_state *state = _state->uapi;
> + u32 src_w =
commits.
Thanks for writing this up Daniel, and for reminding me about it some
time later as well ...
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
On Wed, 6 Nov 2019 at 02:47, Dave Airlie wrote:
> Otherwise I think this seems fine, though it does beg the question in
> my mind of what happens if I get 2 8K monitors, and plug the first
> tile of one in, and the second tile of the other in.
Honestly in that case I think 'you get to
Hi Thierry,
On Fri, 25 Oct 2019 at 12:36, Thierry Reding wrote:
> On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> > I did think about having a state variable in software to get and set
> > this. However, I think it is not very far fetched that some platforms
> > may have "hardware
Hi,
On Tue, 6 Aug 2019 at 10:58, Daniel Vetter wrote:
> On Tue, Aug 6, 2019 at 11:55 AM Emil Velikov wrote:
> > On Tue, 6 Aug 2019 at 10:49, Daniel Vetter wrote:
> > > The thing is, dim push shouldn't allow you to do that. And the patches
> > > have clearly been applied with dim apply (or at
that you are replying to the original sender (in Reply-To) and not the
list itself.
Cheers,
Daniel
-- Forwarded message -
From: Daniel Stone
Date: Mon, 11 Feb 2019 at 23:38
Subject: PSA: Mailman changes, From addresses no longer accurate
To: ,
Hi all,
We have hit another step change
e-time. So, in include/uapi there shouldn't be these numeric
> values.
>
> The strings themselves effectively form the UABI, so I was wondering
> if they should be defined in include/uapi, but you would be the first
> to do that.
>
> Daniel Vetter and/or Daniel Stone mi
Hi Rodrigo,
On Wed, 22 Aug 2018 at 17:06, Rodrigo Vivi wrote:
> On Wed, Aug 22, 2018 at 10:19:19AM -0400, Adam Jackson wrote:
> > On Wed, 2018-08-22 at 16:13 +0300, Jani Nikula wrote:
> > > - Sticking to fdo bugzilla and disabling gitlab issues for at least
> > > drm-intel for the time being.
Hi,
On Wed, 22 Aug 2018 at 15:44, Daniel Vetter wrote:
> On Wed, Aug 22, 2018 at 3:13 PM, Jani Nikula
> wrote:
> > Just a couple of concerns from drm/i915 perspective for starters:
> >
> > - Patchwork integration. I think we'll want to keep patchwork for at
> > least intel-gfx etc. for the
Hi,
On Wed, 22 Aug 2018 at 16:02, Emil Velikov wrote:
> On 22 August 2018 at 12:44, Daniel Vetter wrote:
> > I think it's time to brainstorm a bit about the gitlab migration. Basic
> > reasons:
> >
> > - fd.o admins want to deprecate shell accounts and hand-rolled
> > infrastructure, because
Hey Jakob,
On Thu, 5 Jul 2018 at 14:32, Jakob Bornecrantz wrote:
> So from a VR compositor getting blocked like this is a no-go as the
> user would quickly throw EPUKE. The situation is compounded by the
> fact that the VR compositor has no idea what the display compositor is
> doing with
Hi,
The atomic API being super-explicit about how userspace sequences its
calls is great and all, but having shared global state implicitly
dragged in is kind of ruining my day.
Currently on Intel, Weston sometimes fails on hotplug, because a
commit which only enables CRTC B (not touching CRTC A
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)
Signed-off-by: Daniel Stone <dani...@collabora.com>
Reviewed-by:
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone <dani...@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrj...@intel.com>
Cc: Jani Nikula <jani.nik...@linu
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone <dani...@collabora.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linu
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
Signed-off-by: Daniel Stone <dani...@collabora.com>
Cc: Ville Syrjälä <ville.syrj...@intel.com>
Cc:
Hi Ville,
On 23 March 2018 at 14:49, Daniel Stone <dan...@fooishbar.org> wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrj...@linux.intel.com>
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just
Hi,
I've been working on a getfb2[0] ioctl, which amongst other things
supports multi-planar framebuffers as well as modifiers. getfb
currently calls the framebuffer's handle_create hook, which doesn't
support multiple planes.
Thanks to Noralf's recent work, drivers can just store GEM objects
Hi Ville,
On 23 March 2018 at 14:42, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Fri, Mar 23, 2018 at 01:45:50PM +0000, Daniel Stone wrote:
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -1391
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone <dani...@collabora.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linu
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
Signed-off-by: Daniel Stone <dani...@collabora.com>
Cc: Jani Nikula <jani.nik...@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com>
Cc: Rodri
ts we
> don't want. The mode type is just a hint anyway, and more
> useful for the kernel->userspace direction.
Reviewed-by: Daniel Stone <dani...@collabora.com>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Chamelium support requires igt_frame to be built, which requires both
GSL and Pixman.
Signed-off-by: Daniel Stone <dani...@collabora.com>
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index ef7017cb..5b783e5d
Hi Ville,Given you've tested, my reservations are dropped, so this series is:Acked-by: Daniel Stone <dani...@collabora.com>Sorry for the mobile client formatting.Cheers,Daniel___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Hi,
On 11 December 2017 at 12:08, Mika Kahola <mika.kah...@intel.com> wrote:
> On Mon, 2017-12-11 at 12:00 +0000, Daniel Stone wrote:
>> Did you manage to test this? When I tried, the DDB/watermark
>> allocation was too conservative for sprites, and never allowed enough
Hi Mika,
On 11 December 2017 at 11:11, Mika Kahola wrote:
> On Thu, 2017-08-24 at 22:10 +0300, ville.syrj...@linux.intel.com wrote:
>> Allow sprites to scan out compressed framebuffers.
>>
>> Since different platforms have a different set of planes that
>> support CCS
Hi Pavel,
On 5 December 2017 at 17:34, Pavel Machek wrote:
> Yes, so... This patch makes it more likely to see machines with locked
> down kernels, preventing developers from working with systems their
> own, running hardware. That is evil, and direct threat to Free
> software
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 ... ?
>>
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
>
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
ng 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 Stone <dani...@collabora.com>
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] =
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);
>
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,
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
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
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
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
Hi,
On 25 August 2017 at 12:34, Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Fri, Aug 25, 2017 at 10:40:28AM +0100, Daniel Stone wrote:
>> On 24 August 2017 at 20:10, <ville.syrj...@linux.intel.com> wrote:
>> > Y/Yf somehow dropped out from the SKL+
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
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
th EINVAL */
> + ret = ioctl(fd, DRM_IOCTL_SYNCOBJ_WAIT, );
> + return ret == -1 && errno == EINVAL;
Unfortunately an unrecognised ioctl also leads to a failure with
EINVAL. Try another test for ioctl presence, e.g. do you get ENOENT if
you pass one handle to wait for, but that h
Hi,
On 3 August 2017 at 12:00, Daniel Stone <dan...@fooishbar.org> wrote:
> On 1 August 2017 at 17:58, Ben Widawsky <b...@bwidawsk.net> wrote:
>> @@ -1240,6 +1253,19 @@ intel_sprite_plane_create(struct drm_i915_private
>> *dev_priv,
>>
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 <dani...@collabora.com>
---
tests/kms_ccs.
Will be used in later patches.
Signed-off-by: Daniel Stone <dani...@collabora.com>
---
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
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 <dani...@collabora.com>
---
tests/kms_ccs.
In preparation for also testing sprites.
Signed-off-by: Daniel Stone <dani...@collabora.com>
---
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
Make sure the CCS modifier is supported on our plane, before we try to
use it on that plane.
Signed-off-by: Daniel Stone <dani...@collabora.com>
---
tests/kms_ccs.c | 117 +++-
1 file changed, 116 insertions(+), 1 deletion(-)
diff
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 <dani...@collabora.com>
---
tests/kms_ccs.c | 62 +++--
1 file chang
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 <d
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 <d
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 <dani...@collabora.com>
Cc: Jason Ekstrand <ja...@jlekstrand.net>
---
tests/kms_ccs.c |
On 4 August 2017 at 15:56, Jason Ekstrand <ja...@jlekstrand.net> wrote:
> On August 4, 2017 2:59:56 AM Daniel Stone <dan...@fooishbar.org> wrote:
>>> + width = ALIGN(f.width * 4, 32) / 32;
>>> + height = ALIGN(f.height, 16) / 16;
>>
On 4 August 2017 at 15:00, Lionel Landwerlin
<lionel.g.landwer...@intel.com> wrote:
> v2: Use previous enum to define the new Gen8 enums (Petri)
>
> Signed-off-by: Lionel Landwerlin <lionel.g.landwer...@intel.com>
Tested-by: Daniel Stone &
On 4 August 2017 at 14:38, Daniel Stone <dani...@collabora.com> 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 Vet
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 <dani...@collabora.com>
Cc: Daniel Vetter <daniel.vet...@intel.com>
Cc: Ben Widawsky <b...@bwidawsk.
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
On 3 August 2017 at 18:21, Ben Widawsky <b...@bwidawsk.net> 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/
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);
>
1 - 100 of 311 matches
Mail list logo