Hosts the 0x221E linux distro kernel. https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-6.3.y 2022-10-24T13:18:23Z 2022-10-24T13:18:23Z Thierry Reding 2022-09-22T13:41:25Z urn:sha1:228722c519644f8fee2ef75fe8e9d53cd40a3c6c 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> 2022-10-24T13:18:11Z Thierry Reding 2022-09-22T13:41:24Z urn:sha1:4c1e0a97351a5e88e7e503b40cdbe0f220039a5e 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> 2022-06-24T15:57:29Z Timo Alho 2022-06-22T13:22:59Z urn:sha1:a4740b148a04dc60e14fe6a1dfe216d3bae214fd 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> 2021-06-11T11:31:51Z Thierry Reding 2021-04-13T12:23:35Z urn:sha1:bd778b893963d67d7eb01f49d84ffcd3eaf229dd The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding <treding@nvidia.com> 2020-09-18T13:57:04Z Thierry Reding 2020-09-17T10:07:51Z urn:sha1:0ebdf11699d0491c0a1eee5bb5d920f4f36810ba 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-14T15:57:18Z Jon Hunter 2020-07-12T10:01:15Z urn:sha1:edb2bca2ac48ad5fa2fcf7491fdf915a56dd24f6 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-04-21T22:02:10Z Thierry Reding 2020-04-21T22:00:53Z urn:sha1:d70f5e541ab30bf5ff29b219e9d1980e082ba159 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> 2019-10-01T14:38:45Z Vidya Sagar 2019-08-02T06:17:27Z urn:sha1:befc1bab91171d25de22dbcbf41309582a63ecd7 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-25T12:41:44Z Olof Johansson 2019-06-25T12:41:44Z urn:sha1:9d9dd994b5090955264ce555b1944a48865765a1 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-14T15:45:17Z Bitan Biswas 2019-06-14T12:31:39Z urn:sha1:61ed7ef952fc482ec8d4a966ed0d1e32df276c59 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>