[7/7] arm64: dts: qcom: sdm845: enable dma for spi

Add dmas property for spi@880000 and pinconf setting so that we can use
dma for this spi device. Also, add iommu properties for qup and spi.

Signed-off-by: Vinod Koul <vkoul@kernel.org>

---
 arch/arm64/boot/dts/qcom/sdm845-db845c.dts |  4 ++++
 arch/arm64/boot/dts/qcom/sdm845.dtsi       | 11 +++++++++++
 2 files changed, 15 insertions(+)

-- 
2.26.2

Hi,

looks like sdm845-cheza also uses the spi0 bus, which as far as I understand is going to break with the GPI DMA disabled. Perhaps it should also be enabled over there?

Actually, is there a point in disabling DMA for BLSPs/QUPs in the SoC DTSI? I don't think any platform/vendor firmware disables entire hosts..


Konrad

Hi,

On Mon, Jan 11, 2021 at 7:18 AM Vinod Koul <vkoul@kernel.org> wrote:
>
> @@ -2622,6 +2626,13 @@ pinmux {
>                                                "gpio2", "gpio3";
>                                         function = "qup0";
>                                 };
> +
> +                               config {

Convention in Qualcomm device tree files seems to be that the node is
"pinconf", not "config".


> +                                       pins = "gpio0", "gpio1",
> +                                              "gpio2", "gpio3";
> +                                       drive-strength = <6>;
> +                                       bias-disable;
> +                               };

Pin config almost never belongs in the SoC dtsi file.  This should be
in the board .dts file.  What if pulls are needed on some pins?  What
if you need a stronger or weaker drive strength?

-Doug

Hi Konrad,

On 11-01-21, 17:04, Konrad Dybcio wrote:
> Hi,
> 
> looks like sdm845-cheza also uses the spi0 bus, which as far as I
> understand is going to break with the GPI DMA disabled. Perhaps it
> should also be enabled over there?

If it is working without GPI enabled, it would work.. GPI for QUP is
something that requires firmware and would have to be enabled by
firmware

> Actually, is there a point in disabling DMA for BLSPs/QUPs in the SoC
> DTSI? I don't think any platform/vendor firmware disables entire
> hosts..

Since DMA support may not be available on certain targets (firmware
support), so enabling per board would make sense

Thanks

On 11-01-21, 08:47, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jan 11, 2021 at 7:18 AM Vinod Koul <vkoul@kernel.org> wrote:
> >
> > @@ -2622,6 +2626,13 @@ pinmux {
> >                                                "gpio2", "gpio3";
> >                                         function = "qup0";
> >                                 };
> > +
> > +                               config {
> 
> Convention in Qualcomm device tree files seems to be that the node is
> "pinconf", not "config".

Yes missed that, thanks for pointing
> 
> 
> > +                                       pins = "gpio0", "gpio1",
> > +                                              "gpio2", "gpio3";
> > +                                       drive-strength = <6>;
> > +                                       bias-disable;
> > +                               };
> 
> Pin config almost never belongs in the SoC dtsi file.  This should be
> in the board .dts file.  What if pulls are needed on some pins?  What
> if you need a stronger or weaker drive strength?

Right I will move it to dtsi

> If it is working without GPI enabled, it would work.. GPI for QUP is
> something that requires firmware and would have to be enabled by
> firmware


I think with the new code of yours:


mas->tx = dma_request_slave_channel(mas->dev, "tx");
+ if (IS_ERR_OR_NULL(mas->tx)) {
+ dev_err(mas->dev, "Failed to get tx DMA ch %ld", PTR_ERR(mas->tx)); ret = PTR_ERR(mas->tx); + goto out_pm;


it *may* fail to probe with the channels assigned in the "dmas=" property but with the engine having "status=disabled", but as I don't have any hardware to test that driver on, please confirm whether my concerns are right..


> Since DMA support may not be available on certain targets (firmware
> support), so enabling per board would make sense

Oh really, are there SDM845 boards shipping with GPI DMA *disabled to all peripherals*?


Konrad

On 11-01-21, 21:45, Konrad Dybcio wrote:
> 
> > If it is working without GPI enabled, it would work.. GPI for QUP is
> > something that requires firmware and would have to be enabled by
> > firmware
> 
> 
> I think with the new code of yours:
> 
> 
> mas->tx = dma_request_slave_channel(mas->dev, "tx");
> + if (IS_ERR_OR_NULL(mas->tx)) {
> + dev_err(mas->dev, "Failed to get tx DMA ch %ld", PTR_ERR(mas->tx)); ret = PTR_ERR(mas->tx); + goto out_pm;

This code would be exercised *only* when DMA mode is enabled in
firmware.. Both SPI and I2C driver would probe the mode supported
(reason for exposing stuff in first two patches of this series)..

Only if the device reports we should enable it.. Also if the device is
working with FIFO mode then DMA mode wont work..

> 
> it *may* fail to probe with the channels assigned in the "dmas="
> property but with the engine having "status=disabled", but as I don't
> have any hardware to test that driver on, please confirm whether my
> concerns are right..
> 
> 
> > Since DMA support may not be available on certain targets (firmware
> > support), so enabling per board would make sense
> 
> Oh really, are there SDM845 boards shipping with GPI DMA *disabled to
> all peripherals*?

Is the peripheral working with FIFO mode, then answer is yes :)

Thanks