WoA devices using x1e/x1p use android firmware to boot, which notably
includes Gunyah hypervisor. This means that, so far, Linux-based OS
could only boot in EL1 on those devices.
However Windows can replace Gunyah upon boot with it's own hypervisor,
and with the use of tools such as "slbounce", it's possible to do the
same for Linux-based OS, in which case some modifications to the DT are
necessary to facilitate the absence of Gunyah services.
Add a EL2-specific DT overlay and apply it to x1e/x1p WoA devices to
create -el2.dtb for each of them alongside "normal" dtb.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-5-24e9b4572e15@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
x1e80100 has an SMMUv3 connected to PCIe which is normally controlled by
Gunyah and is thus transparent to the OS. However if we boot Linux in
EL2, without Gunyah, we need to manage this IOMMU ourselves. To make
that easier, and since the hardware actually exists, just not "usually"
managed by Linux, describe it in the dts as "reserved".
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-4-24e9b4572e15@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
WoA devices using sc8280xp use android firmware to boot, which notably
includes QHEE hypervisor. This means that, so far, Linux-based OS could
only boot in EL1 on those devices.
However Windows can replace QHEE upon boot with it's own hypervisor, and
with the use of tools such as "slbounce", it's possible to do the same
for Linux-based OS, in which case some modifications to the DT are
necessary to facilitate the absence of QHEE services.
Add a EL2-specific DT overlay and apply it to sc8280xp WoA devices to
create -el2.dtb for each of them alongside "normal" dtb.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-3-24e9b4572e15@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
sc8280xp has an SMMUv3 connected to PCIe which is normally controlled by
QHEE and is thus transparent to the OS. However if we boot Linux in EL2,
without QHEE, we need to manage this IOMMU ourselves. To make that
easier, and since the hardware actually exists, just not "usually"
managed by Linux, describe it in the dts as "reserved".
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-2-24e9b4572e15@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
WoA devices using sc7180 use android firmware to boot, which notably
includes QHEE hypervisor. This means that, so far, Linux-based OS could
only boot in EL1 on those devices.
However Windows can replace QHEE upon boot with it's own hypervisor, and
with the use of tools such as "slbounce", it's possible to do the same
for Linux-based OS, in which case some modifications to the DT are
necessary to facilitate the absence of QHEE services.
Add a EL2-specific DT overlay and apply it to sc7180 WoA devices to
create -el2.dtb for each of them alongside "normal" dtb.
Signed-off-by: Nikita Travkin <nikita@trvn.ru>
Link: https://lore.kernel.org/r/20250503-sc-el2-overlays-v2-1-24e9b4572e15@trvn.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Since commit b5af64fceb ("soc: qcom: smem: Support reserved-memory
description") the SMEM device can be instantiated directly from a
reserved-memory node.
The 'smem' node is defined in this way for each modern IPQ SoCs except for
IPQ6018. In order to make it inline with the others, move the 'compatible'
and the 'hwlock' properties into the respective reserved-memory node, and
drop the standalone 'smem' node.
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250506-ipq6018-drop-smem-v1-1-af99d177be2f@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.
This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.
Signed-off-by: Pratham Pratap <quic_ppratap@quicinc.com>
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250325123019.597976-6-prashanth.k@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.
This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.
Signed-off-by: Pratham Pratap <quic_ppratap@quicinc.com>
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250325123019.597976-5-prashanth.k@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.
This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250325123019.597976-4-prashanth.k@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.
This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250325123019.597976-3-prashanth.k@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
During device mode initialization on certain QC targets, before the
runstop bit is set, sometimes it's observed that the GEVNTADR{LO/HI}
register write fails. As a result, GEVTADDR registers are still 0x0.
Upon setting runstop bit, DWC3 controller attempts to write the new
events to address 0x0, causing an SMMU fault and system crash.
This was initially observed on SM8450 and later reported on few
other targets as well. As suggested by Qualcomm HW team, clearing
the GUSB3PIPECTL.SUSPHY bit resolves the issue by preventing register
write failures. Address this by setting the snps,dis_u3_susphy_quirk
to keep the GUSB3PIPECTL.SUSPHY bit cleared. This change was tested
on multiple targets (SM8350, SM8450 QCS615 etc.) for over an year
and hasn't exhibited any side effects.
Signed-off-by: Prashanth K <prashanth.k@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250325123019.597976-2-prashanth.k@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Changes queued for v6.15 would have had the potential to break
bisectability and was therefor not accepted. Merge the whole set towards
v6.16, as this is no longer a concern.
