Am Montag, 11. August 2014, 19:37:29 schrieb Andreas Färber:
> Am 11.08.2014 19:01, schrieb Heiko Stübner:
> > Also for an upcoming v2, I've also changed the structure a bit, as the
> > first dma-controller has both a secure and non-secure version of it.
> > 
> > So currently the rk3288.dtsi looks like [0]:
> >     amba {
> >     
> >             compatible = "arm,amba-bus";
> >             #address-cells = <1>;
> >             #size-cells = <1>;
> >             ranges;
> >             
> >             /* dma1 in secure state */
> >             dma-controller@ffb20000 {
> >             
> >                     compatible = "arm,pl330", "arm,primecell";
> >                     reg = <0xffb20000 0x4000>;
> >                     interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> >                     
> >                                  <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> >                     
> >                     #dma-cells = <1>;
> >                     clocks = <&cru ACLK_DMAC1>;
> >                     clock-names = "apb_pclk";
> >                     status = "disabled";
> >             
> >             };
> >             
> >             /* dma1 in non-secure state */
> >             dma-controller@ffb60000 {
> >             
> >                     compatible = "arm,pl330", "arm,primecell";
> >                     reg = <0xffb60000 0x4000>;
> >                     interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
> >                     
> >                                  <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> >                     
> >                     #dma-cells = <1>;
> >                     clocks = <&cru ACLK_DMAC1>;
> >                     clock-names = "apb_pclk";
> >                     status = "disabled";
> >             
> >             };
> >             
> >             dmac2: dma-controller@ff250000 {
> >             
> >                     compatible = "arm,pl330", "arm,primecell";
> >                     reg = <0xff250000 0x4000>;
> >                     interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>,
> >                     
> >                                  <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
> >                     
> >                     #dma-cells = <1>;
> >                     clocks = <&cru ACLK_DMAC2>;
> >                     clock-names = "apb_pclk";
> >             
> >             };
> >     
> >     };
> > 
> > and the board is responsible for enabling the correct variant [1], as most
> > 
> > likely the bootloader decides in which mode to start the dma controller:
> >     amba {
> >     
> >             /* dma1 in secure state */
> >             dmac1: dma-controller@ffb20000 {
> >             
> >                     status = "okay";
> >             
> >             };
> >     
> >     };
> > 
> > This is based on some mailinglist discussion, I found at some point, about
> > this but for the life of me am not able to find anymore. So of course
> > feedback would appreciated there too.
> 
> I would suggest to give labels such as dmac1_s and dmac1_ns like you did
> for dmac2 in the former snippet, so that you can override the status in
> the latter without replicating the amba/dma-controller hierarchy.

I was hoping to just keep it to one handle, so that dma consumers would just 
work and not have to care which dma controller variant was available :-) .


> However, for the Zynq SoC we chose to just model the secure DMAC though
> [*]. I was told that either the bootloader or the user should change the
> DT when running in such a non-secure scenario.

ok, this sounds interesting too, as I haven't seen a board that used the dmac 
in question in non-secure mode, yet.

So I guess one way to handle it could be to declare the non-secure dma, but 
set it to a disabled state and use the secure one as default for everything:

                dmac_bus_s: dma-controller@ffb20000 {
                        compatible = "arm,pl330", "arm,primecell";
                        reg = <0xffb20000 0x4000>;
                        interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
                                     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
                        #dma-cells = <1>;
                        clocks = <&cru ACLK_DMAC1>;
                        clock-names = "apb_pclk";
                };

                dmac_bus_ns: dma-controller@ffb60000 {
                        compatible = "arm,pl330", "arm,primecell";
                        reg = <0xffb60000 0x4000>;
                        interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>,
                                     <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
                        #dma-cells = <1>;
                        clocks = <&cru ACLK_DMAC1>;
                        clock-names = "apb_pclk";
                        status = "disabled";
                };

and a board wanting to use the non-secure variant would then be required to 
override the status and the dma channels in question (this dmac does mainly 
i2s and spdif):

&dmac_bus_s {
        status = "disabled";
}:

&dmac_bus_ns {
        status = "okay";
};

&i2s0 {
        dmas = <&dmac_bus_ns 6>, <&dmac_bus_ns 7>;
};


> [*] https://patchwork.kernel.org/patch/4620251/
> 
> > [0]
> > https://github.com/mmind/linux-rockchip/blob/devel/workbench/arch/arm/boo
> > t/dts/rk3288.dtsi [1]
> > https://github.com/mmind/linux-rockchip/blob/devel/workbench/arch/arm/boo
> > t/dts/rk3288-evb.dtsi
> [snip]

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to