On Wed, Jun 29, 2022 at 3:16 AM Michael Schmitz <schmitzmic@xxxxxxxxx> wrote:
>
> V1 of a patch series to convert m68k Amiga WD33C93 drivers to the
> DMA API.
>
> This series was precipitated by Arnd removing CONFIG_VIRT_TO_BUS. The
> m68k WD33C93 still used virt_to_bus to convert virtual addresses to
> physical addresses suitable for the DMA engines (note m68k does not
> have an IOMMU and uses a direct mapping for DMA addresses).
>
> Arnd suggested to use dma_map_single() to set up dma mappings instead
> of open-coding much the same in every driver dma_setup() function.
>
> It appears that m68k (MMU, except for coldfire) will set up pages for
> DMA transfers as non-cacheable, thus obviating the need for explicit
> cache management.
To clarify, the dma-mapping API has two ways of dealing with this:
- the streaming API (dma_map/unmap_...) uses explicit cache flushes
- the coherent API (dma_alloc_coherent etc) uses page protections
to prevent caching.
These three drivers use the streaming API because they operate on
data passed in from the outside, so the non-cacheable protection bits
are not used here.
> DMA setup on a3000 host adapters can be simplified to skip bounce
> buffer use (assuming SCSI buffers passed to the driver are cache> Thanks, and Cheers,
>
> Michael
>
> line aligned; a safe bet except for maybe sg.c input).
>
> On gvp11 and a2091 host adapters, only the lowest 16 MB of physical
> memory can be directy addressed by DMA, and bounce buffers from that
> space must still be used (possibly allocated from chip RAM using the
> custom allocator) if buffers are located in the higher memory regions.
>
> The m68k VME mvme147 driver has no DMA addressing or alignment
> restrictions and can be converted in the same way as the Amiga a3000
> one, but will require conversion to a platform device driver first.
Right, it seems that the old hack of passing a NULL device pointer
no longer works, and that is probably for the better.
If you want an easy way out, the driver can just call
platform_device_register_full() to create its own device with a
dma_mask set up, and use that device for the DMA API, but
not actually match the device to a driver.
> Only compile tested so far, and hardware testing might be hard to do.
> I'd appreciate someone giving this a thorough review.
Looks all good to me.
Arnd
