Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make bcm2835 DMA address handling less egregious #6658

Merged
merged 2 commits into from
Feb 7, 2025

Conversation

pelwell
Copy link
Contributor

@pelwell pelwell commented Feb 7, 2025

Replace calls to phys_to_dma (and function that belongs to the internals of the DMA framework) with dma_map_resource. Note that this patch does not include matching calls to dma_unmap_resource because the dma_device struct does not include a method to release a dma_async_tx_descriptor, requiring other means to decide when it's no longer needed, and because it does nothing if direct DMA is being used - the mapping process is just an address calculation.

fancer and others added 2 commits February 7, 2025 10:40
A basic device-specific linear memory mapping was introduced back in
commit ("dma: Take into account dma_pfn_offset") as a single-valued offset
preserved in the device.dma_pfn_offset field, which was initialized for
instance by means of the "dma-ranges" DT property. Afterwards the
functionality was extended to support more than one device-specific region
defined in the device.dma_range_map list of maps. But all of these
improvements concerned a single pointer, page or sg DMA-mapping methods,
while the system resource mapping function turned to miss the
corresponding modification. Thus the dma_direct_map_resource() method now
just casts the CPU physical address to the device DMA address with no
dma-ranges-based mapping taking into account, which is obviously wrong.
Let's fix it by using the phys_to_dma_direct() method to get the
device-specific bus address from the passed memory resource for the case
of the directly mapped DMA.

Fixes: 25f1e18 ("dma: Take into account dma_pfn_offset")
Signed-off-by: Serge Semin <[email protected]>
The commit titled "bcm2835-dma: Derive slave DMA addresses correctly"
(now squashed into DMA roll-up) moved the responsibility for calculating
DMA addresses to the DMA driver. Unfortunately it committed the sin of
using phys_to_dma directly rather than using the approved API, i.e.
dma_map_resource.

Signed-off-by: Phil Elwell <[email protected]>
@pelwell pelwell merged commit 71e5e32 into raspberrypi:rpi-6.14.y Feb 7, 2025
11 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants