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. F
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.
> >
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 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 a
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 ou
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
> > dev
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
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 media
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
> +*
at compile-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
Hi Chris,
I'm assuming this has come from the async fbdev work: I'm now (today's
din) getting lockdep splat about AB/BA between the fbdev notifier lock
versus mode_config. It's attached below; seems like it should probably
be fixed up. I guess it only shows on systems with a backlight (in my
case,
se be _very_ careful
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 hav
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 5.1
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 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,
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 slight
te that drm-misc is group maintained, 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 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 k
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 litera
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 le
cking
> 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, 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 :-/
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 wi
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, 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
https://lists
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 exact
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
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 e
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 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?
>
> Since
explicitly
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 amdkf
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
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 no
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 spec
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
> > &
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 "spurio
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
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 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
Che
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 = &plane_state->uapi;
> + u32 src_w = drm_rect_w
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 b
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
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 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 an
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
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 movement.
>
> Users
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 let's add a small helper to
Hi,
On 11 December 2017 at 12:08, Mika Kahola 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
>> blocks to be able to us
Hi Ville,Given you've tested, my reservations are dropped, so this series is:Acked-by: Daniel Stone Sorry for the mobile client formatting.Cheers,Daniel___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/ma
Hi Ville,
On 23 March 2018 at 14:49, Daniel Stone wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just to prevent changes of the obj
>> tiling mode as long a
l the page_flip_handler2 vfunc if it was non-NULL, which being a
random chunk of stack memory, it might well have been.
Set the version as 2, which should be bumped only with the appropriate
version checks.
Signed-off-by: Daniel Stone
---
tests/kms_atomic_transition.c| 2 +-
tests/kms_f
Reviewed-by: Daniel Stone
[mobile email formatting apology here]
On Fri, 7 Apr 2017 at 5:48 pm, Daniel Vetter wrote:
> I thought I've fixed this, but maybe not. Anyway, clearly broken, and
> easy fix.
>
> Cc: Tony Lindgren
> Reported-by: Tony Lindgren
> Fixes: b95
Hi,
On 11 April 2017 at 07:48, Daniel Vetter wrote:
> Note: As Daniel Stone mentioned in the announcement fd.o admins
> started chatting with the communities their hosting, which includs the
> X.org foundation board, to figure out how to fan out enforcement and
> allow projects to r
ng.
I'm extremely deprived of coffee today, but I couldn't find anything
wrong with this. Thanks for doing the diagram!
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Brian,
On 3 May 2017 at 12:00, Brian Starkey wrote:
> Having just caught up on IRC I'm sure I'm far too late for this party,
> but...
>
> Wouldn't this whole thing be a whole lot simpler if "IN_FORMATS"
> stored "pointers" to separate blobs for the format and modifier lists?
>
> I've used/writ
Hi Liviu,
On 3 May 2017 at 11:34, Liviu Dudau wrote:
> On Tue, May 02, 2017 at 10:14:26PM -0700, Ben Widawsky wrote:
>> v2: A minor addition from Daniel
>
> You are *really* pushing your luck by not Cc-ing *any* of the maintainers of
> the drivers you touch. You do want reviews, don't you?
Ouch.
Hi Brian,
On 3 May 2017 at 13:51, Brian Starkey wrote:
> On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:
>> + modifiers_size =
>> + sizeof(struct drm_format_modifier) *
>> format_modifier_count;
>> +
>> + blob_size = ALIGN(sizeof(struct drm_format_modifier_
Hi Brian,
On 3 May 2017 at 15:03, Brian Starkey wrote:
> On Wed, May 03, 2017 at 02:51:18PM +0100, Daniel Stone wrote:
>> formats_offset is the end of the fixed-size element, which is
>> currently aligned to 32 bytes, and practically speaking would always
>> have to be anyw
On 3 May 2017 at 15:07, Liviu Dudau wrote:
> On Wed, May 03, 2017 at 02:45:26PM +0100, Daniel Stone wrote:
>> On 3 May 2017 at 11:34, Liviu Dudau wrote:
>> > You are *really* pushing your luck by not Cc-ing *any* of the maintainers
>> > of
>> > the drivers y
n't accept the FB modifiers. So this gets my:
Acked-by: Daniel Stone
And a future revision with the fixups found here would get my R-b.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 o
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 regards
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 i
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 ti
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. D
Chamelium support requires igt_frame to be built, which requires both
GSL and Pixman.
Signed-off-by: Daniel Stone
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meson.build b/meson.build
index ef7017cb..5b783e5d 100644
--- a/meson.build
+++ b/meson.build
ype is just a hint anyway, and more
> useful for the kernel->userspace direction.
Reviewed-by: Daniel Stone
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
Signed-off-by: Daniel Stone
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm/i915/intel_display.c | 15
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
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gpu/drm
Hi Ville,
On 23 March 2018 at 14:42, Ville Syrjälä 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
>> @@ -13916,7 +13916,8 @@ static void intel_user_frame
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
dire
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
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
---
drivers/gp
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
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel
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
Reviewed-by: Ville Syrjälä
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedeskto
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
Reviewed-by: Ville Syrjälä
Cc: Jani
Hi,
On 14 June 2016 at 00:13, Daniel Vetter wrote:
> +static void intel_atomic_commit_tail(struct drm_atomic_state *state)
> {
> + struct drm_device *dev = state->dev;
> struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> struct drm_i915_private *dev_pr
Hi Chris,
On 24 June 2016 at 22:44, Chris Wilson wrote:
> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f.
>
> Something appears to be off in the timing, but as far as I can tell it
> is not along the event delivery path. The net effect appears to be
> rendering flicker (the current
Hi,
On 19 November 2015 at 16:46, Daniel Vetter wrote:
> @@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void
> *data,
> args->size = exynos_gem->size;
>
> drm_gem_object_unreference(obj);
> - mutex_unlock(&dev->struct_mutex);
drm_gem_object_unrefe
Let us print human-parseable values from the power domain code; upcoming
display code also wants to use it.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c | 67 +
drivers/gpu/drm/i915/i915_drv.h | 66
If we experience a refcounting failure in a power domain/well (unref'ing at
least one too many times), log the name of the offending domain or well.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
Hey,
On 19 November 2015 at 18:24, Ville Syrjälä
wrote:
> On Thu, Nov 19, 2015 at 05:59:10PM +0000, Daniel Stone wrote:
>> +static inline const char *
>> +intel_display_power_domain_str(enum intel_display_power_domain domain)
>
> It's still const. And I assume now w
Let us print human-parseable values from the power domain code; upcoming
display code also wants to use it.
This requires moving it out of i915_debugfs.c, as that is only conditionally
compiled.
v2: Move it out of the header.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c
If we experience a refcounting failure in a power domain/well (unref'ing at
least one too many times), log the name of the offending domain or well.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff
On 20 November 2015 at 08:21, Jani Nikula wrote:
> On Thu, 19 Nov 2015, Ville Syrjälä wrote:
>> On Thu, Nov 19, 2015 at 06:26:23PM +0000, Daniel Stone wrote:
>>> Surely gcc's DCE pass will trivially eliminate this?
>>
>> Dunno. But I rather dislike having
Hi,
On 13 November 2015 at 21:13, Paulo Zanoni wrote:
> 2015-11-13 18:56 GMT-02:00 Chris Wilson :
>> This is confusing me. I think of FBC in terms of the CRTC/pipe, and the
>> fb just describes the plane currently bound to the primary. You've
>> pushed everywhere else to also work on the CRTC, I
On 20 November 2015 at 13:55, Ville Syrjälä
wrote:
> On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
>> +static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
>> +{
>> + struct drm_i915_private *dev_priv = to_i915(state->dev);
>> + int max_pixclk = i
e
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
_ERROR for userspace controlled input isn't great, but
> that's for another patch.
>
> v2: Use _unlocked unreference (Daniel Stone).
>
> Cc: Daniel Stone
> Cc: Inki Dae
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Inki Dae
> Signed-off-by: Daniel Vetter
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
anyway).
>
> Aside: exynos_gem_obj->size is redundant with
> exynos_gem_obj->base.size and probably should be removed.
>
> v2: Use _unlocked unreference (Daniel Stone).
>
> Cc: Daniel Stone
> Cc: Inki Dae
> Signed-off-by: Daniel
Hi,
On 24 November 2015 at 13:27, Chris Wilson wrote:
> On Tue, Nov 24, 2015 at 01:17:57PM +, Tvrtko Ursulin wrote:
>> On 24/11/15 12:53, Chris Wilson wrote:
>> >The WARN_ON is accurate though. The original patch fails to fix even the
>> >limited aspect of the bug it claimed to.
>>
>> That is
Hey,
On 24 November 2015 at 13:59, Daniel Vetter wrote:
> On Tue, Nov 24, 2015 at 01:29:07PM +0000, Daniel Stone wrote:
>> On 24 November 2015 at 13:27, Chris Wilson wrote:
>> > On Tue, Nov 24, 2015 at 01:17:57PM +, Tvrtko Ursulin wrote:
>> >> On 24/1
; expected so wait 1ms before trying again so we give time to aux
> channels to recover.
I know there are still some review comments to resolve, but for the
series (except Nouveau):
Tested-by: Daniel Stone # SKL
I used to see this pretty freque
ble PSR back by default.
For the series:
Tested-by: Daniel Stone # SKL
I haven't managed to get to BDW yet since that relies on IPS bits.
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
On 25 November 2015 at 12:21, Ander Conselvan De Oliveira
wrote:
> On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
>> @@ -4754,6 +4751,9 @@ static void intel_post_plane_update(struct intel_crtc
>> *crtc)
>> if (atomic->post_enable_primary)
>> intel_post_enable_
Hi,
+marcheu
On 26 November 2015 at 10:07, Daniel Vetter wrote:
> On Wed, Nov 25, 2015 at 05:09:02PM +0530, Thulasimani, Sivakumar wrote:
>> however good to explicitly check for this,
>> following needs to be tested before sending in next patch/merge
>> 1) MST displays verification (Ander's repor
Hi,
On 30 November 2015 at 15:14, Daniel Vetter wrote:
> It really is a core drm testcase and not a libdrm testcase. While at it
> also make it generic, since it is.
>
> Cc: Daniel Stone
> Signed-off-by: Daniel Vetter
Currently in the middle of recabling my ARM farm, so can&#x
Hi,
On 4 December 2015 at 08:46, Daniel Vetter wrote:
> + /*
> +* Reject event generation for when a CRTC is off and stays off. It
> +* wouldn't be hard to implement this, but userspace has a track
> record
> +* of happily burning through 100% cpu (or worse, crash)
ination ... Also suggestions from Thierry.
What a beautifully-coloured shed.
Reviewed-by: Daniel Stone
Cheers,
Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi,
On 9 December 2015 at 05:15, Vandana Kannan wrote:
> This patch includes enabling render decompression after checking all the
> requirements (format, tiling, rotation etc.). Along with this, the WAs
> mentioned in BSpec Workaround page have been implemented.
> In case, any of the conditions f
1 - 100 of 323 matches
Mail list logo
