1. 03 Aug, 2018 1 commit
  2. 20 Jun, 2018 1 commit
  3. 30 May, 2018 2 commits
    • Eugeniy Paltsev's avatar
      ARC: mcip: update MCIP debug mask when the new cpu came online · f7f78191
      Eugeniy Paltsev authored
      [ Upstream commit f3205de9 ]
      
      As of today we use hardcoded MCIP debug mask, so if we launch
      kernel via debugger and kick fever cores than HW has all cpus
      hang at the momemt of setup MCIP debug mask.
      
      So update MCIP debug mask when the new cpu came online, instead of
      use hardcoded MCIP debug mask.
      Signed-off-by: default avatarEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f7f78191
    • Eugeniy Paltsev's avatar
      ARC: mcip: halt GFRC counter when ARC cores halt · 50de7f43
      Eugeniy Paltsev authored
      [ Upstream commit 07423d00 ]
      
      In SMP systems, GFRC is used for clocksource. However by default the
      counter keeps running even when core is halted (say when debugging via a
      JTAG debugger). This confuses Linux timekeeping and triggers flase RCU stall
      splat such as below:
      
      | [ARCLinux]# while true; do ./shm_open_23-1.run-test ; done
      | Running with 1000 processes for 1000 objects
      | hrtimer: interrupt took 485060 ns
      |
      | create_cnt: 1000
      | Running with 1000 processes for 1000 objects
      | [ARCLinux]# INFO: rcu_preempt self-detected stall on CPU
      |       2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0
      | INFO: rcu_preempt detected stalls on CPUs/tasks:
      | 	0-...: (1 GPs behind) idle=71e/0/0 softirq=135264/135264 fqs=0
      |	2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0
      |	3-...: (1 GPs behind) idle=4e0/0/0 softirq=134304/134304 fqs=0
      |	(detected by 1, t=13648 jiffies, g=31493, c=31492, q=1)
      
      Starting from ARC HS v3.0 it's possible to tie GFRC to state of up-to 4
      ARC cores with help of GFRC's CORE register where we set a mask for
      cores which state we need to rely on.
      
      We update cpu mask every time new cpu came online instead of using
      hardcoded one or using mask generated from "possible_cpus" as we
      want it set correctly even if we run kernel on HW which has fewer cores
      than expected (or we launch kernel via debugger and kick fever cores
      than HW has)
      
      Note that GFRC halts when all cores have halted and thus relies on
      programming of Inter-Core-dEbug register to halt all cores when one
      halts.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: default avatarEugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      [vgupta: rewrote changelog]
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      50de7f43
  4. 22 Aug, 2017 1 commit
    • Yong Wu's avatar
      iommu/mediatek: Add mt2712 IOMMU support · e6dec923
      Yong Wu authored
      The M4U IP blocks in mt2712 is MTK's generation2 M4U which use the
      ARM Short-descriptor like mt8173, and most of the HW registers are
      the same.
      
      The difference is that there are 2 M4U HWs in mt2712 while there's
      only one in mt8173. The purpose of 2 M4U HWs is for balance the
      bandwidth.
      
      Normally if there are 2 M4U HWs, there should be 2 iommu domains,
      each M4U has a iommu domain.
      Signed-off-by: default avatarYong Wu <yong.wu@mediatek.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      e6dec923
  5. 17 Aug, 2017 1 commit
    • Thierry Reding's avatar
      soc/tegra: Register SoC device · 27a0342a
      Thierry Reding authored
      Move this code from arch/arm/mach-tegra and make it common among 32-bit
      and 64-bit Tegra SoCs. This is slightly complicated by the fact that on
      32-bit Tegra, the SoC device is used as the parent for all devices that
      are instantiated from device tree.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      27a0342a
  6. 13 Jun, 2017 2 commits
    • Thierry Reding's avatar
      soc/tegra: bpmp: Implement generic PM domains · e7149a7a
      Thierry Reding authored
      The BPMP firmware, found on Tegra186 and later, provides an ABI that can
      be used to enable and disable power to several power partitions in Tegra
      SoCs. The ABI allows for enumeration of the available power partitions,
      so the driver can be reused on future generations, provided the BPMP ABI
      remains stable.
      
      Based on work by Stefan Kristiansson <stefank@nvidia.com> and Mikko
      Perttunen <mperttunen@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Reviewed-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      e7149a7a
    • Thierry Reding's avatar
      soc/tegra: bpmp: Update ABI header · 52b8b803
      Thierry Reding authored
      Update the BPMP ABI header to a more recent version. The new version
      adds support for a new powergating ABI as well as access to the ring
      buffer console, which allows debug messages to be output to the BPMP
      debug console.
      
      Some of the previously undocumented fields have been documented and
      missing bitmasks have been added. Furthermore the MRQ_RESET request
      now has a sub-command that allows to determine the maximum ID which
      in turn allows the resets to be enumerated, thereby allowing drivers
      to become agnostic of the Tegra generation.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      52b8b803
  7. 18 May, 2017 2 commits
  8. 30 Apr, 2017 2 commits
  9. 04 Apr, 2017 2 commits
    • Jon Hunter's avatar
      soc/tegra: Move Tegra flowctrl driver · 7e10cf74
      Jon Hunter authored
      The flowctrl driver is required for both ARM and ARM64 Tegra devices
      and in order to enable support for it for ARM64, move the Tegra flowctrl
      driver into drivers/soc/tegra.
      
      By moving the flowctrl driver, tegra_flowctrl_init() is now called by
      via an early initcall and to prevent this function from attempting to
      mapping IO space for a non-Tegra device, a test for 'soc_is_tegra()'
      is also added.
      Signed-off-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      7e10cf74
    • Arnd Bergmann's avatar
      soc/tegra: Fix link errors with PMC disabled · bd737038
      Arnd Bergmann authored
      With the new Tegra186 PMC driver merged, anything that relies on the previous
      PMC driver fails to link when that is disabled:
      
      arch/arm/mach-tegra/pm.o: In function `tegra_pm_set':
      pm.c:(.text.tegra_pm_set+0x3c): undefined reference to `tegra_pmc_enter_suspend_mode'
      arch/arm/mach-tegra/pm.o: In function `tegra_suspend_enter':
      pm.c:(.text.tegra_suspend_enter+0x4): undefined reference to `tegra_pmc_get_suspend_mode'
      arch/arm/mach-tegra/pm.o: In function `tegra_init_suspend':
      pm.c:(.init.text+0x1c): undefined reference to `tegra_pmc_get_suspend_mode'
      pm.c:(.init.text+0x74): undefined reference to `tegra_pmc_set_suspend_mode'
      
      ERROR: tegra_powergate_sequence_power_up [drivers/ata/ahci_tegra.ko] undefined!
      ERROR: tegra_powergate_power_off [drivers/ata/ahci_tegra.ko] undefined!
      
      Making the definition depend on the presence of the driver makes it build
      again, though that might not be the correct fix.
      Reported-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Fixes: 854014236290 ("soc/tegra: Implement Tegra186 PMC support")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      bd737038
  10. 24 Mar, 2017 4 commits
  11. 06 Feb, 2017 1 commit
    • Yuriy Kolerov's avatar
      ARCv2: IDU-intc: Use build registers for getting numbers of interrupts · 6f0310a1
      Yuriy Kolerov authored
      This enhancement is needed to allow masking all available common interrupts
      in IDU interrupt controller in boot time since the kernel can
      discover a number of them from the build register. Also now there
      is no need to specify in device tree a list of used core interrupts
      by IDU. E.g. before:
      
          idu_intc: idu-interrupt-controller {
              compatible = "snps,archs-idu-intc";
              interrupt-controller;
              interrupt-parent = <&core_intc>;
              #interrupt-cells = <2>;
              interrupts = <24 25 26 27 28 29 30 31>;
          };
      
      and after:
      
          idu_intc: idu-interrupt-controller {
              compatible = "snps,archs-idu-intc";
              interrupt-controller;
              interrupt-parent = <&core_intc>;
              #interrupt-cells = <2>;
          };
      Signed-off-by: default avatarYuriy Kolerov <yuriy.kolerov@synopsys.com>
      Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
      6f0310a1
  12. 24 Jan, 2017 1 commit
  13. 16 Jan, 2017 1 commit
  14. 30 Nov, 2016 4 commits
  15. 24 Nov, 2016 1 commit
  16. 23 Nov, 2016 5 commits
  17. 18 Nov, 2016 2 commits
    • Thierry Reding's avatar
      firmware: tegra: Add BPMP support · 983de5f9
      Thierry Reding authored
      The Boot and Power Management Processor (BPMP) is a co-processor found
      on Tegra SoCs. It is designed to handle the early stages of the boot
      process and offload power management tasks (such as clocks, resets,
      powergates, ...) as well as system control services.
      
      Compared to the ARM SCPI, the services provided by BPMP are message-
      based rather than method-based. The BPMP firmware driver provides the
      services to transmit data to and receive data from the BPMP. Users can
      also register a Message ReQuest (MRQ), for which a service routine will
      be run when a corresponding event is received from the firmware.
      
      A set of messages, called the BPMP ABI, are specified for a number of
      different services provided by the BPMP (such as clocks or resets).
      
      Based on work by Sivaram Nair <sivaramn@nvidia.com> and Joseph Lo
      <josephl@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      983de5f9
    • Thierry Reding's avatar
      firmware: tegra: Add IVC library · ca791d7f
      Thierry Reding authored
      The Inter-VM communication (IVC) is a communication protocol which is
      designed for interprocessor communication (IPC) or the communication
      between the hypervisor and the virtual machine with a guest OS.
      
      Message channels are used to communicate between processors. They are
      backed by DRAM or SRAM, so care must be taken to maintain coherence of
      data.
      
      The IVC library maintains memory-based descriptors for the transmission
      and reception channels as well as the data coherence of the counter and
      payload. Clients, such as the driver for the BPMP firmware, can use the
      library to exchange messages with remote processors.
      
      Based on work by Peter Newman <pnewman@nvidia.com> and Joseph Lo
      <josephl@nvidia.com>.
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      ca791d7f
  18. 15 Nov, 2016 1 commit
    • Laxman Dewangan's avatar
      soc/tegra: pmc: Add I/O pad voltage support · 21b49910
      Laxman Dewangan authored
      I/O pins on Tegra SoCs are grouped into so-called I/O pads. Each such
      pad can be used to control the common voltage signal level and power
      state of the pins in the given pad.
      
      I/O pads can be powered down even if the system is active, which can
      save power from that I/O interface. For SoC generations prior to
      Tegra124 the I/O pad voltage is automatically detected and hence the
      system software doesn't need to configure it. However, starting with
      Tegra210 the detection logic has been removed, so explicit control of
      the I/O pad voltage by system software is required.
      Signed-off-by: default avatarLaxman Dewangan <ldewangan@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      21b49910
  19. 07 Nov, 2016 1 commit
  20. 16 Oct, 2016 2 commits
  21. 25 Sep, 2016 2 commits
  22. 31 Aug, 2016 1 commit