On Wed, Apr 16, 2025 at 11:38:03AM +0200, Simona Vetter wrote:
> On Wed, Apr 16, 2025 at 08:57:45AM +0200, Thomas Zimmermann wrote:
> > Test struct drm_gem_object.import_attach to detect imported objects.
> >
> > During object clenanup, the dma_buf field might be NULL.
t; /**
> > diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-
> > buf.h
> > index
> > 5a6fda66d9adf01438619e7e67fa69f0fec2d88d..f3aba46942042de6a2e3a4cca3e
> > b3f87175e29c9 100644
> > --- a/include/uapi/linux/dma-buf.h
> > +++ b/include/uapi/linux/dma-buf.h
> > @@ -178,5 +178,6 @@ struct dma_buf_import_sync_file {
> > #define DMA_BUF_SET_NAME_B _IOW(DMA_BUF_BASE, 1, __u64)
> > #define DMA_BUF_IOCTL_EXPORT_SYNC_FILE _IOWR(DMA_BUF_BASE, 2,
> > struct dma_buf_export_sync_file)
> > #define DMA_BUF_IOCTL_IMPORT_SYNC_FILE _IOW(DMA_BUF_BASE, 3, struct
> > dma_buf_import_sync_file)
> > +#define DMA_BUF_IOCTL_GET_DMA_ADDR _IOR(DMA_BUF_BASE, 4, __u64
> > *)
> >
> > #endif
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ut stolen memory.
2. Account, but don't enforce any limits on evictions. This could already
get funny if then system memory allocations start failing for random
reasons due to memory pressure from other processes.
3. Probably at this point we need a memcg aware shrinker in ttm drivers
that want
n
> Cc: Anusha Srivatsa
> Cc: Christian König
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Simona Vetter
> Cc: Sumit Semwal
> Cc: "Christian König"
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-me...@vger.kernel.org
>
On Tue, Apr 15, 2025 at 03:57:11PM +0200, Christian König wrote:
> Am 15.04.25 um 15:10 schrieb Simona Vetter:
> >> This is for devices who only want to do a vmap of the buffer, isn't it?
> > ... it's for the vmap only case, where you might not even have a struct
>
term goal is to make import_attach optional because its setup
> > requires a DMA-capable device.
>
> HUI WHAT?
>
> Dmitry and I put quite some effort into being able to create an import_attach
> without the requirement to have a DMA-capable device.
>
> The last puzzl
On Mon, Apr 14, 2025 at 04:28:55PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 14, 2025 at 08:56:56AM +, Simon Ser wrote:
> > Explain how to perform front-buffer rendering.
> >
> > v2: apply Pekka's rewrite
> >
> > Signed-off-by: Simon Ser
> &g
On Mon, Apr 14, 2025 at 01:22:06PM +0200, Boris Brezillon wrote:
> Hi Sima,
>
> On Fri, 11 Apr 2025 14:01:16 +0200
> Simona Vetter wrote:
>
> > On Thu, Apr 10, 2025 at 08:41:55PM +0200, Boris Brezillon wrote:
> > > On Thu, 10 Apr 2025 14:01:03 -0400
On Mon, Apr 14, 2025 at 02:08:25PM +0100, Liviu Dudau wrote:
> On Mon, Apr 14, 2025 at 01:22:06PM +0200, Boris Brezillon wrote:
> > Hi Sima,
> >
> > On Fri, 11 Apr 2025 14:01:16 +0200
> > Simona Vetter wrote:
> >
> > > On Thu, Apr 10, 2025 at 08:41:55P
r flushing.
Then just grow dynamic memory synchronously with some heuristics in the
next CS ioctl, that gives you appropriate amounts of throttling, no issues
with error reporting, and you can just use GFP_KERNEL.
> That sounds like it most likely won't work. In an OOM situation the
>
On Fri, Apr 11, 2025 at 02:50:19PM +0200, Christian König wrote:
> Am 11.04.25 um 14:01 schrieb Simona Vetter:
> > On Thu, Apr 10, 2025 at 08:41:55PM +0200, Boris Brezillon wrote:
> >> On Thu, 10 Apr 2025 14:01:03 -0400
> >> Alyssa Rosenzweig wrote:
> >>
>
the context, "transparently" creating a new one and a mix of recreating
some internal driver objects and thoughts&prayers to give the new context
the best chances possible.
You really want all the tricks in step 1 and the quirks in 3 to make sure
this doesn't ever happen. Or at most once per app, hopefully.
I promised terrible after all :-P
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
those, we'll probably need to improve the
guesstimation 1b if it's systematically off by too much. We might even
need to store that on-disk, like shader caches, so that you get a crash
once and then it should work even without an explicit mesa quirk.
Documentation
-
Assuming this is not too terrible an idea and we reach some consensus, I
think it'd be good to bake this into a doc patch somewhere in the
dma_fence documentation. Also including Alyssa recipe for when you have
hardware support for flushing partial rendering. And maybe generalized so
it makes sense for the GS/streamout/... fun on apple hardware.
And perhaps with a section added that points to actual code to help make
this happen like the sparse bo support in this series.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
shall
> retain your authorship. In this case it does appear instead of putting
> in the 5 minutes of looking at Danilo's reasoning and supplied diff,
> and either saying "my bad, this is sufficiently new code and I don't
> feel I wrote it" or "I'd still prefer to retain authorship despite
> your changes", both of which Danilo indicated would be respected you
> somehow picked door number 3 which probably took more time and effort
> than either of the above options. Again no need to pick door number 3
> here, you can let the bus go below 50, it won't explode.
To emphasis and maybe a bit more dry&serious, signed off by lines are not
optional, because they signify agreement to the developer certificate of
origin irrespective of the original license. Upstream has some patches
without sob lines from all authors (well copyright holders to be strict,
with companies there's often some internal authors that get dropped), but
that is some very special case and needs real care.
On the topic itself there's a few different ways to do this, depending
whether it's more co-authorship, a complete rewrite or just some small
bugfixes on top of an existing patch. The important part is that all
authors are acknowledged, and that we have sob lines from everyone.
Ideally also with archive links, where that's not obvious, e.g. when patch
titles changed or the entire series was rewritten or when the original
patch never was submitted to a list tracked by lore.k.o.
Unfortunately git doesn't allow multiple authors, so we cannot acknowledge
them all exactly equally due to lacking tooling in the co-authored case.
But that's what the Co-Authored-by or similar tags are meant for.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;& DRM_DISABLE_EXTRA_BUILD_CHECKS=n
> + default !DRM_DISABLE_EXTRA_BUILD_CHECKS
> +
> config DRM_WERROR
> bool "Compile the drm subsystem with warnings as errors"
> - depends on DRM && EXPERT
> + depends on DRM_EXTRA_BUILD_CHECKS
>
| 39
> ++
> mm/cma.c | 21 +++-
> mm/cma.h | 3 ++
> 17 files changed, 211 insertions(+), 3 deletions(-)
> ---
> base-commit: 55a2aa61ba59c138bd956afe0376ec412a7004cf
> change-id: 20250307-dmem-cgroups-73febced0989
>
> Best regards,
> --
> Maxime Ripard
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
and-alone. Rolling this out as a flag day change is just not realistic I
think, it's just setting yourself up for failure. I think there's two real
optiosn here:
- Gradually roll this out, ideally with support in main Kbuild so it
doesn't have to be replicated.
- Just shoot it down and move on.
This isn't a refactoring, it's pretty substanstial change in how headers
work and how people need to treat them. And you just never change people
with a flag day approach, that doesn't ever work. And if you try, you'll
just piss of a lot of folks who are taken by surprise by your change.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
anything we had discussion whether this is
an acceptable one-off exception for special circumstance. Thanks a lot to
Alyssa for driving this. The very much summarized consensus is that due to
rust this is a special case, and because the userspace is in upstream mesa
and lead by people who know what
On Fri, 14 Mar 2025 at 11:16, Jacek Lawrynowicz
wrote:
>
> Hi,
>
> On 3/4/2025 6:06 PM, Simona Vetter wrote:
> > Hi Jacek!
> >
> > Bit late reply, was sick last week and still recovering from missed mails.
> >
> > On Thu, Feb 20, 2025 at 11:50:10AM +0
On Wed, Mar 19, 2025 at 02:21:32PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 13, 2025 at 03:32:14PM +0100, Simona Vetter wrote:
>
> > So I think you can still achieve that building on top of revocable and a
> > few more abstractions that are internally unsafe. Or a
21 -
> > include/linux/leds.h | 6 ++
> > 11 files changed, 205 insertions(+), 208 deletions(-)
>
> No immediately obvious issues from the LEDs side.
>
> Still needs reviews from Backlight and fbdev.
I looked throught the series and it's a small step, but I think it's the
right direction for where we want backlight/fbdev/drm-kms to head towards
long-term. So on the series:
Acked-by: Simona Vetter
Cheers, Sima
>
> --
> Lee Jones [李琼斯]
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Mar 07, 2025 at 10:55:57AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 02:09:12PM +0100, Simona Vetter wrote:
>
> > > A driver can do a health check immediately in remove() and make a
> > > decision if the device is alive or not to speed up removal
to get a device to use for resource
> > > > > > > management of drm resources. Change the driver to use the faux
> > > > > > > device
> > > > > > > instead as this is NOT a real platform device.
> > > > &g
s/gpu/drm/radeon/atombios_dp.c | 8 +-
> include/drm/display/drm_dp_helper.h| 92 +-
> 12 files changed, 322 insertions(+), 315 deletions(-)
> ---
> base-commit: 565351ae7e0cee80e9b5ed84452a5b13644ffc4d
> change-id: 20241231-drm-rework-dpcd-access-b0fc2e47d613
>
> Best regards,
> --
> Dmitry Baryshkov
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-
> drivers/gpu/drm/udl/udl_drv.h | 1 -
> drivers/gpu/drm/udl/udl_main.c | 14 -
> include/drm/drm_device.h | 41 ++
> 10 files changed, 102 insertions(+), 101 deletions(-)
>
> --
> 2.48.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Mar 07, 2025 at 03:30:41PM +0800, Andy Yan wrote:
>
> Hi All,
> At 2025-03-07 09:08:48, "Andy Yan" wrote:
> >Hi All,
> >
> >At 2025-03-06 23:41:24, "Simona Vetter" wrote:
> >>On Thu, Mar 06, 2025 at 08:10:16AM +0100, Maxime Ripa
On Fri, Mar 07, 2025 at 09:42:25AM +0100, Simona Vetter wrote:
> On Tue, Feb 18, 2025 at 03:23:25PM +0100, Thomas Zimmermann wrote:
> > Add drm_modes_size_dumb(), a helper to calculate the dumb-buffer
> > scanline pitch and allocation size. Implementations of struct
> > drm_d
On Fri, Mar 07, 2025 at 08:32:55AM -0400, Jason Gunthorpe wrote:
> On Fri, Mar 07, 2025 at 11:28:37AM +0100, Simona Vetter wrote:
>
> > > I wouldn't say it is wrong. It is still the correct thing to do, and
> > > following down the normal cleanup paths is a good wa
On Thu, Mar 06, 2025 at 11:32:36AM -0400, Jason Gunthorpe wrote:
> On Thu, Mar 06, 2025 at 11:42:38AM +0100, Simona Vetter wrote:
> > > Further, I just remembered, (Danilo please notice!) there is another
> > > related issue here that DMA mappings *may not* outlive remove()
-++
> + * | 8 | * DRM_FORMAT_C8 | * DRM_FORMAT_R8 |
> + * ++++
> + * | 4 | * DRM_FORMAT_C4 | * DRM_FORMAT_R4 |
> + * +----+
anic handler?
Yeah I really don't like the idea of creating some really brittle one-off
core mm code just so we don't have to vmap a buffer unconditionally. I
think even better would be if drm_panic can cope with non-linear buffers,
it's entirely fine if the drawing function absol
ble failed: %d\n", ret);
> - tc358768_bridge_disable(bridge);
> - tc358768_bridge_post_disable(bridge);
> - }
> }
>
> #define MAX_INPUT_SEL_FORMATS1
>
> static u32 *
>
> --
> 2.48.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
helper will be in a
> drm_bridge_helper.c file to follow the pattern we have for other
> objects.
>
> Co-developed-by: Simona Vetter
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/Makefile| 1 +
> drivers/gpu/drm/drm_bridge_helper.c | 55
> +
ake these drivers'
> life easier.
>
> Reviewed-by: Dmitry Baryshkov
> Co-developed-by: Simona Vetter
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/drm_atomic.c | 45
>
> include/drm/drm_atomic.h | 3 +++
> 2
, like from the hotplug interrupt path or
> > >> > >any
> > >> > >interrupt handler.
> > >> > >
> > >> > >Let's introduce a function to retrieve the connector currently
> > >> > >assigned
> > >&
On Wed, Mar 05, 2025 at 11:10:12AM -0400, Jason Gunthorpe wrote:
> On Wed, Mar 05, 2025 at 08:30:34AM +0100, Simona Vetter wrote:
> > - developers who want to quickly test new driver versions without full
> > reboot. They're often preferring convenience over correctness,
e orphaned, I stuffed it into
drm-misc-next now, thanks for the ping&patch.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Mar 04, 2025 at 12:42:01PM -0400, Jason Gunthorpe wrote:
> On Tue, Mar 04, 2025 at 05:10:45PM +0100, Simona Vetter wrote:
> > On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> > > On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
> &g
user space and
> firmware every couple of weeks here:
> https://github.com/intel/linux-npu-driver/releases
Yeah you need to fix this. With containers and other packages runtimes
there's really no connection between the base os image, and the userspace
you're running. Which means you really cannot assume that on any given
system there's only one abi version across the firmware and userspace
libraries. So even without upstreams "no breaking uapi" guarantee this
does not work in production.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 28, 2025 at 02:40:13PM -0400, Jason Gunthorpe wrote:
> On Fri, Feb 28, 2025 at 11:52:57AM +0100, Simona Vetter wrote:
>
> > - Nuke the driver binding manually through sysfs with the unbind files.
> > - Nuke all userspace that might beholding files and other resour
On Thu, Feb 27, 2025 at 11:38:05AM +0200, Jani Nikula wrote:
> Update GVT-g MAINTAINERS entry to reflect the current status of
> maintenance and repositories.
>
> Cc: Dave Airlie
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: Simona Vetter
> Cc: Tvrtko Ursulin
>
indings::drm_panic_qr_max_data_size}`
>found fn item `extern "C" fn(_, _) -> _
> {drm_panic_qr_max_data_size}`
>
> Reviewed-by: Andreas Hindborg
> Signed-off-by: Alice Ryhl
I guess makes most sense to land this all through a rust tree, for that:
Acked-by: Simona Vetter
The
his nova effort is
> rebuilding from the ground up. So we should avoid just blindly following
> this aspect of the original DRM design.
We can and should definitely try to make this much better. I think we can
get to full correctness wrt the first 3 lifetime things in rust. I'm not
sure whether handling module unload/.text lifetime is worth the bother,
it's probably only going to upset developers if we try. At least that's
been my experience.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Feb 20, 2025 at 05:27:10PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 20, 2025 at 11:00:28AM +0100, Simona Vetter wrote:
> > On Thu, Feb 20, 2025 at 10:53:57AM +0100, Simona Vetter wrote:
> > > On Wed, Feb 19, 2025 at 06:02:39PM +0200, Ville Syrjala wrote:
> >
gt; I'll be glad to take patch 1 in my tree, but I don't want to break
> anything else.
Yeah looks inverted. In case this is all there is I'm happy to land this
patch through your tree, that seems like the simplest approach.
Acked-by: Simona Vetter
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
dina
Reviewed-by: Simona Vetter
I'm assuming you or someone else at bootling has commit rights? Otherwise
I guess on Maxime to get that sorted.
-Sima
> ---
> This patch applies on top of the following commit available in drm-misc
>ab83b7f6a0c1 ("drm/atomic-helper: Intr
sn’t really a great
choice, since it sounds more like a mandatory sentence than something
done by choice. What I object to is the “dictator” part, since if your
goal is to grow a great community and maybe reach world domination,
then you as the maintainer need to serve that community. And not that
the community serves you.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Feb 20, 2025 at 10:53:57AM +0100, Simona Vetter wrote:
> On Wed, Feb 19, 2025 at 06:02:39PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Video players (eg. mpv) do periodic XResetScreenSaver() calls to
> > keep the screen on while the video p
noop"
behaviour.
With the commit message augmented:
Reviewed-by: Simona Vetter
Might also be nice to have a igt for this? Plus also wondering whether we
should cc: stable it.
Cheers, Sima
> Let's just filter out redundant DPMS property changes in the
> kernel to avoid thi
On Wed, Feb 19, 2025 at 04:56:11PM +0100, Maxime Ripard wrote:
> On Wed, Feb 19, 2025 at 02:35:25PM +0100, Simona Vetter wrote:
> > On Tue, Feb 18, 2025 at 11:23:00AM +0100, Maxime Ripard wrote:
> > > Hi,
> > >
> > > Thanks for your answer
> > >
&
MAP_USE(drm_dedbug_classes) to replace the
> > sprinkling of _USEs in drivers and helpers. IIRC, I tried adding a
> > _DEFINE into drm_drv.c, that didn't do it, so I punted for now.
> >
> > I think the dyndbg core additions are ready for review and merging
> > int
On Wed, Feb 19, 2025 at 05:28:37PM +0100, Louis Chauvet wrote:
> Le 19/02/2025 à 14:15, Simona Vetter a écrit :
> > On Wed, Feb 19, 2025 at 10:28:56AM +0100, Maxime Ripard wrote:
> > > On Tue, Dec 17, 2024 at 05:42:56PM +0100, Louis Chauvet wrote:
> > > > H
lug-create connectors with names and PATH property and MST
type, without any of the kernel-internal presentations for hubs/branch
points and all that stuff. Because userspace doesn't ever see that.
- Next up is expressing all the funny constraints that can result in,
across different drivers. For that I think we want ebpf to implement the
various atomic_check hooks, so that you can implement all the funny
constraints of mst link bw limitations, but also host-side display
limitations. And I concur with Maxime that this ebpf support should be
entirely agnostic and just allow you to attach atomic_check
implementations to connectors, planes and crtcs. And then maybe one for
the overall commit, so that global constraints are easier to implement.
So summary: MST testing in vkms only needs to look like MST to userspace.
Internally we'll just hand-roll the entire connector hotplug and leave out
everything else. Because testing driver dp mst implementations and the
helpers is better covered through different means.
Eventually we might want to implement fake i2c and dp-aux implementations
for additional features like TV remote control and fun stuff like that (I
forgot the CEA/HDMI name for these). But I think that's wyy down
the road.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ne.c| 53 +++-
> drivers/gpu/drm/i915/display/skl_universal_plane.c | 56
> --
> include/drm/drm_mode_config.h | 6 +++
> include/drm/drm_plane.h | 17 +++
> 5 files changed,
4a 100644
> > --- a/drivers/gpu/drm/xe/xe_guc_submit.c
> > +++ b/drivers/gpu/drm/xe/xe_guc_submit.c
> > @@ -1988,7 +1988,9 @@ int xe_guc_exec_queue_reset_handler(struct xe_guc
> > *guc, u32 *msg, u32 len)
> > return -EPROTO;
> > hwe = q->hwe;
> > -
> > +#ifdef CONFIG_PROC_FS
> > + atomic_inc(&q->xef->client->reset_count);
> > +#endif
> > xe_gt_info(gt, "Engine reset: engine_class=%s, logical_mask: 0x%x,
> > guc_id=%d",
> >xe_hw_engine_class_to_str(q->class), q->logical_mask,
> > guc_id);
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Feb 18, 2025 at 08:40:08PM +, Cavitt, Jonathan wrote:
> -Original Message-
> From: Tvrtko Ursulin
> Sent: Tuesday, February 18, 2025 10:39 AM
> To: Simona Vetter ; Cavitt, Jonathan
>
> Cc: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
rolled
out there where it fits, and maybe augment the documentation accordingly
so that dp helpers point at this?
Either way would be good to extend the kerneldoc a bit to explain what
this is good for. Either way.
Acked-by: Simona Vetter
Cheers, Sima
> +{
> + struct drm_atomic_state *s
On Mon, Feb 17, 2025 at 09:36:35PM +0200, Dmitry Baryshkov wrote:
> On Mon, Feb 17, 2025 at 05:41:24PM +0100, Simona Vetter wrote:
> > On Thu, Feb 13, 2025 at 03:43:50PM +0100, Maxime Ripard wrote:
> > > Now that connectors are no longer necessarily created by the bridges
> &
On Tue, Feb 18, 2025 at 11:23:00AM +0100, Maxime Ripard wrote:
> Hi,
>
> Thanks for your answer
>
> On Mon, Feb 17, 2025 at 05:41:24PM +0100, Simona Vetter wrote:
> > On Thu, Feb 13, 2025 at 03:43:50PM +0100, Maxime Ripard wrote:
> > > Now that connectors are no lon
to resend the patch, but with scripts/get_maintainer.pl
> output Cc'ed so that DRM maintainers can be notified on the patch.
I don't have the patch since it wasn't cc'ed to dri-devel. Can you please
resend with r-b tag included?
Thanks, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ions are
between dmem and drm, and not between dmem and cgroups at large. And in
any case we can just ack patches for going the other path on a
case-by-case basis.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 17, 2025 at 06:26:17PM +0100, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI he
a
> > Signed-off-by: Maxime Ripard
> >
> > ---
> >
>
> Seems a reasonable expection to me.
>
> Reviewed-by: Javier Martinez Canillas
Acked-by: Simona Vetter
I think some more acks from folks working on Kunit tests would be great,
but that aside I thi
| 10 +
> kernel/cgroup/Makefile | 1 +
> kernel/cgroup/dmem.c | 861
> +++
> mm/page_counter.c| 4 +-
> 20 files changed, 1195 insertions(+), 33 deletions
mplement SVP without any TEE,
> where the TEE implementation would be at best a no-op stub, and at
> worst flat-out impossible.
>
> So that's 'why not TEE as the single uAPI for SVP'. So, again, let's
> please turn this around: _why_ TEE? Who benefits from exposing this as
> completely separate to the more generic uAPI that we specifically
> designed to handle things like this?
Completely concurring on everything said above. TEE exposed through a
dma-buf heap (or maybe special v4l allocation flag for secure video
playback) and then we prime import that on the display side. Maybe also
through drm render drivers for the EGL/VK protected content extensions.
Same for any other hw means to allocate content protected buffers, TEE is
not special here at all.
Anything else needs seriously good justifications why the entire dma-buf
heap design is busted.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
just want to
at least make "no uaf on driver hotunplug" something achievable and hence
are much more ok with the risk that it's just stuck forever or driver
calls take an undue amount of time until they've finished timing out
everything.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 17, 2025 at 06:26:17PM +0100, Simona Vetter wrote:
> On Mon, Feb 17, 2025 at 12:08:08PM +0200, Pekka Paalanen wrote:
> > Hi Arun,
> >
> > this whole series seems to be missing all the UAPI docs for the DRM
> > ReST files, e.g. drm-kms.rst. The UAPI he
ll encounter when reading the framework code.
>
> Suggested-by: Simona Vetter
> Link: https://lore.kernel.org/dri-devel/Z4jtKHY4qN3RNZNG@phenom.ffwll.local/
> Signed-off-by: Maxime Ripard
Thanks for documenting that little bit of lore!
Reviewed-by: Simona Vetter
Cheers, Si
his
for perf or something. But we'll figure that out when it happens.
Reviewed-by: Simona Vetter
> ---
> drivers/dma-buf/dma-buf.c | 34 --
> drivers/dma-buf/udmabuf.c | 1 -
> drivers/gpu/drm/drm_prime.c|
fences do)
and the drm atomic ioctl layer transparently pins/unpins as needed.
Personally I think option C is neat, A doable, B really only for hw that
can dma in/out of histograms and where it's big enough that doing so is a
functional requirement.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
spin_lock(&hwe->pf.lock);
> + if (hwe->pf.info) {
> + kfree(hwe->pf.info);
> + hwe->pf.info = kzalloc(sizeof(struct pagefault), GFP_KERNEL);
> + }
> + spin_unlock(&hwe->pf.lock);
> +
> /*
>* A banned engine is a NOP at this
rm_crtc *crtc;
> +
> + /**
> + * @connector: The connector the bridge is connected to, NULL if
> disabled.
> + *
> + * Do not change this directly.
> + */
> + struct drm_connector *connector;
> +
> /**
>* @input_bus_cfg: input bus configuration
>*/
> struct drm_bus_cfg input_bus_cfg;
>
>
> --
> 2.48.0
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
t; > > > Best regards
> > > > > Thomas
> > > > >
> > > > > [1] https://patchwork.freedesktop.org/series/143182/
> > > > > [2] https://patchwork.freedesktop.org/series/144101/
> > > > >
> > > > >
> > > > > Am 04.02.25 um 09:46 schrieb Jacek Lawrynowicz:
> > > > > > Add possibility to import single buffer into multiple contexts,
> > > > > > fix locking when aborting contexts and add some debug features.
> > > > > >
> > > > > > Andrzej Kacprowski (2):
> > > > > > accel/ivpu: Add missing locks around mmu queues
> > > > > > accel/ivpu: Prevent runtime suspend during context abort work
> > > > > >
> > > > > > Karol Wachowski (3):
> > > > > > ccel/ivpu: Add debugfs interface for setting HWS priority bands
> > > > > > accel/ivpu: Add test modes to toggle clock relinquish disable
> > > > > > accel/ivpu: Implement D0i2 disable test modea
> > > > > >
> > > > > > Tomasz Rusinowicz (1):
> > > > > > accel/ivpu: Allow to import single buffer into multiple contexts
> > > > > >
> > > > > > drivers/accel/ivpu/ivpu_debugfs.c | 84
> > > > > > +++
> > > > > > drivers/accel/ivpu/ivpu_drv.c | 2 +-
> > > > > > drivers/accel/ivpu/ivpu_drv.h | 4 ++
> > > > > > drivers/accel/ivpu/ivpu_fw.c | 4 ++
> > > > > > drivers/accel/ivpu/ivpu_gem.c | 43
> > > > > > drivers/accel/ivpu/ivpu_gem.h | 1 +
> > > > > > drivers/accel/ivpu/ivpu_hw.c | 31
> > > > > > drivers/accel/ivpu/ivpu_hw.h | 5 ++
> > > > > > drivers/accel/ivpu/ivpu_job.c | 10 +++-
> > > > > > drivers/accel/ivpu/ivpu_jsm_msg.c | 29 ---
> > > > > > drivers/accel/ivpu/ivpu_mmu.c | 9
> > > > > > 11 files changed, 202 insertions(+), 20 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.45.1
> > > > >
> > > >
> > >
> >
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
u get funny stuff.
I don't think we have bridge chains with multiple connectors though, so
this is fairly academic and so maybe still a good idea to make this all
more flexible? Unless I've missed the memo and atomic bridges have
flexible routing, and in that case yes this shouldn't be used.
Mildly confused ...
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
attach->dmabuf->ops->unmap_dma_buf(attach, sg_table, direction);
>
> - if (dma_buf_is_dynamic(attach->dmabuf) &&
> - !IS_ENABLED(CONFIG_DMABUF_MOVE_NOTIFY))
> - dma_buf_unpin(attach);
> + if (dma_buf_pin_on_map(attach))
> +
for a moment, but checks all out.
Reviewed-by: Simona Vetter
> ---
> drivers/dma-buf/sw_sync.c | 16
> drivers/dma-buf/sync_debug.c | 21 ++---
> drivers/gpu/drm/vgem/vgem_fence.c | 15 ---
&
>
> Otherwise really hard to debug issues can occur. So fix that invalid
> documentation.
>
> Signed-off-by: Christian König
Oops :-/
Reviewed-by: Simona Vetter
> ---
> include/linux/dma-fence.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
.rs | 32 ++
> 8 files changed, 206 insertions(+), 2 deletions(-)
> ---
> base-commit: 6484e46f33eac8dd42aa36fa56b51d8daa5ae1c1
> change-id: 20250216-nova_timer-c69430184f54
>
> Best regards,
> --
> Alexandre Courbot
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 07, 2025 at 02:49:50PM +0100, Simona Vetter wrote:
> When you're that harmful with your calling out, eventually I'm going to be
> fed up, and you get a live round shot across your bow. And if that then
> causes you to ragequit, because you can't actually dea
On Fri, Feb 07, 2025 at 07:20:03PM +0900, Hector Martin wrote:
> On 2025/02/07 18:41, Hector Martin wrote:
> > On 2025/02/06 3:52, Simona Vetter wrote:
> >> On Tue, Feb 04, 2025 at 03:46:14AM +0900, Hector Martin wrote:
> >>> Adding Linus
> >>>
>
cavalry, fashionably late, maximally
destructive, because it entertains the masses on fedi or reddit or
wherever. I have no idea what you're trying to achieve here, I really
don't get it, but I am for sure fed up dealing with the fallout.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/tests/drm_atomic_state_test.c | 244
> > ++
> > 2 files changed, 245 insertions(+)
> >
>
> Reviewed-by: Dmitry Baryshkov
Pretty sure this blows up with CONFIG_DEBUG_WW_MUTEX_SLOWPATH enabled.
Seems to generally be an issue with our kms kunit
; tests with lockdep.
>
> Reorder the tests to call find_preferred_mode before the acquire context
> has been created to avoid the issue.
>
> Signed-off-by: Maxime Ripard
On the last two patches: Reviewed-by: Simona Vetter
> ---
> drivers/gpu/drm/tests/d
On Wed, Jan 29, 2025 at 03:21:54PM +0100, Maxime Ripard wrote:
> Some tests have the drm pointer assigned multiple times to the same
> value. Drop the redundant assignments.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Simona Vetter
> ---
> drivers/gpu/drm/tests/drm_hdmi_s
-EDEADLK) {
> + drm_atomic_state_clear(state);
> + ret = drm_modeset_backoff(ctx);
> + if (!ret)
> + goto retry;
> + }
Reviewed-by: Simona Vetter
> KUNIT_EXPECT_EQ(test, ret, 0);
>
> crtc_state = drm_atom
ntities variables assignment
> drm/tests: hdmi: Fix recursive locking
>
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 200
> +++--
> 1 file changed, 103 insertions(+), 97 deletions(-)
> ---
> base-commit: e2a81c0cd7de6cb063058be304b18f200c64802b
> change-id: 20250129-test-kunit-5ba3c03bffb0
>
> Best regards,
> --
> Maxime Ripard
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Jan 20, 2025 at 05:54:10PM +0800, Huang, Honglei1 wrote:
> On 2024/12/27 10:02, Huang, Honglei1 wrote:
> > On 2024/12/22 9:59, Demi Marie Obenour wrote:
> > > On 12/20/24 10:35 AM, Simona Vetter wrote:
> > > > On Fri, Dec 20, 2024 at 06:04:09PM +0800, Hongl
deletions(-)
> ---
> base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
> change-id: 20241018-drm-small-improvements-1d104cc10280
>
> Best regards,
> --
> Luca Ceresoli
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Feb 03, 2025 at 04:30:04PM +, Lorenzo Stoakes wrote:
> On Mon, Feb 03, 2025 at 04:49:34PM +0100, Simona Vetter wrote:
> > On Fri, Jan 31, 2025 at 06:28:57PM +, Lorenzo Stoakes wrote:
> > > in the fb_defio video driver, page dirty state is used to determine when
wrprotect_page_one,
> + .invalid_vma = invalid_mkclean_vma,
> + };
> +
> + if (!mapping)
> + return 0;
> +
> + __rmap_walk_file(/* folio = */NULL, mapping, pgoff, nr_pages, &rwc,
> + /* locked = */false);
> +
> + return state.cleaned;
> +}
> +EXPORT_SYMBOL_GPL(mapping_wrprotect_page);
> +
> /**
> * pfn_mkclean_range - Cleans the PTEs (including PMDs) mapped with range of
> * [@pfn, @pfn + @nr_pages) at the specific offset
> (@pgoff)
> --
> 2.48.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Jan 31, 2025 at 11:14:06AM +1100, Alistair Popple wrote:
> On Thu, Jan 30, 2025 at 04:29:33PM +0100, David Hildenbrand wrote:
> > On 30.01.25 14:31, Simona Vetter wrote:
> > > On Thu, Jan 30, 2025 at 10:37:06AM +0100, David Hildenbrand wrote:
> > > > On 3
_cold_or_pageout_pte_range() will
> simply skip "!pte_present()", because it wouldn't know what to do in that
> case.
>
> Of course, there could be page table walkers that check all cases and bail
> out if they find something unexpected: do_swap_page() cannot make forward
> progress and will inject a VM_FAULT_SIGBUS if it doesn't recognize the
> entry. But these are rather rare.
Yeah this all makes sense to me now. Thanks a lot for your explanation,
I'll try to pay it back by trying to review the next version of the series
a bit.
> We could enlighten selected page table walkers to handle device-exclusive
> where it really makes sense later.
I think rmap for eviction/migration is really the big one that obviously
should be fixed. All the other cases I could think of I think just end up
in handle_mm_fault() to sort out the situation and then retry.
Cheers, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 30, 2025 at 01:42:17PM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 05:09:44PM +0100, Simona Vetter wrote:
> > > > An optional callback is a lot less scary to me here (or redoing
> > > > hmm_range_fault or whacking the migration helpers a few
On Fri, Jan 31, 2025 at 11:55:55AM +0100, David Hildenbrand wrote:
> On 31.01.25 00:06, Alistair Popple wrote:
> > On Thu, Jan 30, 2025 at 02:03:42PM +0100, Simona Vetter wrote:
> > > On Thu, Jan 30, 2025 at 10:58:51AM +0100, David Hildenbrand wrote:
> > > > On 30.01
for performance or whatever, we need two
> > things:
> >
> > a) userspace must mmap that memory as hugepage memory, to clearly signal
> > the promise that atomics are split up on hugepage sizes and not just page
> > size
> >
> > b) we need to extend make_device_exclusive and drivers to handle the
> > hugetlb folio case
> >
> > I think thp is simply not going to work here, it's impossible (without
> > potentially causing fault storms) to figure out what userspace might want.
>
> Right, I added a link to this discussion in the patch.
Thanks, Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 30, 2025 at 10:08:32AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 02:06:12PM +0100, Simona Vetter wrote:
> > On Thu, Jan 30, 2025 at 12:08:42PM +0100, David Hildenbrand wrote:
> > > On 30.01.25 11:10, Simona Vetter wrote:
> > > > On Wed, Ja
t; .../devicetree/bindings/dma/linux,cma.yml | 43 ++
> .../bindings/gpu/arm,mali-valhall-csf.yaml| 6 +
> drivers/dma-buf/heaps/cma_heap.c | 120 +++--
> drivers/gpu/drm/panthor/Kconfig | 1 +
> drivers/gpu/drm/panthor/panthor_device.c | 22 +++-
> drivers/gpu/drm/panthor/panthor_device.h | 10 ++
> drivers/gpu/drm/panthor/panthor_fw.c | 46 ++-
> drivers/gpu/drm/panthor/panthor_fw.h | 2 +
> drivers/gpu/drm/panthor/panthor_gem.c | 49 ++-
> drivers/gpu/drm/panthor/panthor_gem.h | 16 ++-
> drivers/gpu/drm/panthor/panthor_heap.c| 2 +
> drivers/gpu/drm/panthor/panthor_sched.c | 124 --
> 12 files changed, 382 insertions(+), 59 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/dma/linux,cma.yml
>
> --
> 2.34.1
>
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jan 30, 2025 at 09:23:17AM -0400, Jason Gunthorpe wrote:
> On Thu, Jan 30, 2025 at 11:50:27AM +0100, Simona Vetter wrote:
> > On Wed, Jan 29, 2025 at 09:47:57AM -0400, Jason Gunthorpe wrote:
> > > On Wed, Jan 29, 2025 at 02:38:58PM +0100, Simona Vetter wrote:
> >
olios early, directly after GUP.
>
> Signed-off-by: David Hildenbrand
Yeah this makes sense. Even for pmd entries I think we want to make this
very explicit with an explicit hugetlb opt-in I think.
Acked-by: Simona Vetter
> ---
> Documentation/mm/hmm.rst
n practice it's always a write access that dirties anyway.
Acked-by: Simona Vetter
> ---
> include/linux/swap.h| 7 +++
> include/linux/swapops.h | 27 ---
> mm/mprotect.c | 8
> mm/page_table_check.c | 5 ++---
> m
1 - 100 of 273 matches
Mail list logo
