wise it would only match the f1
> plane.
Oh okay, I thought f0 was one of the primary planes, but it's not.
Thanks for the explanation.
For the user-space visible change:
Acked-by: Simon Ser
> It should have been an OVERLAY from the beginning. The documentation
> stipulates that there should be an unique PRIMARY plane per CRTC.
Thanks for the quick patch! One comment below…
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Cc: # 5.8+
> Signed-off-by: Paul Cercueil
>
On Monday, March 29th, 2021 at 5:39 PM, Paul Cercueil
wrote:
> Ok, I read that as "all drivers should provide AT LEAST one primary
> plane per CRTC", and not as "all drivers should provide ONE AND ONLY
> ONE primary plane per CRTC". My bad.
Yeah, it's a little complicated to document, because i
On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
wrote:
> Making the second plane an overlay would break the ABI, which is never
> something I'm happy to do; but I'd prefer to do it now than later.
Yeah, I wonder if some user-space depends on this behavior somehow?
> I still have concerns
On Monday, March 29th, 2021 at 4:07 PM, Maxime Ripard wrote:
> Since it looks like you have two mutually exclusive planes, just expose
> one and be done with it?
You can expose the other as an overlay. Clever user-space will be able
to figure out that the more advanced plane can be used if the p
On Saturday, March 27th, 2021 at 12:22 PM, Paul Cercueil
wrote:
> The ingenic-drm driver has two mutually exclusive primary planes
> already; so the fact that a CRTC must have one and only one primary
> plane is an invalid assumption.
Why does this driver expose two primary planes, if it only h
R-b me. Pushed, thanks!
On Tuesday, February 23rd, 2021 at 6:42 PM, Alex Deucher
wrote:
> yeah, fdo ran out of disk space so I moved to gitlab:
>
> https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Ah, thanks for the info, my bad!
On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor
wrote:
> On Mon, Feb 22, 2021 at 11:05:17PM +0000, Simon Ser wrote:
> > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> > wrote:
> >
> > > >> drivers/gpu/drm/amd/amdgpu/../d
On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
wrote:
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> >> warning: variable 'i' is uninitialized when used here
> >> [-Wuninitialized]
>timing = &edid->detailed_timings[i];
>
On Monday, February 15th, 2021 at 9:58 AM, Christian König
wrote:
> we are currently working an Freesync and direct scan out from system
> memory on AMD APUs in A+A laptops.
>
> On problem we stumbled over is that our display hardware needs to scan
> out from uncached system memory and we curren
On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
wrote:
> On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in
Please keep the commit message short. You probbly want to send this patch
to amd-...@lists.freedesktop.org instead of dri-devel.
On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal
wrote:
> Since he didn't comment over Hridya's last clarification about the
> tracepoints to track total GPU memory allocations being orthogonal to
> this series, I assumed he agreed with it.
IIRC he's away this week. (I don't remember wh
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
Code LGTM:
Reviewed-by: Simon Ser
On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul wrote:
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drive
s: Add format mod prop to
> base/ovly/nvdisp")
> Cc: James Jones
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Cc: # v5.8+
> Signed-off-by: Lyude Paul
Together with [1], this patch allows me to run unpatched modifier-aware
user-space successfully, without a c
On Thursday, January 14th, 2021 at 9:06 AM, Simon Ser
wrote:
> On Thursday, January 14th, 2021 at 9:04 AM, Mauro Carvalho Chehab
> wrote:
>
> > A function has a different name between their prototype
> > and its kernel-doc markup:
> >
> > ../include/drm/dr
ototype was for drmm_crtc_alloc_with_planes()
> instead
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Simon Ser
nouveau already has something for colorkey:
https://drmdb.emersion.fr/properties/4008636142/colorkey
I know this is marked "not for merge", but it would be nice to discuss
with them and come up with a standardized property.
On Monday, November 16, 2020 12:03 PM, Colin King
wrote:
> From: Colin Ian King colin.k...@canonical.com
>
> Since moving to the new debug helper functions we now have a debug message
> that dereferences crtc to print a kernel debug message when crtc is null
> and so this debug message will now
On Friday, October 23, 2020 5:27 PM, Ville Syrjälä
wrote:
> These are two extreme cases:
Thanks!
> > I'm trying to get
> > a fix for my user-space 1, and I'm wondering if int32_t is enough
> > after dividing by mode->htotal.
> > CC Pekka, just FYI (I think Weston has similar code).
>
> What's
On Thursday, October 22, 2020 12:14 PM, Ville Syrjälä
wrote:
> On Wed, Oct 21, 2020 at 08:13:43PM -0700, Randy Dunlap wrote:
>
> > Hi,
> > With linux-next 20201021, when booting up, I am seeing this:
> > [ 0.560896] UBSAN: signed-integer-overflow in
> > ../drivers/gpu/drm/drm_modes.c:765:20
> >
On Tuesday, September 1, 2020 3:26 PM, Daniel Vetter wrote:
> On Tue, Sep 01, 2020 at 08:57:37AM +0000, Simon Ser wrote:
>
> > On Monday, August 31, 2020 3:48 PM, Ville Syrjälä
> > ville.syrj...@linux.intel.com wrote:
> >
> > > > > It doesn't s
On Monday, August 31, 2020 3:48 PM, Ville Syrjälä
wrote:
> > > It doesn't seem like this IGT test's goal is to exercise support for
> > > gamma LUTs. Does the test just tries to reset the gamma LUT to linear?
> > > If so, I think the IGT test should be fixed to ignore "I don't support
> > > gamm
On Saturday, August 29, 2020 4:06 PM, Sidong Yang wrote:
> Currently vkms module doesn't support gamma function for userspace. so igt
> subtests in kms_plane(pixel-format-pipe-A-plan) failed for calling
> drmModeCrtcSetGamma().
It doesn't seem like this IGT test's goal is to exercise support for
Thanks for the update!
The driver should also disallow importing a AMLOGIC_FBC_LAYOUT_SCATTER
DMA-BUF from another device, but I guess this is clear enough ("not
transferrable between Amlogic SoCs").
>From a user-space PoV:
Acked-by: Simon Ser
On Thursday, July 2, 2020 9:47 AM, Neil Armstrong
wrote:
> Finally is also adds the Scatter Memory layout, meaning the header contains
> IOMMU
> references to the compressed frames content to optimize memory access
> and layout.
>
> In this mode, only the header memory address is needed, thus t
Commit-ID: 6d77d3b43ad84a48b502f02dc618e7c36737bdfe
Gitweb: https://git.kernel.org/tip/6d77d3b43ad84a48b502f02dc618e7c36737bdfe
Author: Simon Ser
AuthorDate: Mon, 9 Jul 2018 11:17:22 -0500
Committer: Ingo Molnar
CommitDate: Sat, 14 Jul 2018 14:59:42 +0200
objtool: Use '.strta
Executables that are generated by Clang don't have a .shstrtab
section, and store section names in .strtab instead. We can store
section names generated by orc there in this case.
Signed-off-by: Simon Ser
---
tools/objtool/elf.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Commit-ID: ce90aaf5cde4ce057b297bb6c955caf16ef00ee6
Gitweb: https://git.kernel.org/tip/ce90aaf5cde4ce057b297bb6c955caf16ef00ee6
Author: Simon Ser
AuthorDate: Sat, 30 Dec 2017 14:43:32 -0600
Committer: Ingo Molnar
CommitDate: Sat, 30 Dec 2017 22:04:17 +0100
objtool: Fix seg fault with
Commit-ID: d89e426499cf36b96161bd32970d6783f1fbcb0e
Gitweb: https://git.kernel.org/tip/d89e426499cf36b96161bd32970d6783f1fbcb0e
Author: Simon Ser
AuthorDate: Sat, 30 Dec 2017 14:43:31 -0600
Committer: Ingo Molnar
CommitDate: Sat, 30 Dec 2017 22:04:17 +0100
objtool: Fix seg fault
32 matches
Mail list logo
