On Tue, Feb 25, 2014 at 06:54:16AM +0000, Chao Fu wrote:
> From: Chao Fu <[email protected]>
>
> Add bool value use-dma.
> The bool will determine whether DSPI use dma channel transfer data
> in a platform.
>
> Add dmas and dma-names for describing dma channels of DSPI.
>
> Signed-off-by: Chao Fu <[email protected]>
> ---
> Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> index 5376de4..76a1039 100644
> --- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
> @@ -11,6 +11,11 @@ Required properties:
> - spi-num-chipselects : the number of the chipselect signals.
> - bus-num : the slave chip chipselect signal number.
> - big-endian : if DSPI modudle is big endian, the bool will be set in node.
> +- use-dma: the bool decide if use dma method in DSPI transfering.
Why can the OS not decide this based on the presence of dmas which it
can use?
Is there ever a case that there would be dmas present but it would be in
the interests of the OS to not use them?
Mark.
> +- dmas: List of DMA specifiers with the controller specific format
> + as described in the generic DMA client binding. A tx and rx
> + specifier is required for each chip select.
> +- dma-names: Should be named "tx" and "rx".
> Example:
>
> dspi0@4002c000 {
> @@ -26,6 +31,10 @@ dspi0@4002c000 {
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_dspi0_1>;
> big-endian;
> + use-dma;
> + dmas = <&edma0 0 12>,
> + <&edma0 0 13>;
> + dma-names = "rx", "tx";
> status = "okay";
>
> sflash: at26df081a@0 {
> --
> 1.8.4
>
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
