Re: Zynq UltraScale MPSoC, DMA driver

["Jorge Ramirez-Ortiz, Foundries" <jorge@foundries.io>]

On 08/06/21, Michal Simek wrote:
> Hi,
> 
> On 6/7/21 8:41 PM, Jorge Ramirez-Ortiz, Foundries wrote:
> > On 07/06/21, Jorge Ramirez-Ortiz, Foundries wrote:
> >> hi Michal
> >>
> >> um, when we exchanged emails about enabling ECC support for MPSoC, I
> >> left with the understanding that there already was a DMA driver
> >> available in u-boot that I could use to initialize the memory.
> >>
> >> do you have something in the works or will I have to write such a
> >> driver? compatible would be 'xlnx,zynqmp-dma-1.0'
> > 
> > alternatively, would it be acceptable - upstream - If I just init ECC
> > as done by FSBL (ie, without a proper DMA driver, just accessing the
> > controller)?
> 
> There are 2 things here.
> The first thing that would be the best to do it proper framework which
> is likely dma where dma_memset should be likely added.
> The second that this code should land in SPL which can't be big that's
> why this feature should be very small.

the way I am doing it ATM is just a verbatim of XFsbl_EccInit (grabs a
channel and inits all memory to DEADBEEF). About 100 LOC total.

I belive the FSBL copyright notice allows for that (below excerpt).

[..] Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
 in the Software without restriction, including without limitation the rights
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the Software is
 furnished to do so,  [..]

but yes this just works as expected.

a bit trickier is where to init from - for the particular product
I am working on I can hardcode the addresses and sizes and init right
after board_init_f in spl.c...havent had the time to think about
something portable yet - if you have a suggestion I could send both
patches (one for the spl_ecc_init(addr, len) function and another one
calling it)

thanks for your inputs

> 
> Based on above I think that would be good to have long term both of them
> in the tree. It means feel free to send short version and let's look at
> it and dma one should be hopefully pretty much using the same code via
> dma framework.
> 
> Thanks,
> Michal
>