Hello Cristian,
在 2025-07-22 14:16:26，"Cristian Ciocaltea"
写道：
>Hi Andy,
>
>On 7/22/25 5:24 AM, Andy Yan wrote:
>>
>> Hello Cristian，
>>
>> At 2025-07-22 01:39:04, "Cristian Ciocaltea"
>> wrote:
>>> Take the bits per color channel into consideration when computing DCLK
>>> rate.
>>>
>>> Sig
Hi Andy,
On 7/22/25 5:24 AM, Andy Yan wrote:
>
> Hello Cristian，
>
> At 2025-07-22 01:39:04, "Cristian Ciocaltea"
> wrote:
>> Take the bits per color channel into consideration when computing DCLK
>> rate.
>>
>> Signed-off-by: Cristian Ciocaltea
>> ---
>> drivers/gpu/drm/rockchip/rockchip_drm
Hi,
On 7/21/25 6:38 PM, Lucas De Marchi wrote:
> On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
>>
>>
>> On 7/21/25 12:41 AM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> Changes since 20250718:
>>>
>>
>> on ARCH=um SUBARCH=i386, when
>> # CONFIG_DEBUG_FS is not set
>
> can you shar
On 21/07/2025 9:59, Christoph Hellwig wrote:
On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
From: Yonatan Maman
hmm_range_fault() by default triggered a page fault on device private
when HMM_PFN_REQ_FAULT flag was set. pages, migrating them to RAM. In some
cases, such as wit
On 21/07/2025 10:00, Christoph Hellwig wrote:
On Fri, Jul 18, 2025 at 02:51:09PM +0300, Yonatan Maman wrote:
+ .get_dma_pfn_for_device = nouveau_dmem_get_dma_pfn,
Please don't shorten the method name prefix in the implementation
symbol name, as that makes reading / refactoring the cod
From: Mario Limonciello
There is a desire to avoid creating new sysfs files late, so instead
of dynamically deciding to create the boot_display attribute, make
it static.
This also fixes a compilation failure when compiled without
CONFIG_VIDEO on sparc.
Reported-by: Stephen Rothwell
Closes:
h
From: Mario Limonciello
screen_info_pci_dev() relies upon resources being set up for devices
before walking and thus isn't a good candidate for video_is_primary_device()
when called as part of PCI device initialization.
The device argument passed to video_is_primary_device() already has the
nece
From: Mario Limonciello
The past few days there have been various discussions about what to do
with the boot_display sysfs file so that it doesn't need to be made so
late in startup.
Bjorn had an aha moment pointing out that there is no reason to "find"
the PCI device using screen_info_pci_dev()
On 7/21/25 8:59 PM, Bjorn Helgaas wrote:
On Mon, Jul 21, 2025 at 07:28:07PM -0500, Mario Limonciello wrote:
On 7/21/25 6:00 PM, Bjorn Helgaas wrote:
On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
On Fri, Jul 18, 2025 at 12:29:
On Mon, Jul 21, 2025 at 3:48 AM Vincent Mailhol
wrote:
>
> On 21/07/2025 at 00:24, Luis Felipe Hernandez wrote:
> > Fix kernel-doc issues that reported Unexpected indentation errors
> > durring documentation build (make htmldocs) in CAN, I3C and GPU drivers.
> ^^^
> during
>
> > Convert form
Add 50ms disable delay for NV116WHM-N49, NV122WUM-N41, and MNC207QS1-1
to satisfy T9+T10 timing.
Fixes: 0547692ac146 ("drm/panel-edp: Add several generic edp panels")
Signed-off-by: Langyan Ye
---
drivers/gpu/drm/panel/panel-edp.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletion
Hello Cristian，
At 2025-07-22 01:39:04, "Cristian Ciocaltea"
wrote:
>Take the bits per color channel into consideration when computing DCLK
>rate.
>
>Signed-off-by: Cristian Ciocaltea
>---
> drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/
On Mon, Jul 21, 2025 at 07:28:07PM -0500, Mario Limonciello wrote:
> On 7/21/25 6:00 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
> > > On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
> > > > On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello
Update TODO item from drm documentation to contain more applicable
information regarding the removal of deprecated MIPI DSI functions and
no longer reference functions which have already been removed from the
kernel.
Reviewed-by: Douglas Anderson
Signed-off-by: Brigham Campbell
---
Documentatio
Remove the deprecated mipi_dsi_generic_write_seq() and
mipi_dsi_generic_write_chatty() functions now that they are no longer
used.
Reviewed-by: Douglas Anderson
Signed-off-by: Brigham Campbell
---
drivers/gpu/drm/drm_mipi_dsi.c | 34 +++---
include/drm/drm_mipi_dsi.h
Fix bug in unprepare() which causes the function's return value to be
that of the last mipi "enter sleep mode" command.
Update driver to use the "multi" variant of MIPI functions in order to
facilitate improved error handling and remove the panel's dependency on
deprecated MIPI functions.
Use the
Create mipi_dsi_dual, mipi_dsi_dual_dcs_write_seq_multi, and
mipi_dsi_dual_generic_write_seq_multi macros for panels which are driven
by two parallel serial interfaces. This allows for the reduction of code
duplication in drivers for these panels.
Remove mipi_dsi_dual_dcs_write_seq_multi definitio
This series removes the unintuitive mipi_dsi_generic_write_seq() macro
and related mipi_dsi_generic_write_chatty() method from the drm
subsystem. This is in accordance with a TODO item from Douglas Anderson
in the drm subsystem documentation. Tejas Vipin (among others) has
largely spearheaded this
From: Dave Airlie
This adds a kconfig and a module option to turn off ttm memcg
integration completely.
When this is used, no object will ever end up using memcg aware
paths.
There is an existing workload that cgroup support might regress,
the systems are setup to allocate 1GB of uncached pages
From: Dave Airlie
This adds support for adding a obj cgroup to a buffer object,
and passing in the placement flags to make sure it's accounted
properly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 +-
From: Dave Airlie
amdgpu wants to use the objcg api and not have to enable ifdef
around it, so just add a dummy function for the config off path.
Signed-off-by: Dave Airlie
---
include/linux/memcontrol.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/memcontrol.h b/incl
From: Dave Airlie
This adds a placement flag that requests that any bo with this
placement flag set gets accounted for memcg if it's a system memory
allocation.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/dr
From: Dave Airlie
This enables all the backend code to use the list lru in memcg mode,
and set the shrinker to be memcg aware.
It adds the loop case for when pooled pages end up being reparented
to a higher memcg group, that newer memcg can search for them there
and take them back.
Signed-off-b
From: Dave Airlie
This just adds the obj cgroup pointer to the bo and tt structs,
and sets it between them.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_tt.c | 1 +
include/drm/ttm/ttm_bo.h | 6 ++
include/drm/ttm/ttm_tt.h | 2 ++
3 files changed, 9 insertions(+)
diff --
Hi all,
This is a 2nd repost with some fixes and cleanups. Original post is below.
https://lore.kernel.org/dri-devel/20250714052243.1149732-1-airl...@gmail.com/
is the 2nd post.
https://lore.kernel.org/dri-devel/20250630045005.1337339-1-airl...@gmail.com/
is the 1st post.
Differences since las
From: Dave Airlie
Later memcg enablement needs the shrinker initialised before the list lru,
Just move it for now.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_pool.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_
From: Dave Airlie
This introduces 2 new statistics and 3 new memcontrol APIs for dealing
with GPU system memory allocations.
The stats corresponds to the same stats in the global vmstat,
for number of active GPU pages, and number of pages in pools that
can be reclaimed.
The first API charges a
From: Dave Airlie
This flag does nothing yet, but this just changes the APIs to accept
it in the future across all users.
This flag will eventually be filled out with when to account a tt
populate to a memcg.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3
From: Dave Airlie
This gets the memory sizes from the nodes and stores the limit
as 50% of those. I think eventually we should drop the limits
once we have memcg aware shrinking, but this should be more NUMA
friendly, and I think seems like what people would prefer to
happen on NUMA aware systems
From: Dave Airlie
This enable NUMA awareness for the shrinker on the
ttm pools.
Cc: Christian Koenig
Cc: Dave Chinner
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_pool.c | 38 +++---
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/drivers
From: Dave Airlie
The list_lru will now handle numa for us, so need to keep
separate pool types for it. Just consoldiate into the global ones.
This adds a debugfs change to avoid dumping non-existant orders due
to this change.
Cc: Christian Koenig
Cc: Johannes Weiner
Signed-off-by: Dave Airli
From: Dave Airlie
This is an initial port of the TTM pools for
write combined and uncached pages to use the list_lru.
This makes the pool's more NUMA aware and avoids
needing separate NUMA pools (later commit enables this).
Cc: Christian Koenig
Cc: Johannes Weiner
Cc: Dave Chinner
Signed-off
From: Dave Airlie
This uses the newly introduced per-node gpu tracking stats,
to track GPU memory allocated via TTM and reclaimable memory in
the TTM page pools.
These stats will be useful later for system information and
later when mem cgroups are integrated.
Cc: Christian Koenig
Cc: Matthew
From: Dave Airlie
While discussing memcg intergration with gpu memory allocations,
it was pointed out that there was no numa/system counters for
GPU memory allocations.
With more integrated memory GPU server systems turning up, and
more requirements for memory tracking it seems we should start
c
On Mon, Jul 21, 2025 at 01:17:33PM -0700, Randy Dunlap wrote:
On 7/21/25 12:41 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20250718:
on ARCH=um SUBARCH=i386, when
# CONFIG_DEBUG_FS is not set
can you share your entire config? I have all of the settings above, but
I can't reproduce
On Mon, 21 Jul 2025 18:18:48 +0400 Pingfan Liu wrote
---
> IMHO, you could try blacklisting the i915 module to see if
I did this. Problem is in i915.
Here you can see our discussion with i915 devs:
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14598
--
Askar Safin
https://type
On Mon, Jul 21, 2025 at 02:23:13PM +0100, Matthew Wilcox wrote:
> On Fri, Jul 18, 2025 at 11:44:42AM -0300, Jason Gunthorpe wrote:
> > On Fri, Jul 18, 2025 at 03:17:00PM +0100, Matthew Wilcox wrote:
> > > On Fri, Jul 18, 2025 at 02:51:08PM +0300, Yonatan Maman wrote:
> > > > +++ b/include/linux/mem
On Mon Jul 21, 2025 at 10:30 AM MDT, Doug Anderson wrote:
>> +void mpi_dsi_dual_generic_write_multi(struct mipi_dsi_device *dsi1,
>
> BUG: above should be "mipi", not "mpi"
>
>> + struct mipi_dsi_device *dsi2,
>> + struct mipi_
On 7/21/25 6:00 PM, Bjorn Helgaas wrote:
On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello wrote:
On 7/18/2025 12:25 PM, Bjorn Helgaas wrote:
On Thu, Jul 17, 2025 at 12:
The debug logging in gud_disconnect() adds zero detail and is
unnecessary, as it only prints the function name.
The same functionality can be achieved by using ftrace, and is
highlighted by checkpatch, stating the same.
This patch removes the debug log in the gud_disconnect() function.
Signed-of
> > On 14.07.25 07:18, Dave Airlie wrote:
> > > From: Dave Airlie
> > >
> > > This enables all the backend code to use the list lru in memcg mode,
> > > and set the shrinker to be memcg aware.
> > >
> > > It adds the loop case for when pooled pages end up being reparented
> > > to a higher memcg g
On Fri, Jul 18, 2025 at 12:44:11PM -0500, Mario Limonciello wrote:
> On 7/18/2025 12:36 PM, Bjorn Helgaas wrote:
> > On Fri, Jul 18, 2025 at 12:29:05PM -0500, Mario Limonciello wrote:
> > > On 7/18/2025 12:25 PM, Bjorn Helgaas wrote:
> > > > On Thu, Jul 17, 2025 at 12:38:12PM -0500, Mario Limonciel
Qualcomm is changing open source email address policy.
LKML and other busy mailing lists use the oss.qualcomm.com domain.
Signed-off-by: Carl Vanderlip
---
.mailmap| 2 ++
MAINTAINERS | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index b77cd34cf852
This patch adds firmware binary and GPU model naming support for
Mali-Gx20 and Mali-Gx25 GPUs.
The GPU_COHERENCY_FEATURES macros are slightly reworked as the
assumption that FEATURE = BIT(PROTOCOL) no longer holds with the
introduction of the SHAREABLE_CACHE_SUPPORT, which is BIT(5) on the
GPU_COH
This patch adds GPU model name and FW binary support for Mali-G710,
Mali-G510, and Mali-G310.
Reviewed-by: Liviu Dudau
Signed-off-by: Karunika Choo
---
drivers/gpu/drm/panthor/panthor_fw.c | 2 ++
drivers/gpu/drm/panthor/panthor_hw.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/dr
This patch replaces the panthor_model structure with a simple switch
case based on the product_id which is in the format of:
((arch_major << 24) | product_major)
This simplifies comparison and allows extending of the function to
accommodate naming differences based on supported GPU feature
As the FLUSH_MEM and FLUSH_PT MMU_AS commands are deprecated in GPUs
from Mali-Gx20 onwards, this patch adds support for performing cache
maintenance via the FLUSH_CACHES command in GPU_COMMAND in place of
FLUSH_MEM and FLUSH_PT commands.
Mali-Gx10 and Mali-Gx15 GPUs also has support for the FLUSH
This patch series introduces some minor refactoring to enable support
for new Mali GPUs.
Key changes:
- Addition of cache maintenance via the FLUSH_CACHES GPU command for all
supported GPUs in place of FLUSH_MEM and FLUSH_PT MMU_AS commands.
- Added SHAREABLE_CACHE support for GPUs from Mali-Gx2
This patch introduces panthor_hw and moves the initialization of the
gpu_info struct into panthor_hw.c in preparation of handling future GPU
register and naming changes.
Future GPU support can be added by extending panthor_gpu_info_init()
with the necessary register reads behind GPU architecture v
Mali-Gx15 introduces a new GPU_FEATURES register that provides
information about GPU-wide supported features. The register value will
be passed on to userspace via gpu_info.
Additionally, Mali-Gx15 presents an 'Immortalis' naming variant
depending on the shader core count and presence of Ray Inter
Hi,
On Sun, Jul 20, 2025 at 11:16 PM Langyan Ye
wrote:
>
> For the MNB601LS1-4 panel, the T9+T10 timing does not meet the
> requirements of the specification, so disable is set to 100ms.
>
> Fixes: 9d8e91439fc3 ("drm/panel-edp: Add CSW MNB601LS1-4")
> Signed-off-by: Langyan Ye
> ---
> drivers/g
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Reduce coupling to implementation details of the formatting machinery by
> avoiding direct use for `core`'s formatting traits and macros.
>
> Acked-by: Greg Kroah-Hartman
> Reviewed-by: Alice Ryhl
> Reviewed-by: Benno Lossin
> Acked-b
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Reduce coupling to implementation details of the formatting machinery by
> avoiding direct use for `core`'s formatting traits and macros.
>
> Acked-by: Greg Kroah-Hartman
> Reviewed-by: Alice Ryhl
> Reviewed-by: Benno Lossin
> Acked-b
On Mon, Jul 21, 2025 at 10:31 PM Tamir Duberstein wrote:
>
> Yes, please do. I did indeed use b4 - and Alice also let me know that
> this was not correct. Sorry about that! Same is true for 2a, I'll
> reply to that email as well.
Sounds good, thanks for confirming!
> I believe it was for everyth
On Mon, Jul 21, 2025 at 4:25 PM Miguel Ojeda
wrote:
>
> On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
> >
> > Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> > can be taken through Miguel's tree (where the other series must go).
>
> Same here as in step 2b/5,
On Mon, Jul 21, 2025 at 4:20 PM Miguel Ojeda
wrote:
>
> On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
> >
> > Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> > can be taken through Miguel's tree (where the other series must go).
>
> Did you apply this with `b4
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> can be taken through Miguel's tree (where the other series must go).
Same here as in step 2b/5, i.e. Danilo's Acked-by was picked up for
things he didn't Acked-by
On Sun, Jul 20, 2025 at 12:42 AM Tamir Duberstein wrote:
>
> Subsystem maintainers: I would appreciate your `Acked-by`s so that this
> can be taken through Miguel's tree (where the other series must go).
Did you apply this with `b4`? I think you picked Danilo's Acked-by,
which was for a subset, f
On 7/21/25 12:41 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20250718:
>
on ARCH=um SUBARCH=i386, when
# CONFIG_DEBUG_FS is not set
ERROR: modpost: "gt_reset_failure" [drivers/gpu/drm/xe/xe.ko] undefined!
--
~Randy
On Mon, 21 Jul 2025 12:43:33 +0200, Marcus Folkesson wrote:
> Depending on which display that is connected to the controller, an "1"
> means either a black or a white pixel.
>
> The supported format (R1) expects the pixels to map against:
> 0 => Black
> 1 => White
>
> If this is not wha
On Mon, 21 Jul 2025 12:43:32 +0200, Marcus Folkesson wrote:
> Depending on which display that is connected to the controller, an "1"
> means either a black or a white pixel.
>
> The supported formats (R1/R2/XRGB) expects the pixels
> to map against (4bit):
> 00 => Black
> 01 => Dark Gray
> 1
Hi
Am 21.07.25 um 13:43 schrieb Ilpo Järvinen:
On Tue, 15 Jul 2025, Thomas Zimmermann wrote:
The backlight subsystem has gotten its own power constants. Replace
FB_BLANK_UNBLANK with BACKLIGHT_POWER_ON.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Hans de Goede
Acked-by: Ilpo Järvinen
---
This is inteded to address concerns that users might get cryptic error
messages or a failure to boot if they set nouveau.config=NvGspRm=0 on
the kernel command line and their gpu requires gsp (Ada or newer).
With this patch, that configuration results in error messages like this:
nouveau :01:0
This struct element is no longer used.
Signed-off-by: Mel Henning
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/ad102.c | 4 ++--
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gb100.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/gb202.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/su
This option was originally intoduced because the GSP code path was
not well tested and we wanted to leave it up to distros which code path
they shipped by default. By now though, the GSP path is probably better
tested than the old firmware eg. Fedora ships GSP by default and we
generally run CTS on
Following earlier discussion at
https://lists.freedesktop.org/archives/nouveau/2025-June/047887.html
this series removes DRM_NOUVEAU_GSP_DEFAULT.
The first two patches are the same as they were in V1. V2 adds a third
commit that improves an error message in response to feedback from V1.
Mel Henni
From: Mario Limonciello
The boot_display attribute is currently created by PCI core, but the
main reason it exists is for userspace software that interacts with
drm to make decisions. Move the attribute to DRM.
This also fixes a compilation failure when compiled without
CONFIG_VIDEO on sparc.
S
From: Mario Limonciello
Shortly after the series for introducing boot_display was merged
Manivannan Sadhasivam suggested that it's better not to introduce
new top level PCI attributes where possible.
He proposed that the boot_display attribute should be provided by DRM
instead and that userspace
On Mon, Jul 21, 2025 at 12:14:31PM +0200, Danilo Krummrich wrote:
> On Mon Jul 21, 2025 at 10:16 AM CEST, Philipp Stanner wrote:
> > On Mon, 2025-07-21 at 09:52 +0200, Philipp Stanner wrote:
> >> On Sun, 2025-07-20 at 16:56 -0700, James Flowers wrote:
> >> > diff --git a/drivers/gpu/drm/scheduler/s
Take the bits per color channel into consideration when computing DCLK
rate.
Signed-off-by: Cristian Ciocaltea
---
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
b/drivers/gpu/drm/rockchip/rockchip
Stop relying on phy_set_bus_width() based workaround to setup the TMDS
character rate and, instead, use the recently introduced HDMI PHY
configuration API. This is also a prerequisite to enable high color
depth and FRL support.
Additionally, move the logic to ->atomic_check() callback where the
c
Extend struct dw_hdmi_qp_plat_data to include the supported display
output formats and maximum bits per color channel. When provided by the
platform driver, use them to setup the HDMI bridge accordingly.
Additionally, improve debug logging in dw_hdmi_qp_bridge_atomic_enable()
to also show the cur
Since both RK3576 and RK3588 SoCs are capable of handling 10 bpc color
depth, introduce a pair of new helpers to program the necessary
registers, as well as passing bpc at PHY configuration level.
Note max_bpc is unconditionally set to 10 before initializing the QP
bridge library, as there is no n
For consistency and improved readability, redefine a few RK3576 specific
register configurations by relying on GENMASK() and unshifted values for
color depth and output format. Those are not used at the moment, but
will be needed soon to support the related features.
While at it, drop a few other
| 4 +
4 files changed, 97 insertions(+), 34 deletions(-)
---
base-commit: 97987520025658f30bb787a99ffbd9bbff9ffc9d
change-id: 20250721-rk3588-10bpc-85ff4c228e63
пн, 23 черв. 2025 р. о 11:15 Svyatoslav Ryhel пише:
>
> Solomon SSD2825 is a RGB to MIPI DSI bridge used in LG Optimus 4D P880
> and LG Optimus Vu P895
>
> ---
> Changes on switching from v6 to v7:
> - removed enabled checks
> - configuration complete quirk moved from host_transfer to
> atomic_e
Hi,
On Sat, Jul 19, 2025 at 1:27 AM Brigham Campbell
wrote:
>
> @@ -827,6 +827,30 @@ void mipi_dsi_generic_write_multi(struct
> mipi_dsi_multi_context *ctx,
> }
> EXPORT_SYMBOL(mipi_dsi_generic_write_multi);
>
> +/**
> + * mipi_dsi_dual_generic_write_multi() - mipi_dsi_generic_write_multi() f
On Thu Jun 26, 2025 at 6:23 PM CEST, Beata Michalska wrote:
> With the Opaque, the expectations are that Rust should not
> make any assumptions on the layout or invariants of the wrapped
> C types. That runs rather counter to ioctl arguments, which must
> adhere to certain data-layout constraints.
On 7/21/2025 9:24 AM, Heiko Stübner wrote:
Hi Jeff,
Am Montag, 21. Juli 2025, 16:55:01 Mitteleuropäische Sommerzeit schrieb Jeff
Hugo:
On 7/21/2025 3:17 AM, Tomeu Vizoso wrote:
This series adds a new driver for the NPU that Rockchip includes in its
newer SoCs, developed by them on the NVDLA b
From: Hugo Villeneuve
Fix typo in comments:
souch -> such.
Signed-off-by: Hugo Villeneuve
---
drivers/gpu/drm/panel/panel-sitronix-st7703.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7703.c
b/drivers/gpu/drm/panel/panel-sitro
Hi,
On Sun, Jul 20, 2025 at 4:19 AM Diogo Ivo wrote:
>
> On 7/20/25 8:50 AM, Brigham Campbell wrote:
> > On Sat Jul 19, 2025 at 11:10 AM MDT, Diogo Ivo wrote:
> >>> nit: can just be this:
> >>>
> >>> struct mipi_dsi_multi_context dsi_ctx = {};
> >>
> >> I am not an expert here but I was under the
> On 26 Jun 2025, at 13:23, Beata Michalska wrote:
>
> With the Opaque, the expectations are that Rust should not
> make any assumptions on the layout or invariants of the wrapped
> C types. That runs rather counter to ioctl arguments, which must
> adhere to certain data-layout constraints. By
> On 21 Jul 2025, at 12:33, Danilo Krummrich wrote:
>
> On Thu Jun 26, 2025 at 6:23 PM CEST, Beata Michalska wrote:
>> With the Opaque, the expectations are that Rust should not
>> make any assumptions on the layout or invariants of the wrapped
>> C types. That runs rather counter to ioctl arg
On Thu Jun 26, 2025 at 6:23 PM CEST, Beata Michalska wrote:
> With the Opaque, the expectations are that Rust should not
> make any assumptions on the layout or invariants of the wrapped
> C types. That runs rather counter to ioctl arguments, which must
> adhere to certain data-layout constraints.
Hi,
On Mon, Jul 14, 2025 at 1:07 PM Douglas Anderson wrote:
>
> As report by the kernel test robot, a recent patch introduced an
> unnecessary semicolon. Remove it.
>
> Fixes: 55e8ff842051 ("drm/bridge: ti-sn65dsi86: Add HPD for DisplayPort
> connector type")
> Reported-by: kernel test robot
>
On Fri, Jul 18, 2025 at 5:54 AM Dmitry Baryshkov
wrote:
>
> On Fri, Jul 18, 2025 at 04:23:57PM +0530, Vignesh Raman wrote:
> > Uprev IGT to the latest version and update expectation files.
> >
> > Signed-off-by: Vignesh Raman
> > ---
> > drivers/gpu/drm/ci/gitlab-ci.yml | 2 +-
> >
Hi Jeff,
Am Montag, 21. Juli 2025, 16:55:01 Mitteleuropäische Sommerzeit schrieb Jeff
Hugo:
> On 7/21/2025 3:17 AM, Tomeu Vizoso wrote:
> > This series adds a new driver for the NPU that Rockchip includes in its
> > newer SoCs, developed by them on the NVDLA base.
> >
> > In its current form, it
Unfortunately, that doesn't seem to fix the issue.
glxinfo -B still shows llvmpipe being used, just like on stock 6.16-rc7:
glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa (0x)
Device: llvmpi
Hi Danilo,
>
> Yeah, I can pick it up, but it won't be considered for the upcoming merge
> window
> anymore, but for the next. After -rc6 drm-misc is in feature freeze and I also
> already send the PR for Nova.
>
> Daniel, Beata: Is there a reason you need this earlier?
IIUC, this will be merg
Le 26/06/2025 à 16:05, Tvrtko Ursulin a écrit :
On 26/06/2025 14:43, Pierre-Eric Pelloux-Prayer wrote:
Hi,
Le 26/06/2025 à 10:41, Tvrtko Ursulin a écrit :
On 25/06/2025 15:37, Pierre-Eric Pelloux-Prayer wrote:
The drm_sched_job_unschedulable trace point can access
entity->dependency afte
Hi,
I see this on latest Linus + tip/master from today. Something about
clearing blocked tasks' relationships with the same mutex held...
[5.222437] [drm] amdgpu kernel modesetting enabled.
[5.227168] input: HDA Digital PCBeep as
/devices/pci:00/:00:08.1/:03:00.6/sound/card1/
On 7/21/25 4:55 PM, Alice Ryhl wrote:
On Thu, Jun 26, 2025 at 06:23:13PM +0200, Beata Michalska wrote:
With the Opaque, the expectations are that Rust should not
make any assumptions on the layout or invariants of the wrapped
C types. That runs rather counter to ioctl arguments, which must
adher
On Mon, 21 Jul 2025 11:17:33 +0200, Tomeu Vizoso wrote:
> Add the bindings for the Neural Processing Unit IP from Rockchip.
>
> v2:
> - Adapt to new node structure (one node per core, each with its own
> IOMMU)
> - Several misc. fixes from Sebastian Reichel
>
> v3:
> - Split register block in
On Mon, Jul 21, 2025 at 12:13:44PM +0100, Karunika Choo wrote:
> This patch adds firmware binary and GPU model naming support for
> Mali-Gx20 and Mali-Gx25 GPUs.
>
> It also introduces the following registers:
> - GPU_COMMAND_ARG0~1
> - SHADER_PWRFEATURES
> - MCU_FEATURES
>
> The GPU_COHERENCY_FE
Hi.
On Sun, Jul 20, 2025 at 4:51 PM Ryan Walklin wrote:
>
> The Allwinner H700 exposes RGB and LVDS pins as well as a HDMI
> connector. This requires additional clocks for the TCON_TOP as per the
> T507 datasheet (which shares the same die).
>
> Acked-by: Rob Herring (Arm)
> Signed-off-by: Ryan
On Thu, Jun 26, 2025 at 06:23:13PM +0200, Beata Michalska wrote:
> With the Opaque, the expectations are that Rust should not
> make any assumptions on the layout or invariants of the wrapped
> C types. That runs rather counter to ioctl arguments, which must
> adhere to certain data-layout constrai
On 7/21/2025 3:17 AM, Tomeu Vizoso wrote:
This series adds a new driver for the NPU that Rockchip includes in its
newer SoCs, developed by them on the NVDLA base.
In its current form, it supports the specific NPU in the RK3588 SoC.
The userspace driver is part of Mesa and an initial draft can b
On Mon, Jul 21, 2025 at 12:13:43PM +0100, Karunika Choo wrote:
> As the FLUSH_MEM and FLUSH_PT MMU_AS commands are deprecated in GPUs
> from Mali-Gx20 onwards, this patch adds support for performing cache
> maintenance via the FLUSH_CACHES command in GPU_COMMAND in place of
> FLUSH_MEM and FLUSH_PT
On Fri, Jul 18, 2025 at 12:19:41PM -0400, Rodrigo Vivi wrote:
> On Fri, Jul 18, 2025 at 02:59:10PM +0100, Ruben Wauters wrote:
> > On Tue, 2025-07-01 at 12:54 +0100, Ruben Wauters wrote:
> > > DRM_DEBUG_SELFTEST was removed in commit fc8d29e298cf (drm: selftest:
> > > convert drm_mm selftest to KUn
1 - 100 of 196 matches
Mail list logo
