1. 01 Jun, 2015 1 commit
  2. 29 May, 2015 9 commits
  3. 28 May, 2015 5 commits
    • jilai wang's avatar
      firmware: qcom: scm: Add HDCP Support · 9626b699
      jilai wang authored
      HDCP driver needs to check if secure environment supports HDCP.  If it's
      supported, then it requires to program some registers through SCM.
      Add qcom_scm_hdcp_available and qcom_scm_hdcp_req to support these
      requirements.
      Signed-off-by: default avatarJilai Wang <jilaiw@codeaurora.org>
      Signed-off-by: default avatarKumar Gala <galak@codeaurora.org>
      9626b699
    • Thomas Petazzoni's avatar
      bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap() · bfa1ce5f
      Thomas Petazzoni authored
      This commit introduces a variant of the mv_mbus_dram_info() function
      called mv_mbus_dram_info_nooverlap(). Both functions are used by
      Marvell drivers supporting devices doing DMA, and provide them a
      description the DRAM ranges that they need to configure their DRAM
      windows.
      
      The ranges provided by the mv_mbus_dram_info() function may overlap
      with the I/O windows if there is a lot (>= 4 GB) of RAM
      installed. This is not a problem for most of the DMA masters, except
      for the upcoming new CESA crypto driver because it does DMA to the
      SRAM, which is mapped through an I/O window. For this unit, we need to
      have DRAM ranges that do not overlap with the I/O windows.
      
      A first implementation done in commit 1737cac6 ("bus: mvebu-mbus:
      make sure SDRAM CS for DMA don't overlap the MBus bridge window"),
      changed the information returned by mv_mbus_dram_info() to match this
      requirement. However, it broke the requirement of the other DMA
      masters than the DRAM ranges should have power of two sizes.
      
      To solve this situation, this commit introduces a new
      mv_mbus_dram_info_nooverlap() function, which returns the same
      information as mv_mbus_dram_info(), but guaranteed to not overlap with
      the I/O windows.
      
      In the end, it gives us two variants of the mv_mbus_dram_info*()
      functions:
      
       - The normal one, mv_mbus_dram_info(), which has been around for many
         years. This function returns the raw DRAM ranges, which are
         guaranteed to use power of two sizes, but will overlap with I/O
         windows. This function will therefore be used by all DMA masters
         (SATA, XOR, Ethernet, etc.) except the CESA crypto driver.
      
       - The new 'nooverlap' variant, mv_mbus_dram_info_nooverlap(). This
         function returns DRAM ranges after they have been "tweaked" to make
         sure they don't overlap with I/O windows. By doing this tweaking,
         we remove the power of two size guarantee. This variant will be
         used by the new CESA crypto driver.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      bfa1ce5f
    • Thomas Petazzoni's avatar
      Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window" · 885dbd15
      Thomas Petazzoni authored
      This reverts commit 1737cac6 ("bus: mvebu-mbus: make sure SDRAM CS
      for DMA don't overlap the MBus bridge window"), because it breaks DMA
      on platforms having more than 2 GB of RAM.
      
      This commit changed the information reported to DMA masters device
      drivers through the mv_mbus_dram_info() function so that the returned
      DRAM ranges do not overlap with I/O windows.
      
      This was necessary as a preparation to support the new CESA Crypto
      Engine driver, which will use DMA for cryptographic operations. But
      since it does DMA with the SRAM which is mapped as an I/O window,
      having DRAM ranges overlapping with I/O windows was problematic.
      
      To solve this, the above mentioned commit changed the mvebu-mbus to
      adjust the DRAM ranges so that they don't overlap with the I/O
      windows. However, by doing this, we re-adjust the DRAM ranges in a way
      that makes them have a size that is no longer a power of two. While
      this is perfectly fine for the Crypto Engine, which supports DRAM
      ranges with a granularity of 64 KB, it breaks basically all other DMA
      masters, which expect power of two sizes for the DRAM ranges.
      
      Due to this, if the installed system memory is 4 GB, in two
      chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB
      to a little bit less than 2 GB to not overlap with the I/O windows, in
      a way that results in a DRAM range that doesn't have a power of two
      size. This means that whenever you do a DMA transfer with an address
      located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any
      serious DMA activity like simply running:
      
        for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done
      
      in an ext3 partition mounted over a SATA drive will freeze the system.
      
      Since the new CESA crypto driver that uses DMA has not been merged
      yet, the easiest fix is to simply revert this commit. A follow-up
      commit will introduce a different solution for the CESA crypto driver.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Fixes: 1737cac6 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window")
      Cc: <stable@vger.kernel.org> # v4.0+
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      885dbd15
    • Nicolas Schichan's avatar
      bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms. · 8c9e06e6
      Nicolas Schichan authored
      Commit a0b5cd4a ("bus: mvebu-mbus: use automatic I/O
      synchronization barriers") enabled the usage of automatic I/O
      synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the
      control registers of MBus windows, but on non io-coherent platforms
      (orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in
      the window control register is either reserved (all windows except 6
      and 7) or enables read-only protection (windows 6 and 7).
      Signed-off-by: default avatarNicolas Schichan <nschichan@freebox.fr>
      Reviewed-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: <stable@vger.kernel.org> # v4.0+
      Fixes: a0b5cd4a ("bus: mvebu-mbus: use automatic I/O synchronization barriers")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      8c9e06e6
    • Imre Kaloz's avatar
      ARM: mvebu: armada-xp-linksys-mamba: Disable internal RTC · 2ff9ab4c
      Imre Kaloz authored
      The Mamba (like the OpenBlocks AX3) doesn't have a crystal
      connected to the internal RTC - let's prevent the kernel from
      probing it.
      Signed-off-by: default avatarImre Kaloz <kaloz@openwrt.org>
      Cc: <stable@vger.kernel.org> # v4.0 +
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      2ff9ab4c
  4. 27 May, 2015 3 commits
    • Matthias Brugger's avatar
      soc: mediatek: Add compile dependency to pmic-wrapper · 2a910d13
      Matthias Brugger authored
      The pmic-wrapper calls the reset controller. If CONFIG_RESET_CONTROLLER
      is not set, compilation fails with:
      drivers/soc/mediatek/mtk-pmic-wrap.c: In function ‘pwrap_probe’:
      drivers/soc/mediatek/mtk-pmic-wrap.c:836:2: error: implicit declaration of function ‘devm_reset_control_get’ [-Werror=implicit-function-declaration]
      
      This patch sets the dependency in the Kconfig file.
      Signed-off-by: default avatarMatthias Brugger <matthias.bgg@gmail.com>
      2a910d13
    • Sascha Hauer's avatar
      soc: mediatek: PMIC wrap: Fix register state machine handling · d956b80a
      Sascha Hauer authored
      When the PMIC wrapper state machine has read a register it goes into the
      "wait for valid clear" (vldclr) state. The state machine stays in this
      state until the VLDCLR bit is written to. We should write this bit after
      reading a register because the SCPSYS won't let the system go into
      suspend as long as the state machine waits for valid clear.
      
      Since now we never leave the state machine in vldclr state we no longer
      have to check for this state on pwrap_read/pwrap_write entry and can
      remove the corresponding code.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMatthias Brugger <matthias.bgg@gmail.com>
      d956b80a
    • Sascha Hauer's avatar
      soc: mediatek: PMIC wrap: Fix clock rate handling · d71c11f3
      Sascha Hauer authored
      replace chipselect extension values based on SPI clock with hardcoded SoC
      specific values.
      
      The PMIC wrapper has the ability of extending the chipselects by configurable
      amounts of time. We configured the values based on the rate of SPI clock, but
      this is wrong. The delays should be configured based on the internal PMIC clock
      that latches the values from the SPI bus to the internal PMIC registers. By
      default this clock is 24MHz. Other clock frequencies are for debugging only
      and can be removed from the driver.
      Signed-off-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: default avatarMatthias Brugger <matthias.bgg@gmail.com>
      d71c11f3
  5. 20 May, 2015 1 commit
    • Arnd Bergmann's avatar
      Merge tag 'berlin-simple-mfd-4.2-1' of... · 0fcbffc4
      Arnd Bergmann authored
      Merge tag 'berlin-simple-mfd-4.2-1' of git://git.infradead.org/users/hesselba/linux-berlin into next/drivers
      
      Merge "Berlin simple-mfd for v4.2" from Sebastian Hesselbarth:
      - based on arm-soc drivers/simple-mfd branch
      - rework of chip/system ctrl nodes to simple-mfd probing for
        clk, pinctrl, and reset
      - add adc node
      
      * tag 'berlin-simple-mfd-4.2-1' of git://git.infradead.org/users/hesselba/linux-berlin:
        ARM: berlin: add an ADC node for the BG2Q
        ARM: berlin: remove useless chip and system ctrl compatibles
        clk: berlin: drop direct of_iomap of nodes reg property
        ARM: berlin: move BG2Q clock node
        ARM: berlin: move BG2CD clock node
        ARM: berlin: move BG2 clock node
        clk: berlin: prepare simple-mfd conversion
        pinctrl: berlin: drop SoC stub provided regmap
        ARM: berlin: move pinctrl to simple-mfd nodes
        pinctrl: berlin: prepare to use regmap provided by syscon
        reset: berlin: drop arch_initcall initialization
        ARM: berlin: move reset to simple-mfd nodes
        reset: berlin: convert to a platform driver
        ARM: berlin: prepare simple-mfd/syscon conversion of sys/chip ctrl nodes
        ARM: berlin: select MFD_SYSCON by default
      0fcbffc4
  6. 18 May, 2015 15 commits
  7. 15 May, 2015 1 commit
  8. 13 May, 2015 4 commits
  9. 12 May, 2015 1 commit