Le 08/11/2023 à 20:37, Arnd Bergmann a écrit :
> On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote:
>> Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
>
>> powerpc has functions doing more or less the same, they are called
>> __c_kernel_clock_gettime() and alike with their prototypes siting
User-space sometimes needs to allocate scanout-capable memory for
GPU rendering purposes. On a vc4/v3d split render/display SoC, this
is achieved via DRM dumb buffers: the v3d user-space driver opens
the primary vc4 node, allocates a DRM dumb buffer there, exports it
as a DMA-BUF, imports it into
This is necessary to create DMA heaps in other modules
(e.g. graphics drivers).
Signed-off-by: Simon Ser
Cc: Sumit Semwal
Cc: Benjamin Gaignard
Cc: Brian Starkey
Cc: John Stultz
Cc: "T.J. Mercier"
---
drivers/dma-buf/dma-heap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Return an error value from dispc_softreset() so that the caller can
handle the errors.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
The probe function calls dispc_softreset() before runtime PM is enabled
and without enabling any of the DSS clocks. This happens to work by
luck, and we need to make sure the DSS HW is active and the fclk is
enabled.
To fix the above, add a new function, dispc_init_hw(), which does:
-
tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not,
returns immediately as there's no reason to do any register changes.
However, the code checks for 'crtc->state->enable', which does not
reflect the actual HW state. We should instead look at the
'crtc->state->active' flag.
This
At the moment the driver does not use DRM_PLANE_COMMIT_ACTIVE_ONLY, but
still checks for crtc->state->active in tidss_crtc_atomic_flush(), and
skips the flush if the crtc is not active.
The exact reason why DRM_PLANE_COMMIT_ACTIVE_ONLY is not used has been
lost in history.
While working on the TI BSP kernel, adding bootload splash screen
support, I noticed some issues with the driver and opportunities for
cleanups and improvements.
Tomi
Signed-off-by: Tomi Valkeinen
---
Changes in v2:
- Add missing pm_runtime_dont_use_autosuspend() in error path
- Add simple
The IRQ setup code is overly complex. All we really need to do is
initialize the related fields in struct tidss_device, and request the
IRQ.
We can drop all the HW accesses, as they are pointless: the driver will
set the IRQs correctly when it needs any of the IRQs, and at probe time
we have done
K2G display controller does not support soft reset, but we can do the
most important steps manually: mask the IRQs and disable the VPs.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git
K2G doesn't have softreset feature. Instead of having every caller of
dispc_softreset() check for K2G, move the check into dispc_softreset(),
and make dispc_softreset() return 0 in case of K2G.
Reviewed-by: Laurent Pinchart
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c
Use runtime PM autosuspend feature, with 1s timeout, to avoid
unnecessary suspend-resume cycles when, e.g. the userspace temporarily
turns off the crtcs when configuring the outputs.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 9 -
1 file changed, 8
We do a DSS reset in the middle of the dispc_init(). While that happens
to work now, we should really make sure that e..g the fclk, which is
acquired only later in the function, is enabled when doing a reset. This
will be handled in a later patch, but for now, let's move the
dispc_softreset() call
No need to initialize the ret to 0 in dispc_softreset().
Reviewed-by: Laurent Pinchart
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_dispc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync(), which
will handle error situations better. Also fix the return, as there
should be no reason for the current complex return.
Reviewed-by: Laurent Pinchart
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 4
Hi,
On 2023-11-07 19:41, Danilo Krummrich wrote:
> On 11/7/23 05:10, Luben Tuikov wrote:
>> Don't call drm_sched_select_entity() in drm_sched_run_job_queue(). In fact,
>> rename __drm_sched_run_job_queue() to just drm_sched_run_job_queue(), and let
>> it do just that, schedule the work item for
Hello,
On Wed, Nov 08, 2023 at 10:57:00PM +0100, Helge Deller wrote:
> On 11/8/23 22:52, Uwe Kleine-König wrote:
> > But info and so info->fix live longer than the probe function, don't
> > they?
>
> Yes, they do.
> But AFAICS info->fix contains a *copy* of the initial atmel_lcdfb_fix struct
>
On 2023-11-08 19:09, Danilo Krummrich wrote:
> On 11/8/23 06:46, Luben Tuikov wrote:
>> Hi,
>>
>> Could you please use my gmail address, the one one I'm responding from--I
>> don't want
>> to miss any DRM scheduler patches. BTW, the luben.tui...@amd.com email
>> should bounce
>> as
On Wed, Nov 8, 2023 at 2:56 AM Yunsheng Lin wrote:
>
> On 2023/11/8 5:56, Mina Almasry wrote:
> > On Tue, Nov 7, 2023 at 12:00 AM Yunsheng Lin wrote:
> >>
> >> On 2023/11/6 10:44, Mina Almasry wrote:
> >>> Overload the LSB of struct page* to indicate that it's a page_pool_iov.
> >>>
> >>>
On Tue, Nov 7, 2023 at 4:01 PM David Ahern wrote:
>
> On 11/7/23 4:55 PM, Mina Almasry wrote:
> > On Mon, Nov 6, 2023 at 4:03 PM Willem de Bruijn
> > wrote:
> >>
> >> On Mon, Nov 6, 2023 at 3:55 PM David Ahern wrote:
> >>>
> >>> On 11/6/23 4:32 PM, Stanislav Fomichev wrote:
> > The concise
On Wed, Nov 8, 2023 at 3:47 PM David Wei wrote:
>
> On 2023-11-05 18:44, Mina Almasry wrote:
> > Add a netdev_dmabuf_binding struct which represents the
> > dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> > rx queues on the netdevice. On the binding, the dma_buf_attach
>
On Tue, Nov 7, 2023 at 7:40 PM Yunsheng Lin wrote:
>
> On 2023/11/8 5:59, Mina Almasry wrote:
> > On Mon, Nov 6, 2023 at 11:46 PM Yunsheng Lin wrote:
> >>
> >> On 2023/11/6 10:44, Mina Almasry wrote:
> >>> +
> >>> +void __netdev_devmem_binding_free(struct netdev_dmabuf_binding *binding)
> >>> +{
> > On Mon, Nov 6, 2023 at 11:45 PM Yunsheng Lin wrote:
> >>
> >> On 2023/11/6 10:44, Mina Almasry wrote:
> >>> +
> >>> +void netdev_free_devmem(struct page_pool_iov *ppiov)
> >>> +{
> >>> + struct netdev_dmabuf_binding *binding =
> >>> page_pool_iov_binding(ppiov);
> >>> +
> >>> +
On 2023-11-07 15:03, Mina Almasry wrote:
> On Tue, Nov 7, 2023 at 2:55 PM David Ahern wrote:
>>
>> On 11/7/23 3:10 PM, Mina Almasry wrote:
>>> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
On 11/5/23 7:44 PM, Mina Almasry wrote:
> diff --git a/include/linux/netdevice.h
在 2023/11/8 20:58, Arnd Bergmann 写道:
From: Arnd Bergmann
This function is only called locally and does not need to be
global. Since there is no external prototype, gcc warns about
the non-static definition:
fs/jffs2/debug.c:160:6: error: no previous prototype for
On 2023-11-07 14:55, David Ahern wrote:
> On 11/7/23 3:10 PM, Mina Almasry wrote:
>> On Mon, Nov 6, 2023 at 3:44 PM David Ahern wrote:
>>>
>>> On 11/5/23 7:44 PM, Mina Almasry wrote:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index eeeda849115c..1c351c138a5b
Hi, current linux kernel commit 90450a06162e
("Merge tag 'rcu-fixes-v6.7' of
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks")
and the attached config cause the following BUG when booting on
a reference AMD Zen4 development server:
[ 59.995717] input: OpenBMC
On 11/8/23 06:46, Luben Tuikov wrote:
Hi,
Could you please use my gmail address, the one one I'm responding from--I don't
want
to miss any DRM scheduler patches. BTW, the luben.tui...@amd.com email should
bounce
as undeliverable.
On 2023-11-07 21:26, Danilo Krummrich wrote:
Commit
On 08/11/2023 11:43:32+0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
On 2023-11-05 18:44, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur. The entries in the
On Wed, 8 Nov 2023 13:58:24 +0100
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Most architectures that support kprobes declare this function in their
> own asm/kprobes.h header and provide an override, but some are missing
> the prototype, which causes a warning for the __weak stub
On 11/8/23 22:52, Uwe Kleine-König wrote:
On Wed, Nov 08, 2023 at 10:24:09PM +0100, Helge Deller wrote:
On 11/8/23 22:00, Uwe Kleine-König wrote:
On Wed, Nov 08, 2023 at 11:48:05AM -0700, Nathan Chancellor wrote:
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
On Wed, Nov 08, 2023 at 10:24:09PM +0100, Helge Deller wrote:
> On 11/8/23 22:00, Uwe Kleine-König wrote:
> > On Wed, Nov 08, 2023 at 11:48:05AM -0700, Nathan Chancellor wrote:
> > > diff --git a/drivers/video/fbdev/atmel_lcdfb.c
> > > b/drivers/video/fbdev/atmel_lcdfb.c
> > > index
Hi Helge,
On Wed, Nov 8, 2023 at 10:32 PM Helge Deller wrote:
> On 11/8/23 22:06, Geert Uytterhoeven wrote:
> > On Tue, Nov 7, 2023 at 10:20 AM Uwe Kleine-König
> > wrote:
> >> On today's platforms the benefit of platform_driver_probe() isn't that
> >> relevant any more. It allows to drop some
On 11/8/23 22:06, Geert Uytterhoeven wrote:
On Tue, Nov 7, 2023 at 10:20 AM Uwe Kleine-König
wrote:
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any more. It allows to drop some code after booting (or module
loading) for .probe() and discard the .remove()
On 11/8/23 22:00, Uwe Kleine-König wrote:
On Wed, Nov 08, 2023 at 11:48:05AM -0700, Nathan Chancellor wrote:
diff --git a/drivers/video/fbdev/atmel_lcdfb.c
b/drivers/video/fbdev/atmel_lcdfb.c
index 88c75ae7d315..9e391e5eaf9d 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++
Hi Arnd,
On Wed, Nov 8, 2023 at 10:07 PM Arnd Bergmann wrote:
> On Wed, Nov 8, 2023, at 21:42, Geert Uytterhoeven wrote:
> > On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
> >> From: Arnd Bergmann
> >>
> >> Microblaze runs into a single -Wmissing-prototypes warning when that is
> >>
On Wed, Nov 8, 2023, at 21:42, Geert Uytterhoeven wrote:
>
> On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> Microblaze runs into a single -Wmissing-prototypes warning when that is
>> enabled:
>>
>> arch/microblaze/kernel/traps.c:21:6: warning: no previous
> +++ b/drivers/video/fbdev/amifb.c
> @@ -3530,7 +3530,7 @@ static inline void chipfree(void)
> * Initialisation
> */
>
> -static int __init amifb_probe(struct platform_device *pdev)
> +static int amifb_probe(struct platform_device *pdev)
nore...@ellerman.id.au
Hello,
On Wed, Nov 08, 2023 at 11:48:05AM -0700, Nathan Chancellor wrote:
> diff --git a/drivers/video/fbdev/atmel_lcdfb.c
> b/drivers/video/fbdev/atmel_lcdfb.c
> index 88c75ae7d315..9e391e5eaf9d 100644
> --- a/drivers/video/fbdev/atmel_lcdfb.c
> +++ b/drivers/video/fbdev/atmel_lcdfb.c
> @@
Hi Arnd,
On Wed, Nov 8, 2023 at 2:01 PM Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> Microblaze runs into a single -Wmissing-prototypes warning when that is
> enabled:
>
> arch/microblaze/kernel/traps.c:21:6: warning: no previous prototype for
> 'trap_init' [-Wmissing-prototypes]
>
> Include
On 11/8/23 19:48, Nathan Chancellor wrote:
On Tue, Nov 07, 2023 at 10:17:43AM +0100, Uwe Kleine-König wrote:
On today's platforms the benefit of platform_driver_probe() isn't that
relevant any more. It allows to drop some code after booting (or module
loading) for .probe() and discard the
On Wed, Nov 08, 2023 at 01:58:37PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> bch2_target_to_text_sb() is only called in the file it is defined in,
> and it has no extern prototype:
>
> fs/bcachefs/disk_groups.c:583:6: error: no previous prototype for
> 'bch2_target_to_text_sb'
On Wed, Nov 8, 2023, at 19:31, Christophe Leroy wrote:
> Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
> powerpc has functions doing more or less the same, they are called
> __c_kernel_clock_gettime() and alike with their prototypes siting in
> arch/powerpc/include/asm/vdso/gettimeofday.h
>
>
On Wed, Nov 08, 2023 at 01:58:30PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When -Wmissing-prototypes is enabled, the some asm-offsets.c files fail
> to build, even when this warning is disabled in the Makefile for normal
> files:
>
> arch/sparc/kernel/asm-offsets.c:22:5: error: no
Applied. Thanks!
On Tue, Nov 7, 2023 at 11:17 PM Lazar, Lijo wrote:
>
>
>
> On 11/7/2023 9:58 PM, Hunter Chasens wrote:
> > Resolves Sphinx unexpected indentation warning when compiling
> > documentation (e.g. `make htmldocs`). Replaces tabs with spaces and adds
> > a literal block to keep
Applied. Thanks!
On Wed, Nov 8, 2023 at 3:52 AM José Pekkarinen
wrote:
>
> On 2023-10-30 15:54, Aurabindo Pillai wrote:
> > On 10/29/2023 5:39 AM, José Pekkarinen wrote:
> >> Spotted by coccicheck, there is a redundant check for
> >> v->SourcePixelFormat[k] != dm_444_16. This patch will
> >>
On Wed, 08 Nov 2023 11:43:27 +0100, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
On Tue, Nov 07, 2023 at 10:17:43AM +0100, Uwe Kleine-König wrote:
> On today's platforms the benefit of platform_driver_probe() isn't that
> relevant any more. It allows to drop some code after booting (or module
> loading) for .probe() and discard the .remove() function completely if
> the driver
Hi Arnd,
Le 08/11/2023 à 13:58, Arnd Bergmann a écrit :
> From: Arnd Bergmann
>
> The VDSO functions are defined as globals in the kernel sources but intended
> to be called from userspace, so there is no need to declare them in a kernel
> side header.
>
> Without a prototype, this now causes
On 11/8/2023 10:10 AM, Kuogee Hsieh wrote:
On 11/7/2023 1:23 PM, Dmitry Baryshkov wrote:
On Tue, 7 Nov 2023 at 23:01, Kuogee Hsieh
wrote:
On 11/6/2023 5:55 PM, Dmitry Baryshkov wrote:
On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh
wrote:
The purpose of this patch series is to incorporate pm
On 2023-11-08 09:49, Christian König wrote:
Am 08.11.23 um 13:58 schrieb Rajneesh Bhardwaj:
Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.
To optimize the memory clearing operation when a TTM BO gets
On 11/7/2023 1:23 PM, Dmitry Baryshkov wrote:
On Tue, 7 Nov 2023 at 23:01, Kuogee Hsieh wrote:
On 11/6/2023 5:55 PM, Dmitry Baryshkov wrote:
On Sat, 7 Oct 2023 at 01:55, Kuogee Hsieh wrote:
The purpose of this patch series is to incorporate pm runtime framework
into MSM eDP/DP driver so
On 11/8/2023 9:49 AM, Christian König wrote:
Am 08.11.23 um 13:58 schrieb Rajneesh Bhardwaj:
Try to allocate system memory on the NUMA node the device is closest to
and try to run delayed_delete workers on a CPU of this node as well.
To optimize the memory clearing operation when a TTM BO
Hi Krzysztof
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Wednesday, November 8, 2023 4:13 PM
> To: David Airlie ; Daniel Vetter ;
> Maarten Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ;
> Rob Herring ; Krzysztof Kozlowski
> ; Conor Dooley
> ; Alim Akhtar ; Andi
> Shyti ;
Add support for the DSS controller on TI's AM62A7 SoC in the tidss
driver.
This controller has 2 video pipelines that can render 2 video planes on
over a screen, using the overlay managers. The output of the DSS comes
from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1
is tied
The DSS controller on TI's AM62A7 SoC is an update from that on TI's
AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video
pipelines, but unlike the former, the latter only has one output port on
VP2 to service DPI display sinks.
Add the new controller's compatible.
Signed-off-by:
This patch series adds a new compatible for the Display SubSystem (DSS)
controller on TI's AM62A7 SoC. It further adds the required support, for
the same, in the tidss driver.
The DSS controller is similar to the recently added AM625 DSS, with the
key difference being the absence of VP1 output on
Hi,
On Wed, Nov 8, 2023 at 7:45 AM Maxime Ripard wrote:
>
> > @@ -575,9 +599,18 @@ static int panel_edp_get_modes(struct drm_panel *panel,
> >
> > if (!p->edid)
> > p->edid = drm_get_edid(connector, p->ddc);
> > -
> > - if (p->edid)
> > -
On Wed, 08 Nov 2023, Krzysztof Kozlowski wrote:
> Samsung Exynos SoC reuses several devices from older designs, thus
> historically we kept the old (block's) compatible only. This works fine
> and there is no bug here, however guidelines expressed in
>
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
Userspace that registers with the
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
Add a read-only TYPE property. The TYPE specifies the colorop
type, such as enumerated curve, 1D LUT, CTM, 3D LUT, PWL LUT,
etc.
v3:
- Make TYPE a range property
- Move enum drm_colorop_type to uapi header
- Fix drm_get_colorop_type_name description
For now we're only introducing an
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,
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.
v3:
- Drop TODO for lock (it's handled in
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
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 12| | B |
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
---
drivers/gpu/drm/vkms/tests/vkms_color_tests.c |
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
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic_uapi.c | 18 ++
drivers/gpu/drm/drm_colorop.c | 39 +++
include/drm/drm_colorop.h | 20
3 files changed, 72 insertions(+), 5 deletions(-)
diff --git
Signed-off-by: Harry Wentland
---
drivers/gpu/drm/drm_atomic.c | 29 +
include/drm/drm_colorop.h| 5 +
2 files changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 59e1797d1ca8..ccf26b034433 100644
---
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 b995114cf6b8..ad4c2f72fd1e
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
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
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
v3:
- Use include way of testing static functions (Arthur)
Signed-off-by: Harry Wentland
Cc: Arthur Grillo
---
drivers/gpu/drm/vkms/Kconfig
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
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.
v3:
- Add next pointer to colorop to be used by drivers
and in DRM core
Signed-off-by: Harry
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
v3:
- Describe DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE (Sebastian)
- Ask for clear documentation of colorop behavior (Sebastian)
v2:
- Update colorop visualizations to match reality (Sebastian, Alex Hung)
- Updated wording (Pekka)
- Change BYPASS wording to make it non-mandatory (Sebastian)
-
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 | 15 +++
include/drm/drm_colorop.h | 20
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
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.
Signed-off-by: Harry Wentland
Reviewed-by: Simon Ser
---
include/drm/drm_fixed.h | 2 +-
1 file changed, 1
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
On 2023-10-29 05:39, José Pekkarinen wrote:
Spotted by coccicheck, there is a redundant check for
v->SourcePixelFormat[k] != dm_444_16. This patch will
remove it. The corresponding output follows.
drivers/gpu/drm/amd/display/dc/dml/dcn30/display_mode_vba_30.c:5130:86-122: duplicated
Object debugging tools were sporadically reporting illegal attempts to
free a still active i915 VMA object from when parking a GPU tile believed
to be idle.
[161.359441] ODEBUG: free active (active state 0) object: 88811643b958
object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]
On 2023-11-08 11:19, Pekka Paalanen wrote:
> On Wed, 8 Nov 2023 09:31:17 -0500
> Harry Wentland wrote:
>
>> On 2023-11-08 06:40, Sebastian Wick wrote:
>>> On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
>>>
On Tue, 7 Nov 2023 11:58:26 -0500
Harry Wentland wrote:
On Wed, 8 Nov 2023 09:31:17 -0500
Harry Wentland wrote:
> On 2023-11-08 06:40, Sebastian Wick wrote:
> > On Wed, Nov 8, 2023 at 11:16 AM Pekka Paalanen wrote:
> >
> >>
> >> On Tue, 7 Nov 2023 11:58:26 -0500
> >> Harry Wentland wrote:
> >>
> >>> On 2023-11-07 04:55, Pekka Paalanen wrote:
On Wed, Nov 08, 2023 at 04:34:39PM +0100, Maxime Ripard wrote:
> On Tue, Nov 07, 2023 at 04:26:34PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Nov 07, 2023 at 01:18:14PM +0100, Maxime Ripard wrote:
> > > On Tue, Nov 07, 2023 at 12:22:21PM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Nov 07,
On Tue, Nov 07, 2023 at 12:41:54PM -0800, Hsin-Yi Wang wrote:
> Generic edp gets mode from edid. However, some panels report incorrect
> mode in this way, resulting in glitches on panel. Introduce a new quirk
> additional_mode to the generic edid to pick a correct hardcoded mode.
>
>
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> Some platforms/SoCs can power off the GPU entirely by completely cutting
> off power, greatly enhancing battery time during system suspend: add a
> new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators
> during full suspend
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> All of the MediaTek SoCs supported by Panfrost can completely cut power
> to the GPU during full system sleep without any user-noticeable delay
> in the resume operation, as shown by measurements taken on multiple
> MediaTek SoCs.
>
> As an
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> All of the MediaTek SoCs supported by Panfrost can switch the clocks
> off and on during system sleep to save some power without any user
> experience penalty.
>
> Measurements taken on multiple MediaTek SoCs show that adding this
> will
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> Currently, the GPU is being internally powered off for runtime suspend
> and turned back on for runtime resume through commands sent to it, but
> note that the GPU doesn't need to be clocked during the poweroff state,
> hence it is possible
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> In many cases, soft reset takes more than 1 microsecond, but definitely
> less than 10; moreover in the poweron flow, tilers, shaders and l2 will
> become ready (each) in less than 10 microseconds as well.
>
> Even in the cases (at least on
On 02/11/2023 14:26, AngeloGioacchino Del Regno wrote:
> Even though soft reset should ideally never fail, during development of
> some power management features I managed to get some bits wrong: this
> resulted in GPU soft reset failures, where the GPU was never able to
> recover, not even after
On 11/8/23 15:58, Arnd Bergmann wrote:
From: Arnd Bergmann
When CONFIG_SYSFB is disabled, the hyperv_fb driver can now run into
undefined behavior on a gen2 VM, as indicated by this smatch warning:
drivers/video/fbdev/hyperv_fb.c:1077 hvfb_getmem() error: uninitialized symbol
'base'.
On Tue, 7 Nov 2023 12:41:53 -0800, Hsin-Yi Wang wrote:
> Add a few generic edp panels used by mt8186 chromebooks.
>
> Signed-off-by: Hsin-Yi Wang
> Reviewed-by: Douglas Anderson
Acked-by: Maxime Ripard
Thanks!
Maxime
On 06/11/2023 21:17, Stanislav Fomichev wrote:
> I guess I'm just wondering whether other people have any suggestions
> here. Not sure Jonathan's way was better, but we fundamentally
> have two queues between the kernel and the userspace:
> - userspace receiving tokens (recvmsg + magical flag)
> -
On Tue, 7 Nov 2023 12:41:52 -0800, Hsin-Yi Wang wrote:
> Rename AUO 0x235c B116XTN02 to B116XTN02.3 according to decoding edid.
>
> Fixes: 3db2420422a5 ("drm/panel-edp: Add AUO B116XTN02, BOE
> NT116WHM-N21,836X2, NV116WHM-N49 V8.0")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Hsin-Yi Wang
>
1 - 100 of 196 matches
Mail list logo
