Re: [PATCH] ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC

2014-08-11 Thread Peter Ujfalusi
On 08/05/2014 07:32 PM, Vinod Koul wrote:
 On Mon, Aug 04, 2014 at 03:26:56PM +0300, Peter Ujfalusi wrote:
 The edma_setup_from_hw() should know about the CC number when parsing the
 CCCFG register - when it reads the register to be precise. The base
 addresses for CCs stored in an array and we need to provide the correct id
 to edma_read() in order to read the correct register.
 
 Just an othognal question:
 
 I still see lot of code for edma in arm/. What is the plan to re/move that
 to dma/

Yes, there's still a big split. The code under arch/arm/common/ provides still
the 'legacy' edma API. This is still used by audio
sound/soc/davinci/davinci-pcm for older daVinci devices (AM335x. AM43xx uses
the edma-pcm).

And it is not that simple to deprecate davinci-pcm: it can use so called
ping-pong mode for audio data transfer. This mode is not possible via
dmaengine AFAIK.
I'm going to check if edma-pcm would work fine instead of the ping-pong mode.
If it does I can remove davinci-pcm and we can start cleaning up the edma code.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-08-04 Thread Peter Ujfalusi
On 08/01/2014 04:34 PM, Peter Ujfalusi wrote:
 Hi,
 
 On 08/01/2014 04:13 PM, Sergei Shtylyov wrote:
 Hello.

 On 08/01/2014 05:02 PM, Peter Ujfalusi wrote:

 I do. We should follow the standard consistently. Why not call the node
 sound-codec?

 Well, there is _zero_ cases when the audio codec node is named as
 sound-codec in linux-next but we have wm, tlv, twl, max 
 etc.

Which only means people don't read the standard (which is referred to on
 http://www.devicetree.org/Device_Tree_Usage, that says the same).

 Yeah, there are few DTS files which have codec as node name.
 So, no, I'm not going to change the node name from tlv320aic3106.

So you prefer following the bad examples to following the standard?
 
 those bad examples are in the tree and they did went through the review
 process (arch, DT and probably alsa). But it is interesting that we do not
 have a single correct node name for audio codecs (probably for other types 
 also).

I have thought about this over the weekend and I would keep the node name for
the codec as it is in the patch.
It is the common practice for audio and it also helps when reading the DT file
to quickly see the audio support on the board. We all use the 'sound' node
name for audio cards and when we use the name of the codec as node name we do
not need to look further in the dts file to see what is the codec in used (and
what/which cpu dai we are using). All this can be seen in the main sound
support node.

 Well, the Moor has done his duty, the Moor can go...
 
 Let's ask the DT maintainers what should be the correct approach and someone
 should go through all the existing DT files and clean them up? People usually
 start reading the code for examples before the standard...
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH] ARM: edma: Fix configuration parsing for SoCs with multiple eDMA3 CC

2014-08-04 Thread Peter Ujfalusi
The edma_setup_from_hw() should know about the CC number when parsing the
CCCFG register - when it reads the register to be precise. The base
addresses for CCs stored in an array and we need to provide the correct id
to edma_read() in order to read the correct register.

Cc: sta...@vger.kernel.org # 3.16
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 88099175fc56..d86771abbf57 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1443,14 +1443,14 @@ void edma_assign_channel_eventq(unsigned channel, enum 
dma_event_q eventq_no)
 EXPORT_SYMBOL(edma_assign_channel_eventq);
 
 static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
- struct edma *edma_cc)
+ struct edma *edma_cc, int cc_id)
 {
int i;
u32 value, cccfg;
s8 (*queue_priority_map)[2];
 
/* Decode the eDMA3 configuration from CCCFG register */
-   cccfg = edma_read(0, EDMA_CCCFG);
+   cccfg = edma_read(cc_id, EDMA_CCCFG);
 
value = GET_NUM_REGN(cccfg);
edma_cc-num_region = BIT(value);
@@ -1464,7 +1464,8 @@ static int edma_setup_from_hw(struct device *dev, struct 
edma_soc_info *pdata,
value = GET_NUM_EVQUE(cccfg);
edma_cc-num_tc = value + 1;
 
-   dev_dbg(dev, eDMA3 HW configuration (cccfg: 0x%08x):\n, cccfg);
+   dev_dbg(dev, eDMA3 CC%d HW configuration (cccfg: 0x%08x):\n, cc_id,
+   cccfg);
dev_dbg(dev, num_region: %u\n, edma_cc-num_region);
dev_dbg(dev, num_channel: %u\n, edma_cc-num_channels);
dev_dbg(dev, num_slot: %u\n, edma_cc-num_slots);
@@ -1684,7 +1685,7 @@ static int edma_probe(struct platform_device *pdev)
return -ENOMEM;
 
/* Get eDMA3 configuration from IP */
-   ret = edma_setup_from_hw(dev, info[j], edma_cc[j]);
+   ret = edma_setup_from_hw(dev, info[j], edma_cc[j], j);
if (ret)
return ret;
 
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 0/6] ARM: DT/davinci: Audio for da850-evm in DT boot

2014-08-01 Thread Peter Ujfalusi
Hi,

Changes since v1:
- fixed the address missmatch for tlv320aic3106 codec (@1b - 18)
- The edma patches has been taken by Vinod, they should be in linux-next soon.

The following series will enable audio via simple card on the board when booted
with DT.

For edma one patch is needed to have working dma:
http://marc.info/?l=linux-omapm=140680159327749w=2

Regards,
Peter
---
Peter Ujfalusi (6):
  ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0
  ARM: DTS: da850: Add node for edma0
  ARM: DTS: da850: Add node for McASP
  ARM: DTS: da850-evm: Enable McASP via DT boot
  ARM: DTS: da850-evm: Add node for tlv320aic3106 codec
  ARM: DTS: da850-evm: Enable audio via simple-card

 arch/arm/boot/dts/da850-evm.dts  | 72 
 arch/arm/boot/dts/da850.dtsi | 19 +++
 arch/arm/mach-davinci/da8xx-dt.c |  1 +
 3 files changed, 92 insertions(+)

-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 2/6] ARM: DTS: da850: Add node for edma0

2014-08-01 Thread Peter Ujfalusi
Add DT node for edma0.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index b695548dbb4e..41ce4e8bf227 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -150,6 +150,12 @@
};
 
};
+   edma0: edma@01c0 {
+   compatible = ti,edma3;
+   reg =   0x0 0x1;
+   interrupts = 11 13 12;
+   #dma-cells = 1;
+   };
serial0: serial@1c42000 {
compatible = ns16550a;
reg = 0x42000 0x100;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 1/6] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0

2014-08-01 Thread Peter Ujfalusi
Add OF_DEV_AUXDATA for mcasp to be able to use clocks.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index ed1928740b5f..f703d82f08a8 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -46,6 +46,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA(ti,davinci_mdio, 0x01e24000, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,davinci-dm6467-emac, 0x01e2, davinci_emac.1,
   NULL),
+   OF_DEV_AUXDATA(ti,da830-mcasp-audio, 0x01d0, davinci-mcasp.0, 
NULL),
{}
 };
 
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-08-01 Thread Peter Ujfalusi
The board uses aic3106 for audio.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 1422c311af4c..41715b495861 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -51,6 +51,19 @@
tps: tps@48 {
reg = 0x48;
};
+   tlv320aic3106: tlv320aic3106@18 {
+   compatible = ti,tlv320aic3106;
+   reg = 0x18;
+   status = okay;
+
+   /* Regulators */
+   IOVDD-supply = vdcdc2_reg;
+   /* Derived from VBAT: Baseboard 3.3V / 1.8V */
+   AVDD-supply = vbat;
+   DRVDD-supply = vbat;
+   DVDD-supply = vbat;
+   };
+
};
wdt: wdt@1c21000 {
status = okay;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 4/6] ARM: DTS: da850-evm: Enable McASP via DT boot

2014-08-01 Thread Peter Ujfalusi
Add pinctrl nodes for the McASP0 pins and configure McASP to the desired
mode for the board.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 1e11e5a5f723..1422c311af4c 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -17,6 +17,18 @@
soc {
pmx_core: pinmux@1c14120 {
status = okay;
+
+   mcasp0_pins: pinmux_mcasp0_pins {
+   pinctrl-single,bits = 
+   /*
+* AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
+* AFSR, AMUTE
+*/
+   0x00 0x 0x
+   /* AXR11, AXR12 */
+   0x04 0x00011000 0x000ff000
+   ;
+   };
};
serial0: serial@1c42000 {
status = okay;
@@ -170,3 +182,21 @@
};
};
 };
+
+mcasp0 {
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = mcasp0_pins;
+
+   op-mode = 0;  /* MCASP_IIS_MODE */
+   tdm-slots = 2;
+   /* 4 serializer */
+   serial-dir =   /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 0 0
+   0 0 0 0
+   0 0 0 1
+   2 0 0 0
+   ;
+   tx-num-evt = 32;
+   rx-num-evt = 32;
+};
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 6/6] ARM: DTS: da850-evm: Enable audio via simple-card

2014-08-01 Thread Peter Ujfalusi
The audio on the board is using McASP - tlv320aic3106 codec and we have
LineIn and LineOut jacks.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41715b495861..4f935ad9f27b 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -52,6 +52,7 @@
reg = 0x48;
};
tlv320aic3106: tlv320aic3106@18 {
+   #sound-dai-cells = 0;
compatible = ti,tlv320aic3106;
reg = 0x18;
status = okay;
@@ -142,6 +143,33 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+   sound {
+   compatible = simple-audio-card;
+   simple-audio-card,name = DA850/OMAP-L138 EVM;
+   simple-audio-card,widgets =
+   Line, Line In,
+   Line, Line Out;
+   simple-audio-card,routing =
+   LINE1L, Line In,
+   LINE1R, Line In,
+   Line Out, LLOUT,
+   Line Out, RLOUT;
+   simple-audio-card,format = dsp_b;
+   simple-audio-card,bitclock-master = link0_codec;
+   simple-audio-card,frame-master = link0_codec;
+   simple-audio-card,bitclock-inversion;
+
+   simple-audio-card,cpu {
+   sound-dai = mcasp0;
+   system-clock-frequency = 24576000;
+   };
+
+   link0_codec: simple-audio-card,codec {
+   sound-dai = tlv320aic3106;
+   system-clock-frequency = 24576000;
+   };
+   };
 };
 
 /include/ tps6507x.dtsi
@@ -197,6 +225,7 @@
 };
 
 mcasp0 {
+   #sound-dai-cells = 0;
status = okay;
pinctrl-names = default;
pinctrl-0 = mcasp0_pins;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 3/6] ARM: DTS: da850: Add node for McASP

2014-08-01 Thread Peter Ujfalusi
Node for mcasp0

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 41ce4e8bf227..0bd98cd00816 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -276,6 +276,19 @@
ti,davinci-gpio-unbanked = 0;
status = disabled;
};
+
+   mcasp0: mcasp@01d0 {
+   compatible = ti,da830-mcasp-audio;
+   reg = 0x10 0x2000,
+ 0x102000 0x40;
+   reg-names = mpu, dat;
+   interrupts = 54;
+   interrupt-names = common;
+   status = disabled;
+   dmas = edma0 1,
+   edma0 0;
+   dma-names = tx, rx;
+   };
};
nand_cs3@6200 {
compatible = ti,davinci-nand;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-08-01 Thread Peter Ujfalusi
On 08/01/2014 03:49 PM, Sergei Shtylyov wrote:
I do. We should follow the standard consistently. Why not call the node
 sound-codec?

Well, there is _zero_ cases when the audio codec node is named as
sound-codec in linux-next but we have wm, tlv, twl, max etc.
Yeah, there are few DTS files which have codec as node name.
So, no, I'm not going to change the node name from tlv320aic3106.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-08-01 Thread Peter Ujfalusi
Hi,

On 08/01/2014 04:13 PM, Sergei Shtylyov wrote:
 Hello.
 
 On 08/01/2014 05:02 PM, Peter Ujfalusi wrote:
 
 I do. We should follow the standard consistently. Why not call the node
 sound-codec?
 
 Well, there is _zero_ cases when the audio codec node is named as
 sound-codec in linux-next but we have wm, tlv, twl, max 
 etc.
 
Which only means people don't read the standard (which is referred to on
 http://www.devicetree.org/Device_Tree_Usage, that says the same).
 
 Yeah, there are few DTS files which have codec as node name.
 So, no, I'm not going to change the node name from tlv320aic3106.
 
So you prefer following the bad examples to following the standard?

those bad examples are in the tree and they did went through the review
process (arch, DT and probably alsa). But it is interesting that we do not
have a single correct node name for audio codecs (probably for other types 
also).

 Well, the Moor has done his duty, the Moor can go...

Let's ask the DT maintainers what should be the correct approach and someone
should go through all the existing DT files and clean them up? People usually
start reading the code for examples before the standard...

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 1/2] dmaengine: edma: Do not change the error code returned from edma_alloc_slot

2014-07-31 Thread Peter Ujfalusi
In case of edma_alloc_slot() failure during probe we should return the error
unchanged to make debugging easier.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 69f1f5250120..2953de0f53f3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1048,7 +1048,7 @@ static int edma_probe(struct platform_device *pdev)
ecc-dummy_slot = edma_alloc_slot(ecc-ctlr, EDMA_SLOT_ANY);
if (ecc-dummy_slot  0) {
dev_err(pdev-dev, Can't allocate PaRAM dummy slot\n);
-   return -EIO;
+   return ecc-dummy_slot;
}
 
dma_cap_zero(ecc-dma_slave.cap_mask);
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 2/2] dmaengine: edma: Do not register second device when booted with DT

2014-07-31 Thread Peter Ujfalusi
DT boot does not yet support more than one edma device. To avoid issues at
runtime we should not register the second device when the kernel is booted
with DT.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2953de0f53f3..d99351361fcb 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -23,6 +23,7 @@
 #include linux/platform_device.h
 #include linux/slab.h
 #include linux/spinlock.h
+#include linux/of.h
 
 #include linux/platform_data/edma.h
 
@@ -1133,7 +1134,7 @@ static int edma_init(void)
}
}
 
-   if (EDMA_CTLRS == 2) {
+   if (!of_have_populated_dt()  EDMA_CTLRS == 2) {
pdev1 = platform_device_register_full(edma_dev_info1);
if (IS_ERR(pdev1)) {
platform_driver_unregister(edma_driver);
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 1/6] ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0

2014-07-31 Thread Peter Ujfalusi
Add OF_DEV_AUXDATA for mcasp to be able to use clocks.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-davinci/da8xx-dt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index ed1928740b5f..f703d82f08a8 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -46,6 +46,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] 
__initdata = {
OF_DEV_AUXDATA(ti,davinci_mdio, 0x01e24000, davinci_mdio.0, NULL),
OF_DEV_AUXDATA(ti,davinci-dm6467-emac, 0x01e2, davinci_emac.1,
   NULL),
+   OF_DEV_AUXDATA(ti,da830-mcasp-audio, 0x01d0, davinci-mcasp.0, 
NULL),
{}
 };
 
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 0/6] ARM: DT/davinci: Audio for da850-evm in DT boot

2014-07-31 Thread Peter Ujfalusi
Hi,

The following series will enable audio via simple card on the board when booted
with DT.

For edma one patch is needed to have working dma:
http://marc.info/?l=linux-omapm=140680159327749w=2

Regards,
Peter
---
Peter Ujfalusi (6):
  ARM: davinci: da8xx-dt: add OF_DEV_AUXDATA entry for mcasp0
  ARM: DTS: da850: Add node for edma0
  ARM: DTS: da850: Add node for McASP
  ARM: DTS: da850-evm: Enable McASP via DT boot
  ARM: DTS: da850-evm: Add node for tlv320aic3106 codec
  ARM: DTS: da850-evm: Enable audio via simple-card

 arch/arm/boot/dts/da850-evm.dts  | 72 
 arch/arm/boot/dts/da850.dtsi | 19 +++
 arch/arm/mach-davinci/da8xx-dt.c |  1 +
 3 files changed, 92 insertions(+)

-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 6/6] ARM: DTS: da850-evm: Enable audio via simple-card

2014-07-31 Thread Peter Ujfalusi
The audio on the board is using McASP - tlv320aic3106 codec and we have
LineIn and LineOut jacks.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index b9ef2be0b145..031117a4a797 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -143,6 +143,33 @@
regulator-max-microvolt = 500;
regulator-boot-on;
};
+
+   sound {
+   compatible = simple-audio-card;
+   simple-audio-card,name = DA850/OMAP-L138 EVM;
+   simple-audio-card,widgets =
+   Line, Line In,
+   Line, Line Out;
+   simple-audio-card,routing =
+   LINE1L, Line In,
+   LINE1R, Line In,
+   Line Out, LLOUT,
+   Line Out, RLOUT;
+   simple-audio-card,format = dsp_b;
+   simple-audio-card,bitclock-master = link0_codec;
+   simple-audio-card,frame-master = link0_codec;
+   simple-audio-card,bitclock-inversion;
+
+   simple-audio-card,cpu {
+   sound-dai = mcasp0;
+   system-clock-frequency = 24576000;
+   };
+
+   link0_codec: simple-audio-card,codec {
+   sound-dai = tlv320aic3106;
+   system-clock-frequency = 24576000;
+   };
+   };
 };
 
 /include/ tps6507x.dtsi
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-07-31 Thread Peter Ujfalusi
The board uses aic3106 for audio.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 09118c72e83f..b9ef2be0b145 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -51,6 +51,20 @@
tps: tps@48 {
reg = 0x48;
};
+   tlv320aic3106: tlv320aic3106@1b {
+   #sound-dai-cells = 0;
+   compatible = ti,tlv320aic3106;
+   reg = 0x18;
+   status = okay;
+
+   /* Regulators */
+   IOVDD-supply = vdcdc2_reg;
+   /* Derived from VBAT: Baseboard 3.3V / 1.8V */
+   AVDD-supply = vbat;
+   DRVDD-supply = vbat;
+   DVDD-supply = vbat;
+   };
+
};
wdt: wdt@1c21000 {
status = okay;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 2/6] ARM: DTS: da850: Add node for edma0

2014-07-31 Thread Peter Ujfalusi
Add DT node for edma0.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index b695548dbb4e..41ce4e8bf227 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -150,6 +150,12 @@
};
 
};
+   edma0: edma@01c0 {
+   compatible = ti,edma3;
+   reg =   0x0 0x1;
+   interrupts = 11 13 12;
+   #dma-cells = 1;
+   };
serial0: serial@1c42000 {
compatible = ns16550a;
reg = 0x42000 0x100;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 4/6] ARM: DTS: da850-evm: Enable McASP via DT boot

2014-07-31 Thread Peter Ujfalusi
Add pinctrl nodes for the McASP0 pins and configure McASP to the desired
mode for the board.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850-evm.dts | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 1e11e5a5f723..09118c72e83f 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -17,6 +17,18 @@
soc {
pmx_core: pinmux@1c14120 {
status = okay;
+
+   mcasp0_pins: pinmux_mcasp0_pins {
+   pinctrl-single,bits = 
+   /*
+* AHCLKX, ACLKX, AFSX, AHCLKR, ACLKR,
+* AFSR, AMUTE
+*/
+   0x00 0x 0x
+   /* AXR11, AXR12 */
+   0x04 0x00011000 0x000ff000
+   ;
+   };
};
serial0: serial@1c42000 {
status = okay;
@@ -170,3 +182,22 @@
};
};
 };
+
+mcasp0 {
+   #sound-dai-cells = 0;
+   status = okay;
+   pinctrl-names = default;
+   pinctrl-0 = mcasp0_pins;
+
+   op-mode = 0;  /* MCASP_IIS_MODE */
+   tdm-slots = 2;
+   /* 4 serializer */
+   serial-dir =   /* 0: INACTIVE, 1: TX, 2: RX */
+   0 0 0 0
+   0 0 0 0
+   0 0 0 1
+   2 0 0 0
+   ;
+   tx-num-evt = 32;
+   rx-num-evt = 32;
+};
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 3/6] ARM: DTS: da850: Add node for McASP

2014-07-31 Thread Peter Ujfalusi
Node for mcasp0

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/boot/dts/da850.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 41ce4e8bf227..0bd98cd00816 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -276,6 +276,19 @@
ti,davinci-gpio-unbanked = 0;
status = disabled;
};
+
+   mcasp0: mcasp@01d0 {
+   compatible = ti,da830-mcasp-audio;
+   reg = 0x10 0x2000,
+ 0x102000 0x40;
+   reg-names = mpu, dat;
+   interrupts = 54;
+   interrupt-names = common;
+   status = disabled;
+   dmas = edma0 1,
+   edma0 0;
+   dma-names = tx, rx;
+   };
};
nand_cs3@6200 {
compatible = ti,davinci-nand;
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 2/6] ARM: DTS: da850: Add node for edma0

2014-07-31 Thread Peter Ujfalusi
On 07/31/2014 05:26 PM, Sergei Shtylyov wrote:
 On 07/31/2014 02:18 PM, Peter Ujfalusi wrote:
 
 Add DT node for edma0.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
   arch/arm/boot/dts/da850.dtsi | 6 ++
   1 file changed, 6 insertions(+)
 
 diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
 index b695548dbb4e..41ce4e8bf227 100644
 --- a/arch/arm/boot/dts/da850.dtsi
 +++ b/arch/arm/boot/dts/da850.dtsi
 @@ -150,6 +150,12 @@
   };

   };
 +edma0: edma@01c0 {
 +compatible = ti,edma3;
 +reg =0x0 0x1;
 
Why the mismatch between the unit-address part of the node name and the
 reg property?

For some reason the whole da850 uses offset from 0x01c0 for the SoC IPs.
The nodes are under 'soc' and that has the ranges attribute.
I do not really like this either.

 
 +interrupts = 11 13 12;
 +#dma-cells = 1;
 +};
 
 WBR, Sergei
 

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 5/6] ARM: DTS: da850-evm: Add node for tlv320aic3106 codec

2014-07-31 Thread Peter Ujfalusi
On 07/31/2014 05:24 PM, Sergei Shtylyov wrote:
 Hello.
 
 On 07/31/2014 02:18 PM, Peter Ujfalusi wrote:
 
 The board uses aic3106 for audio.
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
   arch/arm/boot/dts/da850-evm.dts | 14 ++
   1 file changed, 14 insertions(+)
 
 diff --git a/arch/arm/boot/dts/da850-evm.dts 
 b/arch/arm/boot/dts/da850-evm.dts
 index 09118c72e83f..b9ef2be0b145 100644
 --- a/arch/arm/boot/dts/da850-evm.dts
 +++ b/arch/arm/boot/dts/da850-evm.dts
 @@ -51,6 +51,20 @@
   tps: tps@48 {
   reg = 0x48;
   };
 +tlv320aic3106: tlv320aic3106@1b {
 
The reg property is 0x18, why the unit-address part of a name is
 different?

True, I have lifted the codec part from other dts file and overlooked the
unit-address.
I will resend the series with this fixed.


 Also, the ePAPR standard [1] says:
 
 The name of a node should be somewhat generic, reflecting the function of the
 device and not its precise programming model.

True. This is why the node for the audio support is named as 'sound'. For the
components, like in this case I do not see issue to call the audio codec with
it's name.

 
 +#sound-dai-cells = 0;
 +compatible = ti,tlv320aic3106;
 +reg = 0x18;
 +status = okay;
 +
 +/* Regulators */
 +IOVDD-supply = vdcdc2_reg;
 +/* Derived from VBAT: Baseboard 3.3V / 1.8V */
 +AVDD-supply = vbat;
 +DRVDD-supply = vbat;
 +DVDD-supply = vbat;
 +};
 +
 
 [1] http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf

BTW: there's a newer version available:
https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf

 
 WBR, Sergei
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 0/2] dma: edma: Allow to disable eDMA IRQ during cyclic transfer

2014-07-28 Thread Peter Ujfalusi
On 07/16/2014 03:29 PM, Peter Ujfalusi wrote:
 Hi,
 
 After this series clients can ask to not receive notifications after each 
 period.
 In this case we can disable the completion interrupt since the position 
 reporting
 does not rely on it for cyclic mode.
 Patchset for ASoC part has been sent which allows users space to take 
 adventage
 of SNDRV_PCM_INFO_NO_PERIOD_WAKEUP:
 [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/078993.html

ping.

 When both series applied on top of linux-next:
 
 # cache the audio file in memory
 cat some_music.mp3  /dev/null
 # start PA
 pulseaudio -v
 # in another terminal, play the music via PA
 mplayer -ao pulse some_music.mp3
 # yet another terminal to monitor the interrupts
 watch cat /proc/interrupts
 # note the non increasing number of edma interrupts ;)
 
 Regards,
 Peter
 ---
 Peter Ujfalusi (2):
   dma: edma: Update caps-residue_granularity to match with reality
   dma: edma: Support to suppress the period interrupts in cyclic mode
 
  drivers/dma/edma.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 1/2] ARM: davinci: board-da850-evm: Mark dcdc2 of TPS65070 as always_on

2014-07-28 Thread Peter Ujfalusi
DCDC2 should not be turned off since it is powering the CPU among other
things.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-davinci/board-da850-evm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 234c5bb091f5..77d8968336df 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -936,6 +936,7 @@ static struct regulator_init_data tps65070_regulator_data[] 
= {
.valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
REGULATOR_CHANGE_STATUS),
.boot_on = 1,
+   .always_on = 1,
},
.num_consumer_supplies = ARRAY_SIZE(tps65070_dcdc2_consumers),
.consumer_supplies = tps65070_dcdc2_consumers,
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 2/2] ARM: davinci: board-da850-evm: Add needed regulators for tlv320aic3106 codec

2014-07-28 Thread Peter Ujfalusi
IOVDD: tps65070's dcdc2
AVDD and DRVDD: fixed regulator derived from 5V via TPS73701DCQ
DVDD: fixed regulator derived from 5V via TPS73701DCQ

This patch needed to be able to probe the audio codec.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/mach-davinci/board-da850-evm.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 77d8968336df..41eb05907f31 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -35,6 +35,7 @@
 #include linux/platform_data/uio_pruss.h
 #include linux/regulator/machine.h
 #include linux/regulator/tps6507x.h
+#include linux/regulator/fixed.h
 #include linux/spi/spi.h
 #include linux/spi/flash.h
 #include linux/wl12xx.h
@@ -841,6 +842,15 @@ static int da850_lcd_hw_init(void)
 
return 0;
 }
+/* Fixed regulator support */
+static struct regulator_consumer_supply fixed_supplies[] = {
+   /* Baseboard 3.3V: 5V - TPS73701DCQ - 3.3V */
+   REGULATOR_SUPPLY(AVDD, 1-0018),
+   REGULATOR_SUPPLY(DRVDD, 1-0018),
+
+   /* Baseboard 1.8V: 5V - TPS73701DCQ - 1.8V */
+   REGULATOR_SUPPLY(DVDD, 1-0018),
+};
 
 /* TPS65070 voltage regulator support */
 
@@ -865,6 +875,7 @@ static struct regulator_consumer_supply 
tps65070_dcdc2_consumers[] = {
{
.supply = dvdd3318_c,
},
+   REGULATOR_SUPPLY(IOVDD, 1-0018),
 };
 
 /* 1.2V */
@@ -1447,6 +1458,8 @@ static __init void da850_evm_init(void)
if (ret)
pr_warn(%s: GPIO init failed: %d\n, __func__, ret);
 
+   regulator_register_fixed(0, fixed_supplies, ARRAY_SIZE(fixed_supplies));
+
ret = pmic_tps65070_init();
if (ret)
pr_warn(%s: TPS65070 PMIC init failed: %d\n, __func__, ret);
-- 
2.0.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 2/2] dma: edma: Support to suppress the period interrupts in cyclic mode

2014-07-16 Thread Peter Ujfalusi
If the client (audio) does not request interrupts for every period we can
disable them.
With updated audio driver stack we can play audio w/o the need to process
any edma interrupts.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d5017abcf7cb..69f1f5250120 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -723,10 +723,10 @@ static struct dma_async_tx_descriptor 
*edma_prep_dma_cyclic(
edesc-absync = ret;
 
/*
-* Enable interrupts for every period because callback
-* has to be called for every period.
+* Enable period interrupt only if it is requested
 */
-   edesc-pset[i].param.opt |= TCINTEN;
+   if (tx_flags  DMA_PREP_INTERRUPT)
+   edesc-pset[i].param.opt |= TCINTEN;
}
 
/* Place the cyclic channel to highest priority queue */
-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 1/2] dma: edma: Update caps-residue_granularity to match with reality

2014-07-16 Thread Peter Ujfalusi
The edma can report accurate DMA position so update the residue_granularity
to DMA_RESIDUE_GRANULARITY_BURST.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index fe55f78ea137..d5017abcf7cb 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1001,7 +1001,7 @@ static int edma_dma_device_slave_caps(struct dma_chan 
*dchan,
caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
caps-cmd_pause = true;
caps-cmd_terminate = true;
-   caps-residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+   caps-residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
 
return 0;
 }
-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 0/2] dma: edma: Allow to disable eDMA IRQ during cyclic transfer

2014-07-16 Thread Peter Ujfalusi
Hi,

After this series clients can ask to not receive notifications after each 
period.
In this case we can disable the completion interrupt since the position 
reporting
does not rely on it for cyclic mode.
Patchset for ASoC part has been sent which allows users space to take adventage
of SNDRV_PCM_INFO_NO_PERIOD_WAKEUP:
[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-July/078993.html

When both series applied on top of linux-next:

# cache the audio file in memory
cat some_music.mp3  /dev/null
# start PA
pulseaudio -v
# in another terminal, play the music via PA
mplayer -ao pulse some_music.mp3
# yet another terminal to monitor the interrupts
watch cat /proc/interrupts
# note the non increasing number of edma interrupts ;)

Regards,
Peter
---
Peter Ujfalusi (2):
  dma: edma: Update caps-residue_granularity to match with reality
  dma: edma: Support to suppress the period interrupts in cyclic mode

 drivers/dma/edma.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 3/3] dma: edma: Serve cyclic (audio) channels with high priority queue

2014-07-08 Thread Peter Ujfalusi
Move the DMA channel used in cyclic mode (audio) to the highest priority
event queue which helps to reduce audio problems.
When the channel is terminated, move it back to the default queue.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index b512caf46944..fe55f78ea137 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -256,8 +256,13 @@ static int edma_terminate_all(struct edma_chan *echan)
 * echan-edesc is NULL and exit.)
 */
if (echan-edesc) {
+   int cyclic = echan-edesc-cyclic;
echan-edesc = NULL;
edma_stop(echan-ch_num);
+   /* Move the cyclic channel back to default queue */
+   if (cyclic)
+   edma_assign_channel_eventq(echan-ch_num,
+  EVENTQ_DEFAULT);
}
 
vchan_get_all_descriptors(echan-vchan, head);
@@ -724,6 +729,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-pset[i].param.opt |= TCINTEN;
}
 
+   /* Place the cyclic channel to highest priority queue */
+   edma_assign_channel_eventq(echan-ch_num, EVENTQ_0);
+
return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags);
 }
 
-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 0/3] ARM/dma: edma: Serve cyclic clients via high priority queue

2014-07-08 Thread Peter Ujfalusi
Hi,

It is preferred that audio is served with the highest priority queue in order to
avoid delays in data transfer between memory and audio IP.

The following series will add an API to arch code to assign a channel to a given
queue.
The default queue is changed from 0 (highest priority) to lowest priority.
In the dmaengine driver we move the cyclic channel to queue0 (highest priority)
and move it back to default queue when the channel is terminated.

Regards,
Peter
---
Peter Ujfalusi (3):
  ARM: edma: Set default queue to lowest priority
  ARM: edma: Add edma_assign_channel_eventq() to move channel to a give
queue
  dma: edma: Serve cyclic (audio) channels with high priority queue

 arch/arm/common/edma.c | 31 ++-
 drivers/dma/edma.c |  8 
 include/linux/platform_data/edma.h |  2 ++
 3 files changed, 40 insertions(+), 1 deletion(-)

-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 1/3] ARM: edma: Set default queue to lowest priority

2014-07-08 Thread Peter Ujfalusi
Use the lowest priority queue as default for clients.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 485be42519b9..f834aae7720f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1470,7 +1470,8 @@ static int edma_setup_from_hw(struct device *dev, struct 
edma_soc_info *pdata,
queue_priority_map[i][1] = -1;
 
pdata-queue_priority_mapping = queue_priority_map;
-   pdata-default_queue = 0;
+   /* Default queue has the lowest priority */
+   pdata-default_queue = i - 1;
 
return 0;
 }
-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 2/3] ARM: edma: Add edma_assign_channel_eventq() to move channel to a give queue

2014-07-08 Thread Peter Ujfalusi
In some cases it is desired to move a channel to a specific event queue.
Such a use case is audio, where it is preferred that it is served with
highest priority compared to other DMA clients.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 28 
 include/linux/platform_data/edma.h |  2 ++
 2 files changed, 30 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index f834aae7720f..88099175fc56 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1414,6 +1414,34 @@ void edma_clear_event(unsigned channel)
 }
 EXPORT_SYMBOL(edma_clear_event);
 
+/*
+ * edma_assign_channel_eventq - move given channel to desired eventq
+ * Arguments:
+ * channel - channel number
+ * eventq_no - queue to move the channel
+ *
+ * Can be used to move a channel to a selected event queue.
+ */
+void edma_assign_channel_eventq(unsigned channel, enum dma_event_q eventq_no)
+{
+   unsigned ctlr;
+
+   ctlr = EDMA_CTLR(channel);
+   channel = EDMA_CHAN_SLOT(channel);
+
+   if (channel = edma_cc[ctlr]-num_channels)
+   return;
+
+   /* default to low priority queue */
+   if (eventq_no == EVENTQ_DEFAULT)
+   eventq_no = edma_cc[ctlr]-default_queue;
+   if (eventq_no = edma_cc[ctlr]-num_tc)
+   return;
+
+   map_dmach_queue(ctlr, channel, eventq_no);
+}
+EXPORT_SYMBOL(edma_assign_channel_eventq);
+
 static int edma_setup_from_hw(struct device *dev, struct edma_soc_info *pdata,
  struct edma *edma_cc)
 {
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index eb8d5627d080..bdb2710e2aab 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -150,6 +150,8 @@ void edma_clear_event(unsigned channel);
 void edma_pause(unsigned channel);
 void edma_resume(unsigned channel);
 
+void edma_assign_channel_eventq(unsigned channel, enum dma_event_q eventq_no);
+
 struct edma_rsv_info {
 
const s16   (*rsv_chans)[2];
-- 
2.0.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct

2014-05-28 Thread Peter Ujfalusi
On 05/27/2014 06:03 PM, Joel Fernandes wrote:
 On 05/27/2014 05:22 AM, Peter Ujfalusi wrote:
 On 05/27/2014 12:32 AM, Olof Johansson wrote:
 [..]

 I came across this patch when I was looking at a pull request from
 Sekhar for EDMA cleanups, and it made me look closer at the contents
 of this file.

 The include/linux/platform_data/ directory is meant to hold
 platform_data definitions for drivers, and nothing more.
 platform_data/edma.h also contains a whole bunch of interface
 definitions for the driver. They do not belong there, and should be
 moved to a different include file.

 That also includes the above struct, because as far as I can tell it's
 a runtime state structure, not something that is passed in with
 platform data.

 Can someone please clean this up? Thanks.

 I think Joel is working on to move/merge the code from arch/arm/common/edma.c
 to drivers/dma/edma.c
 
 Yes, I am planning to work on that soon. But there is an issue, more on
 that discussed below..
 
 I'm sure within this work he is going to clean up the header file as well.
 
 Agreed. The private API should not be expored in any header and should
 be exclusive for the EDMA dmaengine driver ideally.
 
 As a first step I think the non platform_data content can be moved as
 include/linux/edma.h or probably as ti-edma.h?

 
 sound/soc/davinci/davinci-pcm.c: This still uses the EDMA private API in
 arch/arm/common/edma.c. Peter, any idea when the private usage will be
 removed fully, and we switch to dmaengine for ASoC? Before that can
 happen, we can't clean up or do any merges.

We have the edma-pcm platform driver upstream already which I'm using locally
for a long time now on AM335x/AM437x. I'm planning to send a patch to do the
same upstream after the 3.16 window closes.
But, davinci-pcm has a mode called 'ping-pong' which is not available via
dmaengine and this mode is used by several daVinci SoCs to overcome buffer
underflow/overflow issues. This mode essentially means in playback case:
  dma_ch1   dma_ch2
SDRAM --- SRAM --- McASP

ch1 is to move a block of samples to SRAM from where ch2 will copy the samples
word by word to McASP.

If we move all davinci SoCs to use the edma-pcm, we are going to loose this
mode. As a note: the edma-pcm is confirmed to work fine on the tested daVinci
boards.
I think what we need to do first: find a board which is using ping-pong mode,
put under stress test in:
- davinci-pcm, ping-pong mode
- davinci-pcm, no ping-pong mode
- edma-pcm

and see how edma-pcm behaves compared to the davinci-pcm. One of the issue
with davinci-pcm is that in non ping-pong mode it reconfigures the eDMA after
every period, which is a bad thing. The dmaengine implementation does not need
to do that, so we might be fine there.

 What I'd like to do is fold the private API into the dmaengine driver
 and eliminate the need to expose the private API, thus also getting rid
 of the interface declarations Olof referred to.
 
 thanks,
 
 -Joel
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct

2014-05-27 Thread Peter Ujfalusi
On 05/27/2014 12:32 AM, Olof Johansson wrote:
 Hi,
 
 On Mon, Apr 14, 2014 at 4:41 AM, Peter Ujfalusi peter.ujfal...@ti.com wrote:
 The edmacc_param struct should follow the layout of the paRAM area in the
 HW. Be explicit on the size of the fields (u32) and also mark the struct
 as packed to avoid any padding on non 32bit architectures.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 Acked-by: Joel Fernandes jo...@ti.com
 ---
  include/linux/platform_data/edma.h | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

 diff --git a/include/linux/platform_data/edma.h 
 b/include/linux/platform_data/edma.h
 index f50821cb64be..923f8a3e4ce0 100644
 --- a/include/linux/platform_data/edma.h
 +++ b/include/linux/platform_data/edma.h
 @@ -43,15 +43,15 @@

  /* PaRAM slots are laid out like this */
  struct edmacc_param {
 -   unsigned int opt;
 -   unsigned int src;
 -   unsigned int a_b_cnt;
 -   unsigned int dst;
 -   unsigned int src_dst_bidx;
 -   unsigned int link_bcntrld;
 -   unsigned int src_dst_cidx;
 -   unsigned int ccnt;
 -};
 +   u32 opt;
 +   u32 src;
 +   u32 a_b_cnt;
 +   u32 dst;
 +   u32 src_dst_bidx;
 +   u32 link_bcntrld;
 +   u32 src_dst_cidx;
 +   u32 ccnt;
 +} __packed;

  /* fields in edmacc_param.opt */
  #define SAMBIT(0)
 
 I came across this patch when I was looking at a pull request from
 Sekhar for EDMA cleanups, and it made me look closer at the contents
 of this file.
 
 The include/linux/platform_data/ directory is meant to hold
 platform_data definitions for drivers, and nothing more.
 platform_data/edma.h also contains a whole bunch of interface
 definitions for the driver. They do not belong there, and should be
 moved to a different include file.
 
 That also includes the above struct, because as far as I can tell it's
 a runtime state structure, not something that is passed in with
 platform data.
 
 Can someone please clean this up? Thanks.

I think Joel is working on to move/merge the code from arch/arm/common/edma.c
to drivers/dma/edma.c
I'm sure within this work he is going to clean up the header file as well.
As a first step I think the non platform_data content can be moved as
include/linux/edma.h or probably as ti-edma.h?

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[RESEND] dmaengine: edma: Add channel number to debug prints

2014-04-24 Thread Peter Ujfalusi
It helps to identify issues if we have some information regarding to the
channel which the event is associated.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
Hi Vinod,

rebased on:
git://git.infradead.org/users/vkoul/slave-dma.git next

On top of:
406efb1a745c dmaengine: edma: No need save/restore interrupt flags during...

Regards,
Peter

 drivers/dma/edma.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index fa87fd52b0ad..473155d34d7b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -183,7 +183,8 @@ static void edma_execute(struct edma_chan *echan)
}
 
if (edesc-processed = MAX_NR_SG) {
-   dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+   dev_dbg(dev, first transfer starting on channel %d\n,
+   echan-ch_num);
edma_start(echan-ch_num);
} else {
dev_dbg(dev, chan: %d: completed %d elements, resuming\n,
@@ -197,7 +198,7 @@ static void edma_execute(struct edma_chan *echan)
 * MAX_NR_SG
 */
if (echan-missed) {
-   dev_dbg(dev, missed event in execute detected\n);
+   dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -779,7 +780,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
 
-   dev_dbg(dev, allocated channel for %u:%u\n,
+   dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
 
return 0;
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-24 Thread Peter Ujfalusi
On 04/16/2014 07:05 PM, Joel Fernandes wrote:
 On 04/16/2014 07:59 AM, Peter Ujfalusi wrote:
 [..]
 If the dma-priority is missing we should assume lowest priority (0).
 The highest priority depends on the platform. For eDMA3 in AM335x it is 
 three
 level. For designware controller you might have the range 0-8 as valid.

 The question is how to get this information into use?
 We can take the priority number in the core when the dma channel is 
 requested
 and add field to struct dma_chan in order to store it and the DMA 
 drivers
 could have access to it.

 How about Vinod's idea of extending dma_slave_config? Priority is
 similar to rest of the runtime setup dmaengine_slave_config() is meant
 to do.

 The dma_slave_config is prepared by the client drivers, so they would need to
 be updated to handle the priority for the DMA. This would lead to duplicated
 code - unless we have a small function in dmaengine core to fetch this
 information, but still all dmaengine clients would need to call that.
 IMHO it would be better to let the dmaengine core to take the priority for 
 the
 channel when it has been asked so client drivers does not need to know about 
 it.

 
 I still feel it is much cleaner to keep this out of DT and have audio
 driver configure the channel manually for higher priority. Because,
 AFAIK audio is the only device that uses slave DMA and needs higher
 priority. I'd imagine everyone else who needs high priority, have their
 own dedicated DMAC, so from that sense I don't see the priority
 mechanism being used a lot anywhere else but audio, so atleast we can
 rule out things like code duplication in other drivers. Priority can be
 set to a default of low for those drivers that don't configure the
 channel for priority. I'm also OK with EDMA driver configuring channel
 for higher priority manually for the Cyclic case like you did initially.

So how should we go about this?
I'm fine to select higher priority in the eDMA driver for now when a cyclic
channel is configured and later when we have (if we ever have) generic way to
handle DMA channel/transaction priority we can switch eDMA as well to use it.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-16 Thread Peter Ujfalusi
On 04/14/2014 05:32 PM, Sekhar Nori wrote:
 Yes, you can. But as soon as you have other devices using the same priority
 (with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
 During audio playback/capture you execute a long MMC read for example can
 introduce a glitch.

 Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
 wide variety of example use cases, I think it is too early to commit to
 an ABI.

 True, but we need to start from somewhere?
 
 Right, and based on our IRC discussion, we are not really fixing up the
 priority value space. That makes me much more comfortable with the idea.

The only thing we should agree on is the 0 means lowest priority. I think this
will help in case when a new kernel is fed with an older dt blob where the
property does not exist.

 
 Not sure if we should set the range for this either. What I was thinking 
 is to
 add an optional new property to be set by the client nodes, using DMA:

 mcasp0: mcasp@48038000 {
compatible = ti,am33xx-mcasp-audio;
...
dmas =  edma 8,
edma 9;
dma-names = tx, rx;
dma-priorities = 2, 2;
 };

 
 We could agree that lower number means lower priority, higher is - well -
 higher priority.
 
 Even this does not have to be uniform across, right? The numbers could
 be left to interpretation per-SoC.
 
 If the dma-priority is missing we should assume lowest priority (0).
 The highest priority depends on the platform. For eDMA3 in AM335x it is 
 three
 level. For designware controller you might have the range 0-8 as valid.

 The question is how to get this information into use?
 We can take the priority number in the core when the dma channel is 
 requested
 and add field to struct dma_chan in order to store it and the DMA drivers
 could have access to it.
 
 How about Vinod's idea of extending dma_slave_config? Priority is
 similar to rest of the runtime setup dmaengine_slave_config() is meant
 to do.

The dma_slave_config is prepared by the client drivers, so they would need to
be updated to handle the priority for the DMA. This would lead to duplicated
code - unless we have a small function in dmaengine core to fetch this
information, but still all dmaengine clients would need to call that.
IMHO it would be better to let the dmaengine core to take the priority for the
channel when it has been asked so client drivers does not need to know about it.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 00/10] dma: edma: Fixes for cyclic (audio) operation

2014-04-14 Thread Peter Ujfalusi
Hi,

Changes since v2:
- Dropped patch 10 from v2 (simplify direction configuration...)
- Dropped the channel priority related patches since we are going to go via
  different route for configuring the priority.
- Added ACK from Joel for the patches since they are not changed since v2

Changes since v1:
- ASoC patches removed
- Comments from Andriy Shevchenko addressed
- patch added to fix cases when src/dst_maxburst is set to 0

The series contains now only:
Support for DMA pause/resume in cyclic mode
device_slave_caps callback and DMA_CYCLIC flag correction.
While debugging the edma to get things sorted out I noticed that the debug was
too verbose and the important information was hidden even when the we did not
asked for verbose dmaengine debug.
I have included some debug cleanups for the edma dmaengine driver also.

Regards,
Peter
---
Peter Ujfalusi (10):
  platform_data: edma: Be precise with the paRAM struct
  arm: common: edma: Save the number of event queues/TCs
  dmaengine: edma: Correct the handling of src/dst_maxburst == 0
  dmaengine: edma: Add support for DMA_PAUSE/RESUME operation
  dmaengine: edma: Set DMA_CYCLIC capability flag
  dmaengine: edma: Implement device_slave_caps callback
  dmaengine: edma: Reduce debug print verbosity for non verbose
debugging
  dmaengine: edma: Prefix debug prints where the text were identical in
prep callbacks
  dmaengine: edma: Add channel number to debug prints
  dmaengine: edma: Print the direction value as well when it is not
supported

 arch/arm/common/edma.c |  4 ++
 drivers/dma/edma.c | 87 ++
 include/linux/platform_data/edma.h | 18 
 3 files changed, 83 insertions(+), 26 deletions(-)

-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 02/10] arm: common: edma: Save the number of event queues/TCs

2014-04-14 Thread Peter Ujfalusi
For later use save the number of queues available for the CC.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 arch/arm/common/edma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 41bca32409fc..999266bf69b9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1768,6 +1768,9 @@ static int edma_probe(struct platform_device *pdev)
map_queue_tc(j, queue_tc_mapping[i][0],
queue_tc_mapping[i][1]);
 
+   /* Save the number of TCs */
+   edma_cc[j]-num_tc = i;
+
/* Event queue priority mapping */
for (i = 0; queue_priority_mapping[i][0] != -1; i++)
assign_priority_to_queue(j,
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 04/10] dmaengine: edma: Add support for DMA_PAUSE/RESUME operation

2014-04-14 Thread Peter Ujfalusi
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2742867fd1e6..7891378a03f0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
return 0;
 }
 
+static int edma_dma_pause(struct edma_chan *echan)
+{
+   /* Pause/Resume only allowed with cyclic mode */
+   if (!echan-edesc-cyclic)
+   return -EINVAL;
+
+   edma_pause(echan-ch_num);
+   return 0;
+}
+
+static int edma_dma_resume(struct edma_chan *echan)
+{
+   /* Pause/Resume only allowed with cyclic mode */
+   if (!echan-edesc-cyclic)
+   return -EINVAL;
+
+   edma_resume(echan-ch_num);
+   return 0;
+}
+
 static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
unsigned long arg)
 {
@@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum 
dma_ctrl_cmd cmd,
config = (struct dma_slave_config *)arg;
ret = edma_slave_config(echan, config);
break;
+   case DMA_PAUSE:
+   ret = edma_dma_pause(echan);
+   break;
+
+   case DMA_RESUME:
+   ret = edma_dma_resume(echan);
+   break;
+
default:
ret = -ENOSYS;
}
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 01/10] platform_data: edma: Be precise with the paRAM struct

2014-04-14 Thread Peter Ujfalusi
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 include/linux/platform_data/edma.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index f50821cb64be..923f8a3e4ce0 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -43,15 +43,15 @@
 
 /* PaRAM slots are laid out like this */
 struct edmacc_param {
-   unsigned int opt;
-   unsigned int src;
-   unsigned int a_b_cnt;
-   unsigned int dst;
-   unsigned int src_dst_bidx;
-   unsigned int link_bcntrld;
-   unsigned int src_dst_cidx;
-   unsigned int ccnt;
-};
+   u32 opt;
+   u32 src;
+   u32 a_b_cnt;
+   u32 dst;
+   u32 src_dst_bidx;
+   u32 link_bcntrld;
+   u32 src_dst_cidx;
+   u32 ccnt;
+} __packed;
 
 /* fields in edmacc_param.opt */
 #define SAMBIT(0)
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 05/10] dmaengine: edma: Set DMA_CYCLIC capability flag

2014-04-14 Thread Peter Ujfalusi
Indicate that the edma dmaengine driver has support for cyclic mode.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 arch/arm/common/edma.c | 1 +
 drivers/dma/edma.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 999266bf69b9..0b37f7734d0f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1574,6 +1574,7 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
return ERR_PTR(ret);
 
dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
of_dma_controller_register(dev-of_node, of_dma_simple_xlate,
   edma_filter_info);
 
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7891378a03f0..1dd9e8806975 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -891,6 +891,7 @@ static int edma_probe(struct platform_device *pdev)
 
dma_cap_zero(ecc-dma_slave.cap_mask);
dma_cap_set(DMA_SLAVE, ecc-dma_slave.cap_mask);
+   dma_cap_set(DMA_CYCLIC, ecc-dma_slave.cap_mask);
 
edma_dma_init(ecc, ecc-dma_slave, pdev-dev);
 
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 03/10] dmaengine: edma: Correct the handling of src/dst_maxburst == 0

2014-04-14 Thread Peter Ujfalusi
When clients asks for maxburst = 0 it is basically the same case as if they
were asking for maxburst = 1 since in both case ASYNC need to be used and
the eDMA is expected to write/read one word per DMA request.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cd04eb7b182e..2742867fd1e6 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -285,6 +285,10 @@ static int edma_config_pset(struct dma_chan *chan, struct 
edmacc_param *pset,
int absync;
 
acnt = dev_width;
+
+   /* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */
+   if (!burst)
+   burst = 1;
/*
 * If the maxburst is equal to the fifo width, use
 * A-synced transfers. This allows for large contiguous
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 07/10] dmaengine: edma: Reduce debug print verbosity for non verbose debugging

2014-04-14 Thread Peter Ujfalusi
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2f58c04cbcb1..6d9edc47150d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i  nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-   dev_dbg(echan-vchan.chan.device-dev,
+   dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
@@ -560,9 +560,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
 
-   dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-   dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-   dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+   dev_dbg(dev, %s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n,
+   __func__, echan-ch_num, nslots, period_len, buf_len);
 
for (i = 0; i  nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -596,8 +595,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
 
-   dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-   dev_dbg(dev,
+   dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+   dev_vdbg(dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 10/10] dmaengine: edma: Print the direction value as well when it is not supported

2014-04-14 Thread Peter Ujfalusi
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4aa5eb005b5c..91849aa50de1 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -432,7 +432,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
@@ -525,7 +525,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 09/10] dmaengine: edma: Add channel number to debug prints

2014-04-14 Thread Peter Ujfalusi
It helps to identify issues if we have some information regarding to the
channel which the event is associated.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index bc8175c92e0c..4aa5eb005b5c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -185,7 +185,8 @@ static void edma_execute(struct edma_chan *echan)
edma_resume(echan-ch_num);
 
if (edesc-processed = MAX_NR_SG) {
-   dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+   dev_dbg(dev, first transfer starting on channel %d\n,
+   echan-ch_num);
edma_start(echan-ch_num);
}
 
@@ -195,7 +196,7 @@ static void edma_execute(struct edma_chan *echan)
 * MAX_NR_SG
 */
if (echan-missed) {
-   dev_dbg(dev, missed event in execute detected\n);
+   dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -735,7 +736,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
 
-   dev_dbg(dev, allocated channel for %u:%u\n,
+   dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
 
return 0;
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v3 08/10] dmaengine: edma: Prefix debug prints where the text were identical in prep callbacks

2014-04-14 Thread Peter Ujfalusi
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Acked-by: Joel Fernandes jo...@ti.com
---
 drivers/dma/edma.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 6d9edc47150d..bc8175c92e0c 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -436,14 +436,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -459,7 +459,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
@@ -528,7 +529,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
@@ -553,7 +554,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -571,7 +572,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
-- 
1.9.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-14 Thread Peter Ujfalusi
Hi Vinod,

On 04/11/2014 03:46 PM, Vinod Koul wrote:
 I think the number shouldn't be viewed in absolute terms. If we decide that 
 (lets
 say) 0-7, then any controller should map 0 to lowest and 7 to highest.
 
 For your case you can do this and then intermediate numbers would be medium
 priority. Such a system might work well...
 
 Also how would a client driver know which priority to use? Would it come from
 DT?

I think DT would be the best place.
Not sure if we should set the range for this either. What I was thinking is to
add an optional new property to be set by the client nodes, using DMA:

mcasp0: mcasp@48038000 {
compatible = ti,am33xx-mcasp-audio;
...
dmas =  edma 8,
edma 9;
dma-names = tx, rx;
dma-priorities = 2, 2;
};

We could agree that lower number means lower priority, higher is - well -
higher priority.
If the dma-priority is missing we should assume lowest priority (0).
The highest priority depends on the platform. For eDMA3 in AM335x it is three
level. For designware controller you might have the range 0-8 as valid.

The question is how to get this information into use?
We can take the priority number in the core when the dma channel is requested
and add field to struct dma_chan in order to store it and the DMA drivers
could have access to it.
In this way we only need to update the nodes which needs non default priority
for DMA.

What do you think?

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-14 Thread Peter Ujfalusi
On 04/14/2014 03:12 PM, Sekhar Nori wrote:
 On Monday 14 April 2014 05:26 PM, Peter Ujfalusi wrote:
 Hi Vinod,

 On 04/11/2014 03:46 PM, Vinod Koul wrote:
 I think the number shouldn't be viewed in absolute terms. If we decide that 
 (lets
 say) 0-7, then any controller should map 0 to lowest and 7 to highest.

 For your case you can do this and then intermediate numbers would be medium
 priority. Such a system might work well...

 Also how would a client driver know which priority to use? Would it come 
 from
 DT?

 I think DT would be the best place.
 
 In the strict sense of what DT is supposed to represent, DT is not the
 best place for this. Priority is usecase driven rather that hardware
 description driven.

While this is true, the DMA priority - if supported by the DMA engine - is a
HW feature as well. If it is supported by the HW it can be used to tune and
partition the system for the anticipated load or purpose.

 So on a reasonably less loaded system, I am sure you
 could run audio even with a lower priority DMA queue.

Yes, you can. But as soon as you have other devices using the same priority
(with eDMA3 at least) and asks for a 'long' transfer it can ruin the audio.
During audio playback/capture you execute a long MMC read for example can
introduce a glitch.

 Moreover, IMHO, encoding it in DT now will make it an ABI. Without a
 wide variety of example use cases, I think it is too early to commit to
 an ABI.

True, but we need to start from somewhere?

I'm fine if we handle this right now as I did in this series (to put only
cyclic on high priority) for now. With some forward looking changes in the
implementation of course.

 Not sure if we should set the range for this either. What I was thinking is 
 to
 add an optional new property to be set by the client nodes, using DMA:

 mcasp0: mcasp@48038000 {
  compatible = ti,am33xx-mcasp-audio;
  ...
  dmas =  edma 8,
  edma 9;
  dma-names = tx, rx;
  dma-priorities = 2, 2;
 };

 We could agree that lower number means lower priority, higher is - well -
 higher priority.
 If the dma-priority is missing we should assume lowest priority (0).
 The highest priority depends on the platform. For eDMA3 in AM335x it is three
 level. For designware controller you might have the range 0-8 as valid.

 The question is how to get this information into use?
 We can take the priority number in the core when the dma channel is requested
 and add field to struct dma_chan in order to store it and the DMA drivers
 could have access to it.
 In this way we only need to update the nodes which needs non default priority
 for DMA.

 What do you think?
 
 If we are using dma_slave_config, I think it will be easiest to define
 two levels of priority (HIGH and LOW, as thats all we see a need for
 right now), and have the audio driver select the HIGH priority. If
 nothing is set, EDMA can default to LOW.

But the information on which channel should be high priority should be coming
form somewhere... We can wire it in the audio stack, but I don't think it is a
good idea to start with.
And if we have high/low priority we could as well have an integer to specify
the desired level.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 10/14] dma: edma: Simplify direction configuration in edma_config_pset()

2014-04-11 Thread Peter Ujfalusi
On 04/11/2014 01:40 AM, Joel Fernandes wrote:
 On 04/01/2014 08:06 AM, Peter Ujfalusi wrote:
 We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
 check for the direction has been already done in the function calling
 edma_config_pset().
 The error reporting is redundant and also the else if () can be removed.

 
 NAK. Please don't do this. I have been working on MEM_TO_MEM support as
 well so leave it as it is for future.

Sure. It is still valid to say that the error else {} will never going to
happen since you have the same check in the calling function and they already
filtered the non implemented direction.

I'll leave this out from v3.

-- 
Péter

 
 Thanks,
 -Joel
 
 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 855766672aa9..d954099650ae 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -372,14 +372,12 @@ static int edma_config_pset(struct dma_chan *chan, 
 struct edmacc_param *pset,
  src_cidx = cidx;
  dst_bidx = 0;
  dst_cidx = 0;
 -} else if (direction == DMA_DEV_TO_MEM)  {
 +} else {
 +/* DMA_DEV_TO_MEM */
  src_bidx = 0;
  src_cidx = 0;
  dst_bidx = acnt;
  dst_cidx = cidx;
 -} else {
 -dev_err(dev, %s: direction not implemented yet\n, __func__);
 -return -EINVAL;
  }
  
  pset-opt = EDMA_TCC(EDMA_CHAN_SLOT(echan-ch_num));

 

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-11 Thread Peter Ujfalusi
On 04/11/2014 11:56 AM, Sekhar Nori wrote:
 On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
 On 04/11/2014 11:17 AM, Sekhar Nori wrote:
 On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
 Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
 priority channels, like audio.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com

 Acked-by: Sekhar Nori nsek...@ti.com

 ---
  arch/arm/common/edma.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 86a8b263278f..19520e2519d9 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev,
  
pdata-queue_priority_mapping = queue_priority_map;
  
 -  pdata-default_queue = 0;
 +  /* select queue 1 as default */

 It will be nice to expand the comment with explanation of why this is
 being chosen as default (lower priority queue by default for typical
 bulk data transfer).

 Yes, extended comment is a good idea.

 For the next version I think I'm going to change the code around default
 TC/Queue and the non default queue selection, mostly based on Joel's comment:

 EVENTQ_1 as default queue.
 Set the EVENTQ_1 priority to 7
 EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2

 Add new member to struct edma, like high_pri_queue.
 When we set the queue priorities in edma_probe() we look for the highest
 priority queue and save the number in high_pri_queue.

 I will rename the edma_request_non_default_queue() to
 edma_request_high_pri_queue() and it will assign the channel to the high
 priority queue.

 I think this way it is going to be more explicit and IMHO a bit more safer in
 a sense the we are going to get high priority when we ask for it.
 
 Sounds much better. I had posted some ideas about adding support for
 channel priority in the core code but we can leave that for Vinod and
 Dan to say if they really see a need for that.

If we do it via the dmaengine core I think it would be better to have a new
flag to be passed to dmaengine_prep_dma_*().
We could have for example:
DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is
possible.
We can watch for this flag in the edma driver and act accordingly.
ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally
since audio should be treated in this way if the DMA IP can do this.

Not sure what to do with eDMA's 8 priority level. With that we could have high
priority; low priority; low, but not the lowest priority; about in the middle
priority; etc.

We could have also new callback in the dma_device struct with needed wrappers
to set priority level, but where to draw the range? High, Mid and Low? Range
of 0 - 10?

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-11 Thread Peter Ujfalusi
Hi Vinod,

On 04/11/2014 12:42 PM, Vinod Koul wrote:
 On Fri, Apr 11, 2014 at 12:38:00PM +0300, Peter Ujfalusi wrote:
 On 04/11/2014 11:56 AM, Sekhar Nori wrote:
 On Friday 11 April 2014 02:20 PM, Peter Ujfalusi wrote:
 On 04/11/2014 11:17 AM, Sekhar Nori wrote:
 On Tuesday 01 April 2014 06:36 PM, Peter Ujfalusi wrote:
 Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
 priority channels, like audio.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com

 Acked-by: Sekhar Nori nsek...@ti.com

 ---
  arch/arm/common/edma.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
 index 86a8b263278f..19520e2519d9 100644
 --- a/arch/arm/common/edma.c
 +++ b/arch/arm/common/edma.c
 @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev,
  
  pdata-queue_priority_mapping = queue_priority_map;
  
 -pdata-default_queue = 0;
 +/* select queue 1 as default */

 It will be nice to expand the comment with explanation of why this is
 being chosen as default (lower priority queue by default for typical
 bulk data transfer).

 Yes, extended comment is a good idea.

 For the next version I think I'm going to change the code around default
 TC/Queue and the non default queue selection, mostly based on Joel's 
 comment:

 EVENTQ_1 as default queue.
 Set the EVENTQ_1 priority to 7
 EVENTQ_0 priority is going to stay 0 and EVENTQ_2 as 2

 Add new member to struct edma, like high_pri_queue.
 When we set the queue priorities in edma_probe() we look for the highest
 priority queue and save the number in high_pri_queue.

 I will rename the edma_request_non_default_queue() to
 edma_request_high_pri_queue() and it will assign the channel to the high
 priority queue.

 I think this way it is going to be more explicit and IMHO a bit more safer 
 in
 a sense the we are going to get high priority when we ask for it.

 Sounds much better. I had posted some ideas about adding support for
 channel priority in the core code but we can leave that for Vinod and
 Dan to say if they really see a need for that.
 Is it part of this series?

No, it is not. The original series tackled the DMA queue selection within the
edma driver stack. It was selecting high priority channel for cyclic (audio)
use only, all other DMA channels were executed on a lower priority queue.

 If we do it via the dmaengine core I think it would be better to have a new
 flag to be passed to dmaengine_prep_dma_*().
 We could have for example:
 DMA_PREP_HIGH_PRI as flag to indicate that we need high priority DMA if it is
 possible.
 We can watch for this flag in the edma driver and act accordingly.
 ALSA's dmaengine_pcm_prepare_and_submit() could set this flag unconditionally
 since audio should be treated in this way if the DMA IP can do this.

 Will the priority be different for each descriptor or would be based on 
 channel
 usage.

I would say that it is channel based config. I don't see the reason why would
one mix different priorities on a configured channel between descriptors.

 If not then we can add this in dma_slave_config ?

So adding to the struct for example:
bool high_priority;

I'm not sure if it helps if we have let's say three priority level like, low,
normal and high.
I don't think that any client would ask for low priority instead using the
normal priority.

 I can forsee its usage on slave controllers, so yes its useful :)

True I'm sure it is going to be used as soon as it is available if the HW
supports priorities.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-11 Thread Peter Ujfalusi
On 04/11/2014 02:31 PM, Vinod Koul wrote:

 I would say that it is channel based config. I don't see the reason why would
 one mix different priorities on a configured channel between descriptors.

 If not then we can add this in dma_slave_config ?

 So adding to the struct for example:
 bool high_priority;
 
 In designware controller, we can have channel priorties from 0 to 7 which 
 IIRC 7
 being highest. So bool wont work. unsigned int/u8 would be good.

I see. But from a generic code what number should one pass if we want to get
the highest priority? With eDMA3 we essentially have three levels (see later)
so if we receive 7 as priority what shall we do? Just treat as highest? But if
we receive 4, which is somewhere in the middle for designware it is still
means highest for us.

I see this too small step partitioning in common code a bit problematic when
it comes to how to interpret the 'magic numbers'.
Also how all the driver in the system will decide the priority number? I'm
sure they will pick something conveniently average for themselves and I
imagine audio would try to pick something which is bigger than the numbers
others have taken...

 How about your controller, is it binary?

We also have priority from 0 to 7, 0 being the highest priority. We have 3
Transfer Controllers/Event Queues and we can set the priority for the TC/EQ
and assign the given channel to the desired TC/EQ.
So in reality we have 3 priorities to choose from in my view since we only
have 3 TC/EQ in eDMA3 (of AM335x/AM447x) on other SoCs we can have different
number of TC/EQ.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 02/14] dma: edma: Correct the handling of src/dst_maxburst == 0

2014-04-01 Thread Peter Ujfalusi
When clients asks for maxburst = 0 it is basically the same case as if they
were asking for maxburst = 1 since in both case ASYNC need to be used and
the eDMA is expected to write/read one word per DMA request.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index cd04eb7b182e..2742867fd1e6 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -285,6 +285,10 @@ static int edma_config_pset(struct dma_chan *chan, struct 
edmacc_param *pset,
int absync;
 
acnt = dev_width;
+
+   /* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */
+   if (!burst)
+   burst = 1;
/*
 * If the maxburst is equal to the fifo width, use
 * A-synced transfers. This allows for large contiguous
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 00/14] dma: edma: Fixes for cyclic (audio) operation

2014-04-01 Thread Peter Ujfalusi
Hi,

This is basically a resend of the previous series:
https://lkml.org/lkml/2014/3/13/119
with removed ASoC patches (most of them are applied already).

Changes since v1:
- ASoC patches removed
- Comments from Andriy Shevchenko addressed
- patch added to fix cases when src/dst_maxburst is set to 0

Adding support for DMA pause/resume
Possibility to select non default event queue/TC for cyclic (audio) dma
channels: all devices using the eDMA via dmaengine was assigned to the default
EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system
performance point of view since sharing the same EQ/TC can cause latency spikes
for cyclic channels (long DMA transfers for MMC for example).

While debugging the edma to get things sorted out I noticed that the debug was
too verbose and the important information was hidden even when the we did not
asked for verbose dmaengine debug.
I have included some debug cleanups for the edma dmaengine driver also.

Regards,
Peter
---
Peter Ujfalusi (14):
  platform_data: edma: Be precise with the paRAM struct
  dma: edma: Correct the handling of src/dst_maxburst == 0
  dma: edma: Add support for DMA_PAUSE/RESUME operation
  dma: edma: Set DMA_CYCLIC capability flag
  arm: common: edma: Select event queue 1 as default when booted with DT
  arm: common: edma: Save the number of event queues/TCs
  arm: common: edma: API to request non default queue for a channel
  DMA: edma: Use different eventq for cyclic channels
  dma: edma: Implement device_slave_caps callback
  dma: edma: Simplify direction configuration in edma_config_pset()
  dma: edma: Reduce debug print verbosity for non verbose debugging
  dma: edma: Prefix debug prints where the text were identical in prep
callbacks
  dma: edma: Add channel number to debug prints
  dma: edma: Print the direction value as well when it is not supported

 arch/arm/common/edma.c | 34 +-
 drivers/dma/edma.c | 96 +-
 include/linux/platform_data/edma.h | 20 
 3 files changed, 119 insertions(+), 31 deletions(-)

-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 01/14] platform_data: edma: Be precise with the paRAM struct

2014-04-01 Thread Peter Ujfalusi
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 include/linux/platform_data/edma.h | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index f50821cb64be..923f8a3e4ce0 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -43,15 +43,15 @@
 
 /* PaRAM slots are laid out like this */
 struct edmacc_param {
-   unsigned int opt;
-   unsigned int src;
-   unsigned int a_b_cnt;
-   unsigned int dst;
-   unsigned int src_dst_bidx;
-   unsigned int link_bcntrld;
-   unsigned int src_dst_cidx;
-   unsigned int ccnt;
-};
+   u32 opt;
+   u32 src;
+   u32 a_b_cnt;
+   u32 dst;
+   u32 src_dst_bidx;
+   u32 link_bcntrld;
+   u32 src_dst_cidx;
+   u32 ccnt;
+} __packed;
 
 /* fields in edmacc_param.opt */
 #define SAMBIT(0)
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 07/14] arm: common: edma: API to request non default queue for a channel

2014-04-01 Thread Peter Ujfalusi
When using eDMA3 via dmaengine all dma channels will use the default queue.
Since during request time we do not have means to change this it need to be done
later, before the DMA has been started.
With the added function it is possible to move the channel to a non default
queue if it is possible, otherwise (when only one EQ/TC is available for the CC)
the default queue is going to be used.
For example: For optimal system performance the audio (cyclic) DMA should
be placed to a separate queue which is different than what the rest of the
system is using.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 27 +++
 include/linux/platform_data/edma.h |  2 ++
 2 files changed, 29 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be267b2080be..eaf6dd19f082 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -712,6 +712,33 @@ int edma_alloc_channel(int channel,
 }
 EXPORT_SYMBOL(edma_alloc_channel);
 
+/**
+ * edma_request_non_default_queue - try to map the channel to non default queue
+ * @channel: dma channel returned from edma_alloc_channel()
+ *
+ * For certain type of applications like audio it is preferred to not use the
+ * default event queue/tc to avoid eDMA caused latency.
+ *
+ * This function will iterate through the event queues available for the CC and
+ * picks the first EQ/TC which is not set as the default for the CC
+ */
+void edma_request_non_default_queue(int channel)
+{
+   unsigned ctlr = EDMA_CTLR(channel);
+   enum dma_event_q eventq_no = EVENTQ_DEFAULT;
+   int i;
+
+   for (i = 0; i  edma_cc[ctlr]-num_tc; i++) {
+   if (i != edma_cc[ctlr]-default_queue) {
+   eventq_no = i;
+   break;
+   }
+   }
+
+   channel = EDMA_CHAN_SLOT(channel);
+   map_dmach_queue(ctlr, channel, eventq_no);
+}
+EXPORT_SYMBOL(edma_request_non_default_queue);
 
 /**
  * edma_free_channel - deallocate DMA channel
diff --git a/include/linux/platform_data/edma.h 
b/include/linux/platform_data/edma.h
index 923f8a3e4ce0..5d0a1b98f205 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -117,6 +117,8 @@ int edma_alloc_channel(int channel,
void *data, enum dma_event_q);
 void edma_free_channel(unsigned channel);
 
+void edma_request_non_default_queue(int channel);
+
 /* alloc/free parameter RAM slots */
 int edma_alloc_slot(unsigned ctlr, int slot);
 void edma_free_slot(unsigned slot);
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 04/14] dma: edma: Set DMA_CYCLIC capability flag

2014-04-01 Thread Peter Ujfalusi
Indicate that the edma dmaengine driver has support for cyclic mode.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 1 +
 drivers/dma/edma.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 41bca32409fc..86a8b263278f 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1574,6 +1574,7 @@ static struct edma_soc_info 
*edma_setup_info_from_dt(struct device *dev,
return ERR_PTR(ret);
 
dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap);
+   dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap);
of_dma_controller_register(dev-of_node, of_dma_simple_xlate,
   edma_filter_info);
 
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7891378a03f0..1dd9e8806975 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -891,6 +891,7 @@ static int edma_probe(struct platform_device *pdev)
 
dma_cap_zero(ecc-dma_slave.cap_mask);
dma_cap_set(DMA_SLAVE, ecc-dma_slave.cap_mask);
+   dma_cap_set(DMA_CYCLIC, ecc-dma_slave.cap_mask);
 
edma_dma_init(ecc, ecc-dma_slave, pdev-dev);
 
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT

2014-04-01 Thread Peter Ujfalusi
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high
priority channels, like audio.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 86a8b263278f..19520e2519d9 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev,
 
pdata-queue_priority_mapping = queue_priority_map;
 
-   pdata-default_queue = 0;
+   /* select queue 1 as default */
+   pdata-default_queue = EVENTQ_1;
 
prop = of_find_property(node, ti,edma-xbar-event-map, sz);
if (prop)
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 03/14] dma: edma: Add support for DMA_PAUSE/RESUME operation

2014-04-01 Thread Peter Ujfalusi
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2742867fd1e6..7891378a03f0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
return 0;
 }
 
+static int edma_dma_pause(struct edma_chan *echan)
+{
+   /* Pause/Resume only allowed with cyclic mode */
+   if (!echan-edesc-cyclic)
+   return -EINVAL;
+
+   edma_pause(echan-ch_num);
+   return 0;
+}
+
+static int edma_dma_resume(struct edma_chan *echan)
+{
+   /* Pause/Resume only allowed with cyclic mode */
+   if (!echan-edesc-cyclic)
+   return -EINVAL;
+
+   edma_resume(echan-ch_num);
+   return 0;
+}
+
 static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
unsigned long arg)
 {
@@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum 
dma_ctrl_cmd cmd,
config = (struct dma_slave_config *)arg;
ret = edma_slave_config(echan, config);
break;
+   case DMA_PAUSE:
+   ret = edma_dma_pause(echan);
+   break;
+
+   case DMA_RESUME:
+   ret = edma_dma_resume(echan);
+   break;
+
default:
ret = -ENOSYS;
}
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 06/14] arm: common: edma: Save the number of event queues/TCs

2014-04-01 Thread Peter Ujfalusi
For later use save the number of queues available for the CC.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 arch/arm/common/edma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 19520e2519d9..be267b2080be 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1770,6 +1770,9 @@ static int edma_probe(struct platform_device *pdev)
map_queue_tc(j, queue_tc_mapping[i][0],
queue_tc_mapping[i][1]);
 
+   /* Save the number of TCs */
+   edma_cc[j]-num_tc = i;
+
/* Event queue priority mapping */
for (i = 0; queue_priority_mapping[i][0] != -1; i++)
assign_priority_to_queue(j,
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 09/14] dma: edma: Implement device_slave_caps callback

2014-04-01 Thread Peter Ujfalusi
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 10048b40fac8..855766672aa9 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -855,6 +855,23 @@ static void __init edma_chan_init(struct edma_cc *ecc,
}
 }
 
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int edma_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+   caps-src_addr_widths = EDMA_DMA_BUSWIDTHS;
+   caps-dstn_addr_widths = EDMA_DMA_BUSWIDTHS;
+   caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+   caps-cmd_pause = true;
+   caps-cmd_terminate = true;
+   caps-residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+
+   return 0;
+}
+
 static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
  struct device *dev)
 {
@@ -865,6 +882,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
dma-device_issue_pending = edma_issue_pending;
dma-device_tx_status = edma_tx_status;
dma-device_control = edma_control;
+   dma-device_slave_caps = edma_dma_device_slave_caps;
dma-dev = dev;
 
INIT_LIST_HEAD(dma-channels);
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 12/14] dma: edma: Prefix debug prints where the text were identical in prep callbacks

2014-04-01 Thread Peter Ujfalusi
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e8de2e84a60a..7feb6231276e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -434,14 +434,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -457,7 +457,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
@@ -526,7 +527,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
@@ -551,7 +552,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -569,7 +570,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 10/14] dma: edma: Simplify direction configuration in edma_config_pset()

2014-04-01 Thread Peter Ujfalusi
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 855766672aa9..d954099650ae 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -372,14 +372,12 @@ static int edma_config_pset(struct dma_chan *chan, struct 
edmacc_param *pset,
src_cidx = cidx;
dst_bidx = 0;
dst_cidx = 0;
-   } else if (direction == DMA_DEV_TO_MEM)  {
+   } else {
+   /* DMA_DEV_TO_MEM */
src_bidx = 0;
src_cidx = 0;
dst_bidx = acnt;
dst_cidx = cidx;
-   } else {
-   dev_err(dev, %s: direction not implemented yet\n, __func__);
-   return -EINVAL;
}
 
pset-opt = EDMA_TCC(EDMA_CHAN_SLOT(echan-ch_num));
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 08/14] DMA: edma: Use different eventq for cyclic channels

2014-04-01 Thread Peter Ujfalusi
To improve latency with cyclic DMA operation it is preferred to
use different eventq/tc than the default which is used by all
other drivers (mmc, spi, i2c, etc).
When preparing the cyclic dma ask for non default queue for the
channel which is going to be used with cyclic mode.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 1dd9e8806975..10048b40fac8 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-pset[i].opt |= TCINTEN;
}
 
+   /* Use different eventq/tc for cyclic DMA to reduce latency */
+   edma_request_non_default_queue(echan-ch_num);
+
return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags);
 }
 
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 11/14] dma: edma: Reduce debug print verbosity for non verbose debugging

2014-04-01 Thread Peter Ujfalusi
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d954099650ae..e8de2e84a60a 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i  nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
-   dev_dbg(echan-vchan.chan.device-dev,
+   dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
@@ -558,9 +558,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
 
-   dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
-   dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
-   dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+   dev_dbg(dev, %s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n,
+   __func__, echan-ch_num, nslots, period_len, buf_len);
 
for (i = 0; i  nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -594,8 +593,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
 
-   dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
-   dev_dbg(dev,
+   dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+   dev_vdbg(dev,
\n pset[%d]:\n
  chnum\t%d\n
  slot\t%d\n
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 13/14] dma: edma: Add channel number to debug prints

2014-04-01 Thread Peter Ujfalusi
It helps to identify issues if we have some information regarding to the
channel which the event is associated.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7feb6231276e..2413237840f8 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -185,7 +185,8 @@ static void edma_execute(struct edma_chan *echan)
edma_resume(echan-ch_num);
 
if (edesc-processed = MAX_NR_SG) {
-   dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+   dev_dbg(dev, first transfer starting on channel %d\n,
+   echan-ch_num);
edma_start(echan-ch_num);
}
 
@@ -195,7 +196,7 @@ static void edma_execute(struct edma_chan *echan)
 * MAX_NR_SG
 */
if (echan-missed) {
-   dev_dbg(dev, missed event in execute detected\n);
+   dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -736,7 +737,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
 
-   dev_dbg(dev, allocated channel for %u:%u\n,
+   dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
 
return 0;
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH v2 14/14] dma: edma: Print the direction value as well when it is not supported

2014-04-01 Thread Peter Ujfalusi
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2413237840f8..912bf0190f45 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -430,7 +430,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
@@ -523,7 +523,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
-- 
1.9.1

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 00/18] edma/ASoC: dmaengine PCM for AM335x and AM447x

2014-03-14 Thread Peter Ujfalusi
On 03/13/2014 03:46 PM, Mark Brown wrote:
 On Thu, Mar 13, 2014 at 11:18:22AM +0200, Peter Ujfalusi wrote:
 
 With this series AM335x and AM447x will use the dmaengine PCM for audio. The
 daVinci devices will keep using the davinci-pcm for now since I do not have
 means to test them but the code is written in a way that they can be switched
 to use the edma-pcm easily (DA850/OMAP-L138 has been tested and audio was
 working fine).
 
 Can you please not resend the ASoC portions of this series until the
 EDMA portion is stable (and ideally committed)?  I'm not quite sure why
 but every EDMA patch series seems to go through lots of iterations which
 gets rather noisy - my initial reaction to seeing EDMA in a subject is
 to just delete the thread.

Sure, I'm not planning to spam alsa-devel however the switch to dmaengine PCM
for AM335x/AM447x needs the edma patches, otherwise it is not going to work.
AFAIK I have not sent patch to edma as of now so I have no idea how long it
takes to get stuff in (the good thing is that the edma part does not touch DT,
which is alone can reduce the number of iterations).
Anyway, what I can - and already did is:
Reorder the ASoC patches and I can leave out the switch to dmaengine PCM patch
for davinci-mcasp for now. The edma-pcm and the other patches for McASP can go
in right away (I will not add the edma-pcm to the Makefile/Kconfig to avoid
issues).

I will detach the edma stuff and follow it up outside of alsa-devel.

The only thing I'm afraid off is that it is going to take two release cycle to
get this in: first cycle edma part, next cycle for the ASoC to switch to use
the edma-pcm.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 08/18] dma: edma: Implement device_slave_caps callback

2014-03-13 Thread Peter Ujfalusi
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 604c7c94c731..1877319379fc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -851,6 +851,23 @@ static void __init edma_chan_init(struct edma_cc *ecc,
}
 }
 
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int edma_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+   caps-src_addr_widths = EDMA_DMA_BUSWIDTHS;
+   caps-dstn_addr_widths = EDMA_DMA_BUSWIDTHS;
+   caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+   caps-cmd_pause = true;
+   caps-cmd_terminate = true;
+   caps-residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+
+   return 0;
+}
+
 static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
  struct device *dev)
 {
@@ -861,6 +878,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct 
dma_device *dma,
dma-device_issue_pending = edma_issue_pending;
dma-device_tx_status = edma_tx_status;
dma-device_control = edma_control;
+   dma-device_slave_caps = edma_dma_device_slave_caps;
dma-dev = dev;
 
INIT_LIST_HEAD(dma-channels);
-- 
1.9.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 11/18] dma: edma: Prefix debug prints where the text were identical in prep callbacks

2014-03-13 Thread Peter Ujfalusi
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e2aa42b8342f..07ac5f4eeb56 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -430,14 +430,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -453,7 +453,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
@@ -522,7 +523,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
 
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
-   dev_err(dev, Undefined slave buswidth\n);
+   dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
 
@@ -547,7 +548,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
-   dev_dbg(dev, Failed to allocate a descriptor\n);
+   dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
 
@@ -565,7 +566,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan-slot[i]  0) {
kfree(edesc);
-   dev_err(dev, Failed to allocate slot\n);
+   dev_err(dev, %s: Failed to allocate slot\n,
+   __func__);
return NULL;
}
}
-- 
1.9.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 17/18] ASoC: davinci-mcasp: Assign the dma_data earlier in dai_probe callback

2014-03-13 Thread Peter Ujfalusi
Remove the dai startup callback and do the dma_data setup for dmaengine
in the dai_probe function.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/davinci/davinci-mcasp.c | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index 5428615413e2..958933614ca4 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -717,31 +717,33 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream 
*substream,
return ret;
 }
 
-static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
-struct snd_soc_dai *dai)
+static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
+   .trigger= davinci_mcasp_trigger,
+   .hw_params  = davinci_mcasp_hw_params,
+   .set_fmt= davinci_mcasp_set_dai_fmt,
+   .set_clkdiv = davinci_mcasp_set_clkdiv,
+   .set_sysclk = davinci_mcasp_set_sysclk,
+};
+
+static int davinci_mcasp_dai_probe(struct snd_soc_dai *dai)
 {
struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(dai);
 
-   if (mcasp-version = MCASP_VERSION_3)
+   if (mcasp-version = MCASP_VERSION_3) {
/* Using dmaengine PCM */
-   snd_soc_dai_set_dma_data(dai, substream,
-   mcasp-dma_data[substream-stream]);
-   else
+   dai-playback_dma_data =
+   mcasp-dma_data[SNDRV_PCM_STREAM_PLAYBACK];
+   dai-capture_dma_data =
+   mcasp-dma_data[SNDRV_PCM_STREAM_CAPTURE];
+   } else {
/* Using davinci-pcm */
-   snd_soc_dai_set_dma_data(dai, substream, mcasp-dma_params);
+   dai-playback_dma_data = mcasp-dma_params;
+   dai-capture_dma_data = mcasp-dma_params;
+   }
 
return 0;
 }
 
-static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
-   .startup= davinci_mcasp_startup,
-   .trigger= davinci_mcasp_trigger,
-   .hw_params  = davinci_mcasp_hw_params,
-   .set_fmt= davinci_mcasp_set_dai_fmt,
-   .set_clkdiv = davinci_mcasp_set_clkdiv,
-   .set_sysclk = davinci_mcasp_set_sysclk,
-};
-
 #ifdef CONFIG_PM_SLEEP
 static int davinci_mcasp_suspend(struct snd_soc_dai *dai)
 {
@@ -795,6 +797,7 @@ static int davinci_mcasp_resume(struct snd_soc_dai *dai)
 static struct snd_soc_dai_driver davinci_mcasp_dai[] = {
{
.name   = davinci-mcasp.0,
+   .probe  = davinci_mcasp_dai_probe,
.suspend= davinci_mcasp_suspend,
.resume = davinci_mcasp_resume,
.playback   = {
-- 
1.9.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 13/18] dma: edma: Print the direction value as well when it is not supported

2014-03-13 Thread Peter Ujfalusi
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 drivers/dma/edma.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 47abaac7eb18..69dd4e3de67e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -426,7 +426,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
@@ -519,7 +519,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
-   dev_err(dev, %s: bad direction?\n, __func__);
+   dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
 
-- 
1.9.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH 18/18] ASoC: davinci-mcasp: Place constraint on the period size based on FIFO config

2014-03-13 Thread Peter Ujfalusi
We need to place constraint on the period size (and indirectly to buffer
size) if the read or write AFIFO is enabled and it is configured for more
than one word otherwise the DMA will fail in buffer configuration where
the sizes are not aligned with the requested FIFO configuration.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
 sound/soc/davinci/davinci-mcasp.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/sound/soc/davinci/davinci-mcasp.c 
b/sound/soc/davinci/davinci-mcasp.c
index 958933614ca4..17d1112bce24 100644
--- a/sound/soc/davinci/davinci-mcasp.c
+++ b/sound/soc/davinci/davinci-mcasp.c
@@ -717,7 +717,27 @@ static int davinci_mcasp_trigger(struct snd_pcm_substream 
*substream,
return ret;
 }
 
+static int davinci_mcasp_startup(struct snd_pcm_substream *substream,
+struct snd_soc_dai *cpu_dai)
+{
+   struct davinci_mcasp *mcasp = snd_soc_dai_get_drvdata(cpu_dai);
+   int afifo_numevt;
+
+   if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
+   afifo_numevt = mcasp-txnumevt;
+   else
+   afifo_numevt = mcasp-rxnumevt;
+
+   if (afifo_numevt  1)
+   snd_pcm_hw_constraint_step(substream-runtime, 0,
+  SNDRV_PCM_HW_PARAM_PERIOD_SIZE,
+  afifo_numevt);
+
+   return 0;
+}
+
 static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = {
+   .startup= davinci_mcasp_startup,
.trigger= davinci_mcasp_trigger,
.hw_params  = davinci_mcasp_hw_params,
.set_fmt= davinci_mcasp_set_dai_fmt,
-- 
1.9.0

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [alsa-devel] [PATCH 14/18] ASoC: davinci: Add edma dmaengine platform driver

2014-03-13 Thread Peter Ujfalusi
On 03/13/2014 12:28 PM, Lars-Peter Clausen wrote:
 +int edma_pcm_platform_register(struct device *dev)
 +{
 +if (dev-of_node)
 +return snd_dmaengine_pcm_register(dev,
 +edma_dmaengine_pcm_config,
 +SND_DMAENGINE_PCM_FLAG_NO_RESIDUE);
 
 Since the edma dmaengine driver implements the slave cap API there is no need
 to manually specify SND_DMAENGINE_PCM_FLAG_NO_RESIDUE manually. But since the
 edma driver sets the granularity to DMA_RESIDUE_GRANULARITY_DESCRIPTOR in this
 case the generic dmaengine will not set SND_DMAENGINE_PCM_FLAG_NO_RESIDUE
 automatically since it assumes that the dmaengine driver is capable of
 properly reporting the DMA position.

Hrm, I see. For eDMA I think we can support DMA_RESIDUE_GRANULARITY_SEGMENT
granularity. Since according to the documentation the _SEGMENT means that the
DMA position will be updated per periods, which is basically the same thing
what we are doing at the moment when the granularity is
DMA_RESIDUE_GRANULARITY_DESCRIPTOR.
From ALSA point of view at least they are the same: neither of them can report
exact position, the DMA pointer jumps from period to period.

IMHO in the generic dmaengine PCM we should set the SNDRV_PCM_INFO_BATCH for
both cases.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [PATCH 10/18] dma: edma: Reduce debug print verbosity for non verbose debugging

2014-03-13 Thread Peter Ujfalusi
On 03/13/2014 02:53 PM, Shevchenko, Andriy wrote:
 On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
 Do not print the paRAM information when verbose debugging is not asked and
 also reduce the number of lines printed in edma_prep_dma_cyclic()

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index e4f4a0cef58c..e2aa42b8342f 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
  for (i = 0; i  nslots; i++) {
  j = i + edesc-processed;
  edma_write_slot(echan-slot[i], edesc-pset[j]);
 -dev_dbg(echan-vchan.chan.device-dev,
 +dev_vdbg(echan-vchan.chan.device-dev,
  \n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
 
 I believe you may move this code to separate function and reuse it
 later.

As the per patch description, I only changed the debug level in this patch.

 Moreover %d is not good specifier for unsigned types, maybe %u?

You are right for unsigned type %u is the correct. This is why we have %d
since j, echan-ch_num and echan-slot[i] are integer.

 
 @@ -554,9 +554,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
  edesc-cyclic = 1;
  edesc-pset_nr = nslots;
  
 -dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
 -dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
 -dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
 +dev_dbg(dev, %s: channel=%d nslots=%d period_len=%d buf_len=%d\n,
 +__func__, echan-ch_num, nslots, period_len, buf_len);
 
 Consider to use proper specifiers for size_t types, namely %zd.

I just collapsed the three line of dev_dbg into one and have not really
checked the formats.
For size_t the correct format should be %zu.
I'll fix this up for the next version.

  
  for (i = 0; i  nslots; i++) {
  /* Allocate a PaRAM slot, if needed */
 @@ -590,8 +589,8 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
  else
  src_addr += period_len;
  
 -dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 -dev_dbg(dev,
 +dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
 +dev_vdbg(dev,
 
 See the first comment.

As the per patch description, I only changed the debug level in this patch.
This can be done as a separate patch later IMO as part of a bigger debug 
cleanup.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [alsa-devel] [PATCH 13/18] dma: edma: Print the direction value as well when it is not supported

2014-03-13 Thread Peter Ujfalusi
On 03/13/2014 03:03 PM, Shevchenko, Andriy wrote:
 On Thu, 2014-03-13 at 11:18 +0200, Peter Ujfalusi wrote:
 In case of not supported direction it is better to print the direction also.
 It is unlikely, but in such an event it helps with the debugging.

 Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
 ---
  drivers/dma/edma.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
 index 47abaac7eb18..69dd4e3de67e 100644
 --- a/drivers/dma/edma.c
 +++ b/drivers/dma/edma.c
 @@ -426,7 +426,7 @@ static struct dma_async_tx_descriptor 
 *edma_prep_slave_sg(
  dev_width = echan-cfg.dst_addr_width;
  burst = echan-cfg.dst_maxburst;
  } else {
 -dev_err(dev, %s: bad direction?\n, __func__);
 +dev_err(dev, %s: bad direction: %d\n, __func__, direction);
 
 Is it possible to have direction less than zero? Maybe %u?

It is 'enum dma_transfer_direction direction'. %d should be fine.

 
  return NULL;
  }
  
 @@ -519,7 +519,7 @@ static struct dma_async_tx_descriptor 
 *edma_prep_dma_cyclic(
  dev_width = echan-cfg.dst_addr_width;
  burst = echan-cfg.dst_maxburst;
  } else {
 -dev_err(dev, %s: bad direction?\n, __func__);
 +dev_err(dev, %s: bad direction: %d\n, __func__, direction);
 
 Ditto.
 
  return NULL;
  }
  
 
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


[PATCH] ARM: davinci: Fix McASP mem resource names

2013-11-13 Thread Peter Ujfalusi
The ASoC McASP driver looks for the mem resources by name and:
mpu and dat regions.
Change/add the needed name for the mem resources so the driver can pick the
correct resource.

Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Hi,

This is needed for 3.13.

Regards,
Peter

 arch/arm/mach-davinci/devices-da8xx.c | 4 ++--
 arch/arm/mach-davinci/dm355.c | 1 +
 arch/arm/mach-davinci/dm365.c | 1 +
 arch/arm/mach-davinci/dm644x.c| 1 +
 arch/arm/mach-davinci/dm646x.c| 4 ++--
 5 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-davinci/devices-da8xx.c 
b/arch/arm/mach-davinci/devices-da8xx.c
index c46eccb..78829c5 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -487,7 +487,7 @@ int __init da8xx_register_emac(void)
 
 static struct resource da830_mcasp1_resources[] = {
{
-   .name   = mcasp1,
+   .name   = mpu,
.start  = DAVINCI_DA830_MCASP1_REG_BASE,
.end= DAVINCI_DA830_MCASP1_REG_BASE + (SZ_1K * 12) - 1,
.flags  = IORESOURCE_MEM,
@@ -515,7 +515,7 @@ static struct platform_device da830_mcasp1_device = {
 
 static struct resource da850_mcasp_resources[] = {
{
-   .name   = mcasp,
+   .name   = mpu,
.start  = DAVINCI_DA8XX_MCASP0_REG_BASE,
.end= DAVINCI_DA8XX_MCASP0_REG_BASE + (SZ_1K * 12) - 1,
.flags  = IORESOURCE_MEM,
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index ef9ff1f..d4baf4f 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -641,6 +641,7 @@ static struct platform_device dm355_edma_device = {
 
 static struct resource dm355_asp1_resources[] = {
{
+   .name   = mpu,
.start  = DAVINCI_ASP1_BASE,
.end= DAVINCI_ASP1_BASE + SZ_8K - 1,
.flags  = IORESOURCE_MEM,
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 1511a06..9c68e3f 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -942,6 +942,7 @@ static struct platform_device dm365_edma_device = {
 
 static struct resource dm365_asp_resources[] = {
{
+   .name   = mpu,
.start  = DAVINCI_DM365_ASP0_BASE,
.end= DAVINCI_DM365_ASP0_BASE + SZ_8K - 1,
.flags  = IORESOURCE_MEM,
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 143a321..79847d0 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -572,6 +572,7 @@ static struct platform_device dm644x_edma_device = {
 /* DM6446 EVM uses ASP0; line-out is a pair of RCA jacks */
 static struct resource dm644x_asp_resources[] = {
{
+   .name   = mpu,
.start  = DAVINCI_ASP0_BASE,
.end= DAVINCI_ASP0_BASE + SZ_8K - 1,
.flags  = IORESOURCE_MEM,
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 2a73f29..45de58c 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -621,7 +621,7 @@ static struct platform_device dm646x_edma_device = {
 
 static struct resource dm646x_mcasp0_resources[] = {
{
-   .name   = mcasp0,
+   .name   = mpu,
.start  = DAVINCI_DM646X_MCASP0_REG_BASE,
.end= DAVINCI_DM646X_MCASP0_REG_BASE + (SZ_1K  1) - 1,
.flags  = IORESOURCE_MEM,
@@ -641,7 +641,7 @@ static struct resource dm646x_mcasp0_resources[] = {
 
 static struct resource dm646x_mcasp1_resources[] = {
{
-   .name   = mcasp1,
+   .name   = mpu,
.start  = DAVINCI_DM646X_MCASP1_REG_BASE,
.end= DAVINCI_DM646X_MCASP1_REG_BASE + (SZ_1K  1) - 1,
.flags  = IORESOURCE_MEM,
-- 
1.8.4.2

___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [alsa-devel] [PATCH 1/2] ASoC: tlv320aic3x: Convert mic bias to a supply widget

2013-01-31 Thread Peter Ujfalusi
On 01/30/2013 02:22 PM, Hebbar Gururaja wrote:
 @@ -1493,6 +1544,28 @@ static int aic3x_i2c_probe(struct i2c_client *i2c,
   aic3x-setup = ai3x_setup;
   }
  
 + if (!of_property_read_u32(np, ai3x-micbias-vg, value)) {
 + switch (value) {
 + case 1 :
 + aic3x-micbias_vg = AIC3X_MICBIAS_2_0V;
 + break;
 + case 2 :
 + aic3x-micbias_vg = AIC3X_MICBIAS_2_5V;
 + break;
 + case 3 :
 + aic3x-micbias_vg = AIC3X_MICBIAS_AVDDV;
 + break;
 + default :
 + aic3x-micbias_vg = AIC3X_MICBIAS_OFF;
 + dev_err(i2c-dev, Unsuitable MicBias voltage 
 + found in DT\n);
 + }
 + } else {
 + dev_warn(i2c-dev, No MicBias voltage found in DT - 
 + using default\n);

Since ai3x-micbias-vg property is optional I don't think it is appropriate
to print anything here. If you really want a note about this it should be
dev_info().

 + aic3x-micbias_vg = AIC3X_MICBIAS_OFF;
 + }
 +
   } else {
   aic3x-gpio_reset = -1;
   }
 diff --git a/sound/soc/codecs/tlv320aic3x.h b/sound/soc/codecs/tlv320aic3x.h
 index 6db3c41..e521ac3 100644
 --- a/sound/soc/codecs/tlv320aic3x.h
 +++ b/sound/soc/codecs/tlv320aic3x.h
 @@ -238,6 +238,10 @@
  /* Default input volume */
  #define DEFAULT_GAIN0x20
  
 +/* MICBIAS Control Register */
 +#define MICBIAS_LEVEL_SHIFT  (6)
 +#define MICBIAS_LEVEL_MASK   (3  6)
 +
  /* headset detection / button API */
  
  /* The AIC3x supports detection of stereo headsets (GND + left + right 
 signal)
 


-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source


Re: [alsa-devel] [PATCH 2/3] ASoC: Davinci: pcm: add support for sram-support-less platforms

2012-10-02 Thread Peter Ujfalusi
On 09/22/2012 06:33 PM, Mark Brown wrote:
 On Fri, Aug 31, 2012 at 06:20:58PM +0530, Hebbar, Gururaja wrote:
 
 +config SND_DAVINCI_HAVE_SRAM
 +bool
 +default y if ARCH_DAVINCI=y
 +default n if ARCH_OMAP=y
 +
 
 I've been sitting on this mostly since it seems like a step back from
 multi-platform kernels (which is where we're trying to get to) and I've
 been trying to decide what the best approach is.  I'm thinking that we
 do want a generic API for allocating this stuff, it's a fairly generic
 feature (there's TCMs as well).  
 
 Adding ifdefs like this does just doesn't seem good.

I also agree that ifdef is not a good solution.
It is better to have this information passed as device_data and via DT it can
be decided based on the compatible property for the device.

-- 
Péter
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source