On Mon, 8 Jan 2024 at 16:23, Luca Weiss <[email protected]> wrote: > > 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.
I'd say, adding the proper interconnect is a better option. Otherwise we just depend on the QCE itself to set up the vote for us. > > 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/[email protected]/ > [1] > https://lore.kernel.org/linux-arm-msm/[email protected]/ > > 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@1dc4000 { > 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@1dfa000 { > 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); Probably this needs some more sensible value. > + if (ret) > + return ret; > + > ret = bam_init(bdev); > if (ret) > goto err_disable_clk; > -- With best wishes Dmitry
