A-Team_Digital_Solutions/android_kernel_motorola_sm6375
Watch
2
0
Fork
You've already forked android_kernel_motorola_sm6375
 0
mirror of https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git synced 2026-10-11 15:11:48 -04:00
Code Issues Projects Releases Packages Wiki Activity
No description
874,498 commits 10 branches 0 tags 2.1 GiB
  • C 98.2%
  • Assembly 1%
  • Makefile 0.3%
  • Shell 0.2%
  • Python 0.1%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Vivek Gautam 614d15f302 BACKPORT: iommu: arm-smmu-impl: Add sdm845 implementation hook 
Add reset hook for sdm845 based platforms to turn off
the wait-for-safe sequence.

Understanding how wait-for-safe logic affects USB and UFS performance
on MTP845 and DB845 boards:

Qcom's implementation of arm,mmu-500 adds a WAIT-FOR-SAFE logic
to address under-performance issues in real-time clients, such as
Display, and Camera.
On receiving an invalidation requests, the SMMU forwards SAFE request
to these clients and waits for SAFE ack signal from real-time clients.
The SAFE signal from such clients is used to qualify the start of
invalidation.
This logic is controlled by chicken bits, one for each - MDP (display),
IFE0, and IFE1 (camera), that can be accessed only from secure software
on sdm845.

This configuration, however, degrades the performance of non-real time
clients, such as USB, and UFS etc. This happens because, with wait-for-safe
logic enabled the hardware tries to throttle non-real time clients while
waiting for SAFE ack signals from real-time clients.

On mtp845 and db845 devices, with wait-for-safe logic enabled by the
bootloaders we see degraded performance of USB and UFS when kernel
enables the smmu stage-1 translations for these clients.
Turn off this wait-for-safe logic from the kernel gets us back the perf
of USB and UFS devices until we re-visit this when we start seeing perf
issues on display/camera on upstream supported SDM845 platforms.
The bootloaders on these boards implement secure monitor callbacks to
handle a specific command - QCOM_SCM_SVC_SMMU_PROGRAM with which the
logic can be toggled.

There are other boards such as cheza whose bootloaders don't enable this
logic. Such boards don't implement callbacks to handle the specific SCM
call so disabling this logic for such boards will be a no-op.

This change is inspired by the downstream change from Patrick Daly
to address performance issues with display and camera by handling
this wait-for-safe within separte io-pagetable ops to do TLB
maintenance. So a big thanks to him for the change and for all the
offline discussions.

Without this change the UFS reads are pretty slow:
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=10 conv=sync
10+0 records in
10+0 records out
10485760 bytes (10.0MB) copied, 22.394903 seconds, 457.2KB/s
real    0m 22.39s
user    0m 0.00s
sys     0m 0.01s

With this change they are back to rock!
$ time dd if=/dev/sda of=/dev/zero bs=1048576 count=300 conv=sync
300+0 records in
300+0 records out
314572800 bytes (300.0MB) copied, 1.030541 seconds, 291.1MB/s
real    0m 1.03s
user    0m 0.00s
sys     0m 0.54s

Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 759aaa10c76cbaaefc0670410fb2d54cf4ec10cc)
Signed-off-by: John Stultz <john.stultz@linaro.org>
Bug: 146449535
Change-Id: I19992dad55516fa0444c79d7f50363ef57633c97
2019-12-20 09:57:41 -08:00
arch ANDROID: gki_defconfig: Add qcom pcie options to gki_defconfig 2019-12-20 09:57:39 -08:00
block This is the 5.4.4 stable release 2019-12-17 20:10:28 +01:00
certs
crypto crypto: user - fix memory leak in crypto_reportstat 2019-12-13 08:43:11 +01:00
Documentation ANDROID: ASoC: add hikey960-i2s DT bindings 2019-12-18 18:07:51 +00:00
drivers BACKPORT: iommu: arm-smmu-impl: Add sdm845 implementation hook 2019-12-20 09:57:41 -08:00
fs This is the 5.4.4 stable release 2019-12-17 20:10:28 +01:00
include UPSTREAM: firmware/qcom_scm: Add scm call to handle smmu errata 2019-12-20 09:57:41 -08:00
init ANDROID: Kconfig.gki: Add entries for qcom clk drivers 2019-12-20 09:57:38 -08:00
ipc
kernel UPSTREAM: cpufreq: Initialize the governors in core_initcall 2019-12-20 09:57:40 -08:00
lib FROMLIST: vsprintf: Inline call to ptr_to_hashval 2019-12-17 19:53:55 +00:00
LICENSES
mm ANDROID: mm/memory.c: export mm_trace_rss_stat 2019-12-18 18:02:56 +00:00
net This is the 5.4.5 stable release 2019-12-18 16:54:08 +01:00
samples samples/bpf: fix build by setting HAVE_ATTR_TEST to zero 2019-10-31 21:39:15 +01:00
scripts ANDROID: kbuild: merge module sections with LTO 2019-12-10 05:58:01 +00:00
security FROMLIST: Add flags option to get xattr method paired to __vfs_getxattr 2019-11-05 13:50:57 -08:00
sound ANDROID: sound: Add hikey960 i2s audio driver 2019-12-18 18:07:51 +00:00
tools net/tls: Fix return values to avoid ENOTSUPP 2019-12-18 16:08:31 +01:00
usr
virt KVM: arm/arm64: vgic: Don't rely on the wrong pending table 2019-12-13 08:43:00 +01:00
.clang-format
.cocciconfig
.get_maintainer.ignore
.gitattributes
.gitignore Revert "ANDROID: Revert "Merge tag 'modules-for-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux"" 2019-11-13 10:14:45 +00:00
.mailmap ARM: SoC fixes 2019-11-10 13:41:59 -08:00
abi_gki_aarch64.xml ANDROID: gki_defconfig: enable ARM64_SW_TTBR0_PAN 2019-12-19 11:28:48 -08:00
abi_gki_aarch64_whitelist ANDROID: add initial ABI whitelist for android-5.4 2019-12-18 10:56:40 +00:00
build.config.aarch64
build.config.allmodconfig ANDROID: Don't base allmodconfig on gki_defconfig 2019-12-05 13:18:31 +00:00
build.config.allmodconfig.aarch64
build.config.allmodconfig.x86_64
build.config.common ANDROID: clang: update to 10.0.1 2019-11-27 12:49:08 -08:00
build.config.gki
build.config.gki.aarch64 ANDROID: add initial ABI whitelist for android-5.4 2019-12-18 10:56:40 +00:00
build.config.gki.x86_64
build.config.x86_64
COPYING
CREDITS
Kbuild
Kconfig
MAINTAINERS Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 2019-11-22 14:28:14 -08:00
Makefile This is the 5.4.5 stable release 2019-12-18 16:54:08 +01:00
README
README.md ANDROID: Fix typo for FROMLIST: section 2019-10-29 20:31:07 +00:00

README.md

How do I submit patches to Android Common Kernels

  1. BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases. These patches will be merged automatically in the corresponding common kernels. If the patch is already in upstream Linux, post a backport of the patch that conforms to the patch requirements below.

  2. LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are fixing an Android-specific bug, these are very unlikely to be accepted unless they have been coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the patch requirements below.

Common Kernel patch requirements

  • All patches must conform to the Linux kernel coding standards and pass script/checkpatch.pl
  • Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures (see https://source.android.com/setup/build/building-kernels)
  • If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch: UPSTREAM:, BACKPORT:, FROMGIT:, FROMLIST:, or ANDROID:.
  • All patches must have a Change-Id: tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
  • If an Android bug has been assigned, there must be a Bug: tag.
  • All patches must have a Signed-off-by: tag by the author and the submitter

Additional requirements are listed below based on patch type

Requirements for backports from mainline Linux: UPSTREAM:, BACKPORT:

  • If the patch is a cherry-pick from Linux mainline with no changes at all
    • tag the patch subject with UPSTREAM:.
    • add upstream commit information with a (cherry-picked from ...) line
    • Example:
      • if the upstream commit message is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

    - then Joe Smith would upload the patch for the common kernel as

        UPSTREAM: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch requires any changes from the upstream version, tag the patch with BACKPORT: instead of UPSTREAM:.
    • use the same tags as UPSTREAM:
    • add comments about the changes under the (cherry-picked from ...) line
    • Example:
        BACKPORT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        (cherry-picked from c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
        [ Resolved minor conflict in drivers/foo/bar.c ]
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for other backports: FROMGIT:, FROMLIST:,

  • If the patch has been merged into an upstream maintainer tree, but has not yet been merged into Linux mainline
    • tag the patch subject with FROMGIT:
    • add info on where the patch came from as (cherry picked from commit <sha1> <repo> <branch>). This must be a stable maintainer branch (not rebased, so don't use linux-next for example).
    • if changes were required, use BACKPORT: FROMGIT:
    • Example:
      • if the commit message in the maintainer tree is
        important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

    - then Joe Smith would upload the patch for the common kernel as

        FROMGIT: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        (cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
         https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch has been submitted to LKML, but not accepted into any maintainer tree
    • tag the patch subject with FROMLIST:
    • add a Link: tag with a link to the submittal on lore.kernel.org
    • if changes were required, use BACKPORT: FROMLIST:
    • Example:
        FROMLIST: important patch from upstream

        This is the detailed description of the important patch

        Signed-off-by: Fred Jones <fred.jones@foo.org>

        Bug: 135791357
        Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>

Requirements for Android-specific patches: ANDROID:

  • If the patch is fixing a bug to Android-specific code
    • tag the patch subject with ANDROID:
    • add a Fixes: tag that cites the patch with the bug
    • Example:
        ANDROID: fix android-specific bug in foobar.c

        This is the detailed description of the important fix

        Fixes: 1234abcd2468 ("foobar: add cool feature")
        Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
        Signed-off-by: Joe Smith <joe.smith@foo.org>
  • If the patch is a new feature
    • tag the patch subject with ANDROID:
    • add a Bug: tag with the Android bug (required for android-specific features)