Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1739359 > unrolled thread
| Started by | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| First post | 2017-09-26 01:30 +0200 |
| Last post | 2017-09-28 14:30 +0200 |
| Articles | 17 — 5 participants |
Back to article view | Back to linux.kernel
[PATCH v1 0/5] NVIDIA Tegra AHB DMA controller driver Dmitry Osipenko <digetx@gmail.com> - 2017-09-26 01:30 +0200
[PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-26 01:30 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Jon Hunter <jonathanh@nvidia.com> - 2017-09-26 17:00 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-26 17:20 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-27 04:00 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Jon Hunter <jonathanh@nvidia.com> - 2017-09-27 10:40 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-27 14:20 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Jon Hunter <jonathanh@nvidia.com> - 2017-09-27 15:50 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Jon Hunter <jonathanh@nvidia.com> - 2017-09-27 15:50 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-27 16:30 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Stephen Boyd <sboyd@codeaurora.org> - 2017-09-28 01:40 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Jon Hunter <jonathanh@nvidia.com> - 2017-09-28 10:40 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Stephen Warren <swarren@wwwdotorg.org> - 2017-09-29 21:40 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Dmitry Osipenko <digetx@gmail.com> - 2017-09-30 05:20 +0200
Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller Stephen Warren <swarren@wwwdotorg.org> - 2017-10-02 22:50 +0200
Re: [PATCH v1 0/5] NVIDIA Tegra AHB DMA controller driver Vinod Koul <vinod.koul@intel.com> - 2017-09-28 11:30 +0200
Re: [PATCH v1 0/5] NVIDIA Tegra AHB DMA controller driver Dmitry Osipenko <digetx@gmail.com> - 2017-09-28 14:30 +0200
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-26 01:30 +0200 |
| Subject | [PATCH v1 0/5] NVIDIA Tegra AHB DMA controller driver |
| Message-ID | <utKZ3-4P8-5@gated-at.bofh.it> |
NVIDIA Tegra20/30 SoC's have AHB DMA controller. It has 4 DMA channels, supports AHB <-> Memory and Memory <-> Memory transfers, slave / master modes. This driver is primarily supposed to be used by gpu/host1x in a master mode, performing 3D HW context stores. Dmitry Osipenko (5): clk: tegra: Add AHB DMA clock entry clk: tegra: Bump SCLK clock rate to 216MHz on Tegra20 dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller dmaengine: Add driver for NVIDIA Tegra AHB DMA controller ARM: dts: tegra: Add AHB DMA controller nodes .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 + arch/arm/boot/dts/tegra20.dtsi | 9 + arch/arm/boot/dts/tegra30.dtsi | 9 + drivers/clk/tegra/clk-id.h | 1 + drivers/clk/tegra/clk-tegra-periph.c | 1 + drivers/clk/tegra/clk-tegra20.c | 8 +- drivers/clk/tegra/clk-tegra30.c | 2 + drivers/dma/Kconfig | 9 + drivers/dma/Makefile | 1 + drivers/dma/tegra20-ahb-dma.c | 679 +++++++++++++++++++++ 10 files changed, 741 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt create mode 100644 drivers/dma/tegra20-ahb-dma.c -- 2.14.1
[toc] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-26 01:30 +0200 |
| Subject | [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <utKZ4-4P8-31@gated-at.bofh.it> |
| In reply to | #1739359 |
Document DT bindings for NVIDIA Tegra AHB DMA controller that presents
on Tegra20/30 SoC's.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
---
.../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
new file mode 100644
index 000000000000..2af9aa76ae11
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt
@@ -0,0 +1,23 @@
+* NVIDIA Tegra AHB DMA controller
+
+Required properties:
+- compatible: Must be "nvidia,tegra20-ahbdma"
+- reg: Should contain registers base address and length.
+- interrupts: Should contain one entry, DMA controller interrupt.
+- clocks: Should contain one entry, DMA controller clock.
+- resets : Should contain one entry, DMA controller reset.
+- #dma-cells: Should be <1>. The cell represents DMA request select value
+ for the peripheral. For more details consult the Tegra TRM's
+ documentation, in particular AHB DMA channel control register
+ REQ_SEL field.
+
+Example:
+
+ahbdma: ahbdma@60008000 {
+ compatible = "nvidia,tegra20-ahbdma";
+ reg = <0x60008000 0x2000>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&tegra_car TEGRA20_CLK_AHBDMA>;
+ resets = <&tegra_car 33>;
+ #dma-cells = <1>;
+};
--
2.14.1
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2017-09-26 17:00 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <utZv3-66l-11@gated-at.bofh.it> |
| In reply to | #1739360 |
On 26/09/17 00:22, Dmitry Osipenko wrote: > Document DT bindings for NVIDIA Tegra AHB DMA controller that presents > on Tegra20/30 SoC's. > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > --- > .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ > 1 file changed, 23 insertions(+) > create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt > > diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt > new file mode 100644 > index 000000000000..2af9aa76ae11 > --- /dev/null > +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt > @@ -0,0 +1,23 @@ > +* NVIDIA Tegra AHB DMA controller > + > +Required properties: > +- compatible: Must be "nvidia,tegra20-ahbdma" > +- reg: Should contain registers base address and length. > +- interrupts: Should contain one entry, DMA controller interrupt. > +- clocks: Should contain one entry, DMA controller clock. > +- resets : Should contain one entry, DMA controller reset. > +- #dma-cells: Should be <1>. The cell represents DMA request select value > + for the peripheral. For more details consult the Tegra TRM's > + documentation, in particular AHB DMA channel control register > + REQ_SEL field. What about the TRIG_SEL field? Do we need to handle this here as well? Cheers Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-26 17:20 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <utZOq-6tc-1@gated-at.bofh.it> |
| In reply to | #1739953 |
On 26.09.2017 17:50, Jon Hunter wrote: > > On 26/09/17 00:22, Dmitry Osipenko wrote: >> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >> on Tegra20/30 SoC's. >> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >> --- >> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> >> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> new file mode 100644 >> index 000000000000..2af9aa76ae11 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> @@ -0,0 +1,23 @@ >> +* NVIDIA Tegra AHB DMA controller >> + >> +Required properties: >> +- compatible: Must be "nvidia,tegra20-ahbdma" >> +- reg: Should contain registers base address and length. >> +- interrupts: Should contain one entry, DMA controller interrupt. >> +- clocks: Should contain one entry, DMA controller clock. >> +- resets : Should contain one entry, DMA controller reset. >> +- #dma-cells: Should be <1>. The cell represents DMA request select value >> + for the peripheral. For more details consult the Tegra TRM's >> + documentation, in particular AHB DMA channel control register >> + REQ_SEL field. > > What about the TRIG_SEL field? Do we need to handle this here as well? > I've followed APB DMA here, that HW also has TRIG_SEL but ignores it for some reason. I think technically it should be present in the binding, yeah. -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-27 04:00 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uu9NN-4b6-15@gated-at.bofh.it> |
| In reply to | #1739953 |
On 26.09.2017 17:50, Jon Hunter wrote: > > On 26/09/17 00:22, Dmitry Osipenko wrote: >> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >> on Tegra20/30 SoC's. >> >> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >> --- >> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >> 1 file changed, 23 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> >> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> new file mode 100644 >> index 000000000000..2af9aa76ae11 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >> @@ -0,0 +1,23 @@ >> +* NVIDIA Tegra AHB DMA controller >> + >> +Required properties: >> +- compatible: Must be "nvidia,tegra20-ahbdma" >> +- reg: Should contain registers base address and length. >> +- interrupts: Should contain one entry, DMA controller interrupt. >> +- clocks: Should contain one entry, DMA controller clock. >> +- resets : Should contain one entry, DMA controller reset. >> +- #dma-cells: Should be <1>. The cell represents DMA request select value >> + for the peripheral. For more details consult the Tegra TRM's >> + documentation, in particular AHB DMA channel control register >> + REQ_SEL field. > > What about the TRIG_SEL field? Do we need to handle this here as well? > Actually, DMA transfer trigger isn't related a hardware description. It's up to software to decide what trigger to select. So it shouldn't be in the binding. And I think the same applies to requester... any objections? -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2017-09-27 10:40 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uug2S-8no-19@gated-at.bofh.it> |
| In reply to | #1740343 |
On 27/09/17 02:57, Dmitry Osipenko wrote: > On 26.09.2017 17:50, Jon Hunter wrote: >> >> On 26/09/17 00:22, Dmitry Osipenko wrote: >>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>> on Tegra20/30 SoC's. >>> >>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>> --- >>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>> 1 file changed, 23 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>> >>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>> new file mode 100644 >>> index 000000000000..2af9aa76ae11 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>> @@ -0,0 +1,23 @@ >>> +* NVIDIA Tegra AHB DMA controller >>> + >>> +Required properties: >>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>> +- reg: Should contain registers base address and length. >>> +- interrupts: Should contain one entry, DMA controller interrupt. >>> +- clocks: Should contain one entry, DMA controller clock. >>> +- resets : Should contain one entry, DMA controller reset. >>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>> + for the peripheral. For more details consult the Tegra TRM's >>> + documentation, in particular AHB DMA channel control register >>> + REQ_SEL field. >> >> What about the TRIG_SEL field? Do we need to handle this here as well? >> > > Actually, DMA transfer trigger isn't related a hardware description. It's up to > software to decide what trigger to select. So it shouldn't be in the binding. I think it could be, if say a board wanted a GPIO to trigger a transfer. > And I think the same applies to requester... any objections? Well, the REQ_SEL should definitely be in the binding. Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks like we never bothered with it for the APB DMA and so maybe no ones uses this. Cheers Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-27 14:20 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uujtN-2gN-37@gated-at.bofh.it> |
| In reply to | #1740501 |
On 27.09.2017 11:34, Jon Hunter wrote: > > On 27/09/17 02:57, Dmitry Osipenko wrote: >> On 26.09.2017 17:50, Jon Hunter wrote: >>> >>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>> on Tegra20/30 SoC's. >>>> >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>> --- >>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>>> 1 file changed, 23 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> new file mode 100644 >>>> index 000000000000..2af9aa76ae11 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> @@ -0,0 +1,23 @@ >>>> +* NVIDIA Tegra AHB DMA controller >>>> + >>>> +Required properties: >>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>> +- reg: Should contain registers base address and length. >>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>> +- clocks: Should contain one entry, DMA controller clock. >>>> +- resets : Should contain one entry, DMA controller reset. >>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>> + for the peripheral. For more details consult the Tegra TRM's >>>> + documentation, in particular AHB DMA channel control register >>>> + REQ_SEL field. >>> >>> What about the TRIG_SEL field? Do we need to handle this here as well? >>> >> >> Actually, DMA transfer trigger isn't related a hardware description. It's up to >> software to decide what trigger to select. So it shouldn't be in the binding. > > I think it could be, if say a board wanted a GPIO to trigger a transfer. > GPIO isn't a very good example, there is no "GPIO" trigger. To me all triggers are software-defined, so that software could create transfer chains. >> And I think the same applies to requester... any objections? > > Well, the REQ_SEL should definitely be in the binding. > Okay. > Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks > like we never bothered with it for the APB DMA and so maybe no ones uses > this. > -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2017-09-27 15:50 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uukSR-3A0-1@gated-at.bofh.it> |
| In reply to | #1740663 |
On 27/09/17 13:12, Dmitry Osipenko wrote: > On 27.09.2017 11:34, Jon Hunter wrote: >> >> On 27/09/17 02:57, Dmitry Osipenko wrote: >>> On 26.09.2017 17:50, Jon Hunter wrote: >>>> >>>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>>> on Tegra20/30 SoC's. >>>>> >>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>>> --- >>>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>>>> 1 file changed, 23 insertions(+) >>>>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> new file mode 100644 >>>>> index 000000000000..2af9aa76ae11 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> @@ -0,0 +1,23 @@ >>>>> +* NVIDIA Tegra AHB DMA controller >>>>> + >>>>> +Required properties: >>>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>>> +- reg: Should contain registers base address and length. >>>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>>> +- clocks: Should contain one entry, DMA controller clock. >>>>> +- resets : Should contain one entry, DMA controller reset. >>>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>>> + for the peripheral. For more details consult the Tegra TRM's >>>>> + documentation, in particular AHB DMA channel control register >>>>> + REQ_SEL field. >>>> >>>> What about the TRIG_SEL field? Do we need to handle this here as well? >>>> >>> >>> Actually, DMA transfer trigger isn't related a hardware description. It's up to >>> software to decide what trigger to select. So it shouldn't be in the binding. >> >> I think it could be, if say a board wanted a GPIO to trigger a transfer. >> > > GPIO isn't a very good example, there is no "GPIO" trigger. To me all triggers > are software-defined, so that software could create transfer chains. TRM shows the following in the APBDMA_TRIG_REG_0 ... "XRQ_A: XRQ.A (GPIOA) (Hardware initiated DMA request)" Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2017-09-27 15:50 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uukSS-3A0-21@gated-at.bofh.it> |
| In reply to | #1740734 |
On 27/09/17 14:44, Jon Hunter wrote: > > On 27/09/17 13:12, Dmitry Osipenko wrote: >> On 27.09.2017 11:34, Jon Hunter wrote: >>> >>> On 27/09/17 02:57, Dmitry Osipenko wrote: >>>> On 26.09.2017 17:50, Jon Hunter wrote: >>>>> >>>>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>>>> on Tegra20/30 SoC's. >>>>>> >>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>>>> --- >>>>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>>>>> 1 file changed, 23 insertions(+) >>>>>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> new file mode 100644 >>>>>> index 000000000000..2af9aa76ae11 >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> @@ -0,0 +1,23 @@ >>>>>> +* NVIDIA Tegra AHB DMA controller >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>>>> +- reg: Should contain registers base address and length. >>>>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>>>> +- clocks: Should contain one entry, DMA controller clock. >>>>>> +- resets : Should contain one entry, DMA controller reset. >>>>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>>>> + for the peripheral. For more details consult the Tegra TRM's >>>>>> + documentation, in particular AHB DMA channel control register >>>>>> + REQ_SEL field. >>>>> >>>>> What about the TRIG_SEL field? Do we need to handle this here as well? >>>>> >>>> >>>> Actually, DMA transfer trigger isn't related a hardware description. It's up to >>>> software to decide what trigger to select. So it shouldn't be in the binding. >>> >>> I think it could be, if say a board wanted a GPIO to trigger a transfer. >>> >> >> GPIO isn't a very good example, there is no "GPIO" trigger. To me all triggers >> are software-defined, so that software could create transfer chains. > > TRM shows the following in the APBDMA_TRIG_REG_0 ... > > "XRQ_A: XRQ.A (GPIOA) (Hardware initiated DMA request)" Furthermore there are timer and hw-semaphore triggers as well. Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-27 16:30 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uulvz-4kL-11@gated-at.bofh.it> |
| In reply to | #1740740 |
On 27.09.2017 16:46, Jon Hunter wrote: > > On 27/09/17 14:44, Jon Hunter wrote: >> >> On 27/09/17 13:12, Dmitry Osipenko wrote: >>> On 27.09.2017 11:34, Jon Hunter wrote: >>>> >>>> On 27/09/17 02:57, Dmitry Osipenko wrote: >>>>> On 26.09.2017 17:50, Jon Hunter wrote: >>>>>> >>>>>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>>>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>>>>> on Tegra20/30 SoC's. >>>>>>> >>>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>>>>> --- >>>>>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>>>>>> 1 file changed, 23 insertions(+) >>>>>>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>>> >>>>>>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>>> new file mode 100644 >>>>>>> index 000000000000..2af9aa76ae11 >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>>> @@ -0,0 +1,23 @@ >>>>>>> +* NVIDIA Tegra AHB DMA controller >>>>>>> + >>>>>>> +Required properties: >>>>>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>>>>> +- reg: Should contain registers base address and length. >>>>>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>>>>> +- clocks: Should contain one entry, DMA controller clock. >>>>>>> +- resets : Should contain one entry, DMA controller reset. >>>>>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>>>>> + for the peripheral. For more details consult the Tegra TRM's >>>>>>> + documentation, in particular AHB DMA channel control register >>>>>>> + REQ_SEL field. >>>>>> >>>>>> What about the TRIG_SEL field? Do we need to handle this here as well? >>>>>> >>>>> >>>>> Actually, DMA transfer trigger isn't related a hardware description. It's up to >>>>> software to decide what trigger to select. So it shouldn't be in the binding. >>>> >>>> I think it could be, if say a board wanted a GPIO to trigger a transfer. >>>> >>> >>> GPIO isn't a very good example, there is no "GPIO" trigger. To me all triggers >>> are software-defined, so that software could create transfer chains. >> >> TRM shows the following in the APBDMA_TRIG_REG_0 ... >> >> "XRQ_A: XRQ.A (GPIOA) (Hardware initiated DMA request)" > > Furthermore there are timer and hw-semaphore triggers as well. > Aha, I wasn't sure about what XRQ is. AHB DMA doesn't have XRQ.A as a trigger, but XRQ.C/D which I suppose corresponds to GPIO C/D. Timer and hw-semaphore are more questionable, aren't semaphores software-only triggerable? -- Dmitry
[toc] | [prev] | [next] | [standalone]
| From | Stephen Boyd <sboyd@codeaurora.org> |
|---|---|
| Date | 2017-09-28 01:40 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uuu5P-1aK-1@gated-at.bofh.it> |
| In reply to | #1740501 |
On 09/27, Jon Hunter wrote: > > > Well, the REQ_SEL should definitely be in the binding. > > Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks Wrong Stephen? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[toc] | [prev] | [next] | [standalone]
| From | Jon Hunter <jonathanh@nvidia.com> |
|---|---|
| Date | 2017-09-28 10:40 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uuCwr-6Fg-29@gated-at.bofh.it> |
| In reply to | #1741095 |
On 28/09/17 00:32, Stephen Boyd wrote: > On 09/27, Jon Hunter wrote: >> >> >> Well, the REQ_SEL should definitely be in the binding. >> >> Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks > > Wrong Stephen? Indeed! With all the folks in copy, I assumed we had the right one :-) Cheers Jon -- nvpublic
[toc] | [prev] | [next] | [standalone]
| From | Stephen Warren <swarren@wwwdotorg.org> |
|---|---|
| Date | 2017-09-29 21:40 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uv9iF-20d-3@gated-at.bofh.it> |
| In reply to | #1740501 |
On 09/27/2017 02:34 AM, Jon Hunter wrote: > > On 27/09/17 02:57, Dmitry Osipenko wrote: >> On 26.09.2017 17:50, Jon Hunter wrote: >>> >>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>> on Tegra20/30 SoC's. >>>> >>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>> --- >>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 ++++++++++++++++++++++ >>>> 1 file changed, 23 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> new file mode 100644 >>>> index 000000000000..2af9aa76ae11 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>> @@ -0,0 +1,23 @@ >>>> +* NVIDIA Tegra AHB DMA controller >>>> + >>>> +Required properties: >>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>> +- reg: Should contain registers base address and length. >>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>> +- clocks: Should contain one entry, DMA controller clock. >>>> +- resets : Should contain one entry, DMA controller reset. >>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>> + for the peripheral. For more details consult the Tegra TRM's >>>> + documentation, in particular AHB DMA channel control register >>>> + REQ_SEL field. >>> >>> What about the TRIG_SEL field? Do we need to handle this here as well? >>> >> >> Actually, DMA transfer trigger isn't related a hardware description. It's up to >> software to decide what trigger to select. So it shouldn't be in the binding. > > I think it could be, if say a board wanted a GPIO to trigger a transfer. > >> And I think the same applies to requester... any objections? > > Well, the REQ_SEL should definitely be in the binding. > > Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks > like we never bothered with it for the APB DMA and so maybe no ones uses > this. I don't think TRIG_SEL should be in the binding, at least at present. While TRIG_SEL certainly is something used to configure the transfer, I believe the semantics of the current DMA binding only cover DMA transfers that are initiated when SW desires, rather than being a combination of after SW programs the transfer plus some other HW event. So, we always use a default/hard-coded TRIG_SEL value. As such, there's no need for a TRIG_SEL value in DT. There's certainly no known use-case that requires a non-default TRIG_SEL value at present. We could add an extra #dma-cells value later if we find a use for it, and the semantics of that use-case make sense to add it to the DMA specifier, rather than some other separate higher-level property/driver/...
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-30 05:20 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uvgtP-6XF-1@gated-at.bofh.it> |
| In reply to | #1742305 |
On 29.09.2017 22:30, Stephen Warren wrote: > On 09/27/2017 02:34 AM, Jon Hunter wrote: >> >> On 27/09/17 02:57, Dmitry Osipenko wrote: >>> On 26.09.2017 17:50, Jon Hunter wrote: >>>> >>>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>>> on Tegra20/30 SoC's. >>>>> >>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>>> --- >>>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 >>>>> ++++++++++++++++++++++ >>>>> 1 file changed, 23 insertions(+) >>>>> create mode 100644 >>>>> Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> new file mode 100644 >>>>> index 000000000000..2af9aa76ae11 >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>> @@ -0,0 +1,23 @@ >>>>> +* NVIDIA Tegra AHB DMA controller >>>>> + >>>>> +Required properties: >>>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>>> +- reg: Should contain registers base address and length. >>>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>>> +- clocks: Should contain one entry, DMA controller clock. >>>>> +- resets : Should contain one entry, DMA controller reset. >>>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>>> + for the peripheral. For more details consult the Tegra TRM's >>>>> + documentation, in particular AHB DMA channel control register >>>>> + REQ_SEL field. >>>> >>>> What about the TRIG_SEL field? Do we need to handle this here as well? >>>> >>> >>> Actually, DMA transfer trigger isn't related a hardware description. It's up to >>> software to decide what trigger to select. So it shouldn't be in the binding. >> >> I think it could be, if say a board wanted a GPIO to trigger a transfer. >> >>> And I think the same applies to requester... any objections? >> >> Well, the REQ_SEL should definitely be in the binding. >> >> Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks >> like we never bothered with it for the APB DMA and so maybe no ones uses >> this. > > I don't think TRIG_SEL should be in the binding, at least at present. While > TRIG_SEL certainly is something used to configure the transfer, I believe the > semantics of the current DMA binding only cover DMA transfers that are initiated > when SW desires, rather than being a combination of after SW programs the > transfer plus some other HW event. So, we always use a default/hard-coded > TRIG_SEL value. As such, there's no need for a TRIG_SEL value in DT. There's > certainly no known use-case that requires a non-default TRIG_SEL value at > present. We could add an extra #dma-cells value later if we find a use for it, > and the semantics of that use-case make sense to add it to the DMA specifier, > rather than some other separate higher-level property/driver/... Thank you for the comment. If we'd want to extend the binding further with the trigger, how to differentiate trigger from the requester in a case of a single #data-cell? Of course realistically a chance that the further extension would be needed is very-very low, so we may defer the efforts to solve that question and for now make driver aware of the potential #dma-cells extension.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Warren <swarren@wwwdotorg.org> |
|---|---|
| Date | 2017-10-02 22:50 +0200 |
| Subject | Re: [PATCH v1 3/5] dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller |
| Message-ID | <uwfPc-ur-167@gated-at.bofh.it> |
| In reply to | #1742468 |
On 09/29/2017 09:11 PM, Dmitry Osipenko wrote: > On 29.09.2017 22:30, Stephen Warren wrote: >> On 09/27/2017 02:34 AM, Jon Hunter wrote: >>> >>> On 27/09/17 02:57, Dmitry Osipenko wrote: >>>> On 26.09.2017 17:50, Jon Hunter wrote: >>>>> >>>>> On 26/09/17 00:22, Dmitry Osipenko wrote: >>>>>> Document DT bindings for NVIDIA Tegra AHB DMA controller that presents >>>>>> on Tegra20/30 SoC's. >>>>>> >>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> >>>>>> --- >>>>>> .../bindings/dma/nvidia,tegra20-ahbdma.txt | 23 >>>>>> ++++++++++++++++++++++ >>>>>> 1 file changed, 23 insertions(+) >>>>>> create mode 100644 >>>>>> Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> >>>>>> diff --git >>>>>> a/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> new file mode 100644 >>>>>> index 000000000000..2af9aa76ae11 >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra20-ahbdma.txt >>>>>> @@ -0,0 +1,23 @@ >>>>>> +* NVIDIA Tegra AHB DMA controller >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible: Must be "nvidia,tegra20-ahbdma" >>>>>> +- reg: Should contain registers base address and length. >>>>>> +- interrupts: Should contain one entry, DMA controller interrupt. >>>>>> +- clocks: Should contain one entry, DMA controller clock. >>>>>> +- resets : Should contain one entry, DMA controller reset. >>>>>> +- #dma-cells: Should be <1>. The cell represents DMA request select value >>>>>> + for the peripheral. For more details consult the Tegra TRM's >>>>>> + documentation, in particular AHB DMA channel control register >>>>>> + REQ_SEL field. >>>>> >>>>> What about the TRIG_SEL field? Do we need to handle this here as well? >>>>> >>>> >>>> Actually, DMA transfer trigger isn't related a hardware description. It's up to >>>> software to decide what trigger to select. So it shouldn't be in the binding. >>> >>> I think it could be, if say a board wanted a GPIO to trigger a transfer. >>> >>>> And I think the same applies to requester... any objections? >>> >>> Well, the REQ_SEL should definitely be in the binding. >>> >>> Laxman, Stephen, what are your thoughts on the TRIG_SEL field? Looks >>> like we never bothered with it for the APB DMA and so maybe no ones uses >>> this. >> >> I don't think TRIG_SEL should be in the binding, at least at present. While >> TRIG_SEL certainly is something used to configure the transfer, I believe the >> semantics of the current DMA binding only cover DMA transfers that are initiated >> when SW desires, rather than being a combination of after SW programs the >> transfer plus some other HW event. So, we always use a default/hard-coded >> TRIG_SEL value. As such, there's no need for a TRIG_SEL value in DT. There's >> certainly no known use-case that requires a non-default TRIG_SEL value at >> present. We could add an extra #dma-cells value later if we find a use for it, >> and the semantics of that use-case make sense to add it to the DMA specifier, >> rather than some other separate higher-level property/driver/... > > Thank you for the comment. If we'd want to extend the binding further with the > trigger, how to differentiate trigger from the requester in a case of a single > #data-cell? > > Of course realistically a chance that the further extension would be needed is > very-very low, so we may defer the efforts to solve that question and for now > make driver aware of the potential #dma-cells extension. The request selector cell isn't optional, so is always present. If we later add an optional trig_sel cell, we'll either have: #dma-cells=<1>: req_sel or: #dma-cells=<2>: req_sel, trig_sel
[toc] | [prev] | [next] | [standalone]
| From | Vinod Koul <vinod.koul@intel.com> |
|---|---|
| Date | 2017-09-28 11:30 +0200 |
| Message-ID | <uuDiP-7d1-27@gated-at.bofh.it> |
| In reply to | #1739359 |
On Tue, Sep 26, 2017 at 02:22:01AM +0300, Dmitry Osipenko wrote: > NVIDIA Tegra20/30 SoC's have AHB DMA controller. It has 4 DMA channels, > supports AHB <-> Memory and Memory <-> Memory transfers, slave / master > modes. This driver is primarily supposed to be used by gpu/host1x in a > master mode, performing 3D HW context stores. > > Dmitry Osipenko (5): > clk: tegra: Add AHB DMA clock entry > clk: tegra: Bump SCLK clock rate to 216MHz on Tegra20 > dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller > dmaengine: Add driver for NVIDIA Tegra AHB DMA controller > ARM: dts: tegra: Add AHB DMA controller nodes I don't think they are dependent, so consider sending them separately -- ~Vinod
[toc] | [prev] | [next] | [standalone]
| From | Dmitry Osipenko <digetx@gmail.com> |
|---|---|
| Date | 2017-09-28 14:30 +0200 |
| Message-ID | <uuG71-vR-43@gated-at.bofh.it> |
| In reply to | #1741329 |
On 28.09.2017 12:31, Vinod Koul wrote: > On Tue, Sep 26, 2017 at 02:22:01AM +0300, Dmitry Osipenko wrote: >> NVIDIA Tegra20/30 SoC's have AHB DMA controller. It has 4 DMA channels, >> supports AHB <-> Memory and Memory <-> Memory transfers, slave / master >> modes. This driver is primarily supposed to be used by gpu/host1x in a >> master mode, performing 3D HW context stores. >> >> Dmitry Osipenko (5): >> clk: tegra: Add AHB DMA clock entry >> clk: tegra: Bump SCLK clock rate to 216MHz on Tegra20 >> dt-bindings: Add DT bindings for NVIDIA Tegra AHB DMA controller >> dmaengine: Add driver for NVIDIA Tegra AHB DMA controller >> ARM: dts: tegra: Add AHB DMA controller nodes > > I don't think they are dependent, so consider sending them separately > Well, they are dependent in a sense of making driver usable. Only the "SCLK rate bump" patch isn't strictly needed. Splitting this series won't cause building failures, but all pieces should be in place for the working driver. So I suppose it is okay if clk patches would get in earlier than the others, I'll split the series. Thank you for the review. -- Dmitry
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web