[U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes

[Vikas MANOCHA]

Hi Graham,

> -----Original Message-----
> From: Graham Moore [mailto:grmoore at opensource.altera.com]
> Sent: Monday, July 06, 2015 10:57 AM
> To: Vikas MANOCHA
> Cc: Stefan Roese; u-boot at lists.denx.de; dinguyen at opensource.altera.com;
> jteki at openedev.com
> Subject: Re: [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect
> rd-writes
> 
> On 07/02/2015 12:50 PM, Vikas MANOCHA wrote:
> > Hi Graham,
> >
> >> -----Original Message-----
> >> From: Graham Moore [mailto:grmoore at opensource.altera.com]
> >> Sent: Tuesday, June 23, 2015 7:37 AM
> >> To: Vikas MANOCHA
> >> Cc: Stefan Roese; u-boot at lists.denx.de;
> >> dinguyen at opensource.altera.com; jteki at openedev.com
> >> Subject: Re: [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix
> >> indirect rd-writes
> >>
> >> On 06/22/2015 06:31 PM, Vikas MANOCHA wrote:
> >> ...
> >>
> >>>>> The point is if after applying above mentioned patch (...: fix
> >>>>> indirect read/write start address), Read/write are working fine,
> >>>>> then trigger_base value of 0xFFA00_0000 should also work fine.
> >>>>> Can you please modify the trigger_base value from 0x0 to
> >>>>> 0xFFA0_0000 in Socfpga.dtsi & check.
> >>>>> If it works, it would mean both (socfpga & stv0991) are behaving
> same.
> >>>>
> >>>> No. With this change, the "sf read" command crashes / hangs on the
> >>>> SoCFPGA board.
> >>>
> >>> Ok, I don't know why socfpga is not working with trigger_base to be
> >> 0xFFA0_0000.
> >>> Normally it should work, Graham also thinks the same, Let's wait for
> >>> his
> >> discussion with the Altera designers.
> >>>
> >>
> >> Wait a minute, on SoCFPGA, the flashbase is 0xffa00000, and the
> >> trigger base is 0x00000000.  The point of having a different address
> >> was that they needed to be different on SoCFPGA, right?
> >>
> >> As for why they're different, the Altera Cyclone5 SoCFPGA has a
> >> complex multilevel interconnect where the QSPI is three levels down,
> >> and is the only slave of an AHB master.  At that level of the
> >> interconnect, the base address has long been stripped off, it was used to
> select down to the final master.
> >> The QSPI is the only thing on that AHB bus, so its address is zero.
> >> Or at least that's how I understand it.
> >
> > If we check the code for reading/writing to the FIFO/SRAM of the
> controller, complete base address is being used.
> > Which means CPU is using address 0xFFA0_0000, so does not seems like
> base address is stripped off. It is only for the trigger address which needs
> programming to  0x0 ?
> >
> > Regardless, it is something specific to socfpga architecture & should not be
> part of cadence qspi driver.
> >
> 
> I'm sorry, I don't understand your comment.  What is 'it' that should not be
> part of the cadence qspi driver?

I meant : Trigger base address programming to one address (which is 0x0 in case of socfpga) & then reading/writing from 
another locations (NOR location 0xFFA0_0000 in case of socfpga) : It shouldn't be like this in the driver as per the definition of trigger base address.

Trigger base address is the location which should be used to read/write in indirect mode. It actually makes it like reading sram & hence called indirect mode.

It is what was explained & implemented in attached patch. Stefan tested it & it didn't work on socfpga platform, there seems something specific to arch, to be debugged.

Rgds,
Vikas

> 
> -Graham
> 
> > Rgds,
> > Vikas
> >
> >>
> >> -Graham

-------------- next part --------------
An embedded message was scrubbed...
From: Vikas MANOCHA <vikas.manocha at st.com>
Subject: [PATCH RESEND 6/7] spi: cadence_qspi: fix base trigger address & transfer start address
Date: Wed, 17 Jun 2015 04:14:24 +0200
Size: 8985
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150706/5710eca7/attachment.mht>