1. 22 Jun, 2019 1 commit
  2. 17 Jun, 2019 1 commit
  3. 13 Jun, 2019 1 commit
  4. 11 Apr, 2019 1 commit
  5. 02 Apr, 2019 2 commits
  6. 04 Mar, 2019 1 commit
  7. 20 Feb, 2019 1 commit
    • Marek Vasut's avatar
      rcar_gen3: plat: Prevent PCIe hang during L1X config access · 0969397f
      Marek Vasut authored
      
      
      In case the PCIe controller receives a L1_Enter_PM DLLP, it will
      disable the internal PLLs. The system software cannot predict it
      and can attempt to perform device config space access across the
      PCIe link while the controller is in this transitional state. If
      such condition happens, the PCIe controller register access will
      trigger ARM64 SError exception.
      
      This patch adds checks for which PCIe controller is enabled,
      checks whether the PCIe controller is in such a transitional
      state and if so, first completes the transition and then restarts
      the instruction which caused the SError.
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@gmail.com>
      0969397f
  8. 01 Feb, 2019 1 commit
  9. 29 Jan, 2019 1 commit
  10. 08 Jan, 2019 6 commits
  11. 06 Dec, 2018 1 commit
  12. 20 Nov, 2018 1 commit
  13. 17 Oct, 2018 2 commits
    • Jorge Ramirez-Ortiz's avatar
      rcar_gen3: drivers: staging · 6ac2892a
      Jorge Ramirez-Ortiz authored
       - ddr
       - pfc [pin function controller]
       - qos [bandwidth]
      
      checkpatch.pl is generating too many errors.
      6ac2892a
    • Jorge Ramirez-Ortiz's avatar
      rcar-gen3: initial commit for the rcar-gen3 boards · 7e532c4b
      Jorge Ramirez-Ortiz authored
      Reference code:
      ==============
      
      rar_gen3: IPL and Secure Monitor Rev1.0.22
      https://github.com/renesas-rcar/arm-trusted-firmware [rcar_gen3]
      
      Author: Takuya Sakata <takuya.sakata.wz@bp.renesas.com>
      Date:   Thu Aug 30 21:26:41 2018 +0900
      	Update IPL and Secure Monitor Rev1.0.22
      
      General Information:
      ===================
      
      This port has been tested on the Salvator-X Soc_id r8a7795 revision
      ES1.1 (uses an SPD).
      
      Build Tested:
      -------------
      ATFW_OPT="LSI=H3 RCAR_DRAM_SPLIT=1 RCAR_LOSSY_ENABLE=1"
      MBEDTLS_DIR=$mbedtls
      
      $ make clean bl2 bl31 rcar PLAT=rcar ${ATFW_OPT} SPD=opteed
      
      Other dependencies:
      ------------------
      * mbed_tls:
        git@github.com:ARMmbed/mbedtls.git [devel]
      
        Merge: 68dbc94 f34a4c1
        Author: Simon Butcher <simon.butcher@arm.com>
        Date:   Thu Aug 30 00:57:28 2018 +0100
      
      * optee_os:
        https://github.com/BayLibre/optee_os
      
      
      
        Until it gets merged into OP-TEE, the port requires Renesas' Trusted
        Environment with a modification to support power management.
      
        Author: Jorge Ramirez-Ortiz <jramirez@baylibre.com>
        Date:   Thu Aug 30 16:49:49 2018 +0200
          plat-rcar: cpu-suspend: handle the power level
      Signed-off-by: default avatarJorge Ramirez-Ortiz <jramirez@baylibre.com>
      
      * u-boot:
        The port has beent tested using mainline uboot.
      
        Author: Fabio Estevam <festevam@gmail.com>
        Date:   Tue Sep 4 10:23:12 2018 -0300
      
      *linux:
        The port has beent tested using mainline kernel.
      
        Author: Linus Torvalds <torvalds@linux-foundation.org>
        Date:   Sun Sep 16 11:52:37 2018 -0700
            Linux 4.19-rc4
      
      Overview
      ---------
      
      BOOTROM starts the cpu at EL3; In this port BL2 will therefore be entered
      at this exception level (the Renesas' ATF reference tree [1] resets into
      EL1 before entering BL2 - see its bl2.ld.S)
      
      BL2 initializes DDR (and i2c to talk to the PMIC on some platforms)
      before determining the boot reason (cold or warm).
      
      During suspend all CPUs are switched off and the DDR is put in
      backup mode (some kind of self-refresh mode). This means that BL2 is
      always entered in a cold boot scenario.
      
      Once BL2 boots, it determines the boot reason, writes it to shared
      memory (BOOT_KIND_BASE) together with the BL31 parameters
      (PARAMS_BASE) and jumps to BL31.
      
      To all effects, BL31 is as if it is being entered in reset mode since
      it still needs to initialize the rest of the cores; this is the reason
      behind using direct shared memory access to  BOOT_KIND_BASE and
      PARAMS_BASE instead of using registers to get to those locations (see
      el3_common_macros.S and bl31_entrypoint.S for the RESET_TO_BL31 use
      case).
      
      Depending on the boot reason BL31 initializes the rest of the cores:
      in case of suspend, it uses a MBOX memory region to recover the
      program counters.
      
      [1] https://github.com/renesas-rcar/arm-trusted-firmware
      
      
      Tests
      -----
      
      * cpuidle
        -------
         enable kernel's cpuidle arm_idle driver and boot
      
      * system suspend
        --------------
        $ cat suspend.sh
          #!/bin/bash
          i2cset -f -y 7 0x30 0x20 0x0F
          read -p "Switch off SW23 and press return " foo
          echo mem > /sys/power/state
      
      * cpu hotplug:
        ------------
        $ cat offline.sh
          #!/bin/bash
          nbr=$1
          echo 0 > /sys/devices/system/cpu/cpu$nbr/online
          printf "ONLINE:  " && cat /sys/devices/system/cpu/online
          printf "OFFLINE: " && cat /sys/devices/system/cpu/offline
      
        $ cat online.sh
          #!/bin/bash
          nbr=$1
          echo 1 > /sys/devices/system/cpu/cpu$nbr/online
          printf "ONLINE:  " && cat /sys/devices/system/cpu/online
          printf "OFFLINE: " && cat /sys/devices/system/cpu/offline
      Signed-off-by: default avatarldts <jramirez@baylibre.com>
      7e532c4b