| Age | Commit message (Collapse) | Author |
|---|
|
Add cs42l44 to the wake_capable_list because it can generate
jack events whilst the bus is stopped.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260708122948.1502227-1-ckeepax@opensource.cirrus.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The Qualcomm controller driver ignores the paging fields of struct
sdw_msg. For a paged access (register address >= 0x8000 on a
paging-capable peripheral, e.g. the SDCA control space at
0x40000000+) the core sets BIT(15) in the wire address and splits the
upper bits into addr_page1/addr_page2, but since the controller never
programmed the SCP_AddrPage registers the peripheral resolved every
such command against their reset value: reads and writes were
silently redirected to addr[14:0] in page 0.
Write the two SCP_AddrPage registers through the command FIFO before
the transfer, as cadence_master.c (cdns_program_scp_addr) and
amd_manager.c (amd_program_scp_addr) do. Like those controllers the
pages are programmed on every paged message rather than cached per
device; a cache can be a follow-up if the two extra FIFO commands
ever matter.
No peripheral on a Qualcomm bus sets prop.paging_support in mainline
today; the first user is the WCD9378 codec, whose driver is being
upstreamed separately - its entire register map, the
wcd937x-compatible analog core included, lives in the SDCA address
space.
Verified on the Fairphone 6 (SM7635): WCD9378 SDCA registers read
back their documented reset defaults and audio capture through the
codec works end-to-end; without this change every paged access landed
in page 0.
Assisted-by: Claude:claude-fable-5
Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20260706192150.143921-1-jorijnvdgraaf@catcrafts.net
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Not like other ghost devices, the 0x000000D010010500 ADR doesn't belong
to any codec. We should disable it in all devices.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>
Link: https://patch.msgid.link/20260703011656.2572959-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Commit 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12
UV surface offset calculation") computes the UV (chroma) surface
start/size as ceiling(half of Y plane start/size) directly from the
U16.16 fixed-point source rectangle:
x = fp_16_16_to_int_ceil(fp_16_16_div2(src.x1));
For a single pipe the source coordinates are integers, so this is
correct.
(UV start = ceiling(half of Y plane start)).
With bigjoiner + a plane scaler the picture changes. The pipe boundary
is a fixed integer destination pixel, but the plane's position and the
scaler ratio are arbitrary, so drm_rect_clip_scaled() maps the seam back
to a *fractional* per-pipe source. For a 1280->2407 upscaled NV12 plane
crossing the seam:
master src: width = 1204 * 1280/2407 = 640.265899, x1 = 0
joiner src: width = 1203 * 1280/2407 = 639.734115, x1 = 640.265884
The luma path floors this to an integer (src.x1 >> 16 = 640), but the
UV path takes ceiling(640.265884 / 2) = ceil(320.13) = 321. The Y plane
then starts at column 640 while the UV plane starts at 321*2 = 642,
pushing the chroma read one column past the 640-wide chroma surface on
the joiner secondary:
[CRTC:382:pipe C] PLANE ATS fault
[CRTC:382:pipe C][PLANE:267:plane 1C] fault (CTL=0x81009400, ...)
The spec "Y plane start" is the integer pixel the luma surface actually
programs (640), not the pre-floor fixed-point value (640.27). Convert
the Y plane start/size to integer first - matching skl_check_main_surface()
- and then apply the ceiling. This is a no-op for the integer (non-joiner)
case and yields the correct, in-bounds chroma offset for the fractional
joiner seam:
before fix after fix
master 1B: x=0 w=321 x=0 w=320 -> [0, 320)
slave 1C: x=321 w=320 x=320 w=320 -> [320, 640)
The two halves now tile the 640-wide chroma plane exactly and the ATS
fault is gone.
Assisted-by: GitHub-Copilot:Claude-Opus-4.8
Fixes: 16df4cc63c58 ("drm/i915/display: Use ceiling division for NV12 UV surface offset calculation")
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patch.msgid.link/20260618181837.687302-1-vidya.srinivas@intel.com
(cherry picked from commit 0c59cc78241c10e5f02d92b28d811b0435e706a7)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Remove the fallback for VRAM to system memory, I tested it and that
doesn't work at all, only a black screen with pipe fault errors were
observed.
On systems with media GT, extra latency is added when accessing stolen
memory when the GT is in MC6. Since we additionally aren't counting how
much memory is used for stolen and we could in theory fill up the
entire stolen area with DPT's, avoid using stolen and only use the
default memory region.
Using stolen may also result in random system hangs under load.
Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/7513
Fixes: 775d0adc01a5 ("drm/xe/fbdev: Limit the usage of stolen for LNL+")
Cc: <stable@vger.kernel.org> # v6.12+
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patch.msgid.link/20260630135523.1775379-2-dev@lankhorst.se
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
Convert IMX8M_BLK_CTRL and IMX9_BLK_CTRL from bool to tristate
to allow building as loadable modules.
This change is required to support Android devices using Generic Kernel
Image (GKI) kernels, where SoC-specific drivers must be built as loadable
modules rather than built into the core kernel image.
For i.MX8M and i.MX9 devices running Android with GKI kernels, the
BLK_CTRL drivers therefore need to be loadable. Without tristate
support, power domains cannot be initialized correctly, making these
systems non-functional under GKI.
Add prompt strings to make these options visible and configurable
in menuconfig, keeping them enabled by default on appropriate platforms.
Also remove the IMX_GPCV2_PM_DOMAINS dependency from IMX9_BLK_CTRL.
This dependency was incorrect from the beginning because i.MX93 uses a
different power domain architecture compared to i.MX8M series:
- i.MX8M uses GPCv2 (General Power Controller v2) for power domain
management, hence IMX8M_BLK_CTRL correctly depends on it.
- i.MX93 uses BLK_CTRL directly without GPCv2. The hardware doesn't
have GPCv2 at all.
Signed-off-by: Zhipeng Wang <zhipeng.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Ulf Hansson <ulfh@kernel.org>
|
|
Print the dma_addr, phys_base and memory region name for the BIOS FB.
Should make it a bit easier to see whether everything looks correct or
not.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-15-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Apparently we never initialize the name of the struct resource
underlying the memory region. Instead we need to look at the
name stored directly in the memory region itself.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-14-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
The local memory BAR has a name (LMEMBAR). Use that instead
of referring to it by its BAR register index.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-12-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
Do the PTE local memory bit check also for the case when
the initial FB lives in stolen. We have two cases to worry about
here: MTL+ with LMEMBAR, and pre-MTL with stolen being just
(slightly special) physical memory.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-11-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
Add a few helpers that allow us to abstract the xe initial FB PTE
check a bit. Still very ad-hoc compared to the nicely abstracted
i915 counterpart, but whatever.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-10-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
Inform the poor sop reading the logs why the initial FB was rejected
if there is no stolen memory.
Technically this should perhaps be an error since the plane is known
to be enabled at this point, and if there is no stolen then it clearly
can't be scanning out from anywhere. But maybe there are some
virtualization passthrough cases and whatnot where we might not be
able to get access to stolen, so keep it as debug (same as i915).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-9-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
For some reason we've split the alignment of 'base' vs. 'size'
to live on separate sides of the xe initial plane PTE readout.
There's no reason for this split, so make things less confusing
by aligning both at the same time.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patch.msgid.link/20260511214122.8468-7-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
Acked-by: Matthew Brost <matthew.brost@intel.com> #teams
|
|
The initial FB stuff is ultimately about display stuff, so
use the proper display specific debug level for it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-6-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Respect the user's choice of depth/bpp for the fbdev framebuffer
and throw out the fb we inherited from the BIOS if it doesn't
match.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-4-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Pull the "is the BIOS FB OK?" checks to a helper function. We'll
add other relevant checks there later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-3-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Properly turn off the plane if it is enabled but
.get_initial_plane_config() failed for whatever reason.
The hardware does (or at least did) perform some kind of automagic
plane disable when the pipe gets disabled, but we don't rely on that
anywhere else either. Also the GGTT/actual memory may get clobbered
afterwards, so leaving the plane enabled here could result in visual
corruption/GTT faults/etc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patch.msgid.link/20260511214122.8468-2-ville.syrjala@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
|
|
Correct detach kdoc ("device/pasid from"), article use before
IOMMUFD_OBJ_*, and "propogated" -> "propagated".
Link: https://patch.msgid.link/r/20260714024440.188358-1-15927021679@163.com
Signed-off-by: xiongweimin <xiongweimin@kylinos.cn>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
iommu_mock_device_add() first calls iommu_fwspec_init(), which on
success allocates both dev->iommu (via dev_iommu_get()) and
dev->iommu->fwspec. If the subsequent device_add(dev) call fails,
the error path only calls iommu_fwspec_free(dev), which frees
fwspec but leaves dev->iommu still allocated.
This triggers the following kmemleak report when fuzzing with Syzkaller:
BUG: memory leak
unreferenced object 0xffff888011e0a200 (size 192):
comm "syz.1.1695", pid 24885, jiffies 4295222527
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .............N..
ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff ................
backtrace (crc 25df5bb3):
kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline]
slab_post_alloc_hook mm/slub.c:4575 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
__kmalloc_cache_noprof+0x47a/0x710 mm/slub.c:5415
kmalloc_noprof include/linux/slab.h:950 [inline]
kzalloc_noprof include/linux/slab.h:1188 [inline]
dev_iommu_get+0x10c/0x1a0 drivers/iommu/iommu.c:408
iommu_fwspec_init+0x288/0x4d0 drivers/iommu/iommu.c:3087
iommu_mock_device_add+0x46/0xb0 drivers/iommu/iommu.c:385
mock_dev_create drivers/iommu/iommufd/selftest.c:1025 [inline]
iommufd_test_mock_domain drivers/iommu/iommufd/selftest.c:1066 [inline]
iommufd_test+0x2f8a/0x6190 drivers/iommu/iommufd/selftest.c:2072
iommufd_fops_ioctl+0x367/0x540 drivers/iommu/iommufd/main.c:533
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:597 [inline]
__se_sys_ioctl fs/ioctl.c:583 [inline]
__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Fix this by calling dev_iommu_free(dev) instead of iommu_fwspec_free(dev)
in the device_add() failure path. dev_iommu_free() frees both fwspec
and the outer dev_iommu struct and clears dev->iommu.
Link: https://patch.msgid.link/r/76AC62D46B998556+20260711055119.1003477-1-peiyang_he@smail.nju.edu.cn
Reported-by: Peiyang He <peiyang_he@smail.nju.edu.cn>
Fixes: 2a918911ed3d ("iommufd: Register iommufd mock devices with fwspec")
Cc: stable@vger.kernel.org
Signed-off-by: Peiyang He <peiyang_he@smail.nju.edu.cn>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
|
|
get_map_page() allocates bitmap pages using get_zeroed_page().
The bitmaps can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of get_zeroed_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260713-b4-rdma-v2-5-65d2a1a5180c@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
mthca_array is essentially a sparse array of pointers and there is no
need to allocate its memory using page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of get_zeroed_page() with kzalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260713-b4-rdma-v2-4-65d2a1a5180c@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
mthca_reg_user_mr() allocates an array of DMA addresses during memory
registration.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260713-b4-rdma-v2-3-65d2a1a5180c@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
mlx5_ib_mr_wqe_pfault_handler() allocates a scratch buffer for
parsing work queue entries during page fault handling.
This buffer can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260713-b4-rdma-v2-2-65d2a1a5180c@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
ib_umem_get() allocates an array of pointers to struct page for
pin_user_pages_fast() calls during memory registration.
This array can be allocated with kmalloc() as there's nothing special
about it to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Link: https://patch.msgid.link/20260713-b4-rdma-v2-1-65d2a1a5180c@kernel.org
Signed-off-by: Leon Romanovsky <leon@kernel.org>
|
|
The current descriptor layout is:
struct dw_edma_desc *desc
└─ chunk list
└─ burst[]
Creating a DMA descriptor requires at least two kzalloc() calls because
each chunk is allocated as a linked-list node. Since the number of bursts
is already known when the descriptor is created, this linked-list layer is
unnecessary.
Move the burst array directly into struct dw_edma_desc and remove the
struct dw_edma_chunk layer entirely.
Use start_burst and done_burst to track the current bursts, which current
are in the DMA link list.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-10-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The current descriptor layout is:
struct dw_edma_desc *desc
└─ chunk list
└─ burst list
Creating a DMA descriptor requires at least three kzalloc() calls because
each burst is allocated as a linked-list node. Since the number of bursts
is already known when the descriptor is created, a linked list is not
necessary.
Allocate a burst array when creating each chunk to simplify the code and
eliminate one kzalloc() call.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-9-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Use common dw_edma_core_start() for both eDMA and HDMA. Remove .start()
callback functions at eDMA and HDMA.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-8-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Add a non_ll_start() callback and move the common non-linked-list channel
handling into the EDMA core so it can be shared by both the EDMA and HDMA.
Prepare for the upcoming reorganization of the burst and chunk structures.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-7-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Introduce four new callbacks to fill link list entries in preparation for
replacing dw_(edma|hdma)_v0_core_start().
Filling link list entries is expected to become more complex, and without
this abstraction both eDMA and HDMA paths would need to duplicate the same
logic. Add fill-entry callbacks so the code can be shared cleanly between
eDMA and HDMA implementations.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-6-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Move the channel-enable logic into a new helper function,
dw_(edma|hdma)_v0_core_ch_enable(), in preparation for supporting dynamic
link entry additions.
No functional changes.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-5-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Some helper functions do not use any information from dw_edma_chunk, so
passing a dw_edma_chan pointer directly avoids an unnecessary level of
pointer dereferencing and simplifies data access.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-4-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
dw_edma_chan
ll_region is identical for all chunks belonging to the same DMA channel,
so there is no need to copy it into each chunk. Move ll_region to
struct dw_edma_chan to avoid redundant copies.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-3-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Reusing ll_region.sz as the transfer size is misleading because
ll_region.sz represents the memory size of the EDMA link list, not the
amount of data to be transferred.
Add a new xfer_sz field to explicitly indicate the total transfer size
of a chunk.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-2-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The control field in a DMA link list entry must be updated as the final
step because it includes the CB bit, which indicates whether the entry is
ready. Add dma_wmb() to ensure the correct memory write ordering.
Currently the driver does not update DMA link entries while the DMA is
running, so no visible failure occurs. However, fixing the ordering now
prepares the driver for supporting link entry updates during DMA operation.
Tested-by: Koichiro Den <den@valinux.co.jp>
Tested-By: Devendra Verma <devendra.verma@amd.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260713-edma_ll-v7-1-6fb7498c901e@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
When use_dma_read is enabled, the IRQ handler unconditionally overwrites
irq_status with the return value of get_dma_status(). For write operations,
DMA status returns 0 since no DMA read is in progress, causing irq_status
to become 0. The subsequent completion signal is never triggered and the
write operation times out with -ETIMEDOUT:
cadence-qspi f1010000.spi: Indirect write timeout
spi-nor spi0.1: operation failed with -110
Fix this by separating the DMA completion path from the write interrupt
path. If get_dma_status() indicates DMA read completion, signal completion
and return immediately. Otherwise, preserve the original irq_status so that
write completion interrupts are correctly recognized and signalled.
Fixes: aac733a96636 ("spi: cadence-qspi: Fix style and improve readability")
Signed-off-by: Srikanth Boyapally <srikanth.boyapally@amd.com>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Link: https://patch.msgid.link/20260708045148.2993313-1-srikanth.boyapally@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use dev_err_probe() to make error code handling simpler and handle
deferred probe nicely (avoid spamming logs).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260705172737.120095-6-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Use dev_err_probe() to make error code handling simpler and handle
deferred probe nicely (avoid spamming logs).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260705172737.120095-5-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Instead of multiple '&pdev->dev' dereferences, just use a local 'dev'
variable which makes multiple function calls shorter thus easier to
follow.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260705172737.120095-4-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add error handling statement to fls_edma3_irq_init() for the
devm_kasprintf call.
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: imx@lists.linux.dev
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/2026070605-frying-fling-b9c5@gregkh
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
* acpi-irqchip:
irqchip/gic-v5: Enable GICv5 IWB ACPI probe ordering detection
ACPI/IORT: Implement ACPI infrastructure to enable GICv5 IWB probe deferral
ACPI: irq: Move RISC-V interrupt controllers autodep to ACPI IRQ code
ACPI: RISC-V: Fix riscv_acpi_add_prt_dep() loop handling
ACPI: RISC-V: Check acpi_get_handle() status in riscv_acpi_add_prt_dep()
ACPI: RISC-V: Fix riscv_acpi_irq_get_dep() loop termination
ACPI: Add acpi_device_clear_deps() helper function
|
|
* acpi-bus:
ACPI: scan: Set power.no_pm for all struct acpi_device objects
ACPI: bus: Eliminate struct acpi_driver
* acpi-numa:
ACPI: NUMA: remove redundant node_set() call
* acpi-apei:
ACPI: APEI: GHES: Mark ghes_in_nmi_spool_from_list() as maybe unused
* pnp:
PNP: Fix card device cleanup on registration failure
PNP: Drop unused assignment of pnp_device_id driver data
|
|
dw_spi_dma_wait_tx_done() polls dw_spi_dma_tx_busy(), which only checks
DW_SPI_SR_TF_EMPT. An empty TX FIFO merely means the last data word has
been moved into the shift register; the transfer is not complete on the
bus until DW_SPI_SR_BUSY is also cleared. As a result the wait can
return while the controller is still shifting out the final word.
Any caller that tears down or reconfigures the controller right after
the transfer can then lose the tail of the transfer.
The memory-operation path in spi-dw-core.c already waits for both
DW_SPI_SR_BUSY == 0 and DW_SPI_SR_TF_EMPT == 1. Use the same completion
condition in the DMA path so the transfer is guaranteed to be finished
on the bus before the wait returns.
Signed-off-by: Wang YuWei <1973615295@qq.com>
Link: https://patch.msgid.link/tencent_4EA7B5C94669ED4C38A5F6C1C9126E5D9106@qq.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
|
|
The driver has an OF match table wired to .of_match_table, but does
not export the table with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE(of, ...) entry so module alias
information is generated for OF based module autoloading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the platform driver, and the missing module alias publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
|
|
Tegra264 changes the register layout to accommodate wider fields
for duty and scale, and adds configurable depth which will be
supported in a later patch. The enable bit also moves from CSR_0
to a separate CSR_1 register.
To support the new enable register location, introduce an
enable_reg field in struct tegra_pwm_soc that identifies which
register contains the PWM_ENABLE bit. tegra_pwm_enable() and
tegra_pwm_disable() read/write this field accordingly, and
tegra_pwm_config() skips OR-ing PWM_ENABLE into its CSR_0 write
on SoCs where the enable bit is not in CSR_0.
Update the top comment to describe the register layout in more
detail.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260701-t264-pwm-v6-6-2718f61f411f@nvidia.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
Tegra264 has wider fields for the duty and scale register fields.
Parameterize the scale field width. The depth value becomes
disconnected from the duty field width, so define it separately
and remove the duty field width definition.
Co-developed-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260701-t264-pwm-v6-5-2718f61f411f@nvidia.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
On Tegra264, each PWM instance has two registers (per channel, of which
there is one). Update the tegra_pwm_readl/tegra_pwm_writel helper
functions to take channel (as struct pwm_device *) and offset
separately.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260701-t264-pwm-v6-4-2718f61f411f@nvidia.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
The clock driving the Tegra PWM IP can be sourced from different parent
clocks. Hence, let dev_pm_opp_set_rate() set the max clock rate based
upon the current parent clock that can be specified via device-tree.
After this, the Tegra194 SoC data becomes redundant, so get rid of it.
Signed-off-by: Yi-Wei Wang <yiweiw@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Co-developed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260701-t264-pwm-v6-3-2718f61f411f@nvidia.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
Prefix driver-local defines and functions with tegra_/TEGRA_ to clearly
distinguish them from any general PWM related symbols.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260701-t264-pwm-v6-2-2718f61f411f@nvidia.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
|
|
esd_usb_disconnect() frees each CAN netdev with free_candev() inside
its per-netdev loop and only calls unlink_all_urbs(dev) afterwards.
The per-netdev private data (struct esd_usb_net_priv) is embedded in
the net_device allocation returned by alloc_candev(), so once
free_candev() has run, dev->nets[i] points to freed memory.
unlink_all_urbs() then dereferences the freed dev->nets[i] to kill the
per-netdev TX anchor (usb_kill_anchored_urbs(&priv->tx_submitted)),
clear active_tx_jobs, and reset priv->tx_contexts[].
Reorder the teardown so the anchored URBs are killed before the netdevs
are freed, matching other CAN/USB drivers in the same directory such as
ems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then
free: unregister the netdevs first (which stops their TX queues), call
unlink_all_urbs(dev) once, then free the netdevs.
This issue was found by an in-house static analysis tool.
Fixes: 96d8e90382dc ("can: Add driver for esd CAN-USB/2 device")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.5
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Link: https://patch.msgid.link/20260709164159.497640-1-fanwu01@zju.edu.cn
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
