From: Shixiong Ou
[WHY]
On an ARM machine, the following log is present:
[0.900884] efifb: framebuffer at 0x102000, using 3072k, total 3072k
[2.297884] amdgpu :04:00.0: remove_conflicting_pci_framebuffers: bar 0:
0x10 -> 0x100fff
[2.297886] amdgpu :04:00.0: re
Hi,
Here's a series fixing (hopefully) the panel-simple regression for
panels with a panel-dpi compatible.
It's only build tested, so if you could give that series a try
Francesco, I'd really appreciate it.
Thanks!
Maxime
Link: https://lore.kernel.org/dri-devel/20250612081834.GA248237@francesc
On Thu, Jun 26, 2025 at 11:35:12AM +0200, Francesco Dolcini wrote:
> On Thu, Jun 26, 2025 at 11:25:24AM +0200, Francesco Dolcini wrote:
> > On Wed, Jun 25, 2025 at 08:48:37AM +0200, Maxime Ripard wrote:
> > > Here's a series fixing (hopefully) the panel-simple regression for
> > > panels with a pan
This will be especially useful for generic panels (like panel-simple)
which can take different code path depending on if they are MIPI-DSI
devices or platform devices.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_mipi_dsi.c | 3 ++-
include/drm/drm_mipi_dsi.h | 3 +++
2 files changed
If the panel-simple driver is probed from a panel-dpi compatible, the
driver will use an empty panel_desc structure as a descriminant. It
will then allocate and fill another panel_desc as part of its probe.
However, that allocation needs to happen after the panel_simple
structure has been allocate
In order to fix the regession introduced by commit de04bb0089a9
("drm/panel/panel-simple: Use the new allocation in place of
devm_kzalloc()"), we need to move the panel_desc lookup into the common
panel_simple_probe() function.
There's two callers for that function, the probe implementations of th
Commit de04bb0089a9 ("drm/panel/panel-simple: Use the new allocation in
place of devm_kzalloc()") moved the call to drm_panel_init into the
devm_drm_panel_alloc(), which needs a connector type to initialize
properly.
In the panel-dpi compatible case, the passed panel_desc structure is an
empty one
The empty panel_dpi struct was only ever used as a discriminant, but
it's kind of a hack, and with the reworks done in the previous patches,
we shouldn't need it anymore.
Let's get rid of it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/panel-simple.c | 27 ++-
Hello Maxime,
it works for me, thanks!
On Thu, Jun 26, 2025 at 12:04:58PM +0200, Maxime Ripard wrote:
> Here's a series fixing (hopefully) the panel-simple regression for
> panels with a panel-dpi compatible.
>
> It's only build tested, so if you could give that series a try
> Francesco, I'd real
From: Konrad Dybcio
Instead of setting it on a gpu-per-gpu basis, converge it to the
intended "is A650 family or A7xx".
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
d
Hello Anusha,
thanks for your patch
On Wed, Jun 25, 2025 at 05:44:44PM -0500, Anusha Srivatsa wrote:
> The panel allocation in panel_simple_probe() breaks due to not having
> the panel desc for DPI panels. DPI panels gets probed much later.
>
> Currently driver is checking for desc == &panel_dpi
Hello Maxime,
thanks for the patch
On Wed, Jun 25, 2025 at 08:48:37AM +0200, Maxime Ripard wrote:
> Here's a series fixing (hopefully) the panel-simple regression for
> panels with a panel-dpi compatible.
>
> It's only build tested, so if you could give that series a try
> Francesco, I'd really a
Update the Imagination PVR DRM driver to leverage the pwrseq framework
for managing the complex power sequence of the GPU on the T-HEAD TH1520
SoC.
To cleanly separate platform specific logic from the generic driver,
this patch introduces a `pwr_power_sequence_ops` struct containing
function point
This patch series introduces support for the Imagination IMG BXM-4-64
GPU found on the T-HEAD TH1520 SoC. A key aspect of this support is
managing the GPU's complex power-up and power-down sequence, which
involves multiple clocks and resets.
The TH1520 GPU requires a specific sequence to be follow
Add a device tree node for the IMG BXM-4-64 GPU present in the T-HEAD
TH1520 SoC used by the Lichee Pi 4A board. This node enables support for
the GPU using the drm/imagination driver.
By adding this node, the kernel can recognize and initialize the GPU,
providing graphics acceleration capabilitie
Add the "gpu-clkgen" reset property to the AON device tree node. This
allows the AON power domain driver to detect the capability to power
sequence the GPU and spawn the necessary pwrseq-thead-gpu auxiliary
driver for managing the GPU's complex power sequence.
This commit also adds the prerequisit
Update the img,powervr-rogue.yaml to include the T-HEAD TH1520 SoC's
specific GPU compatible string.
The thead,th1520-gpu compatible, along with its full chain
img,img-bxm-4-64, and img,img-rogue, is added to the
list of recognized GPU types.
While the BXM-4-64 GPU IP is designed with two distinc
Several RISC-V boards feature Imagination GPUs that are compatible with
the PowerVR driver. An example is the IMG BXM-4-64 GPU on the Lichee Pi
4A board. This commit adjusts the driver's Kconfig dependencies to allow
the PowerVR driver to be compiled on the RISC-V architecture.
By enabling compila
Hi Francesco,
On Thu, Jun 26, 2025 at 11:25:24AM +0200, Francesco Dolcini wrote:
> Hello Maxime,
> thanks for the patch
>
> On Wed, Jun 25, 2025 at 08:48:37AM +0200, Maxime Ripard wrote:
> > Here's a series fixing (hopefully) the panel-simple regression for
> > panels with a panel-dpi compatible.
On Thu, Jun 26, 2025 at 11:25:24AM +0200, Francesco Dolcini wrote:
> On Wed, Jun 25, 2025 at 08:48:37AM +0200, Maxime Ripard wrote:
> > Here's a series fixing (hopefully) the panel-simple regression for
> > panels with a panel-dpi compatible.
> >
> > It's only build tested, so if you could give th
On Thu, Jun 26, 2025 at 11:35:12AM +0200, Francesco Dolcini wrote:
> On Thu, Jun 26, 2025 at 11:25:24AM +0200, Francesco Dolcini wrote:
> > On Wed, Jun 25, 2025 at 08:48:37AM +0200, Maxime Ripard wrote:
> > > Here's a series fixing (hopefully) the panel-simple regression for
> > > panels with a pan
Hi,
On 28/05/2025 15:25, Aradhya Bhatia wrote:
> Hello all,
>
> This patch series adds support for the dual OLDI TXes supported in Texas
> Instruments' AM62x and AM62Px family of SoCs. The OLDI TX hardware supports
> single-lvds, lvds-clone, and dual-lvds modes. These TXes have now been
> represe
Hi
Am 26.06.25 um 11:49 schrieb oushixiong1...@163.com:
From: Shixiong Ou
[WHY]
On an ARM machine, the following log is present:
[0.900884] efifb: framebuffer at 0x102000, using 3072k, total 3072k
[2.297884] amdgpu :04:00.0: remove_conflicting_pci_framebuffers: bar 0:
0x10
Hi Clément,
thanks for the patch.
On Mon, Jun 16, 2025 at 10:53:56AM +0200, Clément Le Goffic wrote:
> Use the i2c-core-base APIs to allocate a DMA safe buffer when needed.
>
> Signed-off-by: Clément Le Goffic
> ---
> drivers/i2c/busses/i2c-stm32f7.c | 36 +---
>
Hi,
It looks like it's been a slow week, but here's this week drm-misc-next PR
Maxime
drm-misc-next-2025-06-26:
drm-misc-next for 6.17:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- ci: Add Device tree validation and kunit
- connector: Move HDR sink metadat to drm_display_info
Drive
Hi Clément,
Oups, I was too fast.
there might be another place to correct in the driver, dma_unmap_single
within the error handling of the function stm32_i2c_prep_dma_xfer.
err:
dma_unmap_single(chan_dev, dma->dma_buf, dma->dma_len,
dma->dma_data_dir);
On 25/06/2025 15:37, Pierre-Eric Pelloux-Prayer wrote:
The drm_sched_job_unschedulable trace point can access
entity->dependency after it was cleared by the callback
installed in drm_sched_entity_add_dependency_cb, causing:
BUG: kernel NULL pointer dereference, address: 0020
Workqu
On 25.06.25 21:16, David Airlie wrote:
> diff --git a/Documentation/filesystems/proc.rst
> b/Documentation/filesystems/proc.rst
> index 5236cb52e357..7cc5a9185190 100644
> --- a/Documentation/filesystems/proc.rst
> +++ b/Documentation/filesystems/proc.rst
> @@ -1095,6 +1095
Hi Clément,
On Mon, Jun 16, 2025 at 10:53:54AM +0200, Clément Le Goffic wrote:
> If the DMA mapping failed, it produced an error log with the wrong
> device name:
> "stm32-dma3 4040.dma-controller: rejecting DMA map of vmalloc memory"
> Fix this issue by replacing the dev with the I2C dev.
In
From: Konrad Dybcio
The Adreno part of the driver exposes this value to userspace, and the
SMEM data source also presents a x+13 value. Keep things coherent and
make the value uniform across them.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/msm_mdss.c |
From: Konrad Dybcio
As discussed a lot in the past, the UBWC config must be coherent across
a number of IP blocks (currently display and GPU, but it also may/will
concern camera/video as the drivers evolve).
So far, we've been trying to keep the values reasonable in each of the
two drivers separ
As discussed a lot in the past, the UBWC config must be coherent across
a number of IP blocks (currently display and GPU, but it also may/will
concern camera/video as the drivers evolve).
So far, we've been trying to keep the values reasonable in each of the
two drivers separately, but it really m
From: Konrad Dybcio
Add a file that will serve as a single source of truth for UBWC
configuration data for various multimedia blocks.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qco
From: Konrad Dybcio
It's supposed to be on when the UBWC encoder version is >= 4.0.
Drop the per-GPU assignments.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/dri
From: Konrad Dybcio
The bit must be set to 1 if the UBWC encoder version is >= 3.0, drop it
as a separate field.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 12 +++-
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git
From: Konrad Dybcio
This bit is set iff the UBWC version is 1.0. That notably does not
include QCM2290's "no UBWC".
This commit is intentionally cross-subsystem to ease review, as the
patchset is intended to be merged together, with a maintainer
consensus.
Reviewed-by: Dmitry Baryshkov
Signed-
From: Konrad Dybcio
Start the great despaghettification by getting a pointer to the common
UBWC configuration, which houses e.g. UBWC versions that we need to
make decisions.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16 ++
From: Konrad Dybcio
Now that Adreno specifics are out of the way, use the common config
(but leave the HBB hardcoding in place until that is wired up on the
other side).
Acked-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 20 -
drivers
From: Konrad Dybcio
It's only necessary for some lower end parts.
Also rename it to min_acc_len_64b to denote that if set, the minimum
access length is 64 bits, 32b otherwise.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 18 +--
From: Konrad Dybcio
ubwc_swizzle is a bitmask. Check for a bit to make it more obvious.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.
From: Konrad Dybcio
Make the values a bit more meaningful.
This commit is intentionally cross-subsystem to ease review, as the
patchset is intended to be merged together, with a maintainer
consensus.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/adreno/a6
From: Konrad Dybcio
The value of 7 (a.k.a. GENMASK(2, 0), a.k.a. disabling levels 1-3 of
swizzling) is what we want on this platform (and others with a UBWC
1.0 encoder).
Fix it to make mesa happy (the hardware doesn't care about the 2 higher
bits, as they weren't consumed on this platform).
Re
From: Konrad Dybcio
The UBWC 1.0 case is easy - it must be all 3 enabled.
UBWC2.0 and 3.x require that level1 is removed, follow suit.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Konrad Dybcio
---
drivers/soc/qcom/ubwc_config.c | 18 ++
1 file changed, 18 insertions(+)
diff
Hi Clément,
thanks for the patch.
On Mon, Jun 16, 2025 at 10:53:55AM +0200, Clément Le Goffic wrote:
> Fix an issue where the mapped DMA buffer was not unmapped.
>
> Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support")
> Signed-off-by: Clément Le Goffic
> ---
> drivers/i2c/busses/i2c-stm3
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/xe/xe_ggtt.c
between commit:
af2b588abe00 ("drm/xe: Process deferred GGTT node removals on device unwind")
from the drm-fixes tree and commit:
b2d6fd7ac598 ("drm/xe: Do not rely on GGTT internals in xe_g
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 true, which prevents its exec
在 2025/6/25 16:04, Christian Brauner 写道:
On Tue, Jun 24, 2025 at 01:51:51PM +0100, Matthew Wilcox wrote:
On Tue, Jun 24, 2025 at 12:12:08PM +, 陈涛涛 Taotao Chen wrote:
-static int blkdev_write_end(struct file *file, struct address_space *mapping,
+static int blkdev_write_end(struct kiocb *i
2025년 6월 27일 (금) 오전 4:21, Kaustabh Chakraborty 님이 작성:
>
> If there's support for another console device (such as a TTY serial),
> the kernel occasionally panics during boot. The panic message and a
> relevant snippet of the call stack is as follows:
>
> Unable to handle kernel NULL pointer derefe
2025년 6월 27일 (금) 오전 4:21, Kaustabh Chakraborty 님이 작성:
>
> 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 block, say an MIC or a DSI
> master.
>
> Document these bi
The GitLab runner tags are case sensitive, and Flip-hatch's tag was
incorrectly lowercase. This prevented jobs from being picked up
by the runner. Fix the runner tag for Flip-hatch.
Based on https://gitlab.freedesktop.org/mesa/mesa/-/commit/03b480d3
Signed-off-by: Vignesh Raman
---
v1:
- MR -
From: Mario Limonciello
Several places in the kernel do class shifting to match whether a
PCI device is display class. Introduce a helper for those places to
use.
Acked-by: Bjorn Helgaas
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Signed-off-by: Mario Limonciello
---
include/linux
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/gpu/vga/vga_switcheroo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Takashi Iwai
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
sound/hda/hdac_i915.c | 2 +-
sound/pci/hda/hda_intel
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Acked-by: Alex Williamson
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/vfio/pci/vfio_pci_igd.c | 3 +--
1 file changed,
From: Mario Limonciello
This series started out as changes to VGA arbiter to try to handle a case
of a system with 2 GPUs that are not VGA devices [1]. This was discussed
but decided not to overload the VGA arbiter for non VGA devices.
Instead move the x86 specific detection of framebuffer reso
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 attribute 'boot_display' that uses the output of
video_is_primary_device() to populate whether a PCI devic
From: Mario Limonciello
On systems with non VGA GPUs fbcon can't find the primary GPU because
video_is_primary_device() only checks the VGA arbiter.
Add a screen info check to video_is_primary_device() so that callers
can get accurate data on such systems.
Suggested-by: Thomas Zimmermann
Signe
From: Mario Limonciello
When compiled without CONFIG_VIDEO the architecture specific
implementations of video_is_primary_device() include prototypes and
assume that video-common.c will be linked. Guard against this so that the
fallback inline implementation that returns false will be used when
co
From: Mario Limonciello
vga_is_firmware_default() checks firmware resources to find the owner
framebuffer resources to find the firmware PCI device. This is an
open coded implementation of screen_info_pci_dev(). Switch to using
screen_info_pci_dev() instead.
Acked-by: Bjorn Helgaas
Suggested-
From: Mario Limonciello
The inline pci_is_display() helper does the same thing. Use it.
Reviewed-by: Lu Baolu
Reviewed-by: Daniel Dadap
Reviewed-by: Simona Vetter
Suggested-by: Bjorn Helgaas
Signed-off-by: Mario Limonciello
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 inserti
On 24.06.25 13:34, Sunil Khatri wrote:
> Each drm node is associated with a unique client-id.
> Create a directory for each drm-file in the dri root
> directory. This directory is unique to hold information
> related to a client id which is unique in the system
> irrespective of how many drm device
On Wed, 25 Jun 2025 14:11:54 +0530, Dharma Balasubiramani wrote:
> Replace legacy .enable and .disable callbacks with their atomic
> counterparts .atomic_enable and .atomic_disable.
>
> Signed-off-by: Dharma Balasubiramani
Reviewed-by: Maxime Ripard
Thanks!
Maxime
Add support for the CMN N116BCJ-EAK, pleace the EDID here for
subsequent reference.
00 ff ff ff ff ff ff 00 0d ae 63 11 00 00 00 00
19 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27
1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20
a6 00 00 90 10 00 00 1
On 24.06.25 13:34, Sunil Khatri wrote:
> move the debugfs accel driver code to the drm layer.
> This is first inline change to move the debugfs
> related changes for drm to drm_debugfs.c
Maybe write something like this:
"And intermediate step to move all debugfs related handling into drm_debugfs.
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 using Opaque,
ioctl handlers are forced to use unsafe code where
On Wed, Jun 25, 2025 at 08:42:35PM -0700, Boqun Feng wrote:
Hi,
> Hi Beata,
>
> On Wed, Jun 25, 2025 at 10:13:33AM +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 run
There are cases when we try to pin a folio but discover that it has
not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
but there is a chance that we might encounter a fatal crash/failure
(VM_BUG_ON(!h->resv_huge_pages) in alloc_hugetlb_folio_reserve()) if
there are no active rese
On 26.06.25 16:19, Jocelyn Falempe wrote:
> On 25/06/2025 00:18, Jocelyn Falempe wrote:
>> On 24/06/2025 20:55, Andrei Lalaev wrote:
>>> On 18.04.25 18:48, Jocelyn Falempe wrote:
On 32bits ARM, u64/u64 is not supported [1], so change the algorithm
to use a simple fifo with decimal digits
In the error paths after fb_info structure is successfully allocated,
the memory allocated in fb_deferred_io_init() for info->pagerefs is not
freed. Fix that by adding the cleanup function on the error path.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Abdun Nihaal
---
This
On 6/26/2025 3:45 PM, Bjorn Helgaas wrote:
On Tue, Jun 24, 2025 at 03:30:42PM -0500, Mario Limonciello wrote:
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
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/firmware_request_nowarn/ as firmware will
not be availa
On 6/26/2025 3:43 PM, Bjorn Helgaas wrote:
On Tue, Jun 24, 2025 at 03:30:34PM -0500, Mario Limonciello wrote:
From: Mario Limonciello
Several places in the kernel do class shifting to match whether a
PCI device is display class. Introduce a helper for those places to
use.
Reviewed-by: Daniel
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.16-rc3 next-20250626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as doc
On Thu, Jun 26, 2025 at 08:50:43PM +0300, Andy Shevchenko wrote:
> On Thu, Jun 26, 2025 at 10:54:10PM +0530, Abdun Nihaal wrote:
> > In the error paths after fb_info structure is successfully allocated,
> > the memory allocated in fb_deferred_io_init() for info->pagerefs is not
> > freed. Fix that
In order for vmwgfx to use syncobj and maintain compatibility with our
existing userspace fencing IOCTLs we need to be able to call this function.
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/drm_syncobj.c | 13 +++--
include/drm/drm_syncobj.h | 1 +
2 files changed, 12 insertions(
Replace vmwgfx's ad hoc userspace fence tracking with drm_syncobj.
They are nearly identical and it is possible to maintain compatibility
with the old IOCTLs.
Signed-off-by: Ian Forbes
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 3 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
drivers
The PLL_STABLE bit of DSIM_DPHY_STATUS is hardcoded to BIT(31), but
Exynos7870's DSIM has it in BIT(24) as per downstream kernel sources.
In order to support both, move this bit value to the driver data struct
and define it for every driver compatible. Reference the value from
there instead, in fu
On Thu, Jun 26, 2025 at 12:11:16PM -0700, Vivek Kasireddy wrote:
> There are cases when we try to pin a folio but discover that it has
> not been faulted-in. So, we try to allocate it in memfd_alloc_folio()
> but there is a chance that we might encounter a fatal crash/failure
> (VM_BUG_ON(!h->resv_
On Tue, Jun 24, 2025 at 03:30:42PM -0500, Mario Limonciello wrote:
> 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 attribute 'boot_display' that
On Tue, Jun 24, 2025 at 03:30:34PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> Several places in the kernel do class shifting to match whether a
> PCI device is display class. Introduce a helper for those places to
> use.
>
> Reviewed-by: Daniel Dadap
> Reviewed-by: Simona Ve
On Tue, Jun 24, 2025 at 03:30:40PM -0500, Mario Limonciello wrote:
> From: Mario Limonciello
>
> vga_is_firmware_default() checks firmware resources to find the owner
> framebuffer resources to find the firmware PCI device. This is an
> open coded implementation of screen_info_pci_dev(). Switch
On Thu, 12 Jun 2025 00:47:47 +0300, Cristian Ciocaltea wrote:
> As with the RK3588 SoC, RK3576 also allows the use of HDMI PHY PLL as an
> alternative and more accurate pixel clock source for VOP2.
>
> Document the optional PLL clock property.
>
> Moreover, given that this is part of a series i
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 wrote:
From: Mario Limonciello
On systems with multiple GPUs there can be unce
On 18-06-25, 12:59, Tomi Valkeinen wrote:
> The code in cdns-dphy has probably been part of a DSI driver in the
> past. Remove DSI defines and variables which are not used or do not
> actually do anything. Also rename cdns_dsi_get_dphy_pll_cfg() to
> cdns_dphy_get_pll_cfg(), i.e. drop the "dsi", as
On 18-06-25, 12:59, Tomi Valkeinen wrote:
> The DPHY driver does not return the actual hs_clk_rate, so the DSI
> driver has no idea what clock was actually achieved. Set the realized
> hs_clk_rate to the opts struct, so that the DSI driver gets it back.
Acked-by: Vinod Koul
--
~Vinod
On Fri, 13 Jun 2025 23:17:07 +0200, Sasha Finkelstein wrote:
> Add bindings for the GPU present in Apple SoCs
>
> Signed-off-by: Sasha Finkelstein
> ---
> Documentation/devicetree/bindings/gpu/apple,agx.yaml | 94
> ++
Hi Luca,
kernel test robot noticed the following build errors:
[auto build test ERROR on 1174bf15bd601f17556f721798cd9183e169549a]
url:
https://github.com/intel-lab-lkp/linux/commits/Luca-Ceresoli/drm-mipi-dsi-add-sanity-check-of-lane-number-in-mipi_dsi_attach/20250626-005002
base
This patch series aims at adding support for Exynos7870's DECON in the
Exynos7 DECON driver. It introduces a driver data struct so that support
for DECON on other SoCs can be added to it in the future.
It also fixes a few bugs in the driver, such as functions receiving bad
pointers.
Tested on Sam
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 block, say an MIC or a DSI
master.
Document these bindings in the devicetree schema.
Signed-off-by: Kaustabh Chakrabor
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 true, which prevents its execution. decon_commit() is
vital for setting up display timing values, with
If there's support for another console device (such as a TTY serial),
the kernel occasionally panics during boot. The panic message and a
relevant snippet of the call stack is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
000
Call trace:
drm_c
The VIDEO_MODE bit of DSIM_CONFIG is hardcoded to BIT(25), but
Exynos7870's DSIM has it in BIT(18) as per downstream kernel sources.
In order to support both, move this bit value to the driver data struct
and define it for every driver compatible. Reference the value from
there instead, in functio
Currently, PLL_P offset of DSIM_PLLCTRL is configurable in the driver
data, while PLL_M and PLL_S offsets are hardcoded as 4-bit and 1-bit
offsets respectively, but Exynos7870's DSIM have them at 3-bit and 0-bit
offsets as per downstream kernel sources.
In order to support both, move both offset v
Add support for Exynos7870's DSIM IP block in the bridge driver.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/bridge/samsung-dsim.c | 82 +++
include/drm/bridge/samsung-dsim.h | 1 +
2 files changed, 83 insertions(+)
diff --git a/drivers/gpu/drm/b
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 Chakraborty
---
.../bindings/display/bridge/samsung,mipi-dsim.yaml | 27
Presently, all devices refer to clock names from a single array. The
only controlling parameter is the number of clocks (num_clks field of
samsung_dsim_driver_data) which uses the first n clocks of that array.
As new devices are added, this approach turns out to be cumbersome.
Separate the clock n
Add glue layer support for Exynos7870's DSIM IP bridge driver.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index
89
Exynos7870's DSIM requires more time to stabilize its PLL. The current
timeout value, 1000, doesn't suffice. Increase the value to 3000, which
is just about enough as observed experimentally.
Signed-off-by: Kaustabh Chakraborty
---
drivers/gpu/drm/bridge/samsung-dsim.c | 2 +-
1 file changed, 1
On 6/25/2025 10:00 AM, Badal Nilawar wrote:
Extract and print version info of the late binding binary.
v2: Some refinements (Daniele)
Signed-off-by: Badal Nilawar
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/xe/xe_late_bind_fw.c | 124 +
1 - 100 of 153 matches
Mail list logo
