summaryrefslogtreecommitdiffstats
path: root/drivers/firmware/tegra
AgeCommit message (Collapse)AuthorFilesLines
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-16Merge 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-06Merge 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-18Merge 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>