- 12 Oct, 2021 7 commits
-
-
arnavpuranik authored
-
arnavpuranik authored
Signed-off-by:arnavpuranik <puranikarnav@gmail.com>
-
* we force gpu to run at max freq during expensive rendering in order to mitigate jank during blur, but no need to do this in battery saver mode
-
Signed-off-by:
NotZeetaa <rodrigo2005contente@gmail.com> Signed-off-by:
-
echo 0 /sys/kernel/fast_charge/force_fast_charge (disable) echo 1 /sys/kernel/fast_charge/force_fast_charge (enable) Enables force charging up to 900mA in usb mode Signed-off-by:
Oktapra Amtono <oktapra.amtono@gmail.com> Signed-off-by:
-
arnavpuranik authored
Signed-off-by: -
Authored: Dennis Rassmann a.k.a showp1984 adapted by savoca at XDA-Developers. original source: https://github.com/showp1984/bricked-hammerhead Signed-off-by:
Ryan Andri <ryanandri@linuxmail.org>
-
- 11 Oct, 2021 17 commits
-
-
arnavpuranik authored
This reverts commit 64915915.
-
@nathanchance: updated to current interactive from this commit: https://github.com/imoseyon/leanKernel-angler/commit/465224c1ed4d9686aaabdb7e176ea70a65ae1295 Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
utsavbalar1231 <utsavbalar1231@gmail.com> Signed-off-by:
ronaxdevil <pratabidya.007@gmail.com> Signed-off-by:
Mayur <ultramayur123@gmail.com>
-
This adds support for compiling the kernel with optimizations offered by LLVM's polyhedral loop optimizer known as Polly, which can improve performance by improving cache locality in loops. Note that LLVM is not compiled with Polly by default -- it must be enabled explicitly. Signed-off-by:Danny Lin <danny@kdrag0n.dev>
-
arnavpuranik authored
Merge tag 'LA.UM.8.2.r2-04900-sdm660.0' of https://source.codeaurora.org/quic/la/kernel/msm-4.4 into serum "LA.UM.8.2.r2-04900-sdm660.0"
-
arnavpuranik authored
Signed-off-by: -
arnavpuranik authored
Signed-off-by: -
It does not make sense to run kgsl on high and devfreq on regular priority. Change-Id: Ie5e6c9353a4e1324a6a49278e5ad3638462f551c Signed-off-by:
flar2 <asegaert@gmail.com> Signed-off-by:
Dusan Uveric <dusan.uveric9@gmail.com>
-
- uses proper data types ref : https://github.com/ronaxdevil/mayhem_kernel_motorola_sanders/commit/d1568c7374b6a17f460f0d8d91b7534c3ba808d4 Signed-off-by:
-
When memory pressure starts to balloon, allocation latency takes a hit as the page allocator continuously tries to find a way to free up some pages. Boosting when this occurs can significantly help reduce allocation latency, preventing noticeable lag from being observed. Signed-off-by:
Sultan Alsawaf <sultan@kerneltoast.com> Signed-off-by:
-
Boosting Devfreq at focus time can help for the focus speed. Let's try it out. 150ms won't affect battery too much as it's especially when you take photo. Original idea form: https://github.com/YaroST12/MATA_Kernel/commit/c011ecb4cdf10e4568dc16a74de38309cde18b04 Signed-off-by:
-
Signed-off-by:
Francisco Franco <franciscofranco.1990@gmail.com> Signed-off-by:
reaPeR1010 <rohan10102002@gmail.com>
-
A single global boolean is enough to say that we don't want to boost anything while the screen is turned off. Signed-off-by:
-
refrence - 791c216e Signed-off-by:
-
This function isn't used anywhere. Remove it. Signed-off-by:
-
Official Linux kernel style mandates function parameter alignment. Also, update the license headers for the new style. Signed-off-by:
-
Speeds up cold app launches. Signed-off-by:
Sultan Alsawaf <sultanxda@gmail.com> Signed-off-by:
-
This driver boosts enumerated devfreq devices upon input, and allows for boosting specific devfreq devices on other custom events. The boost frequencies for this driver should be set so that frame drops are near-zero at the boosted frequencies and power consumption is minimized at said frequencies. The goal of this driver is to provide an interface to achieve optimal device performance by requesting boosts on key events, such as when a frame is ready to rendered to the display. Currently, support is only present for boosting the cpubw devfreq device, but the driver is structured in a way that makes it easy to add support for new boostable devfreq devices in the future. Signed-off-by:
kdrag0n <dragon@khronodragon.com> Signed-off-by:
-
- 09 Oct, 2021 16 commits
-
-
arnavpuranik authored
Merge branch 'linux-4.4.y' of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux into serum Signed-off-by:
-
Signed-off-by: -
-
-
This reverts commit 34c21662.
-
arnavpuranik authored
Signed-off-by: -
arnavpuranik authored
This reverts commit 54d5dc99.
-
Signed-off-by: -
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20211008112713.515980393@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Kate Hsuan authored
commit 7a8526a5cd51cf5f070310c6c37dd7293334ac49 upstream. Many users are reporting that the Samsung 860 and 870 SSD are having various issues when combined with AMD/ATI (vendor ID 0x1002) SATA controllers and only completely disabling NCQ helps to avoid these issues. Always disabling NCQ for Samsung 860/870 SSDs regardless of the host SATA adapter vendor will cause I/O performance degradation with well behaved adapters. To limit the performance impact to ATI adapters, introduce the ATA_HORKAGE_NO_NCQ_ON_ATI flag to force disable NCQ only for these adapters. Also, two libata.force parameters (noncqati and ncqati) are introduced to disable and enable the NCQ for the system which equipped with ATI SATA adapter and Samsung 860 and 870 SSDs. The user can determine NCQ function to be enabled or disabled according to the demand. After verifying the chipset from the user reports, the issue appears on AMD/ATI SB7x0/SB8x0/SB9x0 SATA Controllers and does not appear on recent AMD SATA adapters. The vendor ID of ATI should be 0x1002. Therefore, ATA_HORKAGE_NO_NCQ_ON_AMD was modified to ATA_HORKAGE_NO_NCQ_ON_ATI. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201693 Signed-off-by:
Kate Hsuan <hpa@redhat.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210903094411.58749-1-hpa@redhat.com Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Cc: Krzysztof Olędzki <ole@ans.pl> Signed-off-by:
-
Faizel K B authored
[ Upstream commit f81c08f897adafd2ed43f86f00207ff929f0b2eb ] testusb' application which uses 'usbtest' driver reports 'unknown speed' from the function 'find_testdev'. The variable 'entry->speed' was not updated from the application. The IOCTL mentioned in the FIXME comment can only report whether the connection is low speed or not. Speed is read using the IOCTL USBDEVFS_GET_SPEED which reports the proper speed grade. The call is implemented in the function 'handle_testdev' where the file descriptor was availble locally. Sample output is given below where 'high speed' is printed as the connected speed. sudo ./testusb -a high speed /dev/bus/usb/001/011 0 /dev/bus/usb/001/011 test 0, 0.000015 secs /dev/bus/usb/001/011 test 1, 0.194208 secs /dev/bus/usb/001/011 test 2, 0.077289 secs /dev/bus/usb/001/011 test 3, 0.170604 secs /dev/bus/usb/001/011 test 4, 0.108335 secs /dev/bus/usb/001/011 test 5, 2.788076 secs /dev/bus/usb/001/011 test 6, 2.594610 secs /dev/bus/usb/001/011 test 7, 2.905459 secs /dev/bus/usb/001/011 test 8, 2.795193 secs /dev/bus/usb/001/011 test 9, 8.372651 secs /dev/bus/usb/001/011 test 10, 6.919731 secs /dev/bus/usb/001/011 test 11, 16.372687 secs /dev/bus/usb/001/011 test 12, 16.375233 secs /dev/bus/usb/001/011 test 13, 2.977457 secs /dev/bus/usb/001/011 test 14 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 17, 0.148826 secs /dev/bus/usb/001/011 test 18, 0.068718 secs /dev/bus/usb/001/011 test 19, 0.125992 secs /dev/bus/usb/001/011 test 20, 0.127477 secs /dev/bus/usb/001/011 test 21 --> 22 (Invalid argument) /dev/bus/usb/001/011 test 24, 4.133763 secs /dev/bus/usb/001/011 test 27, 2.140066 secs /dev/bus/usb/001/011 test 28, 2.120713 secs /dev/bus/usb/001/011 test 29, 0.507762 secs Signed-off-by:
Faizel K B <faizel.kb@dicortech.com> Link: https://lore.kernel.org/r/20210902114444.15106-1-faizel.kb@dicortech.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ming Lei authored
[ Upstream commit 265dfe8ebbabae7959060bd1c3f75c2473b697ed ] After a device is initialized via device_initialize() it should be freed via put_device(). sd_probe() currently gets this wrong, fix it up. Link: https://lore.kernel.org/r/20210906090112.531442-1-ming.lei@redhat.com Reviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ming Lei <ming.lei@redhat.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 372d1f3e1bfede719864d0d1fbf3146b1e638c88 ] The ext2_error() function syncs the filesystem so it sleeps. The caller is holding a spinlock so it's not allowed to sleep. ext2_statfs() <- disables preempt -> ext2_count_free_blocks() -> ext2_get_group_desc() Fix this by using WARN() to print an error message and a stack trace instead of using ext2_error(). Link: https://lore.kernel.org/r/20210921203233.GA16529@kili Signed-off-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Linus Torvalds authored
[ Upstream commit d8b1e10a2b8efaf71d151aa756052fbf2f3b6d57 ] Guenter reported [1] that the pci_iounmap() changes remain problematic, with sparc64 allnoconfig and tinyconfig still not building due to the header file changes and confusion with the arch-specific pci_iounmap() implementation. I'm pretty convinced that sparc should just use GENERIC_IOMAP instead of doing its own thing, since it turns out that the sparc64 version of pci_iounmap() is somewhat buggy (see [2]). But in the meantime, this just fixes the build by avoiding the trivial re-definition of the empty case. Link: https://lore.kernel.org/lkml/20210920134424.GA346531@roeck-us.net/ [1] Link: https://lore.kernel.org/lkml/CAHk-=wgheheFx9myQyy5osh79BAazvmvYURAtub2gQtMvLrhqQ@mail.gmail.com/ [2] Reported-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Jan Beulich authored
[ Upstream commit 3ede7f84c7c21f93c5eac611d60eba3f2c765e0f ] When re-entering the main loop of xenvif_tx_check_gop() a 2nd time, the special considerations for the head of the SKB no longer apply. Don't mistakenly report ERROR to the frontend for the first entry in the list, even if - from all I can tell - this shouldn't matter much as the overall transmit will need to be considered failed anyway. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Reviewed-by:
Paul Durrant <paul@xen.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
commit 35306eb23814444bd4021f8a1c3047d3cb0c8b2b upstream. Jann Horn reported that SO_PEERCRED and SO_PEERGROUPS implementations are racy, as af_unix can concurrently change sk_peer_pid and sk_peer_cred. In order to fix this issue, this patch adds a new spinlock that needs to be used whenever these fields are read or written. Jann also pointed out that l2cap_sock_get_peer_pid_cb() is currently reading sk->sk_peer_pid which makes no sense, as this field is only possibly set by AF_UNIX sockets. We will have to clean this in a separate patch. This could be done by reverting b48596d1dc25 "Bluetooth: L2CAP: Add get_peer_pid callback" or implementing what was truly expected. Fixes: 109f6e39 ("af_unix: Allow SO_PEERCRED to work across namespaces.") Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Jann Horn <jannh@google.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Cc: Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
