[U-Boot] [PATCH 4/5] arm: socfpga: Add intermediate driver between flash and FPGA manager

[Chee, Tien Fong]

On Isn, 2017-08-07 at 10:19 +0200, Marek Vasut wrote:
> On 08/07/2017 10:16 AM, Chee, Tien Fong wrote:
> > 
> > On Isn, 2017-07-31 at 12:55 +0200, Marek Vasut wrote:
> > > 
> > > On 07/31/2017 12:50 PM, tien.fong.chee at intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.chee at intel.com>
> > > > 
> > > > Configuration flip-flop driver is mainly used for handling the
> > > > FPGA
> > > > program
> > > > operation where the FPGA image loading from the flash into FPGA
> > > > manager.
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
> > > > ---
> > > >  arch/arm/mach-socfpga/cff.c              |  581
> > > > ++++++++++++++++++++++++++++++
> > > >  arch/arm/mach-socfpga/include/mach/cff.h |   40 ++
> > > >  include/configs/socfpga_arria10_socdk.h  |    6 +
> > > >  3 files changed, 627 insertions(+), 0 deletions(-)
> > > >  create mode 100644 arch/arm/mach-socfpga/cff.c
> > > >  create mode 100644 arch/arm/mach-socfpga/include/mach/cff.h
> > > > 
> > > Same comment as to previous patch, there is already support for
> > > loading
> > > FPGA from storage used by Xilinx, improve on that.
> > > 
> > Hi Marek,
> > 
> > After i going through the xilinx codes, i found that we are sharing
> > similar fpga framework design. The only different are the way of
> > decoding fpga design and loading from flash to fpga. So this would
> > be
> > handled in cff.c, as for xilinx if i am not mistaken
> > is drivers/fpga/zynqpl.c. I think appropiate location for cff.c
> > should
> > be in arch/mach-socfpga because this is not fpga driver, this is
> > more
> > like platform specific algorithm mechanism to handle fpga decoding
> > and
> > loading from flash to fpga. For the U-boot console command fpga
> > loafs,
> > which will wrap the cff.c and acting as upper layer driver
> > for  user
> > console interface. I plan to enhance this after having a complete
> > boot
> > from sdmmc, qspi and nand because this require considering a lot
> > use
> > case scenarios, and some workaround on PLL clock glitch issue. You
> > know
> > our DDR IOs is part of the fpga periph rbf, simply calling fpga
> > loadfs
> > to reconfigure fpga can corrupt the DDR IOs configuration, and
> > board
> > may hang if it is not handle properly, so i need a workable
> > complete
> > boot to console environment for testing out the enhancement.
> > 
> > Let me know what you think about this patchset, and can i continue
> > process with this patchset?
> I think cff.c is not even needed. Otherwise, submit patches and we'll
> see how that looks.
> 
sure. we can discuss again on new patches.