From: heiko@sntech.de (Heiko Stübner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/4] ARM: dts: rockchip: add rk3288 dma controllers
Date: Mon, 11 Aug 2014 21:15:14 +0200 [thread overview]
Message-ID: <1897828.6acYlvjf7S@diego> (raw)
In-Reply-To: <53E90D69.6000307@suse.de>
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 at 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 at 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 at 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 at 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 at 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 at 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]
WARNING: multiple messages have this Message-ID (diff)
From: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: "Andreas Färber" <afaerber-l3A5Bk7waGM@public.gmane.org>
Cc: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Mike Turquette
<mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Kever Yang <kever.yang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
arm-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Eddie Cai <cf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH 3/4] ARM: dts: rockchip: add rk3288 dma controllers
Date: Mon, 11 Aug 2014 21:15:14 +0200 [thread overview]
Message-ID: <1897828.6acYlvjf7S@diego> (raw)
In-Reply-To: <53E90D69.6000307-l3A5Bk7waGM@public.gmane.org>
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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-08-11 19:15 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-29 19:12 [PATCH 0/4] ARM: rockchip: add dma support Heiko Stuebner
2014-07-29 19:12 ` Heiko Stuebner
2014-07-29 19:12 ` [PATCH 1/4] clk: rockchip: protect critical clocks from getting disabled Heiko Stuebner
2014-07-29 19:12 ` Heiko Stuebner
2014-07-31 22:45 ` Mike Turquette
2014-07-31 22:45 ` Mike Turquette
2014-07-31 23:29 ` Heiko Stübner
2014-07-31 23:29 ` Heiko Stübner
2014-08-01 0:30 ` Mike Turquette
2014-08-01 0:30 ` Mike Turquette
2014-08-01 8:15 ` Heiko Stübner
2014-08-01 8:15 ` Heiko Stübner
2014-08-08 21:58 ` Doug Anderson
2014-08-08 21:58 ` Doug Anderson
2014-08-08 22:20 ` Heiko Stübner
2014-08-08 22:20 ` Heiko Stübner
2014-08-11 10:03 ` Kever Yang
2014-08-11 10:03 ` Kever Yang
2014-08-11 10:22 ` Heiko Stübner
2014-08-11 10:22 ` Heiko Stübner
2014-08-12 0:59 ` Kever Yang
2014-08-12 0:59 ` Kever Yang
2014-07-29 19:12 ` [PATCH 2/4] ARM: rockchip: enable the AMBA bus Heiko Stuebner
2014-07-29 19:12 ` Heiko Stuebner
2014-08-11 3:35 ` Kever Yang
2014-08-11 3:35 ` Kever Yang
2014-08-11 7:50 ` Heiko Stübner
2014-08-11 7:50 ` Heiko Stübner
2014-08-11 16:19 ` Doug Anderson
2014-08-11 16:19 ` Doug Anderson
2014-08-12 1:00 ` Kever Yang
2014-08-12 1:00 ` Kever Yang
2014-07-29 19:12 ` [PATCH 3/4] ARM: dts: rockchip: add rk3288 dma controllers Heiko Stuebner
2014-07-29 19:12 ` Heiko Stuebner
2014-08-11 17:01 ` Doug Anderson
2014-08-11 17:01 ` Doug Anderson
2014-08-11 18:01 ` Heiko Stübner
2014-08-11 18:01 ` Heiko Stübner
2014-08-11 18:37 ` Andreas Färber
2014-08-11 18:37 ` Andreas Färber
2014-08-11 19:15 ` Heiko Stübner [this message]
2014-08-11 19:15 ` Heiko Stübner
2014-08-12 1:01 ` Kever Yang
2014-08-12 1:01 ` Kever Yang
2014-07-29 19:12 ` [PATCH 4/4] ARM: dts: rockchip: add rk3188 " Heiko Stuebner
2014-07-29 19:12 ` Heiko Stuebner
2014-07-29 19:55 ` Sergei Shtylyov
2014-07-29 19:55 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1897828.6acYlvjf7S@diego \
--to=heiko@sntech.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.