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>
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>
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>
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>
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>
Subdevices of bpmp, such as bpmp-i2c, require the bpmp device's
drvdata to be set during their probe. Currently this is not always the
case. Fix this by calling platform_set_drvdata() earlier during bpmp's
probe.
Signed-off-by: Timo Alho <talho@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This contains a fix for missing semaphore release in error paths as well
as a bogus error code return in the BPMP firmware implementation.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAllDkJsTHHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoXtgD/449NCGPiDlOyxouUF/44RGdu0JPCHg
3xOc8QJHvTqjEXBFW0WFM6ziIfi5l8+QirlEURmhEemkyCToRRN8L78WFXGZqQNl
HM54X9ba4d7ac00hXXpsU+OMxJ3SnLkU4m5Vi7FbOPRx3CZvbLa9xDUMwgKNm97H
W90eFDlmpEmLnw1Bzeasy3dyEvJSSCPbl+6oAyk/FYThAwpn9KlSRw6L5vIptggK
qIHRqvN6OGx5B2Rc26oNiB2/RVMcO7+01J+IItPBuTtWJ7tW7XFQCMMTcSAqKtoV
7EToSZK3wnVTQwCufMnsAA+bBoMtk08g/yMGlXpIdKgzzBJiL3U++YAkimmSVUpD
gnUYqwQvLzw7IbHcunQohXF22wGvdsZqv9mnGdC9jgxKt3meSVhiD4c8zjvbAfWk
wBS7CcWGMGt6QLiAzajIzxVGOM2rgTMrOGGw8uzHhteSl5krSm09JKO/dpn4AUXX
O6jO1+5mTdLUJmsvYi21X2ZBjJfxy258VTSzjlzcm/QRw2Nz98L+x8N5a1iOjCVC
eOb5cfeEaT5MBkR7wwvFyWBVmdVb9xNqkAiL//p4qfMeq+oRmT4fTO37gv44BYoK
qsGd1LMsa5TDnvKoy/Ij5ZNvaVlVXRYIswIy41k7THy+9jeuNWp0HLA5Cr2brXJV
VcZeaRT81se5tQ==
=nTv2
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-4.13-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers
firmware: tegra: Changes for v4.13-rc1
This contains a fix for missing semaphore release in error paths as well
as a bogus error code return in the BPMP firmware implementation.
* tag 'tegra-for-4.13-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
firmware: tegra: Fix locking bugs in BPMP
Signed-off-by: Olof Johansson <olof@lixom.net>
There are a bunch of error paths were we don't unlock the bpmp->threaded
lock. Also if __tegra_bpmp_channel_write() fails then we returned
success instead of an error code.
Fixes: 983de5f971 ("firmware: tegra: Add BPMP support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The BPMP firmware, found on Tegra186 and later, provides an ABI that can
be used to enable and disable power to several power partitions in Tegra
SoCs. The ABI allows for enumeration of the available power partitions,
so the driver can be reused on future generations, provided the BPMP ABI
remains stable.
Based on work by Stefan Kristiansson <stefank@nvidia.com> and Mikko
Perttunen <mperttunen@nvidia.com>.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
We are going to split <linux/sched/clock.h> out of <linux/sched.h>, which
will have to be picked up from other headers and .c files.
Create a trivial placeholder <linux/sched/clock.h> file that just
maps to <linux/sched.h> to make this patch obviously correct and
bisectable.
Include the new header in the files that are going to need it.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The Boot and Power Management Processor (BPMP) is a co-processor found
on Tegra SoCs. It is designed to handle the early stages of the boot
process and offload power management tasks (such as clocks, resets,
powergates, ...) as well as system control services.
Compared to the ARM SCPI, the services provided by BPMP are message-
based rather than method-based. The BPMP firmware driver provides the
services to transmit data to and receive data from the BPMP. Users can
also register a Message ReQuest (MRQ), for which a service routine will
be run when a corresponding event is received from the firmware.
A set of messages, called the BPMP ABI, are specified for a number of
different services provided by the BPMP (such as clocks or resets).
Based on work by Sivaram Nair <sivaramn@nvidia.com> and Joseph Lo
<josephl@nvidia.com>.
Signed-off-by: Thierry Reding <treding@nvidia.com>
