arm64: dts: qcom: sc7280: Update domain-idle-states for cluster sleep

QCM6490 uses Trustzone as firmware whereas SC7280 uses arm trusted firmware.
The PSCI suspend param and the number of domain-idle-states supported is
different in Trustzone for cluster sleep.

Move the arm trusted firmware supported domain-idle-states in chrome specific
sc7280-chrome-common.dtsi and add the Trustzone supported sleep states as default
domain-idle-states in sc7280.dtsi

Signed-off-by: Maulik Shah <quic_mkshah@quicinc.com>
Link: https://lore.kernel.org/r/20240109-qcm6490_cluster_sleep-v2-1-8f94f1ad188d@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Move video-firmware to chrome-common

If the video-firmware node is present, the venus driver assumes we're on
a system that doesn't use TZ for starting venus, like on ChromeOS
devices.

Move the video-firmware node to chrome-common.dtsi so we can use venus
on a non-ChromeOS devices. We also need to move the secure SID 0x2184
for iommu since (on some boards) we cannot touch that.

At the same time also disable the venus node by default in the dtsi,
like it's done on other SoCs.

Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Vikash Garodia <quic_vgarodia@quicinc.com>
Link: https://lore.kernel.org/r/20231201-sc7280-venus-pas-v3-2-bc132dc5fc30@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280*: move MPSS and WPSS memory to dtsi

It appears that all SC7280-based devices so far have mpss_mem and
wpss_mem on the same reg with the same size.

Also these memory regions are referenced already in sc7280.dtsi so
that's where they should also be defined.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-4-6aa394d33edf@fairphone.com
[bjorn: delete-node &wpss_mem in qcs6490 rb3gen2, and qcm6490 idp]
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Add CDSP node

Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.

Remove the reserved-memory node from sc7280-chrome-common since CDSP is
currently not used there.

Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-9-6aa394d33edf@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Add ADSP node

Add the node for the ADSP found on the SC7280 SoC, using standard
Qualcomm firmware.

Acked-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-8-6aa394d33edf@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Use WPSS PAS instead of PIL

The wpss-pil driver wants to manage too many resources that cannot be
touched with standard Qualcomm firmware.

Use the compatible from the PAS driver and move the ChromeOS-specific
bits to sc7280-chrome-common.dtsi.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20231208-sc7280-remoteprocs-v3-7-6aa394d33edf@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Add ZAP shader support

Non-Chrome SC7280-family platforms ship a ZAP shader with the Adreno GPU.
Describe that and make sure it doesn't interfere with Chrome devices.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230926-topic-a643-v2-1-06fa3d899c0a@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Mark some nodes as 'reserved'

With the standard Qualcomm TrustZone setup, components such as lpasscc,
pdc_reset and watchdog shouldn't be touched by Linux. Mark them with
the status 'reserved' and reenable them in the chrome-common dtsi.

Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Link: https://lore.kernel.org/r/20230919-fp5-initial-v2-1-14bb7cedadf5@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Mark SCM as dma-coherent for chrome devices

Just like for sc7180 devices using the Chrome bootflow (AKA trogdor
and IDP), sc7280 devices using the Chrome bootflow also need their
firmware marked dma-coherent. On sc7280 this wasn't causing WiFi to
fail to startup, since WiFi works differently there. However, on
sc7280 devices we were still getting the message at bootup after
commit 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache
invalidation from arch_dma_prep_coherent()"""):

qcom_scm firmware:scm: Assign memory protection call failed -22
qcom_rmtfs_mem 9c900000.memory: assign memory failed
qcom_rmtfs_mem: probe of 9c900000.memory failed with error -22

We should mark SCM properly just like we did for trogdor.

Fixes: 7bd6680b47fa ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""")
Fixes: 7a1f4e7f740d ("arm64: dts: qcom: sc7280: Add basic dts/dtsi files for sc7280 soc")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230616081440.v2.4.I21dc14a63327bf81c6bb58fe8ed91dbdc9849ee2@changeid
Signed-off-by: Bjorn Andersson <andersson@kernel.org>

arm64: dts: qcom: sc7280: Fix qspi pin config

Similar to sc7180 (see the patch ("arm64: dts: qcom: sc7180: Fix
trogdor qspi pin config")), we should adjust the qspi pin config for
sc7280.

I won't re-describe all the research/arguments in the sc7180 patch
here, but there are a few differences for sc7280 worth noting:

1. On herobrine the SPI flash (qspi) is wired up differently on the
board. Rather than Cr50 and the AP being wired directly together,
there's actually a mux that will _either_ connect the AP to the
flash or Cr50 to the flash. This means that the internal pulls on
Cr50 don't affect us and we should enable our own pulldowns.

2. On herobrine, EEs added an external pulldown on the MISO line. The
argument in the schematic said that we added it (but not one on
MOSI and CLK) because Cr50 already enabled pulldowns on MOSI and
CLK. ...though, as per #1, those Cr50 pulldowns would only affect
the line when the mux was swung to Cr50.

The ironic result of #1 and #2 is that the external pulldowns on
CLK/MISO/MOSI on herobrine are _exactly opposite_ of the ones on
trogdor.

3. While I still don't have the actual exact schematics for all
variants of IDP/CRD that were produced, I have some reference
schematics that give me a belief of how the qspi is hooked up
there. From this, I'm fairly certain that all of the older variants
of IDP/CRD either have a pulldown on the CLK/MOSI/MISO lines (maybe
through a direct connect to Cr50) or have no pull (in other words,
they don't have a pullup). I'll go ahead and enable internal
pulldowns on all the lines since that won't hurt to double-pull if
there's an external pulldown and it's nice to have a pulldown if
there's nothing external. Note that this only affects _older_
CRDs. Newer revs are considered "herobrine" (see the hoglin/zoglin
device trees).

4. I didn't find the same strange "auto-switch-to-keeper" at suspend
when probing on sc7280. Whatever pulls (or lack thereof) I left at
suspend time seemed to persist into suspend.

Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230323102605.13.Ib44c3e417c414a4227db8def75ded37ad368212c@changeid

arm64: dts: qcom: sc7280: Add Google Herobrine WIFI SKU dts fragment

The Google Herobrine WIFI SKU can save 256M by not having modem/mba/rmtfs
memory regions defined. Add the dts fragment and mark all the board files
appropriately.

Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221110070813.1777-2-quic_sibis@quicinc.com

arm64: dts: qcom: Add LTE SKUs for sc7280-villager family

This adds LTE skus for villager device tree files.

Signed-off-by: Jimmy Chen <jinghung.chen3@hotmail.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/SG2PR03MB5006B0C3E57803E3B1E0EDBCCC949@SG2PR03MB5006.apcprd03.prod.outlook.com

arm64: dts: qcom: sc7280: Add proxy interconnect requirements for modem

Add interconnects that are required to be proxy voted upon during modem
bootup on SC7280 SoCs.

Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/1652978825-5304-2-git-send-email-quic_sibis@quicinc.com

arm64: dts: qcom: sc7280: Set modem FW path for Chrome OS boards

Specify the path of the modem FW for SC7280 Chrome OS boards in
the 'remoteproc_mpss' node.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220510104656.1.Id98b473e08c950f9a461826dde187ef7705a928c@changeid

arm64: dts: qcom: sc7280: Enable wifi for Chrome OS boards

Enable the 'wifi' and 'remoteproc_wpss' nodes for all sc7280
based Chrome OS boards. Delete the corresponding entries from
sc7280-idp.dtsi since this file includes sc7280-chrome-common.dtsi.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220518155252.1.I176d4254c79cfaafa38cbe36f066f02f819df9b6@changeid

arm64: dts: qcom: sc7280: Factor out Chrome common fragment

This factors out a device tree fragment from some sc7280 device
trees. It represents the device tree bits that should be included for
"Chrome" based sc7280 boards. On these boards the bootloader (Coreboot
+ Depthcharge) configures things slightly different than the
bootloader that Qualcomm provides. The modem firmware on these boards
also works differently than on other Qulacomm products and thus the
reserved memory map needs to be adjusted.

NOTES:
- This is _not_ quite a no-op change. The "herobrine" and "idp"
fragments here were different and it looks like someone simply
forgot to update the herobrine version. This updates a few numbers
to match IDP. This will also cause the `pmk8350_pon` to be disabled
on idp/crd, which I belive is a correct change.
- At the moment this assumes LTE skus. Once it's clearer how WiFi SKUs
will work (how much of the memory map they can reclaim) we may add
an extra fragment that will rejigger one way or the other.

Signed-off-by: Douglas Anderson <dianders@chromium.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/20220125144316.v2.3.Iac012fa8d727be46448d47027a1813ea716423ce@changeid