[PATCH v2 0/9] Add support for FDMA DMA controller found on STi chipsets

[PATCH v2 0/9] Add support for FDMA DMA controller found on STi chipsets

[Peter Griffin]

Hi Vinod,

This patchset adds support for the Flexible Direct Memory Access (FDMA) core
found on STi chipsets from STMicroelectronics. The FDMA is a slim (xp70) core CPU
with a dedicated firmware. It is a general purpose DMA controller supporting
16 independent channels and data can be moved from memory to memory or between
memory and paced latency critical real time targets.

After some discussion with the DT maintainers I've decided not to include the
firmware name in DT, and generate the name based on the compatible string.
This is in keeping with how most other kernel drivers request firmware, and avoids
a new DT firmware name binding.

I've also dropped the xbar support for the moment, as I believe it should be
re-worked based on some of the xbar API's that TI recently added. As requested
I've also split it into smaller patches to help with faster review.

regards,

Peter.

Changes since v1:
 - split into smaller patches for easier / faster review (Vinod)
 - new fill_hw_mode() with common code (Vinod)
 - new config_reqctrl() called from *_prep() instead of device_config cb (Vinod)
 - fdma-xbar support removed (Peter)
 - rework firmware name mechanism so fwname isn't in DT (Peter / Lee)
 - st_fdma_seg_to_mem can be static (Paul)
 - EXPORT_SYMBOL st_fdma_filter_fn not required (Paul)
 - s/channel/channels (vinod)
 - better describe "Must be <3>" (vinod)
 - sizeof(*ehdr) (vinod)
 - print values on error debug (vinod)
 - empty line (Vinod)
 - Update to -EIO (Vinod)
 - Make st_fdma tristate (Paul)
 - Remove __exit tag from .remove (Maxime)
 - Update MAINTAINERS rule to fdma* (Lee)
 - Unit address should match reg property (Lee)

Peter Griffin (9):
  dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding
    documentation
  dmaengine: st_fdma: Add st fdma platform specific header
  dmaengine: st_fdma:  Add STMicroelectronics FDMA driver header file
  dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support
  dmaengine: st_fdma: Add xp70 firmware loading mechanism.
  dmaengine: st_fdma: Add fdma suspend and resume callbacks.
  ARM: STi: DT: STiH407: Add FDMA driver dt nodes.
  MAINTAINERS: Add FDMA driver files to STi section.
  ARM: multi_v7_defconfig: Enable STi FDMA driver

 Documentation/devicetree/bindings/dma/st_fdma.txt |   78 ++
 MAINTAINERS                                       |    1 +
 arch/arm/boot/dts/stih407-family.dtsi             |   51 +
 arch/arm/configs/multi_v7_defconfig               |    1 +
 drivers/dma/Kconfig                               |   14 +
 drivers/dma/Makefile                              |    1 +
 drivers/dma/st_fdma.c                             | 1204 +++++++++++++++++++++
 drivers/dma/st_fdma.h                             |  237 ++++
 include/linux/platform_data/dma-st_fdma.h         |   72 ++
 9 files changed, 1659 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt
 create mode 100644 drivers/dma/st_fdma.c
 create mode 100644 drivers/dma/st_fdma.h
 create mode 100644 include/linux/platform_data/dma-st_fdma.h

-- 
1.9.1

--
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

[PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

This patch adds the DT binding documentation for the FDMA constroller
found on STi based chipsets from STMicroelectronics.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 Documentation/devicetree/bindings/dma/st_fdma.txt | 78 +++++++++++++++++++++++
 1 file changed, 78 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/st_fdma.txt

diff --git a/Documentation/devicetree/bindings/dma/st_fdma.txt b/Documentation/devicetree/bindings/dma/st_fdma.txt
new file mode 100644
index 0000000..c24b8d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/st_fdma.txt
@@ -0,0 +1,78 @@
+* STMicroelectronics Flexible Direct Memory Access Device Tree bindings
+
+The FDMA is a general-purpose direct memory access controller capable of
+supporting 16 independent DMA channels. It accepts up to 32 DMA requests.
+The FDMA is based on a Slim processor which require a firmware.
+
+* FDMA Controller
+
+Required properties:
+- compatible	: Should be "st,stih407-fdma-mpe31"
+- reg		: Should contain DMA registers location and length
+- interrupts	: Should contain one interrupt shared by all channels
+- dma-channels	: Number of channels supported by the controller
+- #dma-cells	: Must be <3>. See DMA client section below
+- st,fdma-id	: Must contain fdma controller number
+- clocks	: Must contain an entry for each name in clock-names
+- clock-names	: Must contain "fdma_slim, fdma_hi, fdma_low, fdma_ic" entries
+See: Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+
+Example:
+
+	fdma1: fdma-app@8e40000 {
+		compatible = "st,stih407-fdma-mpe31";
+		reg = <0x8e40000 0x20000>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
+		dma-channels = <16>;
+		#dma-cells = <3>;
+		st,fdma-id = <0>;
+		clocks = <&CLK_S_C0_FLEXGEN CLK_FDMA>,
+			 <&CLK_S_C0_FLEXGEN CLK_TX_ICN_DMU>,
+			 <&CLK_S_C0_FLEXGEN CLK_TX_ICN_DMU>,
+			 <&CLK_S_C0_FLEXGEN CLK_EXT2F_A9>;
+		clock-names = "fdma_slim",
+			      "fdma_hi",
+			      "fdma_low",
+			      "fdma_ic";
+		};
+
+* DMA client
+
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+
+Each dmas request consists of 4 cells:
+1. A phandle pointing to the FDMA controller
+2. The request line number
+3. A 32bit mask specifying (see include/linux/platform_data/dma-st-fdma.h)
+ -bit 2-0: Holdoff value, dreq will be masked for
+	0x0: 0-0.5us
+	0x1: 0.5-1us
+	0x2: 1-1.5us
+ -bit 17: data swap
+	0x0: disabled
+	0x1: enabled
+ -bit 21: Increment Address
+	0x0: no address increment between transfers
+	0x1: increment address between transfers
+ -bit 22: 2 STBus Initiator Coprocessor interface
+	0x0: high priority port
+	0x1: low priority port
+4. transfers type
+ 0 free running
+ 1 paced
+
+Example:
+
+	snd_uni_player2: snd-uni-player@2 {
+		compatible = "st,snd_uni_player";
+		status = "okay";
+		reg = <0x8D82000  0x158>;
+		interrupts = <GIC_SPI 86 IRQ_TYPE_NONE>;
+		version = <5>;
+		dmas = <&fdma0 4 0 1>;
+		dma-names = "tx";
+		description = "Uni Player #2 (DAC)";
+	};
-- 
1.9.1

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Arnd Bergmann]

On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> +- st,fdma-id	: Must contain fdma controller number

What for?
> +Example:
> +
> +	fdma1: fdma-app@8e40000 {

The name should be "dma-controller", not "fdma-app".

> +Example:
> +
> +	snd_uni_player2: snd-uni-player@2 {
> +		compatible = "st,snd_uni_player";

Maybe change the compatible string to "st,snd-uni-player"?

The string you use here would not be acceptable for a binding.

	Arnd

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Arnd,

On Fri, 11 Sep 2015, Arnd Bergmann wrote:

> On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> > +- st,fdma-id	: Must contain fdma controller number
> 
> What for?

It is used by the driver to generate a unique firmware name.
Basically we need to know which controller instance we
are as each controller has a different firmware which needs
to be loaded.

Rob did say that having a index type property is undesirable
over here, see my reply at the bottom
http://www.spinics.net/lists/devicetree/msg92529.html.

However I can't think of any other useful properties we could add
to derive this information.

> > +Example:
> > +
> > +	fdma1: fdma-app@8e40000 {
> 
> The name should be "dma-controller", not "fdma-app".

Ok will fix in v3

> 
> > +Example:
> > +
> > +	snd_uni_player2: snd-uni-player@2 {
> > +		compatible = "st,snd_uni_player";
> 
> Maybe change the compatible string to "st,snd-uni-player"?

Just checking the upstream driver which got merged for v4.3
and the compatible has changed to "st,sti-uni-player" so I
can update the DT doc example to use this in v3.

> 
> The string you use here would not be acceptable for a binding.

Presumably it is the use of "underscores" in the compatible which
is not allowed? Is that correct?

regards,

Peter.

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Lee Jones]

On Sat, 12 Sep 2015, Peter Griffin wrote:

> Hi Arnd,
> 
> On Fri, 11 Sep 2015, Arnd Bergmann wrote:
> 
> > On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> > > +- st,fdma-id	: Must contain fdma controller number
> > 
> > What for?
> 
> It is used by the driver to generate a unique firmware name.
> Basically we need to know which controller instance we
> are as each controller has a different firmware which needs
> to be loaded.
> 
> Rob did say that having a index type property is undesirable
> over here, see my reply at the bottom
> http://www.spinics.net/lists/devicetree/msg92529.html.
> 
> However I can't think of any other useful properties we could add
> to derive this information.

I wouldn't use a property at all.  Why not use the compatible string?

Who chooses the naming scheme of the firmware binary?

Is there any reason they can't be:

  fdma_STiH407_audio.elf
  fdma_STiH407_app.elf
  fdma_STiH407_free_running.elf

Then you can have a different compatible for each:

  compatible = "st,stih407-fdma-mpe31-audio";
  compatible = "st,stih407-fdma-mpe31-app";
  compatible = "st,stih407-fdma-mpe31-free-running";

[...]

> > > +Example:
> > > +
> > > +	snd_uni_player2: snd-uni-player@2 {
> > > +		compatible = "st,snd_uni_player";
> > 
> > Maybe change the compatible string to "st,snd-uni-player"?
> 
> Just checking the upstream driver which got merged for v4.3
> and the compatible has changed to "st,sti-uni-player" so I
> can update the DT doc example to use this in v3.
> 
> > 
> > The string you use here would not be acceptable for a binding.
> 
> Presumably it is the use of "underscores" in the compatible which
> is not allowed? Is that correct?

Yes.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Lee,

On Mon, 14 Sep 2015, Lee Jones wrote:

> > On Fri, 11 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Friday 11 September 2015 15:14:23 Peter Griffin wrote:
> > > > +- st,fdma-id	: Must contain fdma controller number
> > > 
> > > What for?
> > 
> > It is used by the driver to generate a unique firmware name.
> > Basically we need to know which controller instance we
> > are as each controller has a different firmware which needs
> > to be loaded.
> > 
> > Rob did say that having a index type property is undesirable
> > over here, see my reply at the bottom
> > http://www.spinics.net/lists/devicetree/msg92529.html.
> > 
> > However I can't think of any other useful properties we could add
> > to derive this information.
> 
> I wouldn't use a property at all.  Why not use the compatible string?
> 
> Who chooses the naming scheme of the firmware binary?

ST

> 
> Is there any reason they can't be:
> 
>   fdma_STiH407_audio.elf
>   fdma_STiH407_app.elf
>   fdma_STiH407_free_running.elf

Not sure, we could easily rename them locally. Getting ST to change
the firmware names in the stlinux distro might be harder.
My personal preference is to leave the firmware names "as is", unless
there is a real show stopper reason where we *have* to change them e.g.
we can't support all STi platforms with the same userspace because
the firmware filenames aren't unique enough.

> 
> Then you can have a different compatible for each:
> 
>   compatible = "st,stih407-fdma-mpe31-audio";
>   compatible = "st,stih407-fdma-mpe31-app";
>   compatible = "st,stih407-fdma-mpe31-free-running";

I think if you took the approach of only using the compatible
you would still need to use the fdma instance number
otherwise you end up with the same problems discussed in the 
"Firmware filename in DT" thread [1] e.g.

   compatible = "st,stih407-fdma-mpe31-0";
   compatible = "st,stih407-fdma-mpe31-1";
   compatible = "st,stih407-fdma-mpe31-2";

Specifically the problem is related to

"The hardware is identical, and different firmware is used to apply
   it in different ways."

Which is the case with fdma. By encoding the "way you wish to apply it" into the
compatible string, it causes problems if you want to change for example fdma0
to do some other function other than audio.

You then require a DT update, (when the hardware hasn't changed, just the
firmware) which is the same problem as using the filename directly in DT.

Therefore I believe it is important that the DT binding does *not* encode the
way the hardware is to be applied into the binding in *any* way, and defers this
 decision to the driver.
That is the rationale / reasoning behind choosing the fdma instance number.

Assuming you agree with my arguments above, then the choice becomes between 
having a fdma instance DT property, or having lots of compatibles where the only
difference is the appending of the instance number. I think out of the two I prefer
my original approach.

Any thoughts from the DT folks?

regards,

Peter.

[1] http://comments.gmane.org/gmane.linux.drivers.devicetree/133782
--
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

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Arnd Bergmann]

On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> 
> "The hardware is identical, and different firmware is used to apply
>    it in different ways."
> 
> Which is the case with fdma. By encoding the "way you wish to apply it" into the
> compatible string, it causes problems if you want to change for example fdma0
> to do some other function other than audio.
> 
> You then require a DT update, (when the hardware hasn't changed, just the
> firmware) which is the same problem as using the filename directly in DT.
> 
> Therefore I believe it is important that the DT binding does *not* encode the
> way the hardware is to be applied into the binding in *any* way, and defers this
>  decision to the driver.
> That is the rationale / reasoning behind choosing the fdma instance number.
> 
> Assuming you agree with my arguments above, then the choice becomes between 
> having a fdma instance DT property, or having lots of compatibles where the only
> difference is the appending of the instance number. I think out of the two I prefer
> my original approach.
> 
> Any thoughts from the DT folks?

To me both approaches sound wrong: basing the firmware name on the instance
number requires that each instance is always used in the same way, which
is not guaranteed to be the case, and you correctly describe the problem with
using the compatible string for the firmware name if the driver for the FDMA
does not actually care what firmware is being used here.

Whatever code makes the decision as to how the FDMA is used should also
decide on the name of the firmware file. You can have a mapping in the
driver that contains the file names that are used by ST's distro, possibly
with a fallback mechanism that tries more meaningful names first.

	Arnd
--
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

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Arnd,

On Tue, 29 Sep 2015, Arnd Bergmann wrote:

> On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> > 
> > "The hardware is identical, and different firmware is used to apply
> >    it in different ways."
> > 
> > Which is the case with fdma. By encoding the "way you wish to apply it" into the
> > compatible string, it causes problems if you want to change for example fdma0
> > to do some other function other than audio.
> > 
> > You then require a DT update, (when the hardware hasn't changed, just the
> > firmware) which is the same problem as using the filename directly in DT.
> > 
> > Therefore I believe it is important that the DT binding does *not* encode the
> > way the hardware is to be applied into the binding in *any* way, and defers this
> >  decision to the driver.
> > That is the rationale / reasoning behind choosing the fdma instance number.
> > 
> > Assuming you agree with my arguments above, then the choice becomes between 
> > having a fdma instance DT property, or having lots of compatibles where the only
> > difference is the appending of the instance number. I think out of the two I prefer
> > my original approach.
> > 
> > Any thoughts from the DT folks?
> 
> To me both approaches sound wrong: basing the firmware name on the instance
> number requires that each instance is always used in the same way, which
> is not guaranteed to be the case,

Does it? I didn't think it did.

Using the instance number as a DT property defers the decision over what firmware to
load to the driver, which can choose whatever firmware name it wishes.

e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain
unchanged, but the use of that fdma instance has changed.

We currently only have one firmware for each instance with the "use" compiled into it.
If in the future we had two firmwares with different "uses" for the same instance some extra
logic would be required in the driver to make a decision on which firmware to load.

> and you correctly describe the problem with
> using the compatible string for the firmware name if the driver for the FDMA
> does not actually care what firmware is being used here.
> 
> Whatever code makes the decision as to how the FDMA is used should also
> decide on the name of the firmware file.

The code which makes this decision currently is the st_fdma.c driver. However it does
need to know which fdma controller it is operating on to make this decision correctly.

Apart from passing the fdma instance number in DT, how else can we determine which
controller we are?

I guess we could infer it by having a table in the driver containing the base addresses
of the controllers for a given SoC, and match that against what DT passes us in the
reg property. But that seems ugly, and is encoding the same information in two
different places.

I'm open to suggestions if there is a better way to do this.

regards,

Peter.
--
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

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Arnd Bergmann]

On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> Hi Arnd,
> 
> On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> 
> > On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> > > 
> > > "The hardware is identical, and different firmware is used to apply
> > >    it in different ways."
> > > 
> > > Which is the case with fdma. By encoding the "way you wish to apply it" into the
> > > compatible string, it causes problems if you want to change for example fdma0
> > > to do some other function other than audio.
> > > 
> > > You then require a DT update, (when the hardware hasn't changed, just the
> > > firmware) which is the same problem as using the filename directly in DT.
> > > 
> > > Therefore I believe it is important that the DT binding does *not* encode the
> > > way the hardware is to be applied into the binding in *any* way, and defers this
> > >  decision to the driver.
> > > That is the rationale / reasoning behind choosing the fdma instance number.
> > > 
> > > Assuming you agree with my arguments above, then the choice becomes between 
> > > having a fdma instance DT property, or having lots of compatibles where the only
> > > difference is the appending of the instance number. I think out of the two I prefer
> > > my original approach.
> > > 
> > > Any thoughts from the DT folks?
> > 
> > To me both approaches sound wrong: basing the firmware name on the instance
> > number requires that each instance is always used in the same way, which
> > is not guaranteed to be the case,
> 
> Does it? I didn't think it did.
> 
> Using the instance number as a DT property defers the decision over what firmware to
> load to the driver, which can choose whatever firmware name it wishes.
> 
> e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain
> unchanged, but the use of that fdma instance has changed.
> 
> We currently only have one firmware for each instance with the "use" compiled into it.
> If in the future we had two firmwares with different "uses" for the same instance some extra
> logic would be required in the driver to make a decision on which firmware to load.

Ok, I probably need some more background about what the firmware on this
device does, and what it could do with a different firmware. Could you
elaborate?

> > and you correctly describe the problem with
> > using the compatible string for the firmware name if the driver for the FDMA
> > does not actually care what firmware is being used here.
> > 
> > Whatever code makes the decision as to how the FDMA is used should also
> > decide on the name of the firmware file.
> 
> The code which makes this decision currently is the st_fdma.c driver. However it does
> need to know which fdma controller it is operating on to make this decision correctly.
> 
> Apart from passing the fdma instance number in DT, how else can we determine which
> controller we are?
> 
> I guess we could infer it by having a table in the driver containing the base addresses
> of the controllers for a given SoC, and match that against what DT passes us in the
> reg property. But that seems ugly, and is encoding the same information in two
> different places.
> 
> I'm open to suggestions if there is a better way to do this.

Using the address would be the same thing, that doesn't change the
fundamental logic. Can you explain why it matters which instance
a firmware is used on for this driver?

	Arnd

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Arnd,

On Tue, 29 Sep 2015, Arnd Bergmann wrote:

> On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> > Hi Arnd,
> > 
> > On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> > 
> > > On Tuesday 29 September 2015 11:04:40 Peter Griffin wrote:
> > > > 
> > > > "The hardware is identical, and different firmware is used to apply
> > > >    it in different ways."
> > > > 
> > > > Which is the case with fdma. By encoding the "way you wish to apply it" into the
> > > > compatible string, it causes problems if you want to change for example fdma0
> > > > to do some other function other than audio.
> > > > 
> > > > You then require a DT update, (when the hardware hasn't changed, just the
> > > > firmware) which is the same problem as using the filename directly in DT.
> > > > 
> > > > Therefore I believe it is important that the DT binding does *not* encode the
> > > > way the hardware is to be applied into the binding in *any* way, and defers this
> > > >  decision to the driver.
> > > > That is the rationale / reasoning behind choosing the fdma instance number.
> > > > 
> > > > Assuming you agree with my arguments above, then the choice becomes between 
> > > > having a fdma instance DT property, or having lots of compatibles where the only
> > > > difference is the appending of the instance number. I think out of the two I prefer
> > > > my original approach.
> > > > 
> > > > Any thoughts from the DT folks?
> > > 
> > > To me both approaches sound wrong: basing the firmware name on the instance
> > > number requires that each instance is always used in the same way, which
> > > is not guaranteed to be the case,
> > 
> > Does it? I didn't think it did.
> > 
> > Using the instance number as a DT property defers the decision over what firmware to
> > load to the driver, which can choose whatever firmware name it wishes.
> > 
> > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain
> > unchanged, but the use of that fdma instance has changed.
> > 
> > We currently only have one firmware for each instance with the "use" compiled into it.
> > If in the future we had two firmwares with different "uses" for the same instance some extra
> > logic would be required in the driver to make a decision on which firmware to load.
> 
> Ok, I probably need some more background about what the firmware on this
> device does, and what it could do with a different firmware. Could you
> elaborate?

So the fdma hw is a dma engine based around a xp70 slim core. It supports: -
* block memory move between 2 system locations
* paced transfer from system memory to paced peripheral
* paced transfer from a paced peripheral to system memory

I believe each firmware for each instance supports those 3 things.

However the xp70 also has some ancilary HW to facilitate Start Code Detection.
It is this feature which I believe would require a different firmware if we wanted to make
use of it. Looking at the functional spec each xp70 also
has 16 gp output signals which we could also control from the firmware. Whether
these are actually connected to anything useful inside the SoC I don't know.

> > > and you correctly describe the problem with
> > > using the compatible string for the firmware name if the driver for the FDMA
> > > does not actually care what firmware is being used here.
> > > 
> > > Whatever code makes the decision as to how the FDMA is used should also
> > > decide on the name of the firmware file.
> > 
> > The code which makes this decision currently is the st_fdma.c driver. However it does
> > need to know which fdma controller it is operating on to make this decision correctly.
> > 
> > Apart from passing the fdma instance number in DT, how else can we determine which
> > controller we are?
> > 
> > I guess we could infer it by having a table in the driver containing the base addresses
> > of the controllers for a given SoC, and match that against what DT passes us in the
> > reg property. But that seems ugly, and is encoding the same information in two
> > different places.
> > 
> > I'm open to suggestions if there is a better way to do this.
> 
> Using the address would be the same thing, that doesn't change the
> fundamental logic. Can you explain why it matters which instance
> a firmware is used on for this driver?

The reason we care, is that each instance has its own firmware file.

I just did a hexdump on the 3 different firmwares and compared them. Although the majority
of the binary is the same, there are various bytes which change at several different offsets
in the firmware file depending on the instance.

I don't have a xp70 toolchain or know enough about the cpu architecture to analyze what exactly
the firmware is doing at these locations.

regards,

Peter.

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Arnd Bergmann]

On Tuesday 29 September 2015 14:42:15 Peter Griffin wrote:
> On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> > On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> > > Does it? I didn't think it did.
> > > 
> > > Using the instance number as a DT property defers the decision over what firmware to
> > > load to the driver, which can choose whatever firmware name it wishes.
> > > 
> > > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain
> > > unchanged, but the use of that fdma instance has changed.
> > > 
> > > We currently only have one firmware for each instance with the "use" compiled into it.
> > > If in the future we had two firmwares with different "uses" for the same instance some extra
> > > logic would be required in the driver to make a decision on which firmware to load.
> > 
> > Ok, I probably need some more background about what the firmware on this
> > device does, and what it could do with a different firmware. Could you
> > elaborate?
> 
> So the fdma hw is a dma engine based around a xp70 slim core. It supports: -
> * block memory move between 2 system locations
> * paced transfer from system memory to paced peripheral
> * paced transfer from a paced peripheral to system memory
> 
> I believe each firmware for each instance supports those 3 things.

Ok

> However the xp70 also has some ancilary HW to facilitate Start Code Detection.
> It is this feature which I believe would require a different firmware if we wanted to make
> use of it. Looking at the functional spec each xp70 also
> has 16 gp output signals which we could also control from the firmware. Whether
> these are actually connected to anything useful inside the SoC I don't know.

I still don't understand what Start Code Detection is here.

> > > > and you correctly describe the problem with
> > > > using the compatible string for the firmware name if the driver for the FDMA
> > > > does not actually care what firmware is being used here.
> > > > 
> > > > Whatever code makes the decision as to how the FDMA is used should also
> > > > decide on the name of the firmware file.
> > > 
> > > The code which makes this decision currently is the st_fdma.c driver. However it does
> > > need to know which fdma controller it is operating on to make this decision correctly.
> > > 
> > > Apart from passing the fdma instance number in DT, how else can we determine which
> > > controller we are?
> > > 
> > > I guess we could infer it by having a table in the driver containing the base addresses
> > > of the controllers for a given SoC, and match that against what DT passes us in the
> > > reg property. But that seems ugly, and is encoding the same information in two
> > > different places.
> > > 
> > > I'm open to suggestions if there is a better way to do this.
> > 
> > Using the address would be the same thing, that doesn't change the
> > fundamental logic. Can you explain why it matters which instance
> > a firmware is used on for this driver?
> 
> The reason we care, is that each instance has its own firmware file.
> 
> I just did a hexdump on the 3 different firmwares and compared them. Although the majority
> of the binary is the same, there are various bytes which change at several different offsets
> in the firmware file depending on the instance.
> 
> I don't have a xp70 toolchain or know enough about the cpu architecture to analyze what exactly
> the firmware is doing at these locations.

This sounds like we should indeed treat them as different things: We don't
know what the difference is, but we know that each of them needs a different
firmware, and presumably if you get a new SoC variant, it will in turn
need three new ones.

In this case, I'd say using the compatible string to identify them is best,
using whatever the SoC documentation uses to describe them. You can use the
of_device_id data fields to look up the firmware name then.

If the output signals end up being connected to something we want to
control through the firmware, that also makes sense for a new compatible
string, as the driver needs to know about the feature in order to
communicate with the firmware, and the DT needs to be able to describe
the pins (e.g. by making the node act as a GPIO controller) in a way that
requires a different string, too.

	Arnd
--
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

Re: [PATCH v2 1/9] dmaengine: st_fdma: Add STMicroelectronics FDMA DT binding documentation

[Peter Griffin]

Hi Arnd,

On Tue, 29 Sep 2015, Arnd Bergmann wrote:

> On Tuesday 29 September 2015 14:42:15 Peter Griffin wrote:
> > On Tue, 29 Sep 2015, Arnd Bergmann wrote:
> > > On Tuesday 29 September 2015 13:11:55 Peter Griffin wrote:
> > > > Does it? I didn't think it did.
> > > > 
> > > > Using the instance number as a DT property defers the decision over what firmware to
> > > > load to the driver, which can choose whatever firmware name it wishes.
> > > > 
> > > > e.g. in v4.3 it could load xyz.elf, in v4.4 it could choose abc.elf. The DT will remain
> > > > unchanged, but the use of that fdma instance has changed.
> > > > 
> > > > We currently only have one firmware for each instance with the "use" compiled into it.
> > > > If in the future we had two firmwares with different "uses" for the same instance some extra
> > > > logic would be required in the driver to make a decision on which firmware to load.
> > > 
> > > Ok, I probably need some more background about what the firmware on this
> > > device does, and what it could do with a different firmware. Could you
> > > elaborate?
> > 
> > So the fdma hw is a dma engine based around a xp70 slim core. It supports: -
> > * block memory move between 2 system locations
> > * paced transfer from system memory to paced peripheral
> > * paced transfer from a paced peripheral to system memory
> > 
> > I believe each firmware for each instance supports those 3 things.
> 
> Ok
> 
> > However the xp70 also has some ancilary HW to facilitate Start Code Detection.
> > It is this feature which I believe would require a different firmware if we wanted to make
> > use of it. Looking at the functional spec each xp70 also
> > has 16 gp output signals which we could also control from the firmware. Whether
> > these are actually connected to anything useful inside the SoC I don't know.
> 
> I still don't understand what Start Code Detection is here.

I believe the "Start Code Detection" feature is referring to the 4 byte start code
found in packetized elementary stream (PES). So it is a A/V optimisation for the
DMA controller.

> 
> > > > > and you correctly describe the problem with
> > > > > using the compatible string for the firmware name if the driver for the FDMA
> > > > > does not actually care what firmware is being used here.
> > > > > 
> > > > > Whatever code makes the decision as to how the FDMA is used should also
> > > > > decide on the name of the firmware file.
> > > > 
> > > > The code which makes this decision currently is the st_fdma.c driver. However it does
> > > > need to know which fdma controller it is operating on to make this decision correctly.
> > > > 
> > > > Apart from passing the fdma instance number in DT, how else can we determine which
> > > > controller we are?
> > > > 
> > > > I guess we could infer it by having a table in the driver containing the base addresses
> > > > of the controllers for a given SoC, and match that against what DT passes us in the
> > > > reg property. But that seems ugly, and is encoding the same information in two
> > > > different places.
> > > > 
> > > > I'm open to suggestions if there is a better way to do this.
> > > 
> > > Using the address would be the same thing, that doesn't change the
> > > fundamental logic. Can you explain why it matters which instance
> > > a firmware is used on for this driver?
> > 
> > The reason we care, is that each instance has its own firmware file.
> > 
> > I just did a hexdump on the 3 different firmwares and compared them. Although the majority
> > of the binary is the same, there are various bytes which change at several different offsets
> > in the firmware file depending on the instance.
> > 
> > I don't have a xp70 toolchain or know enough about the cpu architecture to analyze what exactly
> > the firmware is doing at these locations.
> 
> This sounds like we should indeed treat them as different things: We don't
> know what the difference is, but we know that each of them needs a different
> firmware, and presumably if you get a new SoC variant, it will in turn
> need three new ones.

Yes I believe so.

> 
> In this case, I'd say using the compatible string to identify them is best,
> using whatever the SoC documentation uses to describe them. You can use the
> of_device_id data fields to look up the firmware name then.

Ok, I  will implement like this in the next version.

> 
> If the output signals end up being connected to something we want to
> control through the firmware, that also makes sense for a new compatible
> string, as the driver needs to know about the feature in order to
> communicate with the firmware, and the DT needs to be able to describe
> the pins (e.g. by making the node act as a GPIO controller) in a way that
> requires a different string, too.

Yes I agree, thanks for your review and comments :)

regards,

Peter.
--
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

[PATCH v2 2/9] dmaengine: st_fdma: Add st fdma platform specific header

[Peter Griffin]

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 include/linux/platform_data/dma-st_fdma.h | 72 +++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)
 create mode 100644 include/linux/platform_data/dma-st_fdma.h

diff --git a/include/linux/platform_data/dma-st_fdma.h b/include/linux/platform_data/dma-st_fdma.h
new file mode 100644
index 0000000..ea2523b
--- /dev/null
+++ b/include/linux/platform_data/dma-st_fdma.h
@@ -0,0 +1,72 @@
+/*
+ * dma-st-fdma.h
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#ifndef __PLAT_ST_FDMA_H
+#define __PLAT_ST_FDMA_H
+
+#include <linux/dmaengine.h>
+
+/*
+ * Channel type
+ */
+enum st_fdma_type {
+	ST_FDMA_TYPE_FREE_RUN,
+	ST_FDMA_TYPE_PACED,
+};
+
+struct st_fdma_cfg {
+	struct device_node *of_node;
+	enum st_fdma_type type;
+	dma_addr_t dev_addr;
+	enum dma_transfer_direction dir;
+	int req_line; /* request line */
+	u32 req_ctrl; /* Request control */
+};
+
+#define FW_NAME_SIZE 30
+
+/**
+ * struct st_fdma_platform_data - platform specific data for FDMA engine
+ *
+ * @nr_channels:	Number of channels supported by hardware
+ * @fw_name:		The firmware name
+ */
+struct st_fdma_platform_data {
+	u32 nr_channels;
+	u32 id;
+	char fw_name[FW_NAME_SIZE];
+};
+
+/*
+ * request control bits
+ */
+#define REQ_CTRL_NUM_OPS_MASK		GENMASK(31, 24)
+#define REQ_CTRL_NUM_OPS(n)		(REQ_CTRL_NUM_OPS_MASK & ((n) << 24))
+#define REQ_CTRL_INITIATOR_MASK		BIT(22)
+#define	REQ_CTRL_INIT0			(0x0 << 22)
+#define	REQ_CTRL_INIT1			(0x1 << 22)
+#define REQ_CTRL_INC_ADDR_ON		BIT(21)
+#define REQ_CTRL_DATA_SWAP_ON		BIT(17)
+#define REQ_CTRL_WNR			BIT(14)
+#define REQ_CTRL_OPCODE_MASK		GENMASK(7, 4)
+#define REQ_CTRL_OPCODE_LD_ST1		(0x0 << 4)
+#define REQ_CTRL_OPCODE_LD_ST2		(0x1 << 4)
+#define REQ_CTRL_OPCODE_LD_ST4		(0x2 << 4)
+#define REQ_CTRL_OPCODE_LD_ST8		(0x3 << 4)
+#define REQ_CTRL_OPCODE_LD_ST16		(0x4 << 4)
+#define REQ_CTRL_OPCODE_LD_ST32		(0x5 << 4)
+#define REQ_CTRL_OPCODE_LD_ST64		(0x6 << 4)
+#define REQ_CTRL_HOLDOFF_MASK		GENMASK(2, 0)
+#define REQ_CTRL_HOLDOFF(n)		((n) & REQ_CTRL_HOLDOFF_MASK)
+
+/* bits used by client to configure request control */
+#define REQ_CTRL_CFG_MASK (REQ_CTRL_HOLDOFF_MASK | REQ_CTRL_DATA_SWAP_ON \
+			| REQ_CTRL_INC_ADDR_ON | REQ_CTRL_INITIATOR_MASK)
+
+bool st_fdma_filter_fn(struct dma_chan *chan, void *param);
+
+#endif	/* __PLAT_ST_FDMA_H */
-- 
1.9.1

Re: [PATCH v2 2/9] dmaengine: st_fdma: Add st fdma platform specific header

[Arnd Bergmann]

On Friday 11 September 2015 15:14:24 Peter Griffin wrote:
> Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  include/linux/platform_data/dma-st_fdma.h | 72 +++++++++++++++++++++++++++++++
>  1 file changed, 72 insertions(+)
>  create mode 100644 include/linux/platform_data/dma-st_fdma.h
> 

This clearly needs an explanation of which platforms require the header.

On ARM, all new platforms use DT, so it's obviously not one of them.

Also, it would make sense to split the portions that are needed for
defining the platform device from the portions that are used by the
slave device definitions.

	Arnd

Re: [PATCH v2 2/9] dmaengine: st_fdma: Add st fdma platform specific header

[Peter Griffin]

Hi Arnd,

On Fri, 11 Sep 2015, Arnd Bergmann wrote:

> On Friday 11 September 2015 15:14:24 Peter Griffin wrote:
> > Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
> > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > ---
> >  include/linux/platform_data/dma-st_fdma.h | 72 +++++++++++++++++++++++++++++++
> >  1 file changed, 72 insertions(+)
> >  create mode 100644 include/linux/platform_data/dma-st_fdma.h
> > 
> 
> This clearly needs an explanation of which platforms require the header.
> 
> On ARM, all new platforms use DT, so it's obviously not one of them.

I will move the relevant parts into the st_fdma.h header file, as no other platforms
will be upstreamed that are not DT based.

regards,

Peter.

Re: [PATCH v2 2/9] dmaengine: st_fdma: Add st fdma platform specific header

[Arnd Bergmann]

On Tuesday 29 September 2015 10:24:42 Peter Griffin wrote:
> On Fri, 11 Sep 2015, Arnd Bergmann wrote:
> 
> > On Friday 11 September 2015 15:14:24 Peter Griffin wrote:
> > > Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
> > > Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > ---
> > >  include/linux/platform_data/dma-st_fdma.h | 72 +++++++++++++++++++++++++++++++
> > >  1 file changed, 72 insertions(+)
> > >  create mode 100644 include/linux/platform_data/dma-st_fdma.h
> > > 
> > 
> > This clearly needs an explanation of which platforms require the header.
> > 
> > On ARM, all new platforms use DT, so it's obviously not one of them.
> 
> I will move the relevant parts into the st_fdma.h header file, as no other platforms
> will be upstreamed that are not DT based.

Ok, it's possible that you can simplify the code a bit after you do that,
e.g. if you can fold the st_fdma_platform_data structure into the main
per-device structure, and if you remove the filter function.

	Arnd
--
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

[PATCH v2 3/9] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Peter Griffin]

Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/dma/st_fdma.h | 237 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 237 insertions(+)
 create mode 100644 drivers/dma/st_fdma.h

diff --git a/drivers/dma/st_fdma.h b/drivers/dma/st_fdma.h
new file mode 100644
index 0000000..5841a301
--- /dev/null
+++ b/drivers/dma/st_fdma.h
@@ -0,0 +1,237 @@
+/*
+ * st_fdma.h
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre <Ludovic.barre-qxv4g6HH51o@public.gmane.org>
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#ifndef __DMA_ST_FDMA_H
+#define __DMA_ST_FDMA_H
+
+#include <linux/dmaengine.h>
+#include <linux/interrupt.h>
+#include <linux/platform_data/dma-st_fdma.h>
+
+#include "virt-dma.h"
+
+#define ST_FDMA_NR_DREQS 32
+#define EM_SLIM	102	/* No official SLIM ELF ID */
+
+enum {
+	CLK_SLIM,
+	CLK_HI,
+	CLK_LOW,
+	CLK_IC,
+	CLK_MAX_NUM,
+};
+
+#define NAME_SZ 10
+
+struct st_fdma_ram {
+	char name[NAME_SZ];
+	u32 offset;
+	u32 size;
+};
+
+/**
+ * struct st_fdma_generic_node - Free running/paced generic node
+ *
+ * @length: Length in bytes of a line in a 2D mem to mem
+ * @sstride: Stride, in bytes, between source lines in a 2D data move
+ * @dstride: Stride, in bytes, between destination lines in a 2D data move
+ */
+struct st_fdma_generic_node {
+	u32 length;
+	u32 sstride;
+	u32 dstride;
+};
+
+/**
+ * struct st_fdma_hw_node - Node structure used by fdma hw
+ *
+ * @next: Pointer to next node
+ * @control: Transfer Control Parameters
+ * @nbytes: Number of Bytes to read
+ * @saddr: Source address
+ * @daddr: Destination address
+ *
+ * @generic: generic node for free running/paced transfert type
+ * 2 others transfert type are possible, but not yet implemented
+ *
+ * The NODE structures must be aligned to a 32 byte boundary
+ */
+struct st_fdma_hw_node {
+	u32 next;
+	u32 control;
+	u32 nbytes;
+	u32 saddr;
+	u32 daddr;
+	union {
+		struct st_fdma_generic_node generic;
+	};
+} __aligned(32);
+
+/*
+ * node control parameters
+ */
+#define NODE_CTRL_REQ_MAP_MASK		GENMASK(4, 0)
+#define NODE_CTRL_REQ_MAP_FREE_RUN	0x0
+#define NODE_CTRL_REQ_MAP_DREQ(n)	((n) & NODE_CTRL_REQ_MAP_MASK)
+#define NODE_CTRL_REQ_MAP_EXT		NODE_CTRL_REQ_MAP_MASK
+#define NODE_CTRL_SRC_MASK		GENMASK(6, 5)
+#define NODE_CTRL_SRC_STATIC		BIT(5)
+#define NODE_CTRL_SRC_INCR		BIT(6)
+#define NODE_CTRL_DST_MASK		GENMASK(8, 7)
+#define NODE_CTRL_DST_STATIC		BIT(7)
+#define NODE_CTRL_DST_INCR		BIT(8)
+#define NODE_CTRL_SECURE		BIT(15)
+#define NODE_CTRL_PAUSE_EON		BIT(30)
+#define NODE_CTRL_INT_EON		BIT(31)
+
+/**
+ * struct st_fdma_sw_node - descriptor structure for link list
+ *
+ * @pdesc: Physical address of desc
+ * @node: link used for putting this into a channel queue
+ */
+struct st_fdma_sw_node {
+	dma_addr_t pdesc;
+	struct st_fdma_hw_node *desc;
+};
+
+struct st_fdma_driverdata {
+	const struct st_fdma_ram *fdma_mem;
+	u32 num_mem;
+	char name[NAME_SZ];
+};
+
+struct st_fdma_desc {
+	struct virt_dma_desc vdesc;
+	struct st_fdma_chan *fchan;
+	bool iscyclic;
+	unsigned int n_nodes;
+	struct st_fdma_sw_node node[];
+};
+
+struct st_fdma_chan {
+	struct st_fdma_dev *fdev;
+	struct dma_pool *node_pool;
+	struct dma_slave_config scfg;
+	struct st_fdma_cfg cfg;
+
+	int dreq_line;
+
+	struct virt_dma_chan vchan;
+	struct st_fdma_desc *fdesc;
+	enum dma_status	status;
+};
+
+struct st_fdma_dev {
+	struct device *dev;
+	const struct st_fdma_driverdata *drvdata;
+	const struct st_fdma_platform_data *pdata;
+	struct dma_device dma_device;
+
+	void __iomem *io_base;
+	struct resource *io_res;
+	struct clk *clks[CLK_MAX_NUM];
+
+	struct st_fdma_chan *chans;
+
+	spinlock_t dreq_lock;
+	unsigned long dreq_mask;
+
+	struct completion fw_ack;
+	atomic_t fw_loaded;
+};
+
+/* Registers*/
+/* FDMA interface */
+#define FDMA_ID_OFST		0x00000
+#define FDMA_VER_OFST		0x00004
+
+#define FDMA_EN_OFST		0x00008
+#define FDMA_EN_RUN			BIT(0)
+
+#define FDMA_CLK_GATE_OFST	0x0000C
+#define FDMA_CLK_GATE_DIS		BIT(0)
+#define FDMA_CLK_GATE_RESET		BIT(2)
+
+#define FDMA_SLIM_PC_OFST	0x00020
+
+#define FDMA_REV_ID_OFST	0x10000
+#define FDMA_REV_ID_MIN_MASK		GENMASK(15, 8)
+#define FDMA_REV_ID_MIN(id)		((id & FDMA_REV_ID_MIN_MASK) >> 8)
+#define FDMA_REV_ID_MAJ_MASK		GENMASK(23, 16)
+#define FDMA_REV_ID_MAJ(id)		((id & FDMA_REV_ID_MAJ_MASK) >> 16)
+
+#define FDMA_STBUS_SYNC_OFST	0x17F88
+#define FDMA_STBUS_SYNC_DIS		BIT(0)
+
+#define FDMA_CMD_STA_OFST	0x17FC0
+#define FDMA_CMD_SET_OFST	0x17FC4
+#define FDMA_CMD_CLR_OFST	0x17FC8
+#define FDMA_CMD_MASK_OFST	0x17FCC
+#define FDMA_CMD_START(ch)		(0x1 << (ch << 1))
+#define FDMA_CMD_PAUSE(ch)		(0x2 << (ch << 1))
+#define FDMA_CMD_FLUSH(ch)		(0x3 << (ch << 1))
+
+#define FDMA_INT_STA_OFST	0x17FD0
+#define FDMA_INT_STA_CH			0x1
+#define FDMA_INT_STA_ERR		0x2
+
+#define FDMA_INT_SET_OFST	0x17FD4
+#define FDMA_INT_CLR_OFST	0x17FD8
+#define FDMA_INT_MASK_OFST	0x17FDC
+
+#define fdma_read(fdev, name) \
+	readl_relaxed((fdev)->io_base + FDMA_##name##_OFST)
+
+#define fdma_write(fdev, val, name) \
+	writel_relaxed((val), (fdev)->io_base + FDMA_##name##_OFST)
+
+/* fchan interface */
+#define FDMA_CH_CMD_OFST	0x10200
+#define FDMA_CH_CMD_STA_MASK		GENMASK(1, 0)
+#define FDMA_CH_CMD_STA_IDLE		(0x0)
+#define FDMA_CH_CMD_STA_START		(0x1)
+#define FDMA_CH_CMD_STA_RUNNING		(0x2)
+#define FDMA_CH_CMD_STA_PAUSED		(0x3)
+#define FDMA_CH_CMD_ERR_MASK		GENMASK(4, 2)
+#define FDMA_CH_CMD_ERR_INT		(0x0 << 2)
+#define FDMA_CH_CMD_ERR_NAND		(0x1 << 2)
+#define FDMA_CH_CMD_ERR_MCHI		(0x2 << 2)
+#define FDMA_CH_CMD_DATA_MASK		GENMASK(31, 5)
+#define fchan_read(fchan, name) \
+	readl_relaxed((fchan)->fdev->io_base \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ FDMA_##name##_OFST)
+
+#define fchan_write(fchan, val, name) \
+	writel_relaxed((val), (fchan)->fdev->io_base \
+			+ (fchan)->vchan.chan.chan_id * 0x4 \
+			+ FDMA_##name##_OFST)
+
+/* req interface */
+#define FDMA_REQ_CTRL_OFST	0x10240
+#define dreq_write(fchan, val, name) \
+	writel_relaxed((val), (fchan)->fdev->io_base \
+			+ fchan->dreq_line * 0x04 \
+			+ FDMA_##name##_OFST)
+/* node interface */
+#define FDMA_NODE_SZ 128
+#define FDMA_PTRN_OFST		0x10800
+#define FDMA_CNTN_OFST		0x10808
+#define FDMA_SADDRN_OFST	0x1080c
+#define FDMA_DADDRN_OFST	0x10810
+#define fnode_read(fchan, name) \
+	readl_relaxed((fchan)->fdev->io_base \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ FDMA_##name##_OFST)
+
+#define fnode_write(fchan, val, name) \
+	writel_relaxed((val), (fchan)->fdev->io_base \
+			+ (fchan)->vchan.chan.chan_id * FDMA_NODE_SZ \
+			+ FDMA_##name##_OFST)
+
+#endif	/* __DMA_ST_FDMA_H */
-- 
1.9.1

--
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

Re: [PATCH v2 3/9] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Koul, Vinod]

On Fri, 2015-09-11 at 15:14 +0100, Peter Griffin wrote:

> +#define FDMA_ID_OFST		0x00000
> +#define FDMA_VER_OFST		0x00004
> > +
> +#define FDMA_EN_OFST		0x00008

Why cant these be BIT() to maintain consistency?

-- 
~Vinod

Re: [PATCH v2 3/9] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Peter Griffin]

[-- Attachment #1: Type: text/plain, Size: 470 bytes --]

Hi,

On 8 October 2015 at 16:43, Koul, Vinod <vinod.koul@intel.com> wrote:

> On Fri, 2015-09-11 at 15:14 +0100, Peter Griffin wrote:
>
> > +#define FDMA_ID_OFST         0x00000
> > +#define FDMA_VER_OFST                0x00004
> > > +
> > +#define FDMA_EN_OFST         0x00008
>
> Why cant these be BIT() to maintain consistency?
>

These are actually register offsets. I'm only using the BIT
macro for bitfields within the registers e.g. FDMA_EN_RUN

regards,

Peter.

[-- Attachment #2: Type: text/html, Size: 941 bytes --]

Re: [PATCH v2 3/9] dmaengine: st_fdma: Add STMicroelectronics FDMA driver header file

[Peter Griffin]

Hi,

On Thu, 08 Oct 2015, Koul, Vinod wrote:

> On Fri, 2015-09-11 at 15:14 +0100, Peter Griffin wrote:
> 
> > +#define FDMA_ID_OFST		0x00000
> > +#define FDMA_VER_OFST		0x00004
> > > +
> > +#define FDMA_EN_OFST		0x00008
> 
> Why cant these be BIT() to maintain consistency?
> 

These are actually register offsets. I'm only using the BIT
macro for bitfields within the registers e.g. FDMA_EN_RUN

regards,

Peter.
--
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

[PATCH v2 5/9] dmaengine: st_fdma: Add xp70 firmware loading mechanism.

[Peter Griffin]

This patch adds the code to load the xp70 fdma firmware
using the asynchronous request_firmware_nowait call
so as not to delay bootup of builtin code.

Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/dma/st_fdma.c | 199 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 199 insertions(+)

diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 24ebd0b..4288e79 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -83,6 +83,162 @@ static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
 	return container_of(vd, struct st_fdma_desc, vdesc);
 }
 
+static void *st_fdma_seg_to_mem(struct st_fdma_dev *fdev, u64 da, int len)
+{
+	int i;
+	resource_size_t base = fdev->io_res->start;
+	const struct st_fdma_ram *fdma_mem = fdev->drvdata->fdma_mem;
+	void *ptr = NULL;
+
+	for (i = 0; i < fdev->drvdata->num_mem; i++) {
+		int mem_off = da - (base + fdma_mem[i].offset);
+
+		/* next mem if da is too small */
+		if (mem_off < 0)
+			continue;
+
+		/* next mem if da is too large */
+		if (mem_off + len > fdma_mem[i].size)
+			continue;
+
+		ptr = fdev->io_base + fdma_mem[i].offset + mem_off;
+		break;
+	}
+
+	return ptr;
+}
+
+static int
+st_fdma_elf_sanity_check(struct st_fdma_dev *fdev, const struct firmware *fw)
+{
+	const char *fw_name = fdev->pdata->fw_name;
+	struct elf32_hdr *ehdr;
+	char class;
+
+	if (!fw) {
+		dev_err(fdev->dev, "failed to load %s\n", fw_name);
+		return -EINVAL;
+	}
+
+	if (fw->size < sizeof(*ehdr)) {
+		dev_err(fdev->dev, "Image is too small\n");
+		return -EINVAL;
+	}
+
+	ehdr = (struct elf32_hdr *)fw->data;
+
+	/* We only support ELF32 at this point */
+	class = ehdr->e_ident[EI_CLASS];
+	if (class != ELFCLASS32) {
+		dev_err(fdev->dev, "Unsupported class: %d\n", class);
+		return -EINVAL;
+	}
+
+	if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) {
+		dev_err(fdev->dev, "Unsupported firmware endianness"
+			"(%d) expected (%d)\n", ehdr->e_ident[EI_DATA],
+			ELFDATA2LSB);
+		return -EINVAL;
+	}
+
+	if (fw->size < ehdr->e_shoff + sizeof(struct elf32_shdr)) {
+		dev_err(fdev->dev, "Image is too small (%u)\n", fw->size);
+		return -EINVAL;
+	}
+
+	if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+		dev_err(fdev->dev, "Image is corrupted (bad magic)\n");
+		return -EINVAL;
+	}
+
+	if (ehdr->e_phnum != fdev->drvdata->num_mem) {
+		dev_err(fdev->dev, "spurious nb of segments (%d) expected (%d)"
+			"\n", ehdr->e_phnum, fdev->drvdata->num_mem);
+		return -EINVAL;
+	}
+
+	if (ehdr->e_type != ET_EXEC) {
+		dev_err(fdev->dev, "Unsupported ELF header type (%d) expected"
+			" (%d)\n", ehdr->e_type, ET_EXEC);
+		return -EINVAL;
+	}
+
+	if (ehdr->e_machine != EM_SLIM) {
+		dev_err(fdev->dev, "Unsupported ELF header machine (%d) "
+			"expected (%d)\n", ehdr->e_machine, EM_SLIM);
+		return -EINVAL;
+	}
+	if (ehdr->e_phoff > fw->size) {
+		dev_err(fdev->dev, "Firmware size is too small\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int
+st_fdma_elf_load_segments(struct st_fdma_dev *fdev, const struct firmware *fw)
+{
+	struct device *dev = fdev->dev;
+	struct elf32_hdr *ehdr;
+	struct elf32_phdr *phdr;
+	int i, mem_loaded = 0;
+	const u8 *elf_data = fw->data;
+
+	ehdr = (struct elf32_hdr *)elf_data;
+	phdr = (struct elf32_phdr *)(elf_data + ehdr->e_phoff);
+
+	/*
+	 * go through the available ELF segments
+	 * the program header's paddr member to contain device addresses.
+	 * We then go through the physically contiguous memory regions which we
+	 * allocated (and mapped) earlier on the probe,
+	 * and "translate" device address to kernel addresses,
+	 * so we can copy the segments where they are expected.
+	 */
+	for (i = 0; i < ehdr->e_phnum; i++, phdr++) {
+		u32 da = phdr->p_paddr;
+		u32 memsz = phdr->p_memsz;
+		u32 filesz = phdr->p_filesz;
+		u32 offset = phdr->p_offset;
+		void *dst;
+
+		if (phdr->p_type != PT_LOAD)
+			continue;
+
+		dev_dbg(dev, "phdr: type %d da %#x ofst:%#x memsz %#x filesz %#x\n",
+			phdr->p_type, da, offset, memsz, filesz);
+
+		if (filesz > memsz) {
+			dev_err(dev, "bad phdr filesz 0x%x memsz 0x%x\n",
+				filesz, memsz);
+			break;
+		}
+
+		if (offset + filesz > fw->size) {
+			dev_err(dev, "truncated fw: need 0x%x avail 0x%zx\n",
+				offset + filesz, fw->size);
+			break;
+		}
+
+		dst = st_fdma_seg_to_mem(fdev, da, memsz);
+		if (!dst) {
+			dev_err(dev, "bad phdr da 0x%x mem 0x%x\n", da, memsz);
+			break;
+		}
+
+		if (phdr->p_filesz)
+			memcpy(dst, elf_data + phdr->p_offset, filesz);
+
+		if (memsz > filesz)
+			memset(dst + filesz, 0, memsz - filesz);
+
+		mem_loaded++;
+	}
+
+	return (mem_loaded != fdev->drvdata->num_mem) ? -EIO : 0;
+}
+
 static void st_fdma_enable(struct st_fdma_dev *fdev)
 {
 	unsigned long hw_id, hw_ver, fw_rev;
@@ -125,6 +281,45 @@ static int st_fdma_disable(struct st_fdma_dev *fdev)
 	return readl(fdev->io_base + FDMA_EN_OFST);
 }
 
+static void st_fdma_fw_cb(const struct firmware *fw, void *context)
+{
+	struct st_fdma_dev *fdev = context;
+	int ret;
+
+	ret = st_fdma_elf_sanity_check(fdev, fw);
+	if (ret)
+		goto out;
+
+	st_fdma_disable(fdev);
+	ret = st_fdma_elf_load_segments(fdev, fw);
+	if (ret)
+		goto out;
+
+	st_fdma_enable(fdev);
+	atomic_set(&fdev->fw_loaded, 1);
+out:
+	release_firmware(fw);
+	complete_all(&fdev->fw_ack);
+}
+
+static int st_fdma_get_fw(struct st_fdma_dev *fdev)
+{
+	int ret;
+
+	init_completion(&fdev->fw_ack);
+	atomic_set(&fdev->fw_loaded, 0);
+
+	ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
+				      fdev->pdata->fw_name, fdev->dev,
+				      GFP_KERNEL, fdev, st_fdma_fw_cb);
+	if (ret) {
+		dev_err(fdev->dev, "request_firmware_nowait err: %d\n", ret);
+		complete_all(&fdev->fw_ack);
+	}
+
+	return ret;
+}
+
 static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
 {
 	struct st_fdma_dev *fdev = fchan->fdev;
@@ -868,6 +1063,10 @@ static int st_fdma_probe(struct platform_device *pdev)
 		vchan_init(&fchan->vchan, &fdev->dma_device);
 	}
 
+	ret = st_fdma_get_fw(fdev);
+	if (ret)
+		goto err_clk;
+
 	/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
 	fdev->dreq_mask = BIT(0) | BIT(31);
 
-- 
1.9.1

--
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

Re: [PATCH v2 5/9] dmaengine: st_fdma: Add xp70 firmware loading mechanism.

[Vinod Koul]

On Fri, Sep 11, 2015 at 03:14:27PM +0100, Peter Griffin wrote:
> This patch adds the code to load the xp70 fdma firmware
> using the asynchronous request_firmware_nowait call
> so as not to delay bootup of builtin code.

Okay we need to check here. Can the driver be built in, if so this is not
the right usage. You should load the firmware on first open for this device

See https://lkml.org/lkml/2015/8/26/588

-- 
~Vinod

Re: [PATCH v2 5/9] dmaengine: st_fdma: Add xp70 firmware loading mechanism.

[Peter Griffin]

Hi Vinod,

On Wed, 07 Oct 2015, Vinod Koul wrote:

> On Fri, Sep 11, 2015 at 03:14:27PM +0100, Peter Griffin wrote:
> > This patch adds the code to load the xp70 fdma firmware
> > using the asynchronous request_firmware_nowait call
> > so as not to delay bootup of builtin code.
> 
> Okay we need to check here. Can the driver be built in,

Yes it can be built in.

> if so this is not
> the right usage. You should load the firmware on first open for this device
> 
> See https://lkml.org/lkml/2015/8/26/588

Ok, thanks for the link, I will see if it is possible to load the firmware after
the first open. If it is I will do this in the next version.

regards,

Peter.

[PATCH v2 6/9] dmaengine: st_fdma: Add fdma suspend and resume callbacks.

[Peter Griffin]

This patch adds the functions to gate the xp70 clock on
suspend and resume.

Signed-off-by: Ludovic Barre <ludovic.barre-qxv4g6HH51o@public.gmane.org>
Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
 drivers/dma/st_fdma.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
index 4288e79..de3afefb 100644
--- a/drivers/dma/st_fdma.c
+++ b/drivers/dma/st_fdma.c
@@ -1127,10 +1127,56 @@ static int st_fdma_remove(struct platform_device *pdev)
 	return 0;
 }
 
+#ifdef CONFIG_PM_SLEEP
+static int st_fdma_pm_suspend(struct device *dev)
+{
+	struct st_fdma_dev *fdev = dev_get_drvdata(dev);
+	int ret;
+
+	if (atomic_read(&fdev->fw_loaded)) {
+		ret = st_fdma_disable(fdev);
+		if (ret & FDMA_EN_RUN) {
+			dev_warn(fdev->dev, "Failed to disable channels");
+			return -EBUSY;
+		}
+	}
+
+	st_fdma_clk_disable(fdev);
+
+	return 0;
+}
+
+static int st_fdma_pm_resume(struct device *dev)
+{
+	struct st_fdma_dev *fdev = dev_get_drvdata(dev);
+	int ret;
+
+	ret = st_fdma_clk_enable(fdev);
+	if (ret) {
+		dev_err(fdev->dev, "Failed to enable clocks\n");
+		goto out;
+	}
+
+	ret = st_fdma_get_fw(fdev);
+out:
+	return ret;
+}
+
+static const struct dev_pm_ops st_fdma_pm = {
+	.suspend_late = st_fdma_pm_suspend,
+	.resume_early = st_fdma_pm_resume,
+};
+
+#define ST_FDMA_PM	(&st_fdma_pm)
+#else
+#define ST_FDMA_PM	NULL
+#endif
+
 static struct platform_driver st_fdma_platform_driver = {
 	.driver = {
 		.name = "st-fdma",
 		.of_match_table = st_fdma_match,
+		.pm = ST_FDMA_PM,
 	},
 	.probe = st_fdma_probe,
 	.remove = st_fdma_remove,
-- 
1.9.1

--
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

Re: [PATCH v2 6/9] dmaengine: st_fdma: Add fdma suspend and resume callbacks.

[Vinod Koul]

On Fri, Sep 11, 2015 at 03:14:28PM +0100, Peter Griffin wrote:
> +#define ST_FDMA_PM	(&st_fdma_pm)
> +#else
> +#define ST_FDMA_PM	NULL
> +#endif
Pls use PM helpers you dont need to do this

-- 
~Vinod

Re: [PATCH v2 6/9] dmaengine: st_fdma: Add fdma suspend and resume callbacks.

[Peter Griffin]

Hi Vinod,

On Wed, 07 Oct 2015, Vinod Koul wrote:

> On Fri, Sep 11, 2015 at 03:14:28PM +0100, Peter Griffin wrote:
> > +#define ST_FDMA_PM	(&st_fdma_pm)
> > +#else
> > +#define ST_FDMA_PM	NULL
> > +#endif
> Pls use PM helpers you dont need to do this
> 
Could you point me at the PM helpers you are referring to?

regards,

Peter.
--
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

Re: [PATCH v2 6/9] dmaengine: st_fdma: Add fdma suspend and resume callbacks.

[Koul, Vinod]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 611 bytes --]

On Tue, 2015-10-13 at 12:19 +0100, Peter Griffin wrote:
> Hi Vinod,
> 
> On Wed, 07 Oct 2015, Vinod Koul wrote:
> 
> > On Fri, Sep 11, 2015 at 03:14:28PM +0100, Peter Griffin wrote:
> > > +#define ST_FDMA_PM	(&st_fdma_pm)
> > > +#else
> > > +#define ST_FDMA_PM	NULL
> > > +#endif
> > Pls use PM helpers you dont need to do this
> > 
> Could you point me at the PM helpers you are referring to?

See SET_RUNTIME_PM_OPS and friends, defined in pm.h

-- 
~Vinod
N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i

[PATCH v2 4/9] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Peter Griffin]

This patch adds support for the Flexible Direct Memory Access (FDMA) core
driver. The FDMA is a slim core CPU with a dedicated firmware.
It is a general purpose DMA controller capable of supporting 16
independent DMA channels. Data moves maybe from memory to memory
or between memory and paced latency critical real time targets and it
is found on al STi based chipsets.

Signed-off-by: Ludovic Barre <ludovic.barre@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 drivers/dma/Kconfig   |  14 +
 drivers/dma/Makefile  |   1 +
 drivers/dma/st_fdma.c | 959 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 974 insertions(+)
 create mode 100644 drivers/dma/st_fdma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 88d474b..8b2609a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -507,4 +507,18 @@ config QCOM_BAM_DMA
 	  Enable support for the QCOM BAM DMA controller.  This controller
 	  provides DMA capabilities for a variety of on-chip devices.
 
+config ST_FDMA
+	tristate "ST FDMA dmaengine support"
+	depends on ARCH_STI
+	select DMA_ENGINE
+	select FW_LOADER
+	select FW_LOADER_USER_HELPER_FALLBACK
+	select DMA_VIRTUAL_CHANNELS
+	help
+	  Enable support for ST FDMA controller.
+	  It supports 16 independent DMA channels, accepts up to 32 DMA requests
+
+	  Say Y here if you have such a chipset.
+	  If unsure, say N.
+
 endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 6a4d6f2..f68e6d8 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_MOXART_DMA) += moxart-dma.o
 obj-$(CONFIG_FSL_RAID) += fsl_raid.o
 obj-$(CONFIG_FSL_EDMA) += fsl-edma.o
 obj-$(CONFIG_QCOM_BAM_DMA) += qcom_bam_dma.o
+obj-$(CONFIG_ST_FDMA) += st_fdma.o
 obj-y += xilinx/
 obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
 obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
diff --git a/drivers/dma/st_fdma.c b/drivers/dma/st_fdma.c
new file mode 100644
index 0000000..24ebd0b
--- /dev/null
+++ b/drivers/dma/st_fdma.c
@@ -0,0 +1,959 @@
+/*
+ * st_fdma.c
+ *
+ * Copyright (C) 2014 STMicroelectronics
+ * Author: Ludovic Barre <Ludovic.barre@st.com>
+ * License terms:  GNU General Public License (GPL), version 2
+ */
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_dma.h>
+#include <linux/platform_device.h>
+#include <linux/interrupt.h>
+#include <linux/clk.h>
+#include <linux/dmaengine.h>
+#include <linux/dmapool.h>
+#include <linux/firmware.h>
+#include <linux/elf.h>
+#include <linux/atomic.h>
+
+#include "st_fdma.h"
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+static char *fdma_clk_name[CLK_MAX_NUM] = {
+	[CLK_SLIM]	= "fdma_slim",
+	[CLK_HI]	= "fdma_hi",
+	[CLK_LOW]	= "fdma_low",
+	[CLK_IC]	= "fdma_ic",
+};
+
+static int st_fdma_clk_get(struct st_fdma_dev *fdev)
+{
+	int i;
+
+	for (i = 0; i < CLK_MAX_NUM; i++) {
+		fdev->clks[i] = devm_clk_get(fdev->dev, fdma_clk_name[i]);
+		if (IS_ERR(fdev->clks[i])) {
+			dev_err(fdev->dev,
+				"failed to get clock: %s\n", fdma_clk_name[i]);
+			return PTR_ERR(fdev->clks[i]);
+		}
+	}
+
+	if (i != CLK_MAX_NUM) {
+		dev_err(fdev->dev, "all clocks are not defined\n");
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int st_fdma_clk_enable(struct st_fdma_dev *fdev)
+{
+	int i, ret;
+
+	for (i = 0; i < CLK_MAX_NUM; i++) {
+		ret = clk_prepare_enable(fdev->clks[i]);
+		if (ret < 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+static void st_fdma_clk_disable(struct st_fdma_dev *fdev)
+{
+	int i;
+
+	for (i = 0; i < CLK_MAX_NUM; i++)
+		clk_disable_unprepare(fdev->clks[i]);
+}
+
+static inline struct st_fdma_chan *to_st_fdma_chan(struct dma_chan *c)
+{
+	return container_of(c, struct st_fdma_chan, vchan.chan);
+}
+
+static struct st_fdma_desc *to_st_fdma_desc(struct virt_dma_desc *vd)
+{
+	return container_of(vd, struct st_fdma_desc, vdesc);
+}
+
+static void st_fdma_enable(struct st_fdma_dev *fdev)
+{
+	unsigned long hw_id, hw_ver, fw_rev;
+	u32 val;
+
+	/* disable CPU pipeline clock & reset cpu pipeline */
+	val = FDMA_CLK_GATE_DIS | FDMA_CLK_GATE_RESET;
+	fdma_write(fdev, val, CLK_GATE);
+	/* disable SLIM core STBus sync */
+	fdma_write(fdev, FDMA_STBUS_SYNC_DIS, STBUS_SYNC);
+	/* enable cpu pipeline clock */
+	fdma_write(fdev, !FDMA_CLK_GATE_DIS, CLK_GATE);
+	/* clear int & cmd mailbox */
+	fdma_write(fdev, ~0UL, INT_CLR);
+	fdma_write(fdev, ~0UL, CMD_CLR);
+	/* enable all channels cmd & int */
+	fdma_write(fdev, ~0UL, INT_MASK);
+	fdma_write(fdev, ~0UL, CMD_MASK);
+	/* enable cpu */
+	writel(FDMA_EN_RUN, fdev->io_base + FDMA_EN_OFST);
+
+	hw_id = fdma_read(fdev, ID);
+	hw_ver = fdma_read(fdev, VER);
+	fw_rev = fdma_read(fdev, REV_ID);
+
+	dev_info(fdev->dev, "fw rev:%ld.%ld on SLIM %ld.%ld\n",
+		 FDMA_REV_ID_MAJ(fw_rev), FDMA_REV_ID_MIN(fw_rev),
+		 hw_id, hw_ver);
+}
+
+static int st_fdma_disable(struct st_fdma_dev *fdev)
+{
+	/* mask all (cmd & int) channels */
+	fdma_write(fdev, 0UL, INT_MASK);
+	fdma_write(fdev, 0UL, CMD_MASK);
+	/* disable cpu pipeline clock */
+	fdma_write(fdev, FDMA_CLK_GATE_DIS, CLK_GATE);
+	writel(!FDMA_EN_RUN, fdev->io_base + FDMA_EN_OFST);
+
+	return readl(fdev->io_base + FDMA_EN_OFST);
+}
+
+static int st_fdma_dreq_get(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+	u32 req_line_cfg = fchan->cfg.req_line;
+	u32 dreq_line;
+	int try = 0;
+
+	/*
+	 * dreq_mask is shared for n channels of fdma, so all accesses must be
+	 * atomic. if the dreq_mask it change between ffz ant set_bit,
+	 * we retry
+	 */
+	do {
+		if (fdev->dreq_mask == ~0L) {
+			dev_err(fdev->dev, "No req lines available\n");
+			return -EINVAL;
+		}
+
+		if (try || req_line_cfg >= ST_FDMA_NR_DREQS) {
+			dev_err(fdev->dev, "Invalid or used req line\n");
+			return -EINVAL;
+		} else {
+			dreq_line = req_line_cfg;
+		}
+
+		try++;
+	} while (test_and_set_bit(dreq_line, &fdev->dreq_mask));
+
+	dev_dbg(fdev->dev, "get dreq_line:%d mask:%#lx\n",
+		dreq_line, fdev->dreq_mask);
+
+	return dreq_line;
+}
+
+static void st_fdma_dreq_put(struct st_fdma_chan *fchan)
+{
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	dev_dbg(fdev->dev, "put dreq_line:%#x\n", fchan->dreq_line);
+	clear_bit(fchan->dreq_line, &fdev->dreq_mask);
+}
+
+static void st_fdma_xfer_desc(struct st_fdma_chan *fchan)
+{
+	struct virt_dma_desc *vdesc;
+	unsigned long nbytes, ch_cmd, cmd;
+
+	vdesc = vchan_next_desc(&fchan->vchan);
+	if (!vdesc)
+		return;
+
+	fchan->fdesc = to_st_fdma_desc(vdesc);
+	nbytes = fchan->fdesc->node[0].desc->nbytes;
+	cmd = FDMA_CMD_START(fchan->vchan.chan.chan_id);
+	ch_cmd = fchan->fdesc->node[0].pdesc | FDMA_CH_CMD_STA_START;
+
+	/* start the channel for the descriptor */
+	fnode_write(fchan, nbytes, CNTN);
+	fchan_write(fchan, ch_cmd, CH_CMD);
+	writel(cmd, fchan->fdev->io_base + FDMA_CMD_SET_OFST);
+
+	dev_dbg(fchan->fdev->dev, "start chan:%d\n", fchan->vchan.chan.chan_id);
+}
+
+static void st_fdma_ch_sta_update(struct st_fdma_chan *fchan,
+				  unsigned long int_sta)
+{
+	unsigned long ch_sta, ch_err;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	ch_sta = fchan_read(fchan, CH_CMD);
+	ch_err = ch_sta & FDMA_CH_CMD_ERR_MASK;
+	ch_sta &= FDMA_CH_CMD_STA_MASK;
+
+	if (int_sta & FDMA_INT_STA_ERR) {
+		dev_warn(fdev->dev, "chan:%d, error:%ld\n", ch_id, ch_err);
+		fchan->status = DMA_ERROR;
+		return;
+	}
+
+	switch (ch_sta) {
+	case FDMA_CH_CMD_STA_PAUSED:
+		fchan->status = DMA_PAUSED;
+		break;
+	case FDMA_CH_CMD_STA_RUNNING:
+		fchan->status = DMA_IN_PROGRESS;
+		break;
+	}
+}
+
+static irqreturn_t st_fdma_irq_handler(int irq, void *dev_id)
+{
+	struct st_fdma_dev *fdev = dev_id;
+	irqreturn_t ret = IRQ_NONE;
+	struct st_fdma_chan *fchan = &fdev->chans[0];
+	unsigned long int_sta, clr;
+
+	int_sta = fdma_read(fdev, INT_STA);
+	clr = int_sta;
+
+	for (; int_sta != 0 ; int_sta >>= 2, fchan++) {
+		if (!(int_sta & (FDMA_INT_STA_CH | FDMA_INT_STA_ERR)))
+			continue;
+
+		spin_lock(&fchan->vchan.lock);
+		st_fdma_ch_sta_update(fchan, int_sta);
+
+		if (fchan->fdesc) {
+			if (!fchan->fdesc->iscyclic) {
+				list_del(&fchan->fdesc->vdesc.node);
+				vchan_cookie_complete(&fchan->fdesc->vdesc);
+				fchan->fdesc = NULL;
+				fchan->status = DMA_COMPLETE;
+			} else {
+				vchan_cyclic_callback(&fchan->fdesc->vdesc);
+			}
+
+			/* Start the next descriptor (if available) */
+			if (!fchan->fdesc)
+				st_fdma_xfer_desc(fchan);
+		}
+
+		spin_unlock(&fchan->vchan.lock);
+		ret = IRQ_HANDLED;
+	}
+
+	fdma_write(fdev, clr, INT_CLR);
+
+	return ret;
+}
+
+static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
+					 struct of_dma *ofdma)
+{
+	struct st_fdma_dev *fdev = ofdma->of_dma_data;
+	struct st_fdma_cfg cfg;
+
+	if (dma_spec->args_count < 1)
+		return NULL;
+
+	cfg.of_node = dma_spec->np;
+	cfg.req_line = dma_spec->args[0];
+	cfg.req_ctrl = 0;
+	cfg.type = ST_FDMA_TYPE_FREE_RUN;
+
+	if (dma_spec->args_count > 1)
+		cfg.req_ctrl = dma_spec->args[1] & REQ_CTRL_CFG_MASK;
+
+	if (dma_spec->args_count > 2)
+		cfg.type = dma_spec->args[2];
+
+	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#x\n",
+		cfg.req_line, cfg.type, cfg.req_ctrl);
+
+	return dma_request_channel(fdev->dma_device.cap_mask,
+			st_fdma_filter_fn, &cfg);
+}
+
+static void st_fdma_free_desc(struct virt_dma_desc *vdesc)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = to_st_fdma_desc(vdesc);
+	for (i = 0; i < fdesc->n_nodes; i++)
+			dma_pool_free(fdesc->fchan->node_pool,
+				      fdesc->node[i].desc,
+				      fdesc->node[i].pdesc);
+	kfree(fdesc);
+}
+
+static struct st_fdma_desc *st_fdma_alloc_desc(struct st_fdma_chan *fchan,
+					       int sg_len)
+{
+	struct st_fdma_desc *fdesc;
+	int i;
+
+	fdesc = kzalloc(sizeof(*fdesc) +
+			sizeof(struct st_fdma_sw_node) * sg_len, GFP_NOWAIT);
+	if (!fdesc)
+		return NULL;
+
+	fdesc->fchan = fchan;
+	fdesc->n_nodes = sg_len;
+	for (i = 0; i < sg_len; i++) {
+		fdesc->node[i].desc = dma_pool_alloc(fchan->node_pool,
+				GFP_NOWAIT, &fdesc->node[i].pdesc);
+		if (!fdesc->node[i].desc)
+			goto err;
+	}
+	return fdesc;
+
+err:
+	while (--i >= 0)
+		dma_pool_free(fchan->node_pool, fdesc->node[i].desc,
+			      fdesc->node[i].pdesc);
+	kfree(fdesc);
+	return NULL;
+}
+
+static int st_fdma_alloc_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	if (fchan->cfg.type == ST_FDMA_TYPE_FREE_RUN) {
+		fchan->dreq_line = 0;
+	} else {
+		fchan->dreq_line = st_fdma_dreq_get(fchan);
+		if (IS_ERR_VALUE(fchan->dreq_line))
+			return -EINVAL;
+	}
+
+	/* Create the dma pool for descriptor allocation */
+	fchan->node_pool = dmam_pool_create(dev_name(&chan->dev->device),
+					    fchan->fdev->dev,
+					    sizeof(struct st_fdma_hw_node),
+					    __alignof__(struct st_fdma_hw_node),
+					    0);
+
+	if (!fchan->node_pool) {
+		dev_err(fchan->fdev->dev, "unable to allocate desc pool\n");
+		return -ENOMEM;
+	}
+
+	dev_dbg(fchan->fdev->dev, "alloc ch_id:%d type:%d\n",
+		fchan->vchan.chan.chan_id, fchan->cfg.type);
+
+	return 0;
+}
+
+static void st_fdma_free_chan_res(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	unsigned long flags;
+	LIST_HEAD(head);
+
+	dev_dbg(fchan->fdev->dev, "freeing chan:%d\n",
+		fchan->vchan.chan.chan_id);
+
+	if (fchan->cfg.type != ST_FDMA_TYPE_FREE_RUN)
+		st_fdma_dreq_put(fchan);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fchan->fdesc = NULL;
+	vchan_get_all_descriptors(&fchan->vchan, &head);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	dma_pool_destroy(fchan->node_pool);
+	fchan->node_pool = NULL;
+	memset(&fchan->cfg, 0, sizeof(struct st_fdma_cfg));
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_memcpy(
+	struct dma_chan *chan,	dma_addr_t dst, dma_addr_t src,
+	size_t len, unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+
+	if (!len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!atomic_read(&fchan->fdev->fw_loaded)) {
+		dev_err(fchan->fdev->dev, "%s: fdma fw not loaded\n", __func__);
+		return NULL;
+	}
+
+	/* We only require a single descriptor */
+	fdesc = st_fdma_alloc_desc(fchan, 1);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	hw_node = fdesc->node[0].desc;
+	hw_node->next = 0;
+	hw_node->control = NODE_CTRL_REQ_MAP_FREE_RUN;
+	hw_node->control |= NODE_CTRL_SRC_INCR;
+	hw_node->control |= NODE_CTRL_DST_INCR;
+	hw_node->control |= NODE_CTRL_INT_EON;
+	hw_node->nbytes = len;
+	hw_node->saddr = src;
+	hw_node->daddr = dst;
+	hw_node->generic.length = len;
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static int config_reqctrl(struct st_fdma_chan *fchan)
+{
+	u32 maxburst = 0, addr = 0;
+	enum dma_slave_buswidth width;
+	int ch_id = fchan->vchan.chan.chan_id;
+	struct st_fdma_dev *fdev = fchan->fdev;
+
+	if (fchan->scfg.direction == DMA_DEV_TO_MEM) {
+		fchan->cfg.req_ctrl &= ~REQ_CTRL_WNR;
+		maxburst = fchan->scfg.src_maxburst;
+		width = fchan->scfg.src_addr_width;
+		addr = fchan->scfg.src_addr;
+	} else if (fchan->scfg.direction == DMA_MEM_TO_DEV) {
+		fchan->cfg.req_ctrl |= REQ_CTRL_WNR;
+		maxburst = fchan->scfg.dst_maxburst;
+		width = fchan->scfg.dst_addr_width;
+		addr = fchan->scfg.dst_addr;
+	} else {
+		return -EINVAL;
+	}
+
+	if (width == DMA_SLAVE_BUSWIDTH_1_BYTE)
+		fchan->cfg.req_ctrl |= REQ_CTRL_OPCODE_LD_ST1;
+	else if (width == DMA_SLAVE_BUSWIDTH_2_BYTES)
+		fchan->cfg.req_ctrl |= REQ_CTRL_OPCODE_LD_ST2;
+	else if (width == DMA_SLAVE_BUSWIDTH_4_BYTES)
+		fchan->cfg.req_ctrl |= REQ_CTRL_OPCODE_LD_ST4;
+	else if (width == DMA_SLAVE_BUSWIDTH_8_BYTES)
+		fchan->cfg.req_ctrl |= REQ_CTRL_OPCODE_LD_ST8;
+	else
+		return -EINVAL;
+
+	fchan->cfg.req_ctrl |= REQ_CTRL_NUM_OPS(maxburst-1);
+	dreq_write(fchan, fchan->cfg.req_ctrl, REQ_CTRL);
+
+	fchan->cfg.dev_addr = addr;
+	fchan->cfg.dir = fchan->scfg.direction;
+
+	dev_dbg(fdev->dev, "chan:%d config_reqctrl:%#x req_ctrl:%#x\n",
+		ch_id, addr, fchan->cfg.req_ctrl);
+
+	return 0;
+}
+
+static void fill_hw_node(struct st_fdma_hw_node *hw_node,
+			struct st_fdma_chan *fchan,
+			enum dma_transfer_direction direction)
+{
+
+	if (direction == DMA_MEM_TO_DEV) {
+		hw_node->control |= NODE_CTRL_SRC_INCR;
+		hw_node->control |= NODE_CTRL_DST_STATIC;
+		hw_node->daddr = fchan->cfg.dev_addr;
+	} else {
+		hw_node->control |= NODE_CTRL_SRC_STATIC;
+		hw_node->control |= NODE_CTRL_DST_INCR;
+		hw_node->saddr = fchan->cfg.dev_addr;
+	}
+	hw_node->generic.sstride = 0;
+	hw_node->generic.dstride = 0;
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_dma_cyclic(
+		struct dma_chan *chan, dma_addr_t buf_addr, size_t len,
+		size_t period_len, enum dma_transfer_direction direction,
+		unsigned long flags)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	int sg_len, i;
+
+	if (!chan || !len || !period_len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!atomic_read(&fchan->fdev->fw_loaded)) {
+		dev_err(fchan->fdev->dev, "%s: fdma fw not loaded\n", __func__);
+		return NULL;
+	}
+
+	if (!is_slave_direction(direction)) {
+		dev_err(fchan->fdev->dev, "bad direction?\n");
+		return NULL;
+	}
+
+	if (!config_reqctrl(fchan)) {
+		dev_err(fchan->fdev->dev, "bad width or direction\n");
+		return NULL;
+	}
+
+	/* the buffer length must be a multiple of period_len */
+	if (len % period_len != 0) {
+		dev_err(fchan->fdev->dev, "len is not multiple of period\n");
+		return NULL;
+	}
+
+	sg_len = len / period_len;
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = true;
+
+	for (i = 0; i < sg_len; i++) {
+		struct st_fdma_hw_node *hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+
+		hw_node->control = NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+		hw_node->control |= NODE_CTRL_INT_EON;
+
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = buf_addr + (i * period_len);
+		else
+			hw_node->daddr = buf_addr + (i * period_len);
+
+		hw_node->nbytes = period_len;
+		hw_node->generic.length = period_len;
+	}
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static struct dma_async_tx_descriptor *st_fdma_prep_slave_sg(
+		struct dma_chan *chan, struct scatterlist *sgl,
+		unsigned int sg_len, enum dma_transfer_direction direction,
+		unsigned long flags, void *context)
+{
+	struct st_fdma_chan *fchan;
+	struct st_fdma_desc *fdesc;
+	struct st_fdma_hw_node *hw_node;
+	struct scatterlist *sg;
+	int i;
+
+	if (!chan || !sgl || !sg_len)
+		return NULL;
+
+	fchan = to_st_fdma_chan(chan);
+
+	if (!atomic_read(&fchan->fdev->fw_loaded)) {
+		dev_err(fchan->fdev->dev, "%s: fdma fw not loaded\n", __func__);
+		return NULL;
+	}
+
+	if (!is_slave_direction(direction)) {
+		dev_err(fchan->fdev->dev, "bad direction?\n");
+		return NULL;
+	}
+
+	fdesc = st_fdma_alloc_desc(fchan, sg_len);
+	if (!fdesc) {
+		dev_err(fchan->fdev->dev, "no memory for desc\n");
+		return NULL;
+	}
+
+	fdesc->iscyclic = false;
+
+	for_each_sg(sgl, sg, sg_len, i) {
+		hw_node = fdesc->node[i].desc;
+
+		hw_node->next = fdesc->node[(i + 1) % sg_len].pdesc;
+		hw_node->control = NODE_CTRL_REQ_MAP_DREQ(fchan->dreq_line);
+
+		fill_hw_node(hw_node, fchan, direction);
+
+		if (direction == DMA_MEM_TO_DEV)
+			hw_node->saddr = sg_dma_address(sg);
+		else
+			hw_node->daddr = sg_dma_address(sg);
+
+		hw_node->nbytes = sg_dma_len(sg);
+		hw_node->generic.length = sg_dma_len(sg);
+	}
+
+	/* interrupt at end of last node */
+	hw_node->control |= NODE_CTRL_INT_EON;
+
+	return vchan_tx_prep(&fchan->vchan, &fdesc->vdesc, flags);
+}
+
+static size_t st_fdma_desc_residue(struct st_fdma_chan *fchan,
+				   struct virt_dma_desc *vdesc,
+				   bool in_progress)
+{
+	struct st_fdma_desc *fdesc = fchan->fdesc;
+	size_t residue = 0;
+	dma_addr_t cur_addr = 0;
+	int i;
+
+	if (in_progress) {
+		cur_addr = fchan_read(fchan, CH_CMD);
+		cur_addr &= FDMA_CH_CMD_DATA_MASK;
+	}
+
+	for (i = fchan->fdesc->n_nodes - 1 ; i >= 0; i--) {
+		if (cur_addr == fdesc->node[i].pdesc) {
+			residue += fnode_read(fchan, CNTN);
+			break;
+		}
+		residue += fdesc->node[i].desc->nbytes;
+	}
+
+	return residue;
+}
+
+static enum dma_status st_fdma_tx_status(struct dma_chan *chan,
+					 dma_cookie_t cookie,
+					 struct dma_tx_state *txstate)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	struct virt_dma_desc *vd;
+	enum dma_status ret;
+	unsigned long flags;
+
+	ret = dma_cookie_status(chan, cookie, txstate);
+	if (ret == DMA_COMPLETE)
+		return ret;
+
+	if (!txstate)
+		return fchan->status;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	vd = vchan_find_desc(&fchan->vchan, cookie);
+	if (fchan->fdesc && cookie == fchan->fdesc->vdesc.tx.cookie)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, true);
+	else if (vd)
+		txstate->residue = st_fdma_desc_residue(fchan, vd, false);
+	else
+		txstate->residue = 0;
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return fchan->status;
+}
+
+static void st_fdma_issue_pending(struct dma_chan *chan)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	unsigned long flags;
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+
+	if (vchan_issue_pending(&fchan->vchan) && !fchan->fdesc)
+		st_fdma_xfer_desc(fchan);
+
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+}
+
+static int st_fdma_pause(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "pause chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc)
+		fdma_write(fchan->fdev, cmd, CMD_SET);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_resume(struct dma_chan *chan)
+{
+	unsigned long flags;
+	unsigned long val;
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+
+	dev_dbg(fchan->fdev->dev, "resume chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	if (fchan->fdesc) {
+		val = fchan_read(fchan, CH_CMD);
+		val &= FDMA_CH_CMD_DATA_MASK;
+		fchan_write(fchan, val, CH_CMD);
+	}
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+
+	return 0;
+}
+
+static int st_fdma_terminate_all(struct dma_chan *chan)
+{
+	unsigned long flags;
+	LIST_HEAD(head);
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	int ch_id = fchan->vchan.chan.chan_id;
+	unsigned long cmd = FDMA_CMD_PAUSE(ch_id);
+
+	dev_dbg(fchan->fdev->dev, "terminate chan:%d\n", ch_id);
+
+	spin_lock_irqsave(&fchan->vchan.lock, flags);
+	fdma_write(fchan->fdev, cmd, CMD_SET);
+	fchan->fdesc = NULL;
+	vchan_get_all_descriptors(&fchan->vchan, &head);
+	spin_unlock_irqrestore(&fchan->vchan.lock, flags);
+	vchan_dma_desc_free_list(&fchan->vchan, &head);
+
+	return 0;
+}
+
+static int st_fdma_slave_config(struct dma_chan *chan,
+				struct dma_slave_config *slave_cfg)
+{
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+	memcpy(&fchan->cfg, slave_cfg, sizeof(fchan->cfg));
+	return 0;
+}
+
+static const struct st_fdma_ram fdma_mpe31_mem[] = {
+	{ .name = "dmem", .offset = 0x10000, .size = 0x3000 },
+	{ .name = "imem", .offset = 0x18000, .size = 0x8000 },
+};
+
+static const struct st_fdma_driverdata fdma_mpe31_stih407 = {
+	.fdma_mem = fdma_mpe31_mem,
+	.num_mem = ARRAY_SIZE(fdma_mpe31_mem),
+	.name = "STiH407",
+};
+
+static const struct of_device_id st_fdma_match[] = {
+	{ .compatible = "st,stih407-fdma-mpe31", .data = &fdma_mpe31_stih407 },
+	{},
+};
+MODULE_DEVICE_TABLE(of, st_fdma_match);
+
+static struct st_fdma_platform_data *
+st_fdma_parse_dt(struct platform_device *pdev,
+		const struct st_fdma_driverdata *drvdata)
+{
+	struct device_node *np = pdev->dev.of_node;
+	struct st_fdma_platform_data *pdata;
+	int ret;
+
+	if (!np)
+		goto err;
+
+	pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
+	if (!pdata)
+		goto err;
+
+	ret = of_property_read_u32(np, "dma-channels", &pdata->nr_channels);
+	if (ret)
+		goto err;
+
+	ret = of_property_read_u32(np, "st,fdma-id", &pdata->id);
+	if (ret)
+		goto err;
+
+	snprintf(pdata->fw_name, FW_NAME_SIZE, "fdma_%s_%d.elf",
+		drvdata->name, pdata->id);
+
+	return pdata;
+
+err:
+	return NULL;
+}
+#define FDMA_DMA_BUSWIDTHS	(BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_3_BYTES) | \
+				 BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int st_fdma_probe(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev;
+	const struct of_device_id *match;
+	struct device_node *np = pdev->dev.of_node;
+	const struct st_fdma_driverdata *drvdata;
+	const struct st_fdma_platform_data *pdata;
+	int irq, ret, i;
+
+	match = of_match_device((st_fdma_match), &pdev->dev);
+	if (!match || !match->data) {
+		dev_err(&pdev->dev, "No device match found\n");
+		return -ENODEV;
+	}
+
+	drvdata = match->data;
+
+	pdata = st_fdma_parse_dt(pdev, drvdata);
+	if (!pdata) {
+		dev_err(&pdev->dev, "unable to find platform data\n");
+		return -EINVAL;
+	}
+
+	fdev = devm_kzalloc(&pdev->dev, sizeof(*fdev), GFP_KERNEL);
+	if (!fdev)
+		return -ENOMEM;
+
+	fdev->chans = devm_kzalloc(&pdev->dev,
+				   pdata->nr_channels
+				   * sizeof(struct st_fdma_chan), GFP_KERNEL);
+	if (!fdev->chans)
+		return -ENOMEM;
+
+	fdev->dev = &pdev->dev;
+	fdev->drvdata = drvdata;
+	fdev->pdata = pdata;
+	platform_set_drvdata(pdev, fdev);
+
+	fdev->io_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	fdev->io_base = devm_ioremap_resource(&pdev->dev, fdev->io_res);
+	if (IS_ERR(fdev->io_base))
+		return PTR_ERR(fdev->io_base);
+
+	irq = platform_get_irq(pdev, 0);
+	if (irq < 0) {
+		dev_err(&pdev->dev, "Failed to get irq resource\n");
+		return -EINVAL;
+	}
+
+	ret = devm_request_irq(&pdev->dev, irq, st_fdma_irq_handler, 0,
+			       dev_name(&pdev->dev), fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to request irq\n");
+		goto err;
+	}
+
+	ret = st_fdma_clk_get(fdev);
+	if (ret)
+		goto err;
+
+	ret = st_fdma_clk_enable(fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to enable clocks\n");
+		goto err_clk;
+	}
+
+	/* Initialise list of FDMA channels */
+	INIT_LIST_HEAD(&fdev->dma_device.channels);
+	for (i = 0; i < fdev->pdata->nr_channels; i++) {
+		struct st_fdma_chan *fchan = &fdev->chans[i];
+
+		fchan->fdev = fdev;
+		fchan->vchan.desc_free = st_fdma_free_desc;
+		vchan_init(&fchan->vchan, &fdev->dma_device);
+	}
+
+	/* Initialise the FDMA dreq (reserve 0 & 31 for FDMA use) */
+	fdev->dreq_mask = BIT(0) | BIT(31);
+
+	dma_cap_set(DMA_SLAVE, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_CYCLIC, fdev->dma_device.cap_mask);
+	dma_cap_set(DMA_MEMCPY, fdev->dma_device.cap_mask);
+
+	fdev->dma_device.dev = &pdev->dev;
+	fdev->dma_device.device_alloc_chan_resources = st_fdma_alloc_chan_res;
+	fdev->dma_device.device_free_chan_resources = st_fdma_free_chan_res;
+	fdev->dma_device.device_prep_dma_cyclic	= st_fdma_prep_dma_cyclic;
+	fdev->dma_device.device_prep_slave_sg = st_fdma_prep_slave_sg;
+	fdev->dma_device.device_prep_dma_memcpy = st_fdma_prep_dma_memcpy;
+	fdev->dma_device.device_tx_status = st_fdma_tx_status;
+	fdev->dma_device.device_issue_pending = st_fdma_issue_pending;
+	fdev->dma_device.device_terminate_all = st_fdma_terminate_all;
+	fdev->dma_device.device_config = st_fdma_slave_config;
+	fdev->dma_device.device_pause = st_fdma_pause;
+	fdev->dma_device.device_resume = st_fdma_resume;
+
+	fdev->dma_device.src_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.dst_addr_widths = FDMA_DMA_BUSWIDTHS;
+	fdev->dma_device.directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+	fdev->dma_device.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
+
+	ret = dma_async_device_register(&fdev->dma_device);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to register DMA device\n");
+		goto err_clk;
+	}
+
+	ret = of_dma_controller_register(np, st_fdma_of_xlate, fdev);
+	if (ret) {
+		dev_err(&pdev->dev, "Failed to register controller\n");
+		goto err_dma_dev;
+	}
+
+	dev_info(&pdev->dev, "ST FDMA engine driver, irq:%d\n", irq);
+
+	return 0;
+
+err_dma_dev:
+	dma_async_device_unregister(&fdev->dma_device);
+err_clk:
+	st_fdma_clk_disable(fdev);
+err:
+	return ret;
+}
+
+static int st_fdma_remove(struct platform_device *pdev)
+{
+	struct st_fdma_dev *fdev = platform_get_drvdata(pdev);
+
+	wait_for_completion(&fdev->fw_ack);
+
+	st_fdma_clk_disable(fdev);
+
+	return 0;
+}
+
+static struct platform_driver st_fdma_platform_driver = {
+	.driver = {
+		.name = "st-fdma",
+		.of_match_table = st_fdma_match,
+	},
+	.probe = st_fdma_probe,
+	.remove = st_fdma_remove,
+};
+module_platform_driver(st_fdma_platform_driver);
+
+bool st_fdma_filter_fn(struct dma_chan *chan, void *param)
+{
+	struct st_fdma_cfg *config = param;
+	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
+
+	if (!param)
+		return false;
+
+	if (fchan->fdev->dma_device.dev->of_node != config->of_node)
+		return false;
+
+	fchan->cfg = *config;
+
+	return true;
+}
+
+MODULE_LICENSE("GPL v2");
+MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
+MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");
-- 
1.9.1

Re: [PATCH v2 4/9] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Arnd Bergmann]

On Friday 11 September 2015 15:14:26 Peter Griffin wrote:
> +
> +#include "st_fdma.h"

Just move the contents of that file here, no other driver should
be including it.

> +static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
> +					 struct of_dma *ofdma)
> +{
> +	struct st_fdma_dev *fdev = ofdma->of_dma_data;
> +	struct st_fdma_cfg cfg;
> +
> +	if (dma_spec->args_count < 1)
> +		return NULL;
> +
> +	cfg.of_node = dma_spec->np;
> +	cfg.req_line = dma_spec->args[0];
> +	cfg.req_ctrl = 0;
> +	cfg.type = ST_FDMA_TYPE_FREE_RUN;
> +
> +	if (dma_spec->args_count > 1)
> +		cfg.req_ctrl = dma_spec->args[1] & REQ_CTRL_CFG_MASK;
> +
> +	if (dma_spec->args_count > 2)
> +		cfg.type = dma_spec->args[2];

The binding mandates #dma-cells=<3>, so you can just return an error
otherwise.

> +	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#x\n",
> +		cfg.req_line, cfg.type, cfg.req_ctrl);
> +
> +	return dma_request_channel(fdev->dma_device.cap_mask,
> +			st_fdma_filter_fn, &cfg);
> +}

Why this indirection? You should be able to just use
dma_get_any_slave_channel() to get the first available channel and
then configure it the same way that the filter function does.

> +bool st_fdma_filter_fn(struct dma_chan *chan, void *param)
> +{
> +	struct st_fdma_cfg *config = param;
> +	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
> +
> +	if (!param)
> +		return false;
> +
> +	if (fchan->fdev->dma_device.dev->of_node != config->of_node)
> +		return false;
> +
> +	fchan->cfg = *config;
> +
> +	return true;
> +}

Please drop this until there is a board file that references the
function. Otherwise it's just dead code. I assume there are some
users in arch/sh/ in a private tree?

	Arnd

Re: [PATCH v2 4/9] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Peter Griffin]

Hi Arnd,

Thanks for reviewing.

On Fri, 11 Sep 2015, Arnd Bergmann wrote:

> On Friday 11 September 2015 15:14:26 Peter Griffin wrote:
> > +
> > +#include "st_fdma.h"
> 
> Just move the contents of that file here, no other driver should
> be including it.

There is another file st_fdma_xbar.c which will be upstreamed shortly
which uses some parts of this header. It was originally part of the
v1 series here: -
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/355069.html

But I removed it from subsequent submissions as it needs to be re-worked
to use some of the new xbar functionality recently added by TI.

However large parts probably aren't required by xbar, and could be
moved into the c file, so I will move those parts in the next submission.

> 
> > +static struct dma_chan *st_fdma_of_xlate(struct of_phandle_args *dma_spec,
> > +					 struct of_dma *ofdma)
> > +{
> > +	struct st_fdma_dev *fdev = ofdma->of_dma_data;
> > +	struct st_fdma_cfg cfg;
> > +
> > +	if (dma_spec->args_count < 1)
> > +		return NULL;
> > +
> > +	cfg.of_node = dma_spec->np;
> > +	cfg.req_line = dma_spec->args[0];
> > +	cfg.req_ctrl = 0;
> > +	cfg.type = ST_FDMA_TYPE_FREE_RUN;
> > +
> > +	if (dma_spec->args_count > 1)
> > +		cfg.req_ctrl = dma_spec->args[1] & REQ_CTRL_CFG_MASK;
> > +
> > +	if (dma_spec->args_count > 2)
> > +		cfg.type = dma_spec->args[2];
> 
> The binding mandates #dma-cells=<3>, so you can just return an error
> otherwise.

Ok will fix in next submission
> 
> > +	dev_dbg(fdev->dev, "xlate req_line:%d type:%d req_ctrl:%#x\n",
> > +		cfg.req_line, cfg.type, cfg.req_ctrl);
> > +
> > +	return dma_request_channel(fdev->dma_device.cap_mask,
> > +			st_fdma_filter_fn, &cfg);
> > +}
> 
> Why this indirection? You should be able to just use
> dma_get_any_slave_channel() to get the first available channel and
> then configure it the same way that the filter function does.

Ok I will look at using this API instead of dma_request_channel
in the next submission.

> 
> > +bool st_fdma_filter_fn(struct dma_chan *chan, void *param)
> > +{
> > +	struct st_fdma_cfg *config = param;
> > +	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
> > +
> > +	if (!param)
> > +		return false;
> > +
> > +	if (fchan->fdev->dma_device.dev->of_node != config->of_node)
> > +		return false;
> > +
> > +	fchan->cfg = *config;
> > +
> > +	return true;
> > +}
> 
> Please drop this until there is a board file that references the
> function. Otherwise it's just dead code. I assume there are some
> users in arch/sh/ in a private tree?

I'll drop this in the next submission. There aren't any users I can
see in the private tree. This function is currently only used by
dma_reuest_channel above, so won't be required if we move over to
using dma_get_any_slave_channel().

regards,

Peter.
--
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

Re: [PATCH v2 4/9] dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support

[Vinod Koul]

On Fri, Sep 11, 2015 at 03:14:26PM +0100, Peter Griffin wrote:

> +static char *fdma_clk_name[CLK_MAX_NUM] = {
> +	[CLK_SLIM]	= "fdma_slim",
> +	[CLK_HI]	= "fdma_hi",
> +	[CLK_LOW]	= "fdma_low",
> +	[CLK_IC]	= "fdma_ic",
> +};

why do we want to have this sort of data in kernel, we should get the clocks
from DT here

> +static int config_reqctrl(struct st_fdma_chan *fchan)
> +{
> +	u32 maxburst = 0, addr = 0;
> +	enum dma_slave_buswidth width;
> +	int ch_id = fchan->vchan.chan.chan_id;
> +	struct st_fdma_dev *fdev = fchan->fdev;
> +
> +	if (fchan->scfg.direction == DMA_DEV_TO_MEM) {
> +		fchan->cfg.req_ctrl &= ~REQ_CTRL_WNR;
> +		maxburst = fchan->scfg.src_maxburst;
> +		width = fchan->scfg.src_addr_width;
> +		addr = fchan->scfg.src_addr;
> +	} else if (fchan->scfg.direction == DMA_MEM_TO_DEV) {
> +		fchan->cfg.req_ctrl |= REQ_CTRL_WNR;
> +		maxburst = fchan->scfg.dst_maxburst;
> +		width = fchan->scfg.dst_addr_width;
> +		addr = fchan->scfg.dst_addr;

This raises red flags, why do we have direction in channel, and where is
this set. Direction belong to a descriptor and you are supposed to use
direction from prep_ calls!


> +	if (!is_slave_direction(direction)) {
> +		dev_err(fchan->fdev->dev, "bad direction?\n");
> +		return NULL;
> +	}
> +
> +	if (!config_reqctrl(fchan)) {
> +		dev_err(fchan->fdev->dev, "bad width or direction\n");

would make sense to print proper error in called fn

> +static enum dma_status st_fdma_tx_status(struct dma_chan *chan,
> +					 dma_cookie_t cookie,
> +					 struct dma_tx_state *txstate)
> +{
> +	struct st_fdma_chan *fchan = to_st_fdma_chan(chan);
> +	struct virt_dma_desc *vd;
> +	enum dma_status ret;
> +	unsigned long flags;
> +
> +	ret = dma_cookie_status(chan, cookie, txstate);
> +	if (ret == DMA_COMPLETE)
> +		return ret;
> +
> +	if (!txstate)
> +		return fchan->status;

why channel status and not cookie status ?

> +static const struct st_fdma_ram fdma_mpe31_mem[] = {
> +	{ .name = "dmem", .offset = 0x10000, .size = 0x3000 },
> +	{ .name = "imem", .offset = 0x18000, .size = 0x8000 },
> +};

why aren't these coming from DT ?

> +MODULE_LICENSE("GPL v2");
> +MODULE_DESCRIPTION("STMicroelectronics FDMA engine driver");
> +MODULE_AUTHOR("Ludovic.barre <Ludovic.barre@st.com>");

No MODULE_ALIAS ?

-- 
~Vinod

[PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Peter Griffin]

These nodes are required to get the fdma driver working
on STiH407 based silicon.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
index 838b812..da07474b 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -565,5 +565,56 @@
 						  <&phy_port2 PHY_TYPE_USB3>;
 			};
 		};
+
+		fdma0: fdma0-audio@8e20000 {
+			compatible = "st,stih407-fdma-mpe31";
+			reg = <0x8e20000 0x20000>;
+			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			st,fdma-id = <0>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			clock-names = "fdma_slim",
+				      "fdma_hi",
+				      "fdma_low",
+				      "fdma_ic";
+		};
+
+		fdma1: fdma1-app@8e40000 {
+			compatible = "st,stih407-fdma-mpe31";
+			reg = <0x8e40000 0x20000>;
+			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			st,fdma-id = <1>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			clock-names = "fdma_slim",
+				      "fdma_hi",
+				      "fdma_low",
+				      "fdma_ic";
+		};
+
+		fdma2: fdma2-free_running@8e60000 {
+			compatible = "st,stih407-fdma-mpe31";
+			reg = <0x8e60000 0x20000>;
+			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
+			dma-channels = <16>;
+			#dma-cells = <3>;
+			st,fdma-id = <2>;
+			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+				 <&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
+				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
+			clock-names = "fdma_slim",
+				      "fdma_hi",
+				      "fdma_low",
+				      "fdma_ic";
+		};
 	};
 };
-- 
1.9.1

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Lee Jones]

On Fri, 11 Sep 2015, Peter Griffin wrote:

> These nodes are required to get the fdma driver working
> on STiH407 based silicon.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> index 838b812..da07474b 100644
> --- a/arch/arm/boot/dts/stih407-family.dtsi
> +++ b/arch/arm/boot/dts/stih407-family.dtsi
> @@ -565,5 +565,56 @@
>  						  <&phy_port2 PHY_TYPE_USB3>;
>  			};
>  		};
> +
> +		fdma0: fdma0-audio@8e20000 {

I'm not familiar with the FDMA driver, so can't comment knowledgeably,
but the <dev> part of <dev>@<base_address> should only describe the
type of hardware.  I believe in this case it should just be
dma@08e20000.  Also notice the leading zero in the address, which I
believe mitigates possible confusion.  Then you be more specific with
the label, so something like 'fdma-audio' seems appropriate here.

> +			compatible = "st,stih407-fdma-mpe31";
> +			reg = <0x8e20000 0x20000>;

I personally find padding up to 32bits helpful in the addresses.

> +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			st,fdma-id = <0>;

We usually shy away from ID properties.  What is it required for in
this case?

> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			clock-names = "fdma_slim",
> +				      "fdma_hi",
> +				      "fdma_low",
> +				      "fdma_ic";
> +		};
> +
> +		fdma1: fdma1-app@8e40000 {
> +			compatible = "st,stih407-fdma-mpe31";
> +			reg = <0x8e40000 0x20000>;
> +			interrupts = <GIC_SPI 7 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			st,fdma-id = <1>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				 <&clk_s_c0_flexgen CLK_TX_ICN_DMU>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			clock-names = "fdma_slim",
> +				      "fdma_hi",
> +				      "fdma_low",
> +				      "fdma_ic";
> +		};
> +
> +		fdma2: fdma2-free_running@8e60000 {
> +			compatible = "st,stih407-fdma-mpe31";
> +			reg = <0x8e60000 0x20000>;
> +			interrupts = <GIC_SPI 9 IRQ_TYPE_NONE>;
> +			dma-channels = <16>;
> +			#dma-cells = <3>;
> +			st,fdma-id = <2>;
> +			clocks = <&clk_s_c0_flexgen CLK_FDMA>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>,
> +				 <&clk_s_c0_flexgen CLK_TX_ICN_DISP_0>,
> +				 <&clk_s_c0_flexgen CLK_EXT2F_A9>;
> +			clock-names = "fdma_slim",
> +				      "fdma_hi",
> +				      "fdma_low",
> +				      "fdma_ic";
> +		};
>  	};
>  };

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Peter Griffin]

Hi Lee,

On Fri, 11 Sep 2015, Lee Jones wrote:

> On Fri, 11 Sep 2015, Peter Griffin wrote:
> 
> > These nodes are required to get the fdma driver working
> > on STiH407 based silicon.
> > 
> > Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> >  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > index 838b812..da07474b 100644
> > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > @@ -565,5 +565,56 @@
> >  						  <&phy_port2 PHY_TYPE_USB3>;
> >  			};
> >  		};
> > +
> > +		fdma0: fdma0-audio@8e20000 {
> 
> I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> but the <dev> part of <dev>@<base_address> should only describe the
> type of hardware.  I believe in this case it should just be
> dma@08e20000.  Also notice the leading zero in the address, which I
> believe mitigates possible confusion.  Then you be more specific with
> the label, so something like 'fdma-audio' seems appropriate here.

Ok, can change to that format in v3.

> 
> > +			compatible = "st,stih407-fdma-mpe31";
> > +			reg = <0x8e20000 0x20000>;
> 
> I personally find padding up to 32bits helpful in the addresses.

None of the stih407-family nodes I can see have this padding, including
the ones merged by you.

> 
> > +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> > +			dma-channels = <16>;
> > +			#dma-cells = <3>;
> > +			st,fdma-id = <0>;
> 
> We usually shy away from ID properties.  What is it required for in
> this case?

Yes Rob did already mention that over here, see my reply at the bottom
http://www.spinics.net/lists/devicetree/msg92529.html.

However I can't think of any other useful properties we could add
to derive this information. The fdma controller number is used
by the driver to generate a unique firmware filename.

regards,

Peter.
--
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

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Lee Jones]

On Fri, 11 Sep 2015, Peter Griffin wrote:
> On Fri, 11 Sep 2015, Lee Jones wrote:
> > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > 
> > > These nodes are required to get the fdma driver working
> > > on STiH407 based silicon.
> > > 
> > > Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > ---
> > >  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
> > >  1 file changed, 51 insertions(+)
> > > 
> > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > index 838b812..da07474b 100644
> > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > @@ -565,5 +565,56 @@
> > >  						  <&phy_port2 PHY_TYPE_USB3>;
> > >  			};
> > >  		};
> > > +
> > > +		fdma0: fdma0-audio@8e20000 {
> > 
> > I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> > but the <dev> part of <dev>@<base_address> should only describe the
> > type of hardware.  I believe in this case it should just be
> > dma@08e20000.  Also notice the leading zero in the address, which I
> > believe mitigates possible confusion.  Then you be more specific with
> > the label, so something like 'fdma-audio' seems appropriate here.
> 
> Ok, can change to that format in v3.
> 
> > 
> > > +			compatible = "st,stih407-fdma-mpe31";
> > > +			reg = <0x8e20000 0x20000>;
> > 
> > I personally find padding up to 32bits helpful in the addresses.
> 
> None of the stih407-family nodes I can see have this padding, including
> the ones merged by you.

Nither of these two facts mean it's correct.

I'm happy to write a patch to correct them all.

Bear in mind that this isn't a hard and fast rule.  Both work and are
legal.  I just think the padding is more consistent.

> > > +			interrupts = <GIC_SPI 5 IRQ_TYPE_NONE>;
> > > +			dma-channels = <16>;
> > > +			#dma-cells = <3>;
> > > +			st,fdma-id = <0>;
> > 
> > We usually shy away from ID properties.  What is it required for in
> > this case?
> 
> Yes Rob did already mention that over here, see my reply at the bottom
> http://www.spinics.net/lists/devicetree/msg92529.html.
> 
> However I can't think of any other useful properties we could add
> to derive this information. The fdma controller number is used
> by the driver to generate a unique firmware filename.

Who chooses the naming scheme of the firmware binary?

Is there any reason they can't be:

  fdma_STiH407_audio.elf
  fdma_STiH407_app.elf
  fdma_STiH407_free_running.elf

Then you can have a different compatible for each.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Peter Griffin]

Hi Lee,

On Fri, 11 Sep 2015, Lee Jones wrote:

> On Fri, 11 Sep 2015, Peter Griffin wrote:
> > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > 
> > > > These nodes are required to get the fdma driver working
> > > > on STiH407 based silicon.
> > > > 
> > > > Signed-off-by: Peter Griffin <peter.griffin-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > > > ---
> > > >  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 51 insertions(+)
> > > > 
> > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > > index 838b812..da07474b 100644
> > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > @@ -565,5 +565,56 @@
> > > >  						  <&phy_port2 PHY_TYPE_USB3>;
> > > >  			};
> > > >  		};
> > > > +
> > > > +		fdma0: fdma0-audio@8e20000 {
> > > 
> > > I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> > > but the <dev> part of <dev>@<base_address> should only describe the
> > > type of hardware.  I believe in this case it should just be
> > > dma@08e20000.  Also notice the leading zero in the address, which I
> > > believe mitigates possible confusion.  Then you be more specific with
> > > the label, so something like 'fdma-audio' seems appropriate here.
> > 
> > Ok, can change to that format in v3.
> > 
> > > 
> > > > +			compatible = "st,stih407-fdma-mpe31";
> > > > +			reg = <0x8e20000 0x20000>;
> > > 
> > > I personally find padding up to 32bits helpful in the addresses.
> > 
> > None of the stih407-family nodes I can see have this padding, including
> > the ones merged by you.
> 
> Nither of these two facts mean it's correct.

I thought it was a 'personal' thing. If it is mandated by the spec, then that
is different.

> 
> I'm happy to write a patch to correct them all.

Are you sure your actually correcting anything? Where does it say you
should have a leading zero?

> 
> Bear in mind that this isn't a hard and fast rule.  Both work and are
> legal.  I just think the padding is more consistent.

Surely adding a patch with how the nodes are currently formatted, is more consistent
than adding a patch with padding?

regards,

Peter.

--
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

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Lee Jones]

On Fri, 11 Sep 2015, Peter Griffin wrote:
> On Fri, 11 Sep 2015, Lee Jones wrote:
> > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > > 
> > > > > These nodes are required to get the fdma driver working
> > > > > on STiH407 based silicon.
> > > > > 
> > > > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > > > > ---
> > > > >  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
> > > > >  1 file changed, 51 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > index 838b812..da07474b 100644
> > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > @@ -565,5 +565,56 @@
> > > > >  						  <&phy_port2 PHY_TYPE_USB3>;
> > > > >  			};
> > > > >  		};
> > > > > +
> > > > > +		fdma0: fdma0-audio@8e20000 {
> > > > 
> > > > I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> > > > but the <dev> part of <dev>@<base_address> should only describe the
> > > > type of hardware.  I believe in this case it should just be
> > > > dma@08e20000.  Also notice the leading zero in the address, which I
> > > > believe mitigates possible confusion.  Then you be more specific with
> > > > the label, so something like 'fdma-audio' seems appropriate here.
> > > 
> > > Ok, can change to that format in v3.
> > > 
> > > > 
> > > > > +			compatible = "st,stih407-fdma-mpe31";
> > > > > +			reg = <0x8e20000 0x20000>;
> > > > 
> > > > I personally find padding up to 32bits helpful in the addresses.
> > > 
> > > None of the stih407-family nodes I can see have this padding, including
> > > the ones merged by you.
> > 
> > Nither of these two facts mean it's correct.
> 
> I thought it was a 'personal' thing. If it is mandated by the spec, then that
> is different.
> 
> > 
> > I'm happy to write a patch to correct them all.
> 
> Are you sure your actually correcting anything? Where does it say you
> should have a leading zero?
> 
> > 
> > Bear in mind that this isn't a hard and fast rule.  Both work and are
> > legal.  I just think the padding is more consistent.
> 
> Surely adding a patch with how the nodes are currently formatted, is more consistent
> than adding a patch with padding?
 
I did mean consistent with the majority of DTS files, rather than just
ours.  There are examples of non-padded values and it's perfectly
legal, but the vast majority of examples do in fact pad their
addresses [see below].  The change is more of a nit than a blocker.

git grep '@0[0-9|a-f]\{7\}' -- arch/arm/boot/dts/
892

git grep '@[0-9|a-f]\{7\} ' -- arch/arm/boot/dts/ | grep -vi sti | \
  grep -vi partition | grep -vi data
140

I'll probably still fix them up and resubmit some patches to bring us
into line with the vast majority.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 7/9] ARM: STi: DT: STiH407: Add FDMA driver dt nodes.

[Peter Griffin]

Hi Lee,

On Fri, 11 Sep 2015, Lee Jones wrote:

> On Fri, 11 Sep 2015, Peter Griffin wrote:
> > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > > On Fri, 11 Sep 2015, Lee Jones wrote:
> > > > > On Fri, 11 Sep 2015, Peter Griffin wrote:
> > > > > 
> > > > > > These nodes are required to get the fdma driver working
> > > > > > on STiH407 based silicon.
> > > > > > 
> > > > > > Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> > > > > > ---
> > > > > >  arch/arm/boot/dts/stih407-family.dtsi | 51 +++++++++++++++++++++++++++++++++++
> > > > > >  1 file changed, 51 insertions(+)
> > > > > > 
> > > > > > diff --git a/arch/arm/boot/dts/stih407-family.dtsi b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > index 838b812..da07474b 100644
> > > > > > --- a/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > +++ b/arch/arm/boot/dts/stih407-family.dtsi
> > > > > > @@ -565,5 +565,56 @@
> > > > > >  						  <&phy_port2 PHY_TYPE_USB3>;
> > > > > >  			};
> > > > > >  		};
> > > > > > +
> > > > > > +		fdma0: fdma0-audio@8e20000 {
> > > > > 
> > > > > I'm not familiar with the FDMA driver, so can't comment knowledgeably,
> > > > > but the <dev> part of <dev>@<base_address> should only describe the
> > > > > type of hardware.  I believe in this case it should just be
> > > > > dma@08e20000.  Also notice the leading zero in the address, which I
> > > > > believe mitigates possible confusion.  Then you be more specific with
> > > > > the label, so something like 'fdma-audio' seems appropriate here.
> > > > 
> > > > Ok, can change to that format in v3.
> > > > 
> > > > > 
> > > > > > +			compatible = "st,stih407-fdma-mpe31";
> > > > > > +			reg = <0x8e20000 0x20000>;
> > > > > 
> > > > > I personally find padding up to 32bits helpful in the addresses.
> > > > 
> > > > None of the stih407-family nodes I can see have this padding, including
> > > > the ones merged by you.
> > > 
> > > Nither of these two facts mean it's correct.
> > 
> > I thought it was a 'personal' thing. If it is mandated by the spec, then that
> > is different.
> > 
> > > 
> > > I'm happy to write a patch to correct them all.
> > 
> > Are you sure your actually correcting anything? Where does it say you
> > should have a leading zero?
> > 
> > > 
> > > Bear in mind that this isn't a hard and fast rule.  Both work and are
> > > legal.  I just think the padding is more consistent.
> > 
> > Surely adding a patch with how the nodes are currently formatted, is more consistent
> > than adding a patch with padding?
>  
> I did mean consistent with the majority of DTS files, rather than just
> ours.  There are examples of non-padded values and it's perfectly
> legal, but the vast majority of examples do in fact pad their
> addresses [see below].  The change is more of a nit than a blocker.

If its perdectly legal, than I'm personally against changing it.
Mainly because it makes it difficult for git and patch to apply
patches from the vendor kernel on top of the upstream kernel
without manual intervention.

I already ran into this with the recent stih407-pinctrl series
where every patch had to be manually fixed up because we changed
PIO to pio, on every pin definition.

I'm all for changing things where they are actually wrong in the
vendor kernel (such as not having the unit address on the reg property,
or the node name being wrong e.g. fdma to dma-controller etc. But this
doesn't appar to be one of those cases.

regards,

Peter.

[PATCH v2 8/9] MAINTAINERS: Add FDMA driver files to STi section.

[Peter Griffin]

This patch adds the FDMA driver files to the STi
section of the maintainers file.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b60e2b2..b3cdd5b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1504,6 +1504,7 @@ S:	Maintained
 F:	arch/arm/mach-sti/
 F:	arch/arm/boot/dts/sti*
 F:	drivers/clocksource/arm_global_timer.c
+F:	drivers/dma/st_fdma*
 F:	drivers/i2c/busses/i2c-st.c
 F:	drivers/media/rc/st_rc.c
 F:	drivers/mmc/host/sdhci-st.c
-- 
1.9.1

Re: [PATCH v2 8/9] MAINTAINERS: Add FDMA driver files to STi section.

[Lee Jones]

On Fri, 11 Sep 2015, Peter Griffin wrote:

> This patch adds the FDMA driver files to the STi
> section of the maintainers file.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Lee Jones <lee.jones@linaro.org>

> diff --git a/MAINTAINERS b/MAINTAINERS
> index b60e2b2..b3cdd5b 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1504,6 +1504,7 @@ S:	Maintained
>  F:	arch/arm/mach-sti/
>  F:	arch/arm/boot/dts/sti*
>  F:	drivers/clocksource/arm_global_timer.c
> +F:	drivers/dma/st_fdma*
>  F:	drivers/i2c/busses/i2c-st.c
>  F:	drivers/media/rc/st_rc.c
>  F:	drivers/mmc/host/sdhci-st.c

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH v2 9/9] ARM: multi_v7_defconfig: Enable STi FDMA driver

[Peter Griffin]

This DMA controller is found on all STi chipsets.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 5fd8df6..ce3c8c1 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -587,6 +587,7 @@ CONFIG_IMX_DMA=y
 CONFIG_MXS_DMA=y
 CONFIG_DMA_OMAP=y
 CONFIG_XILINX_VDMA=y
+CONFIG_ST_FDMA=y
 CONFIG_STAGING=y
 CONFIG_SENSORS_ISL29018=y
 CONFIG_SENSORS_ISL29028=y
-- 
1.9.1

Re: [PATCH v2 9/9] ARM: multi_v7_defconfig: Enable STi FDMA driver

[Lee Jones]

On Fri, 11 Sep 2015, Peter Griffin wrote:

> This DMA controller is found on all STi chipsets.
> 
> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
> ---
>  arch/arm/configs/multi_v7_defconfig | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Lee Jones <lee.jones@linaro.org>

> diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
> index 5fd8df6..ce3c8c1 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig
> @@ -587,6 +587,7 @@ CONFIG_IMX_DMA=y
>  CONFIG_MXS_DMA=y
>  CONFIG_DMA_OMAP=y
>  CONFIG_XILINX_VDMA=y
> +CONFIG_ST_FDMA=y
>  CONFIG_STAGING=y
>  CONFIG_SENSORS_ISL29018=y
>  CONFIG_SENSORS_ISL29028=y

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog