Merge branch 'android-msm-8998-4.4-common' into android-msm-wahoo-4.4
Conflicts: Makefile arch/arm64/configs/wahoo_defconfig arch/arm64/include/asm/cpufeature.h arch/arm64/kernel/sleep.S arch/arm64/kernel/vmlinux.lds.S arch/arm64/mm/fault.c drivers/android/binder.c drivers/firmware/efi/arm-init.c drivers/firmware/efi/efi.c drivers/input/keyboard/gpio_keys.c drivers/input/misc/Makefile drivers/input/misc/vl53L0/Makefile drivers/input/misc/vl53L0/inc/vl53l010_api.h drivers/input/misc/vl53L0/inc/vl53l010_device.h drivers/input/misc/vl53L0/inc/vl53l010_strings.h drivers/input/misc/vl53L0/inc/vl53l010_tuning.h drivers/input/misc/vl53L0/inc/vl53l0_api.h drivers/input/misc/vl53L0/inc/vl53l0_api_calibration.h drivers/input/misc/vl53L0/inc/vl53l0_api_core.h drivers/input/misc/vl53L0/inc/vl53l0_api_histogram.h drivers/input/misc/vl53L0/inc/vl53l0_api_ranging.h drivers/input/misc/vl53L0/inc/vl53l0_api_strings.h drivers/input/misc/vl53L0/inc/vl53l0_def.h drivers/input/misc/vl53L0/inc/vl53l0_device.h drivers/input/misc/vl53L0/inc/vl53l0_interrupt_threshold_settings.h drivers/input/misc/vl53L0/inc/vl53l0_platform.h drivers/input/misc/vl53L0/inc/vl53l0_platform_log.h drivers/input/misc/vl53L0/inc/vl53l0_tuning.h drivers/input/misc/vl53L0/inc/vl53l0_types.h drivers/input/misc/vl53L0/src/vl53l010_api.c drivers/input/misc/vl53L0/src/vl53l010_tuning.c drivers/input/misc/vl53L0/src/vl53l0_api.c drivers/input/misc/vl53L0/src/vl53l0_api_calibration.c drivers/input/misc/vl53L0/src/vl53l0_api_core.c drivers/input/misc/vl53L0/src/vl53l0_api_histogram.c drivers/input/misc/vl53L0/src/vl53l0_api_ranging.c drivers/input/misc/vl53L0/src/vl53l0_api_strings.c drivers/input/misc/vl53L0/src/vl53l0_i2c_platform.c drivers/input/misc/vl53L0/src/vl53l0_platform.c drivers/input/misc/vl53L0/src/vl53l0_port_i2c.c drivers/input/misc/vl53L0/stmvl53l0-cci.h drivers/input/misc/vl53L0/stmvl53l0-i2c.h drivers/input/misc/vl53L0/stmvl53l0.h drivers/input/misc/vl53L0/stmvl53l0_module-cci.c drivers/input/misc/vl53L0/stmvl53l0_module-i2c.c drivers/input/misc/vl53L0/stmvl53l0_module.c drivers/input/touchscreen/Makefile drivers/leds/leds-qpnp.c drivers/media/platform/msm/camera_v2/isp/msm_isp_stats_util.c drivers/media/platform/msm/camera_v2/msm.c drivers/pinctrl/qcom/pinctrl-msm.c drivers/platform/msm/ipa/ipa_v3/ipa_client.c drivers/platform/msm/mhi/mhi_ssr.c drivers/power/supply/qcom/qpnp-smb2.c drivers/power/supply/qcom/smb-lib.c drivers/power/supply/qcom/smb-lib.h drivers/soc/qcom/icnss.c drivers/soc/qcom/qdsp6v2/audio_notifier.c drivers/soc/qcom/service-notifier.c drivers/video/fbdev/msm/mdss_panel.h fs/exec.c fs/ext4/inode.c fs/ext4/readpage.c fs/namei.c fs/sdcardfs/derived_perm.c fs/sdcardfs/file.c fs/sdcardfs/inode.c fs/sdcardfs/lookup.c fs/sdcardfs/main.c fs/sdcardfs/multiuser.h fs/sdcardfs/packagelist.c fs/sdcardfs/sdcardfs.h fs/sdcardfs/super.c fs/utimes.c include/linux/string.h lib/kstrtox.c lib/string.c net/ipv4/tcp_ipv4.c net/unix/af_unix.c sound/soc/codecs/wcd934x/wcd934x-mbhc.h sound/soc/msm/msm8998.c Change-Id: I918ebad22a5f81d48be07bd2bc2ac435ed9acb0a Signed-off-by: Thierry Strudel <tstrudel@google.com>
This commit is contained in:
Thierry Strudel
@@ -132,6 +132,11 @@ DMA_ATTR_FORCE_COHERENT
|
||||
|
||||
When passed to a DMA map call the DMA_ATTR_FORCE_COHERENT DMA
|
||||
attribute can be used to force a buffer to be mapped as IO coherent.
|
||||
|
||||
When the DMA_ATTR_FORCE_COHERENT attribute is set during a map call ensure
|
||||
that it is also set during for the matching unmap call to ensure that the
|
||||
correct cache maintenance is carried out.
|
||||
|
||||
This DMA attribute is only currently supported for arm64 stage 1 IOMMU
|
||||
mappings.
|
||||
|
||||
@@ -143,5 +148,9 @@ coherent.
|
||||
The DMA_ATTR_FORCE_NON_COHERENT DMA attribute overrides the buffer IO
|
||||
coherency configuration set by making the device IO coherent.
|
||||
|
||||
When the DMA_ATTR_FORCE_NON_COHERENT attribute is set during a map call
|
||||
ensure that it is also set during for the matching unmap call to ensure
|
||||
that the correct cache maintenance is carried out.
|
||||
|
||||
This DMA attribute is only currently supported for arm64 stage 1 IOMMU
|
||||
mappings.
|
||||
|
||||
@@ -137,6 +137,7 @@
|
||||
!Finclude/net/cfg80211.h cfg80211_ibss_joined
|
||||
!Finclude/net/cfg80211.h cfg80211_connect_result
|
||||
!Finclude/net/cfg80211.h cfg80211_connect_bss
|
||||
!Finclude/net/cfg80211.h cfg80211_connect_timeout
|
||||
!Finclude/net/cfg80211.h cfg80211_roamed
|
||||
!Finclude/net/cfg80211.h cfg80211_disconnected
|
||||
!Finclude/net/cfg80211.h cfg80211_ready_on_channel
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
subdir-y := accounting auxdisplay blackfin connector \
|
||||
filesystems filesystems ia64 laptops mic misc-devices \
|
||||
filesystems filesystems ia64 laptops misc-devices \
|
||||
networking pcmcia prctl ptp spi timers vDSO video4linux \
|
||||
watchdog
|
||||
|
||||
@@ -374,82 +374,3 @@ One can experience an overall throughput drop if you have created multiple
|
||||
groups and put applications in that group which are not driving enough
|
||||
IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle
|
||||
on individual groups and throughput should improve.
|
||||
|
||||
Writeback
|
||||
=========
|
||||
|
||||
Page cache is dirtied through buffered writes and shared mmaps and
|
||||
written asynchronously to the backing filesystem by the writeback
|
||||
mechanism. Writeback sits between the memory and IO domains and
|
||||
regulates the proportion of dirty memory by balancing dirtying and
|
||||
write IOs.
|
||||
|
||||
On traditional cgroup hierarchies, relationships between different
|
||||
controllers cannot be established making it impossible for writeback
|
||||
to operate accounting for cgroup resource restrictions and all
|
||||
writeback IOs are attributed to the root cgroup.
|
||||
|
||||
If both the blkio and memory controllers are used on the v2 hierarchy
|
||||
and the filesystem supports cgroup writeback, writeback operations
|
||||
correctly follow the resource restrictions imposed by both memory and
|
||||
blkio controllers.
|
||||
|
||||
Writeback examines both system-wide and per-cgroup dirty memory status
|
||||
and enforces the more restrictive of the two. Also, writeback control
|
||||
parameters which are absolute values - vm.dirty_bytes and
|
||||
vm.dirty_background_bytes - are distributed across cgroups according
|
||||
to their current writeback bandwidth.
|
||||
|
||||
There's a peculiarity stemming from the discrepancy in ownership
|
||||
granularity between memory controller and writeback. While memory
|
||||
controller tracks ownership per page, writeback operates on inode
|
||||
basis. cgroup writeback bridges the gap by tracking ownership by
|
||||
inode but migrating ownership if too many foreign pages, pages which
|
||||
don't match the current inode ownership, have been encountered while
|
||||
writing back the inode.
|
||||
|
||||
This is a conscious design choice as writeback operations are
|
||||
inherently tied to inodes making strictly following page ownership
|
||||
complicated and inefficient. The only use case which suffers from
|
||||
this compromise is multiple cgroups concurrently dirtying disjoint
|
||||
regions of the same inode, which is an unlikely use case and decided
|
||||
to be unsupported. Note that as memory controller assigns page
|
||||
ownership on the first use and doesn't update it until the page is
|
||||
released, even if cgroup writeback strictly follows page ownership,
|
||||
multiple cgroups dirtying overlapping areas wouldn't work as expected.
|
||||
In general, write-sharing an inode across multiple cgroups is not well
|
||||
supported.
|
||||
|
||||
Filesystem support for cgroup writeback
|
||||
---------------------------------------
|
||||
|
||||
A filesystem can make writeback IOs cgroup-aware by updating
|
||||
address_space_operations->writepage[s]() to annotate bio's using the
|
||||
following two functions.
|
||||
|
||||
* wbc_init_bio(@wbc, @bio)
|
||||
|
||||
Should be called for each bio carrying writeback data and associates
|
||||
the bio with the inode's owner cgroup. Can be called anytime
|
||||
between bio allocation and submission.
|
||||
|
||||
* wbc_account_io(@wbc, @page, @bytes)
|
||||
|
||||
Should be called for each data segment being written out. While
|
||||
this function doesn't care exactly when it's called during the
|
||||
writeback session, it's the easiest and most natural to call it as
|
||||
data segments are added to a bio.
|
||||
|
||||
With writeback bio's annotated, cgroup support can be enabled per
|
||||
super_block by setting MS_CGROUPWB in ->s_flags. This allows for
|
||||
selective disabling of cgroup writeback support which is helpful when
|
||||
certain filesystem features, e.g. journaled data mode, are
|
||||
incompatible.
|
||||
|
||||
wbc_init_bio() binds the specified bio to its cgroup. Depending on
|
||||
the configuration, the bio may be executed at a lower priority and if
|
||||
the writeback session is holding shared resources, e.g. a journal
|
||||
entry, may lead to priority inversion. There is no one easy solution
|
||||
for the problem. Filesystems can try to work around specific problem
|
||||
cases by skipping wbc_init_bio() or using bio_associate_blkcg()
|
||||
directly.
|
||||
@@ -578,15 +578,6 @@ is completely unused; @cgrp->parent is still valid. (Note - can also
|
||||
be called for a newly-created cgroup if an error occurs after this
|
||||
subsystem's create() method has been called for the new cgroup).
|
||||
|
||||
int allow_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
Called prior to moving a task into a cgroup; if the subsystem
|
||||
returns an error, this will abort the attach operation. Used
|
||||
to extend the permission checks - if all subsystems in a cgroup
|
||||
return 0, the attach will be allowed to proceed, even if the
|
||||
default permission check (root or same user) fails.
|
||||
|
||||
int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
|
||||
(cgroup_mutex held by caller)
|
||||
|
||||
1293
Documentation/cgroup.txt
Normal file
1293
Documentation/cgroup.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -1,647 +0,0 @@
|
||||
|
||||
Cgroup unified hierarchy
|
||||
|
||||
April, 2014 Tejun Heo <tj@kernel.org>
|
||||
|
||||
This document describes the changes made by unified hierarchy and
|
||||
their rationales. It will eventually be merged into the main cgroup
|
||||
documentation.
|
||||
|
||||
CONTENTS
|
||||
|
||||
1. Background
|
||||
2. Basic Operation
|
||||
2-1. Mounting
|
||||
2-2. cgroup.subtree_control
|
||||
2-3. cgroup.controllers
|
||||
3. Structural Constraints
|
||||
3-1. Top-down
|
||||
3-2. No internal tasks
|
||||
4. Delegation
|
||||
4-1. Model of delegation
|
||||
4-2. Common ancestor rule
|
||||
5. Other Changes
|
||||
5-1. [Un]populated Notification
|
||||
5-2. Other Core Changes
|
||||
5-3. Controller File Conventions
|
||||
5-3-1. Format
|
||||
5-3-2. Control Knobs
|
||||
5-4. Per-Controller Changes
|
||||
5-4-1. io
|
||||
5-4-2. cpuset
|
||||
5-4-3. memory
|
||||
6. Planned Changes
|
||||
6-1. CAP for resource control
|
||||
|
||||
|
||||
1. Background
|
||||
|
||||
cgroup allows an arbitrary number of hierarchies and each hierarchy
|
||||
can host any number of controllers. While this seems to provide a
|
||||
high level of flexibility, it isn't quite useful in practice.
|
||||
|
||||
For example, as there is only one instance of each controller, utility
|
||||
type controllers such as freezer which can be useful in all
|
||||
hierarchies can only be used in one. The issue is exacerbated by the
|
||||
fact that controllers can't be moved around once hierarchies are
|
||||
populated. Another issue is that all controllers bound to a hierarchy
|
||||
are forced to have exactly the same view of the hierarchy. It isn't
|
||||
possible to vary the granularity depending on the specific controller.
|
||||
|
||||
In practice, these issues heavily limit which controllers can be put
|
||||
on the same hierarchy and most configurations resort to putting each
|
||||
controller on its own hierarchy. Only closely related ones, such as
|
||||
the cpu and cpuacct controllers, make sense to put on the same
|
||||
hierarchy. This often means that userland ends up managing multiple
|
||||
similar hierarchies repeating the same steps on each hierarchy
|
||||
whenever a hierarchy management operation is necessary.
|
||||
|
||||
Unfortunately, support for multiple hierarchies comes at a steep cost.
|
||||
Internal implementation in cgroup core proper is dazzlingly
|
||||
complicated but more importantly the support for multiple hierarchies
|
||||
restricts how cgroup is used in general and what controllers can do.
|
||||
|
||||
There's no limit on how many hierarchies there may be, which means
|
||||
that a task's cgroup membership can't be described in finite length.
|
||||
The key may contain any varying number of entries and is unlimited in
|
||||
length, which makes it highly awkward to handle and leads to addition
|
||||
of controllers which exist only to identify membership, which in turn
|
||||
exacerbates the original problem.
|
||||
|
||||
Also, as a controller can't have any expectation regarding what shape
|
||||
of hierarchies other controllers would be on, each controller has to
|
||||
assume that all other controllers are operating on completely
|
||||
orthogonal hierarchies. This makes it impossible, or at least very
|
||||
cumbersome, for controllers to cooperate with each other.
|
||||
|
||||
In most use cases, putting controllers on hierarchies which are
|
||||
completely orthogonal to each other isn't necessary. What usually is
|
||||
called for is the ability to have differing levels of granularity
|
||||
depending on the specific controller. In other words, hierarchy may
|
||||
be collapsed from leaf towards root when viewed from specific
|
||||
controllers. For example, a given configuration might not care about
|
||||
how memory is distributed beyond a certain level while still wanting
|
||||
to control how CPU cycles are distributed.
|
||||
|
||||
Unified hierarchy is the next version of cgroup interface. It aims to
|
||||
address the aforementioned issues by having more structure while
|
||||
retaining enough flexibility for most use cases. Various other
|
||||
general and controller-specific interface issues are also addressed in
|
||||
the process.
|
||||
|
||||
|
||||
2. Basic Operation
|
||||
|
||||
2-1. Mounting
|
||||
|
||||
Currently, unified hierarchy can be mounted with the following mount
|
||||
command. Note that this is still under development and scheduled to
|
||||
change soon.
|
||||
|
||||
mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
|
||||
|
||||
All controllers which support the unified hierarchy and are not bound
|
||||
to other hierarchies are automatically bound to unified hierarchy and
|
||||
show up at the root of it. Controllers which are enabled only in the
|
||||
root of unified hierarchy can be bound to other hierarchies. This
|
||||
allows mixing unified hierarchy with the traditional multiple
|
||||
hierarchies in a fully backward compatible way.
|
||||
|
||||
A controller can be moved across hierarchies only after the controller
|
||||
is no longer referenced in its current hierarchy. Because per-cgroup
|
||||
controller states are destroyed asynchronously and controllers may
|
||||
have lingering references, a controller may not show up immediately on
|
||||
the unified hierarchy after the final umount of the previous
|
||||
hierarchy. Similarly, a controller should be fully disabled to be
|
||||
moved out of the unified hierarchy and it may take some time for the
|
||||
disabled controller to become available for other hierarchies;
|
||||
furthermore, due to dependencies among controllers, other controllers
|
||||
may need to be disabled too.
|
||||
|
||||
While useful for development and manual configurations, dynamically
|
||||
moving controllers between the unified and other hierarchies is
|
||||
strongly discouraged for production use. It is recommended to decide
|
||||
the hierarchies and controller associations before starting using the
|
||||
controllers.
|
||||
|
||||
|
||||
2-2. cgroup.subtree_control
|
||||
|
||||
All cgroups on unified hierarchy have a "cgroup.subtree_control" file
|
||||
which governs which controllers are enabled on the children of the
|
||||
cgroup. Let's assume a hierarchy like the following.
|
||||
|
||||
root - A - B - C
|
||||
\ D
|
||||
|
||||
root's "cgroup.subtree_control" file determines which controllers are
|
||||
enabled on A. A's on B. B's on C and D. This coincides with the
|
||||
fact that controllers on the immediate sub-level are used to
|
||||
distribute the resources of the parent. In fact, it's natural to
|
||||
assume that resource control knobs of a child belong to its parent.
|
||||
Enabling a controller in a "cgroup.subtree_control" file declares that
|
||||
distribution of the respective resources of the cgroup will be
|
||||
controlled. Note that this means that controller enable states are
|
||||
shared among siblings.
|
||||
|
||||
When read, the file contains a space-separated list of currently
|
||||
enabled controllers. A write to the file should contain a
|
||||
space-separated list of controllers with '+' or '-' prefixed (without
|
||||
the quotes). Controllers prefixed with '+' are enabled and '-'
|
||||
disabled. If a controller is listed multiple times, the last entry
|
||||
wins. The specific operations are executed atomically - either all
|
||||
succeed or fail.
|
||||
|
||||
|
||||
2-3. cgroup.controllers
|
||||
|
||||
Read-only "cgroup.controllers" file contains a space-separated list of
|
||||
controllers which can be enabled in the cgroup's
|
||||
"cgroup.subtree_control" file.
|
||||
|
||||
In the root cgroup, this lists controllers which are not bound to
|
||||
other hierarchies and the content changes as controllers are bound to
|
||||
and unbound from other hierarchies.
|
||||
|
||||
In non-root cgroups, the content of this file equals that of the
|
||||
parent's "cgroup.subtree_control" file as only controllers enabled
|
||||
from the parent can be used in its children.
|
||||
|
||||
|
||||
3. Structural Constraints
|
||||
|
||||
3-1. Top-down
|
||||
|
||||
As it doesn't make sense to nest control of an uncontrolled resource,
|
||||
all non-root "cgroup.subtree_control" files can only contain
|
||||
controllers which are enabled in the parent's "cgroup.subtree_control"
|
||||
file. A controller can be enabled only if the parent has the
|
||||
controller enabled and a controller can't be disabled if one or more
|
||||
children have it enabled.
|
||||
|
||||
|
||||
3-2. No internal tasks
|
||||
|
||||
One long-standing issue that cgroup faces is the competition between
|
||||
tasks belonging to the parent cgroup and its children cgroups. This
|
||||
is inherently nasty as two different types of entities compete and
|
||||
there is no agreed-upon obvious way to handle it. Different
|
||||
controllers are doing different things.
|
||||
|
||||
The cpu controller considers tasks and cgroups as equivalents and maps
|
||||
nice levels to cgroup weights. This works for some cases but falls
|
||||
flat when children should be allocated specific ratios of CPU cycles
|
||||
and the number of internal tasks fluctuates - the ratios constantly
|
||||
change as the number of competing entities fluctuates. There also are
|
||||
other issues. The mapping from nice level to weight isn't obvious or
|
||||
universal, and there are various other knobs which simply aren't
|
||||
available for tasks.
|
||||
|
||||
The io controller implicitly creates a hidden leaf node for each
|
||||
cgroup to host the tasks. The hidden leaf has its own copies of all
|
||||
the knobs with "leaf_" prefixed. While this allows equivalent control
|
||||
over internal tasks, it's with serious drawbacks. It always adds an
|
||||
extra layer of nesting which may not be necessary, makes the interface
|
||||
messy and significantly complicates the implementation.
|
||||
|
||||
The memory controller currently doesn't have a way to control what
|
||||
happens between internal tasks and child cgroups and the behavior is
|
||||
not clearly defined. There have been attempts to add ad-hoc behaviors
|
||||
and knobs to tailor the behavior to specific workloads. Continuing
|
||||
this direction will lead to problems which will be extremely difficult
|
||||
to resolve in the long term.
|
||||
|
||||
Multiple controllers struggle with internal tasks and came up with
|
||||
different ways to deal with it; unfortunately, all the approaches in
|
||||
use now are severely flawed and, furthermore, the widely different
|
||||
behaviors make cgroup as whole highly inconsistent.
|
||||
|
||||
It is clear that this is something which needs to be addressed from
|
||||
cgroup core proper in a uniform way so that controllers don't need to
|
||||
worry about it and cgroup as a whole shows a consistent and logical
|
||||
behavior. To achieve that, unified hierarchy enforces the following
|
||||
structural constraint:
|
||||
|
||||
Except for the root, only cgroups which don't contain any task may
|
||||
have controllers enabled in their "cgroup.subtree_control" files.
|
||||
|
||||
Combined with other properties, this guarantees that, when a
|
||||
controller is looking at the part of the hierarchy which has it
|
||||
enabled, tasks are always only on the leaves. This rules out
|
||||
situations where child cgroups compete against internal tasks of the
|
||||
parent.
|
||||
|
||||
There are two things to note. Firstly, the root cgroup is exempt from
|
||||
the restriction. Root contains tasks and anonymous resource
|
||||
consumption which can't be associated with any other cgroup and
|
||||
requires special treatment from most controllers. How resource
|
||||
consumption in the root cgroup is governed is up to each controller.
|
||||
|
||||
Secondly, the restriction doesn't take effect if there is no enabled
|
||||
controller in the cgroup's "cgroup.subtree_control" file. This is
|
||||
important as otherwise it wouldn't be possible to create children of a
|
||||
populated cgroup. To control resource distribution of a cgroup, the
|
||||
cgroup must create children and transfer all its tasks to the children
|
||||
before enabling controllers in its "cgroup.subtree_control" file.
|
||||
|
||||
|
||||
4. Delegation
|
||||
|
||||
4-1. Model of delegation
|
||||
|
||||
A cgroup can be delegated to a less privileged user by granting write
|
||||
access of the directory and its "cgroup.procs" file to the user. Note
|
||||
that the resource control knobs in a given directory concern the
|
||||
resources of the parent and thus must not be delegated along with the
|
||||
directory.
|
||||
|
||||
Once delegated, the user can build sub-hierarchy under the directory,
|
||||
organize processes as it sees fit and further distribute the resources
|
||||
it got from the parent. The limits and other settings of all resource
|
||||
controllers are hierarchical and regardless of what happens in the
|
||||
delegated sub-hierarchy, nothing can escape the resource restrictions
|
||||
imposed by the parent.
|
||||
|
||||
Currently, cgroup doesn't impose any restrictions on the number of
|
||||
cgroups in or nesting depth of a delegated sub-hierarchy; however,
|
||||
this may in the future be limited explicitly.
|
||||
|
||||
|
||||
4-2. Common ancestor rule
|
||||
|
||||
On the unified hierarchy, to write to a "cgroup.procs" file, in
|
||||
addition to the usual write permission to the file and uid match, the
|
||||
writer must also have write access to the "cgroup.procs" file of the
|
||||
common ancestor of the source and destination cgroups. This prevents
|
||||
delegatees from smuggling processes across disjoint sub-hierarchies.
|
||||
|
||||
Let's say cgroups C0 and C1 have been delegated to user U0 who created
|
||||
C00, C01 under C0 and C10 under C1 as follows.
|
||||
|
||||
~~~~~~~~~~~~~ - C0 - C00
|
||||
~ cgroup ~ \ C01
|
||||
~ hierarchy ~
|
||||
~~~~~~~~~~~~~ - C1 - C10
|
||||
|
||||
C0 and C1 are separate entities in terms of resource distribution
|
||||
regardless of their relative positions in the hierarchy. The
|
||||
resources the processes under C0 are entitled to are controlled by
|
||||
C0's ancestors and may be completely different from C1. It's clear
|
||||
that the intention of delegating C0 to U0 is allowing U0 to organize
|
||||
the processes under C0 and further control the distribution of C0's
|
||||
resources.
|
||||
|
||||
On traditional hierarchies, if a task has write access to "tasks" or
|
||||
"cgroup.procs" file of a cgroup and its uid agrees with the target, it
|
||||
can move the target to the cgroup. In the above example, U0 will not
|
||||
only be able to move processes in each sub-hierarchy but also across
|
||||
the two sub-hierarchies, effectively allowing it to violate the
|
||||
organizational and resource restrictions implied by the hierarchical
|
||||
structure above C0 and C1.
|
||||
|
||||
On the unified hierarchy, let's say U0 wants to write the pid of a
|
||||
process which has a matching uid and is currently in C10 into
|
||||
"C00/cgroup.procs". U0 obviously has write access to the file and
|
||||
migration permission on the process; however, the common ancestor of
|
||||
the source cgroup C10 and the destination cgroup C00 is above the
|
||||
points of delegation and U0 would not have write access to its
|
||||
"cgroup.procs" and thus be denied with -EACCES.
|
||||
|
||||
|
||||
5. Other Changes
|
||||
|
||||
5-1. [Un]populated Notification
|
||||
|
||||
cgroup users often need a way to determine when a cgroup's
|
||||
subhierarchy becomes empty so that it can be cleaned up. cgroup
|
||||
currently provides release_agent for it; unfortunately, this mechanism
|
||||
is riddled with issues.
|
||||
|
||||
- It delivers events by forking and execing a userland binary
|
||||
specified as the release_agent. This is a long deprecated method of
|
||||
notification delivery. It's extremely heavy, slow and cumbersome to
|
||||
integrate with larger infrastructure.
|
||||
|
||||
- There is single monitoring point at the root. There's no way to
|
||||
delegate management of a subtree.
|
||||
|
||||
- The event isn't recursive. It triggers when a cgroup doesn't have
|
||||
any tasks or child cgroups. Events for internal nodes trigger only
|
||||
after all children are removed. This again makes it impossible to
|
||||
delegate management of a subtree.
|
||||
|
||||
- Events are filtered from the kernel side. A "notify_on_release"
|
||||
file is used to subscribe to or suppress release events. This is
|
||||
unnecessarily complicated and probably done this way because event
|
||||
delivery itself was expensive.
|
||||
|
||||
Unified hierarchy implements "populated" field in "cgroup.events"
|
||||
interface file which can be used to monitor whether the cgroup's
|
||||
subhierarchy has tasks in it or not. Its value is 0 if there is no
|
||||
task in the cgroup and its descendants; otherwise, 1. poll and
|
||||
[id]notify events are triggered when the value changes.
|
||||
|
||||
This is significantly lighter and simpler and trivially allows
|
||||
delegating management of subhierarchy - subhierarchy monitoring can
|
||||
block further propagation simply by putting itself or another process
|
||||
in the subhierarchy and monitor events that it's interested in from
|
||||
there without interfering with monitoring higher in the tree.
|
||||
|
||||
In unified hierarchy, the release_agent mechanism is no longer
|
||||
supported and the interface files "release_agent" and
|
||||
"notify_on_release" do not exist.
|
||||
|
||||
|
||||
5-2. Other Core Changes
|
||||
|
||||
- None of the mount options is allowed.
|
||||
|
||||
- remount is disallowed.
|
||||
|
||||
- rename(2) is disallowed.
|
||||
|
||||
- The "tasks" file is removed. Everything should at process
|
||||
granularity. Use the "cgroup.procs" file instead.
|
||||
|
||||
- The "cgroup.procs" file is not sorted. pids will be unique unless
|
||||
they got recycled in-between reads.
|
||||
|
||||
- The "cgroup.clone_children" file is removed.
|
||||
|
||||
- /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged
|
||||
to before exiting. If the cgroup is removed before the zombie is
|
||||
reaped, " (deleted)" is appeneded to the path.
|
||||
|
||||
|
||||
5-3. Controller File Conventions
|
||||
|
||||
5-3-1. Format
|
||||
|
||||
In general, all controller files should be in one of the following
|
||||
formats whenever possible.
|
||||
|
||||
- Values only files
|
||||
|
||||
VAL0 VAL1...\n
|
||||
|
||||
- Flat keyed files
|
||||
|
||||
KEY0 VAL0\n
|
||||
KEY1 VAL1\n
|
||||
...
|
||||
|
||||
- Nested keyed files
|
||||
|
||||
KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01...
|
||||
KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11...
|
||||
...
|
||||
|
||||
For a writeable file, the format for writing should generally match
|
||||
reading; however, controllers may allow omitting later fields or
|
||||
implement restricted shortcuts for most common use cases.
|
||||
|
||||
For both flat and nested keyed files, only the values for a single key
|
||||
can be written at a time. For nested keyed files, the sub key pairs
|
||||
may be specified in any order and not all pairs have to be specified.
|
||||
|
||||
|
||||
5-3-2. Control Knobs
|
||||
|
||||
- Settings for a single feature should generally be implemented in a
|
||||
single file.
|
||||
|
||||
- In general, the root cgroup should be exempt from resource control
|
||||
and thus shouldn't have resource control knobs.
|
||||
|
||||
- If a controller implements ratio based resource distribution, the
|
||||
control knob should be named "weight" and have the range [1, 10000]
|
||||
and 100 should be the default value. The values are chosen to allow
|
||||
enough and symmetric bias in both directions while keeping it
|
||||
intuitive (the default is 100%).
|
||||
|
||||
- If a controller implements an absolute resource guarantee and/or
|
||||
limit, the control knobs should be named "min" and "max"
|
||||
respectively. If a controller implements best effort resource
|
||||
gurantee and/or limit, the control knobs should be named "low" and
|
||||
"high" respectively.
|
||||
|
||||
In the above four control files, the special token "max" should be
|
||||
used to represent upward infinity for both reading and writing.
|
||||
|
||||
- If a setting has configurable default value and specific overrides,
|
||||
the default settings should be keyed with "default" and appear as
|
||||
the first entry in the file. Specific entries can use "default" as
|
||||
its value to indicate inheritance of the default value.
|
||||
|
||||
- For events which are not very high frequency, an interface file
|
||||
"events" should be created which lists event key value pairs.
|
||||
Whenever a notifiable event happens, file modified event should be
|
||||
generated on the file.
|
||||
|
||||
|
||||
5-4. Per-Controller Changes
|
||||
|
||||
5-4-1. io
|
||||
|
||||
- blkio is renamed to io. The interface is overhauled anyway. The
|
||||
new name is more in line with the other two major controllers, cpu
|
||||
and memory, and better suited given that it may be used for cgroup
|
||||
writeback without involving block layer.
|
||||
|
||||
- Everything including stat is always hierarchical making separate
|
||||
recursive stat files pointless and, as no internal node can have
|
||||
tasks, leaf weights are meaningless. The operation model is
|
||||
simplified and the interface is overhauled accordingly.
|
||||
|
||||
io.stat
|
||||
|
||||
The stat file. The reported stats are from the point where
|
||||
bio's are issued to request_queue. The stats are counted
|
||||
independent of which policies are enabled. Each line in the
|
||||
file follows the following format. More fields may later be
|
||||
added at the end.
|
||||
|
||||
$MAJ:$MIN rbytes=$RBYTES wbytes=$WBYTES rios=$RIOS wrios=$WIOS
|
||||
|
||||
io.weight
|
||||
|
||||
The weight setting, currently only available and effective if
|
||||
cfq-iosched is in use for the target device. The weight is
|
||||
between 1 and 10000 and defaults to 100. The first line
|
||||
always contains the default weight in the following format to
|
||||
use when per-device setting is missing.
|
||||
|
||||
default $WEIGHT
|
||||
|
||||
Subsequent lines list per-device weights of the following
|
||||
format.
|
||||
|
||||
$MAJ:$MIN $WEIGHT
|
||||
|
||||
Writing "$WEIGHT" or "default $WEIGHT" changes the default
|
||||
setting. Writing "$MAJ:$MIN $WEIGHT" sets per-device weight
|
||||
while "$MAJ:$MIN default" clears it.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
io.max
|
||||
|
||||
The maximum bandwidth and/or iops setting, only available if
|
||||
blk-throttle is enabled. The file is of the following format.
|
||||
|
||||
$MAJ:$MIN rbps=$RBPS wbps=$WBPS riops=$RIOPS wiops=$WIOPS
|
||||
|
||||
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
|
||||
read/write IOs per second. "max" indicates no limit. Writing
|
||||
to the file follows the same format but the individual
|
||||
settings may be omitted or specified in any order.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
|
||||
5-4-2. cpuset
|
||||
|
||||
- Tasks are kept in empty cpusets after hotplug and take on the masks
|
||||
of the nearest non-empty ancestor, instead of being moved to it.
|
||||
|
||||
- A task can be moved into an empty cpuset, and again it takes on the
|
||||
masks of the nearest non-empty ancestor.
|
||||
|
||||
|
||||
5-4-3. memory
|
||||
|
||||
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||
not created.
|
||||
|
||||
- The original lower boundary, the soft limit, is defined as a limit
|
||||
that is per default unset. As a result, the set of cgroups that
|
||||
global reclaim prefers is opt-in, rather than opt-out. The costs
|
||||
for optimizing these mostly negative lookups are so high that the
|
||||
implementation, despite its enormous size, does not even provide the
|
||||
basic desirable behavior. First off, the soft limit has no
|
||||
hierarchical meaning. All configured groups are organized in a
|
||||
global rbtree and treated like equal peers, regardless where they
|
||||
are located in the hierarchy. This makes subtree delegation
|
||||
impossible. Second, the soft limit reclaim pass is so aggressive
|
||||
that it not just introduces high allocation latencies into the
|
||||
system, but also impacts system performance due to overreclaim, to
|
||||
the point where the feature becomes self-defeating.
|
||||
|
||||
The memory.low boundary on the other hand is a top-down allocated
|
||||
reserve. A cgroup enjoys reclaim protection when it and all its
|
||||
ancestors are below their low boundaries, which makes delegation of
|
||||
subtrees possible. Secondly, new cgroups have no reserve per
|
||||
default and in the common case most cgroups are eligible for the
|
||||
preferred reclaim pass. This allows the new low boundary to be
|
||||
efficiently implemented with just a minor addition to the generic
|
||||
reclaim code, without the need for out-of-band data structures and
|
||||
reclaim passes. Because the generic reclaim code considers all
|
||||
cgroups except for the ones running low in the preferred first
|
||||
reclaim pass, overreclaim of individual groups is eliminated as
|
||||
well, resulting in much better overall workload performance.
|
||||
|
||||
- The original high boundary, the hard limit, is defined as a strict
|
||||
limit that can not budge, even if the OOM killer has to be called.
|
||||
But this generally goes against the goal of making the most out of
|
||||
the available memory. The memory consumption of workloads varies
|
||||
during runtime, and that requires users to overcommit. But doing
|
||||
that with a strict upper limit requires either a fairly accurate
|
||||
prediction of the working set size or adding slack to the limit.
|
||||
Since working set size estimation is hard and error prone, and
|
||||
getting it wrong results in OOM kills, most users tend to err on the
|
||||
side of a looser limit and end up wasting precious resources.
|
||||
|
||||
The memory.high boundary on the other hand can be set much more
|
||||
conservatively. When hit, it throttles allocations by forcing them
|
||||
into direct reclaim to work off the excess, but it never invokes the
|
||||
OOM killer. As a result, a high boundary that is chosen too
|
||||
aggressively will not terminate the processes, but instead it will
|
||||
lead to gradual performance degradation. The user can monitor this
|
||||
and make corrections until the minimal memory footprint that still
|
||||
gives acceptable performance is found.
|
||||
|
||||
In extreme cases, with many concurrent allocations and a complete
|
||||
breakdown of reclaim progress within the group, the high boundary
|
||||
can be exceeded. But even then it's mostly better to satisfy the
|
||||
allocation from the slack available in other groups or the rest of
|
||||
the system than killing the group. Otherwise, memory.max is there
|
||||
to limit this type of spillover and ultimately contain buggy or even
|
||||
malicious applications.
|
||||
|
||||
- The original control file names are unwieldy and inconsistent in
|
||||
many different ways. For example, the upper boundary hit count is
|
||||
exported in the memory.failcnt file, but an OOM event count has to
|
||||
be manually counted by listening to memory.oom_control events, and
|
||||
lower boundary / soft limit events have to be counted by first
|
||||
setting a threshold for that value and then counting those events.
|
||||
Also, usage and limit files encode their units in the filename.
|
||||
That makes the filenames very long, even though this is not
|
||||
information that a user needs to be reminded of every time they type
|
||||
out those names.
|
||||
|
||||
To address these naming issues, as well as to signal clearly that
|
||||
the new interface carries a new configuration model, the naming
|
||||
conventions in it necessarily differ from the old interface.
|
||||
|
||||
- The original limit files indicate the state of an unset limit with a
|
||||
Very High Number, and a configured limit can be unset by echoing -1
|
||||
into those files. But that very high number is implementation and
|
||||
architecture dependent and not very descriptive. And while -1 can
|
||||
be understood as an underflow into the highest possible value, -2 or
|
||||
-10M etc. do not work, so it's not consistent.
|
||||
|
||||
memory.low, memory.high, and memory.max will use the string "max" to
|
||||
indicate and set the highest possible value.
|
||||
|
||||
6. Planned Changes
|
||||
|
||||
6-1. CAP for resource control
|
||||
|
||||
Unified hierarchy will require one of the capabilities(7), which is
|
||||
yet to be decided, for all resource control related knobs. Process
|
||||
organization operations - creation of sub-cgroups and migration of
|
||||
processes in sub-hierarchies may be delegated by changing the
|
||||
ownership and/or permissions on the cgroup directory and
|
||||
"cgroup.procs" interface file; however, all operations which affect
|
||||
resource control - writes to a "cgroup.subtree_control" file or any
|
||||
controller-specific knobs - will require an explicit CAP privilege.
|
||||
|
||||
This, in part, is to prevent the cgroup interface from being
|
||||
inadvertently promoted to programmable API used by non-privileged
|
||||
binaries. cgroup exposes various aspects of the system in ways which
|
||||
aren't properly abstracted for direct consumption by regular programs.
|
||||
This is an administration interface much closer to sysctl knobs than
|
||||
system calls. Even the basic access model, being filesystem path
|
||||
based, isn't suitable for direct consumption. There's no way to
|
||||
access "my cgroup" in a race-free way or make multiple operations
|
||||
atomic against migration to another cgroup.
|
||||
|
||||
Another aspect is that, for better or for worse, the cgroup interface
|
||||
goes through far less scrutiny than regular interfaces for
|
||||
unprivileged userland. The upside is that cgroup is able to expose
|
||||
useful features which may not be suitable for general consumption in a
|
||||
reasonable time frame. It provides a relatively short path between
|
||||
internal details and userland-visible interface. Of course, this
|
||||
shortcut comes with high risk. We go through what we go through for
|
||||
general kernel APIs for good reasons. It may end up leaking internal
|
||||
details in a way which can exert significant pain by locking the
|
||||
kernel into a contract that can't be maintained in a reasonable
|
||||
manner.
|
||||
|
||||
Also, due to the specific nature, cgroup and its controllers don't
|
||||
tend to attract attention from a wide scope of developers. cgroup's
|
||||
short history is already fraught with severely mis-designed
|
||||
interfaces, unnecessary commitments to and exposing of internal
|
||||
details, broken and dangerous implementations of various features.
|
||||
|
||||
Keeping cgroup as an administration interface is both advantageous for
|
||||
its role and imperative given its nature. Some of the cgroup features
|
||||
may make sense for unprivileged access. If deemed justified, those
|
||||
must be further abstracted and implemented as a different interface,
|
||||
be it a system call or process-private filesystem, and survive through
|
||||
the scrutiny that any interface for general consumption is required to
|
||||
go through.
|
||||
|
||||
Requiring CAP is not a complete solution but should serve as a
|
||||
significant deterrent against spraying cgroup usages in non-privileged
|
||||
programs.
|
||||
@@ -108,6 +108,8 @@ Optional driver parameters:
|
||||
- qcom,sysmon-id: platform device id that sysmon is probed with for the subsystem.
|
||||
- qcom,pil-force-shutdown: Boolean. If set, the SSR framework will not trigger graceful shutdown
|
||||
on behalf of the subsystem driver.
|
||||
- qcom,mdm-link-info: a string indicating additional info about the physical link.
|
||||
For example: "devID_domain.bus.slot" in case of PCIe.
|
||||
|
||||
Example:
|
||||
mdm0: qcom,mdm0 {
|
||||
|
||||
52
Documentation/devicetree/bindings/clock/clk-qpnp-div.txt
Normal file
52
Documentation/devicetree/bindings/clock/clk-qpnp-div.txt
Normal file
@@ -0,0 +1,52 @@
|
||||
Qualcomm Technologies, Inc. QPNP clock divider (clkdiv)
|
||||
|
||||
clkdiv configures the clock frequency of a set of outputs on the PMIC.
|
||||
These clocks are typically wired through alternate functions on
|
||||
gpio pins.
|
||||
|
||||
=======================
|
||||
Supported Properties
|
||||
=======================
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be "qcom,qpnp-clkdiv".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: Addresses and sizes for the memory of this CLKDIV
|
||||
peripheral.
|
||||
|
||||
- qcom,cxo-freq
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: The frequency of the crystal oscillator (CXO) clock in Hz.
|
||||
|
||||
- qcom,clkdiv-id
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: Integer value specifies the hardware identifier of this
|
||||
CLKDIV peripheral.
|
||||
|
||||
- qcom,clkdiv-init-freq
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Initial output frequency in Hz to configure for the CLKDIV
|
||||
peripheral. The initial frequency value should be less than
|
||||
or equal to CXO clock frequency and greater than or equal to
|
||||
CXO_freq/64.
|
||||
|
||||
=======
|
||||
Example
|
||||
=======
|
||||
|
||||
qcom,clkdiv@5b00 {
|
||||
compatible = "qcom,qpnp-clkdiv";
|
||||
reg = <0x5b00 0x100>;
|
||||
|
||||
qcom,cxo-freq = <19200000>;
|
||||
qcom,clkdiv-id = <1>;
|
||||
qcom,clkdiv-init-freq = <9600000>;
|
||||
};
|
||||
@@ -77,7 +77,7 @@ Examples:
|
||||
clks: ccm@53f80000{
|
||||
compatible = "fsl,imx31-ccm";
|
||||
reg = <0x53f80000 0x4000>;
|
||||
interrupts = <0 31 0x04 0 53 0x04>;
|
||||
interrupts = <31>, <53>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
|
||||
@@ -11,6 +11,7 @@ Required properties :
|
||||
"qcom,mmcc-msm8974"
|
||||
"qcom,mmcc-msm8996"
|
||||
"qcom,mmcc-sdm660"
|
||||
"qcom,mmcc-sdm630"
|
||||
|
||||
- reg : shall contain base register location and length
|
||||
- #clock-cells : shall contain 1
|
||||
|
||||
@@ -12,13 +12,22 @@ Required properties:
|
||||
- reg-names: Names of the memory regions defined in reg entry
|
||||
- interrupts: Copy engine interrupt table
|
||||
- qcom,wlan-msa-memory: MSA memory size
|
||||
- clocks: List of clock phandles
|
||||
- clock-names: List of clock names corresponding to the "clocks" property
|
||||
- iommus: SMMUs and corresponding Stream IDs needed by WLAN
|
||||
- qcom,wlan-smmu-iova-address: I/O virtual address range as <start length>
|
||||
format to be used for allocations associated between WLAN and SMMU
|
||||
|
||||
Optional properties:
|
||||
- <supply-name>-supply: phandle to the regulator device tree node
|
||||
optional "supply-name" is "vdd-0.8-cx-mx".
|
||||
- qcom,<supply>-config: Specifies voltage levels for supply. Should be
|
||||
specified in pairs (min, max), units uV. There can
|
||||
be optional load in uA and Regulator settle delay in
|
||||
uS.
|
||||
- qcom,icnss-vadc: VADC handle for vph_pwr read APIs.
|
||||
- qcom,icnss-adc_tm: VADC handle for vph_pwr notification APIs.
|
||||
- qcom,smmu-s1-bypass: Boolean context flag to set SMMU to S1 bypass
|
||||
|
||||
Example:
|
||||
|
||||
@@ -26,6 +35,8 @@ Example:
|
||||
compatible = "qcom,icnss";
|
||||
reg = <0x0a000000 0x1000000>;
|
||||
reg-names = "membase";
|
||||
clocks = <&clock_gcc clk_aggre2_noc_clk>;
|
||||
clock-names = "smmu_aggre2_noc_clk";
|
||||
iommus = <&anoc2_smmu 0x1900>,
|
||||
<&anoc2_smmu 0x1901>;
|
||||
qcom,wlan-smmu-iova-address = <0 0x10000000>;
|
||||
@@ -43,4 +54,7 @@ Example:
|
||||
<0 140 0 /* CE10 */ >,
|
||||
<0 141 0 /* CE11 */ >;
|
||||
qcom,wlan-msa-memory = <0x200000>;
|
||||
qcom,smmu-s1-bypass;
|
||||
vdd-0.8-cx-mx-supply = <&pm8998_l5>;
|
||||
qcom,vdd-0.8-cx-mx-config = <800000 800000 2400 1000>;
|
||||
};
|
||||
|
||||
@@ -3,6 +3,7 @@ Qualcomm adreno/snapdragon hdmi output
|
||||
Required properties:
|
||||
- compatible: one of the following
|
||||
* "qcom,hdmi-tx-8996"
|
||||
* "qcom,hdmi-tx-8998"
|
||||
* "qcom,hdmi-tx-8994"
|
||||
* "qcom,hdmi-tx-8084"
|
||||
* "qcom,hdmi-tx-8974"
|
||||
@@ -21,6 +22,7 @@ Required properties:
|
||||
|
||||
Optional properties:
|
||||
- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
|
||||
- qcom,hdmi-tx-hpd5v-gpio: hdmi 5v boost pin
|
||||
- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
|
||||
- power-domains: reference to the power domain(s), if available.
|
||||
- pinctrl-names: the pin control state names; should contain "default"
|
||||
|
||||
59
Documentation/devicetree/bindings/drm/msm/hdmi-display.txt
Normal file
59
Documentation/devicetree/bindings/drm/msm/hdmi-display.txt
Normal file
@@ -0,0 +1,59 @@
|
||||
Qualcomm Technologies,Inc. Adreno/Snapdragon hdmi display manager
|
||||
|
||||
Required properties:
|
||||
- compatible: "qcom,hdmi-display"
|
||||
- label: label of this display manager
|
||||
|
||||
Optional properties:
|
||||
- qcom,display-type: display type of this manager. It could be "primary",
|
||||
"secondary", "tertiary", etc.
|
||||
- qcom,non-pluggable: Boolean to indicate if display is non pluggable.
|
||||
- qcom,customize-modes: Customized modes when it's non pluggable display.
|
||||
- qcom,customize-mode-id: Customized mode node.
|
||||
- qcom,mode-name: String which indicates the mode name which shall be used
|
||||
by the connector in non pluggable mode. Refer the example below for details.
|
||||
In pluggable mode, the modes shall be filled up
|
||||
after edid parsing.
|
||||
- qcom,mode-h-active: Horizontal active pixels for this mode.
|
||||
- qcom,mode-h-front-porch: Horizontal front porch in pixels for this mode.
|
||||
- qcom,mode-h-pulse-width: Horizontal sync width in pixels for this mode.
|
||||
- qcom,mode-h-back-porch: Horizontal back porch in pixels for this mode.
|
||||
- qcom,mode-h-active-high: Boolean to indicate if mode horizontal polarity is active high.
|
||||
- qcom,mode-v-active: Vertical active lines for this mode.
|
||||
- qcom,mode-v-front-porch: Vertical front porch in lines for this mode.
|
||||
- qcom,mode-v-pulse-width: Vertical sync width in lines for this mode.
|
||||
- qcom,mode-v-back-porch: Vertical back porch in lines for this mode.
|
||||
- qcom,mode-v-active-high: Boolean to indicate if mode vertical polarity is active high.
|
||||
- qcom,mode-refersh-rate: Mode refresh rate in hertz.
|
||||
- qcom,mode-clock-in-khz: Mode pixel clock in KHz.
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
...
|
||||
|
||||
hdmi_display: qcom,hdmi-display {
|
||||
compatible = "qcom,hdmi-display";
|
||||
label = "hdmi_display";
|
||||
qcom,display-type = "secondary";
|
||||
qcom,non-pluggable;
|
||||
qcom,customize-modes {
|
||||
qcom,customize-mode-id@0 {
|
||||
qcom,mode-name = "3840x2160@30Hz";
|
||||
qcom,mode-h-active = <3840>;
|
||||
qcom,mode-h-front-porch = <176>;
|
||||
qcom,mode-h-pulse-width = <88>;
|
||||
qcom,mode-h-back-porch = <296>;
|
||||
qcom,mode-h-active-high;
|
||||
qcom,mode-v-active = <2160>;
|
||||
qcom,mode-v-front-porch = <8>;
|
||||
qcom,mode-v-pulse-width = <10>;
|
||||
qcom,mode-v-back-porch = <72>;
|
||||
qcom,mode-v-active-high;
|
||||
qcom,mode-refersh-rate = <30>;
|
||||
qcom,mode-clock-in-khz = <297000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
};
|
||||
@@ -54,6 +54,7 @@ Optional properties:
|
||||
device node. Refer to pinctrl-bindings.txt
|
||||
- qcom,logical2physical-lane-map: An array that specifies the DP logical to physical lane map setting.
|
||||
- qcom,phy-register-offset: An integer specifying the offset value of DP PHY register space.
|
||||
- qcom,max-pclk-frequency-khz: An integer specifying the max. pixel clock in KHz supported by Display Port.
|
||||
|
||||
Example:
|
||||
mdss_dp_ctrl: qcom,dp_ctrl@c990000 {
|
||||
@@ -89,6 +90,7 @@ Example:
|
||||
qcom,aux-cfg-settings = [00 13 00 10 0a 26 0a 03 8b 03];
|
||||
qcom,logical2physical-lane-map = [02 03 01 00];
|
||||
qcom,phy-register-offset = <0x4>;
|
||||
qcom,max-pclk-frequency-khz = <593470>;
|
||||
|
||||
qcom,core-supply-entries {
|
||||
#address-cells = <1>;
|
||||
|
||||
@@ -271,6 +271,8 @@ Optional properties:
|
||||
"trigger_sw_te" = Software trigger and TE
|
||||
- qcom,mdss-dsi-panel-framerate: Specifies the frame rate for the panel.
|
||||
60 = 60 frames per second (default)
|
||||
- qcom,mdss-dsi-host-esc-clk-freq-hz: Specifies the escape clock needed for the host.
|
||||
19200000 = 19.2 MHz (default)
|
||||
- qcom,mdss-dsi-panel-clockrate: A 64 bit value specifies the panel clock speed in Hz.
|
||||
0 = default value.
|
||||
- qcom,mdss-mdp-kickoff-threshold: This property can be used to define a region
|
||||
@@ -657,6 +659,7 @@ Example:
|
||||
qcom,mdss-dsi-mdp-trigger = <0>;
|
||||
qcom,mdss-dsi-dma-trigger = <0>;
|
||||
qcom,mdss-dsi-panel-framerate = <60>;
|
||||
qcom,mdss-dsi-host-esc-clk-freq-hz = <19200000>;
|
||||
qcom,mdss-dsi-panel-clockrate = <424000000>;
|
||||
qcom,mdss-mdp-kickoff-threshold = <11 2430>;
|
||||
qcom,mdss-mdp-kickoff-delay = <1000>;
|
||||
|
||||
@@ -92,6 +92,8 @@ Required properties
|
||||
active in MDP for this configuration. Meant for
|
||||
hardware that has hw cursors support as a
|
||||
source pipe.
|
||||
- qcom,mdss-rot-xin-id: Array of VBIF clients ids (xins) corresponding
|
||||
to the respective rotator pipes.
|
||||
- qcom,mdss-pipe-cursor-xin-id: Array of VBIF clients ids (xins) corresponding
|
||||
to the respective cursor pipes. Number of xin ids
|
||||
defined should match the number of offsets
|
||||
@@ -754,6 +756,7 @@ Example:
|
||||
qcom,mdss-pipe-rgb-xin-id = <1 5 9>;
|
||||
qcom,mdss-pipe-dma-xin-id = <2 10>;
|
||||
qcom,mdss-pipe-cursor-xin-id = <7 7>;
|
||||
qcom,mdss-rot-xin-id = <14 15>;
|
||||
|
||||
qcom,mdss-pipe-vig-clk-ctrl-offsets = <0x3AC 0 0>,
|
||||
<0x3B4 0 0>,
|
||||
|
||||
@@ -16,7 +16,8 @@ Required properties:
|
||||
"qcom,mdss_hdmi_pll_8996_v3", "qcom,mdss_hdmi_pll_8996_v3_1p8",
|
||||
"qcom,mdss_dsi_pll_8998", "qcom,mdss_dp_pll_8998",
|
||||
"qcom,mdss_hdmi_pll_8998", "qcom,mdss_dsi_pll_sdm660",
|
||||
"qcom,mdss_dp_pll_sdm660"
|
||||
"qcom,mdss_dp_pll_sdm660", "qcom,mdss_dsi_pll_sdm630",
|
||||
"qcom,mdss_dp_pll_sdm630"
|
||||
- cell-index: Specifies the controller used
|
||||
- reg: offset and length of the register set for the device.
|
||||
- reg-names : names to refer to register sets related to this device
|
||||
|
||||
17
Documentation/devicetree/bindings/goldfish/audio.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/audio.txt
Normal file
@@ -0,0 +1,17 @@
|
||||
Android Goldfish Audio
|
||||
|
||||
Android goldfish audio device generated by android emulator.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain "google,goldfish-audio" to match emulator
|
||||
- reg : <registers mapping>
|
||||
- interrupts : <interrupt mapping>
|
||||
|
||||
Example:
|
||||
|
||||
goldfish_audio@9030000 {
|
||||
compatible = "google,goldfish-audio";
|
||||
reg = <0x9030000 0x100>;
|
||||
interrupts = <0x4>;
|
||||
};
|
||||
17
Documentation/devicetree/bindings/goldfish/battery.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/battery.txt
Normal file
@@ -0,0 +1,17 @@
|
||||
Android Goldfish Battery
|
||||
|
||||
Android goldfish battery device generated by android emulator.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain "google,goldfish-battery" to match emulator
|
||||
- reg : <registers mapping>
|
||||
- interrupts : <interrupt mapping>
|
||||
|
||||
Example:
|
||||
|
||||
goldfish_battery@9020000 {
|
||||
compatible = "google,goldfish-battery";
|
||||
reg = <0x9020000 0x1000>;
|
||||
interrupts = <0x3>;
|
||||
};
|
||||
17
Documentation/devicetree/bindings/goldfish/events.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/events.txt
Normal file
@@ -0,0 +1,17 @@
|
||||
Android Goldfish Events Keypad
|
||||
|
||||
Android goldfish events keypad device generated by android emulator.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain "google,goldfish-events-keypad" to match emulator
|
||||
- reg : <registers mapping>
|
||||
- interrupts : <interrupt mapping>
|
||||
|
||||
Example:
|
||||
|
||||
goldfish-events@9040000 {
|
||||
compatible = "google,goldfish-events-keypad";
|
||||
reg = <0x9040000 0x1000>;
|
||||
interrupts = <0x5>;
|
||||
};
|
||||
17
Documentation/devicetree/bindings/goldfish/tty.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/tty.txt
Normal file
@@ -0,0 +1,17 @@
|
||||
Android Goldfish TTY
|
||||
|
||||
Android goldfish tty device generated by android emulator.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain "google,goldfish-tty" to match emulator
|
||||
- reg : <registers mapping>
|
||||
- interrupts : <interrupt mapping>
|
||||
|
||||
Example:
|
||||
|
||||
goldfish_tty@1f004000 {
|
||||
compatible = "google,goldfish-tty";
|
||||
reg = <0x1f004000 0x1000>;
|
||||
interrupts = <0xc>;
|
||||
};
|
||||
52
Documentation/devicetree/bindings/gpio/gpio_keys.txt
Normal file
52
Documentation/devicetree/bindings/gpio/gpio_keys.txt
Normal file
@@ -0,0 +1,52 @@
|
||||
Device-Tree bindings for input/gpio_keys.c keyboard driver
|
||||
|
||||
Required properties:
|
||||
- compatible = "gpio-keys";
|
||||
|
||||
Optional properties:
|
||||
- input-name: input name of the device.
|
||||
- autorepeat: Boolean, Enable auto repeat feature of Linux input subsystem.
|
||||
- pinctrl-names : This should be defined if a target uses pinctrl framework.
|
||||
See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt.
|
||||
It should specify the names of the configs that pinctrl can install in drive.
|
||||
|
||||
Following are the pinctrl configs that can be installed:
|
||||
"gpio_ts_active" : Active configuration of pins, this should specify active
|
||||
config defined in pin groups of interrupt and reset gpio.
|
||||
"gpio_ts_suspend" : Disabled configuration of pins, this should specify sleep
|
||||
config defined in pin groups of interrupt and reset gpio.
|
||||
- name : input device name.
|
||||
- use-syscore : use syscore functionality for driver.
|
||||
|
||||
Each button (key) is represented as a sub-node of "gpio-keys":
|
||||
Subnode properties:
|
||||
|
||||
- gpios: OF device-tree gpio specification.
|
||||
- label: Descriptive name of the key.
|
||||
- linux,code: Keycode to emit.
|
||||
|
||||
Optional subnode-properties:
|
||||
- linux,input-type: Specify event type this button/key generates.
|
||||
If not specified defaults to <1> == EV_KEY.
|
||||
- debounce-interval: Debouncing interval time in milliseconds.
|
||||
If not specified defaults to 5.
|
||||
- gpio-key,wakeup: Boolean, button can wake-up the system.
|
||||
|
||||
Example nodes:
|
||||
|
||||
gpio_keys {
|
||||
compatible = "gpio-keys";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
autorepeat;
|
||||
input-name = "gpio-keys";
|
||||
pinctrl-names = "tlmm_gpio_key_active","tlmm_gpio_key_suspend";
|
||||
pinctrl-0 = <&gpio_key_active>;
|
||||
pinctrl-1 = <&gpio_key_suspend>;
|
||||
use-syscore;
|
||||
button@21 {
|
||||
label = "GPIO Key UP";
|
||||
linux,code = <103>;
|
||||
gpios = <&gpio1 0 1>;
|
||||
};
|
||||
};
|
||||
@@ -110,6 +110,17 @@ Optional Properties:
|
||||
- qcom,l2pc-cpu-mask-latency:
|
||||
The CPU mask latency in microseconds to avoid L2PC
|
||||
on masked CPUs.
|
||||
|
||||
- qcom,gpu-cx-ipeak:
|
||||
To handle Cx peak current limit.
|
||||
<phandle bit>
|
||||
phandle - phandle of cx ipeak device node
|
||||
bit - bit number of client in relevant register
|
||||
- qcom,gpu-cx-ipeak-clk:
|
||||
GPU clock threshold for Cx Ipeak voting. KGSL votes
|
||||
to Cx Ipeak driver when GPU clock crosses this threshold.
|
||||
Cx Ipeak can limit peak current based on voting from other clients.
|
||||
|
||||
- qcom,force-32bit:
|
||||
Force the GPU to use 32 bit data sizes even if
|
||||
it is capable of doing 64 bit.
|
||||
@@ -139,6 +150,11 @@ Optional Properties:
|
||||
baseAddr - base address of the gpu channels in the qdss stm memory region
|
||||
size - size of the gpu stm region
|
||||
|
||||
- qcom,gpu-qtimer:
|
||||
<baseAddr size>
|
||||
baseAddr - base address of the qtimer memory region
|
||||
size - size of the qtimer region
|
||||
|
||||
- qcom,tsens-name:
|
||||
Specify the name of GPU temperature sensor. This name will be used
|
||||
to get the temperature from the thermal driver API.
|
||||
|
||||
@@ -12,6 +12,11 @@ Required properties:
|
||||
- vref-supply: The regulator supply ADC reference voltage.
|
||||
- #io-channel-cells: Should be 1, see ../iio-bindings.txt
|
||||
|
||||
Optional properties:
|
||||
- resets: Must contain an entry for each entry in reset-names if need support
|
||||
this option. See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the name "saradc-apb".
|
||||
|
||||
Example:
|
||||
saradc: saradc@2006c000 {
|
||||
compatible = "rockchip,saradc";
|
||||
@@ -19,6 +24,8 @@ Example:
|
||||
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cru SCLK_SARADC>, <&cru PCLK_SARADC>;
|
||||
clock-names = "saradc", "apb_pclk";
|
||||
resets = <&cru SRST_SARADC>;
|
||||
reset-names = "saradc-apb";
|
||||
#io-channel-cells = <1>;
|
||||
vref-supply = <&vcc18>;
|
||||
};
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
Mstar touch controller
|
||||
STMicroelectronics touch controller
|
||||
|
||||
The mstar controller is connected to host processor
|
||||
The STMicroelectronics controller is connected to host processor
|
||||
via i2c. The controller generates interrupts when the
|
||||
user touches the panel. The host controller is expected
|
||||
to read the touch coordinates over i2c and pass the coordinates
|
||||
@@ -8,21 +8,18 @@ to the rest of the system.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "mstar,msg21xx".
|
||||
- compatible : should be "st,fts".
|
||||
- reg : i2c slave address of the device.
|
||||
- interrupt-parent : parent of interrupt.
|
||||
- interrupts : touch sample interrupt to indicate presense or release
|
||||
of fingers on the panel.
|
||||
- vdd-supply : Power supply needed to power up the device.
|
||||
- vcc_i2c-supply : Power source required to power up i2c bus.
|
||||
- mstar,irq-gpio : irq gpio which is to provide interrupts to host,
|
||||
- vcc-supply : Power source required to power up i2c bus.
|
||||
- st,irq-gpio : irq gpio which is to provide interrupts to host,
|
||||
same as "interrupts" node. It will also
|
||||
contain active low or active high information.
|
||||
- mstar,reset-gpio : reset gpio to control the reset of chip.
|
||||
- mstar,display-coords : display coords in pixels. It is a four
|
||||
tuple consisting of min x, min y, max x and
|
||||
max y values.
|
||||
- pinctrl-names : This should be defined if a target uses pinctrl framework.
|
||||
- st,reset-gpio : reset gpio to control the reset of chip.
|
||||
- pinctrl-names : This should be defined if a target uses pinctrl framework.
|
||||
See "pinctrl" in Documentation/devicetree/bindings/pinctrl/msm-pinctrl.txt.
|
||||
Specify the names of the configs that pinctrl can install in driver.
|
||||
Following are the pinctrl configs that can be installed:
|
||||
@@ -32,40 +29,26 @@ Required properties:
|
||||
config defined in pin groups of interrupt and reset gpio.
|
||||
"pmx_ts_release" : Release configuration of pins, this should specify
|
||||
release config defined in pin groups of interrupt and reset gpio.
|
||||
- mstar,num-max-touches: It defines the maximum number of touch supported by the controller.
|
||||
- mstar,hard-reset-delay-ms : hard reset delay in ms
|
||||
- mstar,post-hard-reset-delay-ms : post hard reset delay in ms
|
||||
|
||||
- st,regulator_avdd : name of Power supply needed to power up the device.
|
||||
- st,regulator_dvdd : name of Power source required to power up i2c bus.
|
||||
Optional properties:
|
||||
|
||||
- mstar,button-map : button map of key codes. It is a three tuple consisting of key codes.
|
||||
- mstar,panel-coords : panel coords for the chip in pixels.
|
||||
It is a four tuple consisting of min x,
|
||||
min y, max x and max y values.
|
||||
- mstar,ic-type : It defines the ic-type of the controller. Values are as folows:
|
||||
1 -> msg2133.
|
||||
2 -> msg21xxA.
|
||||
3 -> msg26xxM.
|
||||
|
||||
Example:
|
||||
i2c@78b9000 { /* BLSP1 QUP5 */
|
||||
mstar@26 {
|
||||
compatible = "mstar,msg21xx";
|
||||
reg = <0x26>;
|
||||
st_fts@49 {
|
||||
compatible = "st,fts";
|
||||
reg = <0x49>;
|
||||
interrupt-parent = <&msm_gpio>;
|
||||
interrupts = <13 0x2008>;
|
||||
mstar,irq-gpio = <&msm_gpio 13 0x00000001>;
|
||||
mstar,reset-gpio = <&msm_gpio 12 0x0>;
|
||||
vdd-supply = <&pm8916_l17>;
|
||||
vcc_i2c-supply = <&pm8916_l6>;
|
||||
mstar,display-coords = <0 0 480 854>;
|
||||
vcc-supply = <&pm8916_l6>;
|
||||
pinctrl-names = "pmx_ts_active","pmx_ts_suspend";
|
||||
pinctrl-0 = <&ts_int_active &ts_reset_active>;
|
||||
pinctrl-1 = <&ts_int_suspend &ts_reset_suspend>;
|
||||
mstar,button-map = <172 139 158>;
|
||||
mstar,ic-type = <2>;
|
||||
mstar,num_max_touches = <2>;
|
||||
mstar,hard-reset-delay-ms = <100>;
|
||||
mstar,post-hard-reset-delay-ms = <100>;
|
||||
st,irq-gpio = <&msm_gpio 13 0x00000001>;
|
||||
st,reset-gpio = <&msm_gpio 12 0x0>;
|
||||
st,regulator_dvdd = "vdd";
|
||||
st,regulator_avdd = "avdd";
|
||||
};
|
||||
};
|
||||
@@ -1,104 +0,0 @@
|
||||
Goodix GT9xx series touch controller
|
||||
|
||||
The Goodix GT9xx series touch controller is connected to the host processor via
|
||||
I2C. The controller generates interrupts when the user touches the panel. The
|
||||
host controller is expected to read the touch coordinates over I2C and pass
|
||||
the coordinates to the rest of the system.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "goodix,gt9xx"
|
||||
- reg : I2C slave address of the device.
|
||||
- interrupt-parent : Parent of interrupt.
|
||||
- interrupts : Configuration of touch panel controller interrupt
|
||||
GPIO.
|
||||
- goodix,product-id : Product identification of the controller.
|
||||
- interrupt-gpios : Interrupt gpio which is to provide interrupts to
|
||||
host, same as "interrupts" node.
|
||||
- reset-gpios : Reset gpio to control the reset of chip.
|
||||
- goodix,display-coords : Display coordinates in pixels. It is a four
|
||||
tuple consisting of min x, min y, max x and
|
||||
max y values.
|
||||
|
||||
Optional properties:
|
||||
|
||||
- avdd-supply : Power supply needed to power up the device, this is
|
||||
for fixed voltage external regulator.
|
||||
- vdd-supply : Power supply needed to power up the device, when use
|
||||
external regulator, do not add this property.
|
||||
- vcc-i2c-supply : Power source required to power up i2c bus.
|
||||
GT9xx series can provide 1.8V from internal
|
||||
LDO, add this properties base on hardware
|
||||
design.
|
||||
- goodix,panel-coords : Panel coordinates for the chip in pixels.
|
||||
It is a four tuple consisting of min x,
|
||||
min y, max x and max y values.
|
||||
- goodix,i2c-pull-up : To specify pull up is required.
|
||||
- goodix,force-update : To specify force update is allowed.
|
||||
- goodix,enable-power-off : Power off touchscreen during suspend.
|
||||
- goodix,button-map : Button map of key codes. The number of key codes
|
||||
depend on panel.
|
||||
- goodix,cfg-data0 : Touch screen controller config data group 0. Ask vendor
|
||||
to provide that.
|
||||
Driver supports maximum six config groups. If more than one
|
||||
groups are defined, driver will select config group depending
|
||||
on hardware configuration. If only config group 0 is defined,
|
||||
it will be used for all hardware configurations.
|
||||
Touch screen controller will use its onchip default config data
|
||||
if this property is not present.
|
||||
- goodix,cfg-data1 : Touch screen controller config data group 1. Ask vendor
|
||||
to provide that.
|
||||
- goodix,cfg-data2 : Touch screen controller config data group 2. Ask vendor
|
||||
to provide that.
|
||||
- goodix,cfg-data3 : Touch screen controller config data group 3. Ask vendor
|
||||
to provide that.
|
||||
- goodix,cfg-data4 : Touch screen controller config data group 4. Ask vendor
|
||||
to provide that.
|
||||
- goodix,cfg-data5 : Touch screen controller config data group 5. Ask vendor
|
||||
to provide that.
|
||||
- goodix,fw-name : Touch screen controller firmware file name.
|
||||
- goodix,slide-wakeup : To specify slide-wakeup property is enabled or not.
|
||||
- goodix,dbl-clk-wakeup : To specify dbl-clk-wakeup property is enabled or not.
|
||||
- goodix,change-x2y : To specify change-x2y property is enabled or not.
|
||||
- goodix,driver-send-cfg : To specify driver-send-cfg property is enabled or not.
|
||||
- goodix,have-touch-key : To specify have-touch-key property is enabled or not.
|
||||
- goodix,with-pen : To specify with-pen property is enabled or not.
|
||||
Example:
|
||||
i2c@f9927000 {
|
||||
goodix@5d {
|
||||
compatible = "goodix,gt9xx";
|
||||
reg = <0x5d>;
|
||||
interrupt-parent = <&msmgpio>;
|
||||
interrupts = <17 0x2008>;
|
||||
reset-gpios = <&msmgpio 16 0x00>;
|
||||
interrupt-gpios = <&msmgpio 17 0x00>;
|
||||
avdd-supply = <&tp_power>;
|
||||
goodix,panel-coords = <0 0 720 1200>;
|
||||
goodix,display-coords = <0 0 720 1080>;
|
||||
goodix,button-map= <158 102 139>;
|
||||
goodix,product-id = "915";
|
||||
goodix,cfg-data0 = [
|
||||
41 D0 02 00 05 0A 05 01 01 08
|
||||
12 58 50 41 03 05 00 00 00 00
|
||||
00 00 00 00 00 00 00 8C 2E 0E
|
||||
28 24 73 13 00 00 00 83 03 1D
|
||||
40 02 00 00 00 03 64 32 00 00
|
||||
00 1A 38 94 C0 02 00 00 00 04
|
||||
9E 1C 00 8D 20 00 7A 26 00 6D
|
||||
2C 00 60 34 00 60 10 38 68 00
|
||||
F0 50 35 FF FF 27 00 00 00 00
|
||||
00 01 1B 14 0C 14 00 00 01 00
|
||||
00 00 00 00 00 00 00 00 00 00
|
||||
00 00 02 04 06 08 0A 0C 0E 10
|
||||
12 14 16 18 1A 1C FF FF FF FF
|
||||
FF FF FF FF FF FF FF FF FF FF
|
||||
FF FF 00 02 04 06 08 0A 0C 0F
|
||||
10 12 13 14 16 18 1C 1D 1E 1F
|
||||
20 21 22 24 26 28 29 2A FF FF
|
||||
FF FF FF FF FF FF FF 22 22 22
|
||||
22 22 22 FF 07 01];
|
||||
goodix,fw_name = "gtp_fw.bin";
|
||||
goodix,have-touch-key;
|
||||
goodix,driver-send-cfg;
|
||||
};
|
||||
};
|
||||
@@ -1,180 +0,0 @@
|
||||
Qualcomm Technologies PNP Flash LED
|
||||
|
||||
QPNP (Qualcomm Technologies Plug N Play) Flash LED (Light
|
||||
Emitting Diode) driver is used to provide illumination to
|
||||
camera sensor when background light is dim to capture good
|
||||
picture. It can also be used for flashlight/torch application.
|
||||
It is part of PMIC on Qualcomm Technologies reference platforms.
|
||||
The PMIC is connected to the host processor via SPMI bus.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "qcom,qpnp-flash-led"
|
||||
- reg : base address and size for flash LED modules
|
||||
|
||||
Optional properties:
|
||||
- qcom,headroom : headroom to use. Values should be 250, 300,
|
||||
400 and 500 in mV.
|
||||
- qcom,startup-dly : delay before flashing after flash executed.
|
||||
Values should 10, 32, 64, and 128 in us.
|
||||
- qcom,clamp-curr : current to clamp at when voltage droop happens.
|
||||
Values are in integer from 0 to 1000 inclusive,
|
||||
indicating 0 to 1000 mA.
|
||||
- qcom,self-check-enabled : boolean type. self fault check enablement
|
||||
- qcom,thermal-derate-enabled : boolean type. derate enablement when module
|
||||
temperature reaches threshold
|
||||
- qcom,thermal-derate-threshold : thermal threshold for derate. Values
|
||||
should be 95, 105, 115, 125 in C.
|
||||
- qcom,thermal-derate-rate : derate rate when module temperature
|
||||
reaches threshold. Values should be
|
||||
"1_PERCENT", "1P25_PERCENT", "2_PERCENT",
|
||||
"2P5_PERCENT", "5_PERCENT" in string.
|
||||
- qcom,current-ramp-enabled : boolean type. stepped current ramp enablement
|
||||
- qcom,ramp-up-step : current ramp up rate. Values should be
|
||||
"0P2US", "0P4US", "0P8US", "1P6US", "3P3US",
|
||||
"6P7US", "13P5US", "27US".
|
||||
- qcom,ramp-dn-step : current ramp down rate. Values should be
|
||||
"0P2US", "0P4US", "0P8US", "1P6US", "3P3US",
|
||||
"6P7US", "13P5US", "27US".
|
||||
- qcom,vph-pwr-droop-enabled : boolean type. VPH power droop enablement. Enablement
|
||||
allows current clamp when phone power drops below
|
||||
pre-determined threshold
|
||||
- qcom,vph-pwr-droop-threshold : VPH power threshold for module to clamp current.
|
||||
Values are 2500 - 3200 in mV with 100 mV steps.
|
||||
- qcom,vph-pwr-droop-debounce-time : debounce time for module to confirm a voltage
|
||||
droop is happening. Values are 0, 10, 32, 64
|
||||
in us.
|
||||
- qcom,pmic-charger-support : Boolean type. This tells if flash utilizes charger boost
|
||||
support
|
||||
- qcom,headroom-sense-ch0-enabled: Boolean type. This configures headroom sensing enablement
|
||||
for LED channel 0
|
||||
- qcom,headroom-sense-ch1-enabled: Boolean type. This configures headroom sensing enablement
|
||||
for LED channel 1
|
||||
- qcom,power-detect-enabled : Boolean type. This enables driver to get maximum flash LED
|
||||
current at current battery level to avoid intensity clamp
|
||||
when battery voltage is low
|
||||
- qcom,otst2-moduled-enabled : Boolean type. This enables driver to enable MASK to support
|
||||
OTST2 connection.
|
||||
- qcom,follow-otst2-rb-disabled : Boolean type. This allows driver to reset/deset module.
|
||||
By default, driver resets module. This entry allows driver to
|
||||
bypass reset module sequence.
|
||||
- qcom,die-current-derate-enabled: Boolean type. This enables driver to get maximum flash LED
|
||||
current, based on PMIC die temperature threshold to
|
||||
avoid significant current derate from hardware. This property
|
||||
is not needed if PMIC is older than PMI8994v2.0.
|
||||
- qcom,die-temp-vadc : VADC channel source for flash LED. This property is not
|
||||
needed if PMIC is older than PMI8994v2.0.
|
||||
- qcom,die-temp-threshold : Integer type array for PMIC die temperature threshold.
|
||||
Array should have at least one value. Values should be in
|
||||
celcius. This property is not needed if PMIC is older than
|
||||
PMI8994v2.0.
|
||||
- qcom,die-temp-derate-current : Integer type arrray for PMIC die temperature derate
|
||||
current. Array should have at least one value. Values
|
||||
should be in mA. This property is not needed if PMIC is older
|
||||
than PMI8994v2.0.
|
||||
|
||||
Required properties inside child node. Chile node contains settings for each individual LED.
|
||||
Each LED hardware needs a node for itself and a switch node to control brightness.
|
||||
For the purpose of turning on/off LED and better regulator control, "led:switch" node
|
||||
is introduced. "led:switch" acquires several existing properties from other nodes for
|
||||
operational simplification. For backward compatibility purpose, switch node can be optional:
|
||||
- label : type of led that will be used, either "flash" or "torch".
|
||||
- qcom,led-name : name of the LED. Accepted values are "led:flash_0",
|
||||
"led:flash_1", "led:torch_0", "led:torch_1"
|
||||
- qcom,default-led-trigger : trigger for the camera flash and torch. Accepted values are
|
||||
"flash0_trigger", "flash1_trigger", "torch0_trigger", torch1_trigger"
|
||||
- qcom,id : enumerated ID for each physical LED. Accepted values are "0",
|
||||
"1", etc..
|
||||
- qcom,max-current : maximum current allowed on this LED. Valid values should be
|
||||
integer from 0 to 1000 inclusive, indicating 0 to 1000 mA.
|
||||
- qcom,pmic-revid : PMIC revision id source. This property is needed for PMI8996
|
||||
revision check.
|
||||
|
||||
Optional properties inside child node:
|
||||
- qcom,current : default current intensity for LED. Accepted values should be
|
||||
integer from 0 t 1000 inclusive, indicating 0 to 1000 mA.
|
||||
- qcom,duration : Duration for flash LED. When duration time expires, hardware will turn off
|
||||
flash LED. Values should be from 10 ms to 1280 ms with 10 ms incremental
|
||||
step. Not applicable to torch. It is required for LED:SWITCH node to handle
|
||||
LED used as flash.
|
||||
- reg<n> : reg<n> (<n> represents number. eg 0,1,2,..) property is to add support for
|
||||
multiple power sources. It includes two properties regulator-name and max-voltage.
|
||||
Required property inside regulator node:
|
||||
- regulator-name : This denotes this node is a regulator node and which
|
||||
regulator to use.
|
||||
Optional property inside regulator node:
|
||||
- max-voltage : This specifies max voltage of regulator. Some switch
|
||||
or boost regulator does not need this property.
|
||||
|
||||
Example:
|
||||
qcom,leds@d300 {
|
||||
compatible = "qcom,qpnp-flash-led";
|
||||
status = "okay";
|
||||
reg = <0xd300 0x100>;
|
||||
label = "flash";
|
||||
qcom,headroom = <500>;
|
||||
qcom,startup-dly = <128>;
|
||||
qcom,clamp-curr = <200>;
|
||||
qcom,pmic-charger-support;
|
||||
qcom,self-check-enabled;
|
||||
qcom,thermal-derate-enabled;
|
||||
qcom,thermal-derate-threshold = <80>;
|
||||
qcom,thermal-derate-rate = "4_PERCENT";
|
||||
qcom,current-ramp-enabled;
|
||||
qcom,ramp_up_step = "27US";
|
||||
qcom,ramp_dn_step = "27US";
|
||||
qcom,vph-pwr-droop-enabled;
|
||||
qcom,vph-pwr-droop-threshold = <3200>;
|
||||
qcom,vph-pwr-droop-debounce-time = <10>;
|
||||
qcom,headroom-sense-ch0-enabled;
|
||||
qcom,headroom-sense-ch1-enabled;
|
||||
qcom,die-current-derate-enabled;
|
||||
qcom,die-temp-vadc = <&pmi8994_vadc>;
|
||||
qcom,die-temp-threshold = <85 80 75 70 65>;
|
||||
qcom,die-temp-derate-current = <400 800 1200 1600 2000>;
|
||||
qcom,pmic-revid = <&pmi8994_revid>;
|
||||
|
||||
pm8226_flash0: qcom,flash_0 {
|
||||
label = "flash";
|
||||
qcom,led-name = "led:flash_0";
|
||||
qcom,default-led-trigger =
|
||||
"flash0_trigger";
|
||||
qcom,max-current = <1000>;
|
||||
qcom,id = <0>;
|
||||
qcom,duration = <1280>;
|
||||
qcom,current = <625>;
|
||||
};
|
||||
|
||||
pm8226_torch: qcom,torch_0 {
|
||||
label = "torch";
|
||||
qcom,led-name = "led:torch_0";
|
||||
qcom,default-led-trigger =
|
||||
"torch0_trigger";
|
||||
boost-supply = <&pm8226_chg_boost>;
|
||||
qcom,max-current = <200>;
|
||||
qcom,id = <0>;
|
||||
qcom,current = <120>;
|
||||
qcom,max-current = <200>;
|
||||
reg0 {
|
||||
regulator-name =
|
||||
"pm8226_chg_boost";
|
||||
max-voltage = <3600000>;
|
||||
};
|
||||
};
|
||||
|
||||
pm8226_switch: qcom,switch {
|
||||
lable = "switch";
|
||||
qcom,led-name = "led:switch";
|
||||
qcom,default-led-trigger =
|
||||
"switch_trigger";
|
||||
qcom,id = <2>;
|
||||
qcom,current = <625>;
|
||||
qcom,duration = <1280>;
|
||||
qcom,max-current = <1000>;
|
||||
reg0 {
|
||||
regulator-name =
|
||||
"pm8226_chg_boost";
|
||||
max-voltage = <3600000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -75,6 +75,9 @@ Optional properties for WLED:
|
||||
- qcom,lcd-auto-pfm-thresh : Specify the auto-pfm threshold, if the headroom voltage level
|
||||
falls below this threshold and auto PFM is enabled, boost
|
||||
controller will enter into PFM mode automatically.
|
||||
- qcom,lcd-psm-ctrl : A boolean property to specify if PSM needs to be
|
||||
controlled dynamically when WLED module is enabled
|
||||
or disabled.
|
||||
|
||||
Optional properties if 'qcom,disp-type-amoled' is mentioned in DT:
|
||||
- qcom,loop-comp-res-kohm : control to select the compensation resistor in kohm. default is 320.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
Qualcomm QPNP Leds
|
||||
Qualcomm Technologies, Inc. QPNP LEDs
|
||||
|
||||
QPNP (Qualcomm Plug N Play) LEDs driver is used for
|
||||
controlling LEDs that are part of PMIC on Qualcomm reference
|
||||
platforms. The PMIC is connected to Host processor via
|
||||
SPMI bus. This driver supports various LED modules such as
|
||||
Keypad backlight, WLED (white LED), RGB LED and flash LED.
|
||||
Qualcomm Technologies, Inc. Plug N Play (QPNP) LED modules
|
||||
are used for controlling LEDs that are connected to a QPNP PMIC.
|
||||
The PMIC is connected to a host processor via the SPMI bus. Various
|
||||
LED modules are supported such as Keypad backlight, WLED (white LED),
|
||||
RGB LED and flash LED.
|
||||
|
||||
Each LED module is represented as a node of "leds-qpnp". This
|
||||
node will further contain the type of LED supported and its
|
||||
@@ -83,7 +83,7 @@ Optional properties for RGB led:
|
||||
- qcom,turn-off-delay-ms: delay in millisecond for turning off the led when its default-state is "on". Value is being ignored in case default-state is "off".
|
||||
- qcom,use-blink: Use blink sysfs entry for switching into lpg mode. For optimal use, set default mode to pwm. All required lpg parameters must be supplied.
|
||||
|
||||
MPP LED is an LED controled through a Multi Purpose Pin.
|
||||
MPP LED is an LED controlled through a Multi Purpose Pin.
|
||||
|
||||
Optional properties for MPP LED:
|
||||
- linux,default-trigger: trigger the led from external modules such as display
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
Laser Sensor Device Tree Bindings.
|
||||
========================================
|
||||
|
||||
Boards with the Laser Sensor connected to CCI shall have the following
|
||||
properties:
|
||||
|
||||
Required node properties:
|
||||
- cell-index: cci hardware core index
|
||||
- compatible:
|
||||
- "st,stmvl53l0" : STMiecroelectronics VL53L0 Laser sensor.
|
||||
- reg : offset and length of the register set for the device
|
||||
- qcom, cci-master: cci master the sensor connected to
|
||||
- cam_cci-supply : cci voltage regulator used
|
||||
- cam_laser-supply: laser sensor voltage regulator
|
||||
- qcom,cam-vreg-name: voltage regulators name
|
||||
- qcom, cam-vreg-min-voltage: specify minimum voltage level for
|
||||
regulators used
|
||||
- qcom, cam-vreg-max-voltage: specify maximum voltage level for
|
||||
regulators used
|
||||
- pinctrl-names : should specify the pin control groups followed by
|
||||
the definition of each group
|
||||
stm,irq-gpio : irq gpio which is to provide interrupts to host.
|
||||
- gpios : should contain phandle to gpio controller node and array of
|
||||
#gpio-cells specifying specific gpio (controller specific)
|
||||
- qcom,gpio-req-tbl-num : contains index to gpios specific to the sensor
|
||||
- qcom,gpio-req-tbl-flags : should contain direction of gpios present in
|
||||
qcom,gpio-req-tbl-num property (in the same order)
|
||||
- qcom,gpio-req-tbl-label : should contain name of gpios present in
|
||||
qcom,gpio-req-tbl-num property (in the same order)
|
||||
@@ -6,10 +6,14 @@ Required properties:
|
||||
- reg : offset and length of msm camera device registers.
|
||||
- reg-names : should specify relevant names for each reg property defined.
|
||||
|
||||
Optional properties:
|
||||
- qcom,gpu-limit : valid kgsl frequency.
|
||||
|
||||
Example:
|
||||
|
||||
qcom,msm-cam@fd8c0000 {
|
||||
compatible = "qcom,msm-cam";
|
||||
reg = <0xfd8C0000 0x10000>;
|
||||
reg-names = "msm-cam";
|
||||
qcom,gpu-limit = <700000000>;
|
||||
};
|
||||
|
||||
@@ -70,6 +70,13 @@ Optional properties:
|
||||
The first entry is register offset and second entry is register value.
|
||||
- qcom,micro-reset: Boolean flag indicating if micro reset need to be enabled.
|
||||
This needs to present on platforms that support this feature.
|
||||
- qcom,cpp-cx-ipeak: To handle Cx peak current limit.
|
||||
<phandle bit>
|
||||
phandle - phandle of cx ipeak device node
|
||||
bit - bit number of client in relevant register
|
||||
This is used to access Cx ipeak HW module to limit the current drawn by
|
||||
various subsystem blocks on Cx power rail. CPP set their bit in tcsr register
|
||||
if it is going to cross its own threshold.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -105,6 +112,7 @@ Example:
|
||||
"micro_iface_clk", "camss_ahb_clk";
|
||||
"smmu_cpp_axi_clk", "cpp_vbif_ahb_clk";
|
||||
qcom,clock-rates = <0 0 0 0 465000000 0 0 465000000 0 0 0 0>;
|
||||
qcom,cpp-cx-ipeak = <&cx_ipeak_lm 2>;
|
||||
qcom,min-clock-rate = <320000000>;
|
||||
qcom,bus-master = <1>;
|
||||
qcom,vbif-qos-setting = <0x20 0x10000000>,
|
||||
|
||||
@@ -23,6 +23,7 @@ Required properties for child node:
|
||||
Only needed for child node.
|
||||
- "vfe" - Required.
|
||||
- "vfe_vbif" - Optional for "vfe32". Required for "vfe40".
|
||||
- "vfe_fuse" - Optional.
|
||||
- interrupts : should contain the vfe interrupt.
|
||||
- interrupt-names : should specify relevant names to each interrupts
|
||||
property defined.
|
||||
@@ -52,9 +53,10 @@ Example:
|
||||
vfe0: qcom,vfe0@fda10000 {
|
||||
cell-index = <0>;
|
||||
compatible = "qcom,vfe44";
|
||||
reg = <0xfda10000 0x1000>;
|
||||
<0xfda40000 0x200>;
|
||||
reg-names = "vfe", "vfe_vbif";
|
||||
reg = <0xfda10000 0x1000>,
|
||||
<0xfda40000 0x200>,
|
||||
<0x7801a4 0x8>;
|
||||
reg-names = "vfe", "vfe_vbif", "vfe_fuse";
|
||||
interrupts = <0 57 0>;
|
||||
interrupt-names = "vfe";
|
||||
vdd-supply = <&gdsc_vfe>;
|
||||
@@ -105,9 +107,10 @@ vfe0: qcom,vfe0@fda10000 {
|
||||
vfe1: qcom,vfe1@fda14000 {
|
||||
cell-index = <1>;
|
||||
compatible = "qcom,vfe44";
|
||||
reg = <0xfda14000 0x1000>;
|
||||
<0xfda40000 0x200>;
|
||||
reg-names = "vfe", "vfe_vbif";
|
||||
reg = <0xfda14000 0x1000>,
|
||||
<0xfda40000 0x200>,
|
||||
<0x7801a4 0x8>;
|
||||
reg-names = "vfe", "vfe_vbif", "vfe_fuse";
|
||||
interrupts = <0 58 0>;
|
||||
interrupt-names = "vfe";
|
||||
vdd-supply = <&gdsc_vfe>;
|
||||
|
||||
@@ -126,7 +126,7 @@ Optional properties:
|
||||
internal persist1 = 0x400
|
||||
internal cmd queue = 0x800
|
||||
- qcom,pm-qos-latency-us = The latency used to vote for QOS power manager. This
|
||||
value is typically max(latencies of every cluster at all power levels) + 1
|
||||
value is typically max(latencies of every cluster at all power levels) + 1
|
||||
- qcom,max-secure-instances = An int containing max number of concurrent secure
|
||||
instances supported, accounting for venus and system wide limitations like
|
||||
memory, performance etc.
|
||||
@@ -135,6 +135,12 @@ value is typically max(latencies of every cluster at all power levels) + 1
|
||||
- qcom,power-conf = Indicates the value at which or beyond, a video session
|
||||
is configured in low power mode to have power benefits. Value is defined
|
||||
interms of HxW of the video session beyond which power benefit is desired.
|
||||
- qcom,cx-ipeak-data : phandle of cx_ipeak device node and bit position on
|
||||
the cx register where venus is supposed to vote
|
||||
- qcom,clock-freq-threshold : Operating threshold frequency of venus which
|
||||
video driver uses to check against the frequency voted. Whenever venus
|
||||
clock frequency crosses this mark, driver intimates cx ipeak driver on
|
||||
supported targets.
|
||||
|
||||
[Second level nodes]
|
||||
Context Banks
|
||||
|
||||
@@ -5,37 +5,148 @@ Modem Host Interface protocol. The bindings referred to below, enable
|
||||
the correct configuration of the interface and required sideband
|
||||
signals.
|
||||
|
||||
Required properties:
|
||||
- compatible: should be "qcom,mhi"
|
||||
- Refer to "Documentation/devicetree/bindings/esoc/esoc_client.txt" for
|
||||
below properties:
|
||||
- esoc-names
|
||||
- esoc-0
|
||||
- Refer to "Documentation/devicetree/bindings/arm/msm/msm_bus.txt" for
|
||||
below optional properties:
|
||||
- qcom,msm-bus,name
|
||||
- qcom,msm-bus,num-cases
|
||||
- qcom,msm-bus,num-paths
|
||||
- qcom,msm-bus,vectors-KBps
|
||||
- mhi-chan-cfg-#: mhi channel configuration parameters for platform
|
||||
- mhi-event-cfg-#: mhi event ring configuration parameters for platform
|
||||
- mhi-event-rings: number of event rings supported by platform
|
||||
- mhi-dev-address-win-size: size of the MHI device addressing window
|
||||
==============
|
||||
Node Structure
|
||||
==============
|
||||
|
||||
Main node properties:
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: "qcom,mhi"
|
||||
|
||||
- qcom,pci-dev_id
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: Device id reported by modem
|
||||
|
||||
- qcom,pci-domain
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: PCIE root complex device connected to
|
||||
|
||||
- qcom,pci-bus
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: PCIE bus device connected to
|
||||
|
||||
- qcom,pci-slot
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: PCIE slot (dev_id/function) device connected to
|
||||
|
||||
- esoc-names
|
||||
Usage: optional
|
||||
Value type: <string>
|
||||
Definition: esoc name for the device
|
||||
|
||||
- esoc-0
|
||||
Usage: required if "esoc-names" is defined
|
||||
Value type: phandle
|
||||
Definition: A phandle pointing to the esoc node.
|
||||
|
||||
- qcom,msm-bus,name
|
||||
Usage: required if MHI is bus master
|
||||
Value type: string
|
||||
Definition: string representing the client name
|
||||
|
||||
- qcom,msm-bus,num-cases
|
||||
Usage: required if MHI is bus master
|
||||
Value type: <u32>
|
||||
Definition: Number of use cases MHI support. Must be set to 2.
|
||||
|
||||
- qcom,msm-bus,num-paths
|
||||
Usage: required if MHI is bus master
|
||||
Value type: <u32>
|
||||
Definition: Total number of master-slave pairs. Must be set to one.
|
||||
|
||||
- qcom,msm-bus,vectors-KBps
|
||||
Usage: required if MHI is bus master
|
||||
Value type: Array of <u32>
|
||||
Definition: Array of tuples which define the bus bandwidth requirements.
|
||||
Each tuple is of length 4, values are master-id, slave-id,
|
||||
arbitrated bandwidth in KBps, and instantaneous bandwidth in
|
||||
KBps.
|
||||
|
||||
- mhi-chan-cfg-#
|
||||
Usage: required
|
||||
Value type: Array of <u32>
|
||||
Definition: mhi channel configuration parameters for platform
|
||||
defined as below <A B C D>:
|
||||
A = chan number
|
||||
B = maximum descriptors
|
||||
C = event ring associated with channel
|
||||
D = flags defined by mhi_macros.h GET_CHAN_PROPS
|
||||
|
||||
- mhi-event-rings
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: Number of event rings device support
|
||||
|
||||
- mhi-event-cfg-#
|
||||
Usage: required
|
||||
Value type: Array of <u32>
|
||||
Definition: mhi event ring configuration parameters for platform
|
||||
defined as below <A B C D E F>:
|
||||
A = maximum event descriptors
|
||||
B = MSI associated with event
|
||||
C = interrupt moderation (see MHI specification)
|
||||
D = Associated channel
|
||||
E = priority of the event ring. 0 being the highest.
|
||||
F = flags defined by mhi_macros.h GET_EV_PROPS
|
||||
|
||||
- qcom,mhi-address-window
|
||||
Usage: required
|
||||
Value type: Array of <u64>
|
||||
Definition: start DDR address and ending DDR address device can access.
|
||||
|
||||
- qcom,mhi-manage-boot
|
||||
Usage: optional
|
||||
Value type: bool
|
||||
Definition: Determine whether MHI host manages firmware download to device.
|
||||
|
||||
- qcom,mhi-fw-image
|
||||
Usage: required if MHI host managing firmware download process
|
||||
Value type: string
|
||||
Definition: firmware image name
|
||||
|
||||
- qcom,mhi-max-sbl
|
||||
Usage: required if MHI host managing firmware download process
|
||||
Value type: <u32>
|
||||
Definition: Maximum size in bytes SBL image device support.
|
||||
|
||||
- qcom,mhi-sg-size
|
||||
Usage: required if MHI host managing firmware download process
|
||||
Value type: <u32>
|
||||
Definition: Segment size in bytes for each segment in bytes.
|
||||
|
||||
- qcom,mhi-bb-required
|
||||
Usage: optional
|
||||
Value type: bool
|
||||
Definition: Determine whether MHI device require bounce buffer
|
||||
during active transfer. If true, during channel open host
|
||||
will pre-allocate transfer buffers.
|
||||
|
||||
========
|
||||
Example:
|
||||
|
||||
mhi: qcom,mhi {
|
||||
compatible = "qcom,mhi";
|
||||
esoc-names = "mdm";
|
||||
esoc-0 = <&mdm1>;
|
||||
qcom,msm-bus,name = "mhi";
|
||||
qcom,msm-bus,num-cases = <2>;
|
||||
qcom,msm-bus,num-paths = <1>;
|
||||
qcom,msm-bus,vectors-KBps =
|
||||
<100 512 0 0>,
|
||||
<100 512 1200000000 1200000000>;
|
||||
mhi-event-rings = <6>;
|
||||
mhi-chan-cfg-102 = <0x66 0x80 0x5 0x62>;
|
||||
mhi-event-cfg-0 = <0x80 0x0 0x0 0x11>;
|
||||
mhi-dev-address-win-size= <0x10 0x00000000>;
|
||||
};
|
||||
========
|
||||
mhi: qcom,mhi {
|
||||
compatible = "qcom,mhi";
|
||||
qcom,pci-dev_id = <0x0301>;
|
||||
qcom,pci-domain = <2>;
|
||||
qcom,pci-bus = <4>;
|
||||
qcom,pci-slot = <0>;
|
||||
qcom,mhi-address-window = <0x0 0x80000000 0x0 0xbfffffff>;
|
||||
esoc-names = "mdm";
|
||||
esoc-0 = <&mdm1>;
|
||||
qcom,msm-bus,name = "mhi";
|
||||
qcom,msm-bus,num-cases = <2>;
|
||||
qcom,msm-bus,num-paths = <1>;
|
||||
qcom,msm-bus,vectors-KBps =
|
||||
<100 512 0 0>,
|
||||
<100 512 1200000000 1200000000>;
|
||||
mhi-event-rings = <1>;
|
||||
mhi-chan-cfg-102 = <0x66 0x80 0x5 0x62>;
|
||||
mhi-event-cfg-0 = <0x80 0x0 0x0 0x0 0 1 0x11>;
|
||||
};
|
||||
|
||||
@@ -17,23 +17,9 @@ Optional properties:
|
||||
"qcom,pwm-sel" property.
|
||||
|
||||
Example:
|
||||
qcom,spmi@fc4c0000 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <3>;
|
||||
|
||||
qcom,pm8941@0 {
|
||||
spmi-slave-container;
|
||||
reg = <0x0>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
qcom,misc@900 {
|
||||
compatible = "qcom,qpnp-misc";
|
||||
reg = <0x900 0x100>;
|
||||
qcom,pwm-sel = <2>;
|
||||
qcom,enable-gp-driver;
|
||||
};
|
||||
}
|
||||
qcom,misc@900 {
|
||||
compatible = "qcom,qpnp-misc";
|
||||
reg = <0x900 0x100>;
|
||||
qcom,pwm-sel = <2>;
|
||||
qcom,enable-gp-driver;
|
||||
};
|
||||
|
||||
@@ -9,8 +9,26 @@ receive(RX)/transmit(TX) control.
|
||||
|
||||
Required properties:
|
||||
- compatible: "qcom,wcn3990-wifi";
|
||||
- reg: Memory regions defined as starting address and size
|
||||
- reg-names: Names of the memory regions defined in reg entry
|
||||
- interrupts: Copy engine interrupt table
|
||||
|
||||
Example:
|
||||
qcom,msm_ath10k@18000000 {
|
||||
msm_ath10k_wlan: qcom,msm_ath10k_wlan@18800000 {
|
||||
compatible = "qcom,wcn3990-wifi";
|
||||
reg = <0x18800000 0x800000>;
|
||||
reg-names = "membase";
|
||||
interrupts =
|
||||
<0 130 0 /* CE0 */ >,
|
||||
<0 131 0 /* CE1 */ >,
|
||||
<0 132 0 /* CE2 */ >,
|
||||
<0 133 0 /* CE3 */ >,
|
||||
<0 134 0 /* CE4 */ >,
|
||||
<0 135 0 /* CE5 */ >,
|
||||
<0 136 0 /* CE6 */ >,
|
||||
<0 137 0 /* CE7 */ >,
|
||||
<0 138 0 /* CE8 */ >,
|
||||
<0 139 0 /* CE9 */ >,
|
||||
<0 140 0 /* CE10 */ >,
|
||||
<0 141 0 /* CE11 */ >;
|
||||
};
|
||||
|
||||
@@ -89,6 +89,13 @@ Optional properties:
|
||||
- qcom,cx-ipeak-vote: Boolean- Present if we need to set bit 5 of cxip_lm_vote_clear
|
||||
during modem shutdown
|
||||
|
||||
One child node to represent the MBA image may be specified, when the MBA image
|
||||
needs to be loaded in a specifically carved out memory region.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "qcom,pil-mba-mem"
|
||||
- memory-region: A phandle that points to a reserved memory where the MBA image will be loaded.
|
||||
|
||||
Example:
|
||||
qcom,mss@fc880000 {
|
||||
compatible = "qcom,pil-q6v5-mss";
|
||||
@@ -128,4 +135,9 @@ Example:
|
||||
qcom,gpio-force-stop = <&smp2pgpio_ssr_smp2p_1_out 0 0>;
|
||||
qcom,ssctl-instance-id = <12>;
|
||||
qcom,sysmon-id = <0>;
|
||||
|
||||
qcom,mba-mem@0 {
|
||||
compatible = "qcom,pil-mba-mem";
|
||||
memory-region = <&peripheral_mem>;
|
||||
};
|
||||
};
|
||||
|
||||
@@ -0,0 +1,55 @@
|
||||
MSM MHI UCI interface device
|
||||
|
||||
MHI userpace control interface (UCI) enables userspace software clients to
|
||||
communicate with device using MHI protocol.
|
||||
|
||||
==============
|
||||
Node Structure
|
||||
==============
|
||||
|
||||
Main node properties:
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: "qcom,mhi-uci"
|
||||
|
||||
- qcom,mhi-uci-channels
|
||||
Usage: required
|
||||
Value type: Array of <u32>
|
||||
Definition: Array tuples which define the channel configuration
|
||||
parameters. Each tuple is of length 2, 1st value
|
||||
represent channel, and 2nd value represent maximum
|
||||
payload supported. Maximum payload supported is 64
|
||||
bytes. Number of tuples must be even value. Max # of
|
||||
tuples is 46.
|
||||
|
||||
- qcom,mhi-uci-ctrlchan
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Channel that will be handling flow control (DTR/RTS) signals.
|
||||
|
||||
=======
|
||||
Example
|
||||
=======
|
||||
qcom,mhi-uci@0 {
|
||||
compatible = "qcom,mhi-uci";
|
||||
qcom,mhi-uci-channels = <0 0x1000>,
|
||||
<1 0x1000>,
|
||||
<2 0x1000>,
|
||||
<3 0xffff>,
|
||||
<10 0x1000>,
|
||||
<11 0x1000>,
|
||||
<14 0x1000>,
|
||||
<15 0x1000>,
|
||||
<16 0x1000>,
|
||||
<17 0x1000>,
|
||||
<18 0x1000>,
|
||||
<19 0x1000>,
|
||||
<24 0x1000>,
|
||||
<25 0x1000>,
|
||||
<32 0x1000>,
|
||||
<33 0x1000>;
|
||||
qcom,mhi-uci-ctrlchan = <18>;
|
||||
status = "ok";
|
||||
};
|
||||
@@ -0,0 +1,59 @@
|
||||
MSM MHI RMNET interface device
|
||||
|
||||
MHI RMNET provides a network interface over PCIe to transfer IP packets
|
||||
between modem and apps.
|
||||
|
||||
==============
|
||||
Node Structure
|
||||
==============
|
||||
|
||||
Main node properties:
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: "qcom,mhi-rmnet"
|
||||
|
||||
- qcom,mhi-rx-channel
|
||||
Usage: optional if mhi-tx-channel is defined.
|
||||
Value type: <u32>
|
||||
Definition: MHI channel number for incoming data
|
||||
|
||||
- qcom,mhi-tx-channel
|
||||
Usage: optional if mhi-rx-channel is defined.
|
||||
Value type: <u32>
|
||||
Definition: MHI channel number for outgoing data
|
||||
|
||||
- qcom,mhi-mru
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: Default payload size for receive path.
|
||||
|
||||
- qcom,mhi-max-mru
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Maximum payload interface support on receive path. If
|
||||
not defined MHI_MAX_MRU is used.
|
||||
|
||||
- qcom,mhi-max-mtu
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Maximum payload interface support on transmit path. If
|
||||
not defined MHI_MAX_MTU is used.
|
||||
|
||||
- qcom,interface-name
|
||||
Usage: optional
|
||||
Value type: <string>
|
||||
Definition: optional string to overwrite default interface name. If
|
||||
not defined string RMNET_MHI_DRIVER_NAME is used.
|
||||
|
||||
========
|
||||
Example:
|
||||
========
|
||||
mhi_rmnet_0: qcom,mhi-rmnet@0 {
|
||||
compatible = "qcom,mhi-rmnet";
|
||||
qcom,mhi-rx-channel = <101>;
|
||||
qcom,mhi-tx-channel = <100>;
|
||||
qcom,mhi-mru = <8000>;
|
||||
status = "okay";
|
||||
};
|
||||
@@ -1,4 +1,4 @@
|
||||
Qualcomm QPNP Coincell - coincell battery charger devices
|
||||
Qualcomm Technologies, Inc. QPNP Coincell - coincell battery charger devices
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "qcom,qpnp-coincell".
|
||||
|
||||
@@ -215,6 +215,12 @@ First Level Node - FG Gen3 device
|
||||
capacity learning cycle. If this is not specified, then
|
||||
the default value is 0. Unit is in decipercentage.
|
||||
|
||||
- qcom,battery-thermal-coefficients
|
||||
Usage: optional
|
||||
Value type: <u8>
|
||||
Definition: Byte array of battery thermal coefficients.
|
||||
This should be exactly 3 bytes in length.
|
||||
|
||||
- qcom,fg-jeita-hyst-temp
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
@@ -272,6 +278,14 @@ First Level Node - FG Gen3 device
|
||||
is specified, then ESR to Rslow scaling factors will be
|
||||
updated to account it for an accurate ESR.
|
||||
|
||||
- qcom,fg-esr-clamp-mohms
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Equivalent series resistance (ESR) in milliohms. If this
|
||||
is specified, then ESR will be clamped to this value when
|
||||
ESR is found to be dropping below this. Default value is
|
||||
20.
|
||||
|
||||
- qcom,fg-esr-filter-switch-temp
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
@@ -320,6 +334,27 @@ First Level Node - FG Gen3 device
|
||||
to be configured in conjunction with the charger side
|
||||
configuration for proper functionality.
|
||||
|
||||
- qcom,slope-limit-temp-threshold
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Battery temperature threshold to decide when slope limit
|
||||
coefficients should be applied along with charging status.
|
||||
Unit is in decidegC.
|
||||
|
||||
- qcom,slope-limit-coeffs
|
||||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A list of integers which holds the slope limit coefficients
|
||||
in the following order. Allowed size is 4. Possible values
|
||||
are from 0 to 31. Unit is in decipercentage.
|
||||
Element 0 - Low temperature discharging
|
||||
Element 1 - Low temperature charging
|
||||
Element 2 - High temperature discharging
|
||||
Element 3 - High temperature charging
|
||||
These coefficients have to be specified along with the
|
||||
property "qcom,slope-limit-temp-threshold" to make dynamic
|
||||
slope limit adjustment functional.
|
||||
|
||||
==========================================================
|
||||
Second Level Nodes - Peripherals managed by FG Gen3 driver
|
||||
==========================================================
|
||||
@@ -354,6 +389,9 @@ pmi8998_fg: qpnp,fg {
|
||||
qcom,ki-coeff-soc-dischg = <30 60 90>;
|
||||
qcom,ki-coeff-med-dischg = <800 1000 1400>;
|
||||
qcom,ki-coeff-hi-dischg = <1200 1500 2100>;
|
||||
qcom,slope-limit-temp-threshold = <100>;
|
||||
qcom,slope-limit-coeffs = <10 11 12 13>;
|
||||
qcom,battery-thermal-coefficients = [9d 50 ff];
|
||||
status = "okay";
|
||||
|
||||
qcom,fg-batt-soc@4000 {
|
||||
|
||||
@@ -1,275 +0,0 @@
|
||||
QTI's QPNP PMIC Fuel Gauge Device
|
||||
|
||||
QPNP PMIC FG provides interface to clients to read properties related
|
||||
to the battery. Its main function is to retrieve the State of Charge (SOC),
|
||||
a 0-100 percentage representing the amount of charge left in the battery.
|
||||
|
||||
There are two required peripherals in the FG driver, both implemented as
|
||||
subnodes in the example. These peripherals must not be disabled if the FG
|
||||
device is to enabled:
|
||||
|
||||
- qcom,fg-soc : The main FG device. Supports battery fuel gauge controls and
|
||||
sensors.
|
||||
- qcom,fg-batt : The FG battery device supports interrupts and controls with
|
||||
respect to the state of the connected battery.For example: the
|
||||
peripheral informs the driver if the battery has been identified
|
||||
by the fuel gauge based on a given battery resistance range.
|
||||
|
||||
Optionally ADC nodes can be added
|
||||
- qcom,revid-tp-rev: A subnode with a register address for the TP_REV register
|
||||
in the REVID peripheral. This is used to apply workarounds that
|
||||
may depend on the trim program.
|
||||
- qcom,fg-adc-vbat : A subnode with a register address for the FG_ADC_USR
|
||||
peripheral which is used mainly for battery current limiting (BCL).
|
||||
This node maps out the VBAT reading register which allows to have
|
||||
a +/- 32 mV accurate reading of VBAT.
|
||||
- qcom,fg-adc-ibat : A subnode with a register address for the FG_ADC_USR
|
||||
peripheral which is used mainly for battery current limiting (BCL).
|
||||
This node maps out the IBAT current reading register which allows
|
||||
to have a +/- 32 mA accurate reading of IBAT.
|
||||
|
||||
Parent node required properties:
|
||||
- compatible : should be "qcom,qpnp-fg" for the FG driver.
|
||||
- qcom,pmic-revid : Should specify the phandle of PMIC
|
||||
revid module. This is used to identify
|
||||
the PMIC subtype.
|
||||
|
||||
Parent node optional properties:
|
||||
- qcom,warm-bat-decidegc: Warm battery temperature in decidegC.
|
||||
- qcom,cool-bat-decidegc: Cool battery temperature in decidegC.
|
||||
- qcom,hot-bat-decidegc: Hot battery temperature in decidegC.
|
||||
- qcom,cold-bat-decidegc: Cold battery temperature in decidegC.
|
||||
- qcom,cold-hot-jeita-hysteresis: A tuple of 2. Index[0] is cold
|
||||
hysteresis and index[1] is hot
|
||||
hysterisis(in decidegC).
|
||||
- qcom,ext-sense-type: Current sense channel used by the FG.
|
||||
Set this to use external rsense.
|
||||
- qcom,thermal-coefficients: Byte array of thermal coefficients for
|
||||
reading battery thermistor. This should
|
||||
be exactly 6 bytes in length.
|
||||
Example: [01 02 03 04 05 06]
|
||||
- qcom,resume-soc: soc to resume charging in percentage.
|
||||
- qcom,resume-soc-raw: soc to resume charging in the scale of
|
||||
[0-255]. This overrides qcom,resume-soc
|
||||
if defined.
|
||||
- qcom,hold-soc-while-full: A boolean property that when defined
|
||||
holds SOC at 100% when the battery is
|
||||
full.
|
||||
- qcom,bcl-lm-threshold-ma: BCL LPM to MPM mode transition threshold
|
||||
in milliAmpere.
|
||||
- qcom,bcl-mh-threshold-ma: BCL MPM to HPM mode transition threshold
|
||||
in milliAmpere.
|
||||
- qcom,use-otp-profile: Specify this flag to avoid RAM loading
|
||||
any battery profile.
|
||||
- qcom,sw-rbias-control: Boolean property which defines whether
|
||||
the Rbias needs to be controlled by
|
||||
software. If this is not set, it will
|
||||
be controlled by hardware (default).
|
||||
- qcom,fg-iterm-ma: Battery current at which the fuel gauge
|
||||
will try to scale 100% towards. When
|
||||
the charge current goes above this, the
|
||||
SoC should be at 100%.
|
||||
- qcom,fg-chg-iterm-ma: Battery current at which the fuel gauge
|
||||
will issue end of charge if the charger
|
||||
is configured to use the fuel gauge
|
||||
ADCs for end of charge detection. This
|
||||
property is in milliamps and should be
|
||||
positive (e.g. 100mA to terminate at
|
||||
-100mA).
|
||||
- qcom,irq-volt-empty-mv: The voltage threshold that the empty
|
||||
soc interrupt will be triggered. When
|
||||
the empty soc interrupt fires, battery
|
||||
soc will be pulled to 0 and the
|
||||
userspace will be notified via the
|
||||
power supply framework. The userspace
|
||||
will read 0% soc and immediately
|
||||
shutdown.
|
||||
- qcom,fg-cutoff-voltage-mv: The voltage where the fuel gauge will
|
||||
steer the SOC to be zero. For example,
|
||||
if the cutoff voltage is set to 3400mv,
|
||||
the fuel gauge will try to count SoC so
|
||||
that the battery SoC will be 0 when it
|
||||
is 3400mV.
|
||||
- qcom,fg-vbat-estimate-diff-mv: If the estimated voltage based on SoC
|
||||
and battery current/resistance differs
|
||||
from the actual voltage by more than
|
||||
this amount, the fuel gauge will
|
||||
redo the first SoC estimate when the
|
||||
driver probes.
|
||||
- qcom,fg-delta-soc: How many percent the monotonic SoC must
|
||||
change before a new delta_soc interrupt
|
||||
is asserted. If this value is raised
|
||||
above 3-4, some period workarounds may
|
||||
not function well, so it's best to
|
||||
leave this at 1 or 2%.
|
||||
- qcom,fg-vbatt-low-threshold: Voltage (in mV) which upon set will be
|
||||
used for configuring the low battery
|
||||
voltage threshold. Interrupt will be
|
||||
asserted and handled based upon
|
||||
this. If this property is not specified,
|
||||
low battery voltage threshold will be
|
||||
configured to 4200 mV.
|
||||
- qcom,cycle-counter-en: Boolean property which enables the cycle
|
||||
counter feature. If this property is
|
||||
present, then the following properties
|
||||
to specify low and high soc thresholds
|
||||
should be defined.
|
||||
- qcom,capacity-learning-on: A boolean property to have the fuel
|
||||
gauge driver attempt to learn the
|
||||
battery capacity when charging. Takes
|
||||
precedence over capacity-estimation-on.
|
||||
- qcom,capacity-learning-feedback: A boolean property to have the fuel
|
||||
gauge driver to feedback the learned
|
||||
capacity into the capacity learning
|
||||
algorithm. This has to be used only if
|
||||
the property "qcom,capacity-learning-on"
|
||||
is specified.
|
||||
- qcom,cl-max-increment-deciperc: The maximum percent that the capacity
|
||||
can rise as the result of a single
|
||||
charge cycle. This property corresponds
|
||||
to .1% increments.
|
||||
- qcom,cl-max-decrement-deciperc: The maximum percent that the capacity
|
||||
can fall as the result of a single
|
||||
charge cycle. This property corresponds
|
||||
to .1% decrements.
|
||||
- qcom,cl-max-temp-decidegc: Above this temperature, capacity
|
||||
learning will be canceled.
|
||||
- qcom,cl-mix-temp-decidegc: Below this temperature, capacity
|
||||
learning will be canceled.
|
||||
- qcom,cl-max-start-soc: The battery soc has to be below this
|
||||
value at the start of a charge cycle
|
||||
for capacity learning to be run.
|
||||
- qcom,cl-vbat-est-thr-uv: The maximum difference between the
|
||||
battery voltage shadow and the current
|
||||
predicted voltage in uV to initiate
|
||||
capacity learning.
|
||||
- qcom,capacity-estimation-on: A boolean property to have the fuel
|
||||
gauge driver attempt to estimate the
|
||||
battery capacity using battery
|
||||
resistance.
|
||||
- qcom,aging-eval-current-ma: Current used to evaluate battery aging.
|
||||
This value should be around the steady
|
||||
state current drawn from the battery
|
||||
when the phone is low on battery.
|
||||
- qcom,fg-cc-cv-threshold-mv: Voltage threshold in mV for configuring
|
||||
constant charge (CC) to constant
|
||||
voltage (CV) setpoint in FG upon
|
||||
which the battery EOC status will
|
||||
be determined. This value should be
|
||||
10 mV less than the float voltage
|
||||
configured in the charger.
|
||||
This property should only be specified
|
||||
if "qcom,autoadjust-vfloat" property is
|
||||
specified in the charger driver to
|
||||
ensure a proper operation.
|
||||
- qcom,bad-battery-detection-enable: A boolean property to enable the fuel
|
||||
gauge driver to detect the damaged battery
|
||||
when the safety-timer expires by using the
|
||||
coulomb count.
|
||||
- qcom,fg-therm-delay-us: The time in microseconds to delay battery
|
||||
thermistor biasing.
|
||||
- qcom,esr-pulse-tuning-en: A boolean property to enable ESR pulse
|
||||
tuning feature. If this is enabled,
|
||||
ESR pulse extraction will be disabled
|
||||
when state of charge (SOC) is less than
|
||||
2%. It will be enabled back when SOC
|
||||
gets above 2%. In addition, for SOC
|
||||
between 2% and 5%, ESR pulse timing
|
||||
settings will be different from default.
|
||||
Once SOC crosses 5%, ESR pulse timings
|
||||
will be restored back to default.
|
||||
|
||||
qcom,fg-soc node required properties:
|
||||
- reg : offset and length of the PMIC peripheral register map.
|
||||
- interrupts : the interrupt mappings.
|
||||
The format should be
|
||||
<slave-id peripheral-id interrupt-number>.
|
||||
- interrupt-names : names for the mapped fg soc interrupts
|
||||
The following interrupts are required:
|
||||
0: high-soc
|
||||
1: low-soc
|
||||
2: full-soc
|
||||
3: empty-soc
|
||||
4: delta-soc
|
||||
5: first-est-done
|
||||
6: sw-fallbk-ocv
|
||||
7: sw-fallbk-new-batt
|
||||
|
||||
qcom,fg-memif node required properties:
|
||||
- reg : offset and length of the PMIC peripheral register map.
|
||||
- interrupts : the interrupt mappings.
|
||||
The format should be
|
||||
<slave-id peripheral-id interrupt-number>.
|
||||
- interrupt-names : names for the mapped fg adc interrupts
|
||||
The following interrupts are required:
|
||||
0: mem-avail
|
||||
|
||||
Example:
|
||||
pmi8994_fg: qcom,fg {
|
||||
compatible = "qcom,qpnp-fg";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
status = "disabled";
|
||||
qcom,pmic-revid = <&pmi8994_revid>;
|
||||
|
||||
qcom,fg-soc@4000 {
|
||||
reg = <0x4000 0x100>;
|
||||
interrupts = <0x2 0x40 0x0>,
|
||||
<0x2 0x40 0x1>,
|
||||
<0x2 0x40 0x2>,
|
||||
<0x2 0x40 0x3>,
|
||||
<0x2 0x40 0x4>,
|
||||
<0x2 0x40 0x5>,
|
||||
<0x2 0x40 0x6>,
|
||||
<0x2 0x40 0x7>;
|
||||
|
||||
interrupt-names = "high-soc",
|
||||
"low-soc",
|
||||
"full-soc",
|
||||
"empty-soc",
|
||||
"delta-soc",
|
||||
"first-est-done",
|
||||
"sw-fallbk-ocv",
|
||||
"sw-fallbk-new-batt";
|
||||
};
|
||||
|
||||
qcom,fg-batt@4100 {
|
||||
reg = <0x4100 0x100>;
|
||||
interrupts = <0x2 0x41 0x0>,
|
||||
<0x2 0x41 0x1>,
|
||||
<0x2 0x41 0x2>,
|
||||
<0x2 0x41 0x3>,
|
||||
<0x2 0x41 0x4>,
|
||||
<0x2 0x41 0x5>,
|
||||
<0x2 0x41 0x6>,
|
||||
<0x2 0x41 0x7>;
|
||||
|
||||
interrupt-names = "soft-cold",
|
||||
"soft-hot",
|
||||
"vbatt-low",
|
||||
"batt-ided",
|
||||
"batt-id-req",
|
||||
"batt-unknown",
|
||||
"batt-missing",
|
||||
"batt-match";
|
||||
};
|
||||
|
||||
qcom,fg-adc-vbat@4254 {
|
||||
reg = <0x4254 0x1>;
|
||||
};
|
||||
|
||||
qcom,fg-adc-ibat@4255 {
|
||||
reg = <0x4255 0x1>;
|
||||
};
|
||||
|
||||
qcom,fg-memif@4400 {
|
||||
reg = <0x4400 0x100>;
|
||||
interrupts = <0x2 0x44 0x0>,
|
||||
<0x2 0x44 0x1>;
|
||||
|
||||
interrupt-names = "mem-avail",
|
||||
"data-rcvry-sug";
|
||||
|
||||
qcom,cold-hot-jeita-hysteresis = <30 50>;
|
||||
};
|
||||
};
|
||||
@@ -1,394 +0,0 @@
|
||||
QPNP SMB Battery Charger
|
||||
|
||||
QPNP SMB Charger is a single-cell switching mode battery charger. It can charge
|
||||
the battery and power the system via the USB and AC adapter input.
|
||||
|
||||
The QPNP SMB Charger interfaces via the SPMI bus.
|
||||
|
||||
There are six different peripherals adding the following functionality.
|
||||
Each of these peripherals are implemented as subnodes in the example at the
|
||||
end of this file.
|
||||
|
||||
- qcom,chgr: Supports charging control and status
|
||||
reporting.
|
||||
- qcom,bat-if: Battery status reporting such as presence,
|
||||
temperature reporting and voltage collapse
|
||||
protection.
|
||||
- qcom,usb-chgpth: USB charge path detection and input current
|
||||
limiting configuration.
|
||||
- qcom,dc-chgpth: DC charge path detection and input current
|
||||
limiting configuration.
|
||||
- qcom,chg-misc: Miscellaneous features such as watchdog timers
|
||||
and SYSOK pin control
|
||||
- qcom,chg-otg: OTG configuration control.
|
||||
|
||||
Parent node required properties:
|
||||
- compatible: Must be "qcom,qpnp-smbcharger"
|
||||
- #address-cells: Must be <1>
|
||||
- #size-cells: Must be <1>
|
||||
- qcom,pmic-revid: Should specify the phandle of PMIC
|
||||
revid module. This is used to identify
|
||||
the PMIC subtype.
|
||||
|
||||
|
||||
|
||||
Sub node required properties:
|
||||
- reg: The SPMI address for this peripheral
|
||||
- interrupts: Specifies the interrupt associated with the peripheral.
|
||||
- interrupt-names: Specifies the interrupt names for the peripheral. Every
|
||||
available interrupt needs to have an associated name
|
||||
with it to indentify its purpose.
|
||||
|
||||
The following lists each subnode and their corresponding
|
||||
required interrupt names:
|
||||
|
||||
qcom,chgr:
|
||||
- chg-tcc-thr: Triggers on charge completion.
|
||||
- chg-taper-thr: Triggers on the taper charge
|
||||
transtion.
|
||||
- chg-inhibit: Notifies on battery voltage
|
||||
being too high to resume
|
||||
charging.
|
||||
- chg-p2f-thr: Triggers on transitioning from
|
||||
precharge to fastcharge.
|
||||
- chg-rechg-thr: Triggers on battery voltage
|
||||
falling below the resume
|
||||
threshold.
|
||||
|
||||
qcom,bat-if:
|
||||
- batt-hot: Triggers on battery temperature
|
||||
hitting the hot threshold.
|
||||
Charging stops.
|
||||
- batt-warm: Triggers on battery temperature
|
||||
hitting the warm threshold.
|
||||
Charging current is reduced.
|
||||
- batt-cool: Triggers on battery temperature
|
||||
hitting the cool threshold.
|
||||
Charging current is reduced
|
||||
- batt-cold: Triggers on battery temperature
|
||||
hitting the cold threshold.
|
||||
Charging stops.
|
||||
- batt-missing: Battery missing status
|
||||
interrupt.
|
||||
- batt-low: Triggers on battery voltage
|
||||
falling across a low threshold.
|
||||
|
||||
qcom,usb-chgpth:
|
||||
- usbin-uv: USB input voltage falls below a
|
||||
valid threshold.
|
||||
- usbin-src-det: USB automatic source detection
|
||||
finishes.
|
||||
|
||||
qcom,dc-chgpth:
|
||||
- dcin-uv: DC input voltage falls below a
|
||||
valid threshold.
|
||||
|
||||
qcom,chgr-misc:
|
||||
- wdog-timeout-mins: Charger watchdog timer
|
||||
interrupt.
|
||||
- temp-shutdown: Triggers when charger goes
|
||||
overtemp and causes a shutdown.
|
||||
- power-ok: Triggers when the charger
|
||||
switcher turns on or off.
|
||||
|
||||
Regulator Subnodes:
|
||||
- qcom,smbcharger-boost-otg A subnode for a regulator device that turns on
|
||||
the charger boost for OTG operation.
|
||||
- qcom,smbcharger-external-otg A subnode for a regulator device that switches
|
||||
off charging and the USB input charge path
|
||||
in order to allow an external regulator to
|
||||
operate. This can be used in place of the
|
||||
qcom,smbcharger-boost-otg if an external boost
|
||||
is available.
|
||||
|
||||
Regulator Sub node required properties:
|
||||
- regulator-name A name string for the regulator in question
|
||||
|
||||
Optional Properties:
|
||||
- qcom,battery-psy-name The name of the main battery power supply that
|
||||
the charger will register. Failing to define
|
||||
this property will default the name to
|
||||
"battery".
|
||||
- qcom,bms-psy-name The psy name to use for reporting battery
|
||||
capacity. If left unspecified the capacity uses
|
||||
a preprogrammed default value of 50.
|
||||
- qcom,float-voltage-mv Float Voltage in mV - the maximum voltage up
|
||||
to which the battery is charged. Supported
|
||||
range 3600mV to 4500mV
|
||||
- qcom,float-voltage-comp Specifies the JEITA float voltage compensation.
|
||||
Value ranges from 0 to 63.
|
||||
- qcom,fastchg-current-ma Specifies the fast charge current in mA. Supported
|
||||
range is from 300mA to 3000mA.
|
||||
- qcom,fastchg-current-comp Specifies the fast charge current compensation in
|
||||
mA. Supported values are 250, 700, 900 and 1200mA.
|
||||
- qcom,charging-timeout-mins Maximum duration in minutes that a single
|
||||
charge cycle may last. Supported values are:
|
||||
0, 192, 384, 768, and 1536. A value of 0
|
||||
means that no charge cycle timeout is used and
|
||||
charging can continue indefinitely.
|
||||
- qcom,precharging-timeout-mins Maximum duration in minutes that a single
|
||||
precharge cycle may last. Supported values
|
||||
are: 0, 24, 48, 96, 192. A value of 0 means
|
||||
that no precharge cycle timeout is used and
|
||||
charging can continue indefinitely. Note that
|
||||
the qcom,charging-timeout-mins property must
|
||||
be specified in order for this to take effect.
|
||||
- qcom,dc-psy-type The type of charger connected to the DC path.
|
||||
Can be "Mains", "Wireless" or "Wipower"
|
||||
- qcom,dc-psy-ma The current in mA dc path can support. Must be
|
||||
specified if dc-psy-type is specified. Valid
|
||||
range 300mA to 2000mA.
|
||||
- qcom,dcin-vadc The phandle to pmi8994 voltage adc. The ADC is
|
||||
used to get notifications when the DCIN voltage
|
||||
crosses a programmed min/max threshold. This is
|
||||
used to make configurations for optimized power
|
||||
draw for Wipower.
|
||||
- qcom,wipower-div2-ilim-map
|
||||
- qcom,wipower-pt-ilim-map
|
||||
- qcom,wipower-default-ilim-map
|
||||
Array of 5 elements to indicate the voltage ranges and their corresponding
|
||||
current limits. The 5 elements with index [0..4] are:
|
||||
[0] => voltage_low in uV
|
||||
[1] => voltage_high in uV
|
||||
[2] => current limit for pass through in mA
|
||||
[3] => current limit for div2 mode dcin low voltage in mA
|
||||
[4] => current limit for div2 mode dcin high voltage in mA
|
||||
The div2 and pt tables indicate the current limits
|
||||
to use when Wipower is operating in divide_by_2 mode
|
||||
and pass through mode respectively.
|
||||
The default table is used when the voltage ranges
|
||||
are beyond the ones specified in the mapping table.
|
||||
Note that if dcin-vadc or any of these mapping
|
||||
tables are not specified, dynamic dcin input
|
||||
is disabled.
|
||||
- qcom,charging-disabled Set this if charging should be disabled in the
|
||||
build by default.
|
||||
- qcom,resume-delta-mv Specifies the minimum voltage drop in
|
||||
millivolts below the float voltage that is
|
||||
required in order to initiate a new charging
|
||||
cycle. Supported values are: 50, 100, 200 and
|
||||
300mV.
|
||||
- qcom,chg-inhibit-en Boolean that indicates whether the charge inhibit
|
||||
feature needs to be enabled. If this is not set,
|
||||
charge inhibit feature is disabled by default.
|
||||
- qcom,chg-inhibit-fg Indicates if the recharge threshold source has
|
||||
to be Fuel gauge ADC. If this is not set, it
|
||||
will be analog sensor by default.
|
||||
- qcom,bmd-algo-disabled Indicates if the battery missing detection
|
||||
algorithm is disabled. If this node is present
|
||||
SMB uses the THERM pin for battery missing
|
||||
detection.
|
||||
- qcom,charge-unknown-battery Boolean that indicates whether an unknown
|
||||
battery without a matching profile will be
|
||||
charged. If this is not set, if the fuel gauge
|
||||
does not recognize the battery based on its
|
||||
battery ID, the charger will not start
|
||||
charging.
|
||||
- qcom,bmd-pin-src A string that indicates the source pin for the
|
||||
battery missind detection. This can be either:
|
||||
- "bpd_none"
|
||||
battery is considered always present
|
||||
- "bpd_id"
|
||||
battery id pin is used
|
||||
- "bpd_thm"
|
||||
battery therm pin is used
|
||||
- "bpd_thm_id"
|
||||
both pins are used (battery is
|
||||
considered missing if either pin is
|
||||
floating).
|
||||
- qcom,iterm-ma Specifies the termination current to indicate
|
||||
end-of-charge. Possible values in mA:
|
||||
50, 100, 150, 200, 250, 300, 500, 600.
|
||||
- qcom,iterm-disabled Disables the termination current feature. This
|
||||
is a boolean property.
|
||||
- otg-parent-supply A phandle to an external boost regulator for
|
||||
OTG if it exists.
|
||||
- qcom,thermal-mitigation: Array of input current limit values for
|
||||
different system thermal mitigation levels.
|
||||
This should be a flat array that denotates the
|
||||
maximum charge current in mA for each thermal
|
||||
level.
|
||||
- qcom,rparasitics-uohm: The parasitic resistance of the board following
|
||||
the line from the battery connectors through
|
||||
vph_power. This is used to calculate maximum
|
||||
available current of the battery.
|
||||
- qcom,vled-max-uv: The maximum input voltage of the flash leds.
|
||||
This is used to calculate maximum available
|
||||
current of the battery.
|
||||
- qcom,autoadjust-vfloat A boolean property that when set, makes the
|
||||
driver automatically readjust vfloat using the
|
||||
fuel gauge ADC readings to make charging more
|
||||
accurate.
|
||||
- qcom,jeita-temp-hard-limit property when present will enable or disable
|
||||
the jeita temperature hard limit based on the
|
||||
value 1 or 0. Specify 0 if the jeita temp hard
|
||||
limit needs to be disabled. If it is not present,
|
||||
jeita temperature hard limit will be based on what
|
||||
the bootloader had set earlier.
|
||||
- qcom,low-volt-dcin: A boolean property which upon set will enable the
|
||||
AICL deglitch configuration dynamically. This needs
|
||||
to be set if the DCIN supply is going to be less
|
||||
than or equal to 5V.
|
||||
- qcom,force-aicl-rerun: A boolean property which upon set will enable the
|
||||
AICL rerun by default along with the deglitch time
|
||||
configured to long interval (20 ms). Also, specifying
|
||||
this property will not adjust the AICL deglitch time
|
||||
dynamically for handling the battery over-voltage
|
||||
oscillations when the charger is headroom limited.
|
||||
- qcom,aicl-rerun-period-s If force-aicl-rerun is on, this property dictates
|
||||
how often aicl is reran in seconds. Possible values
|
||||
are 45, 90, 180, and 360.
|
||||
- qcom,ibat-ocp-threshold-ua Maximum current before the battery will trigger
|
||||
overcurrent protection. Use the recommended
|
||||
battery pack value minus some margin.
|
||||
- qcom,soft-vfloat-comp-disabled Set this property when the battery is
|
||||
powered via external source and could
|
||||
go above the float voltage.
|
||||
- qcom,parallel-usb-min-current-ma Minimum current drawn by the primary
|
||||
charger before enabling the parallel
|
||||
charger if one exists. Do not define
|
||||
this property if no parallel chargers
|
||||
exist.
|
||||
- qcom,parallel-usb-9v-min-current-ma Minimum current drawn by the primary
|
||||
charger before enabling the parallel
|
||||
charger if one exists. This property
|
||||
applies only for 9V chargers.
|
||||
- qcom,parallel-allowed-lowering-ma Acceptable current drop from the initial limit
|
||||
to keep parallel charger activated. If the
|
||||
charger current reduces beyond this threshold
|
||||
parallel charger is disabled. Must be specified
|
||||
if parallel charger is used.
|
||||
- qcom,parallel-main-chg-fcc-percent Percentage of the fast charge current allotted to the
|
||||
main charger when parallel charging is enabled and
|
||||
operational. If this property is not defined, the
|
||||
driver defaults to a 50%/50% split between the main
|
||||
and parallel charger.
|
||||
- qcom,parallel-main-chg-icl-percent Percentage of the input current allotted to the
|
||||
main charger when parallel charging is enabled and
|
||||
operational. If this property is not defined, the
|
||||
driver defaults to a 60%/40% split between the main
|
||||
and parallel charger.
|
||||
- qcom,battery-data Points to the phandle of node which
|
||||
contains the battery-profiles supported
|
||||
by the charger/FG.
|
||||
- qcom,chg-led-support A bool property to support the charger led feature.
|
||||
- qcom,chg-led-sw-controls A bool property to allow the software to control
|
||||
the charger led without a valid charger.
|
||||
- qcom,skip-usb-notification A boolean property to be used when usb gets present
|
||||
and type from other means. Especially true on
|
||||
liquid hardware, where usb presence is detected based on GPIO.
|
||||
- qcom,skip-usb-suspend-for-fake-battery A boolean property to skip
|
||||
suspending USB path for fake
|
||||
battery.
|
||||
- qcom,vchg_sns-vadc Phandle of the VADC node.
|
||||
- qcom,vchg-adc-channel-id The ADC channel to which the VCHG is routed.
|
||||
|
||||
Example:
|
||||
qcom,qpnp-smbcharger {
|
||||
compatible = "qcom,qpnp-smbcharger";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
qcom,iterm-ma = <100>;
|
||||
qcom,float-voltage-mv = <4200>;
|
||||
qcom,resume-delta-mv = <100>;
|
||||
qcom,bmd-pin-src = "bpd_thm_id";
|
||||
qcom,dc-psy-type = "Mains";
|
||||
qcom,dc-psy-ma = <1500>;
|
||||
qcom,bms-psy-name = "bms";
|
||||
qcom,battery-psy-name = "battery";
|
||||
qcom,thermal-mitigation = <1500 700 600 325>;
|
||||
qcom,vchg_sns-vadc = <&pmi8950_vadc>;
|
||||
qcom,vchg-adc-channel-id = <3>;
|
||||
|
||||
qcom,chgr@1000 {
|
||||
reg = <0x1000 0x100>;
|
||||
interrupts = <0x2 0x10 0x0>,
|
||||
<0x2 0x10 0x1>,
|
||||
<0x2 0x10 0x2>,
|
||||
<0x2 0x10 0x3>,
|
||||
<0x2 0x10 0x4>,
|
||||
<0x2 0x10 0x5>,
|
||||
<0x2 0x10 0x6>,
|
||||
<0x2 0x10 0x7>;
|
||||
|
||||
interrupt-names = "chg-error",
|
||||
"chg-inhibit",
|
||||
"chg-prechg-sft",
|
||||
"chg-complete-chg-sft",
|
||||
"chg-p2f-thr",
|
||||
"chg-rechg-thr",
|
||||
"chg-taper-thr",
|
||||
"chg-tcc-thr";
|
||||
};
|
||||
|
||||
qcom,otg@1100 {
|
||||
reg = <0x1100 0x100>;
|
||||
};
|
||||
|
||||
qcom,bat-if@1200 {
|
||||
reg = <0x1200 0x100>;
|
||||
interrupts = <0x2 0x12 0x0>,
|
||||
<0x2 0x12 0x1>,
|
||||
<0x2 0x12 0x2>,
|
||||
<0x2 0x12 0x3>,
|
||||
<0x2 0x12 0x4>,
|
||||
<0x2 0x12 0x5>,
|
||||
<0x2 0x12 0x6>,
|
||||
<0x2 0x12 0x7>;
|
||||
|
||||
interrupt-names = "batt-hot",
|
||||
"batt-warm",
|
||||
"batt-cold",
|
||||
"batt-cool",
|
||||
"batt-ov",
|
||||
"batt-low",
|
||||
"batt-missing",
|
||||
"batt-term-missing";
|
||||
};
|
||||
|
||||
qcom,usb-chgpth@1300 {
|
||||
reg = <0x1300 0x100>;
|
||||
interrupts = <0x2 0x13 0x0>,
|
||||
<0x2 0x13 0x1>,
|
||||
<0x2 0x13 0x2>,
|
||||
<0x2 0x13 0x3>,
|
||||
<0x2 0x13 0x4>,
|
||||
<0x2 0x13 0x5>,
|
||||
<0x2 0x13 0x6>;
|
||||
|
||||
interrupt-names = "usbin-uv",
|
||||
"usbin-ov",
|
||||
"usbin-src-det",
|
||||
"otg-fail",
|
||||
"otg-oc",
|
||||
"aicl-done",
|
||||
"usbid-change";
|
||||
};
|
||||
|
||||
qcom,dc-chgpth@1400 {
|
||||
reg = <0x1400 0x100>;
|
||||
interrupts = <0x2 0x14 0x0>,
|
||||
<0x2 0x14 0x1>;
|
||||
|
||||
interrupt-names = "dcin-uv",
|
||||
"dcin-ov";
|
||||
};
|
||||
|
||||
qcom,chgr-misc@1600 {
|
||||
reg = <0x1600 0x100>;
|
||||
interrupts = <0x2 0x16 0x0>,
|
||||
<0x2 0x16 0x1>,
|
||||
<0x2 0x16 0x2>,
|
||||
<0x2 0x16 0x3>,
|
||||
<0x2 0x16 0x4>,
|
||||
<0x2 0x16 0x5>;
|
||||
|
||||
interrupt-names = "power-ok",
|
||||
"temp-shutdown",
|
||||
"wdog-timeout",
|
||||
"flash-fail",
|
||||
"otst2",
|
||||
"otst3";
|
||||
};
|
||||
};
|
||||
@@ -69,6 +69,8 @@ Optional Properties:
|
||||
via pin in a parallel-charger configuration.
|
||||
0 - Active low and 1 - Active high.
|
||||
If not specified the default value is active-low.
|
||||
- qcom,parallel-external-current-sense If present specifies external rsense is
|
||||
used for charge current sensing.
|
||||
|
||||
Example for standalone charger:
|
||||
|
||||
|
||||
@@ -31,6 +31,12 @@ Charger specific properties:
|
||||
revid module. This is used to identify
|
||||
the SMB subtype.
|
||||
|
||||
- qcom,parallel-mode
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Specifies parallel charging mode. If not specified, MID-MID
|
||||
option is selected by default.
|
||||
|
||||
- qcom,suspend-input
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
@@ -52,6 +58,18 @@ Charger specific properties:
|
||||
Value type: <u32>
|
||||
Definition: Specifies the DC input current limit in micro-amps.
|
||||
|
||||
- qcom,charger-temp-max-mdegc
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Specifies the maximum charger temperature in milli-degrees
|
||||
Celsius. If unspecified a default of 80000 will be used.
|
||||
|
||||
- qcom,connector-temp-max-mdegc
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Specifies the maximum connector temperature in milli-degrees
|
||||
Celsius. If unspecified a default value of 105000 will be used.
|
||||
|
||||
- io-channels
|
||||
Usage: optional
|
||||
Value type: List of <phandle u32>
|
||||
|
||||
@@ -209,6 +209,15 @@ Platform independent properties:
|
||||
as the corresponding addresses are specified in
|
||||
the qcom,cpr-panic-reg-addr-list property.
|
||||
|
||||
- qcom,cpr-reset-step-quot-loop-en
|
||||
Usage: optional; only meaningful for CPR4 and CPRh controllers
|
||||
Value type: <empty>
|
||||
Definition: Boolean value which indicates that the CPR controller should
|
||||
be configured to reset step_quot on each loop_en = 0
|
||||
transition. This configuration allows the CPR controller to
|
||||
first use the default step_quot and then later switch to the
|
||||
run-time calibrated step_quot.
|
||||
|
||||
=================================================
|
||||
Second Level Nodes - CPR Threads for a Controller
|
||||
=================================================
|
||||
|
||||
@@ -28,7 +28,8 @@ MMSS LDO specific properties:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be the following:
|
||||
"qcom,cpr4-sdm660-mmss-ldo-regulator".
|
||||
"qcom,cpr4-sdm660-mmss-ldo-regulator" for SDM660,
|
||||
"qcom,cpr4-sdm630-mmss-ldo-regulator" for SDM630.
|
||||
|
||||
- clocks
|
||||
Usage: required
|
||||
@@ -71,7 +72,7 @@ MMSS specific properties:
|
||||
Usage: required
|
||||
Value type: <u32>
|
||||
Definition: Specifies the number of fuse corners. This value must be 6
|
||||
for sdm660 GFX LDO. These fuse corners are: MinSVS,
|
||||
for sdm660/sdm630 GFX LDO. These fuse corners are: MinSVS,
|
||||
LowSVS, SVS, SVSP, NOM and NOMP. The open-loop voltage fuses
|
||||
are allocated for LowSVS, SVS, NOM and NOMP corners. The
|
||||
open-loop voltages for MinSVS and SVSP are derived by
|
||||
|
||||
@@ -34,7 +34,8 @@ KBSS specific properties:
|
||||
"qcom,cprh-msm8998-v1-kbss-regulator",
|
||||
"qcom,cprh-msm8998-v2-kbss-regulator",
|
||||
"qcom,cprh-msm8998-kbss-regulator",
|
||||
"qcom,cprh-sdm660-kbss-regulator".
|
||||
"qcom,cprh-sdm660-kbss-regulator",
|
||||
"qcom,cprh-sdm630-kbss-regulator".
|
||||
If the SoC revision is not specified, then it is assumed to
|
||||
be the most recent revision of MSM8998, i.e. v2.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Qualcomm Technologies Memory Accelerator
|
||||
Qualcomm Technologies, Inc. Memory Accelerator
|
||||
|
||||
Memory accelerator configures the power-mode (corner) for the
|
||||
accelerator.
|
||||
|
||||
@@ -8,8 +8,9 @@ This document describes the bindings that apply for the GFX LDO regulator.
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be "qcom,msm8953-gfx-ldo" for MSM8953 and
|
||||
"qcom,sdm660-gfx-ldo" for SDM660
|
||||
Definition: should be "qcom,msm8953-gfx-ldo" for MSM8953,
|
||||
"qcom,sdm660-gfx-ldo" for SDM660 and "qcom,sdm630-gfx-ldo"
|
||||
for SDM630.
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
||||
@@ -81,9 +81,9 @@ pm8916:
|
||||
l14, l15, l16, l17, l18
|
||||
|
||||
pm8941:
|
||||
s1, s2, s3, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13, l14,
|
||||
l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2, lvs3,
|
||||
mvs1, mvs2
|
||||
s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
|
||||
l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2, lvs3,
|
||||
5vs1, 5vs2
|
||||
|
||||
The content of each sub-node is defined by the standard binding for regulators -
|
||||
see regulator.txt - with additional custom properties described below:
|
||||
|
||||
@@ -149,6 +149,8 @@ LAB subnode optional properties:
|
||||
already. If it it not specified, then
|
||||
output voltage can be configured to
|
||||
any value in the allowed limit.
|
||||
- qcom,notify-lab-vreg-ok-sts: A boolean property which upon set will
|
||||
poll and notify the lab_vreg_ok status.
|
||||
|
||||
Following properties are available only for PM660A:
|
||||
|
||||
|
||||
@@ -26,6 +26,13 @@ First Level Node - LCDB module
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: Base address of the LCDB SPMI peripheral.
|
||||
|
||||
- qcom,force-module-reenable
|
||||
Usage: required if using SW mode for module enable
|
||||
Value type: <bool>
|
||||
Definition: This enables the workaround to force enable
|
||||
the vph_pwr_2p5_ok signal required for
|
||||
turning on the LCDB module.
|
||||
|
||||
Touch-to-wake (TTW) properties:
|
||||
|
||||
TTW supports 2 modes of operation - HW and SW. In the HW mode the enable/disable
|
||||
@@ -59,7 +66,6 @@ main node.
|
||||
Definition: ON time (in mS) for the VDISP/VDISN signals.
|
||||
Possible values are 4, 8, 16, 32.
|
||||
|
||||
|
||||
========================================
|
||||
Second Level Nodes - LDO/NCP/BOOST block
|
||||
========================================
|
||||
|
||||
@@ -44,12 +44,12 @@ Required Node Structure
|
||||
Value type: <bool>
|
||||
Definition: Enables the voltage programming through SWIRE signal.
|
||||
|
||||
qcom,ext-pin-control
|
||||
- qcom,ext-pin-control
|
||||
Usage: optional
|
||||
Value type: <bool>
|
||||
Definition: Configures the OLED module to be enabled by a external pin.
|
||||
|
||||
qcom,dynamic-ext-pinctl-config
|
||||
- qcom,dynamic-ext-pinctl-config
|
||||
Usage: optional
|
||||
Value type: <bool>
|
||||
Definition: Used to dynamically enable/disable the OLEDB module
|
||||
@@ -57,13 +57,27 @@ Required Node Structure
|
||||
rail. This property is applicable only if qcom,ext-pin-ctl
|
||||
property is specified and it is specific to PM660A.
|
||||
|
||||
qcom,pbs-control
|
||||
- qcom,force-pd-control
|
||||
Usage: optional
|
||||
Value type: <bool>
|
||||
Definition: Used to enable the pull down control forcibly via SPMI by
|
||||
disabling the pull down configuration done by hardware
|
||||
automatically through SWIRE pulses.
|
||||
|
||||
- qcom,pbs-client
|
||||
Usage: optional
|
||||
Value type: <phandle>
|
||||
Definition: Used to send the PBS trigger to the specified PBS client.
|
||||
This property is applicable only if qcom,force-pd-control
|
||||
property is specified.
|
||||
|
||||
- qcom,pbs-control
|
||||
Usage: optional
|
||||
Value type: <bool>
|
||||
Definition: PMIC PBS logic directly configures the output voltage update
|
||||
and pull down control.
|
||||
|
||||
qcom,oledb-init-voltage-mv
|
||||
- qcom,oledb-init-voltage-mv
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Sets the AVDD bias voltage (in mV) when the module is
|
||||
@@ -71,53 +85,53 @@ Required Node Structure
|
||||
property is not specified. Supported values are from 5.0V
|
||||
to 8.1V with a step of 100mV.
|
||||
|
||||
qcom,oledb-default-voltage-mv
|
||||
- qcom,oledb-default-voltage-mv
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Sets the default AVDD bias voltage (in mV) before module
|
||||
enable. Supported values are from 5.0V to 8.1V with the
|
||||
step of 100mV.
|
||||
|
||||
qcom,bias-gen-warmup-delay-ns
|
||||
- qcom,bias-gen-warmup-delay-ns
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Bias generator warm-up time (ns). Supported values are
|
||||
6700, 13300, 267000, 534000.
|
||||
|
||||
qcom,peak-curr-limit-ma
|
||||
- qcom,peak-curr-limit-ma
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Peak current limit (in mA). Supported values are 115, 265,
|
||||
415, 570, 720, 870, 1020, 1170.
|
||||
|
||||
qcom,pull-down-enable
|
||||
- qcom,pull-down-enable
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Pull down configuration of OLEDB.
|
||||
1 - Enable pull-down
|
||||
0 - Disable pull-down
|
||||
|
||||
qcom,negative-curr-limit-enable
|
||||
- qcom,negative-curr-limit-enable
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: negative current limit enable/disable.
|
||||
1 = enable negative current limit
|
||||
0 = disable negative current limit
|
||||
|
||||
qcom,negative-curr-limit-ma
|
||||
- qcom,negative-curr-limit-ma
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Negative current limit (in mA). Supported values are
|
||||
170, 300, 420, 550.
|
||||
|
||||
qcom,enable-short-circuit
|
||||
- qcom,enable-short-circuit
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Short circuit protection enable/disable.
|
||||
1 = enable short circuit protection
|
||||
0 = disable short circuit protection
|
||||
|
||||
qcom,short-circuit-dbnc-time
|
||||
- qcom,short-circuit-dbnc-time
|
||||
usage: optional
|
||||
Value type: <u32>
|
||||
Definitioan: Short circuit debounce time (in Fsw). Supported
|
||||
@@ -126,26 +140,26 @@ qcom,short-circuit-dbnc-time
|
||||
Fast precharge properties:
|
||||
-------------------------
|
||||
|
||||
qcom,fast-precharge-ppulse-enable
|
||||
- qcom,fast-precharge-ppulse-enable
|
||||
usage: optional
|
||||
Value type: <u32>
|
||||
Definitioan: Fast precharge pfet pulsing enable/disable.
|
||||
1 = enable fast precharge pfet pulsing
|
||||
0 = disable fast precharge pfet pulsing
|
||||
|
||||
qcom,precharge-debounce-time-ms
|
||||
- qcom,precharge-debounce-time-ms
|
||||
usage: optional
|
||||
Value type: <u32>
|
||||
Definitioan: Fast precharge debounce time (in ms). Supported
|
||||
values are 1, 2, 4, 8.
|
||||
|
||||
qcom,precharge-pulse-period-us
|
||||
- qcom,precharge-pulse-period-us
|
||||
usage: optional
|
||||
Value type: <u32>
|
||||
Definitioan: Fast precharge pulse period (in us). Supported
|
||||
values are 3, 6, 9, 12.
|
||||
|
||||
qcom,precharge-pulse-on-time-us
|
||||
- qcom,precharge-pulse-on-time-us
|
||||
usage: optional
|
||||
Value type: <u32>
|
||||
Definitioan: Fast precharge pulse on time (in ns). Supported
|
||||
@@ -154,20 +168,20 @@ qcom,precharge-pulse-on-time-us
|
||||
Pulse Skip Modulation (PSM) properties:
|
||||
--------------------------------------
|
||||
|
||||
qcom,psm-enable
|
||||
- qcom,psm-enable
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Pulse Skip Modulation mode.
|
||||
1 - Enable PSM mode
|
||||
0 - Disable PSM mode
|
||||
|
||||
qcom,psm-hys-mv
|
||||
- qcom,psm-hys-mv
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: PSM hysterysis voltage (in mV).
|
||||
Supported values are 13mV and 26mV.
|
||||
|
||||
qcom,psm-vref-mv
|
||||
- qcom,psm-vref-mv
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Reference voltage(in mV) control for PSM comparator.
|
||||
@@ -177,26 +191,26 @@ qcom,psm-vref-mv
|
||||
Pulse Frequency Modulation (PFM) properties:
|
||||
-------------------------------------------
|
||||
|
||||
qcom,pfm-enable
|
||||
- qcom,pfm-enable
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: Pulse Frequency Modulation mode.
|
||||
1 - Enable PFM mode
|
||||
0 - Disable PFM mode
|
||||
|
||||
qcom,pfm-hys-mv
|
||||
- qcom,pfm-hys-mv
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: PFM hysterysis voltage (in mV).
|
||||
Supported values are 13mV and 26mV.
|
||||
|
||||
qcom,pfm-curr-limit-ma
|
||||
- qcom,pfm-curr-limit-ma
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: PFM current limit (in mA).
|
||||
Supported values are 130, 200, 270, 340.
|
||||
|
||||
qcom,pfm-off-time-ns
|
||||
- qcom,pfm-off-time-ns
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: NFET off time at PFM (in ns).
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
Qualcomm QPNP Regulators
|
||||
Qualcomm Technologies, Inc. QPNP Regulators
|
||||
|
||||
qpnp-regulator is a regulator driver which supports regulators inside of PMICs
|
||||
that utilize the MSM SPMI implementation.
|
||||
|
||||
22
Documentation/devicetree/bindings/soc/qcom/qcom,cx_ipeak.txt
Normal file
22
Documentation/devicetree/bindings/soc/qcom/qcom,cx_ipeak.txt
Normal file
@@ -0,0 +1,22 @@
|
||||
* Cx iPeak driver to handle requests from various multimedia clients.
|
||||
|
||||
Cx ipeak HW module is used to limit the current drawn by various subsystem
|
||||
blocks on Cx power rail. Each client needs to set their
|
||||
bit in tcsr register if it is going to cross its own threshold. If all
|
||||
clients are going to cross their thresholds then Cx ipeak hw module will raise
|
||||
an interrupt to cDSP block to throttle cDSP's fmax.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : name of the component used for driver matching, should be
|
||||
"qcom,cx-ipeak-sdm660"
|
||||
|
||||
- reg : physical base address and length of the register set(s), SRAM and XPU
|
||||
of the component.
|
||||
|
||||
Example:
|
||||
|
||||
cx_ipeak_lm: cx_ipeak@1fe5040 {
|
||||
compatible = "qcom,cx-ipeak-sdm660";
|
||||
reg = <0x01fe5040 0x28>;
|
||||
};
|
||||
@@ -10,6 +10,7 @@ pwm(pulse width modulation) and audio.
|
||||
Required Properties:
|
||||
- compatible: must be "qcom,qpnp-haptic"
|
||||
- reg: address of device
|
||||
- qcom,pmic-revid : phandle to fetch PMIC revid
|
||||
- qcom,actuator-type: must be one of "erm" or "lra"
|
||||
- qcom,play-mode : must be one of "buffer", "direct", "pwm" or "audio"
|
||||
|
||||
@@ -23,8 +24,6 @@ Optional Properties:
|
||||
2-bit amplitude control 0x00: 0, 0x01: vmax/4, 0x02: vmax/2,
|
||||
0x03: vmax. Default values are 0x00.
|
||||
- qcom,sc-deb-cycles : short circuit debounce in internal pwm switching clock cycles
|
||||
- qcom,use-play-irq : boolean, use this if the device uses irq for play
|
||||
- qcom,use-sc-irq : boolean, use this if the device uses irq for play
|
||||
- interrupts: Specifies the interrupt associated with Haptics. The available
|
||||
interrupts are play and short circuit. The values for play and
|
||||
short circuit are <0x3 0xc0 0x0> and <0x3 0xc0 0x1>.
|
||||
@@ -53,9 +52,11 @@ Optional properties for pwm play mode:
|
||||
Optional properties when qcom,actuator-type is "lra"
|
||||
- qcom,correct-lra-drive-freq : boolean, use this to ensure LRA is driven at correct resonant
|
||||
frequency, which may change due to operating conditions.
|
||||
- qcom,misc-trim-error-rc19p2-clk-reg-present : boolean, use this if TRIM_ERROR_RC19P2_CLK
|
||||
register is present in MISC module. This register holds
|
||||
the frequency error in 19.2Mhz RC clock.
|
||||
- qcom,pmic-misc : phandle of misc device using which the clock
|
||||
trim error can be read from.
|
||||
- qcom,misc-clk-trim-error-reg : Address offset of MISC_TRIM_ERROR_RC19P2_CLK
|
||||
register if present in MISC module. This
|
||||
holds the frequency error in 19.2 MHz clock.
|
||||
- qcom,lra-auto-res-mode : auto resonance technique, four different modes
|
||||
"none" : no auto resonance
|
||||
"zxd" : zero crossing based discontinuous method
|
||||
@@ -63,9 +64,49 @@ Optional properties when qcom,actuator-type is "lra"
|
||||
"max-qwd" : Maximum QWD
|
||||
"zxd-eop" : ZXD + End of pattern (This is the Default)
|
||||
- qcom,lra-high-z : High Z configuration for auto resonance. Possible string values are
|
||||
"none", "opt1", "opt2" and "opt3" (default)
|
||||
"none", "opt1", "opt2" and "opt3" (default). For PM660,
|
||||
"opt0" is valid value for 1 LRA period.
|
||||
- qcom,lra-qwd-drive-duration : Drive duration of LRA in QWD mode for PM660.
|
||||
Possible values are: 0: 1/4 LRA PERIOD and 1: 3/8 LRA PERIOD
|
||||
- qcom,lra-calibrate-at-eop : To calibrate at End of Pattern for PM660.
|
||||
Possible values are: 0 to disable and 1 to enable Calibration
|
||||
at End of Pattern
|
||||
- qcom,lra-res-cal-period : Auto resonance calibration period. The values range from
|
||||
4 to 32(default)
|
||||
- qcom,perform-lra-auto-resonance-search : boolean, define this property if:
|
||||
a) the underlying PMI chip does not have a register in the MISC block to
|
||||
read the error percentage in RC clock
|
||||
b) the actuator type is LRA
|
||||
Defining this causes the auto resonance search algorithm to be be performed
|
||||
for such devices.
|
||||
c) This property is not defined by default.
|
||||
|
||||
- qcom,drive-period-code-max-limit-percent-variation: RATE_CFG1 and RATE_CFG2 registers will
|
||||
be updated with the values from AUTO_RES_LO and AUTO_RES_HI registers
|
||||
only if the variation from the resonant frequency is within the value
|
||||
mentioned by this property on the higher side.
|
||||
The default value is 25, which means if the drive period code resulting
|
||||
from AUTO_RES register's is more than 25 percent of the existing drive
|
||||
period code, then driver does not update RATE_CFG registers.
|
||||
- qcom,drive-period-code-min-limit-percent-variation: RATE_CFG1 and RATE_CFG2 registers will
|
||||
be updated with the values from AUTO_RES_LO and AUTO_RES_HI registers
|
||||
only if the variation from the resonant frequency is within the value
|
||||
mentioned by this property on the lower side.
|
||||
The default value is 25, which means if the drive period code resulting
|
||||
from AUTO_RES register's is less than 25 percent of the existing drive
|
||||
period code, then driver does not update RATE_CFG registers.
|
||||
|
||||
Optional properties when qcom,lra-auto-res-mode is "qwd"
|
||||
- qcom,time-required-to-generate-back-emf-us: Time period required to generate sufficient
|
||||
back-emf (in case of QWD mode only) in us. For auto resonance
|
||||
detection to work properly,sufficient back-emf has to be
|
||||
generated. In general, back-emf takes some time to build up.
|
||||
When the auto resonance mode is chosen as QWD, high-z will
|
||||
be applied for every LRA cycle and hence there won't be
|
||||
enough back-emf at the start-up. So we need to drive the
|
||||
motor for a few LRA cycles. Hence, auto resonance detection
|
||||
is enabled after this delay period after the PLAY bit is
|
||||
asserted. The default value is 20000us.
|
||||
|
||||
Example:
|
||||
qcom,haptic@c000 {
|
||||
@@ -75,7 +116,10 @@ Example:
|
||||
interrupts = <0x3 0xc0 0x0>,
|
||||
<0x3 0xc0 0x1>;
|
||||
interrupt-names = "sc-irq", "play-irq";
|
||||
qcom,pmic-revid = <&pm660_revid>;
|
||||
vcc_pon-supply = <&pon_perph_reg>;
|
||||
qcom,pmic-misc = <&pmi8998_misc>;
|
||||
qcom,misc-clk-trim-error-reg = <0xf3>;
|
||||
qcom,play-mode = "direct";
|
||||
qcom,wave-play-rate-us = <5263>;
|
||||
qcom,actuator-type = "lra";
|
||||
@@ -86,12 +130,11 @@ Example:
|
||||
qcom,int-pwm-freq-khz = <505>;
|
||||
qcom,en-brake;
|
||||
qcom,brake-pattern = [03 03 00 00];
|
||||
qcom,use-play-irq;
|
||||
qcom,use-sc-irq;
|
||||
qcom,wave-samples = [3e 3e 3e 3e 3e 3e 3e 3e];
|
||||
qcom,wave-rep-cnt = <1>;
|
||||
qcom,wave-samp-rep-cnt = <1>;
|
||||
qcom,lra-high-z = "opt1";
|
||||
qcom,lra-auto-res-mode = "qwd";
|
||||
qcom,lra-res-cal-period = <4>;
|
||||
qcom,time-required-to-generate-back-emf-us = <20000>;
|
||||
};
|
||||
|
||||
30
Documentation/devicetree/bindings/soc/qcom/qpnp-pbs.txt
Normal file
30
Documentation/devicetree/bindings/soc/qcom/qpnp-pbs.txt
Normal file
@@ -0,0 +1,30 @@
|
||||
QPNP PBS
|
||||
|
||||
QPNP (Qualcomm Technologies, Inc. Plug N Play) PBS is programmable boot sequence
|
||||
and this driver is for helping the client drivers triggering such sequence
|
||||
to be configured in PMIC.
|
||||
|
||||
This document describes the bindings for QPNP PBS driver.
|
||||
|
||||
=======================
|
||||
Required Node Structure
|
||||
=======================
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: should be "qcom,qpnp-pbs".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: Base address of the PBS registers.
|
||||
|
||||
|
||||
=======
|
||||
Example
|
||||
=======
|
||||
pm660l_pbs: qcom,pbs@7300 {
|
||||
compatible = "qcom,qpnp-pbs";
|
||||
reg = <0x7300 0x100>;
|
||||
};
|
||||
@@ -514,10 +514,6 @@ Required properties:
|
||||
which is also existing driver WSA881x that represents
|
||||
soundwire slave devices.
|
||||
|
||||
Optional Properties:
|
||||
- qcom,cache-always : Boolean. This property is used in WSA slave
|
||||
device to use cacheable for all registers.
|
||||
|
||||
Example:
|
||||
|
||||
msm_sdw_codec: qcom,msm-sdw-codec@152c1000 {
|
||||
@@ -535,7 +531,6 @@ msm_sdw_codec: qcom,msm-sdw-codec@152c1000 {
|
||||
compatible = "qcom,wsa881x";
|
||||
reg = <0x00 0x20170212>;
|
||||
qcom,spkr-sd-n-gpio = <&tlmm 80 0>;
|
||||
qcom,cache-always;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -40,7 +40,24 @@ Optional properties:
|
||||
receive.
|
||||
|
||||
SPI slave nodes must be children of the SPI master node and can contain
|
||||
properties described in Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
the following properties.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should contain:
|
||||
"qcom,spi-msm-codec-slave" for external codec control
|
||||
|
||||
- reg: Chip select address of device.
|
||||
|
||||
- spi-max-frequency: Maximum SPI clocking speed of device in Hz.
|
||||
|
||||
Optional properties:
|
||||
- spi-cpol: Empty property indicating device requires
|
||||
inverse clock polarity (CPOL) mode.
|
||||
- spi-cpha: Empty property indicating device requires
|
||||
shifted clock phase (CPHA) mode.
|
||||
|
||||
Other optional properties described in
|
||||
Documentation/devicetree/bindings/spi/spi-bus.txt
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@@ -1,8 +1,9 @@
|
||||
Qualcomm QPNP Temperature Alarm
|
||||
Qualcomm Technologies, Inc. QPNP Temperature Alarm
|
||||
|
||||
QPNP temperature alarm peripherals are found inside of Qualcomm PMIC chips that
|
||||
utilize the MSM SPMI implementation. These peripherals provide an interrupt
|
||||
signal and status register to identify high PMIC die temperature.
|
||||
QPNP temperature alarm peripherals are found inside of Qualcomm Technologies,
|
||||
Inc. PMIC chips that utilize the MSM SPMI implementation. These peripherals
|
||||
provide an interrupt signal and status register to identify high PMIC die
|
||||
temperature.
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "qcom,qpnp-temp-alarm".
|
||||
|
||||
@@ -141,6 +141,9 @@ enabled and functional in the driver:
|
||||
- qcom,pm-qos-default-cpu: PM QoS voting is based on the cpu associated with each IO request by the block layer.
|
||||
This defined the default cpu used for PM QoS voting in case a specific cpu value is not available.
|
||||
|
||||
- qcom,vddp-ref-clk-supply : reference clock to ufs device. Controlled by the host driver.
|
||||
- qcom,vddp-ref-clk-max-microamp : specifies max. load that can be drawn for
|
||||
ref-clk supply.
|
||||
Example:
|
||||
ufshc@0xfc598000 {
|
||||
...
|
||||
|
||||
@@ -197,7 +197,9 @@ prototypes:
|
||||
int (*releasepage) (struct page *, int);
|
||||
void (*freepage)(struct page *);
|
||||
int (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
|
||||
bool (*isolate_page) (struct page *, isolate_mode_t);
|
||||
int (*migratepage)(struct address_space *, struct page *, struct page *);
|
||||
void (*putback_page) (struct page *);
|
||||
int (*launder_page)(struct page *);
|
||||
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long);
|
||||
int (*error_remove_page)(struct address_space *, struct page *);
|
||||
@@ -221,7 +223,9 @@ invalidatepage: yes
|
||||
releasepage: yes
|
||||
freepage: yes
|
||||
direct_IO:
|
||||
isolate_page: yes
|
||||
migratepage: yes (both)
|
||||
putback_page: yes
|
||||
launder_page: yes
|
||||
is_partially_uptodate: yes
|
||||
error_remove_page: yes
|
||||
|
||||
@@ -593,9 +593,14 @@ struct address_space_operations {
|
||||
int (*releasepage) (struct page *, int);
|
||||
void (*freepage)(struct page *);
|
||||
ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter, loff_t offset);
|
||||
/* isolate a page for migration */
|
||||
bool (*isolate_page) (struct page *, isolate_mode_t);
|
||||
/* migrate the contents of a page to the specified target */
|
||||
int (*migratepage) (struct page *, struct page *);
|
||||
/* put migration-failed page back to right list */
|
||||
void (*putback_page) (struct page *);
|
||||
int (*launder_page) (struct page *);
|
||||
|
||||
int (*is_partially_uptodate) (struct page *, unsigned long,
|
||||
unsigned long);
|
||||
void (*is_dirty_writeback) (struct page *, bool *, bool *);
|
||||
@@ -748,6 +753,10 @@ struct address_space_operations {
|
||||
and transfer data directly between the storage and the
|
||||
application's address space.
|
||||
|
||||
isolate_page: Called by the VM when isolating a movable non-lru page.
|
||||
If page is successfully isolated, VM marks the page as PG_isolated
|
||||
via __SetPageIsolated.
|
||||
|
||||
migrate_page: This is used to compact the physical memory usage.
|
||||
If the VM wants to relocate a page (maybe off a memory card
|
||||
that is signalling imminent failure) it will pass a new page
|
||||
@@ -755,6 +764,8 @@ struct address_space_operations {
|
||||
transfer any private data across and update any references
|
||||
that it has to the page.
|
||||
|
||||
putback_page: Called by the VM when isolated page's migration fails.
|
||||
|
||||
launder_page: Called before freeing a page - it writes back the dirty page. To
|
||||
prevent redirtying the page, it is kept locked during the whole
|
||||
operation.
|
||||
|
||||
@@ -750,6 +750,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
seconds. Defaults to 10*60 = 10mins. A value of 0
|
||||
disables the blank timer.
|
||||
|
||||
core_ctl_disable_cpumask= [SMP]
|
||||
Exempt the CPUs from being managed by core_ctl.
|
||||
core_ctl operates on a cluster basis. So all the
|
||||
CPUs in a given cluster must be specified to disable
|
||||
core_ctl for that cluster.
|
||||
|
||||
coredump_filter=
|
||||
[KNL] Change the default value for
|
||||
/proc/<pid>/coredump_filter.
|
||||
@@ -1265,6 +1271,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
When zero, profiling data is discarded and associated
|
||||
debugfs files are removed at module unload time.
|
||||
|
||||
goldfish [X86] Enable the goldfish android emulator platform.
|
||||
Don't use this when you are not running on the
|
||||
android emulator
|
||||
|
||||
gpt [EFI] Forces disk with valid GPT signature but
|
||||
invalid Protective MBR to be treated as GPT. If the
|
||||
primary GPT is corrupted, it enables the backup/alternate
|
||||
@@ -1381,7 +1391,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
|
||||
i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX
|
||||
controllers
|
||||
i8042.notimeout [HW] Ignore timeout condition signalled by controller
|
||||
i8042.reset [HW] Reset the controller during init and cleanup
|
||||
i8042.reset [HW] Reset the controller during init, cleanup and
|
||||
suspend-to-ram transitions, only during s2r
|
||||
transitions, or never reset
|
||||
Format: { 1 | Y | y | 0 | N | n }
|
||||
1, Y, y: always reset controller
|
||||
0, N, n: don't ever reset controller
|
||||
Default: only on s2r transitions on x86; most other
|
||||
architectures force reset to be always executed
|
||||
i8042.unlock [HW] Unlock (ignore) the keylock
|
||||
i8042.kbdreset [HW] Reset device connected to KBD port
|
||||
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
subdir-y := mpssd
|
||||
@@ -1,21 +0,0 @@
|
||||
ifndef CROSS_COMPILE
|
||||
# List of programs to build
|
||||
hostprogs-$(CONFIG_X86_64) := mpssd
|
||||
|
||||
mpssd-objs := mpssd.o sysfs.o
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
always := $(hostprogs-y)
|
||||
|
||||
HOSTCFLAGS += -I$(objtree)/usr/include -I$(srctree)/tools/include
|
||||
|
||||
ifdef DEBUG
|
||||
HOSTCFLAGS += -DDEBUG=$(DEBUG)
|
||||
endif
|
||||
|
||||
HOSTLOADLIBES_mpssd := -lpthread
|
||||
|
||||
install:
|
||||
install mpssd /usr/sbin/mpssd
|
||||
install micctrl /usr/sbin/micctrl
|
||||
endif
|
||||
@@ -831,7 +831,7 @@ separate memory range only intended for GPIO driving, and the register
|
||||
range dealing with pin config and pin multiplexing get placed into a
|
||||
different memory range and a separate section of the data sheet.
|
||||
|
||||
A flag "strict" in struct pinctrl_desc is available to check and deny
|
||||
A flag "strict" in struct pinmux_ops is available to check and deny
|
||||
simultaneous access to the same pin from GPIO and pin multiplexing
|
||||
consumers on hardware of this type. The pinctrl driver should set this flag
|
||||
accordingly.
|
||||
|
||||
@@ -357,6 +357,26 @@ of ftrace. Here is a list of some of the key files:
|
||||
to correlate events across hypervisor/guest if
|
||||
tb_offset is known.
|
||||
|
||||
mono: This uses the fast monotonic clock (CLOCK_MONOTONIC)
|
||||
which is monotonic and is subject to NTP rate adjustments.
|
||||
|
||||
mono_raw:
|
||||
This is the raw monotonic clock (CLOCK_MONOTONIC_RAW)
|
||||
which is montonic but is not subject to any rate adjustments
|
||||
and ticks at the same rate as the hardware clocksource.
|
||||
|
||||
boot: This is the boot clock (CLOCK_BOOTTIME) and is based on the
|
||||
fast monotonic clock, but also accounts for time spent in
|
||||
suspend. Since the clock access is designed for use in
|
||||
tracing in the suspend path, some side effects are possible
|
||||
if clock is accessed after the suspend time is accounted before
|
||||
the fast mono clock is updated. In this case, the clock update
|
||||
appears to happen slightly sooner than it normally would have.
|
||||
Also on 32-bit systems, its possible that the 64-bit boot offset
|
||||
sees a partial update. These effects are rare and post
|
||||
processing should be able to handle them. See comments on
|
||||
ktime_get_boot_fast_ns function for more information.
|
||||
|
||||
To set a clock, simply echo the clock name into this file.
|
||||
|
||||
echo global > trace_clock
|
||||
|
||||
@@ -1991,6 +1991,7 @@ registers, find a list below:
|
||||
PPC | KVM_REG_PPC_TM_VSCR | 32
|
||||
PPC | KVM_REG_PPC_TM_DSCR | 64
|
||||
PPC | KVM_REG_PPC_TM_TAR | 64
|
||||
PPC | KVM_REG_PPC_TM_XER | 64
|
||||
| |
|
||||
MIPS | KVM_REG_MIPS_R0 | 64
|
||||
...
|
||||
|
||||
@@ -142,5 +142,111 @@ Steps:
|
||||
20. The new page is moved to the LRU and can be scanned by the swapper
|
||||
etc again.
|
||||
|
||||
Christoph Lameter, May 8, 2006.
|
||||
C. Non-LRU page migration
|
||||
-------------------------
|
||||
|
||||
Although original migration aimed for reducing the latency of memory access
|
||||
for NUMA, compaction who want to create high-order page is also main customer.
|
||||
|
||||
Current problem of the implementation is that it is designed to migrate only
|
||||
*LRU* pages. However, there are potential non-lru pages which can be migrated
|
||||
in drivers, for example, zsmalloc, virtio-balloon pages.
|
||||
|
||||
For virtio-balloon pages, some parts of migration code path have been hooked
|
||||
up and added virtio-balloon specific functions to intercept migration logics.
|
||||
It's too specific to a driver so other drivers who want to make their pages
|
||||
movable would have to add own specific hooks in migration path.
|
||||
|
||||
To overclome the problem, VM supports non-LRU page migration which provides
|
||||
generic functions for non-LRU movable pages without driver specific hooks
|
||||
migration path.
|
||||
|
||||
If a driver want to make own pages movable, it should define three functions
|
||||
which are function pointers of struct address_space_operations.
|
||||
|
||||
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
|
||||
|
||||
What VM expects on isolate_page function of driver is to return *true*
|
||||
if driver isolates page successfully. On returing true, VM marks the page
|
||||
as PG_isolated so concurrent isolation in several CPUs skip the page
|
||||
for isolation. If a driver cannot isolate the page, it should return *false*.
|
||||
|
||||
Once page is successfully isolated, VM uses page.lru fields so driver
|
||||
shouldn't expect to preserve values in that fields.
|
||||
|
||||
2. int (*migratepage) (struct address_space *mapping,
|
||||
struct page *newpage, struct page *oldpage, enum migrate_mode);
|
||||
|
||||
After isolation, VM calls migratepage of driver with isolated page.
|
||||
The function of migratepage is to move content of the old page to new page
|
||||
and set up fields of struct page newpage. Keep in mind that you should
|
||||
indicate to the VM the oldpage is no longer movable via __ClearPageMovable()
|
||||
under page_lock if you migrated the oldpage successfully and returns
|
||||
MIGRATEPAGE_SUCCESS. If driver cannot migrate the page at the moment, driver
|
||||
can return -EAGAIN. On -EAGAIN, VM will retry page migration in a short time
|
||||
because VM interprets -EAGAIN as "temporal migration failure". On returning
|
||||
any error except -EAGAIN, VM will give up the page migration without retrying
|
||||
in this time.
|
||||
|
||||
Driver shouldn't touch page.lru field VM using in the functions.
|
||||
|
||||
3. void (*putback_page)(struct page *);
|
||||
|
||||
If migration fails on isolated page, VM should return the isolated page
|
||||
to the driver so VM calls driver's putback_page with migration failed page.
|
||||
In this function, driver should put the isolated page back to the own data
|
||||
structure.
|
||||
|
||||
4. non-lru movable page flags
|
||||
|
||||
There are two page flags for supporting non-lru movable page.
|
||||
|
||||
* PG_movable
|
||||
|
||||
Driver should use the below function to make page movable under page_lock.
|
||||
|
||||
void __SetPageMovable(struct page *page, struct address_space *mapping)
|
||||
|
||||
It needs argument of address_space for registering migration family functions
|
||||
which will be called by VM. Exactly speaking, PG_movable is not a real flag of
|
||||
struct page. Rather than, VM reuses page->mapping's lower bits to represent it.
|
||||
|
||||
#define PAGE_MAPPING_MOVABLE 0x2
|
||||
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
|
||||
|
||||
so driver shouldn't access page->mapping directly. Instead, driver should
|
||||
use page_mapping which mask off the low two bits of page->mapping under
|
||||
page lock so it can get right struct address_space.
|
||||
|
||||
For testing of non-lru movable page, VM supports __PageMovable function.
|
||||
However, it doesn't guarantee to identify non-lru movable page because
|
||||
page->mapping field is unified with other variables in struct page.
|
||||
As well, if driver releases the page after isolation by VM, page->mapping
|
||||
doesn't have stable value although it has PAGE_MAPPING_MOVABLE
|
||||
(Look at __ClearPageMovable). But __PageMovable is cheap to catch whether
|
||||
page is LRU or non-lru movable once the page has been isolated. Because
|
||||
LRU pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
|
||||
good for just peeking to test non-lru movable pages before more expensive
|
||||
checking with lock_page in pfn scanning to select victim.
|
||||
|
||||
For guaranteeing non-lru movable page, VM provides PageMovable function.
|
||||
Unlike __PageMovable, PageMovable functions validates page->mapping and
|
||||
mapping->a_ops->isolate_page under lock_page. The lock_page prevents sudden
|
||||
destroying of page->mapping.
|
||||
|
||||
Driver using __SetPageMovable should clear the flag via __ClearMovablePage
|
||||
under page_lock before the releasing the page.
|
||||
|
||||
* PG_isolated
|
||||
|
||||
To prevent concurrent isolation among several CPUs, VM marks isolated page
|
||||
as PG_isolated under lock_page. So if a CPU encounters PG_isolated non-lru
|
||||
movable page, it can skip it. Driver doesn't need to manipulate the flag
|
||||
because VM will set/clear it automatically. Keep in mind that if driver
|
||||
sees PG_isolated page, it means the page have been isolated by VM so it
|
||||
shouldn't touch page.lru field.
|
||||
PG_isolated is alias with PG_reclaim flag so driver shouldn't use the flag
|
||||
for own purpose.
|
||||
|
||||
Christoph Lameter, May 8, 2006.
|
||||
Minchan Kim, Mar 28, 2016.
|
||||
|
||||
24
Makefile
24
Makefile
@@ -1,6 +1,6 @@
|
||||
VERSION = 4
|
||||
PATCHLEVEL = 4
|
||||
SUBLEVEL = 21
|
||||
SUBLEVEL = 55
|
||||
EXTRAVERSION =
|
||||
NAME = Blurry Fish Butt
|
||||
|
||||
@@ -128,6 +128,10 @@ _all:
|
||||
# Cancel implicit rules on top Makefile
|
||||
$(CURDIR)/Makefile Makefile: ;
|
||||
|
||||
ifneq ($(words $(subst :, ,$(CURDIR))), 1)
|
||||
$(error main directory cannot contain spaces nor colons)
|
||||
endif
|
||||
|
||||
ifneq ($(KBUILD_OUTPUT),)
|
||||
# Invoke a second make in the output directory, passing relevant variables
|
||||
# check that the output directory actually exists
|
||||
@@ -511,6 +515,12 @@ ifeq ($(KBUILD_EXTMOD),)
|
||||
endif
|
||||
endif
|
||||
endif
|
||||
# install and module_install need also be processed one by one
|
||||
ifneq ($(filter install,$(MAKECMDGOALS)),)
|
||||
ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
|
||||
mixed-targets := 1
|
||||
endif
|
||||
endif
|
||||
|
||||
ifeq ($(mixed-targets),1)
|
||||
# ===========================================================================
|
||||
@@ -622,12 +632,18 @@ ARCH_CFLAGS :=
|
||||
include arch/$(SRCARCH)/Makefile
|
||||
|
||||
KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning,frame-address,)
|
||||
|
||||
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
|
||||
KBUILD_CFLAGS += $(call cc-option,-Oz,-Os)
|
||||
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
|
||||
else
|
||||
ifdef CONFIG_PROFILE_ALL_BRANCHES
|
||||
KBUILD_CFLAGS += -O2
|
||||
else
|
||||
KBUILD_CFLAGS += -O2
|
||||
endif
|
||||
endif
|
||||
|
||||
ifdef CONFIG_CC_WERROR
|
||||
@@ -1296,7 +1312,7 @@ help:
|
||||
@echo ' firmware_install- Install all firmware to INSTALL_FW_PATH'
|
||||
@echo ' (default: $$(INSTALL_MOD_PATH)/lib/firmware)'
|
||||
@echo ' dir/ - Build all files in dir and below'
|
||||
@echo ' dir/file.[oisS] - Build specified target only'
|
||||
@echo ' dir/file.[ois] - Build specified target only'
|
||||
@echo ' dir/file.lst - Build specified mixed source/assembly target only'
|
||||
@echo ' (requires a recent binutils and recent build (System.map))'
|
||||
@echo ' dir/file.ko - Build module including final link'
|
||||
@@ -1536,11 +1552,11 @@ image_name:
|
||||
# Clear a bunch of variables before executing the submake
|
||||
tools/: FORCE
|
||||
$(Q)mkdir -p $(objtree)/tools
|
||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(O) subdir=tools -C $(src)/tools/
|
||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/
|
||||
|
||||
tools/%: FORCE
|
||||
$(Q)mkdir -p $(objtree)/tools
|
||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(O) subdir=tools -C $(src)/tools/ $*
|
||||
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(filter --j% -j,$(MAKEFLAGS))" O=$(shell cd $(objtree) && /bin/pwd) subdir=tools -C $(src)/tools/ $*
|
||||
|
||||
# Single targets
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
@@ -25,6 +25,7 @@ CONFIG_DM_VERITY=y
|
||||
CONFIG_DM_VERITY_FEC=y
|
||||
CONFIG_EMBEDDED=y
|
||||
CONFIG_FB=y
|
||||
CONFIG_HARDENED_USERCOPY=y
|
||||
CONFIG_HIGH_RES_TIMERS=y
|
||||
CONFIG_INET6_AH=y
|
||||
CONFIG_INET6_ESP=y
|
||||
@@ -139,7 +140,12 @@ CONFIG_PPP_DEFLATE=y
|
||||
CONFIG_PPP_MPPE=y
|
||||
CONFIG_PREEMPT=y
|
||||
CONFIG_PROFILING=y
|
||||
CONFIG_QFMT_V2=y
|
||||
CONFIG_QUOTA=y
|
||||
CONFIG_QUOTA_NETLINK_INTERFACE=y
|
||||
CONFIG_QUOTA_TREE=y
|
||||
CONFIG_QUOTACTL=y
|
||||
CONFIG_RANDOMIZE_BASE=y
|
||||
CONFIG_RTC_CLASS=y
|
||||
CONFIG_RT_GROUP_SCHED=y
|
||||
CONFIG_SECCOMP=y
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
# KEEP ALPHABETICALLY SORTED
|
||||
# CONFIG_AIO is not set
|
||||
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
|
||||
# CONFIG_INPUT_MOUSE is not set
|
||||
# CONFIG_LEGACY_PTYS is not set
|
||||
@@ -7,6 +8,7 @@
|
||||
# CONFIG_VT is not set
|
||||
CONFIG_ANDROID_TIMED_GPIO=y
|
||||
CONFIG_ARM_KERNMEM_PERMS=y
|
||||
CONFIG_ARM64_SW_TTBR0_PAN=y
|
||||
CONFIG_BACKLIGHT_LCD_SUPPORT=y
|
||||
CONFIG_BLK_DEV_LOOP=y
|
||||
CONFIG_BLK_DEV_RAM=y
|
||||
|
||||
@@ -371,14 +371,6 @@ __copy_tofrom_user_nocheck(void *to, const void *from, long len)
|
||||
return __cu_len;
|
||||
}
|
||||
|
||||
extern inline long
|
||||
__copy_tofrom_user(void *to, const void *from, long len, const void __user *validate)
|
||||
{
|
||||
if (__access_ok((unsigned long)validate, len, get_fs()))
|
||||
len = __copy_tofrom_user_nocheck(to, from, len);
|
||||
return len;
|
||||
}
|
||||
|
||||
#define __copy_to_user(to, from, n) \
|
||||
({ \
|
||||
__chk_user_ptr(to); \
|
||||
@@ -393,17 +385,22 @@ __copy_tofrom_user(void *to, const void *from, long len, const void __user *vali
|
||||
#define __copy_to_user_inatomic __copy_to_user
|
||||
#define __copy_from_user_inatomic __copy_from_user
|
||||
|
||||
|
||||
extern inline long
|
||||
copy_to_user(void __user *to, const void *from, long n)
|
||||
{
|
||||
return __copy_tofrom_user((__force void *)to, from, n, to);
|
||||
if (likely(__access_ok((unsigned long)to, n, get_fs())))
|
||||
n = __copy_tofrom_user_nocheck((__force void *)to, from, n);
|
||||
return n;
|
||||
}
|
||||
|
||||
extern inline long
|
||||
copy_from_user(void *to, const void __user *from, long n)
|
||||
{
|
||||
return __copy_tofrom_user(to, (__force void *)from, n, from);
|
||||
if (likely(__access_ok((unsigned long)from, n, get_fs())))
|
||||
n = __copy_tofrom_user_nocheck(to, (__force void *)from, n);
|
||||
else
|
||||
memset(to, 0, n);
|
||||
return n;
|
||||
}
|
||||
|
||||
extern void __do_clear_user(void);
|
||||
|
||||
@@ -85,6 +85,10 @@ void flush_anon_page(struct vm_area_struct *vma,
|
||||
*/
|
||||
#define PG_dc_clean PG_arch_1
|
||||
|
||||
#define CACHE_COLORS_NUM 4
|
||||
#define CACHE_COLORS_MSK (CACHE_COLORS_NUM - 1)
|
||||
#define CACHE_COLOR(addr) (((unsigned long)(addr) >> (PAGE_SHIFT)) & CACHE_COLORS_MSK)
|
||||
|
||||
/*
|
||||
* Simple wrapper over config option
|
||||
* Bootup code ensures that hardware matches kernel configuration
|
||||
@@ -94,8 +98,6 @@ static inline int cache_is_vipt_aliasing(void)
|
||||
return IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
|
||||
}
|
||||
|
||||
#define CACHE_COLOR(addr) (((unsigned long)(addr) >> (PAGE_SHIFT)) & 1)
|
||||
|
||||
/*
|
||||
* checks if two addresses (after page aligning) index into same cache set
|
||||
*/
|
||||
|
||||
@@ -22,10 +22,13 @@
|
||||
static inline void __delay(unsigned long loops)
|
||||
{
|
||||
__asm__ __volatile__(
|
||||
" lp 1f \n"
|
||||
" nop \n"
|
||||
"1: \n"
|
||||
: "+l"(loops));
|
||||
" mov lp_count, %0 \n"
|
||||
" lp 1f \n"
|
||||
" nop \n"
|
||||
"1: \n"
|
||||
:
|
||||
: "r"(loops)
|
||||
: "lp_count");
|
||||
}
|
||||
|
||||
extern void __bad_udelay(void);
|
||||
|
||||
@@ -277,8 +277,7 @@ static inline void pmd_set(pmd_t *pmdp, pte_t *ptep)
|
||||
|
||||
#define mk_pte(page, prot) pfn_pte(page_to_pfn(page), prot)
|
||||
#define pte_pfn(pte) (pte_val(pte) >> PAGE_SHIFT)
|
||||
#define pfn_pte(pfn, prot) (__pte(((pte_t)(pfn) << PAGE_SHIFT) | \
|
||||
pgprot_val(prot)))
|
||||
#define pfn_pte(pfn, prot) (__pte(((pfn) << PAGE_SHIFT) | pgprot_val(prot)))
|
||||
#define __pte_index(addr) (((addr) >> PAGE_SHIFT) & (PTRS_PER_PTE - 1))
|
||||
|
||||
/*
|
||||
|
||||
@@ -83,7 +83,10 @@
|
||||
"2: ;nop\n" \
|
||||
" .section .fixup, \"ax\"\n" \
|
||||
" .align 4\n" \
|
||||
"3: mov %0, %3\n" \
|
||||
"3: # return -EFAULT\n" \
|
||||
" mov %0, %3\n" \
|
||||
" # zero out dst ptr\n" \
|
||||
" mov %1, 0\n" \
|
||||
" j 2b\n" \
|
||||
" .previous\n" \
|
||||
" .section __ex_table, \"a\"\n" \
|
||||
@@ -101,7 +104,11 @@
|
||||
"2: ;nop\n" \
|
||||
" .section .fixup, \"ax\"\n" \
|
||||
" .align 4\n" \
|
||||
"3: mov %0, %3\n" \
|
||||
"3: # return -EFAULT\n" \
|
||||
" mov %0, %3\n" \
|
||||
" # zero out dst ptr\n" \
|
||||
" mov %1, 0\n" \
|
||||
" mov %R1, 0\n" \
|
||||
" j 2b\n" \
|
||||
" .previous\n" \
|
||||
" .section __ex_table, \"a\"\n" \
|
||||
|
||||
@@ -107,13 +107,13 @@ static int restore_usr_regs(struct pt_regs *regs, struct rt_sigframe __user *sf)
|
||||
struct user_regs_struct uregs;
|
||||
|
||||
err = __copy_from_user(&set, &sf->uc.uc_sigmask, sizeof(set));
|
||||
if (!err)
|
||||
set_current_blocked(&set);
|
||||
|
||||
err |= __copy_from_user(&uregs.scratch,
|
||||
&(sf->uc.uc_mcontext.regs.scratch),
|
||||
sizeof(sf->uc.uc_mcontext.regs.scratch));
|
||||
if (err)
|
||||
return err;
|
||||
|
||||
set_current_blocked(&set);
|
||||
regs->bta = uregs.scratch.bta;
|
||||
regs->lp_start = uregs.scratch.lp_start;
|
||||
regs->lp_end = uregs.scratch.lp_end;
|
||||
@@ -138,7 +138,7 @@ static int restore_usr_regs(struct pt_regs *regs, struct rt_sigframe __user *sf)
|
||||
regs->r0 = uregs.scratch.r0;
|
||||
regs->sp = uregs.scratch.sp;
|
||||
|
||||
return err;
|
||||
return 0;
|
||||
}
|
||||
|
||||
static inline int is_do_ss_needed(unsigned int magic)
|
||||
|
||||
@@ -130,14 +130,17 @@ static cycle_t arc_counter_read(struct clocksource *cs)
|
||||
cycle_t full;
|
||||
} stamp;
|
||||
|
||||
|
||||
__asm__ __volatile(
|
||||
"1: \n"
|
||||
" lr %0, [AUX_RTC_LOW] \n"
|
||||
" lr %1, [AUX_RTC_HIGH] \n"
|
||||
" lr %2, [AUX_RTC_CTRL] \n"
|
||||
" bbit0.nt %2, 31, 1b \n"
|
||||
: "=r" (stamp.low), "=r" (stamp.high), "=r" (status));
|
||||
/*
|
||||
* hardware has an internal state machine which tracks readout of
|
||||
* low/high and updates the CTRL.status if
|
||||
* - interrupt/exception taken between the two reads
|
||||
* - high increments after low has been read
|
||||
*/
|
||||
do {
|
||||
stamp.low = read_aux_reg(AUX_RTC_LOW);
|
||||
stamp.high = read_aux_reg(AUX_RTC_HIGH);
|
||||
status = read_aux_reg(AUX_RTC_CTRL);
|
||||
} while (!(status & _BITUL(31)));
|
||||
|
||||
return stamp.full;
|
||||
}
|
||||
|
||||
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long address, struct pt_regs *regs,
|
||||
if (state.fault)
|
||||
goto fault;
|
||||
|
||||
/* clear any remanants of delay slot */
|
||||
if (delay_mode(regs)) {
|
||||
regs->ret = regs->bta;
|
||||
regs->ret = regs->bta & ~1U;
|
||||
regs->status32 &= ~STATUS_DE_MASK;
|
||||
} else {
|
||||
regs->ret += state.instr_len;
|
||||
|
||||
@@ -960,11 +960,16 @@ void arc_cache_init(void)
|
||||
/* check for D-Cache aliasing on ARCompact: ARCv2 has PIPT */
|
||||
if (is_isa_arcompact()) {
|
||||
int handled = IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
|
||||
int num_colors = dc->sz_k/dc->assoc/TO_KB(PAGE_SIZE);
|
||||
|
||||
if (dc->alias && !handled)
|
||||
panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
|
||||
else if (!dc->alias && handled)
|
||||
if (dc->alias) {
|
||||
if (!handled)
|
||||
panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
|
||||
if (CACHE_COLORS_NUM != num_colors)
|
||||
panic("CACHE_COLORS_NUM not optimized for config\n");
|
||||
} else if (!dc->alias && handled) {
|
||||
panic("Disable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -39,6 +39,7 @@ config ARM
|
||||
select HAVE_ARCH_HARDENED_USERCOPY
|
||||
select HAVE_ARCH_SECCOMP_FILTER if (AEABI && !OABI_COMPAT)
|
||||
select HAVE_ARCH_TRACEHOOK
|
||||
select HAVE_ARM_SMCCC if CPU_V7
|
||||
select HAVE_BPF_JIT
|
||||
select HAVE_CC_STACKPROTECTOR
|
||||
select HAVE_CONTEXT_TRACKING
|
||||
@@ -230,6 +231,9 @@ config NEED_RET_TO_USER
|
||||
config ARCH_MTD_XIP
|
||||
bool
|
||||
|
||||
config ARCH_WANT_KMAP_ATOMIC_FLUSH
|
||||
bool
|
||||
|
||||
config VECTORS_BASE
|
||||
hex
|
||||
default 0xffff0000 if MMU || CPU_HIGH_VECTOR
|
||||
@@ -652,6 +656,7 @@ config ARCH_QCOM
|
||||
select SPARSE_IRQ
|
||||
select USE_OF
|
||||
select PINCTRL
|
||||
select ARCH_WANT_KMAP_ATOMIC_FLUSH
|
||||
help
|
||||
Support for Qualcomm MSM/QSD based systems. This runs on the
|
||||
apps processor of the MSM/QSD and depends on a shared memory
|
||||
@@ -1458,8 +1463,7 @@ config BIG_LITTLE
|
||||
|
||||
config BL_SWITCHER
|
||||
bool "big.LITTLE switcher support"
|
||||
depends on BIG_LITTLE && MCPM && HOTPLUG_CPU
|
||||
select ARM_CPU_SUSPEND
|
||||
depends on BIG_LITTLE && MCPM && HOTPLUG_CPU && ARM_GIC
|
||||
select CPU_PM
|
||||
help
|
||||
The big.LITTLE "switcher" provides the core functionality to
|
||||
@@ -1517,7 +1521,7 @@ config HOTPLUG_CPU
|
||||
|
||||
config ARM_PSCI
|
||||
bool "Support for the ARM Power State Coordination Interface (PSCI)"
|
||||
depends on CPU_V7
|
||||
depends on HAVE_ARM_SMCCC
|
||||
select ARM_PSCI_FW
|
||||
help
|
||||
Say Y here if you want Linux to communicate with system firmware
|
||||
@@ -2223,7 +2227,8 @@ config ARCH_SUSPEND_POSSIBLE
|
||||
def_bool y
|
||||
|
||||
config ARM_CPU_SUSPEND
|
||||
def_bool PM_SLEEP
|
||||
def_bool PM_SLEEP || BL_SWITCHER || ARM_PSCI_FW
|
||||
depends on ARCH_SUSPEND_POSSIBLE
|
||||
|
||||
config ARCH_HIBERNATION_POSSIBLE
|
||||
bool
|
||||
|
||||
@@ -86,6 +86,18 @@ config FORCE_PAGES
|
||||
|
||||
If unsure say N.
|
||||
|
||||
config FREE_PAGES_RDONLY
|
||||
bool "Set pages as read only while on the buddy list"
|
||||
select FORCE_PAGES
|
||||
select PAGE_POISONING
|
||||
help
|
||||
Pages are always mapped in the kernel. This means that anyone
|
||||
can write to the page if they have the address. Enable this option
|
||||
to mark pages as read only to trigger a fault if any code attempts
|
||||
to write to a page on the buddy list. This may have a performance
|
||||
impact.
|
||||
|
||||
If unsure, say N.
|
||||
|
||||
# These options are only for real kernel hackers who want to get their hands dirty.
|
||||
config DEBUG_LL
|
||||
|
||||
@@ -47,6 +47,8 @@
|
||||
#include "armada-39x.dtsi"
|
||||
|
||||
/ {
|
||||
compatible = "marvell,armada390";
|
||||
|
||||
soc {
|
||||
internal-regs {
|
||||
pinctrl@18000 {
|
||||
@@ -54,4 +56,5 @@
|
||||
reg = <0x18000 0x20>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
@@ -122,6 +122,8 @@
|
||||
uart1: serial@f8020000 {
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pinctrl_uart1_default>;
|
||||
atmel,use-dma-rx;
|
||||
atmel,use-dma-tx;
|
||||
status = "okay";
|
||||
};
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user