Re: [PATCH v1 5/5] arm64: dts: qcom: sdm660: Add initial Inforce IFC6560 board support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/05/2022 19:17, Konrad Dybcio wrote:

On 04/05/2022 00:09, Dmitry Baryshkov wrote:
The IFC6560 is a board from Inforce Computing, built around the SDA660
SoC. This patch describes core clocks, some regulators from the two
PMICs, debug uart, storage, bluetooth and audio DSP remoteproc.

The regulator settings are inherited from prior work by Konrad Dybcio
and AngeloGioacchino Del Regno.

Co-developed-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx>
---
  arch/arm64/boot/dts/qcom/Makefile             |   1 +
  .../boot/dts/qcom/sda660-inforce-ifc6560.dts  | 455 ++++++++++++++++++
  2 files changed, 456 insertions(+)
  create mode 100644 arch/arm64/boot/dts/qcom/sda660-inforce-ifc6560.dts

diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f9e6343acd03..5f717fe0e8d0 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -88,6 +88,7 @@ dtb-$(CONFIG_ARCH_QCOM)    +=

[skipped]

+
+/* BAM DMA doesn't seem to work on the board */
I wonder if these are configured differently on your firmware.. what if you remove the `qcom,controlled-remotely` property, or in case that doesn't work, swap out the BAM clock for a fake one, like xo_board?

You know, replacing BAM clock with xo_board makes the devices probe and work. So does adding interconnects property (together with Bhupeshe's patches which didn't land for some reason). I think I will override just the clocks for now and update the core dtsi once the [1] gets merged.

[1] https://lore.kernel.org/linux-arm-msm/20211110105922.217895-14-bhupesh.sharma@xxxxxxxxxx/

+&blsp1_dma {
+    status = "disabled";
+};

This reference should come before blsp1_i2c6 alphabetically



[skipped]


+
+&mdp {
+    status = "okay";
+};

MDP should be always enabled in SoC DTSI instead, as MDSS is borderline useless without it..

I see your point. sdm845 doesn't disable it, but later platforms (sc7180/sc7280/sm8250) disable mdp and require enabling it explicitly in the board files. I'd tend to follow the example of the later platforms. Not to mention that sdm630.dtsi already contains 'status="disabled"' for this device.

+
+&mdss {
+    status = "okay";
+};
+
+&mmss_smmu {
+    status = "okay";
+};

..and same goes for all the SMMUs (but that's a nit for the future, as I mentioned in one of the previous emails)

Yes.

[skipped]


--
With best wishes
Dmitry



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux