The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/20230803-dt-header-cleanups-for-soc-v2-17-d8de2cc88bff@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Implement support for DRAM MRQ GSCs.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
[treding@nvidia.com: drop unnecessary discrimination enum]
Signed-off-by: Thierry Reding <treding@nvidia.com>
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some error paths in mrq_debug_read and bpmp_debug_show would overwrite
the return error code with a subsequent call to mrq_debug_close.
Change the code to only change the error code if there was no prior
error.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The BPMP firmware driver never worked on big-endian kernels, and
cannot easily be made portable. Add a dependency to make this clear
in case anyone ever wants to try a big-endian kernel on this hardware.
Link: https://lore.kernel.org/linux-arm-kernel/Y34FCQ3xTmcjqKRT@orome/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
There is no need to call the dev_err() function directly to print a
custom message when handling an error from either the platform_get_irq()
or platform_get_irq_byname() functions as both are going to display an
appropriate error message in case of a failure.
./drivers/firmware/tegra/bpmp-tegra210.c:204:2-9: line 204 is redundant
because platform_get_irq() already prints an error
./drivers/firmware/tegra/bpmp-tegra210.c:216:2-9: line 216 is redundant
because platform_get_irq() already prints an error
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2579
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The CPU and BPMP inter-processor communication code is only partially
endian-aware, so it doesn't work properly when run on a big-endian CPU
anyway. Running Tegra SoCs in big-endian mode has also never been
supported, especially not on those with 64-bit ARM processors.
If big-endian support ever becomes necessary this can be added back but
will need additional fixes for completeness.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The shared memory used for inter-processor communication between the CPU
and the BPMP can reside either in system memory or in I/O memory. Use
the iosys-map helpers to abstract these differences away.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The canonical type for 32-bit unsigned integers in the kernel is u32, so
use that instead of uint32_t.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch fixes the following Coccinelle warning:
drivers/firmware/tegra/bpmp-debugfs.c:379: WARNING opportunity for memdup_user
Use memdup_user() rather than duplicating its implementation. This is a
little bit restricted to reduce false positives.
Signed-off-by: Qing Wang <wangqing@vivo.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
If an error occurs, debugfs_create_file() will return ERR_PTR(-ERROR),
so use IS_ERR() to check it.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use memcpy_toio and memcpy_fromio variants of memcpy to guarantee no
unaligned access to IPC memory area. This is to allow the IPC memory to
be mapped as Device memory to further suppress speculative reads from
happening within the 64 kB memory area above the IPC memory when 64 kB
memory pages are used.
Signed-off-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Application of sizeof() to pointer yields the number of bytes of the
pointer, but it should use the length of buffer in the code.
Fixes: 06c2d9a078 ("firmware: tegra: Reduce stack usage")
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Lv Ruyi <lv.ruyi@zte.com.cn>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Use the devm_platform_ioremap_resource() helper instead of calling
platform_get_resource() and devm_ioremap_resource() separately.
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Building the bpmp-debugfs driver for Arm results in a warning for stack usage:
drivers/firmware/tegra/bpmp-debugfs.c:321:16: error: stack frame size of 1224 bytes in function 'bpmp_debug_store' [-Werror,-Wframe-larger-than=]
static ssize_t bpmp_debug_store(struct file *file, const char __user *buf,
It should be possible to rearrange the code to not require two separate
buffers for the file name, but the easiest workaround is to use dynamic
allocation.
Fixes: 5e37b9c137 ("firmware: tegra: Add support for in-band debug")
Link: https://lore.kernel.org/all/20201204193714.3134651-1-arnd@kernel.org/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[treding@nvidia.com: consistently return NULL on failure]
Signed-off-by: Thierry Reding <treding@nvidia.com>
Opencode a copy of mrq_debug_read() in bpmp_debug_show() so that it
can use seq_write() directly instead of poking holes into the seq_file
abstractions using seq_get_buf().
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When call irq_get_irq_data() to get the IRQ's irq_data failed, an
appropriate error code -ENOENT should be returned. However, we directly
return 'err', which records the IRQ number instead of the error code.
Fixes: 139251fc22 ("firmware: tegra: add bpmp driver for Tegra210")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The way that bpmp_populate_debugfs_inband() uses strncpy()
and strncat() makes no sense since the size argument for
the first is insufficient to contain the trailing '/'
and the second passes the length of the input rather than
the output, which triggers a warning:
In function 'strncat',
inlined from 'bpmp_populate_debugfs_inband' at ../drivers/firmware/tegra/bpmp-debugfs.c:422:4:
include/linux/string.h:289:30: warning: '__builtin_strncat' specified bound depends on the length of the source argument [-Wstringop-overflow=]
289 | #define __underlying_strncat __builtin_strncat
| ^
include/linux/string.h:367:10: note: in expansion of macro '__underlying_strncat'
367 | return __underlying_strncat(p, q, count);
| ^~~~~~~~~~~~~~~~~~~~
drivers/firmware/tegra/bpmp-debugfs.c: In function 'bpmp_populate_debugfs_inband':
include/linux/string.h:288:29: note: length computed here
288 | #define __underlying_strlen __builtin_strlen
| ^
include/linux/string.h:321:10: note: in expansion of macro '__underlying_strlen'
321 | return __underlying_strlen(p);
Simplify this to use an snprintf() instead.
Fixes: 5e37b9c137 ("firmware: tegra: Add support for in-band debug")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable support for the BPMP on Tegra234 to avoid relying on Tegra194
being enabled to pull in the needed OF device ID table entry.
On simulation platforms the BPMP hasn't booted up yet by the time we
probe the BPMP driver and the BPMP hasn't had a chance to mark the
doorbell as ringable by the CCPLEX. This corresponding check in the
BPMP driver will therefore fail. Work around this by disabling the
check on simulation platforms.
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for retrieving BPMP debug information via in-band messaging
as opposed to using shared-memory which older BPMP firmware used. Note
that it is possible to detect at runtime whether the BPMP firmware being
used supports the in-band messaging for retrieving the debug
informaation. Therefore, if the BPMP firmware supports the in-band
messaging for debug use this and otherwise fall-back to using shared
memory.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Currently, BPMP debug information is accessible via the Linux debugfs
file-system using a shared-memory scheme. More recent BPMP firmware now
supports accessing the debug information by in-band messaging which does
not require shared-memory. To prepare for adding in-band debugfs support
for the BPMP, move the shared-memory specific initialisation from the
tegra_bpmp_init_debugfs() into a sub-function.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Most functions in the BPMP driver use 'err' as the return variable
name but there are a few places that use 'ret'. Let's use 'err' to
be consistent.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add checking of the BPMP-FW return code values for MRQ_DEBUGFS calls.
Also, development versions of the firmware may have debugfs with a
directory structure larger than 256 KiB. Hence increase the size of the
memory buffer to accommodate those firmware revisions.
And finally, ensure that no access outside of allocated memory buffer
happens in case BPMP-FW returns an invalid response size (nbytes) from
mrq_debugfs_dumpdir() call.
Signed-off-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Since commit 93d2e4322a ("of: platform: Batch fwnode parsing when
adding all top level devices") was added, the probing of the Tegra
SRAM device has occurred later in the boot sequence, after the BPMP
has been probed. The BPMP uses sections of the SRAM for shared memory
and if the BPMP is probed before the SRAM then it fails to probe and
never tries again. This is causing a boot failure on Tegra186 and
Tegra194. Fix this by allowing the probe of the BPMP to be deferred if
the SRAM is not available yet.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra BPMP driver typically ends up deferring probe because it wants
to attach to the SMMU, so there's little sense in registering it at the
core init-level.
One side-effect of this is that the driver will be probed later even if
it doesn't want to attach to an SMMU, which means that consumers will
end up deferring probe, which in turn takes care of ordering the suspend
and resume queue in the correct way. Currently since suspend/resume
order depends on instantiation order, and because BPMP is listed at the
very end of the device tree (after most of its consumers), the suspend
and resume queue is ordered wrongly, which can cause issues for drivers
(like I2C) which suspend after and resume before BPMP. In the case of
I2C this typically leads to the clock failing to enable.
Besides fixing this suspend/resume ordering issue, this also has the
added benefit of allowing the driver to be built as a loadable module,
which can help decrease the size of multiplatform kernel.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Modules like PCIe in Tegra194 need BPMP firmware services in noirq phase
and hence move BPMP resume to noirq phase.
This patch is verified on Tegra210, Tegra186 and Tegra194.
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This contains a single, simple change that resumes the BPMP driver early
so that it is available when the various consumers want to enable their
clocks.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAl0M6qQTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zofelEAC3vOPpxp5WlH5Cu2hxu7LKm5/bWQBy
hMs6NPjx5kP4IOhIMgoE31aDBKiQeUwF8D+SNjyfELqgZjYkc93eVSoB5DzzQC3R
N7kcAiADqIekJlPcJvp5SUzG9gf3nNDLNIpFVkFn+olRY2wDdOzAwClO7ygX/GUU
zdBfu26vhcfBvg9gH/oWV3vjrdRm0H8KULDRWfQFvzHoMRagTCle6+i9MFiCFt4D
BoKar0Vcd02tt0Fh/uYVz58wg5ryHx1Z/j/rkYqgZ74MFL4wmnhhdbJB/+i5QPLf
73NKwxNBvW06ro2e807NpoUn5PjOHUx0uyPWtUsnnk4xu4eVa1XQmsKaWElAmUhO
xync25GGLrIxup9VnHWe19r6U1HgNLW1gX5PQ6su5OobAgaiA/Mkq7FRYoEOBGxN
T1ljNzwZUpIqPCo4BVxWHz+F8Jqsl1hgvbqJjgfxsBxZrkTr9EEltZXBLS1kdbzb
51QkK1QLHqKn8ugydJF3zpF1IPK9cvLD/MjFXCjDDkpmZ7v3F+8QZIAy9nat/k93
kKU/B3iY8q5CPzT/GqpHOWSoLx6qTDe+Sla8egJJhJR8Fr1DItcmtJnmJFztM5aA
O4Uv0RY63YKdqO/XUge5sEVCTVyGCN1y8SuE5Oj5/8b5Zcax+NV00GXRWVy0Tf2F
fSZMk25b/ol4LQ==
=fkWW
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-5.3-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/drivers
firmware: tegra: Changes for v5.3-rc1
This contains a single, simple change that resumes the BPMP driver early
so that it is available when the various consumers want to enable their
clocks.
* tag 'tegra-for-5.3-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: Early resume BPMP
Signed-off-by: Olof Johansson <olof@lixom.net>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms and conditions of the gnu general public license
version 2 as published by the free software foundation this program
is distributed in the hope it will be useful but without any
warranty without even the implied warranty of merchantability or
fitness for a particular purpose see the gnu general public license
for more details
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 263 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Alexios Zavras <alexios.zavras@intel.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190529141901.208660670@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The BPMP implementation on Tegra194 is mostly compatible with the
implementation on Tegra186, so make sure the latter is available when
support for Tegra194 is enabled.
Suggested-by: Timo Alho <talho@nvidia.com>
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Only include support for Tegra210 and Tegra186 in the BPMP driver if
support for those SoCs was selected. This fixes a build failure seen
on 32-bit ARM allmodconfig builds, but could also happen on 64-bit
ARM builds if either Tegra210 or Tegra186 were not selected.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Timo Alho <talho@nvidia.com>
Tested-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch adds driver for Tegra210 BPMP firmware.
The BPMP is a specific processor in Tegra210 chip, which runs firmware
for assisting in entering deep low power states (suspend to ram), and
offloading DRAM memory clock scaling on some platforms.
Based on work by Sivaram Nair <sivaramn@nvidia.com>
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Split BPMP driver into common and chip specific parts to facilitate
adding support for previous and future Tegra chips that are using BPMP
as co-processor.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
As a preparatory change to refactor BPMP driver to support other than
Tegra186 and Tegra194 chip generations, reword and slightly refactor
some of the functions to better match with what is actually happening
in the wire-level protocol.
The communication with BPMP is essentially a Remote Procedure Call
consisting of "request" and "response". Either side (BPMP or CPU) can
initiate the communication. The state machine for communication
consists of following steps (from Linux point of view):
Linux initiating the call:
1) check that channel is free to transmit a request
(is_request_channel_free)
2) copy request message payload to shared location
3) post the request in channel (post_request)
4) notify BPMP that channel state has been updated (ring_doorbell)
5) wait for response (is_response_ready)
6) copy response message payload from shared location
7) acknowledge the response in channel (ack_response)
BPMP initiating the call:
1) wait for request (is_request_ready)
2) copy request message payload from shared location
3) acknowledge the request in channel (ack_request)
4) check that channel is free to transmit response
(is_response_channel_free)
5) copy response message payload to shared location
6) post the response message to channel (post_response)
7) notify BPMP that channel state has been updated (ring_doorbell)
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add support for a new MRQ, that uses in-band messaging instead of IOVA
buffer, to retrieve the firmware version 'tag' during boot. If an
older firmware is used, that does not support the new MRQ, fall back
to the earlier implementation.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Last two characters of the version tag that is 32 bytes long were
stripped out.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Patch "firmware: tegra: add helper to check for supported MRQs" added
an API to check if MRQ is supported. Remove the implementation from
bpmp debugfs code in favor of that.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a helper function to check that firmware is supporting a given MRQ
command.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Sivaram Nair <sivaramn@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When returning from a system sleep state, the BPMP driver needs to
reinitialize the IVC channels used to communicate with the BPMP to
restore proper functionality.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Check the variable that was most recently initialized.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x, y, f, g, e, m;
statement S1,S2,S3,S4;
@@
x = f(...);
if (\(<+...x...+>\&e\)) S1 else S2
(
x = g(...);
|
m = g(...,&x,...);
|
y = g(...);
*if (e)
S3 else S4
)
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Reviewed-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
and they are not placed contiguously in memory. The current channel
management in the BPMP driver does not support this.
Simplify and refactor the channel management such that only one atomic
transmit channel and one receive channel are supported, and channels
are not required to be placed contiguously in memory. The same
configuration also works on T186 so we end up with less code.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This branch contains platform-related driver updates for ARM and ARM64,
these are the areas that bring the changes:
New drivers:
- Driver support for Renesas R-Car V3M (R8A77970)
- Power management support for Amlogic GX
- A new driver for the Tegra BPMP thermal sensor
- A new bus driver for Technologic Systems NBUS
Changes for subsystems that prefer to merge through arm-soc:
- The usual updates for reset controller drivers from Philipp Zabel,
with five added drivers for SoCs in the arc, meson, socfpa, uniphier
and mediatek families.
- Updates to the ARM SCPI and PSCI frameworks, from Sudeep Holla,
Heiner Kallweit and Lorenzo Pieralisi.
Changes specific to some ARM-based SoC
- The Freescale/NXP DPAA QBMan drivers from PowerPC can now work
on ARM as well.
- Several changes for power management on Broadcom SoCs
- Various improvements on Qualcomm, Broadcom, Amlogic, Atmel, Mediatek
- Minor Cleanups for Samsung, TI OMAP SoCs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJaDggbAAoJEGCrR//JCVInIeQQAN1MDyO1UaWiFYnbkVOgzFcj
dqbFOc41DBE/90JoBWE8kR/rjyF83OqztiaYpx9viu2qMMBZVcOwxhCUthWK59c/
IujYdw4zGevLscF+jdrLbXgk97nfaWebsHyTAF307WAdZVJxiVGGzQEcgm71d6Zp
CXjLiUii4winHUMK9FLRY2st0HKAevXhuvZJVV432+sTg3p7fGVilYeGOL5G62WO
zQfCisqzC5q677kGGyUlPRGlHWMPkllsTTnfXcmV/FUiGyVa3lUWY5sEu+wCl96O
U1ffPENeNj/A/4fa1dbErtbiNnC2z/+jf+Dg7Cn8w/dPk4Suf0ppjP8RqIGyxmDl
Wm/UxbwDClxaeF4GSaYh2yKgGRJMH5N87bJnZRINE5ccGiol8Ww/34bFG0xNnfyh
jSAFAc318AFG62WD4lvqWc7LSpzOYxp/MNqIFXKN692St/MJLkx8/q0nTwY1qPY0
3SELz9II3hz+3MfDRqtRi7hZpkgHgQ+UG7S5+Xhmqrl309GOEldCjPVJhhXxWoxK
ZPtZOuyYvGhIC+YAnHaN6lUjADIdNJZHwbuXFImx85oKHVofoxHbcni5vk8Uu7z1
sQNYOtdDGaPG/2u9RJdJlPg/jIgLKxxt/Xm9TYVawpZ5hFANhBTtIq5ExCRAil68
j9sMOrpZ1DzCQyR7zN2v
=qDhq
-----END PGP SIGNATURE-----
Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC driver updates from Arnd Bergmann:
"This branch contains platform-related driver updates for ARM and
ARM64, these are the areas that bring the changes:
New drivers:
- driver support for Renesas R-Car V3M (R8A77970)
- power management support for Amlogic GX
- a new driver for the Tegra BPMP thermal sensor
- a new bus driver for Technologic Systems NBUS
Changes for subsystems that prefer to merge through arm-soc:
- the usual updates for reset controller drivers from Philipp Zabel,
with five added drivers for SoCs in the arc, meson, socfpa,
uniphier and mediatek families
- updates to the ARM SCPI and PSCI frameworks, from Sudeep Holla,
Heiner Kallweit and Lorenzo Pieralisi
Changes specific to some ARM-based SoC
- the Freescale/NXP DPAA QBMan drivers from PowerPC can now work on
ARM as well
- several changes for power management on Broadcom SoCs
- various improvements on Qualcomm, Broadcom, Amlogic, Atmel,
Mediatek
- minor Cleanups for Samsung, TI OMAP SoCs"
[ NOTE! This doesn't work without the previous ARM SoC device-tree pull,
because the R8A77970 driver is missing a header file that came from
that pull.
The fact that this got merged afterwards only fixes it at this point,
and bisection of that driver will fail if/when you walk into the
history of that driver. - Linus ]
* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (96 commits)
soc: amlogic: meson-gx-pwrc-vpu: fix power-off when powered by bootloader
bus: add driver for the Technologic Systems NBUS
memory: omap-gpmc: Remove deprecated gpmc_update_nand_reg()
soc: qcom: remove unused label
soc: amlogic: gx pm domain: add PM and OF dependencies
drivers/firmware: psci_checker: Add missing destroy_timer_on_stack()
dt-bindings: power: add amlogic meson power domain bindings
soc: amlogic: add Meson GX VPU Domains driver
soc: qcom: Remote filesystem memory driver
dt-binding: soc: qcom: Add binding for rmtfs memory
of: reserved_mem: Accessor for acquiring reserved_mem
of/platform: Generalize /reserved-memory handling
soc: mediatek: pwrap: fix fatal compiler error
soc: mediatek: pwrap: fix compiler errors
arm64: mediatek: cleanup message for platform selection
soc: Allow test-building of MediaTek drivers
soc: mediatek: place Kconfig for all SoC drivers under menu
soc: mediatek: pwrap: add support for MT7622 SoC
soc: mediatek: pwrap: add common way for setup CS timing extenstion
soc: mediatek: pwrap: add MediaTek MT6380 as one slave of pwrap
..
workqueue: kill off ACCESS_ONCE()
For several reasons, it is desirable to use {READ,WRITE}_ONCE() in
preference to ACCESS_ONCE(), and new code is expected to use one of the
former. So far, there's been no reason to change most existing uses of
ACCESS_ONCE(), as these aren't currently harmful.
However, for some features it is necessary to instrument reads and
writes separately, which is not possible with ACCESS_ONCE(). This
distinction is critical to correct operation.
It's possible to transform the bulk of kernel code using the Coccinelle
script below. However, this doesn't handle comments, leaving references
to ACCESS_ONCE() instances which have been removed. As a preparatory
step, this patch converts the Tegra IVC code and comments to use
{READ,WRITE}_ONCE() consistently.
----
virtual patch
@ depends on patch @
expression E1, E2;
@@
- ACCESS_ONCE(E1) = E2
+ WRITE_ONCE(E1, E2)
@ depends on patch @
expression E;
@@
- ACCESS_ONCE(E)
+ READ_ONCE(E)
----
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: davem@davemloft.net
Cc: linux-arch@vger.kernel.org
Cc: mpe@ellerman.id.au
Cc: shuah@kernel.org
Cc: snitzer@redhat.com
Cc: thor.thayer@linux.intel.com
Cc: tj@kernel.org
Cc: viro@zeniv.linux.org.uk
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1508792849-3115-3-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Tegra power management firmware running on the co-processor (BPMP)
implements a simple pseudo file system akin to debugfs. The file
system can be used for debugging purposes to examine and change the
status of selected resources controlled by the firmware (such as
clocks, resets, voltages, powergates, ...).
Add support to "mirror" the firmware's file system to debugfs. At
boot, query firmware for a list of all possible files and create
corresponding debugfs entries. Read/write of individual files is
implemented by sending a Message ReQuest (MRQ) that passes the full
file path name and data to firmware via DRAM.
Signed-off-by: Timo Alho <talho@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Expose and export the tegra_bpmp_mrq_return() function for use by
drivers outside the core BPMP driver. This function is used to reply to
messages originating from the BPMP, which is required in the thermal
driver.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Response messages from Tegra BPMP firmware contain an error return code
as the first word of payload. The error code is used to indicate
incorrectly formatted request message or use of non-existing resource
(clk, reset, powergate) identifier. Current implementation of
tegra_bpmp_transfer() ignores this code and does not pass it to caller.
Fix this by adding an extra struct member to tegra_bpmp_message and
populate that with return code.
Signed-off-by: Timo Alho <talho@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Rob Herring