; > Just to clarify: when I say "a logical place", I very much want to
> > emphasize the "a" - maybe there are better places, and I'm not saying
> > that is the only possible place. But it sounds more logical to me than
> > some.
> >
> > Linus
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 22, 2024 at 03:18:02PM +0200, Maxime Ripard wrote:
> On Tue, May 21, 2024 at 02:06:19PM GMT, Daniel Vetter wrote:
> > On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> > > On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> > > > On W
On Wed, May 22, 2024 at 03:34:52PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Mon, May 06, 2024 at 03:38:24PM GMT, Daniel Vetter wrote:
> > On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, May 06, 2024 at 01:49
turn ERR_CAST(attach);
> + }
> +
> + obj->import_attach = attach;
> + get_dma_buf(buf);
> +
> + ret = virtgpu_dma_buf_init_obj(dev, bo, attach);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + return obj;
> }
>
> struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> @@ -281,3 +332,4 @@ struct drm_gem_object *virtgpu_gem_prime_import_sg_table(
> {
> return ERR_PTR(-ENODEV);
> }
> +
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 15, 2024 at 07:22:21PM +0300, Oded Gabbay wrote:
> Because I left habana, Ofir Bitton is now the habanalabs driver
> maintainer.
>
> The git repo also changed location to the Habana GitHub website.
>
> Signed-off-by: Oded Gabbay
Acked-by: Daniel Vetter
On Tue, 21 May 2024 at 14:38, Daniel Vetter wrote:
>
> On Mon, May 20, 2024 at 12:05:14PM +0200, Jacek Lawrynowicz wrote:
> > From: "Wachowski, Karol"
> >
> > Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
> > allows users to call m
> > > > The next best solution is to keep the final DRM device open until a new
> > > > one
> > > > shows up. All DRM graphics drivers with hotplugging support are
> > > > required to
> > > > accept commands after their hardware has been unplugged. They simply
> > > > won't
> > > > display anything.
> > > >
> > > > Best regards
> > > > Thomas
> > > >
> > > >
> > > > > Thanks
> > > > >
> > > > --
> > > > --
> > > > Thomas Zimmermann
> > > > Graphics Driver Developer
> > > > SUSE Software Solutions Germany GmbH
> > > > Frankenstrasse 146, 90461 Nuernberg, Germany
> > > > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> > > > HRB 36809 (AG Nuernberg)
> > > >
> >
> > --
> > --
> > Thomas Zimmermann
> > Graphics Driver Developer
> > SUSE Software Solutions Germany GmbH
> > Frankenstrasse 146, 90461 Nuernberg, Germany
> > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> > HRB 36809 (AG Nuernberg)
> >
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
mple:
> void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
> ptr[0] = 0;
>
> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
> Cc: Noralf Trønnes
> Cc: Eric Anholt
> Cc: Rob Herring
> Cc: Maarten Lankhorst
> Cc
ems logic to me to use a "real"
> > platform driver and a platform device for each pipeline, but I don't have
> > the experience to tell if this is a good idea or not.
>
> I'm afraid I don't know which approach could work better. Trusting Sima and
> Maíra on this one.
As I've said, I'm not opposed to a switch. I just think it's an orthogonal
issue to the configfs and should be separately justified.
We're trying hard to get away from kms userspace sneaking too much under
the hood of the driver, and have gone a long way from the o.g. drm days
where "everything is pci" was encoded into uapi. So from that pov I kinda
like the fact that vkms is special and fairly free-floating.
But maybe userspace does want to be able to test their device enumeration
more like a real device, so if vkms currently sticks out there that would
be a really good reason to change things and make it look more like a real
driver/device.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
n the agenda?
Yeah sounds good, and I'll try to at least attend lpc this year since it's
rather close ... Might be good to explicitly ping teams of merged and
in-flight drivers we have in accel already.
I think the topic list is at least a good starting point.
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
des in said
> hook, which will likely come as a suprise when the driver has
> declared no support for such modes (via setting
> connector->ycbcr_420_allowed to false).
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10992
> Signed-off-by: Ville Syrjälä
Sounds
On Thu, May 16, 2024 at 09:51:35AM -0700, John Stultz wrote:
> On Thu, May 16, 2024 at 3:56 AM Daniel Vetter wrote:
> > On Wed, May 15, 2024 at 11:42:58AM -0700, John Stultz wrote:
> > > But it makes me a little nervous to add a new generic allocation flag
> > >
On Mon, May 20, 2024 at 02:01:48PM +0200, Luca Ceresoli wrote:
> Hello Daniel,
>
> On Thu, 16 May 2024 15:22:01 +0200
> Daniel Vetter wrote:
>
> > Apologies for missing v1 ...
> >
> > On Fri, May 10, 2024 at 09:10:36AM +0200, Luca Ceresoli wrote
On Thu, May 16, 2024 at 11:12:19PM +0100, Adrián Larumbe wrote:
> Hi Daniel,
>
> On 02.05.2024 10:09, Daniel Vetter wrote:
> > On Wed, May 01, 2024 at 07:50:43PM +0100, Adrián Larumbe wrote:
> > > Up to this day, all fdinfo-based GPU profilers must traverse the enti
P_NOWAIT | __GFP_NOWARN);
>
> Should this be __GFP_NOWARN? There is no fallback on failure, and if
> this fails and the __vmalloc() above didn't, there is no error message
> at all.
GFP_NOWAIT already has __GFP_NOWARN, so redundant. And there's really
nothing you can do as a fallback (aside from dmesg output, which this code
already does - ok mabye dev_coredump could also do warnings, but that's a
separate patch).
With the __GFP_NOWARN dropped:
Reviewed-by: Daniel Vetter
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
O_CONNECTOR flag for
drm_bridge_attach.
There's probably a pile more fundamental issues I've missed, but this
should get a good discussion started.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
oint of this series, so could you
> >> share some use-cases you're trying to address?
> >>
> >
> > The end use-case we have demonstrated right now with this series is a
> > proof-of-concept display cluster use-case where RTOS boots early on MCU core
> > (launched at bootloader stage) and initializes the display (using the global
> > common0 register space and irq) and starts displaying safety tell-tales on
> > one
> > plane, and once Linux boots up on application processor,
> > Linux (using common1 register space and irq) controls the other plane with
> > GPU
> > rendering using a QT based application. And yes, we also support the
> > scenario
> > where Linux crashes but RTOS being the DSS master and in control of DSS
> > power,
> > clock domain and global register space is not impacted by the crash.
>
> You mention 2 scenarios but are actually the same? Or did I misunderstand?
>
> In both cases the RTOS own the display pipeline and Linux can just display
> using a single plane.
>
> That's why I think that agree with Maxime, that a fwkms could be a simpler
> solution to your use case instead of adding all this complexity to the DSS
> driver. Yes, I understand the HW supports all this flexibility but there's
> no real use case yet (you mentioned that don't even have firmware for this
> single plane owned by the RTOS in the R5F case).
>
> The DT binding for a fwkms driver would be trivial, in fact maybe we might
> even leverage simpledrm for this case and not require a new driver at all.
I guess you can still do things like pageflipping and maybe use some of
the color/blending hardware? Maybe even have more than one plane
available? fwkms/simpledrm conceptually cannot really support pageflipping
even, so that's a much, much reduced feature set.
That all aside I do think we should limit the support to just the first
case, where linux gets a few pieces assigned to it and is not the DSS
master. From what I'm understanding you could assign entire crtc with
planes and everything to linux, so this shouldn't really constraint
real-world usage?
At least until there's support in firmware for this it's all way too
theoretical, and I agree with Maxime and Javier that there's some serious
design questions about how this kind of static leasing should work with
drm sitting on top.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
I think one option might be to just start using these internally, but not
sure the dma-api would understand a fallback cadence of allocators (afaik
you can specify specific cma regions already, but that doesn't really
covere the case where you can fall back to pages and iommu to remap to
contig dma space) ... And I don't think abandonding the dma-api for
allocating cma buffers is going to be a popular proposal.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 08, 2024 at 08:38:00PM +0100, Chris Clayton wrote:
>
>
> On 08/05/2024 16:54, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
> >> Hi,
> >>
> >> I'm running the la
On Thu, May 09, 2024 at 10:23:16AM +0100, Daniel Stone wrote:
> Hi,
>
> On Wed, 8 May 2024 at 16:49, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> > > Right now, if your platform requires CMA for display, then the app
>
On Mon, May 13, 2024 at 01:51:23PM +, Simon Ser wrote:
> On Wednesday, May 8th, 2024 at 17:49, Daniel Vetter wrote:
>
> > On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> >
> > > On Wed, 8 May 2024 at 09:33, Daniel Vetter dan...@ffwll.ch wrote:
&g
- GL
> * - Vulkan extensions
> + * - libcamera
I think we can bikeshed whether we want to be more specific (with like
listing the gl/vk extensions), but imo it's a good start and imo also
totally makes sense to officially list libcamera. On both patches.
Acked-by: Daniel Vetter
I think col
On Wed, May 08, 2024 at 09:02:02AM +0100, Chris Clayton wrote:
> Hi,
>
> I'm running the latest development kernel - 6.9.0-rc7+ (HEAD is
> dccb07f2914cdab2ac3a5b6c98406f765acab803.)
>
> As I say in $SUBJECT, the directory /sys/kernel/debug/vgaswitcheroo is
> missing in this release. Perhaps
On Wed, May 08, 2024 at 09:38:33AM +0100, Daniel Stone wrote:
> On Wed, 8 May 2024 at 09:33, Daniel Vetter wrote:
> > On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> > > That would have the unfortunate side effect of making sandboxed apps
> > > less
t fork()s and creates P2. Now both P1 and P2 call
> epoll_wait(). Since signalfds are always relative to the caller and P1
> did call signalfd_poll() to register the callback only P1 can get
> events. So P2 can't take over signalfds in that epoll loop.
>
> Honestly, the inheritance semantics of epoll across fork() seem pretty
> wonky and it would've been better if an epoll fd inherited across
> would've returned ESTALE or EINVAL or something. And if that inheritance
> of epoll instances would really be a big use-case there'd be some
> explicit way to enable this.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 08, 2024 at 12:35:52PM +0100, Pavel Begunkov wrote:
> On 5/8/24 08:16, Daniel Vetter wrote:
> > On Tue, May 07, 2024 at 08:32:47PM -0300, Jason Gunthorpe wrote:
> > > On Tue, May 07, 2024 at 08:35:37PM +0100, Pavel Begunkov wrote:
> > > > On 5/7/2
mm, start, end, order,
> flags, !fallback);
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
> I'll review the talk. However the fact that the effort has stalled
> most likely means that 'one fits them all' approach didn't really fly
> well. We have too many usecases.
I think there's two reasons:
- It's a really hard problem with many aspects. Where you need to allocate
the
real official thing.
udmabuf does kinda allow you to pin memory, but we can easily fix that by
adding the right accounting and then either let mlock rlimits or cgroups
kernel memory limits enforce good behavior.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, May 08, 2024 at 06:46:53AM +0100, Daniel Stone wrote:
> Hi,
>
> On Tue, 7 May 2024 at 12:15, Daniel Vetter wrote:
> > On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> > > On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > > I agree t
On Wed, May 08, 2024 at 07:55:08AM +0200, Christian König wrote:
> Am 07.05.24 um 21:07 schrieb Linus Torvalds:
> > On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
> > > On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
> > >
> > > > I'
terfaces
are intentionally "everything is optional".
Similarly you can (and should) reject and dma_buf_attach to devices where
p2p connectevity isn't there, or well really for any other reason that
makes stuff complicated and is out of scope for your use-case. It's better
to r
l because
depending upon allocator, that's indeed beneficial. Other drm drivers have
more buffer-based concepts for opportunistically memory around, usually
by marking buffers that are just kept as cache as purgeable (which is a
concept that goes all the way to opengl/vulkan).
But these are all internals of the dma-buf exporter, the dma-buf api users
don't ever need to care.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
> >
> > It's really annoying that on some distros/builds we don't have that, and
> > for gpu driver stack reasons we _really_ need to know whether a fd is th
fers - say always taking the output buffer from the GPU, then we've added
> another dependency which is more difficult to guarantee across different
> arches.
>
> ---
> bod
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
l the generic interfaces/ops, because we also use
dma-buf as userspace handles for some really special memory.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
e.
So I don't think there's any reasons to recommend against using epoll on
dma-buf fd (or sync_file or drm_syncobj or any of the sharing primitives
we have really).
Cheers, Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, May 06, 2024 at 04:01:42PM +0200, Hans de Goede wrote:
> Hi Sima,
>
> On 5/6/24 3:38 PM, Daniel Vetter wrote:
> > On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
> >> Hi,
> >>
> >> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de
On Mon, May 06, 2024 at 04:53:47PM +0200, Arnd Bergmann wrote:
> On Mon, May 6, 2024, at 15:14, Daniel Vetter wrote:
> > On Fri, May 03, 2024 at 01:22:10PM -0700, Florian Fainelli wrote:
> >> On 5/3/24 12:45, Arnd Bergmann wrote:
> >> > On Fri, May 3, 2024, at
> I dunno. I think that would be the right thing to do, but I wouldn't
> > be surprised if some disgusting eventpoll user then might depend on
> > the current situation where the eventpoll thing stays around even
> > after the close() if you have another copy of the f
On Mon, May 06, 2024 at 04:46:54PM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 02:47:23PM +0200, Daniel Vetter wrote:
> > On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote:
> > > On Sun, 5 May 2024 at 13:30, Al Viro wrote:
> > > >
> >
d buffer.
That aside, why can you not use the same file with multiple epoll files in
different processes? Afaik from a quick look, all the tracking structures
are per epoll file, so both client and compositor using it should work?
I haven't tried, so I just might be extremely blind ...
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ient for that.
-Sima
> > But devices tagged for uaccess are only opened up to users who are
> > physcially present behind the machine and those can just hit
> > the powerbutton, so I don't believe that any *on purpose* DOS is part of
> > the thread model.
>
> How would that work for headless devices?
>
> Maxime
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
migrate to using FB_CORE=m FB=n FB_NOTIFY=n
> > instead and use simpledrm for the console in place of the legacy
> > fbdev layer.
>
> That is beyond my reach :)
This one is. And it doesn't need to be simpledrm, just a drm kms driver
with fbdev emulation. Heck even if you have an fbdev driver you should
control the corresponding backlight explicitly, and not rely on the fb
notifier to magical enable/disable some random backlights somewhere.
So please do not encourage using this in any modern code.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
gain ever?" ways no matter what. But with common code
there will at least be all of dri-devel and hopefully some mm folks
involved in sorting things out.
Most other areas it's indeed better to explore the design space with a few
drivers before going with common code, at the cost of having some really
terrible driver code in upstream. But here the cost of some really bad
design in drivers is just too expensive imo.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sse3 sha1_ssse3 drm_ttm_helper ttm nvme_auth vmxnet3 serio_raw
> ata_generic pata_acpi fuse i2c_dev
> May 03 22:25:05 fedora.local kernel: CPU: 2 PID: 2204 Comm:
> kms_pipe_crc_ba Not tainted 6.9.0-rc2-vmwgfx #5
> May 03 22:25:05 fedora.local kernel: Hardware name: VMware, Inc.
> VMw
On Fri, May 03, 2024 at 06:06:03PM +0100, Tvrtko Ursulin wrote:
>
> On 03/05/2024 16:58, Alex Deucher wrote:
> > On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
> > >
> > > On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
> > > >
&g
it just means we have 3 of those then
when only really 2 are needed.
Also maybe here two: dma_fence are bounded like other disk i/o (including
the option of timeouts if things go very wrong), so it's very much not
forever but at most a few seconds worst case (shit hw/driver excluded, as
usual).
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
;
> You are right that it's similar to the epoll thing in that sense, it
> just looks a _lot_ more straightforward to me (and, unlike epoll,
> doesn't look actively buggy right now).
>
> Could we abstract out this kind of "stashed file pointer" so that we'd
> have a *
r bugs when things go really
wrong ofc), but more like a few seconds in a worst case scenario.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
driver, do $bar" is just
guaranteed to fragement the ecosystem, so imo that should be the absolute
last resort.
-Sima
> > > +
> > > - drm-shared-: [KiB|MiB]
> > > The total size of buffers that are shared with another file (e.g.,
> > > have more
> > > @@ -145,6 +150,9 @@ than a single handle).
> > > The total size of buffers that including shared and private memory.
> > > +This is an alias for drm-memory- and only one of the two
> > > should be
> > > +present.
> > > +
> > > - drm-resident-: [KiB|MiB]
> > > The total size of buffers that are resident in the specified region.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
clients {
> + __u64 user_data;
> + __kernel_size_t len;
> +};
> +
> #if defined(__cplusplus)
> }
> #endif
> @@ -1236,6 +1241,8 @@ extern "C" {
> #define DRM_IOCTL_SYNCOBJ_TRANSFER DRM_IOWR(0xCC, struct
> drm_syncobj_transfer)
> #define DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNALDRM_IOWR(0xCD, struct
> drm_syncobj_timeline_array)
>
> +#define DRM_IOCTL_GET_CLIENTSDRM_IOWR(0xD1, struct
> drm_get_clients)
> +
> /**
> * DRM_IOCTL_MODE_GETFB2 - Get framebuffer metadata.
> *
> --
> 2.44.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 30, 2024 at 09:09:15PM -0300, Jason Gunthorpe wrote:
> On Tue, Apr 30, 2024 at 08:57:48PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 30, 2024 at 02:30:02PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Apr 29, 2024 at 10:25:48AM +0200, Thomas Hellström wrote:
&g
primary->kdev;
> kdev->groups = connector_dev_groups;
> @@ -550,7 +605,7 @@ struct device *drm_sysfs_minor_alloc(struct drm_minor
> *minor)
> minor_str = "card%d";
>
> kdev->devt = MKDEV(DRM_MAJOR, minor->index);
>
had some long chats with Thomas and I think there's enough
option to spawn pretty much any possible upstream consensus. So I'm not
worried.
But first this needs to be page-centric in the fundamental mirroring
approach.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Apr 30, 2024 at 04:38:55PM +0300, Jani Nikula wrote:
> On Tue, 30 Apr 2024, Daniel Vetter wrote:
> > Might also be a good idea to wait a bit in case there's any regression
> > reports for really old userspace. But I guess there's not a high chance
> > for that to hap
ug might reallocate your mmio range to another thunderbolt
device that has been plugged in meanwhile).
It's definitely big time fun all around :-/
Oh also, please help improve the docs on this stuff, I'm trying to make
sure it's all there and ideally the various pieces link to the other
parts, but it's tricky and I understand this stuff to much to spot the
gaps ...
Cheers, Sima
>
> >
> > Cc: Aravind and Michal since this likely relates to the FLR discussion...
> >
> > but it looks to me that we should move more towards the devm_ and limit
> > the usage of drmm_ to some very specific cases...
>
> agreed,
>
> Lucas De Marchi
>
> >
> > >
> > > >
> > > > Lucas De Marchi
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
before putting in the effort. ;)
Might also be a good idea to wait a bit in case there's any regression
reports for really old userspace. But I guess there's not a high chance
for that to happen here, so imo fine to just go ahead right away.
-Sima
>
> > Reviewed-by: Hamza Mahfooz
>
> Thanks,
> Jani.
>
>
> --
> Jani Nikula, Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Apr 19, 2024 at 03:20:19PM +0200, Jocelyn Falempe wrote:
> drm_panic has been introduced recently, and uses the same fonts as
> FRAMEBUFFER_CONSOLE.
>
> Signed-off-by: Jocelyn Falempe
Acked-by: Daniel Vetter
lib/fonts/ doesn't seem to have a designated maintainer, so
drivers/gpu/drm/vkms/vkms_output.c| 404 --
> drivers/gpu/drm/vkms/vkms_plane.c | 44 +-
> drivers/gpu/drm/vkms/vkms_writeback.c | 42 +-
> 11 files changed, 1514 insertions(+), 241 deletions(-)
> create mode 100644 drivers/gpu/drm/vkms/vkms_configfs.c
>
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
config_crtc->crtc_config_idx)) {
> + encoder_entry->encoder->possible_crtcs |=
> + drm_crtc_mask(_crtc->base);
> + }
> + }
> +
> + if (vkmsdev->config.writeback) {
> + int ret = vkms_enable_writeback_connector(vkmsdev,
> + vkms_crtc);
> + if (ret)
> + DRM_WARN(
> + "Failed to init writeback connector for
> config crtc: %s. Error code %d",
> + item->ci_name, ret);
> + }
> + }
> +
> + drm_mode_config_reset(dev);
> +
> + return 0;
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 950e6c930273..3198bf0dca73 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include
> +#include
>
> #include
> #include
> @@ -215,20 +216,25 @@ static const struct drm_plane_helper_funcs
> vkms_plane_helper_funcs = {
> };
>
> struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> -enum drm_plane_type type)
> +enum drm_plane_type type, char *name, ...)
> {
> struct drm_device *dev = >drm;
> struct vkms_output *output = >output;
> struct vkms_plane *plane;
> + va_list va;
> int ret;
>
> if (output->num_planes >= VKMS_MAX_PLANES)
> return ERR_PTR(-ENOMEM);
>
> plane = >planes[output->num_planes++];
> +
> + va_start(va, name);
> ret = drm_universal_plane_init(dev, >base, 0, _plane_funcs,
> vkms_formats, ARRAY_SIZE(vkms_formats),
> -NULL, type, NULL);
> +NULL, type, name, va);
> + va_end(va);
> +
> if (ret)
> return ERR_PTR(ret);
>
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tus_connected;
> + const struct vkms_config_connector *config_connector =
> + find_config_for_connector(connector);
> +
> + if (!config_connector)
> + return connector_status_connected;
> +
> + if (!config_connector->connected)
> + status = connector_status_disconnected;
> +
> + return status;
> +}
> +
> static const struct drm_encoder_funcs vkms_encoder_funcs = {
> .destroy = drm_encoder_cleanup,
> };
> @@ -280,12 +325,12 @@ int vkms_output_init(struct vkms_device *vkmsdev)
> struct vkms_config_connector *config_connector =
> item_to_config_connector(item);
> struct drm_connector *connector = vkms_connector_init(vkmsdev);
> -
> if (IS_ERR(connector)) {
> DRM_ERROR("Failed to init connector from config: %s",
> item->ci_name);
> return PTR_ERR(connector);
> }
> + config_connector->connector = connector;
>
> for (int j = 0; j < output->num_encoders; j++) {
> struct encoder_map *encoder = _map[j];
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
er to get things going, we'll bake that mess in forever.
Instead I think it'd be best if we just disable writeback support for the
initial configfs work.
For properly enabling writeback I think we need a new configfs group for
just writeback connectors, since those are fairly special (like you cannot
ever hotplug them, they're always there).
> + int ret = vkms_enable_writeback_connector(vkmsdev,
> + vkms_crtc);
> + if (ret)
> + DRM_WARN(
> + "Failed to init writeback connector for
> config crtc: %s. Error code %d",
> + item->ci_name, ret);
> + }
> + }
> +
> + drm_mode_config_reset(dev);
> +
> + return 0;
> }
> diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
> b/drivers/gpu/drm/vkms/vkms_plane.c
> index 950e6c930273..3198bf0dca73 100644
> --- a/drivers/gpu/drm/vkms/vkms_plane.c
> +++ b/drivers/gpu/drm/vkms/vkms_plane.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include
> +#include
>
> #include
> #include
> @@ -215,20 +216,25 @@ static const struct drm_plane_helper_funcs
> vkms_plane_helper_funcs = {
> };
>
> struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> -enum drm_plane_type type)
> +enum drm_plane_type type, char *name, ...)
> {
> struct drm_device *dev = >drm;
> struct vkms_output *output = >output;
> struct vkms_plane *plane;
> + va_list va;
> int ret;
>
> if (output->num_planes >= VKMS_MAX_PLANES)
> return ERR_PTR(-ENOMEM);
>
> plane = >planes[output->num_planes++];
> +
> + va_start(va, name);
> ret = drm_universal_plane_init(dev, >base, 0, _plane_funcs,
> vkms_formats, ARRAY_SIZE(vkms_formats),
> -NULL, type, NULL);
> +NULL, type, name, va);
> + va_end(va);
> +
> if (ret)
> return ERR_PTR(ret);
>
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
places (since really everything we do needs that lock), I'd focus on
adding it to important helper functions like the xarray wrappers for
allocating ids (if we do those).
- Then for walking the various lists (both here and in the next patch) we
should also add proper wrapper macros to configfs.h, which both do the
right upcasting and also have the lockdep assert.
> +
> + /* The platform device if this is registered, otherwise NULL */
> + struct vkms_device *vkms_device;
> +};
> +
> struct vkms_device_setup {
> - bool is_default;
> + // Is NULL in the case of the default card.
> + struct vkms_configfs *configfs;
> };
>
> struct vkms_device {
> struct drm_device drm;
> struct platform_device *platform;
> - bool is_default;
> + // Is NULL in the case of the default card.
> + struct vkms_configfs *configfs;
> struct vkms_output output;
> struct vkms_config config;
> };
> @@ -164,11 +217,42 @@ struct vkms_device {
> #define to_vkms_plane_state(target)\
> container_of(target, struct vkms_plane_state, base.base)
>
> +#define item_to_configfs(item) \
> + container_of(to_config_group(item), struct vkms_configfs, device_group)
> +
> +#define item_to_config_connector(item)\
> + container_of(to_config_group(item), struct vkms_config_connector, \
> + config_group)
> +
> +#define item_to_config_crtc(item)\
> + container_of(to_config_group(item), struct vkms_config_crtc, \
> + config_group)
> +
> +#define item_to_config_encoder(item)\
> + container_of(to_config_group(item), struct vkms_config_encoder, \
> + config_group)
> +
> +#define item_to_config_plane(item)\
> + container_of(to_config_group(item), struct vkms_config_plane, \
> + config_group)
> +
> +#define item_to_config_links(item) \
> + container_of(to_config_group(item), struct vkms_config_links, group)
> +
> +#define plane_item_to_configfs(item)
> \
> + container_of(to_config_group(item->ci_parent), struct vkms_configfs, \
> + planes_group)
> +
> +/* Devices */
> +struct vkms_device *vkms_add_device(struct vkms_configfs *configfs);
> +void vkms_remove_device(struct vkms_device *vkms_device);
> +
> /* CRTC */
> struct vkms_crtc *vkms_crtc_init(struct vkms_device *vkmsdev,
>struct drm_plane *primary,
>struct drm_plane *cursor);
>
> +int vkms_output_init(struct vkms_device *vkmsdev);
> int vkms_output_init_default(struct vkms_device *vkmsdev);
>
> struct vkms_plane *vkms_plane_init(struct vkms_device *vkmsdev,
> @@ -191,4 +275,8 @@ void vkms_writeback_row(struct vkms_writeback_job *wb,
> const struct line_buffer
> int vkms_enable_writeback_connector(struct vkms_device *vkmsdev,
> struct vkms_crtc *vkms_crtc);
>
> +/* ConfigFS Support */
> +int vkms_init_configfs(void);
> +void vkms_unregister_configfs(void);
> +
> #endif /* _VKMS_DRV_H_ */
> diff --git a/drivers/gpu/drm/vkms/vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index bfc2e2362c6d..dc69959c5e1d 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -176,3 +176,8 @@ int vkms_output_init_default(struct vkms_device *vkmsdev)
>
> return ret;
> }
> +
> +int vkms_output_init(struct vkms_device *vkmsdev)
> +{
> + return -EOPNOTSUPP;
> +}
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
vkms_output.c
> b/drivers/gpu/drm/vkms/vkms_output.c
> index 86faf94f7408..bfc2e2362c6d 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -80,7 +80,7 @@ static struct drm_encoder *vkms_encoder_init(struct
> vkms_device *vkms_device)
> return encoder;
> }
>
> -int vkms_output_init(struct vkms_device *vkmsdev, int index)
> +int vkms_output_init_default(struct vkms_device *vkmsdev)
> {
> struct vkms_output *output = >output;
> struct drm_device *dev = >drm;
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
you have static arrays, but vkms really shouldn't need it's own
arrays to keep track of what drm already keeps track of.
Using DRM limits also means we can rely on the drm validation code instead
of having to duplicate that code in the vkms configfs validation
functions.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ers/gpu/drm/vkms/vkms_output.c
> index 5ce70dd946aa..963a64cf068b 100644
> --- a/drivers/gpu/drm/vkms/vkms_output.c
> +++ b/drivers/gpu/drm/vkms/vkms_output.c
> @@ -62,7 +62,7 @@ int vkms_output_init(struct vkms_device *vkmsdev, int index)
> if (IS_ERR(primary))
>
spinlock_irqsave/restore (John Ogness)
>
> v11:
> * Use macro instead of inline functions for drm_panic_lock/unlock (John
> Ogness)
>
> v12:
> * Use array for map and pitch in struct drm_scanout_buffer
>to support multi-planar format later. (Thomas Zimmermann)
> *
t later. (Thomas Zimmermann)
> * Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann)
>
> Signed-off-by: Jocelyn Falempe
Some detail suggestions for the kerneldoc but those aside Acked-by: Daniel
Vetter
> ---
> Documentation/gpu/drm-kms.rst
es that the debugfs file disappears
before drm_dev_unregister finishes (otherwise we have a bit a problem),
and looks like we're good.
Maybe add a todo that it would be nice to simulate nmi context, not sure
lockdept can help here ...
Anyway Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/
On Tue, Apr 09, 2024 at 06:30:40PM +0200, Jocelyn Falempe wrote:
> From: Daniel Vetter
>
> Rough sketch for the locking of drm panic printing code. The upshot of
> this approach is that we can pretty much entirely rely on the atomic
> commit flow, with the pair of raw_spin_lock/u
e too
Yeah that's a good idea and defacto how we handled this - additional users
of anything (whether library or uapi or whatever) get to clean up an
existing mess if it's too bad. But for uapi it's good to be really
explicit and document that.
Acked-by: Daniel Vetter
Cheers, Sima
--
On Fri, Mar 08, 2024 at 02:45:52PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 07.03.24 um 10:14 schrieb Jocelyn Falempe:
> > From: Daniel Vetter
> >
> > Rough sketch for the locking of drm panic printing code. The upshot of
> > this approach is that
tionally. Also I think locking that's only
conditional on Kconfig is just a bit too suprising to be a good idea
irrespective of this specific case.
-Sima
>
> Best regards,
>
> --
>
> Jocelyn
>
> On 01/03/2024 11:39, Daniel Vetter wrote:
> > Rough s
On Tue, Mar 05, 2024 at 09:20:04AM +0106, John Ogness wrote:
> Hi Daniel,
>
> Great to see this moving forward!
>
> On 2024-03-01, Daniel Vetter wrote:
> > But for the initial cut of a drm panic printing support I don't think
> > we need that, because the critical s
ld emails to point to the
> main one.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
Directly applied to drm-fixes as requested on irc.
-Sima
> ---
> .mailmap| 5 +
> MAINTA
uch not correct there, hence this
separate rfc.
v2:
- fix authorship, this was all my typing
- some typo oopsies
- link to the drm panic work by Jocelyn for context
Signed-off-by: Daniel Vetter
Cc: Jocelyn Falempe
Cc: Andrew Morton
Cc: "Peter Zijlstra (Intel)"
Cc: Lukas Wunner
Cc
hw).
Signed-off-by: Daniel Vetter
Cc: Jocelyn Falempe
Cc: Andrew Morton
Cc: "Peter Zijlstra (Intel)"
Cc: Lukas Wunner
Cc: Petr Mladek
Cc: Steven Rostedt
Cc: John Ogness
Cc: Sergey Senozhatsky
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc:
ULL);
> +
> + if (IS_ERR(debug_dir))
> + return PTR_ERR(debug_dir);
> + debug_trigger = debugfs_create_file("trigger", 0200, debug_dir,
> + NULL, _drm_panic_ops);
> + return 0;
> +}
> +
> +static void __exit debugfs_end(void)
> +{
> + debugfs_remove_recursive(debug_dir);
> +}
> +
> +module_init(debugfs_start);
> +module_exit(debugfs_end);
> +
> +#endif
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
tside of these functions it is not safe to call
into driver code.
At that point it might be simpler to only register one panic notifier per
drm_device, and push the loop into the panic handler again.
Cheers, Sima
> + simpledrm_init_panic_buffer(primary_plane);
>
> /* CRTC */
>
> --
> 2.43.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
on (or whatever compositor you like) config file support
to set a bunch of "really only way to configure is by hand" output
properties would clear the bar here for me. Because that is a feature I
already mentioned that xrandr _does_ have, and which modetest hackery very
much does not.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 28, 2024 at 01:49:34PM -0800, Jessica Zhang wrote:
>
>
> On 2/2/2024 2:15 AM, Maxime Ripard wrote:
> > On Tue, Jan 30, 2024 at 09:53:13AM +0100, Daniel Vetter wrote:
> > > > > > > > Wouldn't it be simpler if we had a vkms-like pane
| 14 +
> 38 files changed, 3882 insertions(+), 30 deletions(-)
> create mode 100644 Documentation/gpu/rfc/color_pipeline.rst
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.c
> create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_colorop.h
> create mode 100644 drivers/gpu/drm/drm_colorop.c
> create mode 100644 drivers/gpu/drm/tests/drm_fixp_test.c
> create mode 100644 drivers/gpu/drm/vkms/Kconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
> create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_colorop.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.c
> create mode 100644 drivers/gpu/drm/vkms/vkms_luts.h
> create mode 100644 include/drm/drm_colorop.h
>
> --
> 2.44.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Feb 28, 2024 at 01:13:45PM +0200, Laurent Pinchart wrote:
> On Wed, Feb 28, 2024 at 11:41:57AM +0100, Jacopo Mondi wrote:
> > On Tue, Feb 27, 2024 at 03:08:27PM +0200, Laurent Pinchart wrote:
> > > On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote:
> >
On Tue, Feb 27, 2024 at 03:10:06PM +0200, Laurent Pinchart wrote:
> On Mon, Feb 26, 2024 at 05:24:41PM +0100, Jacopo Mondi wrote:
> > On Mon, Feb 26, 2024 at 04:46:24PM +0100, Daniel Vetter wrote:
> > > On Mon, 26 Feb 2024 at 16:39, Jacopo Mondi wrote:
> > &
s://gitlab.freedesktop.org/lumag/msm.git#msm-next-lumag
>
> If someone could just send me all the new equivalent URLs when the
> change happens, I will fix them up in my config.
>
> --
> Cheers,
> Stephen Rothwell
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
truct drm_sched_fence), 0,
> - SLAB_HWCACHE_ALIGN, NULL);
> + sched_fence_slab = KMEM_CACHE(drm_sched_fence, SLAB_HWCACHE_ALIGN);
> if (!sched_fence_slab)
> return -ENOMEM;
>
> --
> 2.39.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
go through Gitlab now, so it will change a
> few things. We will also need to update and move the issue template to
> the new repo to maintain consistency.
>
> I would expect the transition (if everything goes smoothly) to occur in
> the merge-window time frame (11/03 -> 24/03).
>
> Let me know if you have any questions, or if there's anything we missed,
> Maxime
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
op /
> > igt_drm_fdinfo / igt_drm_clients. Where and how exactly TBD.
>
> As soon as the new patch is merged, I'll go and reflect the driver uAPI
> changes
> in all three of these.
Would be good (and kinda proper per process rules) to implement the code
in at least e.g. gputop for
ima
>
> On Tue, Feb 06, 2024 at 03:07:47PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 01, 2024 at 10:42:56PM -0800, Shradha Gupta wrote:
> > > This patchset consists of sanity checks before enabling/disabling
> > > output polling to make sure we do not call polling e
d not 'old_data' as the
> latter is always set now. (And it is supposed to be non-NULL. Otherwise
> we would see the bug above again.)
>
> Signed-off-by: Jiri Slaby (SUSE)
> Fixes: a5a923038d70 ("fbdev: fbcon: Properly revert changes when vc_resize()
> failed")
> Cc:
_VENDOR_ALLWINNER 0x09
> #define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
> +#define DRM_FORMAT_MOD_VENDOR_RPI 0x0b
>
> /* add more to the end as needed */
>
> @@ -1568,6 +1569,10 @@ drm_fourcc_canonicalize_nvidia_format_mod(__u64
> modifier)
> #define AMD_FMT_MOD_CLEAR(field) \
>
ps://anongit.freedesktop.org/git/drm/drm
> -https://anongit.freedesktop.org/git/drm/drm.git
> +https://gitlab.freedesktop.org/drm/kernel.git
> +ssh://g...@gitlab.freedesktop.org:drm/kernel.git
> "
> drm_tip_repos[linux-upstream]="
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> --
> 2.43.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, 26 Feb 2024 at 16:21, Maxime Ripard wrote:
>
> Now that the main DRM tree has moved to Gitlab, adjust the MAINTAINERS
> git trees to reflect the location change.
>
> Signed-off-by: Maxime Ripard
Acked-by: Daniel Vetter
> ---
> MAINTAINERS | 4 ++--
> 1 fi
rg/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#for-linux-next
> https://gitlab.freedesktop.org/agd5f/linux#drm-next
> https://gitlab.freedesktop.org/drm/msm.git#msm-next
> https://gitlab.freedesktop.org/drm/tegra.git#for-next
> https://gitlab.freedesktop.org/lumag/msm.git#msm-next-lu
abs/gaudi/gaudi.c | 9 +-
> drivers/accel/habanalabs/gaudi2/gaudi2.c | 308 --
> drivers/accel/habanalabs/gaudi2/gaudi2P.h | 15 +-
> drivers/accel/habanalabs/goya/goya.c | 12 +-
> drivers/accel/habanalabs/goya/goya_coresight.c | 3 +-
> .../habanalabs/include/hw_ip/mmu/mmu_general.h | 2 +
> 21 files changed, 1008 insertions(+), 510 deletions(-)
> create mode 100644 drivers/accel/habanalabs/common/mmu/mmu_v2.c
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 33 +-
> drivers/gpu/drm/xe/xe_uc.h | 1 +
> drivers/gpu/drm/xe/xe_uc_fw.c | 60 +-
> drivers/gpu/drm/xe/xe_uc_fw_types.h| 9 +-
> drivers/gpu/drm/xe/xe_vm.c | 287 ++-
> drivers/gpu/drm/xe/xe_vm.h | 7 +-
> drivers/gpu/drm/xe/xe_vm_types.h | 18 +-
> drivers/gpu/drm/xe/xe_vram_freq.c | 128 +++
> drivers/gpu/drm/xe/xe_vram_freq.h | 13 +
> drivers/gpu/drm/xe/xe_wa.c | 191 +
> drivers/gpu/drm/xe/xe_wa_oob.rules | 12 +-
> drivers/gpu/drm/xe/xe_wait_user_fence.c| 2 +-
> drivers/gpu/drm/xe/xe_wopcm_types.h| 4 +-
> include/uapi/drm/xe_drm.h | 34 +-
> 141 files changed, 6518 insertions(+), 1187 deletions(-)
> create mode 100644 drivers/gpu/drm/xe/abi/gsc_proxy_commands_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_actions_sriov_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_relay_actions_abi.h
> create mode 100644 drivers/gpu/drm/xe/abi/guc_relay_communication_abi.h
> rename drivers/gpu/drm/xe/{ => display}/xe_display.c (99%)
> rename drivers/gpu/drm/xe/{ => display}/xe_display.h (100%)
> create mode 100644 drivers/gpu/drm/xe/regs/xe_pcode_regs.h
> create mode 100644 drivers/gpu/drm/xe/tests/xe_guc_db_mgr_test.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_guc_relay_test.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_kunit_helpers.c
> create mode 100644 drivers/gpu/drm/xe/tests/xe_kunit_helpers.h
> create mode 100644 drivers/gpu/drm/xe/tests/xe_test_mod.c
> create mode 100644 drivers/gpu/drm/xe/xe_gsc_proxy.c
> create mode 100644 drivers/gpu/drm/xe/xe_gsc_proxy.h
> create mode 100644 drivers/gpu/drm/xe/xe_gt_sriov_printk.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_db_mgr.c
> create mode 100644 drivers/gpu/drm/xe/xe_guc_db_mgr.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_hxg_helpers.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay.c
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay.h
> create mode 100644 drivers/gpu/drm/xe/xe_guc_relay_types.h
> create mode 100644 drivers/gpu/drm/xe/xe_memirq.c
> create mode 100644 drivers/gpu/drm/xe/xe_memirq.h
> create mode 100644 drivers/gpu/drm/xe/xe_memirq_types.h
> create mode 100644 drivers/gpu/drm/xe/xe_vram_freq.c
> create mode 100644 drivers/gpu/drm/xe/xe_vram_freq.h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ls/msm-sc7180-trogdor-lazor-limozeen-skips.txt
> create mode 100644 drivers/gpu/drm/panel/panel-himax-hx83112a.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Kconfig
> create mode 100644 drivers/gpu/drm/renesas/rz-du/Makefile
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_crtc.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_drv.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_encoder.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_kms.h
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.c
> create mode 100644 drivers/gpu/drm/renesas/rz-du/rzg2l_du_vsp.h
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Fri, Feb 16, 2024 at 05:51:59PM +0100, Christian König wrote:
> Am 16.02.24 um 17:32 schrieb Daniel Vetter:
> > On Tue, Feb 13, 2024 at 04:50:26PM +0100, Pierre-Eric Pelloux-Prayer wrote:
> > > This new event can be used to trace where a given dma_fence is added
> > &
On Fri, Feb 16, 2024 at 06:04:43PM +0100, Daniel Vetter wrote:
> On Thu, Feb 15, 2024 at 06:11:16PM +0800, Hsiao Chien Sung wrote:
> > Register CRC related function pointers to support
> > CRC retrieval.
> >
> > Signed-off-by: Hsiao Chien Sung
> > ---
> >
1 - 100 of 23124 matches
Mail list logo
