Add the missing clk_disable_unprepare() before return in
kmb_dsi_clk_enable().
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/kmb/kmb_dsi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/kmb/kmb_dsi.c b/drivers/gpu/drm/kmb/kmb_dsi.c
index cf7cf0b07541..02141ac593c6 10064
Add missing clk_disable_unprepare, thanks!
Gaosheng Cui (3):
drm/exynos: Add missing clk_disable_unprepare in exynos_fimd_resume
drm/gem: Add missing clk_disable_unprepare in ade_power_up
drm/kmb: Add missing clk_disable_unprepare in kmb_dsi_clk_enable
drivers/gpu/drm/exynos/exynos_drm_fim
Add the missing clk_disable_unprepare() before return in
exynos_fimd_resume().
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f
Add the missing clk_disable_unprepare() before return in
ade_power_up().
Signed-off-by: Gaosheng Cui
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
b/drivers/gpu/drm/hisilicon/kirin/kirin_
On Sat, Aug 03, 2024 at 05:48:14AM +0530, Riyan Dhiman wrote:
> Adhere to Linux kernel coding style
>
> Reported by checkpatch:
>
> CHECK: mutex definition without comment
>
> Proof for comment:
>
> 1. The mutex is used to protect access to the 'running' list
> (line 1798 tsi148_dma_list_exec f
Hi Sui,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.11-rc1 next-20240802]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to
On Mon, Jul 29, 2024 at 09:38:48PM -0400, Richard Acayan wrote:
> The Snapdragon 670 has the Adreno A615 GPU. Add it along with its device
> tree dependencies.
>
> Signed-off-by: Richard Acayan
> ---
> arch/arm64/boot/dts/qcom/sdm670.dtsi | 168 +++
> 1 file changed, 168 i
On Wed, Jul 24, 2024 at 10:16 PM Mikhail Gavrilov
wrote:
> > https://patchwork.freedesktop.org/patch/605201/
> For which kernel is this patch intended? The patch is not applied on
> top of d67978318827.
I am able to apply this patch on top of e4fc196f5ba3 and the issue is gone.
Tested-by: Mikhai
DPU debugging macros need to be converted to a proper drm_debug_*
macros, however this is a going an intrusive patch, not suitable for a
fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER
to make sure that DPU debugging messages always end up in the drm debug
messages and are c
During suspend/resume process all connectors are explicitly disabled and
then reenabled. However resume fails because of the connector_status check:
[ 1185.831970] [dpu error]connector not connected 3
It doesn't make sense to check for the Writeback connected status (and
other drivers don't perfo
Leonard Lausen reported an issue with suspend/resume of the sc7180
devices. Fix the WB atomic check, which caused the issue. Also make sure
that DPU debugging logs are always directed to the drm_debug / DRIVER so
that usual drm.debug masks work in an expected way.
Signed-off-by: Dmitry Baryshkov
-Original Message-
From: Intel-gfx On Behalf Of Andi
Shyti
Sent: Friday, August 2, 2024 1:39 AM
To: intel-gfx ; dri-devel
Cc: Jann Horn ; Jani Nikula ;
Joonas Lahtinen ; Vivi, Rodrigo
; Tvrtko Ursulin ; Jann Horn
; Chris Wilson ; Niemiec,
Krzysztof ; Andi Shyti ;
Auld, Matthew ; An
-Original Message-
From: Intel-gfx On Behalf Of Andi
Shyti
Sent: Friday, August 2, 2024 1:39 AM
To: intel-gfx ; dri-devel
Cc: Jann Horn ; Jani Nikula ;
Joonas Lahtinen ; Vivi, Rodrigo
; Tvrtko Ursulin ; Jann Horn
; Chris Wilson ; Niemiec,
Krzysztof ; Andi Shyti ;
Auld, Matthew ; An
On 2024-07-25 11:33, Dragan Simic wrote:
Hello all,
Just checking, is this patch good enough to be accepted? If not, is
there
some other preferred way for cleaning up the produced messages?
Just a brief reminder...
On 2024-07-04 01:32, Dragan Simic wrote:
Clean up a few logged messages,
> No functional modification involved.
>
> ./drivers/gpu/drm/amd/display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c:6463:166-167:
> Unneeded semicolon.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=9633
> Signed-off-by: Jiapeng Chong
> ---
> .../dis
The pull request you sent on Fri, 2 Aug 2024 15:08:04 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2024-08-02
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/29b4a6996c244f0d360537d6a4a0996468372c17
Thank you!
--
Deet-doot-dot, I am a bot.
ht
On Fri, Aug 2, 2024 at 4:37 PM Harry Wentland wrote:
>
> On 2024-08-02 09:28, Sebastian Wick wrote:
> > I'm very unhappy about how this has played out.
> >
> > We have a new sysfs property that controls a feature of the display
> > path that has been set to a default(!) which changes the color
> >
This add the support for:
- R1/R2/R4/R8
R1 format was tested with [1] and [2].
[1]:
https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
[2]:
https://lore.kernel.org/igt-dev/20240306-b4-kms_tests-v1-0-8fe451efd...@bootlin.com/
Reviewed-by: Pekka Paalanen
Signed-off-by
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
- c
From: Arthur Grillo
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.
From: Arthur Grillo
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts, updated the commit message]
Acked-by: Pekka Paalanen
Signed-off-by: Louis
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentati
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12/NV16/NV24
- NV21/NV61/NV42
- YUV420/YUV422/YUV444
- YVU420/YVU422/YVU444
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a spec
As all the rotation are now supported by VKMS, this simplification does
not make sense anymore, so remove it.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_plane.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/
Re-introduce a line-by-line composition algorithm for each pixel format.
This allows more performance by not requiring an indirection per pixel
read. This patch is focused on readability of the code.
Line-by-line composition was introduced by [1] but rewritten back to
pixel-by-pixel algorithm in [
The pixel_read_direction enum is useful to describe the reading direction
in a plane. It avoids using the rotation property of DRM, which not
practical to know the direction of reading.
This patch also introduce two helpers, one to compute the
pixel_read_direction from the DRM rotation property, an
The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing
different concepts (coordinate calculation and color management), extract
the x_limit and x_dst computation outside of this helper.
It also increases the maintainability by grouping the computation related
to coordinates in the sa
As the pixel_read and pixel_write function should never modify the input
buffer, mark those pointers const.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_drv.h | 4 ++--
drivers/gpu/drm/vkms/vkms_formats.c | 20 ++--
Introduce the usage of block_h/block_w to compute the offset and the
pointer of a pixel. The previous implementation was specialized for
planes with block_h == block_w == 1. To avoid confusion and allow easier
implementation of tiled formats. It also remove the usage of the
deprecated format field
From: Arthur Grillo
Remove intermidiary variables and access the variables directly from
drm_frame. These changes should be noop.
Signed-off-by: Arthur Grillo
Acked-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Reviewed-by: Louis Chauvet
[Louis Chauvet: Applied review from Maíra]
Signed-off-by
Introduce two callbacks which does nothing. They are used in replacement
of NULL and it avoid kernel OOPS if this NULL is called.
If those callback are used, it means that there is a mismatch between
what formats are announced by atomic_check and what is realy supported by
atomic_update.
Acked-by
Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the
compiler to check if the passed functions take the correct arguments.
Such typedefs will help ensuring consistency across the code base in
case of update of these prototypes.
Rename input/output variable in a consistent way betw
Add some documentation on pixel conversion functions.
Update of outdated comments for pixel_write functions.
Signed-off-by: Louis Chauvet
Acked-by: Pekka Paalanen
---
drivers/gpu/drm/vkms/vkms_composer.c | 7
drivers/gpu/drm/vkms/vkms_drv.h | 15 -
drivers/gpu/drm/vkms/vkms_f
Few no-op changes to remove double spaces and fix wrong alignments.
Reviewed-by: Pekka Paalanen
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_composer.c | 10 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++
drivers/gpu/drm/vkms/vkms_drv.c
This patchset is the second version of [1]. It is almost a complete
rewrite to use a line-by-line algorithm for the composition.
During the development of this series Pekka and Arthur found an issue in
drm core. The YUV part of this series depend on the fix [9]. I'll let
Arthur extract it and subm
As the comment explains, the if check ensures that the divisor oa_period
is a u32. Explicitly cast oa_period to u32 to remove the following
Coccinelle/coccicheck warning reported by do_div.cocci:
WARNING: do_div() does a 64-by-32 division, please consider using div64_u64
instead
Use the prefer
On 8/1/24 03:35, Jani Nikula wrote:
On Wed, 31 Jul 2024, Hamza Mahfooz wrote:
Video Format Data Blocks (VFDBs) contain the necessary information that
needs to be fed to the Optimized Video Timings (OVT) Algorithm.
Also, we require OVT support to cover modes that aren't supported by
earlier stan
Hi,
On 2024-08-01 10:52:55+, Hans de Goede wrote:
> On 7/31/24 10:55 PM, Daniel Vetter wrote:
> > On Wed, Jul 31, 2024 at 08:40:12PM +0300, Jani Nikula wrote:
> >> On Wed, 31 Jul 2024, Thomas Weißschuh wrote:
> >>> The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> >>>
Hi,
On Fri, Aug 2, 2024 at 12:06 AM Terry Hsiao
wrote:
>
> Rename HKC MB116AN01 from Unknown to MB116AN01
>
> Signed-off-by: Terry Hsiao
> ---
> drivers/gpu/drm/panel/panel-edp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-edp.c
> b/driv
On 2024-08-01 20:32, Kasireddy, Vivek wrote:
> Hi Huan,
>
>> This patchset attempts to fix some errors in udmabuf and remove the
>> upin_list structure.
>>
>> Some of this fix just gather the patches which I upload before.
>>
>> Patch1
>> ===
>> Try to remove page fault mmap and direct map it.
>>
On 2024-08-02 10:59, Hamza Mahfooz wrote:
> This reverts commit 76299a557f36d624ca32500173ad7856e1ad93c0.
>
> It was merged without meeting userspace requirements.
>
> Signed-off-by: Hamza Mahfooz
Series is:
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/drm_connector.c | 48
On 7/31/24 02:38, Linux regression tracking (Thorsten Leemhuis) wrote:
[+amd-glx, +lkml, +dri-devel]
On 27.07.24 18:52, serg.parti...@gmail.com wrote:
After updating from 6.8.9 to 6.9.1 I noticed a bug on my HP Envy x360
with AMD Ryzen 5 4500U.
[...]
After waking up from sleep brightness is s
Tomi, could you please push this through drm-misc ?
On Tue, Jul 30, 2024 at 12:34:40AM +, Kuninori Morimoto wrote:
> We already have for_each_endpoint_of_node(), don't use
> of_graph_get_next_endpoint() directly. Replace it.
>
> Signed-off-by: Kuninori Morimoto
> Acked-by: Dmitry Baryshkov
This reverts commit 9d8c094ddab05db88d183ba82e23be807848cad8.
It was merged without meeting userspace requirements.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 4 --
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 52 ++-
.../gpu/drm/amd/dis
This reverts commit 76299a557f36d624ca32500173ad7856e1ad93c0.
It was merged without meeting userspace requirements.
Signed-off-by: Hamza Mahfooz
---
drivers/gpu/drm/drm_connector.c | 48 -
include/drm/drm_connector.h | 2 --
include/drm/drm_mode_config.h |
On 2024-08-02 09:28, Sebastian Wick wrote:
> I'm very unhappy about how this has played out.
>
> We have a new sysfs property that controls a feature of the display
> path that has been set to a default(!) which changes the color
> behavior! This broke color management for everyone who is on a dev
On 25-07-24, 15:06, Abhinav Kumar wrote:
> Fix the voltage swing and pre-emphasis tables for sm8350 as the current
> one do not match the hardware docs.
>
> Fixes: ef14aff107bd ("phy: qcom: com-qmp-combo: add SM8350 & SM8450 support")
> Signed-off-by: Abhinav Kumar
> ---
> drivers/phy/qualcomm/p
On Thu, Aug 01, 2024 at 06:46:10PM +0530, Akhil P Oommen wrote:
> On Thu, Jul 11, 2024 at 10:00:19AM +, Vladimir Lypak wrote:
> > Two fields of preempt_record which are used by CP aren't reset on
> > resume: "data" and "info". This is the reason behind faults which happen
> > when we try to swi
I'm very unhappy about how this has played out.
We have a new sysfs property that controls a feature of the display
path that has been set to a default(!) which changes the color
behavior! This broke color management for everyone who is on a device
which supports this feature.
What should have be
Hi Maíra,
Am 02.08.24 um 14:56 schrieb Maíra Canal:
Hi Stefan,
On 7/31/24 13:41, Stefan Wahren wrote:
Hi Maíra,
Am 30.07.24 um 13:23 schrieb Maíra Canal:
On 7/28/24 10:00, Stefan Wahren wrote:
Common pattern of handling deferred probe can be simplified with
dev_err_probe() and devm_clk_get_
Hi Stefan,
On 7/31/24 13:41, Stefan Wahren wrote:
Hi Maíra,
Am 30.07.24 um 13:23 schrieb Maíra Canal:
On 7/28/24 10:00, Stefan Wahren wrote:
Common pattern of handling deferred probe can be simplified with
dev_err_probe() and devm_clk_get_optional(). This results in much
less code.
Signed-of
Am Do., 1. Aug. 2024 um 14:34 Uhr schrieb Jani Nikula
:
>
> On Mon, 01 Jul 2024, Xaver Hugl wrote:
> > Am Do., 20. Juni 2024 um 22:22 Uhr schrieb Xaver Hugl
> > :
> >> Merging can only happen once a real world userspace application has
> >> implemented support for it. I'll try to do that sometime
There are a several statements with two following semicolons, replace
these with just one semicolon.
Signed-off-by: Colin Ian King
---
.../drm/amd/display/dc/dml2/dml21/dml21_translation_helper.c | 2 +-
.../dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c| 2 +-
.../display/dc/dml2/d
I'm still scratching my head what the heck this could be.
Increasing the TTM prefault number has minimal more CPU overhead on the
first access but makes subsequent accesses to the same buffer faster
(because the buffer is already completely present).
So as long as Chrome didn't wrote some sin
Hi,
So, can't reproduce this any more with with recent rawhide (rc1+).
Tried also with the same old kernels but this time its with newer mesa
and google-chrome (126 -> 127). The same scenario as before now works
ok.
Cheers and sorry for the noise.
- Yanko
On Wed, 2024-07-24 at 10:13 +0300, Yank
Am 02.08.24 um 09:17 schrieb Lu Yao:
Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.
Signed-off-by: Lu Yao
---
The patch can work properly on the TTY, but after start X, drawn
image is messy, it looks like the d
On Fri, 02 Aug 2024, Thomas Zimmermann wrote:
> Hi
>
> Am 02.08.24 um 10:03 schrieb Jani Nikula:
>> On Thu, 01 Aug 2024, Thomas Zimmermann wrote:
>>> For cloned outputs, don't pick a default resolution of 1024x768 as
>>> most hardware can do better. Instead look through the modes of all
>>> conne
https://bugzilla.kernel.org/show_bug.cgi?id=219117
Jean-Christophe Guillain (jean-christo...@guillain.net) changed:
What|Removed |Added
Resolution|ANSWERED|
Hi
Am 02.08.24 um 10:03 schrieb Jani Nikula:
On Thu, 01 Aug 2024, Thomas Zimmermann wrote:
For cloned outputs, don't pick a default resolution of 1024x768 as
most hardware can do better. Instead look through the modes of all
connectors to find a common mode for all of them.
Signed-off-by: Tho
On Fri, Aug 2, 2024 at 10:39 AM Andi Shyti wrote:
> Calculating the size of the mapped area as the lesser value
> between the requested size and the actual size does not consider
> the partial mapping offset. This can cause page fault access.
>
> Fix the calculation of the starting and ending addr
Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference bet
When mapping a framebuffer object, the virtual memory area (VMA)
offset ('vm_pgoff') should be adjusted by the start of the
'vma_node' associated with the object. This ensures that the VMA
offset is correctly aligned with the corresponding offset within
the GGTT aperture.
Increment vm_pgoff by the
Hi,
this series fixes the memory limits calculation (start, end), in
order to avoid access to addresses not belonging to the mapped
page.
This series has been reviewed in other communities but, because
it needs to go through drm-tip, I am proposing it again here in
the intel-gfx mailing list.
Ja
Hi Krzysztof,
On Thu, Aug 01, 2024 at 05:40:48PM +0200, Krzysztof Niemiec wrote:
> While the sysfs entries for engines are added in intel_engines_init()
> during driver load, the corresponding function intel_engines_release()
> does not correctly get rid of them. This can lead to a UAF if, after
>
On Thu, 01 Aug 2024, abid-sayyad wrote:
> Fixed warning for the following:
> ./include/uapi/drm/drm_mode.h:869: warning: Function parameter or struct
> member
> 'width' not described in 'drm_plane_size_hint'
> ./include/uapi/drm/drm_mode.h:869: warning: Function para
On Thu, 01 Aug 2024, Thomas Zimmermann wrote:
> For cloned outputs, don't pick a default resolution of 1024x768 as
> most hardware can do better. Instead look through the modes of all
> connectors to find a common mode for all of them.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm
Rename HKC MB116AN01 from Unknown to MB116AN01
Signed-off-by: Terry Hsiao
---
drivers/gpu/drm/panel/panel-edp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 2733366b02b0..7183df26 100644
--- a
July 31, 2024 at 3:17 PM, "Thomas Zimmermann" mailto:tzimmerm...@suse.de?to=%22Thomas%20Zimmermann%22%20%3Ctzimmermann%40suse.de%3E
> wrote:
>
> Replace FB_BLANK_ constants with their counterparts from the
> backlight subsystem. The values are identical, so there's no
> change in functionality o
Hi
Am 02.08.24 um 06:47 schrieb Ma Ke:
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is
assigned to modeset->mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
Cc: sta...@vger.kernel.org
Fixes: cf1
On Mon, 15 Jul 2024 18:35:51 +1000, Dave Airlie wrote:
> The test here creates an sg table, but never maps it, when
> we get to drm_gem_shmem_free, the helper tries to unmap and this
> causes warnings on some platforms and debug kernels.
>
> This also sets a 64-bit dma mask, as I see an swiotlb wa
Add support for the drm_panic module, which displays a pretty user
friendly message on the screen when a Linux kernel panic occurs.
Signed-off-by: Lu Yao
---
The patch can work properly on the TTY, but after start X, drawn
image is messy, it looks like the data isn't linearly arranged.
However at
Am 02.08.24 um 06:47 schrieb Ma Ke:
In drm_client_modeset_probe(), the return value of drm_mode_duplicate() is
assigned to modeset->mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
Cc: sta...@vger.kernel.org
Fixes: cf13
On Tue, Jul 30, 2024 at 7:24 AM Dmitry Baryshkov
wrote:
>
> On Sat, Jul 27, 2024 at 08:33:10PM GMT, Alper Nebi Yasak wrote:
> > Hi,
> >
> > I have a MT8186 "Magneton" Chromebook that I'm trying to boot a kernel
> > based on Collabora's for-kernelci branch [1], using a config from
> > postmarketOS
73 matches
Mail list logo
