The Allwinner SoCs have a handful of SRAM that can be either mapped to be
accessible by devices or the CPU.
That mapping is controlled by an SRAM controller, and that mapping might
not be set by the bootloader, for example if the device wasn't used at all,
or if we're using solutions like the U-Boot's Falcon Boot.
We could also imagine changing this at runtime for example to change the
mapping of these SRAMs to use them for suspend/resume or runtime memory
rate change, if that ever happens.
These use cases require some API in the kernel to control that mapping,
exported through a drivers/soc driver.
This driver also implement a debugfs file that shows the SRAM found in the
system, the current mapping and the SRAM that have been claimed by some
drivers in the kernel.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
mvebu-mbus: add mv_mbus_dram_info_nooverlap() needed for the new
Marvell crypto driver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlVo26sACgkQCwYYjhRyO9UQ4gCeLb6E7RWXGXtLBXRvRi+1a5Vm
GckAn2a/4vAQExwlDsiqHMsM2Iw9Phc7
=1es8
-----END PGP SIGNATURE-----
Merge tag 'mvebu-drivers-4.2' of git://git.infradead.org/linux-mvebu into next/drivers
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.
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>
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>
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>
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>
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>
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>
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>
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>
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 1737cac693 ("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>
This reverts commit 1737cac693 ("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: 1737cac693 ("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>
Commit a0b5cd4ac2 ("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: a0b5cd4ac2 ("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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
The RAM code is used by the memory and external memory controllers to
determine which set of timings to use for memory frequency scaling.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVU1A5AAoJEN0jrNd/PrOhd9IP/iKCdG7BcPX5V+ae7u+12quN
iMvYQBW7z9g292XnFvrB7pOqJaZIp0qLGAWpqA8DqOmF2nLVt5yw8yBB9kEWeeJ6
0Il3xUneZ7NNpdN5NzCWkVfKdr2xFIvWfsl4LrW4fr7C0VaeMi9xq+cFBxK82Xpz
9z9PDDz02ZnVGbaNZJNR7Tc5Ub0dEKHeRlpCFi9wJi0DXrURIklXuLPCoCiEH4KV
K6AuC69ChR4m0nQqhkbeXK4395nfKEIgV+Rmlp6/spJoaQBFC5WELtEzzDLuPS2+
4asfoFZgqEI0tSbG7sczJ4wdPrissYTULfpMW7cVC98vtzMmZLTixoAsgTss9CxS
wmkKyrrgbHM7yxqMksIF7b1z385E7OgNaMMmNPKHfKbzyuoHo+qomFo3WfMLHoZt
2sNvg8qfD0ueCsrsy4zNLoBq+QgwXyDRRO8DnAlToUD7sadqBbPpb3gJd2tBUVjI
v29hf/k3TnMVJJo+uRcZfAaQMvhDr2SK1XDSTzJ3Emkvch70d9idlxmf2H+auSY7
Fbv+NHmdjQeoARicwKAR2ZMc9RVrtQ2/FCMxirX/lagnB3ky+3W3CkhRGuid3yNq
koxW15TY+4YIbgPXXxAwc5uL5IeBQ8YfR7kupSaGLL+FmDD2VBSw7bogc9Plb941
PKocKOFnw3/HRY3mOtjQ
=yv05
-----END PGP SIGNATURE-----
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJVU1AnAAoJEN0jrNd/PrOhWI8P/jqbjvaCbsbVciS4myB8xYhP
A4pny5L38xmz6ngKliBEfW10nwq2JsH+dKAlXzRYMej4QghKjVrVzY2AtYQ3v5wv
MeUx+yJTA54PxRHnI+dAiD7ak8ZswKsFADSVxbbOVHmI+4LQ9PAryW1lhQqikP+8
FzVXWzNrCh1Ikv9qiOYimbKycCYVwzf1cpOnaYgDt+WRfCZBYRaVP2KdTblgC8yu
BM2FiPoWUKdB+YCMYJB7qJtfZOe+lF6lUA8nUVaydnW3F9ll+fCnG/Ypk1iRkXr7
rrAW6IIvkvlLpxb4o27QkuSZYNEvjwbpNAfYEocZ7v/bLAa1Knwjj3MUItgE6MFp
zZuZ0bJ135DvGvNmkPpq3bK8c+iDsqqW2XjmHY6DCSDS9rYzyvu9b37XOYsV9HVr
iMY3Zd8gjrtzMwiE3xLaGxaz20osuWLU4JbOHHRVpgf2u5AWGEfN/kdO+ZJlerFG
7Z3t8svJaGaHB0EICvRxx/1dcnyW/FAS/7GC2Pb3afHBlqmxXdHa6cGzpbFlmEfz
miYgVlEZziJXL+MsUPNHUoupSe9jo/oxm8YOIXR7z9pI9Xg2OWOxhv0afG+i1Y/a
AniEnEmeon+wmL0699bDCvvtEEyRW+k2/mT9xp/M9Nr48DLRHYRVuiNYXd/wAk1t
xu63NH9f+I/4pMb1H+Za
=86m4
-----END PGP SIGNATURE-----
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
- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJVQ7fuAAoJEL9jRaJfXa5Pr6EH+wd92YXgpFHy4x0O77GdK/gk
ErzfFlq/3GX6V+1WkMn0Nfj1vhl/Mq9RF4nSbmEU4c5x0ov48J67b94peo9RChfF
+BjaLw0mNijpCvcFYNIOW4qvJr5LKizvaq3uzw7h7AFl24MwRIKrNXJP6qON04sB
9TCekVCWutKORkEmVpl4Wltsb3LpqNwo/ziby2dmgRCsxPeXnOycsk45/4Tc0GSg
oR5MXLAuvxvNivNMF83FphiAeqPu1eeSWYkT468qqarr4NWKpbYd6uNTMViVHUcW
Yd6pxUwB7dphmLckDOIuJ9QJOfxL263uHaq1taUm1HVp15ldKfWapgVH4hIsUj8=
=mXhn
-----END PGP SIGNATURE-----
Merge tag 'ccn/updates-for-4.2' of git://git.linaro.org/people/pawel.moll/linux into next/drivers
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
- Document MFD DT bindings
- Instantiate subdevices for simple MFDs
- Switch Integrator and RealView to use the simple MFD
- Augment LED driver to probe from platform device
- Add LEDs to Juno Vexpress64
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVUFhiAAoJEEEQszewGV1z0p0P+wf7GkyEqDRY5345gs7dsqDr
ELX48ikqRod8I+C596sbBuJbCM7kQWGPiN3vKToFgqSusOHwKOMyOhvSCzgWSxfS
cTLi86JCNsKjJpIk/AlthBWnvupQMyGdlV2tm2RLC2xrO6t3DKndQ39+yOqd3tMn
OKRpETiejiYSbyrHRX03LNAltRzWJDI7wsmJJs7Nqowb0vw/talixkzKG4PXOb6U
1/cVZgfvpf0z7z1TncfLLsXwjSDyRfchCDCSke6wqH7yXTPSzkCUVttEufANqo+o
PL5VDClaplppj1eo3T2MdeBSD5JONF18TECKVM1LE46glSjAfNnKko+fDSMQXNVx
d09XH5GoDdpKKZlwXP78H2QqLREAjyx/+K7Os/9D1i4kv+oGLigFD6zB3hHV9+lG
TNDWDnW8qUTGYfRj3K3FgWgF8sU8esxNUTMg6buOOXhD3lcpeXcIbLd9vALzCVZy
EARcIifTyD/JFIMs+lJAGD3ZHpzUDRIx9hI165CKxxpdBKEqRW4s/nsDopFszQgp
AIhcbORKNvR/RGdxz0GozN+51r7XWexmoCfLJpntBXp/zbZxKXlrhKNL+1ktCE01
vs++Xci9Qy6ngjTyLikLeiLmDR6V43xAV+8tTR2ifvshfBGpY8y1e7CwNH4yML0c
XLV50CAumHx3HIcbXHM9
=1q0y
-----END PGP SIGNATURE-----
Merge tag 'simple-mfd' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator into next/drivers
Merge "Simple MFD base patches and cleanups" from Linus Walleij:
- Document MFD DT bindings
- Instantiate subdevices for simple MFDs
- Switch Integrator and RealView to use the simple MFD
- Augment LED driver to probe from platform device
- Add LEDs to Juno Vexpress64
* tag 'simple-mfd' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-integrator:
arm64: add LEDs and some trigger support to defconfig
arm64: juno: Add APB registers and LEDs using syscon
leds: syscon: instantiate from platform device
ARM: dts: update syscons to use simple-mfd
MFD/OF: document MFD devices and handle simple-mfd
Si5351 clock generator on CuBox uses XTAL as clock reference, name the
clock phandle accordingly.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Since many boards for ARM, experimental or server alike, will
feature LEDs, let's include LED class and trigger support for
heartbeat and CPU in the defconfig. Many systems (such as the
ARM Juno) will use a system controller "syscon" to access the
LED registers, so include support for this as well.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This defines the Juno "APB system registers" as a syscon device,
and all the LEDs controlled by the APB system registers right
below it using the syscon LEDs driver on top of syscon. Define
LED0 for heartbeat, LED1 for MMC0 activity and the following
four LEDs indicating CPU activity using the Linux-specific
DT bindings for triggers.
This is the pattern and same drivers as used on the legacy
platform device trees for the ARM Integrators and the RealView
PB1176.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Tested-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently syscon LEDs will traverse the device tree looking for syscon devices
and if found, traverse any subnodes of these to identify matching children
and from there instantiate LED class devices.
This is not a good use of the Linux device model. Instead we have converted the
device trees to add the "simple-mfd" property to the MFD nexi spawning syscon
LEDs so that these will appear as platform devices in the system and we can
use the proper device probing mechanism.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The Integrators and the RealView use simple MFD devices with register bit
LEDs as subnodes, update these to use the "simple-mfd" compatible property
so that subdevices get spawned from the MFD nexi.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This defines a new compatible option for MFD devices "simple-mfd" that will
make the OF core spawn child devices for all subnodes of that MFD device.
It is optional but handy for things like syscon and possibly other
simpler MFD devices.
Since there was no file to put the documentation in, I took this opportunity
to make a small writeup on MFD devices and add the compatible definition
there.
Suggested-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-by: Antoine Tenart <antoine.tenart@free-electrons.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Devicetree <devicetree@vger.kernel.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Pull drm fixes from Dave Airlie:
"I really need to get back to sending these on my Friday, instead of my
Monday morning, but nothing too amazing in here: a few amdkfd fixes, a
few radeon fixes, i915 fixes, one tegra fix and one core fix"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm: Zero out invalid vblank timestamp in drm_update_vblank_count.
drm/tegra: Don't use vblank_disable_immediate on incapable driver.
drm/radeon: stop trying to suspend UVD sessions
drm/radeon: more strictly validate the UVD codec
drm/radeon: make UVD handle checking more strict
drm/radeon: make VCE handle check more strict
drm/radeon: fix userptr lockup
drm/radeon: fix userptr BO unpin bug v3
drm/amdkfd: Initialize sdma vm when creating sdma queue
drm/amdkfd: Don't report local memory size
drm/amdkfd: allow unregister process with queues
drm/i915: Drop PIPE-A quirk for 945GSE HP Mini
drm/i915: Sink rate read should be saved in deca-kHz
drm/i915/dp: there is no audio on port A
drm/i915: Add missing MacBook Pro models with dual channel LVDS
drm/i915: Assume dual channel LVDS if pixel clock necessitates it
drm/radeon: don't setup audio on asics that don't support it
drm/radeon: disable semaphores for UVD V1 (v2)
Maxime Ripard