Adding regulator driver for MAX77812 device which is
used in t210b01 based platforms for powering cpu,gpu
and dram io
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These are generated by the Tegra210 Android bootloader. This is similar
to the Tegra124 handling, so the support is based on that and modified
to match Tegra210 by referencing the downstream Nvidia 4.9 kernel.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These entries are imported from the downstream Nvidia Linux4Tegra
kernel. They are expected to be updated with the trained values by the
bootloader. This is done by the Nvidia Android bootloader, which is
different from the handling by the Nvidia Linux bootloader which places
these values in a reserved memory location. P2180 is supported by both
bootloaders, so lets support initializing emc on both.
It should be noted that the bootloader will not create these nodes in
the kernel dtb if they do not exist. It will only set in place existing
properties.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add support for booting and using NVENC on Tegra210+ to the Host1x
and TegraDRM drivers. This driver only supports the new TegraDRM uAPI.
Change-Id: I07e1386604d7638ba43381c3f289688d7c5cb12b
Add initial device-tree support for NVIDIA Shield TV (a.k.a. Foster)
based upon Tegra210 SoC with 3 GiB of LPDDR4 RAM. It is based on P2571.
Change-Id: Ideeeb15f835ebf7f7617d3989908d245aff4b316
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Enable the XUSB controller on P2571. One of the USB 3.0 lanes goes to an
internal ethernet interface, while two other USB 3.0 lanes support the
the USB-A receptacles on the I/O board.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This is based on 6f78a94, which enabled added the fan and thermal zones
for the Jetson Nano Devkit. The fan and thermal characteristics of the
two devices are similar, so using the same configuration.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This adds the gpu regulator and enables the gpu node.
Change-Id: I8a0f580fa600d8f37fb3fa497cf657abf2905d5f
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Based on the p2180 pmic config, modified to match p2530
Change-Id: Ic7baa787b8e9633da72622a4562258860c05fca6
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The SHIELD TV 2015 is a consumer media Android device that is based on
P2571
Change-Id: Ib981728d277f7daca812223ec3534d98555d43a1
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
The p3310 som has a BCM4354 module with wifi on sdio.
Change-Id: Ie4b42165fb81a129a7afe58c1c632261d13eca53
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This appears to be a typo. The voltage input to the wireless module is
expected to be 1.8V-3.3V, per the downstream device tree.
Fixes: 02df3f03a8 ("arm64: tegra: Add initial power tree for P3310")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping.
One table is added for each cluster even though the table data is
same because the bandwidth request is per cluster. This is done
because the OPP framework creates a single icc path and hence single
bandwidth request if the table is marked as 'opp-shared' and shared
among all clusters. For us, the OPP table data is same but the MC
Client ID argument to interconnects property is different for each
cluster. So, having per cluster tables makes different icc paths for
each cluster and helps to make per cluster BW requests.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add OPP table and interconnects property to scale DDR frequency with
CPU frequency for better performance. Each operating point entry of
the OPP table has CPU freq to per MC channel bandwidth mapping. One
table is added for each cluster because the different cpu types have
different scaling curves.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC driver is already a provider.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Add Interconnect framework support to dynamically set the DRAM
bandwidth from different clients. The MC driver is added as an ICC
provider and the EMC driver is already a provider.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This adds support for dynamic frequency scaling of external memory on
devices with bpmp firmware that does not support bwmgr.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
This will be used in the upcoming non-bpmp icc support, which will use
the common tegra emc rate support which uses the opp framework.
Change-Id: If4a3efaae0ad06de029ffd34c2b11faea5044d58
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
These are being referenced by actmon, but are not currently enabled.
Fixes: 654427e0b9 ("arm64: tegra: Add OPP tables on Tegra210")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
As is, the EMC drivers for each 32-bit platform contain almost
identical duplicated code for aggregating rate requests. Move this
code out to a shared tegra-emc-common file to reduce duplication,
and add kerneldoc comments.
Based on code from the tegra20-emc driver.
Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
Link: https://patch.msgid.link/20260501-memory-refactor-v3-1-69fb1ae1a7ca@nvidia.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Without the cmu, nvdisplay will display colors that are notably darker
than intended. The vendor bootloader and the downstream display driver
enable the cmu and sets a sRGB table. Loading that table here results in
the intended colors.
Co-developed-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Kurt Kiefer <kekiefer@gmail.com>
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Tested-by: Jasper Korten <jja2000@gmail.com>
The member list of struct binder_priority is missing the colon kernel-doc
needs to associate a line with a member, so neither @sched_policy nor @prio
is picked up as a description.
This has been wrong since the block was introduced together with the struct
in "ANDROID: binder: add support for RT prio inheritance." That commit was
merged on experimental/android-4.19-staging and the block has been carried
forward across branches since, so there is no commit in android-mainline
history to point a Fixes: tag at. The same commit spelled @sched_policy:
correctly in the binder_node block just above, which suggests the missing
colons here were a typo rather than a convention.
struct binder_priority is ANDROID-only and does not exist upstream, so there
is nothing to send to mainline for this.
scripts/kernel-doc -none drivers/android/binder_internal.h reports two
warnings for binder_priority before this change and none after it. The
remaining warnings in this file are also present in mainline and are left
alone here.
No functional change.
Change-Id: Id475f34170682b465e270a0ffa359f8bbd1b641f
Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
dma_heap_find(), dma_heap_buffer_alloc() and dma_heap_bufferfd_alloc() all
have a documented parameter list but no Return: section, so kernel-doc has
nothing to say about what a caller gets back.
Documentation/doc-guide/kernel-doc.rst asks for a Return: section on
functions that return a value, and scripts/kernel-doc -none -Wall
include/linux/dma-heap.h reports three "No description found for return
value" warnings before this change and none after it. The default warning
level is unaffected: the file is clean there both before and after.
The wording follows what the implementations in drivers/dma-buf/dma-heap.c
actually do:
dma_heap_find() returns the heap, or NULL when the name is not
registered
dma_heap_buffer_alloc() returns a dma_buf, or an ERR_PTR() on failure
dma_heap_bufferfd_alloc() returns an fd, or a negative errno on failure
All three helpers are ANDROID-only and do not exist upstream, so there is
nothing to send to mainline for this.
No functional change.
Change-Id: I9b8aa342cdda421af018171ec96f1257d8dbd5bc
Signed-off-by: Hung-Chun Tseng <alan.tseng.cs@gmail.com>
dump_tasks() can be called from NMI context to dump memory status of all
tasks. However, calling from NMI context has safety issues:
1. find_lock_task_mm() acquires task_lock(t) using spin_lock(), which
is not NMI-safe and can deadlock if alloc_lock is held when NMI fires.
2. mem_cgroup_scan_tasks() traverses memcg structures and takes locks
that are not NMI-safe.
Fix these by:
- Using spin_trylock(&t->alloc_lock) in find_lock_task_mm() when in_nmi().
- Returning early if a memcg oom dump is requested in NMI context.
Fixes: 4df28ddcd9 ("ANDROID: mm: export dump_tasks symbol.")
Bug: 538262381
Change-Id: I8b79213015fde74b81427d44f122296c5e0edaf9
Signed-off-by: Mayank Rungta <mrungta@google.com>
MTK_TIMER is selected by ARCH_MEDIATEK. The commit enables
it in order to not alter the core when we enable
CONFIG_ARCH_MEDIATEK in vendor fragment.
It is also not directly settable due to visibility
condition "if COMPILE_TEST" not met thus selecting
it as a hidden config.
The GKI_HIDDEN_MTK_CONFIGS is enabled if ARM64 since
it is only applicable to Mediatek devices.
Bug: 432487220
Bug: 532940853
Bug: 545953895
Change-Id: Iac562e539063a59f3988e87a151251eb7554f964
Signed-off-by: Zyta Szpak <zyta@google.com>
(cherry picked from commit a79d348482)
(cherry picked from commit bcb75c47c8566960be30d9c3cf14f8b5bbf4d49a)
Currently, __alloc_contig_verify_gfp_mask() rejects __GFP_NORETRY because
it is not in the allowed action_mask. This causes cma_alloc() calls that
pass __GFP_NORETRY to fail immediately during mask verification in
alloc_contig_range().
Support __GFP_NORETRY by adding it to the allowed action_mask and
cc_action_mask. Furthermore, adjust the construction of gfp_cc_mask
so that if the caller explicitly requested __GFP_NORETRY, we respect
it and do not force __GFP_RETRY_MAYFAIL, avoiding conflicting retry
directives for the underlying migration/compaction.
This allows cma_alloc() with __GFP_NORETRY to fail quickly when the
range cannot be allocated, rather than retrying heavily or failing
immediately due to invalid GFP flags.
Bug: 519847597
Test: Local build and flash verification
Change-Id: I1bee0b838ac957d08a24358d100d20b8ef7babeb
Signed-off-by: Minchan Kim <minchan@google.com>
Signed-off-by: Henry Dong <donghenry@google.com>
In q2_get_counter(), a new counter entry is added to counter_list
and counter_list_lock is released before proc_create_data() is
invoked. During this window, another thread can locate the counter
in counter_list and increment its reference count via
atomic_inc(&e->ref).
If proc_create_data() subsequently fails, the error handling path
previously called list_del() and kfree() unconditionally, ignoring
the refcount. If another thread acquired a reference in the interim,
this resulted in a Use-After-Free (UAF) condition.
Fix this by using atomic_dec_and_test(&e->ref) under
counter_list_lock when proc_create_data() fails. Only remove from
counter_list and free the memory if the refcount reaches zero. If
another thread holds a reference, set procfs_entry to NULL and
leave the counter intact for the surviving thread.
Fixes: 2e134f75ce91 ("ANDROID: netfilter: xt_quota2: add quota2 from xtables-addons")
Bug: 499166786
Change-Id: I1270d6d94ec0bd6a83858ad053434dae0393b7e3
Signed-off-by: Todd Kjos <tkjos@google.com>
favordynmods prioritizes cgroup writes over reads. Before commit
0568f89d4f ("cgroup: replace global percpu_rwsem with per threadgroup
resem when writing to cgroup.procs") first introduced in the 6.18
kernel, this effectively meant replacing the percpu_rwsem fast path with
a global lock (percpu_rwsem slowpath) for readers to allow speeding up
writers. This forced all fork()s and exit()s globally down the slow
path. After commit 0568f89d4f that is no longer the case, and the
write side of the lock is much more narrow at per-threadgroup scope
instead of global, drastically reducing contention.
So we want to use favordynmods only on kernels that have commit
0568f89d4f. A runtime check for the presence of commit 0568f89d4f is
possible, but awkward and potentially slow depending on how it's done. A
better alternative is to simply enable CONFIG_CGROUP_FAVOR_DYNMODS on
kernels where we know commit 0568f89d4f is present.
Bug: 543503146
Change-Id: I511223793adeab7263635895a467a15258086a23
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Aaron Kling
Venkat Reddy Talla
Mikko Perttunen
Hung-Chun Tseng
Mayank Rungta
Zyta Szpak
Henry Dong
Todd Kjos
T.J. Mercier