On Thu, Apr 08, 2021 at 01:40:59PM +0200, Paolo Bonzini wrote:
> On 08/04/21 12:05, Daniel Vetter wrote:
> > On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> > > On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > > > Both kvm (in bd2
t much yolo locking here, I'd minimally put a comment
there that we don't actually care about races, it's just to shut up ttm
locking checks. Whether that's true or not is another question I think.
And if it's just this case here, maybe inline the trylock, and for t
On Thu, Apr 08, 2021 at 02:44:16PM +0200, Christian König wrote:
> Am 08.04.21 um 13:31 schrieb Daniel Vetter:
> > On Thu, Apr 08, 2021 at 01:17:32PM +0200, Christian König wrote:
> > > Am 08.04.21 um 13:08 schrieb Daniel Vetter:
> > > > On Thu, Apr 01, 2021 at 03:
On Fri, Apr 09, 2021 at 09:06:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 11:48 schrieb Daniel Vetter:
> >
> > Maybe just me, but to avoid overstretching the attention spawn of doc
> > readers I'd avoid this example here. And maybe make the recomm
On Fri, Apr 09, 2021 at 09:54:03AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 11:48 schrieb Daniel Vetter:
> > On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote:
> > > Platform devices might operate on firmware framebuffers, such as VESA or
&g
On Fri, Apr 09, 2021 at 01:07:30PM +0200, Christian König wrote:
> Only needed during device hot plug and remove and not exported.
>
> Signed-off-by: Christian König
> Suggested-by: Bernard
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_device.c | 4 ++--
&g
fore 2000 that would shed some light
on why this code even exists.
I think we can just tune down the pr_info_once to pr_debug and done.
Maybe a comment about where the single user we're aware of is.
-Daniel
>
> The fact that v_vlin/v_clin are ignored doesn't necessarily mean that
or your patche, merged to drm-misc-next for 5.14.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5b4547e0f775..46dceb51c90f 100644
>
On Mon, Apr 12, 2021 at 2:18 PM Matthew Auld wrote:
>
> Add an entry for the new uAPI needed for DG1.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Daniel Vetter
> Cc: Dave Airlie
> ---
> Documentation/gpu/rfc/i915_create_ext.c | 4
l below + what component. So for these two patches it
would be drm/atomic-helpers: as prefix in the patch summary lines. Can
you pls adjust that? Patches look good otherwise.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 8
> 1 file changed, 4 insertions(+), 4 dele
On Thu, Apr 08, 2021 at 05:39:22PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 08, 2021 at 04:57:51PM +0300, Pekka Paalanen wrote:
> > On Thu, 8 Apr 2021 13:30:16 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Apr 08, 2021 at 12:59:19PM +0300, Pekka Paalanen wr
On Thu, Apr 08, 2021 at 07:24:30PM -0300, Leandro Ribeiro wrote:
>
>
> On 4/8/21 8:35 AM, Daniel Vetter wrote:
> > On Tue, Apr 06, 2021 at 04:21:16PM -0300, Leandro Ribeiro wrote:
> >> This patch is to emphasize how userspace should use the plane format list
> >
On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote:
> On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
> >
> > On Mon, Apr 05, 2021 at 10:45:23AM -0700, Rob Clark wrote:
> > > From: Rob Clark
> > >
> > > One would normally hope not to be und
I guess subject should have i915/selftest in it? Also if you resubmit
other people's code needs your sob. Otherwise looks reasonable.
-Daniel
> ---
> drivers/gpu/drm/i915/selftests/i915_vma.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/se
Mohammed Khajapasha
Sob missing (I didn't check all previous patches), but also I think we
should aim more to reuse drm fbdev helpers and retire our owns here.
Eventually, long-term, and all that.
-Daniel
> ---
> drivers/gpu/drm/i915/display/intel_fbdev.c | 29 +-
&
p having the same struct member name in all lock types, and is not
exposed to drivers at all.
Am I missing something, or why do we have this compile-time type casting
stuff going on in i915 page accessors?
-Daniel
> ---
> .../drm/i915/gem/selftests/i915_gem_context.c | 11 +
> drivers/
. IIRC you suggested that years ago and I'm working on
> the details of that idea ever since.
Yeah that's going to be a pile :-) But I think we've reached the same
conclusion on i915 for polishing our lmem manager (atm it's ghost objects
all the way down), before we
" of the patches in the series.
Also applied to drm-misc-next.
-Daniel
>
> Fabio M. De Francesco (2):
> gpu: drm: Replace "unsigned" with "unsigned int"
> gpu: drm: Correct comments format
>
> drivers/gpu/drm/drm_atomic_helper.c | 40 ++--
On Mon, Apr 12, 2021 at 08:23:33AM -0700, Rob Clark wrote:
> On Mon, Apr 12, 2021 at 7:28 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 08, 2021 at 08:23:42AM -0700, Rob Clark wrote:
> > > On Thu, Apr 8, 2021 at 4:15 AM Daniel Vetter wrote:
> > > >
> > &g
On Mon, Apr 12, 2021 at 07:01:19PM +0300, Jani Nikula wrote:
> On Mon, 12 Apr 2021, Daniel Vetter wrote:
> > And that's some serious wtf. Yes we've done some compile-time type
> > casting automagic between i915_priv and dev in the past, and I think even
> >
On Mon, Apr 12, 2021 at 05:49:50PM +0200, Thomas Hellström wrote:
> On Mon, 2021-04-12 at 17:43 +0200, Daniel Vetter wrote:
> > On Mon, Apr 12, 2021 at 04:21:37PM +0200, Christian König wrote:
> > >
> > >
> > > Am 12.04.21 um 16:16 schrieb Tho
On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld
wrote:
>
> On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote:
> >
> > On Mon, Apr 12, 2021 at 10:05:25AM +0100, Matthew Auld wrote:
> > > We need to general our accessor for the page directories and tables from
> >
the case here for both komeda and
malidp.
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Brian Starkey
---
drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 1 -
drivers/gpu/drm/arm/malidp_drv.c| 1 -
2 files changed, 2
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++--
1 file changed, 7 insertions
the case here.
This one actually set it twice on top of what drm_plane_init does, so
double-redundant!
Signed-off-by: Daniel Vetter
Cc: Philipp Zabel
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: linux-arm-ker...@lists.infradead.org
the case here.
Signed-off-by: Daniel Vetter
Cc: Yannick Fertre
Cc: Philippe Cornu
Cc: Benjamin Gaignard
Cc: Maxime Coquelin
Cc: Alexandre Torgue
Cc: linux-st...@st-md-mailman.stormreply.com
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/stm/ltdc.c | 2 --
1 file changed, 2
the case here.
Signed-off-by: Daniel Vetter
Cc: Eric Anholt
Cc: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index bb5529a7a9c2..f29ac64a5aa5 100644
--- a/drivers/gpu/drm/vc4
shmem helpers seem a bit sloppy here by automatically rounding up when
actually creating the buffer, which results in under-reporting of what
we actually have. Caught by igt/vgem_basic tests.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 4 ++--
1 file changed, 2
the case here.
Signed-off-by: Daniel Vetter
Cc: "Ville Syrjälä"
Cc: Manasi Navare
Cc: Jani Nikula
Cc: "José Roberto de Souza"
Cc: Chris Wilson
Cc: Imre Deak
Cc: Dave Airlie
Cc: Maarten Lankhorst
Cc: Karthik B S
Cc: Matt Roper
---
drivers/gpu/drm/i915/display/intel
the case here.
Signed-off-by: Daniel Vetter
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Cc: Krzysztof Kozlowski
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
---
drivers/gpu/drm/exynos/exynos_drm_fb.c | 2 --
1 file changed, 2 deletions
the case here.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Kalyan Thota
Cc: Jordan Crouse
Cc: Eric Anholt
Cc: Tanmay Shah
Cc: Rajendra Nayak
Cc: Jeykumar Sankaran
Cc: Qinglang Miao
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 5 -
1 file changed, 5 deletions(-)
diff --git a
: Pekka Paalanen
Cc: Rob Clark
Cc: Jordan Crouse
Cc: Emil Velikov
Cc: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 --
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 8 +++-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: sta...@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc:
org # v5.1 +
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/dc.c | 10 --
drivers/gpu/drm/tegra/drm.c | 2 --
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/d
none of the planes registered supported
modifiers).
Now that this is all done consistently across all drivers, document
the rules and enforce it in the drm core.
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airli
.gmail.com/
Acked-by: Christian König
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off-by: Daniel Vetter
Cc: Melissa Wen
Cc: Chris Wilson
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/vgem/vgem_drv.c | 340 +---
2 files changed, 4 insertions(+), 337 deletions(-)
diff --git a/dri
On Tue, Apr 13, 2021 at 11:29 AM Matthew Auld
wrote:
>
> On Mon, 12 Apr 2021 at 18:01, Daniel Vetter wrote:
> >
> > On Mon, Apr 12, 2021 at 6:08 PM Matthew Auld
> > wrote:
> > >
> > > On Mon, 12 Apr 2021 at 16:17, Daniel Vetter wrote:
> > >
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019
On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> On Tue, 13 Apr 2021 11:49:03 +0200
> Daniel Vetter wrote:
>
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitte
On Tue, Apr 13, 2021 at 01:54:00PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:49 +0200 schrieb Daniel Vetter:
> > It's very confusing for userspace to have to deal with inconsistencies
> > here, and some drivers screwed this up a bit. Most just ommitted the
On Tue, Apr 13, 2021 at 04:11:29PM +0200, Daniel Vetter wrote:
> On Tue, Apr 13, 2021 at 02:56:02PM +0300, Pekka Paalanen wrote:
> > On Tue, 13 Apr 2021 11:49:03 +0200
> > Daniel Vetter wrote:
> >
> > > It's very confusing for userspace to have to deal with i
is found before using it.
> >
> > Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI
> > D0")
> > BugLink: https://bugs.launchpad.net/bugs/1922403
> > Signed-off-by: Kai-Heng Feng
>
> Reviewed-by: Alex Deucher
fbdev is in drm-misc, so may
On Mon, Apr 12, 2021 at 06:07:32PM -0400, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> Same PR as last week plus a few accumulated fixes, rebased on drm-next
> to resolve the dependencies between ttm and scheduler with changes in amdgpu.
>
> The following ch
On Sun, Apr 11, 2021 at 05:53:32PM -0700, Rob Clark wrote:
> Hi Dave&Daniel,
>
> This time around a bit larger than usual, but a large part of that is
> Dmitry's dsi phy/pll refactor (which is itself a pretty large negative
> diffstat). The dsi phy/pll refactor includes
Lucas Stach
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 18 +-
include/drm/drm_mode_config.h | 2 ++
2 files changed, 19 insertions(+), 1 del
On Wed, Apr 14, 2021 at 10:24:22AM +0800, Liu Ying wrote:
> Hi Daniel,
>
> On Tue, 2021-04-13 at 16:14 +0200, Lucas Stach wrote:
> > Am Dienstag, dem 13.04.2021 um 16:04 +0200 schrieb Daniel Vetter:
> > > On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
that someone else has already accounted these buffers against
the ttm memory hard-limit anywhere? If not I think this needs to wait for
the shrinker work to get solid, since fixing the double-accounting for
this is probably not worth it.
-Daniel
> ---
> drivers/gpu/drm/ttm/ttm_tt.c | 27 +
ffers together. At least until
the shrinker has landed.
And this here just opens up the barn door without any explanation why it's
ok.
-Daniel
>
> Regards,
> Christian.
>
> > ---
> > drivers/gpu/drm/ttm/ttm_tt.c | 27 ++-
> > 1 file chang
proving code maintainability
> in vkms.
>
> Signed-off-by: Melissa Wen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_drv.h| 8 ++--
> drivers/gpu/drm/vkms/vkms_output.c | 19 +--
> drivers/gpu/drm/vkms/vkms_plane.c | 29 +++
elissa Wen
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vkms/vkms_composer.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
> b/drivers/gpu/drm/vkms/vkms_composer.c
> index
's
going to be a lot slower. Maybe worth checking, and perhaps we need to
throw some ineline hints (like always_inline or something like that) on
both the blend function and the alpha_blending and x_blending helpers.
Cursor is generally tiny, but when we start "blendin
ary <- overlay) <- cursor)
> + */
> + for (i = 1; i < crtc_state->num_active_planes; i++)
> + compose_planes(primary_composer,
Ofc that then clashes with compose_planes here, but this function only
composes a single plane. So the plural plane_s_ is kinda wrong, and we
c
On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestions from
On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 08:51:51AM +0200, Christian König wrote:
> > > Am 14.04.21 um 08:48 schrieb Felix Kuehling:
> > > > Pages in SG BOs were not al
On Wed, Apr 14, 2021 at 12:49 PM Christian König
wrote:
>
> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 11:19:41AM +0200, Christian König wrote:
> >> Am 14.04.21 um 11:15 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 08:51:
On Wed, Apr 14, 2021 at 2:43 PM Christian König
wrote:
>
> Am 14.04.21 um 14:25 schrieb Daniel Vetter:
> > On Wed, Apr 14, 2021 at 12:49 PM Christian König
> > wrote:
> >> Am 14.04.21 um 12:26 schrieb Daniel Vetter:
> >>> On Wed, Apr 14, 2021 at 11:19:41AM
On Tue, Apr 13, 2021 at 01:37:38PM +0200, Thierry Reding wrote:
> On Tue, Apr 13, 2021 at 11:49:01AM +0200, Daniel Vetter wrote:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019
On Tue, Apr 13, 2021 at 01:47:28PM +0200, Lucas Stach wrote:
> Am Dienstag, dem 13.04.2021 um 11:48 +0200 schrieb Daniel Vetter:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019
On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.04.21 um 11:22 schrieb Daniel Vetter:
> > > Is it that easy? simepldrm's detach function has code to synchronize with
> > > concurrent hotplug removals. If we can use drm_de
On Thu, Apr 15, 2021 at 12:17:34PM +0200, Thomas Zimmermann wrote:
> Drivers may want to set their own callbacks for a VM area. Only set
> TTM's callbacks if the vm_ops field is clear.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/
408,6 +408,16 @@ void unregister_shrinker(struct shrinker *shrinker)
> }
> EXPORT_SYMBOL(unregister_shrinker);
>
> +/**
> + * sync_shrinker - Wait for all running shrinkers to complete.
Maybe make it clear this is a barrier type thing, it wont stop shrinkers
at all, just synchronize
On Thu, Apr 15, 2021 at 08:59:11AM -0400, Rodrigo Vivi wrote:
> Hi Dave and Daniel,
>
> Here goes drm-intel-fixes-2021-04-15:
>
> Display panel & power related fixes:
>
> - Backlight fix (Lyude)
> - Display watermark fix (Ville)
> - VLV panel power fix (Hans)
&
> > either attach a grabbed lock to the list for batch unlocking, or be
> > responsible for unlocking when the lock's scope is exited. It's also
> > possible to create sublists if so desired. I believe the below would be
> > sufficient to cover the i915 functional
On Thu, Apr 15, 2021 at 4:02 PM Thomas Hellström (Intel)
wrote:
>
>
> On 4/15/21 3:37 PM, Daniel Vetter wrote:
> > On Tue, Apr 13, 2021 at 09:57:06AM +0200, Christian König wrote:
> >>
> >> Am 13.04.21 um 09:50 schrieb Thomas Hellström:
> >>> Hi!
>
On Thu, Apr 15, 2021 at 01:00:40PM +0200, Thomas Zimmermann wrote:
> It's only used by DRM_FBDEV_EMULATION, so inline it there.
>
> Signed-off-by: Thomas Zimmermann
I'm not sure on patch 1, I'll leave that to Zack, but I think 2-4 would
work alone too. On those:
On Thu, Apr 15, 2021 at 05:40:24PM +0200, Thomas Hellström (Intel) wrote:
>
> On 4/15/21 4:40 PM, Daniel Vetter wrote:
> > On Thu, Apr 15, 2021 at 4:02 PM Thomas Hellström (Intel)
> > wrote:
> > >
> > > On 4/15/21 3:37 PM, Daniel Vetter wrote:
> > &g
this,
since he just reviewed the gem_create_ext rfc from Matt.
-Daniel
> drivers/gpu/drm/i915/i915_drv.c| 2 +-
> include/uapi/drm/i915_drm.h| 47 ++
> 3 files changed, 88 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gp
creation uapi, so needs coordination. Also
ping maintainers for awareness, not sure yet how to get this merged
with the branches we have (I forgot the maintainer ping on patch 12).
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 59 ++-
>
el modesetting - vmwgfx_kms.c
> >
>
> This changes the behavior a bit, I guess DRM_VMWGFX (or at least
> DRM_VMWGFX_FBCON) would need to select DRM_FBDEV_EMULATION to preserve the
> old behavior, but that's largely due to the fact that given how those options
> were setup we never run without FB set. In general it should be ok and looks
> more reasonable than the current setup. I'll try it out on Monday just in
> case, but for now:
The issue is that select in Kconfig is pretty annoying (hard to
disable, and it's not recursive), so there's a bit a push to retire
it. Especially for user-facing config knobs like whether you want
fbdev emulation or not. Hence the change.
-Daniel
> Reviewed-by: Zack Rusin
>
> z
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Apr 15, 2021 at 09:12:14PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 15.04.21 um 14:57 schrieb Daniel Vetter:
> > On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 09.04.21 um 11:22 schrieb Daniel Vett
On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> It's not properly formatted kernel doc, just nerf the warnings for now.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jaso
On Thu, Apr 15, 2021 at 04:59:56PM +0100, Matthew Auld wrote:
> Add some example usage for the extension chaining also, which is quite
> nifty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vette
On Thu, Apr 15, 2021 at 04:59:57PM +0100, Matthew Auld wrote:
> Add a note about the two-step process.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason
On Fri, Apr 16, 2021 at 10:44:28AM +0200, Daniel Vetter wrote:
> On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> > It's not properly formatted kernel doc, just nerf the warnings for now.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtine
On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
> On 4/15/21 8:59 AM, Matthew Auld wrote:
> > Add a note about the two-step process.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Jordan Justen
On Thu, Apr 15, 2021 at 04:59:58PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestion
Hi Linus,
I pinged the usual suspects, only intel fixes pending. drm-next also looks
ready, minus the big pull request summary Dave will have to type next
week.
Cheers, Daniel
drm-fixes-2021-04-16:
drm/i915 fixes
Cheers, Daniel
The following changes since commit
On Fri, Apr 16, 2021 at 12:37 PM Matthew Auld wrote:
>
> Add section for drm/i915 uAPI and pull in i915_drm.h.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
>
On Fri, Apr 16, 2021 at 6:38 PM Jason Ekstrand wrote:
>
> On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
> >
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for m
more difficult to propagate the return from the bottom to up.
> So I ended up with this approach as it's much simpler.
Yeah that's because atomic assume you can at least blank your screen to black.
-Daniel
> But if there is any better way (even simpler or more robust), I'd
>
On Sun, Apr 18, 2021 at 1:03 AM Dave Airlie wrote:
>
> Hi Zack,
>
> Please make sure to always cc dri-devel and/or Daniel on these so if
> I'm away they don't get lost, but also so that they make it into
> patchwork for processing.
>
> If you have a chance can
.13 is what we work on right now.
>
> Yeah, but how do you want to get it into Linus tree?
>
> I can push it together with other DMA-buf patches through drm-misc-next and
> then Dave will send it to Linus for inclusion in 5.13.
Small correction, we've already frozen for the mer
On Tue, Apr 20, 2021 at 03:31:27PM +0900, Inki Dae wrote:
>
>
> 21. 4. 13. 오후 6:48에 Daniel Vetter 이(가) 쓴 글:
> > Since
> >
> > commit 890880ddfdbe256083170866e49c87618b706ac7
> > Author: Paul Kocialkowski
> > Date: Fri Jan 4 09:56:10 2019 +0100
> &
erface, but really there's not much
userspace for it. In other words, it would work as well as current offb
would, but that's at least that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
}
> > > > + ret = bo->bdev->funcs->verify_access(bo, filp);
> > >
> > > Is there any reason we can't call vmw_verify_access() directly here?
> > >
> > > Would allow us to completely nuke the verify_access callback as well
> > &g
2: warning: expecting prototype for A
> > buffer object shrink method that tries to swap out the first(). Prototype
> > was for ttm_global_swapout() instead
> >
> > Cc: Christian Koenig
> > Cc: Huang Rui
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: dri-d
comment stating that this is all just to make
gcc happy.
>
> Signed-off-by: Fabio M. De Francesco
Applied to drm-misc-next, thanks for the patch.
-Daniel
> ---
>
> Changes from v1: Added the reason why of this change in the log.
>
> drivers/gpu/drm/drm_bufs.c |
dea (because it's a pretty
long list of patches that have come up on this).
So what is this for?
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 12
> fs/proc/meminfo.c | 5 -
> include/linux/dma-buf.h | 1 +
> 3 files changed, 17 insertions(+), 1 dele
On Mon, Apr 19, 2021 at 10:18:07AM +0200, Krzysztof Kozlowski wrote:
> Remove trailing whitespaces. No functional change.
>
> Signed-off-by: Krzysztof Kozlowski
Both patches applied to drm-misc-next, thanks.
-Daniel
> ---
> drivers/gpu/drm/gma500/backlight.c| 4 +--
>
o force-probe a connector
> anymore. Instead, KMS will perform a regular read-only connector
> query.
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
> Cc: Pekka Paalanen
> ---
> drivers/gpu/drm/drm_connector.c | 11 ---
> include/uapi/drm/drm_mode.h
accordingly. Thanks to the implicit device
selection performed when creating an EGLDisplay from a gbm_device, we
cannot currently discover what that device node is.
> Do you have any other potential solution in mind?
I can't think of any right now, but am open to hearing them.
> W
, priority inversions be damned. I'm really not sure we should
fight that - if it's really that inefficient then maybe hw will add
support for waiting sync constructs in hardware, or at least be
smarter about scheduling other stuff. E.g. on intel hw both the kernel
scheduler and fw scheduler
On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote:
> > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Apr 16, 2021 at 11:00 AM Thomas Zimmermann
&
On Tue, Apr 20, 2021 at 09:26:00AM +, peter.enderb...@sony.com wrote:
> On 4/20/21 10:58 AM, Daniel Vetter wrote:
> > On Sat, Apr 17, 2021 at 06:38:35PM +0200, Peter Enderborg wrote:
> >> This adds a total used dma-buf memory. Details
> >> can be found in deb
Just 2 comments on the kernel aspects here.
On Tue, Apr 20, 2021 at 12:18 PM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote:
>>
>> I'm working on a Wayland extension [1] that, among other things, allows
>> compositors to advert
On Tue, Apr 20, 2021 at 07:03:19AM -0400, Marek Olšák wrote:
> Daniel, are you suggesting that we should skip any deadlock prevention in
> the kernel, and just let userspace wait for and signal any fence it has
> access to?
Yeah. If we go with userspace fences, then userspace can hang it
ssible memory will cause an allocation failure or
> invoke the OOM killer. Evictions to GPU-inaccessible memory might not be
> supported.
>
> Kernel drivers could move to this new memory management today. Only buffer
> residency and evictions would stop using per-BO fences.
>
e FIFO (the codec wants
to push things through in order), and some of them are mailbox (the display
wants to get the latest content, not from half a second ago before the
other player started jumping around and now you're dead). You can't reason
about any of these dependencies ahead of t
Hi,
On Tue, 20 Apr 2021 at 13:01, Daniel Vetter wrote:
> - We live in a post xf86-video-$vendor world, and all these other
> compositors rely on implicit sync. You're not going to be able to get
> rid of them anytime soon. What's worse, all the various EGL/vk buffer
>
301 - 400 of 26160 matches
Mail list logo
