All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read
Date: Thu, 13 Aug 2015 04:09:49 +0200	[thread overview]
Message-ID: <201508130409.49348.marex@denx.de> (raw)
In-Reply-To: <1437013654-29387-3-git-send-email-vikas.manocha@st.com>

On Thursday, July 16, 2015 at 04:27:30 AM, Vikas Manocha wrote:
> There is no need to check for sram fill level. If sram is empty, cpu will
> go in the wait state till the time data is available from flash.


Consider the following scenario:
- CPU core reads some memory area, but there are no data available just yet
  => CPU core goes into wait state
- The data never arrive

Will the CPU be stuck forever ? If we checked the fill level first instead,
we would never enter such stuck-state.

> Also Relying on SRAM fill level only for deciding when the data should be
> fetched from the local SRAM is not most efficient approach, particularly
> if we are working on high data rates.
> 
> It should be noticed that after one SRAM word is collected, the information
> is forwarded into system domain and then synchronized into register domain
> (apb). If we are using slow APB and AHB clks, SRAM fill level might not be
> up-to-dated because of latency cycles needed for synchronization. For
> example in case we are getting SRAM fill level equal to 10 locations but
> in reality there were 2 another words completed and actual level is 12 but
> information may not be synchronized yet because of the synchronization
> latency on APB domain.
> 
> Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
> ---
[...]
Best regards,
Marek Vasut

  reply	other threads:[~2015-08-13  2:09 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-16  2:27 [U-Boot] [v2 0/6] spi: cadence_qspi: optimize & fix indirect rd-writes Vikas Manocha
2015-07-16  2:27 ` [U-Boot] [v2 1/6] spi: cadence_qspi: move trigger base configuration in init Vikas Manocha
2015-08-13  2:07   ` Marek Vasut
2015-08-13 15:50     ` vikasm
2015-08-13 17:35       ` Marek Vasut
2015-08-13 19:05         ` vikasm
2015-08-14  1:24         ` vikas
2015-08-14  1:43           ` Marek Vasut
2015-08-14  1:44             ` vikas
2015-08-14  1:55               ` Marek Vasut
2015-07-16  2:27 ` [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read Vikas Manocha
2015-08-13  2:09   ` Marek Vasut [this message]
2015-08-13 16:27     ` vikasm
2015-08-13 17:33       ` Marek Vasut
2015-08-13 19:49         ` vikas
2015-08-13 20:35           ` Marek Vasut
2015-08-13 21:04             ` vikas
2015-08-13 22:47               ` Marek Vasut
2015-08-13 23:18                 ` vikas
2015-08-13 23:46                   ` Marek Vasut
2015-08-14  0:26                     ` vikas
2015-08-14  0:44                       ` Marek Vasut
2015-08-14  0:46                         ` vikas
2015-08-14  1:03                           ` Marek Vasut
2015-08-14  1:05                             ` vikas
2015-08-14  3:54                               ` Marek Vasut
2015-07-16  2:27 ` [U-Boot] [v2 3/6] spi: cadence_qspi: remove sram polling from flash write Vikas Manocha
2015-08-13  2:11   ` Marek Vasut
2015-08-13 16:30     ` vikasm
2015-08-13 17:34       ` Marek Vasut
2015-07-16  2:27 ` [U-Boot] [v2 4/6] spi: cadence_qspi: fix indirect read/write start address Vikas Manocha
2015-07-16  2:27 ` [U-Boot] [v2 5/6] spi: cadence_qspi: fix base trigger address & transfer " Vikas Manocha
2015-08-13  2:15   ` Marek Vasut
2015-08-13 16:42     ` vikasm
2015-08-13 21:36       ` vikas
2015-08-13 22:48         ` Marek Vasut
2015-08-14  0:37           ` vikas
2015-08-14  1:04             ` Marek Vasut
2015-08-14  1:39               ` vikas
2015-08-14  1:56                 ` Marek Vasut
2015-08-14  2:14                   ` Vikas MANOCHA
2015-07-16  2:27 ` [U-Boot] [v2 6/6] spi: cadence_qspi: get fifo width from device tree Vikas Manocha

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=201508130409.49348.marex@denx.de \
    --to=marex@denx.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.