On Wed, Dec 18, 2024 at 07:24:23AM +0200, Dmitry Baryshkov wrote:
> On Tue, 17 Dec 2024 at 19:21, Maxime Ripard wrote:
> > On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote:
> > > While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
> > > framework, I stumbled upon a
> >> @@ -474,20 +478,28 @@ static int intel_dg_mtd_erase(struct mtd_info
> *mtd, struct erase_info *info)
> >>total_len = info->len;
> >>addr = info->addr;
> >>
> >> + ret = pm_runtime_resume_and_get(mtd->dev.parent);
> > on this, I really don't believe this is right and we should use
> >
Hi Wei Lin,
> Subject: Re: [PATCH 0/4] cover-letter: Allow MMIO regions to be exported
> through dmabuf
> >>
> >> From: Wei Lin Guay
> >>
> >> This is another attempt to revive the patches posted by Jason
> >> Gunthorpe and Vivek Kasireddy, at
> >> https://patchwork.kernel.org/project/linux-media
Hi Christian,
> Subject: Re: [PATCH 0/4] cover-letter: Allow MMIO regions to be exported
> through dmabuf
>
>
>> I will resend the patch series. I was experiencing issues with my email
>> client, which inadvertently split the series into two separate emails.
>
>
> Alternatively I can also
On 12/17/2024, Maxime Ripard wrote:
> Hi,
Hi,
>
> Thanks for the description, I have several questions here.
Thanks for the feedback!
>
> On Thu, Nov 14, 2024 at 02:57:52PM +0800, Liu Ying wrote:
>> This patch series aims to add ITE IT6263 LVDS to HDMI converter on
>> i.MX8MP EVK.
>>
>> Since
On Tue, 17 Dec 2024 at 19:21, Maxime Ripard wrote:
>
> Hi,
>
> On Tue, Dec 17, 2024 at 02:40:22AM +0200, Dmitry Baryshkov wrote:
> > While porting lt9611 DSI-to-HDMI bridge driver to use HDMI Connector
> > framework, I stumbled upon an issue while handling the Audio InfoFrames.
> > The HDMI codec
On 18-12-2024 04:19, Rodrigo Vivi wrote:
On Tue, Nov 19, 2024 at 04:01:08PM +0200, Alexander Usyskin wrote:
Enable runtime PM in mtd driver to notify graphics driver that
whole card should be kept awake while nvm operations are
performed through this driver.
CC: Lucas De Marchi
Acked-by: Miq
On 2024/12/13 18:19, Dmitry Baryshkov wrote:
On Fri, 13 Dec 2024 at 11:21, fange zhang wrote:
On 2024/12/10 19:02, Dmitry Baryshkov wrote:
On Tue, Dec 10, 2024 at 02:54:00PM +0800, Fange Zhang wrote:
From: Li Liu
Add display MDSS and DSI configuration for QCS615 RIDE board.
QCS615 has
Hi Daniel,
At 2024-12-18 08:55:48, "Andy Yan" wrote:
>
>Hi Daniel,
>
>At 2024-12-17 20:07:54, "Daniel Stone" wrote:
>>Hi Andy,
>>
>>On Tue, 17 Dec 2024 at 00:41, Andy Yan wrote:
>>> At 2024-12-16 21:06:07, "Daniel Stone" wrote:
>>> >On Sat, 14 Dec 2024 at 08:18, Andy Yan wrote:
>>> >> This
From: "Dr. David Alan Gilbert"
hdmi5_core_handle_irqs() is a function that was copied from omapdss by
commit f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
but it wasn't used in the original anyway.
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
drivers/gpu/drm/omapdrm/dss
From: "Dr. David Alan Gilbert"
hdmi5_core_handle_irqs() has been unused since
commit f5bab2229190 ("OMAPDSS: HDMI: Add OMAP5 HDMI support")
Remove it.
Signed-off-by: Dr. David Alan Gilbert
---
.../video/fbdev/omap2/omapfb/dss/hdmi5_core.c | 17 -
.../video/fbdev/omap2/omapfb
Hi,
在 2024-12-18 00:59:57，"Cristian Ciocaltea"
写道：
>On 12/17/24 6:53 PM, Maxime Ripard wrote:
>> On Tue, Dec 17, 2024 at 06:36:41PM +0200, Cristian Ciocaltea wrote:
>>> On 12/17/24 5:00 PM, Maxime Ripard wrote:
On Wed, Dec 11, 2024 at 07:01:15PM +0100, Heiko Stübner wrote:
> Am Mittwoc
Hi Daniel,
At 2024-12-17 20:07:54, "Daniel Stone" wrote:
>Hi Andy,
>
>On Tue, 17 Dec 2024 at 00:41, Andy Yan wrote:
>> At 2024-12-16 21:06:07, "Daniel Stone" wrote:
>> >On Sat, 14 Dec 2024 at 08:18, Andy Yan wrote:
>> >> This is the only afbc format supported by the upcoming
>> >> VOP for rk
On 12/17/24 15:43, Christian Heusel wrote:
On 24/12/17 06:05PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 6.12.6 release.
There are 172 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, p
[Thanks, Imre for the heads up and help with the conflict resolution]
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/display/intel_dp_mst.c
between commit:
6fe7b1d10cbd ("drm/i915/dp_mst: Expose a connector to kernel users after it's
properl
From: Abhinav Kumar
In preparation to register a iommu fault handler for display
related modules, register a fault handler for the backing
mmu object of msm_kms.
Currently, the fault handler only captures the display snapshot
but we can expand this later if more information needs to be
added to
From: Abhinav Kumar
There is no recovery mechanism in place yet to recover from mmu
faults for DPU. We can only prevent the faults by making sure there
is no misconfiguration.
Rate-limit the snapshot capture for mmu faults to once per
msm_atomic_commit_tail() as that should be sufficient to capt
From: Abhinav Kumar
In preparation of registering a separate fault handler for
display, lets rename the existing msm_fault_handler to
msm_gpu_fault_handler.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/msm_iommu.c | 6 +++---
From: Abhinav Kumar
Switch msm_kms to use msm_iommu_disp_new() so that the newly
registered fault handler will kick-in during any mmu faults.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/msm_kms.c | 2 +-
1 file changed, 1 in
From: Abhinav Kumar
Introduce a new API msm_iommu_disp_new() for display use-cases.
Signed-off-by: Abhinav Kumar
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/msm_iommu.c | 26 ++
drivers/gpu/drm/msm/msm_mmu.h | 1 +
2 files cha
| 3 +++
drivers/gpu/drm/msm/msm_mmu.h| 1 +
5 files changed, 52 insertions(+), 4 deletions(-)
---
base-commit: 86313a9cd152330c634b25d826a281c6a002eb77
change-id: 20241217-abhinavk-smmu-fault-handler-ade75fef9809
Best regards,
--
Jessica Zhang
On 24/12/17 06:05PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 6.12.6 release.
> There are 172 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses shou
Avoid multiple CPU page faults to the same device page racing by trying
to lock the page in do_swap_page before taking an extra reference to the
page. This prevents scenarios where multiple CPU page faults each take
an extra reference to a device page, which could abort migration in
folio_migrate_m
From: Thomas Hellström
Add support for mapping device pages to Xe SVM by attaching drm_pagemap
to a memory region, which is then linked to a GPU SVM devmem allocation.
This enables GPU SVM to derive the device page address.
v3:
- Better commit message (Thomas)
- New drm_pagemap.h location
Sig
Add DRM_GPUVA_OP_DRIVER which allows driver to define their own gpuvm
ops. Useful for driver created ops which can be passed into the bind
software pipeline.
v3:
- s/DRM_GPUVA_OP_USER/DRM_GPUVA_OP_DRIVER (Thomas)
- Better commit message (Thomas)
Cc: Danilo Krummrich
Signed-off-by: Matthew Bros
Add SVM device memory mirroring which enables device pages for
migration. Enabled via CONFIG_XE_DEVMEM_MIRROR Kconfig. Kconfig option
defaults to enabled. If not enabled, SVM will work sans migration and
KMD memory footprint will be less.
v3:
- Add CONFIG_XE_DEVMEM_MIRROR
Signed-off-by: Niranjan
Add drm_gpusvm_devmem to xe_bo. Required to enable SVM migrations.
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_bo_types.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/xe/xe_bo_types.h b/drivers/gpu/drm/xe/xe_bo_types.h
index 46
Get device pfns from BO's buddy blocks. Used in migrate_* core MM
functions called in GPU SVM to migrate between device and system memory.
v2:
- Use new drm_gpusvm_devmem_ops
v3:
- Better commit message (Thomas)
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Oak Zeng
Signed-off-by: M
Add functions which migrate to / from VRAM accepting a single DPA
argument (VRAM) and array of dma addresses (SRAM). Used for SVM
migrations.
v2:
- Don't unlock job_mutex in error path of xe_migrate_vram
v3:
- Kernel doc (Thomas)
- Better commit message (Thomas)
- s/dword/num_dword (Thomas)
-
Useful to experiment with notifier size and how it affects performance.
v3:
- Pull missing changes including in following patch (Thomas)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_module.c | 4
drivers/gpu/drm/xe/xe_module.h | 1 +
drivers/gpu/drm/xe/xe_svm.c| 4 +++-
3 fi
Migration is implemented with range granularity, with VRAM backing being
a VM private TTM BO (i.e., shares dma-resv with VM). The lifetime of the
TTM BO is limited to when the SVM range is in VRAM (i.e., when a VRAM
SVM range is migrated to SRAM, the TTM BO is destroyed).
The design choice for usi
Add some useful SVM debug logging fro SVM range which prints the range's
state.
v2:
- Upadte logging with latest structure layout
v3:
- Better commit message (Thomas)
- New range structure (Thomas)
- s/COLLECTOT/s/COLLECTOR (Thomas)
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
Used to show we can bounce memory multiple times which will happen once
a real migration policy is implemented. Can be removed once migration
policy is implemented.
v3:
- Pull some changes into the previous patch (Thomas)
- Spell out power of 2 (Thomas)
- Better commit message (Thomas)
Signed-
This patch introduces support for GPU Shared Virtual Memory (SVM) in the
Direct Rendering Manager (DRM) subsystem. SVM allows for seamless
sharing of memory between the CPU and GPU, enhancing performance and
flexibility in GPU computing tasks.
The patch adds the necessary infrastructure for SVM, i
Implement with a simple BO put which releases the device memory.
v2:
- Use new drm_gpusvm_devmem_ops
v3:
- Better commit message (Thomas)
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_svm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/driv
uAPI is designed with the use case that only mapping a BO to a malloc'd
address will unbind a CPU-address mirror VMA. Therefore, allowing a
CPU-address mirror VMA to unbind when the GPU has bindings in the range
being unbound does not make much sense. This behavior is not supported,
as it simplifie
Add GPUSVM device memory copy vfunc functions and connect to migration
layer. Used for device memory migration.
v2:
- Allow NULL device pages in xe_svm_copy
- Use new drm_gpusvm_devmem_ops
v3:
- Prefix defines with XE_ (Thomas)
- Change copy chunk size to 8M
- Add a bunch of comments to xe_sv
Add unbind to SVM garbage collector. To facilitate add unbind support
function to VM layer which unbinds a SVM range. Also teach PY layer to
understand unbinds of SVM ranges.
v3:
- s/INVALID_VMA/XE_INVALID_VMA (Thomas)
- Kernel doc (Thomas)
- New GPU SVM range structure (Thomas)
- s/DRM_GPUVA_
Clear root PT entry and invalidate entire VM's address space when
closing the VM. Will prevent the GPU from accessing any of the VM's
memory after closing.
v2:
- s/vma/vm in kernel doc (CI)
- Don't nuke migration VM as this occur at driver unload (CI)
v3:
- Rebase and pull into SVM series (Thom
From: Thomas Hellström
Add dma_addr res cursor which walks an array of drm_pagemap_dma_addr.
Useful for SVM ranges and programing page tables.
v3:
- Better commit message (Thomas)
- Use new drm_pagemap.h location
Signed-off-by: Matthew Brost
Signed-off-by: Thomas Hellström
---
drivers/gpu/
Add SVM range invalidation vfunc which invalidates PTEs. A new PT layer
function which accepts a SVM range is added to support this. In
addition, add the basic page fault handler which allocates a SVM range
which is used by SVM range invalidation vfunc.
v2:
- Don't run invalidation if VM is close
Wire xe_bo_move to GPU SVM migration via new helper xe_svm_bo_evict.
v2:
- Use xe_svm_bo_evict
- Drop bo->range
v3:
- Kernel doc (Thomas)
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_svm.c | 14 ++
drivers/gpu/drm/xe/xe_svm.h | 2 ++
2 files changed, 16 insertions(+)
Add basic SVM garbage collector which destroy a SVM range upon a MMU
UNMAP event. The garbage collector runs on worker or in GPU fault
handler and is required as locks in the path of reclaim are required and
cannot be taken the notifier.
v2:
- Flush garbage collector in xe_svm_close
v3:
- Better
Support for CPU address mirror bindings in SRAM fully in place, enable the
implementation.
v3:
- s/system allocator/CPU address mirror (Thomas)
Signed-off-by: Matthew Brost
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/xe/xe_svm.c | 10 ++
drivers/gpu/drm/xe/xe_vm.c | 6 --
Add XE_BO_FLAG_CPU_ADDR_MIRROR to indicate BO is tied to SVM range.
While these BO's are kernel allocations, we need a VM reference in this
case which this flag indicates. In addition, we do not support CCS on
these BO's either. The later can be revisited later.
v2:
- Take VM ref for system alloc
Add the DRM_XE_VM_BIND_FLAG_CPU_ADDR_MIRROR flag, which is used to
create unpopulated virtual memory areas (VMAs) without memory backing or
GPU page tables. These VMAs are referred to as CPU address mirror VMAs.
The idea is that upon a page fault or prefetch, the memory backing and
GPU page tables
Add (re)bind to SVM page fault handler. To facilitate add support
function to VM layer which (re)binds a SVM range. Also teach PT layer to
understand (re)binds of SVM ranges.
v2:
- Don't assert BO lock held for range binds
- Use xe_svm_notifier_lock/unlock helper in xe_svm_close
- Use drm_pagem
Add SVM init / close / fini to faulting VMs. Minimual implementation
acting as a placeholder for follow on patches.
v2:
- Add close function
v3:
- Better commit message (Thomas)
- Kernel doc (Thomas)
- Update chunk array to be unsigned long (Thomas)
- Use new drm_gpusvm.h header location (Tho
Xe depends on DRM_GPUSVM for SVM implementation, select it in Kconfig.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/xe/Kconfig b/drivers/gpu/drm/xe/Kconfig
index b51a2bde73e2..3a08e16bfada 100644
--- a/drivers/gpu
Add migrate_device_pfns which prepares an array of pre-populated device
pages for migration. This is needed for eviction of known set of
non-contiguous devices pages to cpu pages which is a common case for SVM
in DRM drivers using TTM.
v2:
- s/migrate_device_vma_range/migrate_device_prepopulated_
From: Thomas Hellström
Introduce drm_pagemap ops to map and unmap dma to VRAM resources. In the
local memory case it's a matter of merely providing an offset into the
device's physical address. For future p2p the map and unmap functions may
encode as needed.
Similar to how dma-buf works, let the
TTM doesn't support fair eviction via WW locking, this mitigated in by
using retry loops in exec and preempt rebind worker. Extend this retry
loop to BO allocation. Once TTM supports fair eviction this patch can be
reverted.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_bo.c | 8 +++
Version 3 of GPU SVM has been promoted to the proper series from an RFC.
Thanks to everyone (especially Sima and Thomas) for their numerous
reviews on revision 1, 2 and for helping to address many design issues.
This version has been tested with IGT [1] on PVC, BMG, and LNL. Also
tested with level
On Mon, Dec 02, 2024 at 02:00:44PM +0100, Thomas Hellström wrote:
> On Tue, 2024-10-15 at 20:25 -0700, Matthew Brost wrote:
> > Add documentation for agree upon GPU SVM design principles, current
> > status, and future plans.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > Documentation/gpu/rfc
The static analyser tool gave the following advice:
./fs/btrfs/ioctl.c:4987:9-16: WARNING opportunity for kmemdup
4986 if (!iov) {
→ 4987 iov = kmalloc(sizeof(struct iovec) *
args.iovcnt, GFP_NOFS);
4988 if (!iov) {
4989
The source static analysis tool gave the following advice:
./fs/xfs/libxfs/xfs_dir2.c:382:15-22: WARNING opportunity for kmemdup
→ 382 args->value = kmalloc(len,
383 GFP_KERNEL | __GFP_NOLOCKDEP |
__GFP_RETRY_MAYFAIL);
384 if (!args->value)
385
The static analyser tool gave the following advice:
./drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:1266:7-14: WARNING opportunity for
kmemdup
→ 1266 tmp = kmalloc(used_size, GFP_KERNEL);
1267 if (!tmp)
1268 return -ENOMEM;
1269
→ 1270 memcpy(tmp, &h
On Tue, Nov 19, 2024 at 04:01:08PM +0200, Alexander Usyskin wrote:
> Enable runtime PM in mtd driver to notify graphics driver that
> whole card should be kept awake while nvm operations are
> performed through this driver.
>
> CC: Lucas De Marchi
> Acked-by: Miquel Raynal
> Signed-off-by: Alexa
On Tue, Nov 19, 2024 at 04:01:05PM +0200, Alexander Usyskin wrote:
> Implement read(), erase() and write() functions.
>
> CC: Lucas De Marchi
> CC: Rodrigo Vivi
> Acked-by: Miquel Raynal
> Co-developed-by: Tomas Winkler
> Signed-off-by: Tomas Winkler
> Co-developed-by: Vitaly Lubart
> Signed
On Tue, 17 Dec 2024 12:53:22 -0800 Easwar Hariharan
wrote:
> There have been a couple of comments[1][2] that came in after you queued
> the series to mm. Would you rather I send individual patches addressing
> these, or just send a v4 of the entire series (-netdev of course) so you
> can replace
On 12/10/2024 5:00 PM, Easwar Hariharan wrote:
> On 12/10/2024 4:35 PM, Andrew Morton wrote:
>> On Tue, 10 Dec 2024 22:02:31 + Easwar Hariharan
>> wrote:
>>
>>> This is a series that follows up on my previous series to introduce
>>> secs_to_jiffies() and convert a few initial users.
>>
>> Tha
On 12/17/24 10:17 PM, Derek Foreman wrote:
> The code that changes hdmi->ref_clk was accidentally copied from
> downstream code that sets a different clock. We don't actually
> want to set any clock here at all.
>
> Setting this clock incorrectly leads to incorrect timings for
> DDC, CEC, and HDCP
dm_get_plane_scale doesn't take into account plane scaled size equal to
zero, leading to a kernel oops due to division by zero. Fix by setting
out-scale size as zero when the dst size is zero, similar to what is
done by drm_calc_scale(). This issue started with the introduction of
cursor ovelay mod
Hi,
Some issues have been found by Cosmic users of AMD display since the
introduction of cursor overlay mode: page fault and divide errors
causing interface freezes. Both are 100% reproducible and affects
multiple HW versions.
Patch 1 addresses the page fault error by resolving the definition
mis
As the hw supports up to 4 surfaces, increase the maximum number of
surfaces to prevent the DC error when trying to use more than three
planes.
[drm:dc_state_add_plane [amdgpu]] *ERROR* Surface: can not attach plane_state
3e2cb82c! Maximum is: 3
Link: https://gitlab.freedesktop.org/drm/a
DC driver is using two different values to define the maximum number of
surfaces: MAX_SURFACES and MAX_SURFACE_NUM. Consolidate MAX_SURFACES as
the unique definition for surface updates across DC.
It fixes page fault faced by Cosmic users on AMD display versions that
support two overlay planes, si
On Tue, Dec 17, 2024, at 21:14, Lucas De Marchi wrote:
> On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
>>On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
>>> On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
When INTEL_VSEC is in
On Tue, 17 Dec 2024 16:43:19 +0100, AngeloGioacchino Del Regno wrote:
> Add a binding for the HDMI TX v2 Encoder found in MediaTek MT8195
> and MT8188 SoCs.
>
> This fully supports the HDMI Specification 2.0b, hence it provides
> support for 3D-HDMI, Polarity inversion, up to 16 bits Deep Color,
The code that changes hdmi->ref_clk was accidentally copied from
downstream code that sets a different clock. We don't actually
want to set any clock here at all.
Setting this clock incorrectly leads to incorrect timings for
DDC, CEC, and HDCP signal generation.
No Fixes listed, as the theoretica
Hey,
Den 2024-12-17 kl. 19:23, skrev Tejun Heo:
Hello,
On Tue, Dec 17, 2024 at 06:37:22PM +0100, Maarten Lankhorst wrote:
Den 2024-12-17 kl. 18:11, skrev Tejun Heo:
On Tue, Dec 17, 2024 at 03:28:50PM +0100, Maarten Lankhorst wrote:
Now that all patches look good, what is needed to merge the
On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
From: Arnd Bergmann
When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
x86_64-linux-ld: vmli
On Tue, Dec 17, 2024 at 08:28:59PM +0100, Arnd Bergmann wrote:
> On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
> > On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
> >> From: Arnd Bergmann
> >>
> >> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
> >>
From: Florian Fainelli
On Thu, 12 Dec 2024 18:36:33 +, Dave Stevenson
wrote:
> The names of the hdmi0 and hdmi1 nodes had addresses that
> didn't match the reg properties for the nodes.
>
> Fixes: f66b382affd8 ("arm64: dts: broadcom: Add display pipeline support to
> BCM2712")
> Signed-of
On 12/12/24 10:36, Dave Stevenson wrote:
I missed the DT errors from the recent patchset[1] (DT patches
in linux-next via Florian, DRM bindings patches on dri-misc-next)
as Rob's bot report got spam filtered, so this is a fixup set.
Largely it was changes to number of interrupts or clocks in the
On Tue, Nov 19, 2024 at 04:01:04PM +0200, Alexander Usyskin wrote:
> In intel-dg, there is no access to the spi controller,
> the information is extracted from the descriptor region.
>
> CC: Rodrigo Vivi
> CC: Lucas De Marchi
> Acked-by: Miquel Raynal
> Co-developed-by: Tomas Winkler
> Signed-
From: Florian Fainelli
On Thu, 12 Dec 2024 18:36:34 +, Dave Stevenson
wrote:
> The brcm,bcm2836-l1-intc controller isn't used on this platform.
> It is used on 32-bit kernels for the smp_boot_secondary hook, but
> BCM2712 can't run a 32-bit kernel.
>
> Remove the node.
>
> Fixes: e1417095
From: Florian Fainelli
On Thu, 12 Dec 2024 18:36:32 +, Dave Stevenson
wrote:
> CHECK_DTBS produces errors on bcm2712-rpi-5-b.dtb and bcm2712-d-rpi-5-b.dtb
> of:
> intc@7d508380: $nodename:0: 'intc@7d508380' does not match
> '^interrupt-controller(@[0-9a-f,]+)*$'
> from schema $id:
On Tue, Dec 17, 2024, at 19:52, Rodrigo Vivi wrote:
> On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
>>
>> x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
>> (.text+0x198
On Mon, Dec 16, 2024 at 04:57:04PM -0800, Vinay Belgaumkar wrote:
> Default SLPC power profile is Base(0). Power Saving mode(1)
> has conservative up/down thresholds and is suitable for use with
> apps that typically need to be power efficient.
>
> Cc: Sushma Venkatesh Reddy
> Cc: Rodrigo Vivi
>
On 12/17/2024 2:21 AM, Rob Clark wrote:
> On Mon, Dec 16, 2024 at 12:25 PM Akhil P Oommen
> wrote:
>>
>> On 12/16/2024 10:28 PM, Connor Abbott wrote:
>>> On Mon, Dec 16, 2024 at 11:55 AM Akhil P Oommen
>>> wrote:
On 12/13/2024 10:40 PM, Antonino Maniscalco wrote:
> On 12/13/24 5:50
On Tue, Dec 17, 2024 at 08:18:44AM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> When INTEL_VSEC is in a loadable module, XE cannot be built-in any more:
>
> x86_64-linux-ld: vmlinux.o: in function `xe_vsec_init':
> (.text+0x19861bf): undefined reference to `intel_vsec_register'
>
> Thi
On 12/17/2024 10:54, Lizhi Hou wrote:
Defining a number of enum elements in uapi header is meaningless. It will
not be used as expected and can potentially lead to incompatible issue
between user space application and driver.
Signed-off-by: Lizhi Hou
---
include/uapi/drm/amdxdna_accel.h | 1 -
Hello,
On Tue, Dec 17, 2024 at 06:37:22PM +0100, Maarten Lankhorst wrote:
> Den 2024-12-17 kl. 18:11, skrev Tejun Heo:
> > On Tue, Dec 17, 2024 at 03:28:50PM +0100, Maarten Lankhorst wrote:
> > > Now that all patches look good, what is needed to merge the series?
> > > Without
> > > patch 6/7 as
On Tue, Dec 17, 2024 at 10:14:31AM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> The i.MX7D MIPI DSIM block is compatible with i.MX8MM.
>
> imx7s.dtsi uses the following compatible string:
>
> compatible = "fsl,imx7d-mipi-dsim", "fsl,imx8mm-mipi-dsim";
>
> Document "fsl,imx7d-mipi-dsim
Hi Andi,
On Tuesday, 17 December 2024 18:12:08 CET Andi Shyti wrote:
> Hi Janusz,
>
> ...
>
> > > > +
> > > > cond_resched();
> > > >
> > > > - if (intel_gt_wait_for_idle(gt, HZ * 3) == -ETIME) {
> > > > + if (intel_gt_wait_for_idle(gt, HZ * timeout_
On 12/17/2024 8:21 PM, Neil Armstrong wrote:
> The Adreno GPU Management Unit (GMU) can also scale the ddr
> bandwidth along the frequency and power domain level, but for
> now we statically fill the bw_table with values from the
> downstream driver.
>
> Only the first entry is used, which is a di
On Tue, 17 Dec 2024 02:40:29 +0200, Dmitry Baryshkov wrote:
> Extend drm_bridge_connector code to read the EDID and use it to update
> connector status if the bridge chain implements HDMI bridge. Performing
> it from the generic location minimizes individual bridge's code and
> enforces standard be
On 12/17/2024 9:33 AM, Julia Lawall wrote:
>
>
> On Tue, 17 Dec 2024, Alexander Gordeev wrote:
>
>> On Tue, Dec 10, 2024 at 10:02:33PM +, Easwar Hariharan wrote:
>>
>> Hi Easwar,
>>
>>> This script finds and suggests conversions of timeout patterns that
>>> result in seconds-denominated time
Den 2024-12-17 kl. 18:11, skrev Tejun Heo:
On Tue, Dec 17, 2024 at 03:28:50PM +0100, Maarten Lankhorst wrote:
Now that all patches look good, what is needed to merge the series? Without
patch 6/7 as it is a hack for testing.
There were some questions raised about device naming. One thing we
On Tue, Dec 17, 2024 at 07:11:00AM -1000, Tejun Heo wrote:
> On Tue, Dec 17, 2024 at 03:28:50PM +0100, Maarten Lankhorst wrote:
> > Now that all patches look good, what is needed to merge the series? Without
> > patch 6/7 as it is a hack for testing.
>
> There were some questions raised about devi
On Tue, 17 Dec 2024, Alexander Gordeev wrote:
> On Tue, Dec 10, 2024 at 10:02:33PM +, Easwar Hariharan wrote:
>
> Hi Easwar,
>
> > This script finds and suggests conversions of timeout patterns that
> > result in seconds-denominated timeouts to use the new secs_to_jiffies()
> > API in inclu
On Tue, Dec 10, 2024 at 10:02:35PM +, Easwar Hariharan wrote:
> Commit b35108a51cf7 ("jiffies: Define secs_to_jiffies()") introduced
> secs_to_jiffies(). As the values here are a multiple of 1000, use
> secs_to_jiffies() instead of msecs_to_jiffies to avoid the multiplication.
>
> This is conv
On Tue, Dec 17, 2024 at 03:32:15PM +0100, Herve Codina wrote:
> In some cases observed during ESD tests, the TI SN65DSI83 cannot recover
> from errors by itself. A full restart of the bridge is needed in those
> cases to have the bridge output LVDS signals again.
>
> Also, during tests, cases were
On Tue, Dec 10, 2024 at 10:02:33PM +, Easwar Hariharan wrote:
Hi Easwar,
> This script finds and suggests conversions of timeout patterns that
> result in seconds-denominated timeouts to use the new secs_to_jiffies()
> API in include/linux/jiffies.h for better readability.
>
> Suggested-by:
On Tue, Dec 17, 2024 at 02:40:32AM +0200, Dmitry Baryshkov wrote:
> Use the helper function to update the connector's information. This
> makes sure that HDMI-related events are handled in a generic way.
> Currently it is limited to the HDMI state reporting to the sound system.
>
> Signed-off-by:
On Tue, Dec 17, 2024 at 02:40:31AM +0200, Dmitry Baryshkov wrote:
> The vc4_hdmi_connector_detect_ctx() via vc4_hdmi_handle_hotplug()
> already reads EDID and propagates it to the drm_connector. Stop
> rereading EDID as a part of the .get_modes() callback and just update
> the list of modes. This m
On Tue, Dec 17, 2024 at 02:40:30AM +0200, Dmitry Baryshkov wrote:
> Drop driver-specific implementation and use the generic HDMI Codec
> framework in order to implement the HDMI audio support.
>
> Signed-off-by: Dmitry Baryshkov
Assuming it's been tested:
Acked-by: Maxime Ripard
Maxime
sign
Hi Andrew!
On Tue, 2024-12-17 at 09:56 -0600, Andrew Davis wrote:
> On 12/17/24 7:37 AM, A. Sverdlin wrote:
> > From: Alexander Sverdlin
> >
> > Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers
> > with I2C interface.
> >
> > Link: https://www.ti.com/lit/gpn/lp8864-q1
On Tue, 17 Dec 2024 02:40:28 +0200, Dmitry Baryshkov wrote:
> The HDMI Connectors need to perform a variety of tasks when the HDMI
> connector state changes. Such tasks include setting or invalidating CEC
> address, notifying HDMI codec driver, updating scrambler data, etc.
>
> Implementing such t
On Tue, Dec 17, 2024 at 02:40:25AM +0200, Dmitry Baryshkov wrote:
> Several DRM drivers implement HDMI codec support (despite its name it
> applies to both HDMI and DisplayPort drivers). Implement generic
> framework to be used by these drivers. This removes a requirement to
> implement get_eld() c
1 - 100 of 276 matches
Mail list logo
