On Thu, 5 Jun 2025 at 17:32, Tomeu Vizoso wrote:
> On Thu, Jun 5, 2025 at 3:37 PM Robin Murphy wrote:
> > It should only need a single IOMMU domain per DRM client, so no faffing
> > about replicating mappings. iommu_paging_domain_alloc() does need *an*
> > appropriate target device so it can iden
Hey,
On Thu, 5 Jun 2025 at 08:41, Tomeu Vizoso wrote:
> > Indeed if you're using the IOMMU API directly then you need to do your
> > own address space management either way, so matching bits of process VA
> > space is pretty simple to put on the table.
>
> My impression was that the VM_BIND facil
Hi Tomeu,
I have some bad news ...
On Wed, 4 Jun 2025 at 08:57, Tomeu Vizoso wrote:
> +int rocket_ioctl_create_bo(struct drm_device *dev, void *data, struct
> drm_file *file)
> +{
> + [...]
> +
> + /* This will map the pages to the IOMMU linked to core 0 */
> + sgt = drm_gem_sh
Signed-off-by: Konstantin Shabanov
> Reported-by: Dan Callaghan
> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7968
Acked-by: Daniel Stone
Cheers,
Daniel
On Mon, 26 May 2025 at 08:16, Boris Brezillon
wrote:
> On Sat, 24 May 2025 16:03:37 +0100
> Daniel Stone wrote:
> > Unfortunately I have to revoke my T-b as we're seeing a pile of
> > failures in a CI stress test with this, e.g.
> > https://gitlab.freedesktop.org
Hi,
On Sun, 25 May 2025 at 11:51, Krzysztof Kozlowski wrote:
> On 25/05/2025 12:48, Daniel Stone wrote:
> > On Sun, 25 May 2025 at 06:16, Krzysztof Kozlowski
> > wrote:
> >> ---
> >> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.ya
On Sun, 25 May 2025 at 06:16, Krzysztof Kozlowski
wrote:
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
> @@ -45,9 +45,8 @@ properties:
>- description: OVL-2L Clock
>
>iommu
is not scheduled, we suspend the
> timeout again which undoes what drm_sched_job_begin() did when calling
> drm_sched_start_timeout(). So the timeout does not reset when a job
> is finished.
>
> Co-developed-by: Boris Brezillon
> Signed-off-by: Boris Brezillon
> Tested-by: Daniel
Hi Jason,
On Thu, 22 May 2025 at 09:52, Jason-JH Lin wrote:
> Our hardware registers are set through GCE, not by the CPU.
> DRM might assume the hardware is disabled immediately after calling
> atomic_disable() of drm_plane, but it is only truly disabled after the
> GCE IRQ is triggered.
>
> Addi
lures due to timeouts when fetching the full repository.
>
> The current s3cp stopped working after the migration. Update to the
> latest mesa and ci-templates to get s3cp working again and adapt to
> recent changes in mesa-ci.
I thought I already did this, sorry; the series is:
Acked-b
Hi,
On Thu, 15 May 2025 at 19:02, Harry Wentland wrote:
> On 2025-05-15 13:19, Daniel Stone wrote:
> > Yeah, the Weston patches are marching on. We've still been doing a
> > little bit of cleanup and prep work in the background to land them,
> > but we also can't l
Hi Steven,
On Thu, 8 May 2025 at 11:42, Steven Price wrote:
> I'm also seeing a splat when running this, see below. I haven't got my
> head around how this is happening, but I see it when glmark quits at the
> end of the test.
>
> [ 399.505066] Unable to handle kernel NULL pointer dereference at
Hi,
On Thu, 15 May 2025 at 15:11, Harry Wentland wrote:
> On 2025-05-15 05:45, Simon Ser wrote:
> > I've reviewed all of the core DRM patches :)
> >
> > Have there been updates from user-space implementations?
>
> I know Leandro has been working on Weston to make use of
> this and last year Xaver
e
> decoders are likely much more common than hardware ones for the foreseeable
> future. Note that these formats already have Vulkan equivalents:
> - VK_FORMAT_G16_B16_R16_3PLANE_420_UNORM
> - VK_FORMAT_G16_B16_R16_3PLANE_422_UNORM
> - VK_FORMAT_G16_B16_R16_3PLANE_444_UNORM
Thanks a lot for these - series is:
Reviewed-by: Daniel Stone
Cheers,
Daniel
Hi Andy,
On Thu, 8 May 2025 at 11:49, Andy Yan wrote:
> Let the user know what went wrong in drm_gem_fb_afbc_init
> failure paths.
Thanks for this, and thanks also for using drm_dbg_kms() to make sure
that userspace can't flood the log with errors.
Reviewed-by: Daniel Stone
Cheers,
Daniel
Hey there,
On Thu, 1 May 2025 at 12:22, Robert Mader wrote:
> Unlike formats typically used by hardware decoders the 10/12bit formats
> use a LSB alignment. In order to allow fast implementations in GL
> and Vulkan the padding must contain only zeros, so the float
> representation can be calculat
Hi Andy,
On Fri, 18 Apr 2025 at 01:16, Andy Yan wrote:
> I prefer the V1 version PATCH[0]. This is because we do not deal with
> hardware-related
> differences at this level. It involves a VOP-related restriction and we
> always handle
> limitiation like this within the VOP driver .
As said
Hi,
On Mon, 14 Apr 2025 at 16:34, Steven Price wrote:
> On 14/04/2025 13:47, Boris Brezillon wrote:
> > Hm, I might have been too prompt at claiming this was doable. In
> > practice, doing that might regress Lima and Panfrost in situations
> > where trying harder than GFP_NOWAIT would free up som
Hi,
On Fri, 11 Apr 2025 at 16:05, Adrián Larumbe
wrote:
> +#define PANTHOR_BO_LABEL_MAXLENPAGE_SIZE
PAGE_SIZE can change between kernel builds with a config setting.
If the thinking here is '4KiB is big enough' (which I agree with),
then just define it to 4096.
Cheers,
Daniel
On Mon, 14 Apr 2025 at 09:24, Simon Ser wrote:
> On Friday, January 17th, 2025 at 12:15, Pekka Paalanen
> wrote:
> > Wasn't this also conditional on the DRM_CAP_CRTC_IN_VBLANK_EVENT or did
> > userspace really need to count the events even without it?
>
> DRM_CAP_CRTC_IN_VBLANK_EVENT is uncondit
Hi Harry,
On Tue, 8 Apr 2025 at 18:30, Harry Wentland wrote:
> On 2025-04-08 12:40, Daniel Stone wrote:
> > OK, Harry's reply cleared that up perfectly - the flexibility that's
> > there at the moment is about being able to reuse colorops for CRTCs in
> > post
Hi there,
On Tue, 1 Apr 2025 at 20:53, Simon Ser wrote:
> On Tuesday, April 1st, 2025 at 17:14, Daniel Stone
> wrote:
> > 'plane' seems really incongruous here. The colorop can be created for
> > any number of planes, but we're setting it to always be bound t
Hi Konstantin,
On Thu, 3 Apr 2025 at 07:45, Konstantin Shabanov wrote:
> Disable AFBC for resolutions bigger than 2560x1600 as RK3399 doesn't
> support them.
>
> From the datasheet[1] ("1.2.10 Video IN/OUT", "Display Interface", p. 17):
>
> Support AFBC function co-operation with GPU
> * su
Hi Alex,
On Wed, 26 Mar 2025 at 23:50, Alex Hung wrote:
> +static int drm_colorop_init(struct drm_device *dev, struct drm_colorop
> *colorop,
> + struct drm_plane *plane, enum drm_colorop_type
> type)
> +{
> + struct drm_mode_config *config = &dev->mode_config;
>
Hi Vignesh,
On Fri, 28 Mar 2025 at 11:03, Vignesh Raman wrote:
> The current s3cp implementation does not work anymore after the
> migration, and instead of fixing it and propagating the fix down to us,
> it's simpler to directly use curl. Uprev mesa [1][2] to adapt these
> changes. Also replace
Hi Vignesh,
On Fri, 28 Mar 2025 at 11:03, Vignesh Raman wrote:
> Ensure the repository is not shallow before fetching branches in
> check-patch job. This prevents issues where git merge-base fails
> due to incomplete history. Set the timeout of check-patch job to 1h.
Ouch - an hour is pretty bru
the series is:
Acked-by: Daniel Stone
Cheers,
Daniel
Hi Vignesh,
On Fri, 28 Feb 2025 at 15:12, Vignesh Raman wrote:
> The python-artifacts job has a timeout of 10 minutes, which causes
> build failures as it was unable to clone the repository within the
> specified limits. Set GIT_DEPTH to 50 to speed up cloning and avoid
> build failures due to ti
cally for marge-bot and scheduled
> pipelines, but in all other cases run manually. Also
> remove CI_PROJECT_NAMESPACE checks specific to mesa.
Thanks Vignesh, this is:
Reviewed-by: Daniel Stone
nd refactors software-driver stage jobs.
>
> Test run with this series,
> https://gitlab.freedesktop.org/vigneshraman/linux/-/pipelines/1366054
Series is:
Reviewed-by: Daniel Stone
Please merge at will.
Cheers,
Daniel
On Wed, 26 Feb 2025 at 08:35, Dmitry Baryshkov
wrote:
> The job has a timeout of 10 minutes, which causes a build failures as it
> is even unable to clone the repo within the specified limits. Extend
> the job's timeout to 1 hour.
This is neither expected nor sensible. We should fix this some oth
Hi Vignesh,
On Wed, 26 Feb 2025 at 13:55, Vignesh Raman wrote:
> Merge request pipelines were only created when changes
> were made to drivers/gpu/drm/ci/, causing MRs that didn't
> touch this path to break. Fix MR pipeline rules to trigger
> jobs for all changes.
Thanks a lot for fixing this up
Hey,
On Tue, 25 Feb 2025 at 22:18, Alyssa Rosenzweig wrote:
> > > These layouts are notably not used for interchange across hardware
> > > blocks (e.g. with the display controller). There are other layouts for
> > > that but we don't support them either in userspace or kernelspace yet
> > > (even
Hi,
On Tue, 25 Feb 2025 at 21:35, Alyssa Rosenzweig wrote:
> These layouts are notably not used for interchange across hardware
> blocks (e.g. with the display controller). There are other layouts for
> that but we don't support them either in userspace or kernelspace yet
> (even downstream), so
Hi Sumit,
On Fri, 21 Feb 2025 at 11:24, Sumit Garg wrote:
> On Tue, 18 Feb 2025 at 21:52, Daniel Stone wrote:
> > dma-heaps was created to solve the problem of having too many
> > 'allocate $n bytes from $specialplace' uAPIs. The proliferation was
> > pain
On Tue, 18 Feb 2025 at 14:35, Jens Wiklander wrote:
> This can be tested on a RockPi 4B+ with the following steps:
> repo init -u https://github.com/jenswi-linaro/manifest.git -m rockpi4.xml \
> -b prototype/sdp-v5
> repo sync -j8
> cd build
> make toolchains -j$(nproc)
> make all -j$(npro
Hi Sumit,
On Mon, 17 Feb 2025 at 06:13, Sumit Garg wrote:
> On Fri, 14 Feb 2025 at 21:19, Boris Brezillon
> wrote:
> > I would say one heap per-profile.
>
> And then it would have a per vendor multiplication factor as each
> vendor enforces memory restriction in a platform specific manner which
Hi,
On Thu, 13 Feb 2025 at 15:57, Jens Wiklander wrote:
> On Thu, Feb 13, 2025 at 3:05 PM Daniel Stone wrote:
> > But just because TEE is one good backend implementation, doesn't mean
> > it should be the userspace ABI. Why should userspace care that TEE has
> > media
Hi,
On Thu, 13 Feb 2025 at 12:40, Boris Brezillon
wrote:
> On Thu, 13 Feb 2025 14:46:01 +0530 Sumit Garg wrote:
> > Yeah but all the prior vendor specific secure/restricted DMA heaps
> > relied on DT information.
>
> Right, but there's nothing in the DMA heap provider API forcing that.
Yeah. DM
On Wed, 5 Feb 2025 at 13:48, Vignesh Raman wrote:
> Update drm/ci maintainer entries:
>
> * Add myself as drm/ci maintainer.
> * Update Helen's email address.
Acked-by: Daniel Stone
Heya,
On Fri, 24 Jan 2025 at 08:42, Erik Faye-Lund
wrote:
> On Thu, 2025-01-09 at 13:14 +0000, Daniel Stone wrote:
> > Thanks, this is:
> > Reviewed-by: Daniel Stone
> >
> > I can push into drm-misc as well, but give me a bit to get dim set up
> > again.
&g
On Thu, 16 Jan 2025 at 10:35, Dmitry Baryshkov
wrote:
> On Thu, Jan 16, 2025 at 11:17:50AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Jan 16, 2025 at 11:03 AM Tomi Valkeinen
> > wrote:
> > > On the platforms I have been using (omap, tidss, xilinx, rcar) the dumb
> > > buffers are the only buffe
On Wed, 15 Jan 2025 at 14:20, Tomi Valkeinen
wrote:
> No disagreement there, we need CREATE_DUMB2.
>
> My point is that we have the current UAPI, and we have userspace using
> it, but we don't have clear rules what the ioctl does with specific
> parameters, and we don't document how it has to be u
On Wed, 15 Jan 2025 at 04:05, Marek Olšák wrote:
> On Tue, Jan 14, 2025 at 12:58 PM Daniel Stone wrote:
>> AMD hardware is the only hardware I know of which doesn't support
>> overaligning. Say (not hypothetically) we have a GPU and a display
>> controller which have a
Hi,
On Tue, 14 Jan 2025 at 09:38, Marek Olšák wrote:
> I would keep the existing modifier interfaces, API extensions, and
> expectations the same as today for simplicity.
Well yes, not just for simplicity, but because everything stops
working if you don't.
> The new linear modifier definition
Hi,
On Thu, 9 Jan 2025 at 15:30, Michel Dänzer wrote:
> On 2025-01-08 18:22, Simona Vetter wrote:
> > Maybe I'm wrong, but my understanding is that English generally doesn't do
> > compound words connected with dashes, you just line them up with spaces.
>
> I hope you don't mind me jumping in, th
Hi Eric,
On Thu, 19 Dec 2024 at 17:49, wrote:
> MediaTek (MTK) uses some unique tiled memory formats
> for video decoding. Add these to the uapi drm_fourcc.h
> so that we can use them in Mesa, GStreamer, and other
> tools/libraries.
Thanks, this is:
Reviewed-by: Daniel Stone
I c
Hey Eric,
On Thu, 19 Dec 2024 at 00:20, Eric Smith wrote:
> On 18/12/2024 10.33, Daniel Stone wrote:
> >> +/*
> >> + * MediaTek Tiled Modifier
> >> + * This is a tiled layout using tiles of 16x32 pixels in a row-major
> >> layout.
> >>
On Thu, 19 Dec 2024 at 02:54, Marek Olšák wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey wrote:
>> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
>> > For that reason I think linear modifiers with explicit pitch/size
>> > alignment constraints is a sound concept and fits i
On Wed, 18 Dec 2024 at 10:32, Brian Starkey wrote:
> On Wed, Dec 18, 2024 at 11:24:58AM +, Simona Vetter wrote:
> > For that reason I think linear modifiers with explicit pitch/size
> > alignment constraints is a sound concept and fits into how modifiers work
> > overall.
>
> Could we make it
Hi Eric,
On Fri, 13 Dec 2024 at 18:47, wrote:
> MediaTek (MTK) uses some unique tiled memory formats
> for video decoding. Add these to the uapi drm_fourcc.h
> so that we can use them in Mesa, GStreamer, and other
> tools/libraries.
Thanks for pushing these upstream!
> +/* MediaTek layouts */
>
Hi Andy,
On Tue, 17 Dec 2024 at 00:41, Andy Yan wrote:
> At 2024-12-16 21:06:07, "Daniel Stone" wrote:
> >On Sat, 14 Dec 2024 at 08:18, Andy Yan wrote:
> >> This is the only afbc format supported by the upcoming
> >> VOP for rk3576.
> >>
> >&
Hi Andy,
On Sat, 14 Dec 2024 at 08:18, Andy Yan wrote:
> This is the only afbc format supported by the upcoming
> VOP for rk3576.
>
> Add support for it.
Out of interest, how was this tested? There is no 32x8 modifier in the
format list in format_modifiers_afbc[], so it seems like it shouldn't
b
Hi Andy,
On Mon, 9 Dec 2024 at 12:32, Andy Yan wrote:
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> index bd8db45eeba6..1f101a3c3942 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> +++ b/drivers/gpu/drm/rockchip/rockc
Hi Arun,
On Thu, 21 Nov 2024 at 12:35, Arun R Murthy wrote:
> The corresponding mutter changes to enable/disable histogram, read the
> histogram data, communicate with the library and write the enhanced data
> back to the KMD is also pushed for review at
> https://gitlab.gnome.org/GNOME/mutter/-
Hi Arun,
On Tue, 19 Nov 2024 at 14:39, Murthy, Arun R wrote:
> > On Tue, 19 Nov 2024 at 10:55, Arun R Murthy
> > wrote:
> > > The corresponding mutter changes to enable/disable histogram, read the
> > > histogram data, communicate with the library and write the enhanced
> > > data back to the KM
Hi Arun,
On Tue, 19 Nov 2024 at 10:55, Arun R Murthy wrote:
> The corresponding mutter changes to enable/disable histogram, read the
> histogram data, communicate with the library and write the enhanced data
> back to the KMD is also pushed for review at
> https://gitlab.gnome.org/GNOME/mutter/-
Hi Piotr,
On Wed, 16 Oct 2024 at 20:19, Piotr Zalewski wrote:
> On Wednesday, October 16th, 2024 at 2:27 PM, Daniel Stone
> wrote:
> > 1 is the only solution that can work. Silently changing the colour
> > properties of a separate CRTC is not OK, since this can lead to
> &
Hi all,
On Wed, 16 Oct 2024 at 02:11, Andy Yan wrote:
> At 2024-10-16 04:13:40, "Piotr Zalewski" wrote:
> >Ok I get it now. Is such rework correct? - when gamma LUT for rk356x is
> >being set, instead of disabling the LUT before the gamma LUT write for the
> >current CRTC's video port, active vi
Hi Vignesh,
On Fri, 4 Oct 2024 at 09:31, Vignesh Raman wrote:
> +.software-driver:
> + stage: software-driver
> + extends:
> +- .test-gl
> +- .test-rules
> + timeout: "1h30m"
> + tags:
> +- kvm
> + script:
> +- ln -sf $CI_PROJECT_DIR/install /install
> +- mv install/bzIma
Hi Jens,
On Fri, 30 Aug 2024 at 08:04, Jens Wiklander wrote:
> This patch set is based on top of Yong Wu's restricted heap patch set [1].
> It's also a continuation on Olivier's Add dma-buf secure-heap patch set [2].
>
> The Linaro restricted heap uses genalloc in the kernel to manage the heap
>
Hi Vignesh,
On Thu, 5 Sept 2024 at 10:41, Vignesh Raman wrote:
> Uprev IGT to the latest version and deqp-runner
> to v0.20.0. Also update expectation files.
Thanks! This is:
Reviewed-by: Daniel Stone
Hi José,
On Tue, 13 Aug 2024 at 11:51, José Expósito wrote:
> - When a CRTC is added and removed before device creation, there
>is a vblank warning.
>The issue is caused because vblanks are referenced using the
>CRTC index but, because one of the CRTCs is removed, the
>indices ar
On Wed, 7 Aug 2024 at 09:21, Vignesh Raman wrote:
> Uprev mesa to adapt to the latest changes in mesa ci.
> Project 'anholt/deqp-runner' was moved to 'mesa/deqp-runner'.
> So update the link.
Reviewed-by: Daniel Stone
it series adds support in drm-ci to run tests
> for both GPU and display drivers for MediaTek mt8173/mt8183, Rockchip
> rk3288/rk3399, and Amlogic Meson G12B (A311D) platforms.
>
> Update the expectations file, and skip driver-specific tests and
> tools_test on non-intel platforms.
Tha
Hi Piotr,
On Thu, 25 Jul 2024 at 20:06, Piotr Zalewski wrote:
> I based my patch on how gamma LUT is handled in VOP. There, in atomic
> enable, gamma LUT write takes places at the end too, after the mutex was
> already first-time unlocked. I understand the concept of DRM atomic state
> updates an
Hi Vignesh,
On Wed, 24 Jul 2024 at 11:12, Vignesh Raman wrote:
> For rockchip rk3288 and rk3399, the display driver is rockchip
> and gpu driver is panfrost. Currently, in drm-ci for rockchip
> rk3288 and rk3399, only the gpu driver is tested. Refactor
> the existing rockchip jobs to test both di
Hi Vignesh,
On Wed, 24 Jul 2024 at 11:11, Vignesh Raman wrote:
> +dumb_buffer@create-clear,Fail
> +dumb_buffer@create-valid-dumb,Fail
> +dumb_buffer@invalid-bpp,Fail
> +dumb_buffer@map-invalid-size,Fail
> +dumb_buffer@map-uaf,Fail
> +dumb_buffer@map-valid,Fail
> +fbdev@eof,Fail
> +fbdev@read,Fail
Hi Piotr,
On Wed, 24 Jul 2024 at 23:06, Piotr Zalewski wrote:
> Add support for gamma LUT in VOP2 driver. The implementation is based on
> the one found in VOP driver and modified to be compatible with VOP2. Blue
> and red channels in gamma LUT register write were swapped with respect to
> how ga
andle overlapping overlay planes, and
any userspace which supports overlays (including Weston) already looks
at zpos, handles immutable properties, and will dtrt.
Anyway, this is:
Acked-by: Daniel Stone
Cheers,
Daniel
ame change before:
> > Reviewed-by: Fei Shao
> > Tested-by: Fei Shao
>
> Thanks!
And:
Reviewed-by: Daniel Stone
> >> OOTH, Intel recently added a feature for enumerating "suggested"
> >> cursor sizes. See https://patchwork.freedesktop.org/patc
te the link from anongit to the Gitlab server to prevent the build
> script from hanging indefinitely.
It should be fixed by now, but yeah, the canonical source has changed.
Reviewed-by: Daniel Stone
Thanks Deborah!
Cheers,
Daniel
Hi,
On Fri, 28 Jun 2024 at 10:43, Tomeu Vizoso wrote:
> On Wed, Jun 26, 2024 at 9:26 PM Daniel Stone wrote:
> > It's not just etnaviv, it's literally every Mesa driver which works
> > with decoupled render/display. So that would be etnaviv-v2,
> > panfrost-v2,
On Wed, 26 Jun 2024 at 18:52, Daniel Vetter wrote:
> On Wed, Jun 26, 2024 at 11:39:01AM +0100, Daniel Stone wrote:
> > On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> > > So we are kind of stuck here between breaking one or the other use-
> > > case. I'm leani
Hi,
On Wed, 26 Jun 2024 at 09:28, Lucas Stach wrote:
> Mesa doesn't cope right now. Mostly because of the renderonly thing
> where we magically need to match render devices to otherwise render
> incapable KMS devices. The way this matching works is that the
> renderonly code tries to open a scree
Hi Dave,
On Fri, 21 Jun 2024 at 14:19, Dave Stevenson
wrote:
> Add myself as maintainer for VC4 alongside Maxime, and
> our internal review list as reviewer.
Both patches are:
Acked-by: Daniel Stone
Cheers,
Daniel
On Wed, 19 Jun 2024 at 12:31, Ville Syrjala
wrote:
> Export drm_plane_has_format() so that drivers can use it.
Acked-by: Daniel Stone
Hi,
On Mon, 20 May 2024 at 08:39, Tomeu Vizoso wrote:
> On Fri, May 10, 2024 at 10:34 AM Lucas Stach wrote:
> > Am Mittwoch, dem 24.04.2024 um 08:37 +0200 schrieb Tomeu Vizoso:
> > > If we expose a render node for NPUs without rendering capabilities, the
> > > userspace stack will offer it to co
nd its extensions, 2) Vulkan and its extensions, 3) libcamera.
But it doesn't really make much difference; people are going to get the point.
With whatever reasonable wording, series is:
Reviewed-by: Daniel Stone
Thanks Jacopo!
-d
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
> > needs access to the GPU render node and the display node too, in order
> > to a
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 efficient on some platforms, since they wouldn't be able to do
> > direct
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 that bad applications are an issue, but not for the flathub / snaps
> > case. Flatpacks / snaps run sandboxed and don't ha
/HEIGHT caps, which can only declare
> a one size fits all limit for the whole device.
Acked-by: Daniel Stone
Cheers,
Daniel
On Mon, 26 Feb 2024 at 12:03, Jani Nikula wrote:
> On Mon, 26 Feb 2024, Daniel Stone wrote:
> > It's a fair question. If you want to verify that someone is
> > @intel.com, maybe get them to email you out-of-band to check it. If
> > you want to check something else, j
On Mon, 26 Feb 2024 at 11:57, Jani Nikula wrote:
> On Mon, 26 Feb 2024, Maxime Ripard wrote:
> > For the recent-ish subscriptions, it's possible since we've required to
> > open a Gitlab issue for a while, so we have the association between the
> > Gitlab account and the SSH account already.
> >
Hi,
On Mon, 26 Feb 2024 at 03:21, Lucas De Marchi wrote:
> All of this should be fixed by now: dim is used for applying and pushing
> patches, which has additional checks so that doesn't happen again. Still
> pending confirmation from Daniel Stone if the git server hooks are ready
Hi Stephen,
On Tue, 20 Feb 2024 at 22:46, Stephen Rothwell wrote:
> On Tue, 20 Feb 2024 11:25:05 +0000 Daniel Stone wrote:
> > cc sfr - once we move the DRM repos to a different location, what's
> > the best way to update linux-next?
>
> These are (I think) all the
On Tue, 20 Feb 2024 at 09:05, Maxime Ripard wrote:
> On Tue, Feb 20, 2024 at 09:49:25AM +0100, Maxime Ripard wrote:
> > This will be mostly transparent to current committers and users: we'll
> > still use dim, in the exact same way, the only change will be the URL of
> > the repo. This will also b
Hi,
On Fri, 16 Feb 2024 at 09:00, Tomi Valkeinen
wrote:
> On 13/02/2024 13:39, Daniel Stone wrote:
> > Specifically, you probably want commits 4cde507be6a1 and 58dde0e0c000.
> > I think the window of breakage was small enough that - assuming either
> > those commits or an up
Hi,
On Tue, 13 Feb 2024 at 10:18, Marius Vlad wrote:
> On Tue, Feb 13, 2024 at 11:57:59AM +0200, Tomi Valkeinen wrote:
> > I haven't. I'm quite unfamiliar with Weston, and Randolph from TI (cc'd) has
> > been working on the Weston side of things. I also don't know if there's
> > something TI spec
On Wed, 31 Jan 2024 at 02:31, Zack Rusin wrote:
> On Tue, Jan 30, 2024 at 6:50 PM Daniel Stone wrote:
> > The entire model we have is that basis timing flows backwards. The
> > 'hardware' gives us a deadline, KMS angles to meet that with a small
> > margin, the
Hi,
On Tue, 30 Jan 2024 at 18:39, Zack Rusin wrote:
> In general, yes. Of course it's a little more convoluted because we'll
> act like OpenGL runtime here (i.e. glXSwapBuffers), i.e. our driver
> will fake page-flips because the only memory we'll have is a single
> buffer as the actual page-flip
Hi Lucas,
On Fri, 26 Jan 2024 at 17:00, Lucas Stach wrote:
> The dma sync operation needs to be done with DMA_BIDIRECTIONAL when
> the BO is prepared for both read and write operations. With the
> current inverted if ladder it would only be synced for DMA_FROM_DEVICE.
>
> [...]
>
> static inline
Hi Vignesh,
On Tue, 16 Jan 2024 at 09:55, Vignesh Raman wrote:
> Rename the name of xfail files for mediatek (mt8173 and mt8183),
> to include information about the tested driver and update xfails
> accordingly. Since the correct driver name is passed from the job to
> test gpu and display driver
Hi Vignesh,
On Wed, 10 Jan 2024 at 10:47, Vignesh Raman wrote:
> On 09/01/24 19:08, Daniel Stone wrote:
> > A better sequencing would be something like:
> >1. add ANX7625 config
> >2. refactor _existing_ MTK display jobs to use YAML includes, change
> > the ex
Hi,
On Wed, 10 Jan 2024 at 10:44, Daniel Vetter wrote:
> On Tue, Jan 09, 2024 at 11:12:11PM +, Andri Yngvason wrote:
> > ţri., 9. jan. 2024 kl. 22:32 skrifađi Daniel Stone :
> > > How does userspace determine what's happened without polling? Will it
> > > onl
Hi,
On Tue, 9 Jan 2024 at 18:12, Andri Yngvason wrote:
> + * active color format:
> + * This read-only property tells userspace the color format actually used
> + * by the hardware display engine "on the cable" on a connector. The
> chosen
> + * value depends on hardware capabilities
Hi,
On Wed, 20 Dec 2023 at 12:11, Vignesh Raman wrote:
> Some ARM SOCs have a separate display controller and GPU, each with
> different drivers. For mediatek mt8173, the GPU driver is powervr,
> and the display driver is mediatek. In the case of mediatek mt8183,
> the GPU driver is panfrost, and
Hi Vignesh,
On Wed, 29 Nov 2023 at 12:19, Vignesh Raman wrote:
> Expected driver for mt8173 is "mediatek" and for mt8183
> it is "panfrost". Set IGT_FORCE_DRIVER to 'mediatek' as
> the expected driver for mt8173.
Actually, for mt8183 it's both. And for mt8173 it will probably be
mediatek+pvr pre
ble at [3]. IGT test available
> at [4].
Series is:
Reviewed-by: Daniel Stone
1 - 100 of 814 matches
Mail list logo
