On Tue, Jun 24, 2025 at 01:58:47PM +0800, Ling Xu wrote:
> 在 6/23/2025 6:28 PM, Konrad Dybcio 写道:
> > On 6/22/25 3:38 PM, Ling Xu wrote:
> >> The fastrpc driver has support for 5 types of remoteprocs. There are
> >> some products which support GDSP remoteprocs. Add changes to support
> >> GDSP remo
Hi Mario,
kernel test robot noticed the following build errors:
[auto build test ERROR on pci/next]
[also build test ERROR on pci/for-linus tiwai-sound/for-next
tiwai-sound/for-linus tip/x86/core linus/master v6.16-rc3 next-20250627]
[If your patch is applied to the wrong git tree, kindly drop
The error handling in fbtft_framebuffer_alloc() mixes managed allocation
and plain allocation, and performs error handling in an order different
from the order in fbtft_framebuffer_release().
Fix them by moving vmem allocation closer to where it is used, and using
plain kzalloc() for txbuf allocat
After commit 56c134f7f1b5 ("fbdev: Track deferred-I/O pages in pageref
struct"), fb_deferred_io_init() allocates memory for info->pagerefs as
well as return an error code on failure. However the error code is
ignored here and the memory allocated could leak because of not calling
fb_deferred_io_cle
v2:
- Change the earlier patch to also handle the error code returned by
fb_deferred_io_init() and update Fixes tag to point to the commit that
introduced the memory allocation (which leads to leak).
- Add second patch to make the error handling order symmetric to
fbtft_framebuffer_release()
On Fri, Jun 27, 2025 at 12:10 PM Javier Martinez Canillas
wrote:
>
> Laurent Pinchart writes:
>
> > On Fri, Jun 27, 2025 at 09:39:37AM -0700, Rob Clark wrote:
> >> On Mon, Feb 26, 2024 at 5:43 AM Jacopo Mondi wrote:
> >> >
> >> > Add FourCC definitions for the 48-bit RGB/BGR formats to the
> >> >
The pull request you sent on Sat, 28 Jun 2025 07:05:56 +1000:
> https://gitlab.freedesktop.org/drm/kernel.git tags/drm-fixes-2025-06-28
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7abdafd2343ab199367c8243d6a5f06a9aa6976b
Thank you!
--
Deet-doot-dot, I am a bot.
h
Handle two cases for Adreno 7xx:
- Adreno 702 follows A610 and A619 example and has clocks in the GPU
node.
- Newer 7xx GPUs use a different pattern for the compatibles and did not
match currently.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 5
Adreno A506 and A510 have one extra clock, alwayson. Describe it in the
schema.
Signed-off-by: Dmitry Baryshkov
---
Documentation/devicetree/bindings/display/msm/gpu.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml
b/Documentation
Rather than having a single list with all possible clocks for A3xx-A5xx
define individual Adreno GPU types and corresponding clock lists.
Signed-off-by: Dmitry Baryshkov
---
.../devicetree/bindings/display/msm/gpu.yaml | 220 ++---
1 file changed, 194 insertions(+), 26 dele
Currently MSM GPU schema defines a single statement for all A3xx - A5xx
GPUs, listing all possible clocks for all generations. Split the list
per GPU type, listing exact clock names for each type.
Signed-off-by: Dmitry Baryshkov
---
Dmitry Baryshkov (3):
dt-bindings: display/msm/gpu: accoun
On Fri, Jun 27, 2025 at 07:18:03PM +0200, Christophe JAILLET wrote:
> Functions and other stuff all start with "mdp4_", except a few ones that
> start with "mpd4_" (d and p switched)
>
> Make things consistent and use "mdp4_" everywhere.
>
> Signed-off-by: Christophe JAILLET
> ---
> The change h
[also Cc'ing Mauro]
On Fri, Jun 27, 2025 at 05:27:18PM +0530, Kevin Paul Reddy Janagari wrote:
> Functions drm_format_info, drm_modeset_lock, drm_ioctl_flags are not being
> indexed in the documentation because there are structs with the same name
> and sphinx is only indexing one of them, Added
Hi Danilo, thank you an Boqun for having a look at this,
> On 27 Jun 2025, at 20:12, Danilo Krummrich wrote:
>
> On Fri, Jun 27, 2025 at 07:34:04PM -0300, Daniel Almeida wrote:
>> +#[pin_data]
>> +pub(crate) struct TyrData {
>> +pub(crate) pdev: ARef,
>> +
>> +#[pin]
>> +clks: Mutex
On Fri, Jun 27, 2025 at 07:34:04PM -0300, Daniel Almeida wrote:
> +#[pin_data]
> +pub(crate) struct TyrData {
> +pub(crate) pdev: ARef,
> +
> +#[pin]
> +clks: Mutex,
> +
> +#[pin]
> +regulators: Mutex,
> +
> +// Some inforation on the GPU. This is mainly queried by userspace
On Fri, Jun 27, 2025 at 07:34:04PM -0300, Daniel Almeida wrote:
[...]
> +#[pin_data]
> +pub(crate) struct TyrData {
> +pub(crate) pdev: ARef,
> +
> +#[pin]
> +clks: Mutex,
> +
> +#[pin]
> +regulators: Mutex,
> +
> +// Some inforation on the GPU. This is mainly queried by use
The formats XRGB16161616 and ARGB16161616 were already supported.
Add the support for:
- ABGR16161616
- XBGR16161616
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 6 ++
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 8 insertion
educe code duplication between yuv formats
PATCH 8 adds support for P01* formats
I tested the implementation using kms_plane.
Signed-off-by: Louis Chauvet
---
Changes in v6:
- Reformat commit message
- Remove outdated comment
- Link to v5:
https://lore.kernel.org/r/20250627-b4-new-color-fo
Add the support for:
- RGB888
- BGR888
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 +++
drivers/gpu/drm/vkms/vkms_plane.c | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkm
The callback functions for line conversion are almost identical for
semi-planar formats. The generic READ_LINE_YUV_SEMIPLANAR macro
generate all the required boilerplate to process a line from a
semi-planar format.
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/v
The formats XRGB and ARGB were already supported. Add the
support for:
- XBGR
- ABGR
- RGBA
- BGRA
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 13 +++--
drivers/gpu/drm/vkms/vkms_plane.c | 5 -
2 files ch
The formats NV 12/16/24/21/61/42 were already supported.
Add support for:
- P010
- P012
- P016
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 ++-
drivers/gpu/drm/vkms/vkms_plane.c | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 143 +-
drivers/gpu/drm/vkms/vkms_formats.c | 22 ++--
drivers/gpu/dr
The format RGB565 was already supported. Add the support for:
- BGR565
Reviewed-by: Maíra Canal
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/vkms/vkms_formats.c | 13 +
drivers/gpu/drm/vkms/vkms_plane.c | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/vk
The callback functions for line conversion are almost identical for
some format. The generic READ_LINE macro generate all the required
boilerplate to process a line.
Two overrides of this macro have been added to avoid duplication of
the same arguments every time.
Reviewed-by: Maíra Canal
Signed
Functions drm_format_info, drm_modeset_lock, drm_ioctl_flags are not being
indexed in the documentation because there are structs with the same name
and sphinx is only indexing one of them, Added them to namespaces as a
workaround for suppressing the warnings and indexing the functions
Signed-o
Functions drm_format_info, drm_modeset_lock, drm_ioctl_flags are not being
indexed in the documentation because there are structs with the same name
and sphinx is only indexing one of them, Added them to namespaces as a
workaround for suppressing the warnings and indexing the functions
This is a
On Fri, Jun 27, 2025 at 07:36:33PM -0300, Daniel Almeida wrote:
> I´ll fix the missing "rust: drm:" tags on a v2.
>
No worries. For a second I thought you meant to write "Introduce Tyrion"
;-)
Regards,
Boqun
> - Daniel
I’ll fix the missing “rust: drm:” tags on a v2.
— Daniel
omem)
+.try_access()
+.ok_or(ENODEV)?
+.try_write32(value, self.0)
+}
+}
+
+pub(crate) const CSF_GLB_DOORBELL_ID: usize = 0;
diff --git a/drivers/gpu/drm/tyr/tyr.rs b/drivers/gpu/drm/tyr/tyr.rs
new file mode 100644
index
..455100aafcffb58af955d3796f2621f2947ad7b9
--- /dev/null
+++ b/drivers/gpu/drm/tyr/tyr.rs
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0 or MIT
+
+//! Rust driver for ARM Mali CSF-based GPUs
+//!
+//! The name "Tyr" is inspired by Norse mythology, reflecting ARM's tradition
of
+//! naming their GPUs after Nordic mythological figures and places.
+
+use crate::driver::TyrDriver;
+
+mod driver;
+mod file;
+mod gem;
+mod gpu;
+mod regs;
+
+kernel::module_platform_driver! {
+type: TyrDriver,
+name: "tyr",
+author: "The Tyr driver authors",
+description: "Rust driver for ARM Mali CSF-based GPUs",
+license: "Dual MIT/GPL",
+}
diff --git a/rust/uapi/uapi_helper.h b/rust/uapi/uapi_helper.h
index
1409441359f510236256bc17851f9aac65c45c4e..f9959c1d889170ebe6ad5f98a431225fb08625b5
100644
--- a/rust/uapi/uapi_helper.h
+++ b/rust/uapi/uapi_helper.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
---
base-commit: 1b1d6cbeba24e4c9ff39580101472efeb3bd9b6f
change-id: 20250627-tyr-683ec49113ba
Best regards,
--
Daniel Almeida
On Fri, 27 Jun 2025 01:09:00 +0530, Kaustabh Chakraborty wrote:
> Add compatible string for Exynos7870 DSIM bridge controller. The
> device requires four clock sources, in schema they're named as "bus",
> "pll", "byte", and "esc".
>
> Suggested-by: Krzysztof Kozlowski
> Signed-off-by: Kaustabh
On Tue, Jun 24, 2025 at 05:36:29PM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 24, 2025 at 04:23:31PM +0200, Christian König wrote:
> > On 24.06.25 16:03, Riana Tauro wrote:
> > > Hi Christian
> > >
> > > On 6/24/2025 5:56 PM, Christian König wrote:
> > >> On 23.06.25 12:01, Riana Tauro wrote:
> > >>
Hi Linus,
Regular weekly drm updates, nothing out of the ordinary, amdgpu, xe,
i915 and a few misc bits. Seems about right for this time in the
release cycle.
Dave.
drm-fixes-2025-06-28:
drm fixes for 6.16-rc4
core:
- fix drm_writeback_connector_cleanup function signature
- use correct HDMI aud
On Wed, Jun 25, 2025 at 10:30:08PM +0530, Badal Nilawar wrote:
> Introducing xe_late_bind_fw to enable firmware loading for the devices,
> such as the fan controller, during the driver probe. Typically,
> firmware for such devices are part of IFWI flash image but can be
> replaced at probe after OE
On Tue, Jun 17, 2025 at 02:25:40PM +0200, Maxime Ripard wrote:
> Some parts of the memory can be dedicated to specific purposes and
> exposed as a dedicated memory allocator.
>
> This is especially useful if that particular region has a particular
> properties the rest of the memory doesn't have.
On Tue, Jun 17, 2025 at 02:25:41PM +0200, Maxime Ripard wrote:
> Some reserved memory regions might have particular memory setup or
> attributes that make them good candidates for heaps.
>
> Let's provide a heap type that will create a new heap for each reserved
> memory region flagged as such.
>
Laurent Pinchart writes:
> On Fri, Jun 27, 2025 at 09:39:37AM -0700, Rob Clark wrote:
>> On Mon, Feb 26, 2024 at 5:43 AM Jacopo Mondi wrote:
>> >
>> > Add FourCC definitions for the 48-bit RGB/BGR formats to the
>> > DRM/KMS uapi.
>> >
>> > The format will be used by the Raspberry Pi PiSP Back En
Hi Mike,
Thank you for the patch.
On Fri, Jun 27, 2025 at 04:50:46PM +0200, Mike Looijmans wrote:
> XRGB is the default mode that Xorg will want to use. Add support
> for this to the Zynqmp DisplayPort driver, so that applications can use
> 32-bit framebuffers. This solves that the X server w
On Fri, Jun 27, 2025 at 09:39:37AM -0700, Rob Clark wrote:
> On Mon, Feb 26, 2024 at 5:43 AM Jacopo Mondi wrote:
> >
> > Add FourCC definitions for the 48-bit RGB/BGR formats to the
> > DRM/KMS uapi.
> >
> > The format will be used by the Raspberry Pi PiSP Back End,
> > supported by a V4L2 driver i
On 6/27/25 7:18 PM, Christophe JAILLET wrote:
> Functions and other stuff all start with "mdp4_", except a few ones that
> start with "mpd4_" (d and p switched)
>
> Make things consistent and use "mdp4_" everywhere.
>
> Signed-off-by: Christophe JAILLET
> ---
Nice, thank you
Reviewed-by: Konra
On Thu, May 22, 2025 at 04:52:09PM +1000, Dave Airlie wrote:
Hey iosys_map users :)
I fell down a bit of a refactor hole today, it was just random and
sometimes you just have to let these things run their course.
I noticed iosys_map has a 7-byte hole in a 16-byte structure, and
it gets embedded
Functions and other stuff all start with "mdp4_", except a few ones that
start with "mpd4_" (d and p switched)
Make things consistent and use "mdp4_" everywhere.
Signed-off-by: Christophe JAILLET
---
The change has been done with:
sed -i s/mpd4/mdp4/g *
and the modified files have been compil
Fix the following kernel doc warning:
include/drm/drm_device.h:40: warning: Function parameter or struct member 'pid'
not described in 'drm_wedge_task_info'
include/drm/drm_device.h:40: warning: Function parameter or struct member
'comm' not described in 'drm_wedge_task_info'
Fixes: 183bccafa17
Remove the repetitive wording at the end of "Task information" section.
Signed-off-by: André Almeida
---
v3: new patch
---
Documentation/gpu/drm-uapi.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index
Fix the following warning:
Documentation/gpu/drm-uapi.rst:450: WARNING: Title underline too short.
Task information
--- [docutils]
Fixes: cd37124b4093 ("drm/doc: Add a section about "Task information" for the
wedge API")
Reported-by: Stephen Rothwell
Signed-off-by: André Almeida
-
On Fri, Jun 27, 2025 at 11:03:13AM +, 陈涛涛 Taotao Chen wrote:
> +++ b/fs/ext4/inode.c
> @@ -1270,6 +1270,9 @@ static int ext4_write_begin(const struct kiocb *iocb,
> if (unlikely(ret))
> return ret;
>
> + if (iocb->ki_flags & IOCB_DONTCACHE)
> + fgp |= FGP_D
ot tainted
6.16.0-rc3-next-20250627-dirty #15839 PREEMPT
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
unwind_backtrace from show_stack+0x10/0x14
show_stack from dump_stack_lvl+0x68/0x88
dump_stack_lvl from __warn+0x94/0x1f0
_
On Mon, Feb 26, 2024 at 5:43 AM Jacopo Mondi
wrote:
>
> Add FourCC definitions for the 48-bit RGB/BGR formats to the
> DRM/KMS uapi.
>
> The format will be used by the Raspberry Pi PiSP Back End,
> supported by a V4L2 driver in kernel space and by libcamera in
> userspace, which uses the DRM FourC
Thanks Andy and Dan for your detailed comments. I'll send a V2 with an
another clean up patch that fixes the order and removes devm for txbuf.
Regards,
Nihaal
On Thu, Jun 26, 2025 at 06:33:15PM -0500, Mario Limonciello wrote:
> On 6/26/25 4:47 PM, Bjorn Helgaas wrote:
> > On Thu, Jun 26, 2025 at 04:12:21PM -0500, Mario Limonciello wrote:
> > > On 6/26/2025 3:45 PM, Bjorn Helgaas wrote:
> > > > On Tue, Jun 24, 2025 at 03:30:42PM -0500, Mario Limonciello w
On Fri, Jun 27, 2025 at 04:03:32PM +0300, Raag Jadav wrote:
> On Thu, Jun 19, 2025 at 11:06:55AM -0300, André Almeida wrote:
> > Fix the following kernel doc warning:
> >
> > include/drm/drm_device.h:40: warning: Function parameter or struct member
> > 'pid' not described in 'drm_wedge_task_info'
On Fri, Jun 27, 2025 at 11:03:11AM +, 陈涛涛 Taotao Chen wrote:
> @@ -1399,13 +1400,10 @@ static int write_end_fn(handle_t *handle, struct
> inode *inode,
> }
>
> /*
> - * We need to pick up the new inode size which generic_commit_write gave us
> - * `file' can be NULL - eg, when called from
On Fri, Jun 27, 2025 at 11:03:11AM +, 陈涛涛 Taotao Chen wrote:
> diff --git a/fs/exfat/file.c b/fs/exfat/file.c
> index 841a5b18e3df..fdc2fa1e5c41 100644
> --- a/fs/exfat/file.c
> +++ b/fs/exfat/file.c
> @@ -532,10 +532,12 @@ int exfat_file_fsync(struct file *filp, loff_t start,
> loff_t end, in
On 6/27/2025 2:07 AM, Thomas Zimmermann wrote:
Hi
Am 27.06.25 um 06:31 schrieb Mario Limonciello:
From: Mario Limonciello
On systems with multiple GPUs there can be uncertainty which GPU is the
primary one used to drive the display at bootup. In order to disambiguate
this add a new sysfs attr
Use DRM's shadow-plane helper to map and access the GEM object's buffer
within kernel address space. Encasulates the vmap logic in the GEM-DMA
helpers.
The repaper driver currently reads the vaddr field from the GME buffer
object directly. This only works because GEM code 'automagically' sets
vadd
Use DRM's shadow-plane helper to map and access the GEM object's buffer
within kernel address space. Encasulates the vmap logic in the GEM-DMA
helpers.
The sharp-memory driver currently reads the vaddr field from the GME
buffer object directly. This only works because GEM code 'automagically'
sets
On 2025-06-27 14:44, Krzysztof Kozlowski wrote:
On 27/06/2025 15:44, Kaustabh Chakraborty wrote:
a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
+++
b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
@@ -80,6 +80,14 @@ properties:
XRGB is the default mode that Xorg will want to use. Add support
for this to the Zynqmp DisplayPort driver, so that applications can use
32-bit framebuffers. This solves that the X server would fail to start
unless one provided an xorg.conf that sets DefaultDepth to 16.
Signed-off-by: Mike Loo
[Public]
> -Original Message-
> From: long.yunj...@zte.com.cn
> Sent: Friday, June 20, 2025 11:28 PM
> To: Wentland, Harry
> Cc: Li, Sun peng (Leo) ; sique...@igalia.com; Deucher,
> Alexander ; Koenig, Christian
> ; airl...@gmail.com; sim...@ffwll.ch;
> fang.yum...@zte.com.cn; amd-...@li
[Public]
> -Original Message-
> From: long.yunj...@zte.com.cn
> Sent: Friday, June 20, 2025 11:26 PM
> To: Deucher, Alexander
> Cc: Koenig, Christian ; airl...@gmail.com;
> sim...@ffwll.ch; Zhang, Hawking ; Wang,
> Yang(Kevin) ; Liu, Xiang(Dean)
> ; Zhou1, Tao ; yanz...@vivo.com;
> fang.
On 27/06/2025 15:44, Kaustabh Chakraborty wrote:
>>> a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
>>> +++
>>> b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml
>>> @@ -80,6 +80,14 @@ properties:
>>>- const: vsync
>>>- c
On 26-06-2025 09:20, Gupta, Anshuman wrote:
-Original Message-
From: Nilawar, Badal
Sent: Wednesday, June 25, 2025 10:30 PM
To: intel...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; linux-
ker...@vger.kernel.org
Cc: Gupta, Anshuman ; Vivi, Rodrigo
; Usyskin, Alexander ;
gr
On 2025-06-27 04:06, Inki Dae wrote:
Hi,
2025년 6월 27일 (금) 오전 4:21, Kaustabh Chakraborty
님이 작성:
decon_commit() has a condition guard at the beginning:
if (ctx->suspended)
return;
But, when it is being called from decon_atomic_enable(),
ctx->suspended
is still set to
On 2025-06-27 07:50, Krzysztof Kozlowski wrote:
On Fri, Jun 27, 2025 at 12:50:28AM +0530, Kaustabh Chakraborty wrote:
Similar to FIMD and Exynos5433's DECON, the Exynos7 DECON hardware:
- May optionally require an IOMMU to initialize a display region.
- May require a port connection to another b
Hi Louis,
On 27/06/25 06:12, Louis Chauvet wrote:
Some YUV format uses 16 bit values, so change the helper function for
conversion to support those new formats.
Signed-off-by: Louis Chauvet > ---
drivers/gpu/drm/vkms/tests/vkms_format_test.c | 139 +-
drivers/gpu/drm/
On 27/06/2025 11:40, Yongxing Mou wrote:
On 2025/6/25 22:03, Dmitry Baryshkov wrote:
On Wed, Jun 25, 2025 at 08:34:18PM +0800, Yongxing Mou wrote:
On 2025/6/9 20:48, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:21PM +0800, Yongxing Mou wrote:
From: Abhinav Kumar
Originally,
Hi Louis,
On 27/06/25 06:12, Louis Chauvet wrote:
The formats NV 12/16/24/21/61/42 were already supported.
Add support for:
- P010
- P012
- P016
Signed-off-by: Louis Chauvet
Reviewed-by: Maíra Canal
Best Regards,
- Maíra
---
drivers/gpu/drm/vkms/vkms_formats.c | 7 ++-
drivers/gpu
Le 27/06/2025 à 15:17, Maíra Canal a écrit :
Hi Louis,
On 27/06/25 06:12, Louis Chauvet wrote:
The formats XRGB and ARGB were already supported. Add the
support for: - XBGR - RGBX - BGRX - ABGR - RGBA -
BGRA
Please, remove RGBX and BGRX from this lis
Manually setting/forcing the connector status in sysfs does not
propagate the CONNECTOR ID. For drivers that use polling, including
manually setting it up with sysfs this would similarly to the HDP IRQ
path which can pass it through drm_connector_helper_hpd_irq_event().
Signed-off-by: Marius Vlad
Hi Louis,
On 27/06/25 06:12, Louis Chauvet wrote:
The formats XRGB and ARGB were already supported. Add the
support for: - XBGR - RGBX - BGRX - ABGR - RGBA -
BGRA
Please, remove RGBX and BGRX from this list. Also, for
readability, it would be great if yo
On Thu, Jun 19, 2025 at 11:06:55AM -0300, André Almeida wrote:
> Fix the following kernel doc warning:
>
> include/drm/drm_device.h:40: warning: Function parameter or struct member
> 'pid' not described in 'drm_wedge_task_info'
> include/drm/drm_device.h:40: warning: Function parameter or struct
On Thu, Jun 19, 2025 at 11:06:54AM -0300, André Almeida wrote:
> Fix the following warning:
>
> Documentation/gpu/drm-uapi.rst:450: WARNING: Title underline too short.
>
> Task information
> --- [docutils]
>
> Fixes: cd37124b4093 ("drm/doc: Add a section about "Task information" for
On Fri, Jun 20, 2025 at 8:45 AM Rob Clark wrote:
>
> For UNMAP/REMAP steps we could be needing to lock objects that are not
> explicitly listed in the VM_BIND ioctl in order to tear-down unmapped
> VAs. These helpers handle locking/preparing the needed objects.
>
> Note that these functions do no
On 27/06/2025 11:40, Yongxing Mou wrote:
On 2025/6/25 22:03, Dmitry Baryshkov wrote:
On Wed, Jun 25, 2025 at 08:34:18PM +0800, Yongxing Mou wrote:
On 2025/6/9 20:48, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:21PM +0800, Yongxing Mou wrote:
From: Abhinav Kumar
dp_display cach
On 6/27/25 1:23 PM, Konrad Dybcio wrote:
> On 6/27/25 12:33 PM, Ling Xu wrote:
>> Currently, domain ids are added for each instance, which is not a scalable.
>
> 's/ a//g'
>
> [...]
>
>> -/* Unsigned PD offloading is only supported on CDSP and CDSP1 */
>> +/* Unsigned
On 27-06-2025 02:36, Daniele Ceraolo Spurio wrote:
On 6/25/2025 10:00 AM, Badal Nilawar wrote:
Search for late binding firmware binaries and populate the meta data of
firmware structures.
v2 (Daniele):
- drm_err if firmware size is more than max pay load size
- s/request_firmware/firmwa
On 27/06/2025 10:49, Yongxing Mou wrote:
On 2025/6/25 21:32, Dmitry Baryshkov wrote:
On Wed, Jun 25, 2025 at 04:43:55PM +0800, Yongxing Mou wrote:
On 2025/6/9 20:41, Dmitry Baryshkov wrote:
On Mon, Jun 09, 2025 at 08:21:20PM +0800, Yongxing Mou wrote:
From: Abhinav Kumar
In preparation
On 32bits ARM, u64 divided by a constant is not optimized to a
multiply by inverse by the compiler [1].
So do the multiply by inverse explicitly for this architecture.
Link: https://github.com/llvm/llvm-project/issues/37280 [1]
Reported-by: Andrei Lalaev
Closes:
https://lore.kernel.org/dri-devel
On 27.06.25 10:20, Thomas Zimmermann wrote:
> A GEM handle can be released while the GEM buffer object is attached
> to a DRM framebuffer. This leads to the release of the dma-buf backing
> the buffer object, if any. [1] Trying to use the framebuffer in further
> mode-setting operations leads to a
On Fri, 2025-06-27 at 01:32 +, CK Hu (胡俊光) wrote:
> On Wed, 2025-06-25 at 14:49 -0400, Nícolas F. R. A. Prado wrote:
> > External email : Please do not click links or open attachments
> > until you have verified the sender or the content.
> >
> >
> > On Wed, 2025-06-25 at 17:54 +0800, Liankun
Hi Jeff,
> On Mon, 2025-06-23 at 14:01 +, Krzysztof Karas wrote:
> > Hi Jeff,
> >
> > [...]
> > > +static __maybe_unused int
> > > +ref_tracker_dir_seq_print(struct ref_tracker_dir *dir, struct seq_file
> > > *seq)
> > > +{
> > > + struct ostream os = { .func = pr_ostream_seq,
> > > +
On 6/27/25 12:33 PM, Ling Xu wrote:
> The fastrpc driver has support for 5 types of remoteprocs. There are
> some products which support GDSP remoteprocs. GDSP is General Purpose
> DSP where tasks can be offloaded. This patch extends the driver to
> support GDSP remoteprocs.
>
> Signed-off-by: Lin
On 2025-06-27 10:07, Inki Dae wrote:
2025년 6월 27일 (금) 오전 4:42, Kaustabh Chakraborty
님이 작성:
Exynos7870's DSIM has separate registers for LINK and DPHY status.
This
is in contrast to other devices in the driver which use a single
register for both.
Add their respective entries in the register
On 6/27/25 12:33 PM, Ling Xu wrote:
> Currently, domain ids are added for each instance, which is not a scalable.
's/ a//g'
[...]
> - /* Unsigned PD offloading is only supported on CDSP and CDSP1 */
> + /* Unsigned PD offloading is only supported on CDSP*/
missing space
On 6/27/25 12:33 PM, Ling Xu wrote:
> Add GDSP0 and GDSP1 fastrpc compute-cb nodes for sa8775p SoC.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Ling Xu
> ---
Reviewed-by: Konrad Dybcio
Konrad
On Fri, Jun 27, 2025 at 01:33:04PM +0200, Javier Martinez Canillas wrote:
> The commit d391c5827107 ("drivers/firmware: move x86 Generic System
> Framebuffers support") moved the sysfb*.c source files from arch/x86
> to drivers/firmware, because the logic wasn't x86 specific and could
> be used by
On 27/06/2025 13:44, Miguel Ojeda wrote:
On Fri, Jun 27, 2025 at 11:41 AM Jocelyn Falempe wrote:
+/// On arm32 architecture, dividing an u64 by a constant will generate a call
+/// to __aeabi_uldivmod which is not present in the kernel.
+/// So use the multiply by inverse method for this archi
On 27/06/2025 13:36, Alice Ryhl wrote:
On Fri, Jun 27, 2025 at 11:41 AM Jocelyn Falempe wrote:
On 32bits ARM, u64 divided by a constant is not optimized to a
multiply by inverse by the compiler [1].
So do the multiply by inverse explicitly for this architecture.
Link: https://github.com/llvm/
Thomas Zimmermann writes:
> Hi
[...]
>> These two functions contain the same logic that you are using in the
>> simpledrm driver. I wonder if could be made helpers so that the code
>> isn't duplicated in both drivers.
>
> No please not!. Any work should rather be directed towards deleting
> si
On Di, 2025-05-27 at 16:21 +0200, Philipp Zabel wrote:
> Replace an open-coded goto-again construct with a while loop and a
> custom MHZ macro with the common HZ_PER_MHZ.
>
> Signed-off-by: Philipp Zabel
> ---
> Philipp Zabel (2):
> drm/bridge: samsung-dsim: use while loop in samsung_dsim_t
Drop the unused MIPI_DSI_MODE_VSYNC_FLUSH flag. Whether or not a display
FIFO flush on vsync is required to avoid sending garbage to the panel is
not a property of the DSI link, but of the integration between display
controller and DSI host bridge.
Acked-by: Marek Szyprowski
Signed-off-by: Philip
This series enables the vsync flush feature in the samsung-dsim driver
unconditionally and removes the MIPI_DSI_MODE_VSYNC_FLUSH flag.
Background: I've recently seen shifted display issues on two different
i.MX8MM boards (mxsfb + samsung-dsim) with different DSI panels.
The symptoms were horizonal
Drop the MIPI_DSI_MODE_VSYNC_FLUSH flag from DSI mode_flags.
It has no effect anymore.
Acked-by: Marek Szyprowski
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-samsun
Always flush the display FIFO on vsync pulse, even if not explicitly
requested by the panel via MIPI_DSI_MODE_VSYNC_FLUSH mode_flag.
The display FIFO should be empty at vsync. Flushing it at vsync pulses
helps to remove garbage that may have entered the FIFO during startup
(if synchronisation betw
Drop the MIPI_DSI_MODE_VSYNC_FLUSH flag from DSI mode_flags.
It has no effect anymore.
Acked-by: Marek Szyprowski
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/panel/panel-samsung-s6d7aa0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-samsun
On Fri, Jun 27, 2025 at 11:41 AM Jocelyn Falempe wrote:
>
> +/// On arm32 architecture, dividing an u64 by a constant will generate a call
> +/// to __aeabi_uldivmod which is not present in the kernel.
> +/// So use the multiply by inverse method for this architecture.
This sounds more like a nor
On Fri, Jun 27, 2025 at 1:37 PM Alice Ryhl wrote:
>
> I would get rid of this conditional and declare another div10 function
> that just does input/10 on other arches.
Yeah, please keep `cfg`s as local as possible, i.e. inside the
implementation of the function where possible, so that we share ev
Hi
Am 27.06.25 um 13:33 schrieb Javier Martinez Canillas:
The commit d391c5827107 ("drivers/firmware: move x86 Generic System
Framebuffers support") moved the sysfb*.c source files from arch/x86
to drivers/firmware, because the logic wasn't x86 specific and could
be used by other architectures.
On Fri, Jun 27, 2025 at 11:41 AM Jocelyn Falempe wrote:
>
> On 32bits ARM, u64 divided by a constant is not optimized to a
> multiply by inverse by the compiler [1].
> So do the multiply by inverse explicitly for this architecture.
>
> Link: https://github.com/llvm/llvm-project/issues/37280 [1]
>
Hi
Am 27.06.25 um 09:56 schrieb Javier Martinez Canillas:
Luca Weiss writes:
Some devices might require keeping an interconnect path alive so that
the framebuffer continues working. Add support for that by setting the
bandwidth requirements appropriately for all provided interconnect
paths.
1 - 100 of 184 matches
Mail list logo
