- 01 Jun, 2015 1 commit
-
-
git://git.infradead.org/linux-mvebuArnd Bergmann authored
Merge "mvebu drivers change for 4.2" from Gregory CLEMENT: mvebu-mbus: add mv_mbus_dram_info_nooverlap() needed for the new Marvell crypto driver * tag 'mvebu-drivers-4.2' of git://git.infradead.org/linux-mvebu: bus: mvebu-mbus: add mv_mbus_dram_info_nooverlap() Based on the earlier bug fixes branch, which contains six other patches already merged into 4.1.
-
- 29 May, 2015 9 commits
-
-
Arnd Bergmann authored
Merge tag 'qcom-soc-for-4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom into next/drivers Merge "Qualcomm ARM Based SoC Updates for v4.2-1" from Kumar Gala: * Added Subsystem Power Manager (SPM) driver * Split out 32-bit specific SCM code * Added HDCP SCM call * tag 'qcom-soc-for-4.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/galak/linux-qcom: firmware: qcom: scm: Add HDCP Support firmware: qcom: scm: Split out 32-bit specific SCM code ARM: qcom: Add Subsystem Power Manager (SPM) driver
-
Suzuki K. Poulose authored
Each CCI model have different event/source codes and formats. This patch exports this information via the sysfs, which includes the aliases for the events. The aliases are listed by 'perf list', helping the users to specify the name of the event instead of the binary config values. Each event alias must accompany the 'source' code except for the following cases : 1) CCI-400 - cycles event, doesn't relate to an interface. 2) CCI-500 - Global events to the CCI. (Fixed source code = 0xf) Each CCI model provides two sets of attributes(format and event), which are dynamically populated before registering the PMU, to allow for the appropriate information. Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Pawel Moll <pawel.moll@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
CCI-500 provides 8 event counters which can count any of the supported events independently. The PMU event id is a 9-bit value made of two parts. bits [8:5] - Source port 0x0-0x6 Slave Ports 0x8-0xD Master Ports 0xf Global Events to CCI 0x7,0xe Reserved bits [0:4] - Event code (specific to each type of port) The generic CCI-500 controlling interface remains the same with CCI-400. However there are some differences in the PMU event counters. - No cycle counter - Upto 8 counters(4 in CCI-400) - Each counter area is 64K(4K in CCI400) - The counter0 starts at offset 0x10000 from the base of CCI Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: devicetree@vger.kernel.org Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
Rename CCI400 specific defintions from CCI_xxx to CCI400_xxx. Introduce generic ARM_CCI_PMU to cover common code for handling the CCI PMU. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
Given that each CCI has different set of interfaces and its associated events, it is good to abstract the validation of the event codes to make it easier to add support for a new CCI model. This patch also abstracts the mapping of a given event to a counter, as there are some special counters for certain specific events. We assume that the fixed hardware counters are always at the beginning, so that we can use cci_model->fixed_hw_events as an upper bound to given idx to check if we need to program the counter for an event. Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
Adds the PMU model specific counters to the PMU model abstraction to make it easier to add a new PMU. The patch cleans up the naming convention used all over the code. e.g, CCI_PMU_MAX_HW_EVENTS => maximum number of events that can be counted at any time, which is in fact the maximum number of counters available. Change all such namings to use 'counters' instead of events. This patch also abstracts the following: 1) Size of a PMU event counter area. 2) Maximum number of programmable counters supported by the PMU model 3) Number of counters which counts fixed events (e.g, cycle counter on CCI-400). Also changes some of the static allocation of the data structures to dynamic, to accommodate the number of events supported by a PMU. Gets rid ofthe CCI_PMU_* defines for the model. All such data should be accessed via the model abstraction. Limits the number of counters to the maximum supported by the 'model'. Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
This patch gets rid of the global struct cci_pmu variable and makes the code use the cci_pmu explicitly. Makes code a bit more robust and reader friendly. Cc: Punit Agrawal <punit.agrawal@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Acked-by: Punit Agrawal <punit.agrawal@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Suzuki K. Poulose authored
Do not enable CCI-400 PMU by default and fix the dependency on PERF_EVENTS than HW_PERF_EVENTS. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: arm@kernel.org Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
https://github.com/mbgg/linux-mediatekArnd Bergmann authored
Merge "ARM: mediatek: soc updates for v4.2" from Matthias Brugger: - pmic wrapper: fix clock handling - pmic wrapper: fix state machine - pmic wrapper: fix compile dependency * tag 'v4.1-next-soc' of https://github.com/mbgg/linux-mediatek: soc: mediatek: Add compile dependency to pmic-wrapper soc: mediatek: PMIC wrap: Fix register state machine handling soc: mediatek: PMIC wrap: Fix clock rate handling
-
- 28 May, 2015 5 commits
-
-
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: Jilai Wang <jilaiw@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org>
-
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
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: Thomas 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: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
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: Nicolas Schichan <nschichan@freebox.fr> Reviewed-by: Thomas 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
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: Imre Kaloz <kaloz@openwrt.org> Cc: <stable@vger.kernel.org> # v4.0 + Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
- 27 May, 2015 3 commits
-
-
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: Matthias Brugger <matthias.bgg@gmail.com>
-
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: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
-
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: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
-
- 20 May, 2015 1 commit
-
-
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
-
- 18 May, 2015 15 commits
-
-
Antoine Tenart authored
This patch adds the ADC node for the Berlin BG2Q, using the newly added Berlin IIO ADC driver. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
Now that the rework to have one sub-node per device in the chip and system controllers is done, their dedicated compatible can be removed. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
The Berlin clock driver was sharing a DT node with the pin controller and the reset driver. All these devices are now sub-nodes of the chip controller. This patch rework the Berlin clock driver to allow moving the Berlin clock DT bindings into their own sub-node of the chip controller node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
With the introduction of the Berlin simple-mfd controller driver, all drivers previously sharing the chip and system controller nodes now have their own sub-node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
With the introduction of the Berlin simple-mfd controller driver, all drivers previously sharing the chip and system controller nodes now have their own sub-node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
With the introduction of the Berlin simple-mfd controller driver, all drivers previously sharing the chip and system controller nodes now have their own sub-node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
Prepare conversion of berlin clk drivers to a simple-mfd sub-node by checking for parent node compatible. If parent node is "syscon" compatible use it for of_iomap instead of the own node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
With convertsion to simple-mfd sub-nodes, drop the regmap registration by SoC stubs. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
Now with proper support for simple-mfd probed pinctrl driver, move to the new soc-pinctrl and system-pinctrl nodes. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
The Berlin pin controller nodes will be simple-mfd probed sub-nodes of soc-controller and system-controller nodes. The register bank is managed by syscon, which provides a regmap. Prepare to get the regmap from syscon parent node instead of SoC stub provided regmap. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
With proper platform driver probing for berlin reset driver, drop the arch_initcall workaround. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
Now with a proper platform driver for reset and simple-mfd, move to the new marvell,berlin-reset node. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
The Berlin reset controller was introduced without being a platform driver because of a needed DT rework: the node describing the reset controller also describes the pinctrl and clk controllers... Prepare conversion by adding a platform driver probe to a new compatible "marvell,berlin2-reset" with syscon regmap. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Acked-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
The chip and system controller nodes will be handled by simple-mfd based driver probing. Prepare the conversion by adding "simple-mfd" and "syscon" compatibles to the corresponding nodes. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
Antoine Tenart authored
The chip and system controller nodes handle sub-devices, such as the clock, pinctrl or reset controllers. The drivers handling them need a regmap provided by syscon. Select it by default when using a Berlin SoC. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
-
- 15 May, 2015 1 commit
-
-
Gregory CLEMENT authored
Since many releases, the modifications of the mvebu and berlin device tree files are merged through the mvebu subsystem. This patch makes it official in order to help the contributors using the get_maintainer.pl to find the accurate peoples. In the same time, updated the mvebu description which now includes the kirkwood SoCs and new Armada SoCs. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Acked-by: Jason Cooper <jason@lakedaemon.net> Acked-by: Andrew Lunn <andrew@lunn.ch>
-
- 13 May, 2015 4 commits
-
-
Pawel Moll authored
hrtimer_start() will no longer defer already expired timers to the softirq in 4.2, and the __hrtimer_start_range_ns() function is getting removed, causing build errors when both the tip tree and the arm-ccn changes are merged. This changes the code back to using hrtimer_start, which will do the right thing after this branch gets merged with the timers update from tip. As pointed out after a discussion on the mailing list, the result will not be worse than the what was there before you pulled my updates, as the code was using normal hrtimer_start(). It's just when I realised that it should be pinned I looked at what x86 uncore pmu is doing and shamelessly (and probably a bit mindlessly) copied the "do not wakeup" version from there. [arnd: update commit message] Reported-by: Mark Brown <mark.brown@arm.com> Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Arnd Bergmann authored
Merge tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers Merge "ARM: tegra: Add EMC driver for v4.2-rc1" from Thierry Reding: This introduces the EMC driver that's required to scale the external memory frequency. * tag 'tegra-for-4.2-emc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: memory: tegra: Add EMC frequency debugfs entry memory: tegra: Add EMC (external memory controller) driver memory: tegra: Add API needed by the EMC driver of: Add Tegra124 EMC bindings of: Document timings subnode of nvidia,tegra-mc
-
Arnd Bergmann authored
Merge tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers Merge "ARM: tegra: RAM code access for v4.2-rc1" from Thierry Reding: The RAM code is used by the memory and external memory controllers to determine which set of timings to use for memory frequency scaling. * tag 'tegra-for-4.2-ramcode' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: fuse: Add RAM code reader helper of: Document long-ram-code property in nvidia,tegra20-apbmisc
-
Arnd Bergmann authored
Merge tag 'tegra-for-4.2-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers Merge "ARM: tegra: Memory controller updates for v4.2-rc1" from Thierry Reding: Adds support for Tegra132 (which is mostly the same as for Tegra124, except for cache maintenance). debugfs support is also introduced for the SMMU part of the memory controller, which allows users to inspect the translation state for SWGROUPs and memory clients. * tag 'tegra-for-4.2-memory' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: memory: tegra: Disable ARBITRATION_EMEM interrupt memory: tegra: Add Tegra132 support iommu/tegra-smmu: Add debugfs support memory: tegra: Add SWGROUP names
-
- 12 May, 2015 1 commit
-
-
git://git.linaro.org/people/pawel.moll/linuxArnd Bergmann authored
Pull "Set of ARM CCN PMU driver updates" from Pawel Moll: - fixed a nasty bitfield mangling bug - added new hints to the perf userspace tool - pinned events processing to a single PMU - modified events initialisation so they can be rotated now * tag 'ccn/updates-for-4.2' of git://git.linaro.org/people/pawel.moll/linux: bus: arm-ccn: Allocate event when it is being added, not initialised bus: arm-ccn: Do not group CCN events with other PMUs bus: arm-ccn: Provide required event arguments bus: arm-ccn: cpumask attribute bus: arm-ccn: Fix node->XP config conversion
-