1. 23 Oct, 2018 1 commit
  2. 05 Oct, 2018 3 commits
  3. 27 Sep, 2018 1 commit
    • Laurentiu Tudor's avatar
      soc: fsl: qbman: add APIs to retrieve the probing status · 853dc104
      Laurentiu Tudor authored
      Add a couple of new APIs to check the probing status of qman and bman:
       'int bman_is_probed()' and 'int qman_is_probed()'.
      They return the following values.
       *  1 if qman/bman were probed correctly
       *  0 if qman/bman were not yet probed
       * -1 if probing of qman/bman failed
      Drivers that use qman/bman driver services are required to use these
      APIs before calling any functions exported by qman or bman drivers
      or otherwise they will crash the kernel.
      The APIs will be used in the following couple of qbman portal patches
      and later in the series in the dpaa1 ethernet driver.
      Signed-off-by: default avatarLaurentiu Tudor <laurentiu.tudor@nxp.com>
      Signed-off-by: default avatarLi Yang <leoyang.li@nxp.com>
      853dc104
  4. 21 Sep, 2018 3 commits
  5. 27 Aug, 2018 2 commits
  6. 24 Jul, 2018 1 commit
  7. 21 Jul, 2018 5 commits
    • Lina Iyer's avatar
      drivers: qcom: rpmh: add support for batch RPMH request · c8790cb6
      Lina Iyer authored
      Platform drivers need make a lot of resource state requests at the same
      time, say, at the start or end of an usecase. It can be quite
      inefficient to send each request separately. Instead they can give the
      RPMH library a batch of requests to be sent and wait on the whole
      transaction to be complete.
      
      rpmh_write_batch() is a blocking call that can be used to send multiple
      RPMH command sets. Each RPMH command set is set asynchronously and the
      API blocks until all the command sets are complete and receive their
      tx_done callbacks.
      Signed-off-by: default avatarLina Iyer <ilina@codeaurora.org>
      Signed-off-by: default avatarRaju P.L.S.S.S.N <rplsssn@codeaurora.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      c8790cb6
    • Lina Iyer's avatar
      drivers: qcom: rpmh: allow requests to be sent asynchronously · 564b5e24
      Lina Iyer authored
      Platform drivers that want to send a request but do not want to block
      until the RPMH request completes have now a new API -
      rpmh_write_async().
      
      The API allocates memory and send the requests and returns the control
      back to the platform driver. The tx_done callback from the controller is
      handled in the context of the controller's thread and frees the
      allocated memory. This API allows RPMH requests from atomic contexts as
      well.
      Signed-off-by: default avatarLina Iyer <ilina@codeaurora.org>
      Signed-off-by: default avatarRaju P.L.S.S.S.N <rplsssn@codeaurora.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      564b5e24
    • Lina Iyer's avatar
      drivers: qcom: rpmh: cache sleep/wake state requests · 600513df
      Lina Iyer authored
      Active state requests are sent immediately to the RSC controller, while
      sleep and wake state requests are cached in this driver to avoid taxing
      the RSC controller repeatedly. The cached values will be sent to the
      controller when the rpmh_flush() is called.
      
      Generally, flushing is a system PM activity and may be called from the
      system PM drivers when the system is entering suspend or deeper sleep
      modes during cpuidle.
      
      Also allow invalidating the cached requests, so they may be re-populated
      again.
      Signed-off-by: default avatarLina Iyer <ilina@codeaurora.org>
      [rplsssn: remove unneeded semicolon, address line over 80chars error]
      Signed-off-by: default avatarRaju P.L.S.S.S.N <rplsssn@codeaurora.org>
      Reviewed-by: default avatarEvan Green <evgreen@chromium.org>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      600513df
    • Lina Iyer's avatar
      drivers: qcom: rpmh: add RPMH helper functions · c1038456
      Lina Iyer authored
      Sending RPMH requests and waiting for response from the controller
      through a callback is common functionality across all platform drivers.
      To simplify drivers, add a library functions to create RPMH client and
      send resource state requests.
      
      rpmh_write() is a synchronous blocking call that can be used to send
      active state requests.
      Signed-off-by: default avatarLina Iyer <ilina@codeaurora.org>
      Signed-off-by: default avatarRaju P.L.S.S.S.N <rplsssn@codeaurora.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      c1038456
    • Lina Iyer's avatar
      drivers: qcom: rpmh-rsc: add RPMH controller for QCOM SoCs · 658628e7
      Lina Iyer authored
      Add controller driver for QCOM SoCs that have hardware based shared
      resource management. The hardware IP known as RSC (Resource State
      Coordinator) houses multiple Direct Resource Voter (DRV) for different
      execution levels. A DRV is a unique voter on the state of a shared
      resource. A Trigger Control Set (TCS) is a bunch of slots that can house
      multiple resource state requests, that when triggered will issue those
      requests through an internal bus to the Resource Power Manager Hardened
      (RPMH) blocks. These hardware blocks are capable of adjusting clocks,
      voltages, etc. The resource state request from a DRV are aggregated
      along with state requests from other processors in the SoC and the
      aggregate value is applied on the resource.
      
      Some important aspects of the RPMH communication -
      - Requests are <addr, value> with some header information
      - Multiple requests (upto 16) may be sent through a TCS, at a time
      - Requests in a TCS are sent in sequence
      - Requests may be fire-n-forget or completion (response expected)
      - Multiple TCS from the same DRV may be triggered simultaneously
      - Cannot send a request if another request for the same addr is in
        progress from the same DRV
      - When all the requests from a TCS are complete, an IRQ is raised
      - The IRQ handler needs to clear the TCS before it is available for
        reuse
      - TCS configuration is specific to a DRV
      - Platform drivers may use DRV from different RSCs to make requests
      
      Resource state requests made when CPUs are active are called 'active'
      state requests. Requests made when all the CPUs are powered down (idle
      state) are called 'sleep' state requests. They are matched by a
      corresponding 'wake' state requests which puts the resources back in to
      previously requested active state before resuming any CPU. TCSes are
      dedicated for each type of requests. Active mode TCSes (AMC) are used to
      send requests immediately to the resource, while control TCS are used to
      provide specific information to the controller. Sleep and Wake TCS send
      sleep and wake requests, after and before the system halt respectively.
      Signed-off-by: default avatarLina Iyer <ilina@codeaurora.org>
      Signed-off-by: default avatarRaju P.L.S.S.S.N <rplsssn@codeaurora.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      658628e7
  8. 22 Jun, 2018 1 commit
  9. 02 Jun, 2018 1 commit
    • Arnd Bergmann's avatar
      ARM: tegra: fix compile-testing PCI host driver · 32561354
      Arnd Bergmann authored
      The tegra_cpuidle_pcie_irqs_in_use() function is stubbed out for non-ARM
      builds, but now we can compile-test the Tegra pci driver on non-Tegra
      ARM platforms as well, which results in a new link error:
      
      drivers/pci/host/pci-tegra.o: In function `tegra_pcie_map_irq':
      pci-tegra.c:(.text+0x288): undefined reference to `tegra_cpuidle_pcie_irqs_in_use'
      drivers/pci/host/pci-tegra.o: In function `tegra_msi_map':
      pci-tegra.c:(.text+0xba0): undefined reference to `tegra_cpuidle_pcie_irqs_in_use'
      
      This adapts the #ifdef statement to match the exact condition under which
      the function can be called.
      
      Fixes: 51bc085d ("PCI: Improve host drivers compile test coverage")
      Cc: Rob Herring <robh@kernel.org>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Acked-by: Rob Herring's avatarRob Herring <robh@kernel.org>
      Acked-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: Olof Johansson's avatarOlof Johansson <olof@lixom.net>
      32561354
  10. 25 May, 2018 1 commit
  11. 30 Apr, 2018 2 commits
    • Dmitry Osipenko's avatar
      memory: tegra: Introduce memory client hot reset · 20e92462
      Dmitry Osipenko authored
      In order to reset busy HW properly, memory controller needs to be
      involved, otherwise it is possible to get corrupted memory or hang machine
      if HW was reset during DMA. Introduce memory client 'hot reset' that will
      be used for resetting of busy HW.
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      20e92462
    • Dmitry Osipenko's avatar
      memory: tegra: Squash tegra20-mc into common tegra-mc driver · a8d502fd
      Dmitry Osipenko authored
      Tegra30+ has some minor differences in registers / bits layout compared
      to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver
      in a preparation for the upcoming MC hot reset controls implementation,
      avoiding code duplication.
      
      Note that this currently doesn't report the value of MC_GART_ERROR_REQ
      because it is located within the GART register area and cannot be safely
      accessed from the MC driver (this happens to work only by accident). The
      proper solution is to integrate the GART driver with the MC driver, much
      like is done for the Tegra SMMU, but that is an invasive change and will
      be part of a separate patch series.
      Signed-off-by: default avatarDmitry Osipenko <digetx@gmail.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      a8d502fd
  12. 27 Apr, 2018 1 commit
  13. 16 Apr, 2018 1 commit
    • Geert Uytterhoeven's avatar
      soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure · 144345a4
      Geert Uytterhoeven authored
      If CONFIG_RASPBERRYPI_FIRMWARE=n:
      
          drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_polarity’:
          drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used uninitialized in this function
          drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_direction’:
          drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used uninitialized in this function
      
      The dummy firmware interface functions return 0, which means success,
      causing subsequent code to make use of the never initialized output
      parameter.
      
      Fix this by making the dummy functions return an error code (-ENOSYS)
      instead.
      
      Note that this assumes the firmware always fills in the requested data
      in the CONFIG_RASPBERRYPI_FIRMWARE=y case.
      
      Fixes: d45f1a56 ("staging: vc04_services: fix up rpi firmware functions")
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: Eric Anholt's avatarEric Anholt <eric@anholt.net>
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      144345a4
  14. 08 Mar, 2018 1 commit
    • Mikko Perttunen's avatar
      firmware: tegra: Simplify channel management · 1abb081e
      Mikko Perttunen authored
      The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
      and they are not placed contiguously in memory. The current channel
      management in the BPMP driver does not support this.
      
      Simplify and refactor the channel management such that only one atomic
      transmit channel and one receive channel are supported, and channels
      are not required to be placed contiguously in memory. The same
      configuration also works on T186 so we end up with less code.
      Signed-off-by: default avatarMikko Perttunen <mperttunen@nvidia.com>
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      1abb081e
  15. 28 Feb, 2018 2 commits
    • Eugeniy Paltsev's avatar
      ARC: mcip: update MCIP debug mask when the new cpu came online · f3205de9
      Eugeniy Paltsev authored
      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>
      f3205de9
    • Eugeniy Paltsev's avatar
      ARC: mcip: halt GFRC counter when ARC cores halt · 07423d00
      Eugeniy Paltsev authored
      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]
      07423d00
  16. 22 Feb, 2018 1 commit
  17. 15 Dec, 2017 1 commit
  18. 13 Dec, 2017 1 commit
  19. 02 Nov, 2017 1 commit
  20. 19 Oct, 2017 3 commits
  21. 17 Oct, 2017 1 commit
  22. 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
  23. 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
  24. 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
  25. 18 May, 2017 2 commits