From: Graham Moore <grmoore@opensource.altera.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes
Date: Mon, 6 Jul 2015 12:56:43 -0500 [thread overview]
Message-ID: <559AC15B.20008@opensource.altera.com> (raw)
In-Reply-To: <9026814FBF99304F9FA3AC3FB72F3E2F016C37C8@SAFEX1MAIL4.st.com>
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?
-Graham
> Rgds,
> Vikas
>
>>
>> -Graham
next prev parent reply other threads:[~2015-07-06 17:56 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 2:14 [U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 1/7] spi: cadence_qspi: remove sram polling from flash read Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 2/7] spi: cadence_qspi: read can be independent of fifo width Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 3/7] spi: cadence_qspi: remove sram polling from flash write Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 4/7] spi: cadence_qspi: move trigger base configuration in init Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 5/7] spi: cadence_qspi: fix indirect read/write start address Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 6/7] spi: cadence_qspi: fix base trigger address & transfer " Vikas Manocha
2015-06-17 2:14 ` [U-Boot] [PATCH RESEND 7/7] spi: cadence_qspi: get fifo width from device tree Vikas Manocha
2015-06-18 12:02 ` [U-Boot] [PATCH RESEND 0/7] spi: cadence_qspi: optimize & fix indirect rd-writes Stefan Roese
2015-06-18 18:05 ` Vikas MANOCHA
2015-06-19 6:16 ` Stefan Roese
2015-06-19 21:38 ` Vikas MANOCHA
2015-06-22 8:34 ` Stefan Roese
2015-06-22 23:31 ` Vikas MANOCHA
2015-06-23 14:36 ` Graham Moore
2015-06-23 14:51 ` Vikas MANOCHA
2015-07-02 17:50 ` Vikas MANOCHA
2015-07-06 17:56 ` Graham Moore [this message]
2015-07-06 18:19 ` Vikas MANOCHA
2015-07-01 16:24 ` Vikas MANOCHA
2015-07-09 1:29 ` Vikas MANOCHA
2015-07-13 9:00 ` Stefan Roese
2015-07-15 21:14 ` Vikas MANOCHA
2015-07-16 6:46 ` Stefan Roese
2015-07-23 12:22 ` Stefan Roese
2015-08-11 21:19 ` vikasm
2015-08-12 11:36 ` Stefan Roese
2015-08-12 12:01 ` Jagan Teki
2015-08-12 17:52 ` vikasm
2015-08-12 20:22 ` Marek Vasut
2015-08-13 0:16 ` vikasm
2015-08-13 0:26 ` Marek Vasut
2015-08-13 0:36 ` vikasm
2015-08-13 2:15 ` Marek Vasut
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559AC15B.20008@opensource.altera.com \
--to=grmoore@opensource.altera.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox