On Fri, Oct 04, 2024 at 11:12:45AM +0800, Moudy Ho wrote:
> The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'clocks' property:
> display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
>
> To resolve this issue, the constraints for 'clo
Hi,
On 03-10-2024 15:13, Aradhya Bhatia wrote:
> Hi Wadim,
>
> Thanks for the patch.
>
> Probably a nit, but the dt-binding patch should come before the driver
> patch.
>
> On 03-10-2024 13:50, Wadim Egorov wrote:
>> Introduce a data-lines property to define the number of parallel RGB
>> input
Am 03.10.24 um 15:26 schrieb Krzysztof Kozlowski:
On 03/10/2024 13:56, Wadim Egorov wrote:
Am 03.10.24 um 12:03 schrieb Krzysztof Kozlowski:
On 03/10/2024 10:20, Wadim Egorov wrote:
The SI9022 HDMI transmitter can be configured with 16, 18, or 24 input
data lines. This commit introduces t
Hi Linus,
Weekly fixes, xe and amdgpu lead the way, with panthor, and few core
components getting various fixes. Nothing seems too out of the
ordinary.
Regards,
Dave.
drm-fixes-2024-10-04:
drm fixes for 6.12-rc2
atomic:
- Use correct type when reading damage rectangles
display:
- Fix kernel do
The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'clocks' property:
display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
To resolve this issue, the constraints for 'clocks' and
other properties within the subschema will be reinforced.
Hi,
This patch contains an incorrect compatible name; please excuse the
oversight and discard this patch.
Sincerely,
Moudy Ho
On Fri, 2024-10-04 at 10:24 +0800, Moudy Ho wrote:
> The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
> to an excessively long 'clocks' property:
>
The display node in mt8195.dtsi was triggering a CHECK_DTBS error due
to an excessively long 'clocks' property:
display@14f06000: clocks: [[31, 14], [31, 43], [31, 44]] is too long
To resolve this issue, the constraints for 'clocks' and
other properties within the subschemas will be reinforced.
Hi all,
Today's linux-next merge of the drm-xe tree got a conflict in:
drivers/gpu/drm/xe/xe_guc_submit.c
between commit:
9286a191abe2 ("drm/xe: Drop GuC submit_wq pool")
from the drm-misc-fixes tree and commit:
861108666cc0 ("drm/xe: fix UAF around queue destruction")
from the drm-xe
The patch is to solve null dereference in 'aux.dev', which is
introduced in recent radeon rework. By having 'late_register',
the connector should be registered after 'drm_dev_register'
automatically, where in before it is the opposite.
Fixes: 90985660ba48 ("drm/radeon: remove load callback from km
On Thu, 03 Oct 2024 10:14:18 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, 03 Oct 2024 10:14:22 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, Oct 03, 2024 at 10:14:19AM +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of
On Thu, 03 Oct 2024 10:14:21 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
On Thu, 03 Oct 2024 10:14:20 +0200, Krzysztof Kozlowski wrote:
> Split of the bindings was artificial and not helping - we end up with
> multiple binding files for very similar devices thus increasing the
> chances of using different order of reg and clocks entries.
>
> Unify DPU bindings of SC7
Under `CONFIG_DRM_PANIC_SCREEN_QR_CODE=y`, zlib is used:
ld.lld: error: undefined symbol: zlib_deflate_workspacesize
>>> referenced by drm_panic.c
>>> drivers/gpu/drm/drm_panic.o:(drm_panic_qr_init) in
archive vmlinux.a
Thus select `CONFIG_ZLIB_DEFLATE`.
Fixes: cb5164a
Fri, Sep 06, 2024 at 01:01:29PM +0200, Daniel Gomez kirjoitti:
> The uuid_t struct defined in sys/types.h on macOS hosts conflicts with
> the one defined in file2alias, resulting in the typedef redefinition
> error below. To resolve this conflict, define the _UUID_T and
> __GETHOSTUUID_ in file2ali
Op 06-09-2024 om 09:52 schreef Thomas Zimmermann:
Store the lcd device in struct fb_info.lcd_dev. The lcd subsystem can
now detect the lcd's fbdev device from this field.
This makes the implementation of check_fb in clps711x_lcd_ops obsolete.
Remove it.
Signed-off-by: Thomas Zimmermann
Reviewe
On 9/17/24 2:08 PM, Colin Ian King wrote:
The mutex field has two following semicolons, replace this with just
one semicolon.
Signed-off-by: Colin Ian King
Applied to drm-misc-fixes, thanks!
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/gsp.h | 2 +-
1 file changed, 1 insertion(+), 1 d
Applied. Thanks!
On Thu, Oct 3, 2024 at 6:53 AM Sundararaju, Sathishkumar
wrote:
>
>
> The patch is Reviewed-by: Sathishkumar S
>
> Regards,
> Sathish
>
>
> On 10/3/2024 3:56 PM, Advait Dhamorikar wrote:
> > Fix shift-count-overflow in JPEG instance
> > multiplication. The expression's value ma
u16 crtc_width = crtc_state->base.crtc->mode.hdisplay;
> + u16 crtc_height = crtc_state->base.mode.vdisplay;
> + u16 crtc_width = crtc_state->base.mode.hdisplay;
> struct vkms_writeback_job *active_wb;
> struct vkms_frame_info *wb_frame_info;
> u32 wb_format = fb->format->format;
>
> ---
> base-commit: cbc1e8696fbea0010a73bf93534c712f9ad177db
> change-id: 20241003-remove-legacy-a2683a7bbcd5
>
> Best regards,
> --
> Louis Chauvet
--
Ville Syrjälä
Intel
Hi,
On Thu, Sep 26, 2024 at 2:29 AM Pin-yen Lin wrote:
>
> The bridge might miss the display change events when it's powered off.
> This happens when a user changes the external monitor when the system
> is suspended and the embedded controller doesn't not wake AP up.
>
> It's also observed that
Hi,
On Thu, Sep 26, 2024 at 10:15 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Sep 26, 2024 at 2:29 AM Pin-yen Lin wrote:
> >
> > The bridge might miss the display change events when it's powered off.
> > This happens when a user changes the external monitor when the system
> > is suspended and t
On Thu, 2024-10-03 at 10:33 +0200, Louis Chauvet wrote:
> Hi Lyude,
>
> Le 30/09/24 - 19:09, Lyude Paul a écrit :
> > This adds some very basic rust bindings for fourcc. We only have a single
> > format code added for the moment, but this is enough to get a driver
> > registered.
> >
> > TODO:
>
On 2024-08-27 13:49, Louis Chauvet wrote:
> Le 19/08/24 - 16:56, Harry Wentland a écrit :
>> This is an RFC set for a color pipeline API, along with implementations
>> in VKMS and amdgpu. It is tested with a set of IGT tests that can be
>> found at [1]. The IGT tests run a pixel-by-pixel compari
On Thu, 2024-10-03 at 10:30 +0200, Louis Chauvet wrote:
> Hi Lyude
>
> Thank you for all this amazing work!
>
> [...]
>
> > +impl Plane {
> > +/// Construct a new [`Plane`].
> > +///
> > +/// A driver may use this from their [`Kms::create_objects`] callback
> > in order to construct
A short description about the AMD color pipeline.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 122 +++---
1 file changed, 102 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c
b/drivers/gpu/drm/
From: Alex Hung
This adds support for a 3D LUT.
The color pipeline now consists of the following colorops:
1. 1D curve colorop
2. Multiplier
3. 3x4 CTM
4. 1D curve colorop
5. 1D LUT
6. 3D LUT
7. 1D curve colorop
8. 1D LUT
Signed-off-by: Alex Hung
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.
From: Alex Hung
Signed-off-by: Alex Hung
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_plane.c
index 22ff9a31b592..1bfb
From: Alex Hung
This adds support for a multiplier. This multiplier is
programmed via the HDR Multiplier in DCN.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-multiply_125
kms_colorop --run plane-XR30-XR30-multiply_inv_125
The color pipeline now consists of th
From: Alex Hung
It is to be used to enable HDR by allowing userpace to create and pass
3D LUTs to kernel and hardware.
1. new drm_colorop_type: DRM_COLOROP_3D_LUT.
2. 3D LUT modes define hardware capabilities to userspace applications.
3. mode index points to current 3D LUT mode in lut_3d_modes.
Not all HW will be able to do bypass on all color
operations. Introduce an 'allow_bypass' boolean for
all colorop init functions and only create the BYPASS
property when it's true.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 22 +---
drivers/gpu/drm/drm_
From: Alex Hung
Swap the order of matrix and multiplier as designed in hardware.
Signed-off-by: Alex Hung
---
.../amd/display/amdgpu_dm/amdgpu_dm_color.c | 22 ++---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 32 +--
2 files changed, 27 insertions(+), 27 deletion
We want to make sure userspace is aware of the 1D LUT
interpolation. While linear interpolation is common it
might not be supported on all HW. Give driver implementers
a way to specify their interpolation.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_colorop.c | 6 ++--
From: Alex Hung
This introduces a new drm_colorop_type: DRM_COLOROP_MULTIPLIER.
It's a simple multiplier to all pixel values. The value is
specified via a S31.32 fixed point provided via the
"MULTIPLIER" property.
Signed-off-by: Alex Hung
---
drivers/gpu/drm/drm_atomic.c | 3 +++
driver
From: Alex Hung
Expose one 1D curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program HW to perform
the sRGB transform when the colorop is not in bypass.
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf
The color pipeline now consists
From: Alex Hung
This adds support for a 3x4 color transformation matrix.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-ctm_3x4_50_desat
kms_colorop --run plane-XR30-XR30-ctm_3x4_overdrive
kms_colorop --run plane-XR30-XR30-ctm_3x4_oversaturate
kms_colorop --run
From: Alex Hung
We've previously introduced DRM_COLOROP_1D_CURVE for
pre-defined 1D curves. But we also have HW that supports
custom curves and userspace needs the ability to pass
custom curves, aka LUTs.
This patch introduces a new colorop type, called
DRM_COLOROP_1D_LUT that provides a SIZE pr
This patchset enables support for the PQ_125 EOTF and its inverse
on all existing plane 1D curve colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this patchset the following IGT subtests are passing:
kms_colorop --run plane-XR30-XR30-pq_125_eotf
kms_colorop --run plane-XR30-XR30-pq_125_inv_
The BT.709 and BT.2020 OETFs are the same, the only difference
being that the BT.2020 variant is defined with more precision
for 10 and 12-bit per color encodings.
Both are used as encoding functions for video content, and are
therefore defined as OETF (opto-electronic transfer function)
instead o
From: Alex Hung
This patch adds colorops for custom 1D LUTs in the SHAPER and
BLND HW blocks.
With this change the following IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf_lut-srgb_eotf_lut
The color pipeline now consists of t
When the plane_color_pipeline bit is set we should ignore
deprecated properties, such as COLOR_RANGE and COLOR_ENCODING.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_
This adds support for the BT.709/BT.2020 transfer functions
on all current 1D curve plane colorops, i.e., on DEGAM, SHAPER,
and BLND blocks.
With this change the following IGT subtests pass:
kms_colorop --run plane-XR30-XR30-bt2020_inv_oetf
kms_colorop --run plane-XR30-XR30-bt2020_oetf
Signed-off
This patch introduces a VKMS color pipeline that includes two
drm_colorops for named transfer functions. For now the only ones
supported are sRGB EOTF, sRGB Inverse EOTF, and a Linear TF.
We will expand this in the future but I don't want to do so
without accompanying IGT tests.
We introduce a new
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_test.c | 38 +++-
drivers/gpu/drm/vkms/vkms_composer.c | 15 ++--
drivers/gpu/drm/vkms/vkms_composer.h | 13 +++
3 files changed, 53 insertions(+), 13 deletions(-)
diff --git a/drivers
From: Alex Hung
Expose a 2nd curve colorop with support for
DRM_COLOROP_1D_CURVE_SRGB_INV_EOTF and program HW to
perform the sRGB Inverse EOTF on the shaper block
when the colorop is not in bypass.
With this change the follow IGT tests pass:
kms_colorop --run plane-XR30-XR30-srgb_inv_eotf
kms_co
The PQ function defines a mapping of code values to nits (cd/m^2).
The max code value maps to 10,000 nits.
Windows DWM's canonical composition color space (CCCS) defaults
to composing SDR contents to 80 nits and uses a float value of
1.0 to represent this. For this reason AMD HW hard-codes a PQ
f
From: Alex Hung
Expose a 3rd 1D curve colorop, with support for
DRM_COLOROP_1D_CURVE_SRGB_EOTF and program the BLND block
to perform the sRGB transform when the colorop is not in
bypass
With this change the following IGT test passes:
kms_colorop --run plane-XR30-XR30-srgb_eotf-srgb_inv_eotf-srgb
Certain operations require us to preserve values below 0.0 and
above 1.0 (0x0 and 0x respectively in 16 bpc unorm). One
such operation is a BT709 encoding operation followed by its
decoding operation, or the reverse.
We'll use s32 values as intermediate in and outputs of our
color operations,
A whole slew of tests for CTM handling that greatly helped in
debugging the CTM code. The extent of tests might seem a bit
silly but they're fast and might someday help save someone
else's day when debugging this.
Signed-off-by: Harry Wentland
---
v6:
- update reference values since we're now r
From: Alex Hung
Create a new macro for_each_new_colorop_in_state to access new
drm_colorop_state updated from uapi.
Signed-off-by: Alex Hung
---
include/drm/drm_atomic.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.
Add the default Bypass pipeline and ensure it passes the
kms_colorop test plane-XR30-XR30-bypass.
Signed-off-by: Harry Wentland
---
.../amd/display/amdgpu_dm/amdgpu_dm_plane.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_
Drivers will need to know whether an atomic check/commit
originated from a client with DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
so they can ignore deprecated properties, like COLOR_ENCODING
and COLOR_RANGE.
Pass the plane_color_pipeline bit to drm_atomic_state.
Signed-off-by: Harry Wentland
---
v5:
Debugging LUT math is much easier when we can unit test
it. Add kunit functionality to VKMS and add tests for
- get_lut_index
- lerp_u16
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
---
v6:
- Eliminate need to include test as .c file (Louis Chauvet)
v5:
- Bring back static for lerp_u16 a
While working on the CTM implementation of VKMS I had to ascertain
myself of a few assumptions. One of those is whether drm_fixed.h
treats its numbers using signed-magnitude or twos-complement. It is
twos-complement.
In order to make someone else's day easier I am adding the
drm_test_int2fixp test
We add two 3x4 matrices into the VKMS color pipeline. The reason
we're adding matrices is so that we can test that application
of a matrix and its inverse yields an output equal to the input
image.
One complication with the matrix implementation has to do with
the fact that the matrix entries are
This type is used to support a 3x4 matrix in colorops. A 3x4
matrix uses the last column as a "bias" column. Some HW exposes
support for 3x4. The calculation looks like:
out matrixin
|R| |0 1 2 3 | | R |
|G| = |4 5 6 7 | x | G |
|B| |8 9 10 11| | B |
We want to be able to bypass each colorop at all times.
Introduce a new BYPASS boolean property for this.
Signed-off-by: Harry Wentland
---
v6:
- clarify that bypass is only valid if BYPASS prop exists (Louis Chauvet)
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm/drm_colorop.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 44c5b5dd8b33..0f4eba51ee4b 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b
Signed-off-by: Harry Wentland
---
v5:
- Drop unused header definitions
v3:
- Read NEXT ID from drm_colorop's next pointer
drivers/gpu/drm/drm_atomic.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 12e787e73c63..35136987d
We're adding a new enum COLOR PIPELINE property. This
property will have entries for each COLOR PIPELINE by
referencing the DRM object ID of the first drm_colorop
of the pipeline. 0 disables the entire COLOR PIPELINE.
Userspace can use this to discover the available color
pipelines, as well as set
With the introduction of the pre-blending color pipeline we
can no longer have color operations that don't have a clear
position in the color pipeline. We deprecate all existing
plane properties. For upstream drivers those are:
- COLOR_ENCODING
- COLOR_RANGE
Drivers are expected to ignore these
CTM values are defined as signed-magnitude values. Add
a helper that converts from CTM signed-magnitude fixed
point value to the twos-complement value used by
drm_fixed.
Signed-off-by: Harry Wentland
---
include/drm/drm_fixed.h | 18 ++
1 file changed, 18 insertions(+)
diff --gi
We'll construct color pipelines out of drm_colorop by
chaining them via the NEXT pointer. NEXT will point to
the next drm_colorop in the pipeline, or by 0 if we're
at the end of the pipeline.
Signed-off-by: Harry Wentland
---
v5:
- move next comment here from Add 3x4 CTM patch (Sebastian)
- Ad
This is an RFC set for a color pipeline API, along with implementations
in VKMS and amdgpu. It is tested with a set of IGT tests that can be
found at [1]. The IGT tests run a pixel-by-pixel comparison with an
allowable delta variation as the goal for these transformations is
perceptual correctness,
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Co-developed-by: Alex Hung
---
v5:
- Add drm_get_colorop_curve_1d_type_name in header
- Add drm_colorop_init
- Set default curve
- Add kernel docs
v4:
- Use drm_colorop_curve_1d_type_enum_list to get name (Pekka)
- Create separate in
This patches introduces a new drm_colorop mode object. This
object represents color transformations and can be used to
define color pipelines.
We also introduce the drm_colorop_state here, as well as
various helpers and state tracking bits.
Signed-off-by: Harry Wentland
---
v6:
- Comment that
Signed-off-by: Harry Wentland
---
v5:
- Don't require BYPASS to succeed (Sebastian)
- use DATA for 1D and 3D LUT types (Sebastian)
- update 3DLUT ops to use 3DLUT_MODES and 3DLUT_MODE_INDEX
- Add section on drm_colorop extensibility
- Add color_pipeline.rst to RFC toc tree
v4:
- Drop IOCTL
Signed-off-by: Harry Wentland
---
v5:
- Drop TODO
Documentation/gpu/drm-kms.rst | 15 +++
drivers/gpu/drm/drm_colorop.c | 31 +++
2 files changed, 46 insertions(+)
diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index abfe2207
fixp2int always rounds down, fixp2int_ceil rounds up. We need
the new fixp2int_round.
Signed-off-by: Harry Wentland
Reviewed-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/dri
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
For now we're only introducing an enumerated 1D LUT type to
illustrate the concept.
Signed-off-by: Harry Wentland
---
v6:
- fix doc typo (Alex Hung)
v5:
- Add drm_
On 2024-09-10 16:37, Alex Goins wrote:
> Hi Harry,
>
> Thanks for this. I just want to remind about a few things that would be
> required
> for NVIDIA hardware, as discussed at the Display Next Hackfest -- fully
> understand that they aren't currently included in this series because they
> aren't
Hi shiyongbang,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.12-rc1 next-20241003]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
Yes, it's not great, but I think it's better than having the length in two
places.
Agreed. I'll respin. :)
Thanks
--
Gustavo
On 10/3/24 8:44 PM, Gustavo A. R. Silva wrote:
On 03/10/24 12:36, Danilo Krummrich wrote:
On 9/13/24 12:23 PM, Danilo Krummrich wrote:
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you might want
On 03/10/24 12:36, Danilo Krummrich wrote:
On 9/13/24 12:23 PM, Danilo Krummrich wrote:
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you might want to send a v2 based on Kees'
comments?
Do you
On 9/13/24 12:23 PM, Danilo Krummrich wrote:
Hi,
On 9/13/24 10:09 AM, Gustavo A. R. Silva wrote:
Hi all,
Friendly ping: who can take this, please? 🙂
Usually, that's me. But I thought you might want to send a v2 based on Kees'
comments?
Do you plan to follow up on this? I'd prefer if we cou
On 9/27/24 9:33 PM, Nicolas Dufresne wrote:
Le mercredi 25 septembre 2024 à 22:45 +0200, Marek Vasut a écrit :
On 9/25/24 7:58 PM, Nicolas Dufresne wrote:
[...]
+static irqreturn_t ipu_mem2mem_vdic_nfb4eof_interrupt(int irq, void *dev_id)
+{
+ struct ipu_mem2mem_vdic_priv *priv = d
On 9/26/24 1:14 PM, Philipp Zabel wrote:
Hi,
Hi,
On Mi, 2024-09-25 at 22:14 +0200, Marek Vasut wrote:
The userspace could distribute the frames between the two devices in an
alternating manner, can it not ?
This doesn't help with latency, or when converting a single large
frame.
For the d
On 9/26/24 1:16 PM, Philipp Zabel wrote:
On Mi, 2024-09-25 at 22:45 +0200, Marek Vasut wrote:
[...]
The driver is not taking ownership of prev_buf, only curr_buf is guaranteed to
exist until v4l2_m2m_job_finish() is called. Usespace could streamoff, allocate
new buffers, and then an old freed bu
On 6/3/24 11:15 AM, egyszer...@freemail.hu wrote:
From: Benjamin Szőke
The goal is to clean-up Linux repository from AUX file names, because
the use of such file names is prohibited on other operating systems
such as Windows, so the Linux repository cannot be cloned and
edited on them.
Signed-
From: Ville Syrjälä
Rename the 'new_crtc' variable to just 'crtc' in
drm_client_firmware_config(). We don't call any of the other
stuff in here new or old so this feels out of place.
v2: Rebase
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_client_modeset.c | 12 ++--
1 file cha
From: Ville Syrjälä
crtc->mode is legacy junk and shouldn't really be used with
atomic drivers.
Most (all?) atomic drivers do end up still calling
drm_atomic_helper_update_legacy_modeset_state() at some
point, so crtc->mode does still get populated, and this
does work for now. But now that the m
From: Ville Syrjälä
drm_client_firmware_config() is currently picking up the current
mode of the crtc via the legacy crtc->mode, which is not supposed
to be used by atomic drivers at all. We can't simply switch over
to the proper crtc->state->mode because we drop the crtc->mutex
(which protects c
From: Markus Elfring
Date: Thu, 3 Oct 2024 19:56:29 +0200
An of_node_put(cmm) call was immediately used after a null pointer check
for an of_find_device_by_node() call in this function implementation.
Thus call such a function instead directly before the check.
This issue was transformed by usin
Hi,
On 3-Oct-24 5:54 PM, Alex Deucher wrote:
> + Hans
>
> On Thu, Oct 3, 2024 at 2:33 AM Wu Hoi Pok wrote:
>>
>> This is a fix patch not tested yet,
>> for a bug I introduce in previous rework of radeon driver.
>> The bug is a null dereference in 'aux.dev', which is the
>> 'device' not registere
kstrdup_const() and kfree_const() can be confusing in code built as a
module. In such a case, it does not do what one could expect from the name
of the functions.
The code is not wrong by itself, but in such a case, it is equivalent to
kstrdup() and kfree().
So, keep thinks simple and straightfor
Hi Sumit,
On Thu, 3 Oct 2024 at 12:27, Sumit Semwal wrote:
>
> Hello Pintu,
>
> On Tue, 1 Oct 2024 at 23:16, Pintu Kumar wrote:
> >
> > Symbolic permissions are not preferred, instead use the octal.
> > Also, fix other warnings/errors as well for cleanup.
> >
> > WARNING: Block comments use * on
On 10/3/24 00:17, Jason-JH Lin (林睿祥) wrote:
Jason:
That is a lot of information, and quite above my head! Thank you
though.
I should note that the log items I sent you are from the "good"
kernel -
6.11 with the commit reverted. Here is a much longer set of logs:
https://termbin.com/co6v
I've
When register_framebuffer failed, it jumps out_fb_dealloc_cmap without
calling unregister_framebuffer, which may cause potential memory leak.
Signed-off-by: clingfei
---
drivers/video/fbdev/clps711x-fb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/cl
On 02/10/2024 15:04, Thomas Zimmermann wrote:
With the next DRM client coming soon (drm_log) and most of DRM's
fbdev emulation consolidated in a few places, it's time to provide
a single place for the clients.
The new module drm_client_lib.ko stores most of the in-kernel client
code. It is desig
On 3.10.2024 5:01 AM, Bjorn Andersson wrote:
> Support for per-process page tables requires the SMMU aparture to be
> setup such that the GPU can make updates with the SMMU. On some targets
> this is done statically in firmware, on others it's expected to be
> requested in runtime by the driver, th
On 3.10.2024 5:01 AM, Bjorn Andersson wrote:
> The QCOM_SCM_SVC_MP service provides QCOM_SCM_MP_CP_SMMU_APERTURE_ID,
> which is used to trigger the mapping of register banks into the SMMU
> context for per-processes page tables to function (in case this isn't
> statically setup by firmware).
>
> T
On Thu, Oct 03, 2024 at 02:33:00PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_client_firmware_config() is currently picking up the current
> mode of the crtc via the legacy crtc->mode, which is not supposed
> to be used by atomic drivers at all. We can't simply switch over
> to the
On Fri, Oct 04, 2024 at 12:12:36AM +0800, clingfei wrote:
> When register_framebuffer failed, it jumps out_fb_dealloc_cmap without
> calling unregister_framebuffer, which may cause potential memory leak.
This looks completely wrong. If register_framebuffer() fails, then the
work that register_fram
Add documentation about the preemption feature supported by the msm
driver.
Signed-off-by: Antonino Maniscalco
---
Documentation/gpu/msm-preemption.rst | 99
1 file changed, 99 insertions(+)
diff --git a/Documentation/gpu/msm-preemption.rst
b/Documentation/
Initialize with 4 rings to enable preemption.
Add the "preemption_enabled" module parameter to override this.
Tested-by: Rob Clark
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Neil Armstrong # on SM8450-HDK
Signed-off-by: Antonino Maniscalco
Some userspace changes are necessary so add a flag for userspace to
advertise support for preemption when creating the submitqueue.
When this flag is not set preemption will not be allowed in the middle
of the submitted IBs therefore mantaining compatibility with older
userspace.
The flag is reje
Add trace points corresponding to preemption being triggered and being
completed for latency measurement purposes.
Reviewed-by: Akhil P Oommen
Tested-by: Rob Clark
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Armstrong # on SM8550-QRD
Tested-by: Neil Armstrong # on SM8450-HDK
Sig
Use the postamble to reset perf counters when switching between rings,
except when sysprof is enabled, analogously to how they are reset
between submissions when switching pagetables.
Reviewed-by: Akhil P Oommen
Tested-by: Rob Clark
Tested-by: Neil Armstrong # on SM8650-QRD
Tested-by: Neil Arms
1 - 100 of 227 matches
Mail list logo
