[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CY9E4ZCHOMWU.C18NR0H7V1QX@fairphone.com>
Date: Mon, 08 Jan 2024 15:22:38 +0100
From: "Luca Weiss" <luca.weiss@...rphone.com>
To: "Konrad Dybcio" <konrad.dybcio@...aro.org>, "Andy Gross"
<agross@...nel.org>, "Bjorn Andersson" <andersson@...nel.org>, "Rob
Herring" <robh+dt@...nel.org>, "Krzysztof Kozlowski"
<krzysztof.kozlowski+dt@...aro.org>, "Conor Dooley" <conor+dt@...nel.org>,
"Bhupesh Sharma" <bhupesh.linux@...il.com>, "David Heidelberg"
<david@...t.cz>, "Stephan Gerhold" <stephan@...hold.net>
Cc: <~postmarketos/upstreaming@...ts.sr.ht>, <phone-devel@...r.kernel.org>,
"Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
<linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RFT] arm64: dts: qcom: sm8350: Reenable crypto &
cryptobam
On Mon Jan 8, 2024 at 3:18 PM CET, Konrad Dybcio wrote:
> On 8.01.2024 14:49, Luca Weiss wrote:
> > When num-channels and qcom,num-ees is not provided in devicetree, the
> > driver will try to read these values from the registers during probe but
> > this fails if the interconnect is not on and then crashes the system.
> >
> > So we can provide these properties in devicetree (queried after patching
> > BAM driver to enable the necessary interconnect) so we can probe
> > cryptobam without reading registers and then also use the QCE as
> > expected.
>
> This really feels a bit backwards.. Enable the resource to query the
> hardware for numbers, so that said resource can be enabled, but
> slightly later :/
If you think adding interconnect support to driver and dtsi is better,
let me know.
Stephan (+CC) mentioned it should be okay like this *shrug*
For the record, this is the same way I got the values for sc7280[0] and
sm6350[1].
[0] https://lore.kernel.org/linux-arm-msm/20231229-sc7280-cryptobam-fixup-v1-1-bd8f68589b80@fairphone.com/
[1] https://lore.kernel.org/linux-arm-msm/20240105-sm6350-qce-v1-0-416e5c7319ac@fairphone.com/
diff --git a/arch/arm64/boot/dts/qcom/sm8350.dtsi b/arch/arm64/boot/dts/qcom/sm8350.dtsi
index b46236235b7f..cd4dd9852d9e 100644
--- a/arch/arm64/boot/dts/qcom/sm8350.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8350.dtsi
@@ -1756,8 +1756,8 @@ cryptobam: dma-controller@...4000 {
qcom,controlled-remotely;
iommus = <&apps_smmu 0x594 0x0011>,
<&apps_smmu 0x596 0x0011>;
- /* FIXME: Probing BAM DMA causes some abort and system hang */
- status = "fail";
+ interconnects = <&aggre2_noc MASTER_CRYPTO 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "memory";
};
crypto: crypto@...a000 {
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 5e7d332731e0..9de28f615639 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -40,6 +40,7 @@
#include <linux/circ_buf.h>
#include <linux/clk.h>
#include <linux/dmaengine.h>
+#include <linux/interconnect.h>
#include <linux/pm_runtime.h>
#include "../dmaengine.h"
@@ -394,6 +395,7 @@ struct bam_device {
const struct reg_offset_data *layout;
struct clk *bamclk;
+ struct icc_path *mem_path;
int irq;
/* dma start transaction tasklet */
@@ -1206,6 +1208,7 @@ static int bam_init(struct bam_device *bdev)
bdev->num_channels = val & BAM_NUM_PIPES_MASK;
}
+ printk(KERN_ERR "%s:%d DBG num_ees=%u num_channels=%u\n", __func__, __LINE__, bdev->num_ees, bdev->num_channels);
/* Reset BAM now if fully controlled locally */
if (!bdev->controlled_remotely && !bdev->powered_remotely)
bam_reset(bdev);
@@ -1298,6 +1301,14 @@ static int bam_dma_probe(struct platform_device *pdev)
return ret;
}
+ bdev->mem_path = devm_of_icc_get(bdev->dev, "memory");
+ if (IS_ERR(bdev->mem_path))
+ return PTR_ERR(bdev->mem_path);
+
+ ret = icc_set_bw(bdev->mem_path, 1, 1);
+ if (ret)
+ return ret;
+
ret = bam_init(bdev);
if (ret)
goto err_disable_clk;
Powered by blists - more mailing lists