The generation of kheader.tar.xz file uses xargs in ways that seems to
be unaccepatble by certain build environments, thus leading to build
failures. Disable the CONFIG to avoid the situation.
Change-Id: Ib7a2ca0c449f22021e80ac1382a9e5bdf6b388ba
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Enable interconnect L3 driver so that consumer can vote
for L3 performance points.
Change-Id: I1ec2064db2c06a3e9c9b04de865c9b78dc3db9c6
Signed-off-by: David Dai <daidavid1@codeaurora.org>
Move qseecom specific workarounds to the main file. This allows
access to the scm device struct.
Change-Id: I08bb227e88a7ba21bce0d3e7911819b07815c83f
Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org>
Having the same node being added to bcm voter commit list will result
in an infinite loop when walking through the list. Prevent the same
node from being added multiple times by checking bcm->list and
clean up commit list after sending the commands to RPMh.
Change-Id: Ie210437df43efd537bdcb0143b03423964ac3840
Signed-off-by: David Dai <daidavid1@codeaurora.org>
The QTI Tri-LED driver enables the configuration of the output of LED
channels in the TRI_LED and HR_LED peripherals found in QTI PMICs.
This is a snapshot of the driver taken from msm-4.19 as of commit
cf2cbb63fb60 ("Merge "input: touchscreen: synaptics_tcm: enable touch
driver"") with the following modifications:
- Remove the setting of struct pwm_output_pattern to NULL in
__tri_led_config_pwm()
- Remove LED_KEEP_TRIGGER from qpnp_tri_led_register()
- Add a MODULE_SOFTDEP link to the QTI PWM LPG driver so that modprobe
can enforce the functional dependency on it.
Change-Id: I7ceb2ff1a9ed1fec09651744ec2e7b2ba73f1bae
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
This driver supports communication with secure processor subsystem
(SPSS) over rpmsg and ungerlying glink transport layer. The
communication is based on using shared memory and interrupts.
Add snapshot for spcom driver from msm-4.19 commit b3159f82fb1b
("soc: qcom: spcom: fix active pid clean up").
Change-Id: Ic35584e8770980e2f480949808529a1d933da1f6
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
There are a few a3xx and a5xx targets that use the downstream API
clk_set_flags() for power control. The bad news is that this is API is
not upstream, but the good news is that none of the targets that require
it are likely to be used in this kernel so we can safely keep most
of the target support and replace these calls with a WARN_ON mostly
as a nod to developers that might try to use this code as an example
for adding new target support later.
Change-Id: Ic0dedbad440b410d31a933891e436ea136bc796a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Remove some memory accounting that is unsupported in the upstream kernel.
If the feature that used these statistics returns then these can be
easily returned to their rightful places.
Change-Id: Ic0dedbadf56ab28d6610d52ab6e901dc8f9dadff
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add a Kconfig option to allow the driver to mark all memory buffers
as I/O coherent by default if the target supports I/O coherency.
This is a config option for now because I/O coherency has traditionally
been a little fickle and it represents a paradigm shift to enable it
universally. Eventually the goal is to leave it on by default and invert
the polarity of this option.
In conjunction we can use this option to manage kernel targets that do not
not support fine grained cache operations. Because it is impossible to stop
the user from creating and using cached surfaces the driver has
to either support I/O coherency by default OR have access to fine grained
cache operations. We can take advantage of the new Kconfig option to
make some compile time decisions and compile out the cache code if it isn't
supported.
This isn't 100% foolproof though. If your target doesn't support I/O
coherency and there are no cache operations available you are out of luck,
so as it stands this precludes cached operations on a3xx and a5xx with this
kernel. We will still allow cached surfaces but they will never be
coherent. If this becomes a problem we'll need to figure out a way to
disallow cached surfaces on those targets.
Change-Id: Ic0dedbad7d923b54f64f34cd68a59c3522ca5ee9
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Remove the unused bus.mod member and make the bus governor compile in the
new directory structure.
Change-Id: I8c9bf21bb3b260cc932e1a0e1835788905cd67b5
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
With the demise of msm_bus_scale we lost the API to generate TCS
commands so we need to do it ourselves.
Change-Id: Ic0dedbadad9bead0508febcb942e5bb1bd6cb465
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Instead of using a bespoke function to get the list of clocks, use the
built in functions instead. To do this, we'll need a local function
to get a clock pointer by name from the list so this is a great time to
add a file just for general purpose driver functions.
Change-Id: Ic0dedbad96f478afc1a416a94df7c0e203ecca8a
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Replace all of the legacy bus scaling code with the new interconnect API.
This includes removing all msm_bus support as well as the devbw interface
which is not needed since icc can set both the IB and the AB on our behalf.
As part of this, move most of the bus specific code into its own file,
add support for parsing a table of our own from the device tree and handle
both the GPU and GMU bus setting paths properly.
Change-Id: Ic0dedbadfbb3c48ec414ec60e3032b2204b4e724
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
The other reason why we define a OPP table for each target is for devfreq.
This is equally as silly as the first reason because we already have a
frequency table and forcing the developer to define it twice only invites
a mistake. Remove the need for the static OPP table and create it
dynamically, at run time, from the information we already have.
Change-Id: Ic0dedbada16ec0832c0d531f39460f14aadc1bdd
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
There are only two reasons for us to define a OPP table these days, and
one of them is to define the voltage levels that we send to the GMU.
That is silly because we have a perfectly good power level definition
already handy. Move the levels to the GPU definition and use them
accordingly.
Change-Id: Ic0dedbad2d3c84a2de7cda5311ff99e96434b9e5
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add a copy of the Adreno GPU bandwidth governor from msm-4.19 as of
01dafb76 ("Merge "power: qpnp-qnovo5: Add standalone class param"")
Like the GPU frequency governor, move it to the KGSL driver directory
to share local headers.
Change-Id: Ic0dedbadbdeef532a3e847db759b9840282064da
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Life goes on, and so does the kernel. Update some API changes since
msm-4.19 including helper functions for vmfault functions, renaming
a memory statistic, updating cmd-db and removing __mutex_user which
is not longer available.
Change-Id: Ic0dedbad0b24042f3683a4be99888a0aa86baf78
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Add a copy of the Adreno GPU frequency governor as of
01dafb76 ("Merge "power: qpnp-qnovo5: Add standalone class param"").
Instead of keeping the governor in drivers/devfreq, move it to the GPU
driver directory so that it can share a header file with the GPU driver.
Change-Id: Ic0dedbada21ca0310ce1ce69126fa0096c70c2e6
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
There was a time, long long ago, when having a "zero" power level made
sense because a "zero" powerlevel wasn't really "zero". That is no longer
the case and it is silly to force the DT to define it for EVERY. SINGLE.
TARGET. Get rid of it and assume that zero is, well... zero.
Change-Id: Ic0dedbadc5551585de893cdb5b3ed948a62aa430
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
