On Mon, Feb 26, 2024 at 04:21:23PM +0100, 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
Applied to drm-next
Maxime
signature.asc
Description: PGP signature
On Mon, Feb 26, 2024 at 04:16:31PM +0100, Maxime Ripard wrote:
> Start the big migration with drm.git.
>
> Existing remotes need to be adjusted with
>
> git remote set-url drm ssh://g...@gitlab.freedesktop.org:drm/kernel.git
>
> or
>
> git remote set-url drm
Hi
Am 27.02.24 um 08:06 schrieb Tony Lindgren:
* Tony Lindgren [240226 13:26]:
* Thomas Zimmermann [240226 09:10]:
Am 26.02.24 um 10:01 schrieb Tomi Valkeinen:
On 26/02/2024 10:26, Tomi Valkeinen wrote:
How is it broken? I don't usually use the console (or fbdev) but
enabling it now, it
Hi Adam,
On Tue, Feb 27, 2024 at 4:46 AM Adam Ford wrote:
> Update the binding to add support for various Renesas SoC's with PowerVR
> Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> the table to indicate such like what was done for the ti,am62-gpu.
>
>
Hi, Hsin-yi:
On Fri, 2024-02-23 at 13:23 -0800, Hsin-Yi Wang wrote:
External email : Please do not click links or open attachments until you have
verified the sender or the content.
It's possible that mtk_crtc->event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is
On Sun, 18 Feb 2024 22:41:14 +0100, Boris Brezillon wrote:
> Hello,
>
> This is the 5th version of the kernel driver for Mali CSF-based GPUs,
> and, unless someone has good reasons to block the merging of this
> driver, I expect it to be the last one (the gallium driver is now
>
> [ ... ]
* Tony Lindgren [240226 13:26]:
> * Thomas Zimmermann [240226 09:10]:
> > Am 26.02.24 um 10:01 schrieb Tomi Valkeinen:
> > > On 26/02/2024 10:26, Tomi Valkeinen wrote:
> > > > How is it broken? I don't usually use the console (or fbdev) but
> > > > enabling it now, it seems to work fine for me,
Hi Oak,
Am 23.02.24 um 21:12 schrieb Zeng, Oak:
Hi Christian,
I go back this old email to ask a question.
sorry totally missed that one.
Quote from your email:
“Those ranges can then be used to implement the SVM feature required
for higher level APIs and not something you need at the
DPSUB in bridge mode supports multiple input media bus formats.
Announce the list of supported input media bus formats via
drm_bridge.atomic_get_input_bus_fmts callback.
Signed-off-by: Anatoliy Klymenko
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 37 +
Set layer mode of operation (live or dma-based) during layer creation.
Each DPSUB layer mode of operation is defined by corresponding DT node port
connection, so it is possible to assign it during layer object creation.
Previously it was set in layer enable functions, although it is too late
as
Program live video input format according to selected media bus format.
In the bridge mode of operation, DPSUB is connected to FPGA CRTC which
almost certainly supports a single media bus format as its output. Expect
this to be delivered via the new bridge atomic state. Program DPSUB
registers
Add select_output_bus_format to CRTC atomic helpers callbacks. This
callback Will allow CRTC to participate in media bus format negotiation
over connected DRM bridge chain and impose CRTC-specific restrictions.
A good example is CRTC implemented as FPGA soft IP. This kind of CRTC will
most
: bfa4437fd3938ae2e186e7664b2db65bb8775670
change-id: 20240226-dp-live-fmt-6415773b5a68
Best regards,
--
Anatoliy Klymenko
The GPU on the R-Car H3 is a Rogue GX6650 which uses firmware
rogue_4.46.6.61_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by:
The GPU on the R-Car M3-W is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
The GPU on the R-Car M3-W+ is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
The GPU on the RZ/G2H is a Rogue GX6650 which uses firmware
rogue_4.46.6.62_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.46.6.62_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
Signed-off-by:
Update the binding to add support for various Renesas SoC's with PowerVR
Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
the table to indicate such like what was done for the ti,am62-gpu.
Signed-off-by: Adam Ford
diff --git
Renesas has used a few variants of the Power VR GPU in their R-Car
and RZ/G2 families. While there is still some work to do at the Mesa
level, adding these device tree nodes allows the Power VR driver
to enumerate and load the respective firmware located:
The GPU on the RZ/G2M is a Rogue GX6250 which uses firmware
rogue_4.45.2.58_v1.fw available from Imagination.
When enumerated, it appears as:
powervr fd00.gpu: [drm] loaded firmware powervr/rogue_4.45.2.58_v1.fw
powervr fd00.gpu: [drm] FW version v1.0 (build 6513336 OS)
On Mon, Feb 26, 2024 at 7:49 PM Dmitry Baryshkov
wrote:
> Could you please specify how you tried to compile the code? I can see
> warnings from headrgen2, but I'm really puzzled by the errors from the
> MSM driver itself.
I applied this patch set onto v6.8-rc6.
On Mon, Feb 26, 2024 at 11:11 AM Dmitry Baryshkov
wrote:
>
> Move non-GPU xml.h files into the ./registers subdir and add the
> _shipped suffix. The GPU files are left intact for now, since they
> require processing via a gen_headers.py, while display headers are
> regenerated using headergen2
>
On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
>
> It's found that some panels have variants that they share the same panel id
> although their EDID and names are different. One of the variants requires
> using overridden modes to resolve glitching issue as described in commit
> 70e0d5550f5c
On Tue, 27 Feb 2024 at 03:10, Hsin-Yi Wang wrote:
>
> On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
> wrote:
> >
> > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> > >
> > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > > auo_b116xa3_mode""). It's found
On Tue, 27 Feb 2024 at 03:00, Doug Anderson wrote:
>
> Hi,
>
> On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
> wrote:
> >
> > On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> > >
> > > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > > auo_b116xa3_mode""). It's
Hi David,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linux/master mkl-can-next/testing kdave/for-next
akpm-mm/mm-nonmm-unstable axboe-block/for-next linus/master v6.8-rc6
next-20240226]
[cannot apply
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
wrote:
>
> On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> >
> > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > product id. One of them
On 27/2/24 02:23, Hans de Goede wrote:
> Hi All,
>
> On 2/2/24 09:53, Daniel van Vugt wrote:
>> Until now, deferred console takeover only meant defer until there is
>> output. But that risks stepping on the toes of userspace splash screens,
>> as console messages may appear before the splash
On 2/25/24 22:55, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20240223:
>
on powerpc32 or i386:
../drivers/gpu/drm/xe/xe_ggtt.c: In function 'xe_ggtt_set_pte':
../drivers/gpu/drm/xe/xe_ggtt.c:78:9: error: implicit declaration of function
'writeq'; did you mean 'writel'?
Hi,
On Mon, Feb 26, 2024 at 4:37 PM Dmitry Baryshkov
wrote:
>
> On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
> >
> > This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> > auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> > product id. One of
syzbot has found a reproducer for the following issue on:
HEAD commit:d206a76d7d27 Linux 6.8-rc6
git tree: upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=12eea10618
kernel config: https://syzkaller.appspot.com/x/.config?x=fad652894fc96962
dashboard link:
On Sat, 24 Feb 2024 at 00:40, Hsin-Yi Wang wrote:
>
> This series is a follow up for 1a5e81de180e ("Revert "drm/panel-edp: Add
> auo_b116xa3_mode""). It's found that 2 different AUO panels use the same
> product id. One of them requires an overridden mode, while the other should
> use the mode
Hi,
On Mon, Feb 26, 2024 at 2:39 PM Hsin-Yi Wang wrote:
>
> On Mon, Feb 26, 2024 at 2:29 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
> > >
> > > It's found that some panels have variants that they share the same panel
> > > id
> > > although
On 2/26/2024 05:25, Nilawar, Badal wrote:
Hi John,
On 04-01-2024 23:35, john.c.harri...@intel.com wrote:
From: John Harrison
Use the new w/a KLV support to enable a MTL w/a. Note, this w/a is a
super-set of Wa_16019325821, so requires turning that one as well as
setting the new flag for
> +static struct sk_buff *am65_cpsw_alloc_skb(struct net_device *ndev, unsigned
> int len)
> +{
> + struct page *page;
> + struct sk_buff *skb;
> +
> + page = dev_alloc_pages(0);
You are likely to get better performance if you use the page_pool.
When FEC added XDP support, the first
Hi Rob
> This is resend v2 of replace of_graph_get_next_endpoint()
>
> We should get rid of or minimize of_graph_get_next_endpoint() in
> its current form. In general, drivers should be asking for a specific
> port number because their function is fixed in the binding.
>
>
On 2/26/2024 2:34 PM, Dmitry Baryshkov wrote:
The function dp_wait_hpd_asserted() uses pm_runtime_get_sync() and
doesn't care about the return value. Potentially this can lead to
unclocked access if for some reason resuming of the DP controller fails.
Change the function to use
On Mon, Feb 26, 2024 at 2:29 PM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
> >
> > It's found that some panels have variants that they share the same panel id
> > although their EDID and names are different. One of the variants requires
> > using
The function dp_wait_hpd_asserted() uses pm_runtime_get_sync() and
doesn't care about the return value. Potentially this can lead to
unclocked access if for some reason resuming of the DP controller fails.
Change the function to use pm_runtime_resume_and_get() and return an
error if resume fails.
Hi,
On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
>
> It's found that some panels have variants that they share the same panel id
> although their EDID and names are different. One of the variants requires
> using overridden modes to resolve glitching issue as described in commit
>
Hi,
On Fri, Feb 23, 2024 at 2:40 PM Hsin-Yi Wang wrote:
>
> @@ -2770,58 +2770,63 @@ static u32 edid_extract_panel_id(const struct edid
> *edid)
> }
>
> /**
> - * drm_edid_get_panel_id - Get a panel's ID through DDC
> - * @adapter: I2C adapter to use for DDC
> + * drm_edid_get_panel_id - Get a
On Fri, Feb 16, 2024 at 9:30 AM Doug Anderson wrote:
>
> Hi,
>
> On Fri, Feb 16, 2024 at 12:21 AM Javier Martinez Canillas
> wrote:
> >
> > > The kernel tree we landed on was the v5.15 tree, which is currently
> > > serving all Qualcomm sc7180-based Chromebooks, all Mediatek 8173
> > >
Hi Daniel,
On Mon, 26 Feb 2024 15:50:10 +0100 Daniel Vetter wrote:
>
> > git://git.freedesktop.org/git/drm/drm.git#topic/drm-ci
>
> This one you can drop right away, it's all merged, apologies for not
> telling you earlier.
Thanks, removed now.
--
Cheers,
Stephen Rothwell
On 2/23/2024 5:45 AM, Jérémie Dautheribes wrote:
Add support for Crystal Clear Technology CMT430B19N00 4.3" 480x272
TFT-LCD panel.
Signed-off-by: Jérémie Dautheribes
Hi Jérémie,
Reviewed-by: Jessica Zhang
Thanks,
Jessica Zhang
---
drivers/gpu/drm/panel/panel-simple.c | 29
On 2/22/2024 9:47 AM, Adam Green wrote:
On 22/02/2024 17:14, Jessica Zhang wrote:
Hi Adam,
Just wondering, why the change to 120 here?
Thanks,
Jessica Zhang
Hi,
The 120ms is taken from the datasheet specification for the controller
as maximum time it takes for the display to reset,
si_device_register_full(dev, host, );
if (IS_ERR(dsi)) {
---
base-commit: 2ae0a045e6814c8c1d676d6153c605a65746aa29
change-id: 20240226-anx7625-defer-log-no-dsi-host-c3f9ccbcb287
Best regards,
--
Nícolas F. R. A. Prado
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
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
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 +++
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
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
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
v4:
- Drop IOCTL docs since we dropped the IOCTLs (Pekka)
- Clarify reading and setting of COLOR_PIPELINE prop (Pekka)
- Add blurb about not requiring to reject a pipeline due to
incompatible ops, as long as op can be bypassed (Pekka)
- Dropped informational strings (such as input CSC) as
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 |
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
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
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
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
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
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
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
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
v4:
- Use drm_colorop_curve_1d_type_enum_list to get name (Pekka)
- Create separate init function for 1D curve
- Pass supported TFs into 1D curve init function
Signed-off-by: Harry Wentland
Signed-off-by: Alex Hung
Co-developed-by: Alex Hung
---
drivers/gpu/drm/drm_atomic_uapi.c | 18
v3:
- Read NEXT ID from drm_colorop's next pointer
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 1 +
include/drm/drm_colorop.h| 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index
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
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
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.
v4:
- Comment on origin of bt709_enc matrix (Pekka)
- Use full opaque alpha
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
---
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
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
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
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
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
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.
v4:
- Drop IOCTL definitions (Pekka)
- add missing
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
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,
The if/switch statement is bound to grow with more types and
subtypes. Pull this out into its own funcion to make things more
manageable and readable.
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/vkms_composer.c | 48
1 file changed, 28 insertions(+), 20
Unit testing this in VKMS shows that passing 0 into
this function returns -1, which is highly counter-
intuitive. Fix it by checking whether the input is
>= 0 instead of > 0.
Fixes: 64566b5e767f9 ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil")
Signed-off-by: Harry Wentland
Reviewed-by:
fixp2int always rounds down, fixp2int_ceil rounds up. We need
the new fixp2int_round.
Signed-off-by: Harry Wentland
---
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
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.
v4:
- Allow setting of NEXT property to NULL (Chaitanya Kumar Borah)
v3:
- Add next pointer to colorop
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 25 -
include/drm/drm_colorop.h| 5 +
2 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index b400e32c9d39..3645c36d63b3
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
v4:
- Use enum property for TYPE (Pekka)
v3:
- Make TYPE a range property
- Move enum drm_colorop_type to uapi header
- Fix drm_get_colorop_type_name description
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
---
drivers/gpu/drm/drm_atomic_uapi.c | 6 +-
drivers/gpu/drm/drm_colorop.c | 16
include/drm/drm_colorop.h | 20
This aligns with most other DRM drivers and will allow
us to add new VKMS config options without polluting
the DRM Kconfig.
v3:
- Change SPDX to GPL-2.0-only to match DRM KConfig
SPDX (Simon)
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
---
drivers/gpu/drm/Kconfig | 14
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
index fc73e48aa57c..e6ac01dee830
When the floor LUT index (drm_fixp2int(lut_index) is the last
index of the array the ceil LUT index will point to an entry
beyond the array. Make sure we guard against it and use the
value of the floor LUT index.
v3:
- Drop bits from commit description that didn't contribute
anything of value
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
v4:
- Test the critical points of the lerp function (Pekka)
v3:
- Use include way of testing static functions (Arthur)
Signed-off-by: Harry Wentland
Cc:
A value of 0x8000 and higher should round up, and
below should round down. VKMS Kunit tests for lerp_u16
showed that this is not the case. Fix it.
1 << (DRM_FIXED_POINT_HALF - 1) =
1 << 15 = 0x8000
This is not 0.5, but 0.0762939453125.
Instead of some smart math use a simple if/else to
This is an RFC set for a color pipeline API, along with a sample
implementation in VKMS. All the key API bits are here. VKMS now
supports two named transfer function colorops and two matrix
colorops. We have IGT tests that check all four of these colorops
with a pixel-by-pixel comparison that
"
+ sudo IGT_DEVICE="sys:/sys/devices/platform/vkms"
./build/benchmarks/kms_fb_stress
+
TODO
---
base-commit: eeb8e8d9f124f279e80ae679f4ba6e822ce4f95f
change-id: 20240226-bench-vkms-5b8b7aab255e
Best regards,
--
Arthur Grillo
Hi, Christian
On Fri, 2024-02-23 at 15:30 +0100, Christian König wrote:
> Am 06.02.24 um 13:56 schrieb Christian König:
> > Am 06.02.24 um 13:53 schrieb Thomas Hellström:
> > > Hi, Christian,
> > >
> > > On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
> > > > Previously we would never
Hello,
On Mon, Feb 26, 2024 at 6:29 PM Jernej Škrabec wrote:
>
> Dne ponedeljek, 26. februar 2024 ob 08:13:42 CET je Frank Oltmanns napisal(a):
> > It seems to me that all options for changing the GPU's rate in a stable
> > manner have been exhausted. There seems to be no common interpretation
>
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8552c902efe7ef670b6961fb8885b67961aeb629 Add linux-next specific
files for 20240226
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402261912.yaxzeprg-...@intel.com
Error
Hi All,
On 2/2/24 09:53, Daniel van Vugt wrote:
> Until now, deferred console takeover only meant defer until there is
> output. But that risks stepping on the toes of userspace splash screens,
> as console messages may appear before the splash screen. So check for the
> "splash" parameter (as
From: Markus Elfring
Date: Mon, 26 Feb 2024 18:46:38 +0100
The label “err” was used as a target for two statements despite of
the implementation detail that failure conditions could be handled better.
* Thus return directly after a call of the function “a6xx_gmu_get_mmio”
failed at the
On 2024-02-26 17:53, Christian König wrote:
> Am 26.02.24 um 17:50 schrieb Michel Dänzer:
>> On 2024-02-26 17:46, Michel Dänzer wrote:
>>> On 2024-02-26 17:34, Christian König wrote:
>>>
My question is why has it worked so far? I mean we are not doing this
since yesterday and the
Hello Simon,
Thank you for the review.
On 2/26/24 18:25, Simon Horman wrote:
On Fri, Feb 23, 2024 at 12:01:37PM +0100, Julien Panis wrote:
This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
Ethernet driver. The following features are implemented:
- NETDEV_XDP_ACT_BASIC (XDP_PASS,
On 26/02/2024 13:27, Paweł Anikiel wrote:
> On Mon, Feb 26, 2024 at 1:07 PM Krzysztof Kozlowski
> wrote:
>>
>> On 26/02/2024 12:09, Paweł Anikiel wrote:
>>> On Mon, Feb 26, 2024 at 10:15 AM Krzysztof Kozlowski
>>> wrote:
On 21/02/2024 17:02, Paweł Anikiel wrote:
> Add device nodes
Dne ponedeljek, 26. februar 2024 ob 08:13:42 CET je Frank Oltmanns napisal(a):
> Hi Jernej,
> hi Maxime,
> hi Ondřej,
>
> On 2024-02-19 at 10:41:19 +0100, Frank Oltmanns wrote:
> > Hi Ondřej,
> >
> > On 2024-02-11 at 20:25:29 +0100, Ondřej Jirman wrote:
> >> Hi Frank,
> >>
> >> On Sun, Feb 11,
On 26/02/2024 13:43, Paweł Anikiel wrote:
> + intel,max-stream-count:
> +$ref: /schemas/types.yaml#/definitions/uint32
> +description: Max stream count configuration parameter
> +
> + port:
> +$ref: /schemas/graph.yaml#/properties/port
> +description:
1 - 100 of 307 matches
Mail list logo
