Property #stream-id-cells is legacy leftover and isn't currently
documented nor used.
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20211208184707.100716-1-david@ixit.cz
Add device node for Sleep stats driver which provides various
low power mode stats on sc7180, sc7280, sm8150, sm8250 and sm8350.
Also update the reg size of aoss_qmp device to 0x400.
Cc: devicetree@vger.kernel.org
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1634107104-22197-5-git-send-email-mkshah@codeaurora.org
Use the Qualcomm Mailbox Protocol (QMP) property to control the load
state resources on SC7180 SoCs and drop deprecated power-domains exposed
by AOSS QMP node.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1631800770-371-6-git-send-email-sibis@codeaurora.org
The sc7180's dynamic-power-coefficient violates the device tree bindings.
The bindings (arm/cpus.yaml) say that the units for the
dynamic-power-coefficient are supposed to be "uW/MHz/V^2". The ones for
sc7180 aren't this. Qualcomm arbitrarily picked 100 for the "little" CPUs
and then picked a number for the big CPU based on this.
At the time, there was a giant dicussion about this. Apparently Qualcomm
Engineers were instructed not to share the actual numbers here. As part
of the discussion, I pointed out [1] that these numbers shouldn't really
be secret since once a device is shipping anyone can just run a script
and produce them. This patch is the result of running the script I posted
in that discussion on sc7180-trogdor-coachz, which is currently available
for purchase by consumers.
[1] https://lore.kernel.org/r/CAD=FV=U1FP0e3_AVHpauUUZtD-5X3XCwh5aT9fH_8S_FFML2Uw@mail.gmail.com/
I ran the script four times, measuring little, big, little, big. I used
the 64-bit version of dhrystone 2.2 in my test. I got these results:
576 kHz, 596 mV, 20 mW, 88 Cx
768 kHz, 596 mV, 32 mW, 122 Cx
1017 kHz, 660 mV, 45 mW, 97 Cx
1248 kHz, 720 mV, 87 mW, 139 Cx
1324 kHz, 756 mV, 109 mW, 148 Cx
1516 kHz, 828 mV, 150 mW, 148 Cx
1612 kHz, 884 mV, 182 mW, 147 Cx
1708 kHz, 884 mV, 192 mW, 146 Cx
1804 kHz, 884 mV, 207 mW, 149 Cx
Your dynamic-power-coefficient for cpu 0: 132
825 kHz, 596 mV, 142 mW, 401 Cx
979 kHz, 628 mV, 183 mW, 427 Cx
1113 kHz, 656 mV, 224 mW, 433 Cx
1267 kHz, 688 mV, 282 mW, 449 Cx
1555 kHz, 812 mV, 475 mW, 450 Cx
1708 kHz, 828 mV, 566 mW, 478 Cx
1843 kHz, 884 mV, 692 mW, 476 Cx
1900 kHz, 884 mV, 722 mW, 482 Cx
1996 kHz, 916 mV, 814 mW, 482 Cx
2112 kHz, 916 mV, 862 mW, 483 Cx
2208 kHz, 916 mV, 962 mW, 521 Cx
2323 kHz, 940 mV, 1060 mW, 517 Cx
2400 kHz, 956 mV, 1133 mW, 518 Cx
Your dynamic-power-coefficient for cpu 6: 471
576 kHz, 596 mV, 26 mW, 103 Cx
768 kHz, 596 mV, 40 mW, 147 Cx
1017 kHz, 660 mV, 54 mW, 114 Cx
1248 kHz, 720 mV, 97 mW, 151 Cx
1324 kHz, 756 mV, 113 mW, 150 Cx
1516 kHz, 828 mV, 154 mW, 148 Cx
1612 kHz, 884 mV, 194 mW, 155 Cx
1708 kHz, 884 mV, 203 mW, 152 Cx
1804 kHz, 884 mV, 219 mW, 155 Cx
Your dynamic-power-coefficient for cpu 0: 142
825 kHz, 596 mV, 148 mW, 530 Cx
979 kHz, 628 mV, 189 mW, 475 Cx
1113 kHz, 656 mV, 230 mW, 461 Cx
1267 kHz, 688 mV, 287 mW, 466 Cx
1555 kHz, 812 mV, 469 mW, 445 Cx
1708 kHz, 828 mV, 567 mW, 480 Cx
1843 kHz, 884 mV, 699 mW, 482 Cx
1900 kHz, 884 mV, 719 mW, 480 Cx
1996 kHz, 916 mV, 814 mW, 484 Cx
2112 kHz, 916 mV, 861 mW, 483 Cx
2208 kHz, 916 mV, 963 mW, 522 Cx
2323 kHz, 940 mV, 1063 mW, 520 Cx
2400 kHz, 956 mV, 1135 mW, 519 Cx
Your dynamic-power-coefficient for cpu 6: 489
As you can see, the calculations aren't perfectly consistent but
roughly you could say about 480 for big and 137 for little.
The ratio between these numbers isn't quite the same as the ratio
between the two numbers that Qualcomm used. Perhaps this is because
Qualcomm measured something slightly different than the 64-bit version
of dhrystone 2.2 or perhaps it's because they fudged these numbers a
bit (and fudged the capacity-dmips-mhz). As per discussion [2], let's
use the numbers I came up with and also un-fudge
capacity-dmips-mhz. While unfudging capacity-dmips-mhz, let's scale it
so that bigs are 1024 which seems to be the common practice.
In general these numbers don't need to be perfectly exact. In fact,
they can't be since the CPU power depends a lot on what's being run on
the CPU and the big/little CPUs are each more or less efficient in
different operations. Historically running the 32-bit vs. 64-bit
versions of dhrystone produced notably different numbers, though I
didn't test this time.
We also need to scale all of the sustainable-power numbers by the same
amount. I scale ones related to the big CPUs by the adjustment I made
to the big dynamic-power-coefficient and the ones related to the
little CPUs by the adjustment I made to the little
dynamic-power-coefficient.
[2] https://lore.kernel.org/r/0a865b6e-be34-6371-f9f2-9913ee1c5608@codeaurora.org/
Fixes: 71f873169a ("arm64: dts: qcom: sc7180: Add dynamic CPU power coefficients")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210902145127.v2.1.I049b30065f3c715234b6303f55d72c059c8625eb@changeid
As usual, the bulk of work in the SoC tree goes into DT files,
this time with a roughly even split between 32-bit and 64-bit
SoCs rather than the usual mostly 64-bit changes.
New SoCs:
- Microchip SAMA7 SoC family based on Cortex-A7, a new
32-bit platform based on the older SAMA5 series.
- Qualcomm Snapdragon SDM636 and SM8150, variations of the
existing phone SoCs.
- Renesas R-Car H3e-2G and M3e-2G SoCs, variations of
older Renesas SoCs.
New boards:
- Marvell CN913x reference boards
- ASpeed AST2600 BMC implementations for Facebook Cloudripper,
Elbert and Fuji server boards.
- Snapdragon 665 based Sony Xperia 10II
- Snapdragon MSM8916 based Xiaomi Redmi 2
- Snapdragon MSM8226 based Samsung Galaxy S3 Neo
- NXP i.MX based 32-bit boards:
- DHCOM based PicoITX
- DHSOM based DRC0ỉ
- SolidRun SolidSense
- SKOV i.MX6 boards.
- NXP i.MX based 64-bit boards:
- Nitrogen8 SoM and MNT Reform2
- LS1088A based Traverse Ten64
- i.MX8M based GW7902.
- NVIDIA Jetson TX2 NX Developer Kit
- 4KOpen STiH418-b2264 development board
- ux500 based Samsung phones: Gavini, Codina and Kyle
- TI AM335x based Sancloud BBE Lite
- ixp4xx dts files to replace all old board files
Other changes:
- Treewide fixes for dtc warnings
- Rockchips i/o domain support
- TI OMAP/AM3 CPSW switch driver support
- Improved device support for allwinner, aspeed, qualcomm, NXP,
nvidia, Renesas, Samsung, Amlogic, Mediatek, ixp4xx, stm32, sti,
OMAP and actions.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iD8DBQBhL13Z5t5GS2LDRf4RAljwAJ0acTxOBYP8J5zETlAQRWYcYWh5hACfZOgC
Om6K0IN5+lJuaUyF/GdmqS4=
=zXua
-----END PGP SIGNATURE-----
Merge tag 'dt-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC DT updates from Arnd Bergmann:
"As usual, the bulk of work in the SoC tree goes into DT files, this
time with a roughly even split between 32-bit and 64-bit SoCs rather
than the usual mostly 64-bit changes.
New SoCs:
- Microchip SAMA7 SoC family based on Cortex-A7, a new 32-bit
platform based on the older SAMA5 series.
- Qualcomm Snapdragon SDM636 and SM8150, variations of the existing
phone SoCs.
- Renesas R-Car H3e-2G and M3e-2G SoCs, variations of older Renesas
SoCs.
New boards:
- Marvell CN913x reference boards
- ASpeed AST2600 BMC implementations for Facebook Cloudripper, Elbert
and Fuji server boards.
- Snapdragon 665 based Sony Xperia 10II
- Snapdragon MSM8916 based Xiaomi Redmi 2
- Snapdragon MSM8226 based Samsung Galaxy S3 Neo
- NXP i.MX based 32-bit boards:
- DHCOM based PicoITX
- DHSOM based DRC0ỉ
- SolidRun SolidSense
- SKOV i.MX6 boards.
- NXP i.MX based 64-bit boards:
- Nitrogen8 SoM and MNT Reform2
- LS1088A based Traverse Ten64
- i.MX8M based GW7902.
- NVIDIA Jetson TX2 NX Developer Kit
- 4KOpen STiH418-b2264 development board
- ux500 based Samsung phones: Gavini, Codina and Kyle
- TI AM335x based Sancloud BBE Lite
- ixp4xx dts files to replace all old board files
Other changes:
- Treewide fixes for dtc warnings
- Rockchips i/o domain support
- TI OMAP/AM3 CPSW switch driver support
- Improved device support for allwinner, aspeed, qualcomm, NXP,
nvidia, Renesas, Samsung, Amlogic, Mediatek, ixp4xx, stm32, sti,
OMAP and actions"
* tag 'dt-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (412 commits)
arm/arm64: dts: Fix remaining dtc 'unit_address_format' warnings
ARM: dts: rockchip: Add SFC to RV1108
arm64: dts: marvell: armada-37xx: Extend PCIe MEM space
ARM: dts: aspeed: p10bmc: Add power control pins
ARM: dts: aspeed: cloudripper: Add comments for "mdio1"
ARM: dts: aspeed: minipack: Update flash partition table
dt-bindings: arm: fsl: Add Traverse Ten64 (LS1088A) board
dt-bindings: vendor-prefixes: add Traverse Technologies
arm64: dts: add device tree for Traverse Ten64 (LS1088A)
arm64: dts: ls1088a: add missing PMU node
arm64: dts: ls1088a: add internal PCS for DPMAC1 node
ARM: dts: imx6qp-prtwd3: configure ENET_REF clock to 125MHz
ARM: dts: vf610-zii-dev-rev-b: Remove #address-cells and #size-cells property from at93c46d dt node
ARM: dts: add SKOV imx6q and imx6dl based boards
dt-bindings: arm: fsl: add SKOV imx6q and imx6dl based boards
dt-bindings: vendor-prefixes: Add an entry for SKOV A/S
arm64: dts: imx8mq-reform2: add sound support
arm64: dts: imx8m: drop interrupt-affinity for pmu
arm64: dts: imx8qxp: update pmu compatible
arm64: dts: imx8mm: update pmu compatible
...
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmD95yIeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGqp0H/j/xHL20EHaUJOaV
iJjnfGyjtnkLC5FCoV/q/v9sFuSW2p4W1nyF8/eIgVKObef94Mg4/xxaHQrWIM56
cbzK9aIcD9InAuImJ6lju4fqjNmFrt2x7mhfzjPKqmhfINfZ5CohpLFN5XdOwzYC
l+ZgmUUl7GLDAND2M6rtkc7AOk4qTyAySDvvPFELE/uNgV4EKaENSIWofHhEzW5v
Yk+4agawaFTfa6H9+uMVYZBOcEKwheQ0E2tcOJvHJT8Mwm8MFoC/B7fLY5zxIdN2
7A7r/7qbSQmSDSjOgwKS4ZOjom0xGSD+V+596SzET6jkbahR2HJ/mrFvmD7GNEoW
OWJPjzI=
=vzIM
-----END PGP SIGNATURE-----
Merge tag 'v5.14-rc3' into arm64-for-5.15
The USB maintainer felt the strong need to push '1f958f3dff42
("Revert "arm64: dts: qcom: Harmonize DWC USB3 DT nodes name"")'
through the usb tree, so merge v5.14-rc3 to resolve the resulting merge
conflicts.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
qup-i2c devices on sc7180 are clocked with a fixed clock (19.2 MHz)
Though qup-i2c does not support DVFS, it still needs to vote for a
performance state on 'CX' to satisfy the 19.2 Mhz clock frequency
requirement.
Use 'required-opps' to pass this information from
device tree, and also add the power-domains property to specify
the CX power-domain.
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
modified QFPROM controller CORRECTED region size as per RAW region size
Signed-off-by: Ravi Kumar Bokka <rbokka@codeaurora.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/1613582792-5225-1-git-send-email-rbokka@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This reverts commit eb9b7bfd59 as it
breaks working userspace implementations (i.e. Android systems)
The device node name here is part of configfs, so it is a user-visable
api that can not be changed.
Reported-by: John Stultz <john.stultz@linaro.org>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/CALAqxLX_FNvFndEDWtGbFPjSzuAbfqxQE07diBJFZtftwEJX5A@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The calculations for the DLL register values are based on the clock rate
of the reference clock. Provide the reference clock in the definition of
the two SDHCI controllers to not rely on the default values.
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Link: https://lore.kernel.org/r/1623309107-27833-1-git-send-email-sbhanu@codeaurora.org
[bjorn: Rewrote commit message]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
As per Dmitry Baryshkov [1]:
a) The 2nd "reg" should be 0x3c because "Offset 0x38 is
USB3_DP_COM_REVISION_ID3 (not used by the current driver though)."
b) The 3rd "reg" "is a serdes region and qmp_v3_dp_serdes_tbl contains
registers 0x148 and 0x154."
I think because the 3rd "reg" is a serdes region we should just use
the same size as the 1st "reg"?
[1] https://lore.kernel.org/r/ee5695bb-a603-0dd5-7a7f-695e919b1af1@linaro.org
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Chandan Uddaraju <chandanu@codeaurora.org>
Cc: Vara Reddy <varar@codeaurora.org>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Fixes: 58fd7ae621 ("arm64: dts: qcom: sc7180: Update dts for DP phy inside QMP phy")
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315103836.1.I9a97120319d43b42353aeac4d348624d60687df7@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210324204836.29668-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We had introduced the QUP-CORE ICC path to put proxy votes from
QUP wrapper on behalf of earlycon, if other users of QUP-CORE turn
off this clock before the real console is probed, unclocked access
to HW was seen from earlycon.
With ICC sync state support proxy votes are no longer need as ICC
will ensure that the default bootloader votes are not removed until
all it's consumer are probed.
We can safely remove ICC path for QUP-CORE clock from QUP wrapper
device.
Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org>
Signed-off-by: Akash Asthana <akashast@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20210324101836.25272-3-rojay@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Move rmtfs memory region so that it does not overlap with system
RAM (kernel data) when KAsan is enabled. This puts rmtfs right
after mba_mem which is not supposed to increase beyond 0x94600000
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Sujit Kautkar <sujitka@chromium.org>
Link: https://lore.kernel.org/r/20210330014610.1451198-1-sujitka@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Using pdc interrupts for USB instead of GIC interrupts to
support wake up in case xo shutdown.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Sandeep Maheswaram <sanm@codeaurora.org>
Link: https://lore.kernel.org/r/1594235417-23066-4-git-send-email-sanm@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In general pinconf belongs in board files, not SoC files. Move it to
the only current user (trogdor). Also adjust the drive strengths and
pulls.
Cc: V Sujith Kumar Reddy <vsujithk@codeaurora.org>
Cc: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Cc: Tzung-Bi Shih <tzungbi@chromium.org>
Cc: Judy Hsiao <judyhsiao@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210301133318.v2.2.Id27e7e6f90c29bf623fa4880e18a14ba1dffd2d2@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Drop the old node and add the new one in its place.
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Chandan Uddaraju <chandanu@codeaurora.org>
Cc: Vara Reddy <varar@codeaurora.org>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
[dianders: Adjusted due to DP not itself not in upstream dts yet]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210301133318.v2.1.Iad06142ceb8426ce5492737bf3d9162ed0dd2b55@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Use the generic DT node name "power-controller" for AOSS message ram
instead of the protocol name QMP(Qualcomm Messaging Protocol) since
it is used for power management requests.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org>
Link: https://lore.kernel.org/r/e96d665d1e98b46a189a57e39575ae0debf37172.1614669585.git.saiprakash.ranjan@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The "modem-remoteproc" property is no longer required for the IPA
driver, so get rid of it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add labels to the cpuN-thermal nodes to allow board files to use
a phandle instead replicating the node hierarchy when adjusting
certain properties.
Due to the 'sustainable-power' property CPU thermal zones are
more likely to need property updates than other SC7180 zones,
hence only labels for CPU zones are added for now.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20210108141648.1.Ia8019b8b303ca31a06752ed6ceb5c3ac50bd1d48@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We shouldn't put any pinconf here in case someone decides to invert this
HPD signal or remove an external pull-down. It's better to leave that to
the board pinconf nodes, so drop it here.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reported-by: Douglas Anderson <dianders@chromium.org>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Fixes: 681a607ad2 ("arm64: dts: qcom: sc7180: Add DisplayPort HPD pin dt node")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20201215020004.731239-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Use GIC_SPI rather than 0 in the specifiers for the two ARM GIC
interrupts used by IPA.
Signed-off-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20201126015457.6557-3-elder@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Recently we learned that Android and Windows firmware don't seem to
like using 3 as an iommu mask value for IPA. A simple fix was to
specify exactly the streams needed explicitly, rather than implying
a range with the mask. Make the same change for the SC7180 platform.
See also:
https://lore.kernel.org/linux-arm-msm/20201123052305.157686-1-bjorn.andersson@linaro.org/
Fixes: d82fade846 ("arm64: dts: qcom: sc7180: add IPA information")
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20201126015457.6557-2-elder@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add DDR/L3 bandwidth votes for the pro variant of SC7180 SoC, as it support
frequencies upto 2.5 GHz.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Link: https://lore.kernel.org/r/1606198876-3515-2-git-send-email-sibis@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Commit 22337b9102 ("arm64: dts: qcom: sc7180: Changed polling mode
in Thermal-zones node") sets both 'polling-delay' and
'polling-delay-passive' to zero with the rationale that TSENS interrupts
are enabled. A TSENS interrupt fires when the temperature of a thermal
zone reaches a trip point, which makes regular polling below the passive
trip point temperature unnecessary. However the situation is different
when passive cooling is active, regular polling is still needed to
trigger a periodic evaluation of the thermal zone by the thermal governor.
Change 'polling-delay-passive' back to the original value of 250 ms.
Commit 2315ae70af ("arm64: dts: qcom: sc7180: Add gpu cooling
support") recently changed the value for the GPU thermal zones from
zero to 100 ms, also set it to 250 ms for uniformity. If some zones
really need different values these can be changed in dedicated patches.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Fixes: 22337b9102 ("arm64: dts: qcom: sc7180: Changed polling mode in Thermal-zones node")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20201111120334.1.Ifc04ea235c3c370e3b21ec3b4d5dead83cc403b4@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
After many years of struggle, commit fa2d0aa969 ("mmc: core: Allow
setting slot index via device tree alias") finally allows the use of
aliases to number SD/MMC slots. Let's do that for sc7180 SoCs so that
if eMMC and SD are both used they have consistent numbers across boots
and kernel changes.
Picking numbers can be tricky. Do we call these "1" and "2" to match
the name in documentation or "0" and "1" with the assertion that we
should always start at 0 and count up?
While the "start counting at 0" makes sense if there are not already
well-defined numbers for all sd/mmc controllers, in the case of sc7180
there _are_ well defined numbers. IMO it is less confusing to use
those and match the docs.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201111073652.1.Ia5bccd9eab7d74ea1ea9a7780e3cdbf662f5a464@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen <akhilpo@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/1604054832-3114-2-git-send-email-akhilpo@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add the camera clock controller node supported on SC7180.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Link: https://lore.kernel.org/r/1604687907-25712-1-git-send-email-tdas@codeaurora.org
[bjorn: Dropped camcc include]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20200905200454.240929-21-robdclark@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add the soc-specific compatible string so that it can be matched
more specifically now that the driver cares which SoC it's on.
Signed-off-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201028172737.v3.2.Ia3b68ac843df93c692627a3a92b947b3a5785863@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
When the chip select line is controlled by the QUP, changing CS is a
time consuming operation. We have to send a command over to the geni
and wait for it to Ack us every time we want to change (both making it
high and low). To send this command we have to make a choice in
software when we want to control the chip select, we have to either:
A) Wait for the Ack via interrupt which slows down all SPI transfers
(and incurrs extra processing associated with interrupts).
B) Sit in a loop and poll, waiting for the Ack.
Neither A) nor B) is a great option.
We can avoid all of this by realizing that, at least on some boards,
there is no advantage of considering this line to be a geni line.
While it's true that geni _can_ control the line, it's also true that
the line can be a GPIO and there is no downside of viewing it that
way. Setting a GPIO is a simple MMIO operation.
This patch provides definitions so a board can easily select the GPIO
mode.
NOTE: apparently, it's possible to run the geni in "GSI" mode. In GSI
the SPI port is allowed to be controlled by more than one user (like
firmware and Linux) and also the port can operate sequences of
operations in one go. In GSI mode it _would_ be invalid to look at
the chip select as a GPIO because that would prevent other users from
using it. In theory GSI mode would also avoid some overhead by
allowing us to sequence the chip select better. However, I'll argue
GSI is not relevant for all boards (and certainly not any boards
supported by mainline today). Why?
- Apparently to run a SPI chip in GSI mode you need to initialize it
(in the bootloader) with a different firmware and then it will
always run in GSI mode. Since there is no support for GSI mode in
the current Linux driver, it must be that existing boards don't have
firmware that's doing that. Note that the kernel device tree
describes hardware but also firmware, so it is legitimate to make
the assumption that we don't have GSI firmware in a given dts file.
- Some boards with sc7180 have SPI connected to the Chrome OS EC or
security chip (Cr50). The protocols for talking to cros_ec and cr50
are extremely complex. Both drivers in Linux fully lock the bus
across several distinct SPI transfers. While I am not an expert on
GSI mode it feels highly unlikely to me that we'd ever be able to
enable GSI mode for these devices.
From a testing perspective, running "flashrom -p ec -r /tmp/foo.bin"
in a loop after this patch shows almost no reduction in time, but the
number of interrupts per command goes from 32357 down to 30611 (about
a 5% reduction).
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Akash Asthana <akashast@codeaurora.org>
Link: https://lore.kernel.org/r/20200921142655.v3.1.I997a428f58ef9d48b37a27a028360f34e66c00ec@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In commit e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number
of interconnect cells") we missed increasing the cells on one
interconnect. That's no bueno. Fix it.
NOTE: it appears that things aren't totally broken without this fix,
but clearly something isn't going to be working right. If nothing
else, without this fix I see this in the logs:
OF: /soc@0/mdss@ae00000: could not get #interconnect-cells for /soc@0/interrupt-controller@17a00000
Fixes: e23b1220a2 ("arm64: dts: qcom: sc7180: Increase the number of interconnect cells")
Reviewed-by: Georgi Djakov <georgi.djakov@linaro.org>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20201001141838.1.I08054d1d976eed64ffa1b0e21d568e0dc6040b54@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Increase the number of interconnect-cells, as now we can include
the tag information. The consumers can specify the path tag as an
additional argument to the endpoints.
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Tested-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Link: https://lore.kernel.org/r/20200903133134.17201-8-georgi.djakov@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The number of interrupt cells for the mdss interrupt controller is 1,
meaning there should only be one cell for the interrupt number, not two
where the second cell is the irq flags. Drop the second cell to match
the binding.
Cc: Kalyan Thota <kalyan_t@codeaurora.org>
Cc: Harigovindan P <harigovi@codeaurora.org
Fixes: a3db7ad1af ("arm64: dts: sc7180: add display dt nodes")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20200811192503.1811462-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Move the bus clock to mdp device node,in order
to facilitate bus band width scaling on sc7180
target.
The parent device MDSS will not vote for bus bw,
instead the vote will be triggered by mdp device
node. Since a minimum vote is required to turn
on bus clock, move the clock node to mdp device
from where the votes are requested.
This patch has dependency on the below series
https://patchwork.kernel.org/patch/11468783/
Reviewed-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Krishna Manikandan <mkrishn@codeaurora.org>
Link: https://lore.kernel.org/r/1594899334-19772-2-git-send-email-kalyan_t@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add the bandwidth domain supporting performance state and
the corresponding OPP tables for the sdhc device on sc7180.
Signed-off-by: Pradeep P V K <ppvk@codeaurora.org>
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Link: https://lore.kernel.org/r/1597646464-1863-1-git-send-email-sbhanu@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The 'sustainable_power' attribute provides an estimate of the sustained
power that can be dissipated at the desired control temperature. One
could argue that this value is not necessarily the same for all devices
with the same SoC, which may have different form factors or thermal
designs. However there are reasons to specify a (default) value at SoC
level for SC7180: most importantly, if no value is specified at all the
power_allocator thermal governor (aka 'IPA') estimates a value, using the
minimum power of all cooling devices of the zone, which can result in
overly aggressive thermal throttling. For most devices an approximate
conservative value should be more useful than the minimum guesstimate
of power_allocator. Devices that need a different value can overwrite
it in their <device>.dts. Also the thermal zones for SC7180 have a high
level of granularity (essentially one for each function block), which
makes it more likely that the default value just works for many devices.
The values correspond to 1901 MHz for the big cores, and 1804 MHz for
the small cores. The values were determined by limiting the CPU
frequencies to different max values and launching a bunch of processes
that cause high CPU load ('while true; do true; done &' is simple and
does a good job). A frequency is deemed sustainable if the CPU
temperatures don't rise (consistently) above the second trip point
('control temperature', 95 degC in this case). Once the highest
sustainable frequency is found, the sustainable power can be calculated
by multiplying the energy consumption per core at this frequency (which
can be found in /sys/kernel/debug/energy_model/) with the number of
cores that are specified as cooling devices.
The sustainable frequencies were determined at room temperature
on a device without heat sink or other passive cooling elements.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20200813113030.1.I89c33c4119eaffb986b1e8c1bc6f0e30267089cd@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
