Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 1月, 2015 5 次提交
    • O
      Merge tag 'tegra-for-3.20-soc' of... · 82483ad6
      由 Olof Johansson 提交于 
      Merge tag 'tegra-for-3.20-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/soc

Merge "ARM: tegra: Core code changes for v3.20" from Thierry Reding:

This contains a couple of preparatory patches for 64-bit support. A new
feature is implemented in the power-management controller which allows
it to switch off the SoC if it overheats.

* tag 'tegra-for-3.20-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  soc: tegra: Add thermal reset (thermtrip) support to PMC
  ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device tree
  of: Add descriptions of thermtrip properties to Tegra PMC bindings
  soc/tegra: pmc: Add Tegra132 support
  soc/tegra: fuse: Add Tegra132 support
  soc/tegra: fuse: Constify tegra_fuse_info structures
  soc/tegra: Add Tegra132 support
  clocksource: Build Tegra timer on 32-bit ARM only
  soc/tegra: pmc: restrict compilation of suspend-related support to ARM
Signed-off-by: NOlof Johansson <olof@lixom.net>
      82483ad6
    • O
      Merge tag 'imx-soc-3.20' of... · 085dd64e
      由 Olof Johansson 提交于 
      Merge tag 'imx-soc-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/soc

Merge "ARM: imx: soc changes for 3.20" from Shawn Guo:

The i.MX SoC changes for 3.20:
 - Add .disable_unused function hook for shared gate clock to ensure
   the clock tree use count matches the hardware state
 - Add a deeper idle state for i.MX6SX cpuidle driver powering off the
   ARM core
 - One correction on i.MX6Q esai_ipg parent clock setting
 - Add a missing iounmap call for imx6q_opp_check_speed_grading()
 - Add missing clocks for VF610 UART4, UART5 and SNVS blocks
 - Expand VF610 device tree compatible matching table to cover more
   Vybrid family SoCs
 - Expand i.MX clk-pllv3 a bit with the shift for frequency multiplier
   to support Vybrid's USB PLL oddity

* tag 'imx-soc-3.20' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: clk-imx6q: refine esai_ipg's parent
  ARM i.MX6q: unmap memory mapped at imx6q_opp_check_speed_grading()
  ARM: imx: clk-vf610: Add clock for SNVS
  ARM: imx: clk-vf610: Add clock for UART4 and UART5
  ARM: imx: drop CPUIDLE_FLAG_TIME_VALID from cpuidle-imx6sx
  ARM: imx: support arm power off in cpuidle for i.mx6sx
  ARM: imx: remove unnecessary setting for DSM
  ARM: imx: correct the hardware clock gate setting for shared nodes
  ARM: imx: pllv3: add shift for frequency multiplier
  ARM vf610: add compatibilty strings of supported Vybrid SoC's
Signed-off-by: NOlof Johansson <olof@lixom.net>
      085dd64e
    • O
      Merge tag 'v3.20-next-soc1' of https://github.com/mbgg/linux-mediatek into next/soc · eeec0434
      由 Olof Johansson 提交于 
      Merge "ARM: mediatek: soc changes for v3.20" from Matthias Brugger:

This adds config options for the different Mediatek SoC. We need this so that
the pinctrl driver does not bloat the kernel binary.

Apart we change the Kconfig description and add the config option for mt6592
low-level debug option.

* tag 'v3.20-next-soc1' of https://github.com/mbgg/linux-mediatek:
  ARM: mediatek: Low-level-debug for mt6592
  ARM: mediatek: Add config options for mediatek SoCs.
Signed-off-by: NOlof Johansson <olof@lixom.net>
      eeec0434
    • O
      Merge tag 'mvebu-soc-3.20-2' of git://git.infradead.org/linux-mvebu into next/soc · 8a333cc7
      由 Olof Johansson 提交于 
      Merge "mvebu/soc #2" from Andrew Lunn:

Soc patches for mvebu for v3.20, part #2.

* tag 'mvebu-soc-3.20-2' of git://git.infradead.org/linux-mvebu:
  bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window
  bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x
  ARM: mvebu: use arm_coherent_dma_ops and re-enable hardware I/O coherency
  bus: mvebu-mbus: use automatic I/O synchronization barriers
  bus: mvebu-mbus: fix support of MBus window 13
  ARM: mvebu: completely disable hardware I/O coherency
Signed-off-by: NOlof Johansson <olof@lixom.net>
      8a333cc7
    • O
      Merge tag 'v3.20-rockchip-soc1' of... · 0dcfd9e3
      由 Olof Johansson 提交于 
      Merge tag 'v3.20-rockchip-soc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into next/soc

Merge "ARM: rockchip: soc updates for v3.20" from Heiko Stübner:

SoC parts of basic suspend support and removal of
Cortex-A9 reference from the machine name.

* tag 'v3.20-rockchip-soc1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  ARM: rockchip: remove cpu-core name from machine name
  ARM: rockchip: Add pmu-sram binding
  ARM: rockchip: add suspend and resume for RK3288
Signed-off-by: NOlof Johansson <olof@lixom.net>
      0dcfd9e3
  3. 23 1月, 2015 3 次提交
  5. 22 1月, 2015 12 次提交
  7. 21 1月, 2015 2 次提交
  9. 20 1月, 2015 14 次提交
    • Z
      ARM: sirf: add Atlas7 machine support · 4cba0585
      由 Zhiwu Song 提交于 
      CSRatlas7 is next-gen auto SoC from CSR.
It could bring to customers most integrated SoC solution:
- World leading Bluetooth 4.0 and GNSS baseband
- Audio processing, analog CODEC and ADC by DSP
- Analog video input
- SDR accelerators
- CAN bus support by Cortex-M3
Signed-off-by: NZhiwu Song <Zhiwu.Song@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      4cba0585
    • B
      ARM: sirf: move to debug_ll_io_init and drop map_io · 1805f4d6
      由 Barry Song 提交于 
      This patch moves to debug_ll_io_init(), then finally drops CSR map_io()
machine callbacks.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      1805f4d6
    • Z
      ARM: sirf: move platsmp to support Atlas7 SoC · a7ae982f
      由 Zhiwu Song 提交于 
      This patch breaks Marco SMP support, but Marco project has been dropped.
So it corrects cpu1 jump/flag address for Atlas7 and removes scu related
logic as scu doesn't expose in cortex-a7.
Signed-off-by: NZhiwu Song <Zhiwu.Song@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      a7ae982f
    • B
      ARM: sirf: drop Marco machine · 3c7d21b4
      由 Barry Song 提交于 
      Marco will not be supported any more. it has been replaced by CSR
Atlas7.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      3c7d21b4
    • B
      ARM: sirf: drop Marco support in reset controller module · e664c3ff
      由 Barry Song 提交于 
      Marco will not be supported any more. It has been replaced by CSR
Atlas7.
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      e664c3ff
    • G
      ARM: sirf: add two debug ports for CSRatlas7 SoC · 01ea63d9
      由 Guo Zeng 提交于 
      this patch adds UART0 and UART1 as LLUART port, as the new Atlas7
registers layout are different, it also refines some names of old
hard-coded MARCOs and uses CONFIG_DEBUG_UART_PHYS/DEBUG_UART_VIRT
to define different base addresses for multiple ports.
Signed-off-by: NGuo Zeng <Guo.Zeng@csr.com>
Signed-off-by: NZhiwu Song <Zhiwu.Song@csr.com>
Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Acked-by: NArnd Bergmann <arnd@arndb.de>
      01ea63d9
    • S
      ARM: clk-imx6q: refine esai_ipg's parent · ade9233f
      由 Shengjiu Wang 提交于 
      esai_ipg clock's parent is ahb, not ipg.
Signed-off-by: NShengjiu Wang <shengjiu.wang@freescale.com>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      ade9233f
    • S
      ARM i.MX6q: unmap memory mapped at imx6q_opp_check_speed_grading() · 23bec172
      由 Sebastian Andrzej Siewior 提交于 
      imx6q_opp_check_speed_grading() remaps memory to the base variable and
never unmaps it. I can't see how this can be of any use later so here I
unmap it.
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NShawn Guo <shawn.guo@linaro.org>
      23bec172
    • T
      bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window · 1737cac6
      由 Thomas Petazzoni 提交于 
      The mvebu-mbus driver reads the SDRAM window registers, and make the
information about the DRAM CS configuration available to device
drivers using the mv_mbus_dram_info() API. This information is used by
the DMA-capable device drivers to program their address decoding
windows.

Until now, we were basically providing the SDRAM window register
details as is. However, it turns out that the DMA capability of the
CESA cryptographic engine consists in doing DMA being the DRAM and the
crypto SRAM mapped as a MBus window. For this case, it is very
important that the SDRAM CS information does not overlap with the MBus
bridge window.

Therefore, this commit improves the mvebu-mbus driver to make sure we
adjust the SDRAM CS information so that it doesn't overlap with the
MBus bridge window. This problem was reported by Boris Brezillon,
while working on the mv_cesa driver for Armada 37x/38x/XP. We use the
memblock memory information to know where the usable RAM is located,
as this information is guaranteed to be correct on all SoC variants.

We could have used the MBus bridge window registers on Armada 370/XP,
but they are not really used on Armada 375/38x (Cortex-A9 based),
since the PL310 L2 filtering is used instead to discriminate between
RAM accesses and I/O accesses. Therefore, using the memblock
information is more generic and works accross the different platforms.
Reported-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      1737cac6
    • M
      bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38x · 7fdf3d8a
      由 Michal Mazur 提交于 
      On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

To make things even more fun, the hardware designers have chosen to
put the window 13 remap registers in a completely custom location,
using a logic that differs from the one used for all other remappable
windows.

To solve this problem, this commit:

 * Adds a SoC specific function to calculate offset of remap registers
   to the mvebu_mbus_soc_data structure. This function,
   ->win_remap_offset(), returns the offset of the remap registers, or
   MVEBU_MBUS_NO_REMAP if the window does not have the remap
   capability. This new function replaces the previous integer field
   num_remappable_wins, which was insufficient to encode the special
   case of window 13.

 * Adds an implementation of the ->win_remap_offset() function for the
   various SoC families. Some have 2 first windows that are remapable,
   some the 4 first, some the 8 first, and then the Armada XP/375/38x
   case where the 8 first are remapable plus the special window
   13. This is implemented in functions
   generic_mbus_win_remap_2_offset(),
   generic_mbus_win_remap_4_offset(),
   generic_mbus_win_remap_8_offset() and
   armada_xp_mbus_win_remap_offset() respectively.

 * Change the code to use the ->win_remap_offset() function when
   accessing the remap registers, and also to use a newly introduced
   mvebu_mbus_window_is_remappable() helper function that tells
   whether a given window is remapable or not.

 * Separate Armada 370 from XP/375/38X because the window 13 of Armada
   370 does not support the remap capability.

[Thomas: adapted for the mainline kernel, minor clarifications in the
code, reword the commit log.]
Signed-off-by: NMichal Mazur <arg@semihalf.com>
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      7fdf3d8a
    • T
      ARM: mvebu: use arm_coherent_dma_ops and re-enable hardware I/O coherency · 1bd4d8a6
      由 Thomas Petazzoni 提交于 
      Now that we have enabled automatic I/O synchronization barriers, we no
longer need any explicit barriers. We can therefore simplify
arch/arm/mach-mvebu/coherency.c by using the existing
arm_coherent_dma_ops instead of our custom mvebu_hwcc_dma_ops, and
re-enable hardware I/O coherency support.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Andrew Lunn <andrew@lunn.ch>: Remove forgotten comment]
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      1bd4d8a6
    • T
      bus: mvebu-mbus: use automatic I/O synchronization barriers · a0b5cd4a
      由 Thomas Petazzoni 提交于 
      Instead of using explicit I/O synchronization barriers shoehorned
inside the streaming DMA mappings API (in
arch/arm/mach-mvebu/coherency.c), we are switching to use automatic
I/O synchronization barrier.

The primary motivation for this change is that explicit I/O
synchronization barriers are not only needed for streaming DMA
mappings (which can easily be done by overriding the dma_map_ops), but
also for coherent DMA mappings (which is a lot less easy to do, since
the kernel assumes such mappings are coherent and don't require any
sort of cache maintenance operation to ensure the consistency of the
buffers).

Switching to automatic I/O synchronization barriers will also allow us
to use the existing arm_coherent_dma_ops instead of our custom
arm_dma_ops.

In order to use automatic I/O synchronization barriers, this commit
changes mvebu-mbus in two ways:

 - It enables automatic I/O synchronization barriers in the 0x84
   register of the MBus bridge, by enabling such barriers for all MBus
   units. This enables automatic barriers for the on-SoC peripherals
   that are doing DMA.

 - It enables the SyncEnable bit in the MBus windows, so that PCIe
   devices also use automatic I/O synchronization barrier.

This automatic synchronization barrier relies on the assumption that
at least one register of a given hardware unit is read before the
driver accesses the DMA mappings modified by this unit. This
assumption is guaranteed for PCI devices by vertue of the PCI
standard, and we can reasonably verify that this assumption is also
true for the limited number of platform drivers doing DMA used on
Marvell EBU platforms.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      a0b5cd4a
    • A
      Merge branch 'mvebu/fixes-3' into mvebu/soc · fe6e91e3
      由 Andrew Lunn 提交于
      fe6e91e3
    • A
      bus: mvebu-mbus: fix support of MBus window 13 · 38bdf45f
      由 Andrew Lunn 提交于 
      On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.

As a minimal fix for stable, don't use window 13. A full fix will
follow later.

Fixes: fddddb52 ("bus: introduce an Marvell EBU MBus driver")
Cc: <stable@vger.kernel.org> # v3.10+
Reviewed-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      38bdf45f
  11. 18 1月, 2015 1 次提交
  13. 17 1月, 2015 3 次提交