[PATCH v2 00/15] dmaengine: bcm2835: add BCM2711 40-bit DMA support

[Andrea della Porta]

On 17:16 Tue 12 Mar     , Dave Stevenson wrote:
> Hi Andrea
> 
> On Tue, 12 Mar 2024 at 09:12, Andrea della Porta <andrea.porta at suse.com> wrote:
> >
> > * Spam *
> > The BCM2711 has 4 DMA channels with a 40-bit address range, allowing them
> > to access the full 4GB of memory on a Pi 4.
> > This patchset aims to update the dma engine for BCM* chipset with respect
> > to current advancements in downstream vendor tree. In particular, it
> > supports the BCM2711 DMA engine in terms of extended DMA addressing to 40 bit.
> >
> > Changes with respect to the first version (see [1]) of this patchset:
> >
> > * dropped support of the new BCM2712. It will be the focus of a subsequent
> >   patch.
> >
> > * merged patchset from Stefan Wahren [2] to support newer chipset with a
> >   platform agnostic design, while also retaining the new features added
> >   from downstream [1], as follows:
> >
> >   - patches from 1 to 5 are preparatory, adding some features and bugfix
> >     common to all chipsets.
> >   - patches from 6 to 12 add hw abstraction
> >   - patches 13 to 15 eventually add 40 bit and BCM2711 support
> >
> > * fixed a couple of bugs from [2] relative to address shifting on 40 bit
> >   support specific code
> >
> > * added the relevant entries in the dts and DT binding that was missing
> >   in the first patch
> >
> > * used FIELD_PREP() wherever appropriate as advised in [3]
> >
> > * of_match_node() has been replaced by the more generic device_get_match_data(),
> >   as per [4]
> >
> > * fixed several errors and warnings from checkpatch
> >
> >
> > Please note that there is still a pending discussion around here [5]:
> > this patch still use the current approach (used in both downstream
> > code and in Stefan's redesigned patchset) of getting the address as it is
> > (dma_addr_t) and just add the relevant offset when needed (on 40 bit
> > channel, see .addr_offset in struct bcm2835_dma_cfg). This is not
> > optimal but still deemed as less hacky than using DMA internals (see
> > [6]). As soon as there will be guidelines for [5] or dma_map_resource()
> > will take care of dma_ranges, a subsequent patch will adjust accordingly.
> >
> > Since there is an ongoing effort from Dave Stevenson to upstream a
> > patchset with similar goals, I'm adding him to the email loop in order
> > seek for collaboration.
> 
> Please hold fire on these patches until we resolve the dma-ranges question.
> If the dma-ranges are defined correctly, then the cb_offset is not
> required as the mapping deals with it.
> 
> At present we have a mess with the 32bit DMA controllers, and need to
> clean it up whilst still having old DT files work. Fixing it up also
> requires fixing the DMA users (primarily MMC, SPI, and vc4 HDMI
> audio), so will need some care over patch ordering to avoid
> regressions.
> If at all possible then I would like to avoid the same mess on the 40
> bit controllers too.
>

I agree with you: I've just sent the entire patchset again for consistency since
I had an unlucky issue with the internal imap server that results in the patchset to be
splitted and to be *not* received by all intended recipients. I saw that you were
one of those so I apologize for the inconvenience. I'll wait for any guidelines
regarding dmap_map_resource() and how to proceed about that.

Many thanks,
Andrea
 
> Thanks
>   Dave
> 
> FWIW my work in progress branch is currently
> https://github.com/6by9/linux/tree/mainline_2712_rp1_dma_vc4_rc5,
> which includes my fixed up set of Stefan's patches, as well as all the
> other patches that need working on for Pi5 support upstream.
> 
> > Many thanks,
> >
> > Andrea
> >
> > Links:
> > [1] https://lore.kernel.org/linux-arm-kernel/cover.1706948717.git.andrea.porta@suse.com/
> > [2] https://lore.kernel.org/linux-arm-kernel/13ec386b-2305-27da-9765-8fa3ad71146c@i2se.com/T/
> > [3] https://lore.kernel.org/linux-arm-kernel/YguMW8n1q0ZV5tKH@matsya/
> > [4] https://lore.kernel.org/linux-arm-kernel/1e71c153-e482-409c-b229-9b9c0662b67e@arm.com/
> > [5] https://lore.kernel.org/all/CAPY8ntByJYzSv0kTAc1kY0Dp=vwrzcA0oWiPpyg7x7_BQwGSnA@mail.gmail.com/
> > [6] https://lkml.org/lkml/2024/2/5/1161
> >
> > Andrea della Porta (11):
> >   dmaengine: bcm2835: Fix several spellos
> >   dmaengine: bcm2835: Support common dma-channel-mask
> >   dmaengine: bcm2835: move CB info generation into separate function
> >   dmaengine: bcm2835: move CB final extra info generation into function
> >   dmaengine: bcm2835: make address increment platform independent
> >   dmaengine: bcm2385: drop info parameters
> >   dmaengine: bcm2835: pass dma_chan to generic functions
> >   dmaengine: bcm2835: introduce multi platform support
> >   dt-bindings: dma: Added bcm2711-dma
> >   dmaengine: bcm2835: Add BCM2711 40-bit DMA support
> >   ARM: dts: bcm2711: add bcm2711-dma node
> >
> > Dom Cobley (2):
> >   dmaengine: bcm2835: Support dma flags for multi-beat burst
> >   dmaengine: bcm2835: Fixes for dma_abort
> >
> > Phil Elwell (2):
> >   dmaengine: bcm2835: Add support for per-channel flags
> >   dmaengine: bcm2835: Add NO_WAIT_RESP, DMA_WIDE_SOURCE and
> >     DMA_WIDE_DEST flag
> >
> >  .../bindings/dma/brcm,bcm2835-dma.yaml        |    4 +-
> >  arch/arm/boot/dts/broadcom/bcm2711.dtsi       |   16 +
> >  drivers/dma/bcm2835-dma.c                     | 1084 +++++++++++++----
> >  3 files changed, 892 insertions(+), 212 deletions(-)
> >
> > --
> > 2.35.3
> >
> >