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
Hi Vignesh,
On Thu, 19 Oct 2023 at 09:07, Vignesh Raman wrote:
> +# Some tests crashes with malloc error and IGT tests floods
> +# the CI log with error messages and we end up with a warning message
> +# Job's log exceeded limit of 4194304 bytes.
> +# Job execution will continue but no more outpu
Hi Shawn,
On Mon, 16 Oct 2023 at 06:23, Shawn Sung (宋孝謙) wrote:
> On Fri, 2023-10-13 at 17:26 +0100, Daniel Stone wrote:
> > If I understand the driver correctly, padding is automatically
> > applied
> > to compensate for unaligned dimensions. The first/last rows/columns
&
On Fri, 6 Oct 2023 at 18:32, Rob Clark wrote:
> ssh logging is the default for mesa, as it is generally more reliable.
> But if there are kernel issues, especially at boot, UART logging is
> infinitely more useful.
Hmm, we should still be capturing the UART boot logs regardless. Those
go into a c
Hi Shawn,
On Fri, 6 Oct 2023 at 08:38, Hsiao Chien Sung wrote:
> + Padding provides ability to add pixels to width and height of a layer with
> + specified colors. Due to hardware design, Mixer in VDOSYS1 requires
> + width of a layer to be 2-pixel-align, or 4-pixel-align when ETHDR is
> enab
On Mon, 18 Sept 2023 at 23:02, Helen Koike wrote:
> On 14/09/2023 05:12, Daniel Vetter wrote:
> > Also yes how that landed without anyone running lockdep is ... not good. I
> > guess we need a lockdep enabled drm ci target that runs vkms tests asap
> > :-)
>
> btw, I just executed a draft version
Hi Jason, CK,
On Tue, 19 Sept 2023 at 04:04, Jason-JH.Lin wrote:
> The patch series provides drm driver support for enabling secure video
> path (SVP) playback on MediaiTek hardware in the Linux kernel.
>
> [...]
>
> Memory Usage in SVP:
> The overall flow of SVP starts with encrypted video comin
Hey,
On Thu, 14 Sept 2023 at 10:54, Maxime Ripard wrote:
> On Tue, Sep 12, 2023 at 02:16:41PM +0100, Daniel Stone wrote:
> > Hopefully less mangled formatting this time: turns out Thunderbird +
> > plain text is utterly unreadable, so that's one less MUA that is
> > act
Hi Maxime,
Hopefully less mangled formatting this time: turns out Thunderbird +
plain text is utterly unreadable, so that's one less MUA that is
actually usable to send email to kernel lists without getting shouted
at.
On Mon, 11 Sept 2023 at 15:46, Maxime Ripard wrote:
> On Mon, Sep 11, 2023 at
Hi,
On 04/09/2023 09:54, Daniel Vetter wrote:
On Wed, 30 Aug 2023 at 17:14, Helen Koike > wrote: >> >> On 30/08/2023 11:57, Maxime Ripard wrote: >>> >>> I
agree that we need a baseline, but that baseline should be >>> defined
by the tests own merits, not their outcome on a >>> particular plat
Hi,
On Fri, 25 Aug 2023 at 08:56, Hsia-Jun Li wrote:
> On 8/25/23 15:40, Pekka Paalanen wrote:
> > if userspace cannot access things like an image's HDR metadata, then it
> > will be impossible for userspace to program KMS to have the correct
> > color pipeline, or to send intended HDR metadata t
Hi Geert,
On Thu, 24 Aug 2023 at 16:09, Geert Uytterhoeven wrote:
> struct drm_client_dev *client = buffer->client;
> - struct drm_mode_fb_cmd fb_req = { };
> - const struct drm_format_info *info;
> + struct drm_mode_fb_cmd2 fb_req = { };
> int ret;
>
> - i
Hi,
On 11/08/2023 17:35, Robin Murphy wrote:
On 2023-08-09 17:53, Boris Brezillon wrote:
+obj-$(CONFIG_DRM_PANTHOR) += panthor.o
FWIW I still think it would be nice to have a minor
directory/Kconfig/Makefile reshuffle and a trivial bit of extra
registration glue to build both drivers into a
Userspace should not be able to trigger DRM_ERROR messages to spam the
logs; especially not through atomic commit parameters which are
completely legitimate for userspace to attempt.
Signed-off-by: Daniel Stone
Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc")
---
drive
Make it a little bit more clear what's going on and fix some formatting.
Signed-off-by: Daniel Stone
---
Documentation/driver-api/dma-buf.rst | 24
1 file changed, 16 insertions(+), 8 deletions(-)
v2: New.
diff --git a/Documentation/driver-api/dma-buf.r
1 - 100 of 800 matches
Mail list logo
