Re: [PATCH v2 2/2] hw/ssi: xilinx_spips: Implement basic QSPI DMA support

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

On Wed, Feb 10, 2021 at 05:08:01PM +0800, Bin Meng wrote:
> On Tue, Feb 9, 2021 at 10:30 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Edgar,
> >
> > On Mon, Feb 8, 2021 at 11:17 PM Edgar E. Iglesias
> > <edgar.iglesias@gmail.com> wrote:
> > >
> > >
> > >
> > > On Mon, Feb 8, 2021 at 3:45 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > >>
> > >> Hi Edgar,
> > >>
> > >> On Mon, Feb 8, 2021 at 10:34 PM Edgar E. Iglesias
> > >> <edgar.iglesias@gmail.com> wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Mon, 8 Feb 2021, 15:10 Bin Meng, <bmeng.cn@gmail.com> wrote:
> > >> >>
> > >> >> Hi Edgar,
> > >> >>
> > >> >> On Mon, Feb 8, 2021 at 8:44 PM Edgar E. Iglesias
> > >> >> <edgar.iglesias@gmail.com> wrote:
> > >> >> >
> > >> >> > On Mon, Feb 08, 2021 at 01:25:24PM +0800, Bin Meng wrote:
> > >> >> > > From: Xuzhou Cheng <xuzhou.cheng@windriver.com>
> > >> >> > >
> > >> >> > > ZynqMP QSPI supports SPI transfer using DMA mode, but currently this
> > >> >> > > is unimplemented. When QSPI is programmed to use DMA mode, QEMU will
> > >> >> > > crash. This is observed when testing VxWorks 7.
> > >> >> > >
> > >> >> > > Add a basic implementation of QSPI DMA functionality.
> > >> >> > >
> > >> >> > > Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com>
> > >> >> > > Signed-off-by: Bin Meng <bin.meng@windriver.com>
> > >> >> >
> > >> >> > + Francisco
> > >> >> >
> > >> >> > Hi,
> > >> >> >
> > >> >> > Like Peter commented on the previous version, the DMA unit is actully separate.
> > >> >>
> > >> >> Is it really separate? In the Xilinx ZynqMP datasheet, it's an
> > >> >> integrated DMA unit dedicated for QSPI usage. IIUC, other modules on
> > >> >> the ZynqMP SoC cannot use it to do any DMA transfer. To me this is no
> > >> >> different like a DMA engine in a ethernet controller.
> > >> >
> > >> >
> > >> > Yes, it's a separate module.
> > >> >
> > >> >>
> > >> >> > This module is better modelled by pushing data through the Stream framework
> > >> >> > into the DMA. The DMA model is not upstream but can be found here:
> > >> >> > https://github.com/Xilinx/qemu/blob/master/hw/dma/csu_stream_dma.c
> > >> >> >
> > >> >>
> > >> >> What's the benefit of modeling it using the stream framework?
> > >> >
> > >> >
> > >> >
> > >> > Because it matches real hw and this particular dma exists in various instances, not only in qspi. We don't want duplicate implementations of the same dma.
> > >> >
> > >>
> > >> Would you please share more details, like what other peripherals are
> > >> using this same DMA model?
> > >>
> > >
> > > It's used by the Crypto blocks (SHA, AES) and by the bitstream programming blocks on the ZynqMP.
> > > In Versal there's the same plus some additional uses of this DMA...
> >
> > Sigh, it's not obvious from the ZynqMP datasheet. Indeed the crypto
> > blocks seem to be using the same IP that QSPI uses for its DMA mode.
> > With that additional information, I agree modeling the DMA as a
> > separate model makes sense.
> >
> > Will investigate the Xilinx fork, and report back.
> 
> Unfortunately the Xilinx fork of QEMU does not boot VxWorks. It looks
> like the fork has quite a lot of difference from the upstream QEMU.
> For example, the fork has a new machine name for ZynqMP which does not
> exist in the upstream. It seems quite a lot has not been upstreamed
> yet, sigh.
> 
> The CSU DMA model in the Xilinx fork seems to be quite complicated and
> has lots of functionalities. However right now our goal is to
> implement a minimum model that could be used to work with the GQSPI
> model to make the QSPI DMA functionality work.
> We implemented a basic CSU DMA model based on the Xilinx fork, and
> will send it as v3 soon.
>

We've prepared a patch with the QSPI DMA support using the complete
DMA model. We'll send that out soon. It's better if you base your
work on that.

Cheers,
Edgar