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>
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>
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 7bd6680b47 ("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: 7bd6680b47 ("Revert "Revert "arm64: dma: Drop cache invalidation from arch_dma_prep_coherent()""")
Fixes: 7a1f4e7f74 ("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>
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
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
