aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2015-01-29ARM: zynq: Simplify SLCR initializationMichal Simek2-30/+7
Based on "mfd: syscon: Decouple syscon interface from platform devices" (sha1: bdb0066df96e74a4002125467ebe459feff1ebef) SLCR driver can use syscon/regmap drivers directly. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-01-29ARM: zynq: PM: Fixed simple typo.Moritz Fischer1-1/+1
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-01-29ARM: zynq: Setup default gpio number for Xilinx ZynqMichal Simek1-1/+1
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2015-01-27ARM: digicolor: add low level debug supportBaruch Siach2-2/+46
Use the USART peripheral as UART for low level debug. Only the UA0 port is currently supported. Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-27ARM: initial support for Conexant Digicolor CX92755 SoCBaruch Siach4-0/+26
Add initial support for the Conexant CX92755 SoC. The CX92755 is one of the Digicolor series of SoCs, all sharing many of the same peripherals. The code was tested on the CX92755 evaluation kit, AKA Equinox. Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Baruch Siach <baruch@tkos.co.il> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-26ARM: OMAP2+: Add dm816x hwmod supportTony Lindgren5-3/+1146
Add minimal hwmod support that works at least on dm8168. This is based on the code in the earlier TI CDP tree, and an earlier patch by Aida Mynzhasova <aida.mynzhasova@skitlab.ru>. I've set up things to work pretty much the same way as for am33xx. We are basically using cm33xx.c with a different set of clocks and clockdomains. This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches published at: http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html Cc: Aida Mynzhasova <aida.mynzhasova@skitlab.ru> Cc: Brian Hutchinson <b.hutchman@gmail.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-01-26ARM: OMAP2+: Add clock domain support for dm816xAida Mynzhasova5-38/+298
This patch adds required definitions and structures for clockdomain initialization, so omap3xxx_clockdomains_init() was substituted by new ti81xx_clockdomains_init() while early initialization of TI81XX platform. Note that we now need to have 81xx in a separate CONFIG_SOC_TI81XX block instead inside the ifdef block for omap3 to avoid make randconfig build errors. This code is based on the TI81XX-LINUX-PSP-04.04.00.02 patches published at: http://downloads.ti.com/dsps/dsps_public_sw/psp/LinuxPSP/TI81XX_04_04/04_04_00_02/index_FDS.html Cc: Brian Hutchinson <b.hutchman@gmail.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Aida Mynzhasova <aida.mynzhasova@skitlab.ru> [tony@atomide.com: updated to apply, renamed to clockdomains81xx.c, fixed to use am33xx_clkdm_operations, various fixes suggested by Paul Walmsley] Reviewed-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-01-26ARM: OMAP2+: Add board-generic.c entry for ti81xxTony Lindgren1-0/+36
This allows booting ti81xx boards when a .dts file is in place. Cc: Brian Hutchinson <b.hutchman@gmail.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-01-26ARM: at91: pm: remove warning to remove SOC_AT91SAM9263 usageAlexandre Belloni1-9/+0
The SOC_AT91SAM9263 is being removed, stop using it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: remove unused mach/system_rev.hAlexandre Belloni1-27/+0
mach/system_rev.h is not used, remove it. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: stop using HAVE_AT91_DBGUxAlexandre Belloni2-22/+3
In order to remove SOC_SAM9xxx options, stop using HAVE_AT91_DBGUx. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: fix ordering of SRAM and PM initializationNicolas Ferre3-9/+9
The PM initialization needs internal SRAM for allocating a gen_pool and use it to store its PM code. So we need to have of_platform_populate() before this code. Suggested-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: sam9: set arm_pm_idle from sam9_dt_device_initAlexandre Belloni8-40/+7
As all sam9 SoCs are setting arm_pm_idle to at91sam9_idle(), do it from sam9_dt_device_init(). Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> [nicolas.ferre@atmel.com: adapt patch to newer series] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: fix sam9n12 and sam9x5 arm_pm_idleAlexandre Belloni2-0/+11
sam9n12 and sam9x5 don't set arm_pm_idle because of an oversight, fix that. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: mark const init data with __initconst instead of __initdataAlexandre Belloni2-2/+2
As long as there is no other non-const variable marked __initdata in the same compilation unit it doesn't hurt. If there were one however compilation would fail with error: $variablename causes a section type conflict because a section containing const variables is marked read only and so cannot contain non-const variables. Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> [nicolas.ferre@atmel.com: update the paths after having re-arranged the patches] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: fix PM initialization for newer SoCsNicolas Ferre4-1/+30
Newer SoCs: at91sam9x5, at91sam9n12, sama5d3 and sama5d4 embed a DDR controller and have a different PMC status register layout than the at91sam9g45. Create another at91_sam9x5_pm_init() function to match this compatibility. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-26ARM: at91: fix Kconfig.debug by adding DEBUG_AT91_UART optionNicolas Ferre1-2/+8
The DEBUG_AT91_UART Kconfig option was forgotten when moving the AT91 debug-macro.S file. Add it and use it for the at91.S compilation. Reported-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
2015-01-23MAINTAINERS: Add co-maintainer for ARM/Qualcomm SupportAndy Gross1-0/+3
Added myself as a co-maintainer. Updated the files to include the Qualcomm SoC directory. Added linux-soc mailing list. Signed-off-by: Andy Gross <agross@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-23ARM: qcom: Drop unnecessary selects from ARCH_QCOMStephen Boyd1-2/+0
We don't need to force gpiolib on everyone given that it isn't required to actually boot the device and the multiplatform Kconfig already selects ARCH_WANT_OPTIONAL_GPIOLIB. CLKSRC_OF is already selected by CONFIG_ARCH_MULTIPLATFORM too, so we can drop that here. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-23ARM: qcom: Fix SCM interface for big-endian kernelsStephen Boyd2-18/+20
The secure environment only runs in little-endian mode, so any buffers shared with the secure environment should have their contents converted to little-endian. We also mark such elements with __le32 to allow sparse to catch such problems. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-23ARM: qcom: scm: Clarify boot interfaceStephen Boyd2-3/+3
The secure world only knows about 32-bit wide physical addresses for the boot API. Clarify the kernel interface by explicitly stating a u32 instead of phys_addr_t which could be 32 or 64 bits depending on LPAE or not. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-23soc: tegra: Add thermal reset (thermtrip) support to PMCMikko Perttunen1-0/+103
This adds a device tree controlled option to enable PMC-based thermal reset in overheating situations. Thermtrip is supported on Tegra30, Tegra114 and Tegra124. The thermal reset only works when the thermal sensors are calibrated, so a soctherm driver is also required. The thermtrip event is triggered by the soctherm block, and all soctherm sensors default to showing a temperature of zero Celsius before they are initialized. Because of this, it is safe to initialize thermtrip and soctherm in any order. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-23ARM: tegra: Add PMC thermtrip programming to Jetson TK1 device treeMikko Perttunen1-0/+7
This adds the required information to reset the board during an overheating situation to the Jetson TK1 device tree. The thermal reset is handled by the PMC by sending an I2C message to the PMIC. The entries specify the I2C message to be sent. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-23of: Add descriptions of thermtrip properties to Tegra PMC bindingsMikko Perttunen1-0/+26
Hardware-triggered thermal reset requires configuring the I2C reset procedure. This configuration is read from the device tree, so document the relevant properties in the binding documentation. Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2015-01-22ARM: qcom: Add SCM warmboot flags for quad core targets.Lina Iyer1-0/+2
Quad core targets like APQ8074, APQ8064, APQ8084 need SCM support set up warm boot addresses in the Secure Monitor. Extend the SCM flags to support warmboot addresses for secondary cores. Signed-off-by: Lina Iyer <lina.iyer@linaro.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-21ARM: hisi: enable smp for HiP01Wang Long3-0/+84
Enable smp for HiP01 board. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> [olof: split off the dts change to a separate commit] Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-21ARM: hisi: rename secondary_startup functionWang Long3-3/+3
As hix5hd2 and hip01 has the same secondary_startup so rename hix5hd2_secondary_startup to to hisi_secondary_startup. the hip01 will use hisi_secondary_startup for the secondary core boot. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-21ARM: hisi: rename smp_prepares_cpus functionWang Long1-2/+2
As hix5hd2 and hip01 has the same .smp_prepare_cpus in struct smp_operations, so rename hix5hd2_smp_prepare_cpus to hisi_common_smp_prepare_cpus. the hip01 will use hisi_common_smp_prepare_cpus in its struct smp_operations. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-21ARM: hisi: enable HiP01 SoCWang Long2-0/+18
Enable Hisilicon HiP01 SoC. This HiP01 SoC series support both one core or dual cores and quad cores. The core is Cortex A9. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-21ARM: debug: add HiP01 debug uartWang Long1-0/+10
Add the support of Hisilicon HiP01 debug uart. The uart of hip01 is 8250 compatible. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Wei Xu <xuwei5@hisilicon.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-01-21ARM: rockchip: remove cpu-core name from machine nameHeiko Stuebner1-1/+1
The Rockchip support is not limited to Cortex-A9 socs anymore and its presence may confuse people reading /proc/cpuinfo. So remove the core specific part. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Doug Anderson <dianders@chromium.org> Tested-by: Doug Anderson <dianders@chromium.org>
2015-01-20ARM: mediatek: Low-level-debug for mt6592Matthias Brugger1-1/+1
This patch changes the description of the low-level-debug port. SoC mt8127 and mt6592 have the same uart port and the same mapping. We just change the description to add low-level-debug to mt6592. Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2015-01-20ARM: mediatek: Add config options for mediatek SoCs.Yingjoe Chen1-1/+21
The upcoming MTK pinctrl driver have a big pin table for each SoC and we don't want to bloat the kernel binary if we don't need it. Add config options so we can build for one SoC only. Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com> Signed-off-by: Hongzhou Yang <hongzhou.yang@mediatek.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2015-01-20ARM: sirf: add Atlas7 machine supportZhiwu Song2-1/+25
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: Zhiwu Song <Zhiwu.Song@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: sirf: move to debug_ll_io_init and drop map_ioBarry Song3-41/+0
This patch moves to debug_ll_io_init(), then finally drops CSR map_io() machine callbacks. Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: sirf: move platsmp to support Atlas7 SoCZhiwu Song2-40/+13
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: Zhiwu Song <Zhiwu.Song@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: sirf: drop Marco machineBarry Song3-27/+0
Marco will not be supported any more. it has been replaced by CSR Atlas7. Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: sirf: drop Marco support in reset controller moduleBarry Song1-29/+12
Marco will not be supported any more. It has been replaced by CSR Atlas7. Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: sirf: add two debug ports for CSRatlas7 SoCGuo Zeng2-18/+46
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: Guo Zeng <Guo.Zeng@csr.com> Signed-off-by: Zhiwu Song <Zhiwu.Song@csr.com> Signed-off-by: Barry Song <Baohua.Song@csr.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
2015-01-20ARM: clk-imx6q: refine esai_ipg's parentShengjiu Wang1-1/+1
esai_ipg clock's parent is ahb, not ipg. Signed-off-by: Shengjiu Wang <shengjiu.wang@freescale.com> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
2015-01-20ARM i.MX6q: unmap memory mapped at imx6q_opp_check_speed_grading()Sebastian Andrzej Siewior1-1/+1
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: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
2015-01-19bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge windowThomas Petazzoni1-16/+89
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: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Fixed merge conflict] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: fix support of MBus window 13 on Armada XP/375/38xMichal Mazur1-48/+116
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: Michal Mazur <arg@semihalf.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Undo the simple fix for stable] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19ARM: mvebu: use arm_coherent_dma_ops and re-enable hardware I/O coherencyThomas Petazzoni1-55/+3
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> [Andrew Lunn <andrew@lunn.ch>: Remove forgotten comment] Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: use automatic I/O synchronization barriersThomas Petazzoni1-3/+14
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19bus: mvebu-mbus: fix support of MBus window 13Andrew Lunn1-0/+13
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: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver") Cc: <stable@vger.kernel.org> # v3.10+ Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
2015-01-19ARM: qcom: scm: Add logging of actual return code from scm callOlav Haugan1-0/+1
When an error occurs during an scm call the error returned is remapped so we lose the original error code. This means that when an error occurs we have no idea what actually failed within the secure environment. Add a logging statement that will log the actual error code from scm call allowing us to easily determine what caused the error to occur. Signed-off-by: Olav Haugan <ohaugan@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-19ARM: qcom: scm: Flush the command buffer only instead of the entire cacheVikram Mulukutla1-5/+12
scm_call flushes the entire cache before calling into the secure world. This is both a performance penalty as well as insufficient on SMP systems where the CPUs possess a write-back L1 cache. Flush only the command and response buffers instead, moving the responsibility of flushing any other cached buffer (being passed to the secure world) to callers. Signed-off-by: Vikram Mulukutla <markivx@codeaurora.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-19ARM: qcom: scm: Get cacheline size from CTRStephen Boyd1-6/+8
Instead of hardcoding the cacheline size as 32, get the cacheline size from the CTR register. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
2015-01-19ARM: qcom: scm: Fix incorrect cache invalidationStephen Boyd1-8/+23
The cache invalidation in scm_call() correctly rounds down the start address to invalidate the beginning of the cacheline but doesn't properly round up the 'end' address to make it aligned. The last chunk of the buffer won't be invalidated when 'end' is not cacheline size aligned so make sure to invalidate the last few bytes in such situations. It also doesn't do anything about outer caches so make sure to invalidate and flush those as well. Signed-off-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.