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

[Bin Meng]

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.

Regards,
Bin