summaryrefslogtreecommitdiff
path: root/drivers/firmware/tegra
AgeCommit message (Collapse)AuthorFilesLines
2021-10-18firmware: tegra: Fix error application of sizeof() to pointerLv Ruyi1-2/+3
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: 06c2d9a078ab ("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>
2021-10-07firmware: tegra: bpmp: Use devm_platform_ioremap_resource()Cai Huoqing1-5/+2
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>
2021-10-07firmware: tegra: Reduce stack usageArnd Bergmann1-9/+17
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: 5e37b9c137ee ("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>
2021-08-11firmware: tegra: Stop using seq_get_buf()Christoph Hellwig1-11/+47
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>
2021-06-11firmware: tegra: bpmp: Fix Tegra234-only buildsThierry Reding3-2/+5
The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding <treding@nvidia.com>
2021-06-01firmware: tegra: Fix error return code in tegra210_bpmp_init()Zhen Lei1-1/+1
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: 139251fc2208 ("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>
2020-11-10firmware: tegra: fix strncpy()/strncat() confusionArnd Bergmann1-5/+1
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: 5e37b9c137ee ("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>
2020-09-18firmware: tegra: Enable BPMP support on Tegra234Thierry Reding1-1/+2
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>
2020-07-14firmware: tegra: Add support for in-band debugJon Hunter1-8/+369
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>
2020-07-14firmware: tegra: Prepare for supporting in-band debugfsJon Hunter1-30/+23
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>
2020-07-14firmware: tegra: Use consistent return variable nameJon Hunter2-21/+21
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>
2020-07-14firmware: tegra: Add return code checks and increase debugfs sizeTimo Alho1-2/+10
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>
2020-05-22firmware: tegra: Defer BPMP probe if shared memory not availableJon Hunter1-2/+2
Since commit 93d2e4322aa7 ("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>
2020-04-22firmware: tegra: Make BPMP a regular driverThierry Reding1-6/+3
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>
2020-02-17firmware: tegra: Fix a typo in KconfigChristophe JAILLET1-1/+1
A 'n' is mising in 'commuication' Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-01firmware: tegra: Move BPMP resume to noirq phaseVidya Sagar1-1/+1
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>
2019-06-25Merge tag 'tegra-for-5.3-firmware' of ↵Olof Johansson1-1/+3
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>
2019-06-14firmware: tegra: Early resume BPMPBitan Biswas1-1/+3
Early resume Tegra BPMP to fix Xavier clock rate error as follows: [ 159.017101] of_serial 3110000.serial: calling platform_pm_resume+0x0/0x58 @ 317, parent: cbb [ 159.025501] of_serial 3110000.serial: platform_pm_resume+0x0/0x58 returned 0 after 14 usecs [ 159.033694] tegra-i2c 31c0000.i2c: calling platform_pm_resume+0x0/0x58 @ 317, parent: cbb [ 159.042254] tegra-i2c 31c0000.i2c: failed changing clock rate: -22 [ 159.048216] PM: dpm_run_callback(): platform_pm_resume+0x0/0x58 returns -22 [ 159.055553] tegra-i2c 31c0000.i2c: platform_pm_resume+0x0/0x58 returned -22 after 13072 usecs [ 159.063875] PM: Device 31c0000.i2c failed to resume: error -22 Signed-off-by: Bitan Biswas <bbiswas@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 288Thomas Gleixner3-28/+3
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>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner2-0/+2
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>
2019-02-07firmware/tegra: Enable Tegra186 BPMP support on Tegra194Thierry Reding3-3/+7
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>
2019-02-07firmware: tegra: Conditionally support SoC generationsThierry Reding2-0/+12
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>
2019-01-25firmware: tegra: bpmp-tegra186: Remove unused includesThierry Reding1-5/+0
Many of the include files are not needed, so drop them. Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-01-25firmware: tegra: add bpmp driver for Tegra210Timo Alho4-9/+282
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>
2019-01-25firmware: tegra: Refactor BPMP driverTimo Alho4-202/+394
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>
2019-01-25firmware: tegra: Reword messaging terminologyTimo Alho1-38/+71
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>
2018-11-08firmware: tegra: Use in-band messages for firmware version queryTimo Alho1-2/+34
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>
2018-11-08firmware: tegra: Print version tag at fullTimo Alho1-6/+10
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>
2018-11-08firmware: tegra: Switch to global mrq_is_supported()Timo Alho1-28/+1
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>
2018-11-08firmware: tegra: Add helper to check for supported MRQsTimo Alho1-0/+25
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>
2018-10-10firmware: tegra: bpmp: Implement suspend/resume supportThierry Reding1-0/+19
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>
2018-03-08firmware: tegra: adjust tested variableJulia Lawall1-1/+1
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>
2018-03-08firmware: tegra: Simplify channel managementMikko Perttunen1-78/+64
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>
2017-11-17Merge tag 'armsoc-drivers' of ↵Linus Torvalds3-9/+470
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 ..
2017-10-25locking/atomics, firmware/ivc: Convert ACCESS_ONCE() to READ_ONCE()/WRITE_ONCE()Mark Rutland1-12/+12
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>
2017-10-19firmware: tegra: Add BPMP debugfs supportTimo Alho3-1/+451
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>
2017-10-19firmware: tegra: Expose tegra_bpmp_mrq_return()Mikko Perttunen1-2/+3
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>
2017-10-17firmware: tegra: Propagate error code to callerTimo Alho1-6/+16
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>
2017-08-17firmware: tegra: set drvdata earlierTimo Alho1-2/+2
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>
2017-07-07Merge tag 'dma-mapping-4.13' of git://git.infradead.org/users/hch/dma-mappingLinus Torvalds1-2/+2
Pull dma-mapping infrastructure from Christoph Hellwig: "This is the first pull request for the new dma-mapping subsystem In this new subsystem we'll try to properly maintain all the generic code related to dma-mapping, and will further consolidate arch code into common helpers. This pull request contains: - removal of the DMA_ERROR_CODE macro, replacing it with calls to ->mapping_error so that the dma_map_ops instances are more self contained and can be shared across architectures (me) - removal of the ->set_dma_mask method, which duplicates the ->dma_capable one in terms of functionality, but requires more duplicate code. - various updates for the coherent dma pool and related arm code (Vladimir) - various smaller cleanups (me)" * tag 'dma-mapping-4.13' of git://git.infradead.org/users/hch/dma-mapping: (56 commits) ARM: dma-mapping: Remove traces of NOMMU code ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus ARM: NOMMU: Introduce dma operations for noMMU drivers: dma-mapping: allow dma_common_mmap() for NOMMU drivers: dma-coherent: Introduce default DMA pool drivers: dma-coherent: Account dma_pfn_offset when used with device tree dma: Take into account dma_pfn_offset dma-mapping: replace dmam_alloc_noncoherent with dmam_alloc_attrs dma-mapping: remove dmam_free_noncoherent crypto: qat - avoid an uninitialized variable warning au1100fb: remove a bogus dma_free_nonconsistent call MAINTAINERS: add entry for dma mapping helpers powerpc: merge __dma_set_mask into dma_set_mask dma-mapping: remove the set_dma_mask method powerpc/cell: use the dma_supported method for ops switching powerpc/cell: clean up fixed mapping dma_ops initialization tile: remove dma_supported and mapping_error methods xen-swiotlb: remove xen_swiotlb_set_dma_mask arm: implement ->dma_supported instead of ->set_dma_mask mips/loongson64: implement ->dma_supported instead of ->set_dma_mask ...
2017-06-20firmware/ivc: use dma_mapping_errorChristoph Hellwig1-2/+2
DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thierry Reding <treding@nvidia.com>
2017-06-19Merge tag 'tegra-for-4.13-firmware' of ↵Olof Johansson1-10/+18
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>
2017-06-14firmware: tegra: Fix locking bugs in BPMPDan Carpenter1-10/+18
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 <dan.carpenter@oracle.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-06-13soc/tegra: bpmp: Implement generic PM domainsThierry Reding1-0/+4
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>
2017-03-02sched/headers: Prepare for new header dependencies before moving code to ↵Ingo Molnar1-0/+1
<linux/sched/clock.h> 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>
2016-11-18firmware: tegra: Add BPMP supportThierry Reding3-0/+881
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>
2016-11-18firmware: tegra: Add IVC libraryThierry Reding3-0/+709
The Inter-VM communication (IVC) is a communication protocol which is designed for interprocessor communication (IPC) or the communication between the hypervisor and the virtual machine with a guest OS. Message channels are used to communicate between processors. They are backed by DRAM or SRAM, so care must be taken to maintain coherence of data. The IVC library maintains memory-based descriptors for the transmission and reception channels as well as the data coherence of the counter and payload. Clients, such as the driver for the BPMP firmware, can use the library to exchange messages with remote processors. Based on work by Peter Newman <pnewman@nvidia.com> and Joseph Lo <josephl@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com>
generated by cgit v1.2.3 (git 2.39.0) at 2024-07-23 00:29:55 +0300