1. 26 Jul, 2017 1 commit
    • David Cunado's avatar
      Address edge case for stale PSCI CPU data in cache · 71341d23
      David Cunado authored
      
      
      There is a theoretical edge case during CPU_ON where the cache
      may contain stale data for the target CPU data - this can occur
      under the following conditions:
      
      - the target CPU is in another cluster from the current
      - the target CPU was the last CPU to shutdown on its cluster
      - the cluster was removed from coherency as part of the CPU shutdown
      
      In this case the cache maintenace that was performed as part of the
      target CPUs shutdown was not seen by the current CPU's cluster. And
      so the cache may contain stale data for the target CPU.
      
      This patch adds a cache maintenance operation (flush) for the
      cache-line containing the target CPU data - this ensures that the
      target CPU data is read from main memory.
      
      Change-Id: If8cfd42639b03174f60669429b7f7a757027d0fb
      Signed-off-by: default avatarDavid Cunado <david.cunado@arm.com>
      71341d23
  2. 20 Jul, 2017 1 commit
  3. 14 Jul, 2017 6 commits
  4. 12 Jul, 2017 8 commits
  5. 11 Jul, 2017 1 commit
  6. 10 Jul, 2017 4 commits
  7. 07 Jul, 2017 3 commits
  8. 06 Jul, 2017 7 commits
  9. 05 Jul, 2017 4 commits
  10. 02 Jul, 2017 1 commit
  11. 30 Jun, 2017 1 commit
    • Caesar Wang's avatar
      rockchip/rk3399: fixes the typo and the WARNINGS during suspend/resume · c3710ee7
      Caesar Wang authored
      
      
      This patch fixes the two things as follows:
      
      1) rk3399_flash_l2_b" seems to be a typo. That's "flush", not "flash".
      
      2) fixes the warnings log.
      We always hit the warnings thing during the suspend, as below log:
      ..
      [   51.022334] CPU5: shutdown
      [   51.025069] psci: CPU5 killed.
      INFO:    sdram_params->ddr_freq = 928000000
      WARNING: rk3399_flash_l2_b:reg 28830380,wait
      
      When the L2 completes the clean and invalidate sequence, it asserts the
      L2FLUSHDONE signal. The SoC can now deassert L2FLUSHREQ signal and then
      the L2 deasserts L2FLUSHDONE.
      
      Then, a loop without a delay isn't really great to measure time. We should
      probably add a udelay(10) or so in there and then maybe replace the WARN()
      after the loop. In the actual tests, the L2 cache will take ~4ms by
      default for big cluster.
      
      In the real world that give 10ms for the enough margin, like the
      ddr/cpu/cci frequency and other factors that will affect it.
      
      Change-Id: I55788c897be232bf72e8c7b0e10cf9b06f7aa50d
      Signed-off-by: default avatarCaesar Wang <wxt@rock-chips.com>
      c3710ee7
  12. 29 Jun, 2017 3 commits