08 Feb, 2019
2 commits
-
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
Reviewed-by: Timo Alho
Tested-by: Timo Alho
Signed-off-by: Thierry Reding -
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
Reviewed-by: Timo Alho
Tested-by: Timo Alho
Signed-off-by: Thierry Reding
25 Jan, 2019
3 commits
-
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
Signed-off-by: Timo Alho
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding -
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
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding -
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
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding
08 Nov, 2018
3 commits
-
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
Acked-by: Sivaram Nair
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding -
Last two characters of the version tag that is 32 bytes long were
stripped out.Signed-off-by: Timo Alho
Acked-by: Sivaram Nair
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding -
Add a helper function to check that firmware is supporting a given MRQ
command.Signed-off-by: Timo Alho
Acked-by: Sivaram Nair
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding
10 Oct, 2018
1 commit
-
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
08 Mar, 2018
2 commits
-
Check the variable that was most recently initialized.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)//
@@
expression x, y, f, g, e, m;
statement S1,S2,S3,S4;
@@x = f(...);
if (\(\&e\)) S1 else S2
(
x = g(...);
|
m = g(...,&x,...);
|
y = g(...);
*if (e)
S3 else S4
)
//Signed-off-by: Julia Lawall
Reviewed-by: Mikko Perttunen
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding
19 Oct, 2017
2 commits
-
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
Reviewed-by: Jon Hunter
Signed-off-by: Thierry Reding -
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
Signed-off-by: Thierry Reding
17 Oct, 2017
1 commit
-
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
Acked-by: Jon Hunter
Signed-off-by: Thierry Reding
17 Aug, 2017
1 commit
-
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
Signed-off-by: Thierry Reding
19 Jun, 2017
1 commit
-
…/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 BPMPSigned-off-by: Olof Johansson <olof@lixom.net>
14 Jun, 2017
1 commit
-
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: 983de5f97169 ("firmware: tegra: Add BPMP support")
Signed-off-by: Dan Carpenter
Signed-off-by: Thierry Reding
13 Jun, 2017
1 commit
-
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 and Mikko
Perttunen .Signed-off-by: Thierry Reding
Reviewed-by: Ulf Hansson
Signed-off-by: Thierry Reding
02 Mar, 2017
1 commit
-
We are going to split out of , which
will have to be picked up from other headers and .c files.Create a trivial placeholder file that just
maps to 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
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar
18 Nov, 2016
1 commit
-
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 and Joseph Lo
.Signed-off-by: Thierry Reding