Enable CPU cooling device to mitigate the CPU frequency in lahaina.
Adding the #cooling-cells property will enable the cpufreq driver to
register CPU cooling device.
Change-Id: I50e2fcdcc259337d2f4501a75b1a756546cbbbd0
Hardware with revision 2 is changed to use 8-bit FIFO memory while
revision 1 is using 9-bit FIFO memory. To unify the data assignment
from devicetree, change to use 8-bit data for "qcom,wf-fifo-data"
property. Software can expand the 8-bit data to 9-bit for V1
hardware accordingly.
Change-Id: I00749a3cb395bf38ffd4d0cc9fd48de29b949c6d
Add the swr-slave regulator device node in pm8350b haptics module for
swr-haptics device to control the SWR slave online status.
Change-Id: Ib3ee6fe8f8d4357392a64f06123e482f41ef8308
Add a subnode to define a regulator device to control the online status
of the SWR slave in haptics module.
Change-Id: I2e97a9ab4f4499ab0cce23f626d1834a4f7e90c1
Add the QMP and QMP DEBUGFS node to facilitiate communication with AOP.
The QMP driver sends messages using the AOP msgram with a mailbox like
protocol.
Change-Id: I281738bf848b97bc975bdb892731f729128d8ac2
Add the device tree entries for glink driver and glink packet driver
to provide the communication with remote peripherals.
Change-Id: Iac0cb5bbc55a081a12d8dd0b166a149f11b09f29
Add 4 new compute DSP context banks for lahaina, in addition to
the existing 8 context banks, so that 12 concurrent fastrpc
sessions can be run on the remote subsystem.
Change-Id: Id3117510972d002e0d345157295dec9d271b2de7
Acked-by: Thyagarajan Venkatanarayanan <venkatan@qti.qualcomm.com>
Add a definition for the qcom,pmic-arb property which can be used
by consumer devices to reference an spmi-pmic-arb device.
Change-Id: Ib891890c4892446aff1c5d4cba133efd6f239b9e
The register base and size for the dc_noc is incorrect. Let's fix it
with what we have in the documentation.
Change-Id: Ifbd44ef6bf9889457ebd93c8b1ab39f9c5e34591
Normally, the TCS needs to wait for completion in both AMC and WAKE
sets, since we need to be sure all necessary system resources are
available before they are used. However, the display RSC has strict
wakeup timelines to meet and thus cannot take the latency hit caused by
waiting for completion in the WAKE set. The display RSC will perform
additional processing in between when the WAKE request is sent and
completed. The apps RSC will hold minimum votes on each required
resource to ensure they are enabled, which prevents any unclocked
access. The display RSC is just responsible for scaling to the required
performance levels. The worst that can happen if the WAKE request isn't
satisfied in time is a dropped frame.
Change-Id: Id3757b2ffc73ee93ed8f97d7d591e135150c9cdc