Re: [PATCH] ASoC: Intel: Atom: ix spelling mistake: "allocationf" -> "allocation"

[Koul, Vinod]

On Tue, 2017-02-21 at 16:50 +, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in dev_err message.

Acked-by: Vinod Koul 

-- 
~Vinod

Re: [PATCH] ASoC: Intel: Atom: ix spelling mistake: "allocationf" -> "allocation"

[Koul, Vinod]

On Tue, 2017-02-21 at 16:50 +, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in dev_err message.

Acked-by: Vinod Koul 

-- 
~Vinod

Re: [PATCH] dmaengine: st_fdma: Update st_fdma to 'depends on REMOTEPROC'.

[Koul, Vinod]

On Fri, 2016-10-21 at 09:44 +0100, Peter Griffin wrote:
> During randconfig builds you can get the following warning
> "warning: (ST_FDMA) selects ST_SLIM_REMOTEPROC which has unmet direct
>  dependencies (REMOTEPROC)"
> 
> randconfig builds should always build without any warnings so
> update fdma to depend on REMOTEPROC so this can not happen.

Applied, thanks

-- 
~Vinod

Re: [PATCH] dmaengine: st_fdma: Update st_fdma to 'depends on REMOTEPROC'.

[Koul, Vinod]

On Fri, 2016-10-21 at 09:44 +0100, Peter Griffin wrote:
> During randconfig builds you can get the following warning
> "warning: (ST_FDMA) selects ST_SLIM_REMOTEPROC which has unmet direct
>  dependencies (REMOTEPROC)"
> 
> randconfig builds should always build without any warnings so
> update fdma to depend on REMOTEPROC so this can not happen.

Applied, thanks

-- 
~Vinod

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Koul, Vinod]

On Sun, 2016-10-30 at 10:06 +0800, Chen-Yu Tsai wrote:
> Looking at the dmaengine API, I believe we got it wrong.
> 
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:

Not a single transfer but smallest transaction within a transfer of a
block. So dmaengines transfer data in bursts from source to destination,
this parameter decides the size of that bursts

> 
>  * @src_maxburst: the maximum number of words (note: words, as in
>  * units of the src_addr_width member, not bytes) that can be sent
>  * in one burst to the device. Typically something like half the
>  * FIFO depth on I/O peripherals so you don't overflow it. This
>  * may or may not be applicable on memory sources.
>  * @dst_maxburst: same as src_maxburst but for destination target
>  * mutatis mutandis.
> 
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.

Nope, the client configures these parameters and dmaengine driver
validates and programs

> 
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.

Beware that higher bursts means chance of underrun of FIFO. This value
is selected with consideration of power and performance required. Lazy
allocation would be half of FIFO size..

-- 
~Vinod

Re: [PATCH 01/14] dma: sun6i-dma: Add burst case of 4

[Koul, Vinod]

On Sun, 2016-10-30 at 10:06 +0800, Chen-Yu Tsai wrote:
> Looking at the dmaengine API, I believe we got it wrong.
> 
> max_burst in dma_slave_config denotes the largest amount of data
> a single transfer should be, as described in dmaengine.h:

Not a single transfer but smallest transaction within a transfer of a
block. So dmaengines transfer data in bursts from source to destination,
this parameter decides the size of that bursts

> 
>  * @src_maxburst: the maximum number of words (note: words, as in
>  * units of the src_addr_width member, not bytes) that can be sent
>  * in one burst to the device. Typically something like half the
>  * FIFO depth on I/O peripherals so you don't overflow it. This
>  * may or may not be applicable on memory sources.
>  * @dst_maxburst: same as src_maxburst but for destination target
>  * mutatis mutandis.
> 
> The DMA engine driver should be free to select whatever burst size
> that doesn't exceed this. So for max_burst = 4, the driver can select
> burst = 4 for controllers that do support it, or burst = 1 for those
> that don't, and do more bursts.

Nope, the client configures these parameters and dmaengine driver
validates and programs

> 
> This also means we can increase max_burst for the audio codec, as
> the FIFO is 64 samples deep for stereo, or 128 samples for mono.

Beware that higher bursts means chance of underrun of FIFO. This value
is selected with consideration of power and performance required. Lazy
allocation would be half of FIFO size..

-- 
~Vinod

Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Koul, Vinod]

On Wed, 2016-04-06 at 16:00 -0700, Sören Brinkmann wrote:
> On Wed, 2016-04-06 at 22:13:59 +0000, Koul, Vinod wrote:
> > On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> > > On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.t
> > > > > > xt
> > > > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > > > {3}, flush s2mm channel
> > > > > > 
> > > > > >  Required child node properties:
> > > > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s
> > > > > > -channel"
> > > > > > or
> > > > > > -   "xlnx,axi-vdma-s2mm-channel".
> > > > > > +- compatible: It should be either "xlnx,axi-dma-mm2s
> > > > > > -channel"
> > > > > > or
> > > > > > +   "xlnx,axi-dma-s2mm-channel".
> > > > > 
> > > > > This change is not backwards compatible and breaks every user
> > > > > of
> > > > > the current
> > > > > binding.
> > > > 
> > > > This commit 
> > > > http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > > > dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0b
> > > > fa 
> > > > Renames xilinx_vdma_ prefix to xilinx_dma which includes
> > > > renaming of
> > > > the above properties.
> > 
> > That patch changes driver from vdma to dma. It does not change
> > property
> > name!
> 
> It does. Unfortunately there are no line numbers on that website,
> hence here an excerpt
> from the commit you mention:
> @@ -1220,26 +1220,26 @@ static int xilinx_vdma_chan_probe(struct
> xilinx_vdma_device *xdev,
>   if (!has_dre)
>   xdev->common.copy_align = fls(width - 1);
>  
> - if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s
> -channel")) {
> + if (of_device_is_compatible(node, "xlnx,axi-dma-mm2s
> -channel")) {
>   chan->direction = DMA_MEM_TO_DEV;
>   chan->id = 0;

Right, missed that somehow.

Am dropping the patch

-- 
~Vinod

Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Koul, Vinod]

On Wed, 2016-04-06 at 16:00 -0700, Sören Brinkmann wrote:
> On Wed, 2016-04-06 at 22:13:59 +0000, Koul, Vinod wrote:
> > On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> > > On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > > > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > > > +++
> > > > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.t
> > > > > > xt
> > > > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > > > {3}, flush s2mm channel
> > > > > > 
> > > > > >  Required child node properties:
> > > > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s
> > > > > > -channel"
> > > > > > or
> > > > > > -   "xlnx,axi-vdma-s2mm-channel".
> > > > > > +- compatible: It should be either "xlnx,axi-dma-mm2s
> > > > > > -channel"
> > > > > > or
> > > > > > +   "xlnx,axi-dma-s2mm-channel".
> > > > > 
> > > > > This change is not backwards compatible and breaks every user
> > > > > of
> > > > > the current
> > > > > binding.
> > > > 
> > > > This commit 
> > > > http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > > > dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0b
> > > > fa 
> > > > Renames xilinx_vdma_ prefix to xilinx_dma which includes
> > > > renaming of
> > > > the above properties.
> > 
> > That patch changes driver from vdma to dma. It does not change
> > property
> > name!
> 
> It does. Unfortunately there are no line numbers on that website,
> hence here an excerpt
> from the commit you mention:
> @@ -1220,26 +1220,26 @@ static int xilinx_vdma_chan_probe(struct
> xilinx_vdma_device *xdev,
>   if (!has_dre)
>   xdev->common.copy_align = fls(width - 1);
>  
> - if (of_device_is_compatible(node, "xlnx,axi-vdma-mm2s
> -channel")) {
> + if (of_device_is_compatible(node, "xlnx,axi-dma-mm2s
> -channel")) {
>   chan->direction = DMA_MEM_TO_DEV;
>   chan->id = 0;

Right, missed that somehow.

Am dropping the patch

-- 
~Vinod

Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Koul, Vinod]

On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > {3}, flush s2mm channel
> > > > 
> > > >  Required child node properties:
> > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s-channel"
> > > > or
> > > > -   "xlnx,axi-vdma-s2mm-channel".
> > > > +- compatible: It should be either "xlnx,axi-dma-mm2s-channel"
> > > > or
> > > > +   "xlnx,axi-dma-s2mm-channel".
> > > 
> > > This change is not backwards compatible and breaks every user of
> > > the current
> > > binding.
> > 
> > This commit http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0bfa 
> > Renames xilinx_vdma_ prefix to xilinx_dma which includes renaming of
> > the above properties.

That patch changes driver from vdma to dma. It does not change property
name!

> > The patch (dmaengine: vdma: Rename xilinx_vdma_ prefix to
> > xilinx_dma) already got applied in the dma-next tree.
> > That's why sent this patch to sync with the current driver I mean
> > latest driver.
> 
> The correct solution for this is to revert that part of the change
> ASAP,
> since, as Soeren pointed out, it breaks all existing users.

No the commit applied is only the name changes inside the driver. They
don't break anything yet. IIUC this patch breaks not the applied one..

Thanks
-- 
~Vinod

Re: [PATCH v3 1/5] Documentation: DT: vdma: Rename vdma-chan prefix to dma-chan

[Koul, Vinod]

On Wed, 2016-04-06 at 23:16 +0200, Lars-Peter Clausen wrote:
> On 04/06/2016 06:25 PM, Appana Durga Kedareswara Rao wrote:
> > a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > +++
> > > > b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
> > > > @@ -24,8 +24,8 @@ Optional properties:
> > > > {3}, flush s2mm channel
> > > > 
> > > >  Required child node properties:
> > > > -- compatible: It should be either "xlnx,axi-vdma-mm2s-channel"
> > > > or
> > > > -   "xlnx,axi-vdma-s2mm-channel".
> > > > +- compatible: It should be either "xlnx,axi-dma-mm2s-channel"
> > > > or
> > > > +   "xlnx,axi-dma-s2mm-channel".
> > > 
> > > This change is not backwards compatible and breaks every user of
> > > the current
> > > binding.
> > 
> > This commit http://git.kernel.org/cgit/linux/kernel/git/vkoul/slave-
> > dma.git/commit/?h=next=8e66e7d682b04f7141f8ae666908c8dcd7fc0bfa 
> > Renames xilinx_vdma_ prefix to xilinx_dma which includes renaming of
> > the above properties.

That patch changes driver from vdma to dma. It does not change property
name!

> > The patch (dmaengine: vdma: Rename xilinx_vdma_ prefix to
> > xilinx_dma) already got applied in the dma-next tree.
> > That's why sent this patch to sync with the current driver I mean
> > latest driver.
> 
> The correct solution for this is to revert that part of the change
> ASAP,
> since, as Soeren pointed out, it breaks all existing users.

No the commit applied is only the name changes inside the driver. They
don't break anything yet. IIUC this patch breaks not the applied one..

Thanks
-- 
~Vinod

Re: [PATCH v3 01/15] dmaengine: dw: fix master selection

[Koul, Vinod]

On Wed, 2016-04-06 at 22:56 +0300, Andy Shevchenko wrote:
> On Wed, Apr 6, 2016 at 9:56 PM, Vinod Koul 
> wrote:
> > On Mon, Apr 04, 2016 at 08:10:54PM +0300, Andy Shevchenko wrote:
> > > On Mon, 2016-04-04 at 10:03 -0700, Vinod Koul wrote:
> > > > On Fri, Mar 18, 2016 at 04:24:40PM +0200, Andy Shevchenko wrote:
> > > > > 
> > > > > + /*
> > > > > +  * We need controller-specific data to set up slave
> > > > > transfers.
> > > > > +  */
> > > > > + BUG_ON(chan->private && !dw_dma_filter(chan, chan-
> > > > > > private));
> > > > I don't think BUG_ON is apt here, gracefully failing and
> > > > printing
> > > > that can
> > > > be better..
> > > 
> > > Hm, this is coming from the existing code.
> > > 
> > > I would prefer to keep this one as is since it's targeted to
> > > stable@,
> > > and I may issue sequential patch to replace BUG_ON. Sounds okay?
> > 
> > But since this is going stable, how about we remove here in the
> > patch and
> > benefit stable tree as well?
> 
> I'm fine with that. I will send you patch tomorrow.Other than that do
> we have any issues with the rest?

I did look at few more they looked fine, but didn't look at entire
series


-- 
~Vinod

Re: [PATCH v3 01/15] dmaengine: dw: fix master selection

[Koul, Vinod]

On Wed, 2016-04-06 at 22:56 +0300, Andy Shevchenko wrote:
> On Wed, Apr 6, 2016 at 9:56 PM, Vinod Koul 
> wrote:
> > On Mon, Apr 04, 2016 at 08:10:54PM +0300, Andy Shevchenko wrote:
> > > On Mon, 2016-04-04 at 10:03 -0700, Vinod Koul wrote:
> > > > On Fri, Mar 18, 2016 at 04:24:40PM +0200, Andy Shevchenko wrote:
> > > > > 
> > > > > + /*
> > > > > +  * We need controller-specific data to set up slave
> > > > > transfers.
> > > > > +  */
> > > > > + BUG_ON(chan->private && !dw_dma_filter(chan, chan-
> > > > > > private));
> > > > I don't think BUG_ON is apt here, gracefully failing and
> > > > printing
> > > > that can
> > > > be better..
> > > 
> > > Hm, this is coming from the existing code.
> > > 
> > > I would prefer to keep this one as is since it's targeted to
> > > stable@,
> > > and I may issue sequential patch to replace BUG_ON. Sounds okay?
> > 
> > But since this is going stable, how about we remove here in the
> > patch and
> > benefit stable tree as well?
> 
> I'm fine with that. I will send you patch tomorrow.Other than that do
> we have any issues with the rest?

I did look at few more they looked fine, but didn't look at entire
series


-- 
~Vinod

Re: [PATCH 0/2] Bypass BAM init if Remotely controlled

[Koul, Vinod]

On Tue, 2016-04-05 at 16:21 -0500, Andy Gross wrote:
> On Tue, Apr 05, 2016 at 11:19:50AM -0700, Vinod Koul wrote:
> > On Tue, Mar 22, 2016 at 11:55:56AM +0200, Stanimir Varbanov wrote:
> > > On 03/22/2016 11:49 AM, Pramod Gurav wrote:
> > > > On some QOCM platforms(eg 8996) BAM control registers are
> > > > managed remotely
> > > > hence can not be accessed by application processor for writes.
> > > > So skip the bam_init
> > > > for any such platform if DT property is set.
> > > > 
> > > > Tested on 8996 (BAM Global control is through remote) and DB410C
> > > > boards.
> > > > Tested with i2c DMA on these targets which uses BAM as DMA
> > > > controller.
> > > 
> > > I have similar patches at [1] already, could you check them first.
> > 
> > was there an update posted on these? I dont have this series or an
> > update in
> > my queue
> 
> No updates that I can see.  The original is here:
> 
> https://lkml.org/lkml/2015/12/1/113
> 

And that seemed to have some discussion so I dont recall looking at it. 

-- 
~Vinod

Re: [PATCH 0/2] Bypass BAM init if Remotely controlled

[Koul, Vinod]

On Tue, 2016-04-05 at 16:21 -0500, Andy Gross wrote:
> On Tue, Apr 05, 2016 at 11:19:50AM -0700, Vinod Koul wrote:
> > On Tue, Mar 22, 2016 at 11:55:56AM +0200, Stanimir Varbanov wrote:
> > > On 03/22/2016 11:49 AM, Pramod Gurav wrote:
> > > > On some QOCM platforms(eg 8996) BAM control registers are
> > > > managed remotely
> > > > hence can not be accessed by application processor for writes.
> > > > So skip the bam_init
> > > > for any such platform if DT property is set.
> > > > 
> > > > Tested on 8996 (BAM Global control is through remote) and DB410C
> > > > boards.
> > > > Tested with i2c DMA on these targets which uses BAM as DMA
> > > > controller.
> > > 
> > > I have similar patches at [1] already, could you check them first.
> > 
> > was there an update posted on these? I dont have this series or an
> > update in
> > my queue
> 
> No updates that I can see.  The original is here:
> 
> https://lkml.org/lkml/2015/12/1/113
> 

And that seemed to have some discussion so I dont recall looking at it. 

-- 
~Vinod

Re: linux-next: build failure after merge of the slave-dma tree

[Koul, Vinod]

On Thu, 2015-10-15 at 11:51 +1100, Stephen Rothwell wrote:
> Hi Vinod,
> 
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/dma/idma64.h:19:47: fatal error: asm-generic/io-64-nonatomic-lo-hi.h: 
> No
> such file or directory
>  #include 
>^
> 
> Caused by commit
> 
>   97c37accd38f ("dmaengine: idma64: use lo_hi_readq() / lo_hi_writeq()")
> 
> interacting with commit
> 
>   f626fe17485b ("move io-64-nonatomic*.h out of asm-generic")
> 
> from the asm-generic tree.
> 
> I have applied the folling merge fix patch and can carry it as necessary.

Thanks Stephen, This looks fine to me.

So should I ask Linus to apply this fix once merge window opens or you will send
this, how do we go about fixing this one :)

Or should I merge the above commit from asm-generic tree?

-- 
~Vinod

Re: linux-next: build failure after merge of the slave-dma tree

[Koul, Vinod]

On Thu, 2015-10-15 at 11:51 +1100, Stephen Rothwell wrote:
> Hi Vinod,
> 
> After merging the slave-dma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/dma/idma64.h:19:47: fatal error: asm-generic/io-64-nonatomic-lo-hi.h: 
> No
> such file or directory
>  #include 
>^
> 
> Caused by commit
> 
>   97c37accd38f ("dmaengine: idma64: use lo_hi_readq() / lo_hi_writeq()")
> 
> interacting with commit
> 
>   f626fe17485b ("move io-64-nonatomic*.h out of asm-generic")
> 
> from the asm-generic tree.
> 
> I have applied the folling merge fix patch and can carry it as necessary.

Thanks Stephen, This looks fine to me.

So should I ask Linus to apply this fix once merge window opens or you will send
this, how do we go about fixing this one :)

Or should I merge the above commit from asm-generic tree?

-- 
~Vinod

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

[Koul, Vinod]

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

See SET_RUNTIME_PM_OPS and friends, defined in pm.h

-- 
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

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

[Koul, Vinod]

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

See SET_RUNTIME_PM_OPS and friends, defined in pm.h

-- 
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

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

[Koul, Vinod]

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

> +#define FDMA_ID_OFST 0x0
> +#define FDMA_VER_OFST0x4
> > +
> +#define FDMA_EN_OFST 0x8

Why cant these be BIT() to maintain consistency?

-- 
~Vinod

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

[Koul, Vinod]

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

> +#define FDMA_ID_OFST 0x0
> +#define FDMA_VER_OFST0x4
> > +
> +#define FDMA_EN_OFST 0x8

Why cant these be BIT() to maintain consistency?

-- 
~Vinod

Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Koul, Vinod]

On Tue, 2015-10-06 at 09:15 +0300, Peter Ujfalusi wrote:
> Hi
> 
> On 09/24/2015 01:01 PM, Peter Ujfalusi wrote:
> > Hi,
> > 
> > Changes since v3:
> > - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got 
> > squashed
> >   by accident for v3
> > - Added Tony's Acked-by to patch 11 (for mach-oamp2 part)
> 
> Gentle ping on this series ;)

Its a long one :)

I hope to get this done next week after am back from Dublin

> 
-- 
~Vinod

Re: [PATCH v4 00/25] dmaengine/ARM: Merge the edma drivers into one

[Koul, Vinod]

On Tue, 2015-10-06 at 09:15 +0300, Peter Ujfalusi wrote:
> Hi
> 
> On 09/24/2015 01:01 PM, Peter Ujfalusi wrote:
> > Hi,
> > 
> > Changes since v3:
> > - Separated the two (patch 10/11 in v2 patch 10 in v3) patch which got 
> > squashed
> >   by accident for v3
> > - Added Tony's Acked-by to patch 11 (for mach-oamp2 part)
> 
> Gentle ping on this series ;)

Its a long one :)

I hope to get this done next week after am back from Dublin

> 
-- 
~Vinod

Re: [PATCH v6 2/2] dmaengine: Add Xilinx AXI Central Direct Memory Access Engine driver support

[Koul, Vinod]

On Mon, 2015-10-05 at 13:50 +, Appana Durga Kedareswara Rao wrote:

> > 
> > On Mon, Sep 07, 2015 at 06:03:18PM +0530, Kedareswara rao Appana wrote:
> > > This is the driver for the AXI Central Direct Memory Access (AXI
> > > CDMA) core, which is a soft Xilinx IP core that provides
> > > high-bandwidth Direct Memory Access (DMA) between a memory-mapped
> > > source address and a memory-mapped destination address.
> > 
> > Where is the 1/2 here ? I have only this one in my mails..
> 
> You are there in the 1/2 not the dmaeng...@vger.kernel.org.

The threading is broken in your patch series. ON searching I found the 1/2. 
Please
make sure patch series are threaded properly.

-- 
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH v6 2/2] dmaengine: Add Xilinx AXI Central Direct Memory Access Engine driver support

[Koul, Vinod]

On Mon, 2015-10-05 at 13:50 +, Appana Durga Kedareswara Rao wrote:

> > 
> > On Mon, Sep 07, 2015 at 06:03:18PM +0530, Kedareswara rao Appana wrote:
> > > This is the driver for the AXI Central Direct Memory Access (AXI
> > > CDMA) core, which is a soft Xilinx IP core that provides
> > > high-bandwidth Direct Memory Access (DMA) between a memory-mapped
> > > source address and a memory-mapped destination address.
> > 
> > Where is the 1/2 here ? I have only this one in my mails..
> 
> You are there in the 1/2 not the dmaeng...@vger.kernel.org.

The threading is broken in your patch series. ON searching I found the 1/2. 
Please
make sure patch series are threaded properly.

-- 
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 3.7] dma: sh: Don't use ENODEV for failing slave lookup

[Koul, Vinod]

> 
> If dmaengine driver's .device_alloc_chan_resources() method returns -ENODEV,
> dma_request_channel() will decide, that the driver has been removed and will 
> remove
> the device from its list. To prevent this use ENXIO if a slave lookup fails.
> 
> Reported-by: Kuninori Morimoto 
> Signed-off-by: Guennadi Liakhovetski 
Applied thanks, CCed stable as well

--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] dmatest: Fix NULL pointer dereference on ioat

[Koul, Vinod]

> On Wed, Nov 14, 2012 at 8:17 AM, viresh kumar  wrote:
> > On Mon, Nov 12, 2012 at 4:33 AM, Jon Mason  wrote:
> >> device_control is an optional and not implemented in all DMA drivers.
> >> Any calls to these will result in a NULL pointer dereference.
> >> dmatest makes two of these calls when completing the kernel thread
> >> and removing the module.  These are corrected by calling the
> >> dmaengine_device_control wrapper and checking for a non-existant
> >> device_control function pointer there.
> >>
> >> Signed-off-by: Jon Mason 
> >> CC: Vinod Koul 
> >> CC: Dan Williams 
> 
> > Reviewed-by: Viresh Kumar 
Applied, Thanks

--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v2] dmatest: Fix NULL pointer dereference on ioat

[Koul, Vinod]

 On Wed, Nov 14, 2012 at 8:17 AM, viresh kumar viresh.ku...@linaro.org wrote:
  On Mon, Nov 12, 2012 at 4:33 AM, Jon Mason jon.ma...@intel.com wrote:
  device_control is an optional and not implemented in all DMA drivers.
  Any calls to these will result in a NULL pointer dereference.
  dmatest makes two of these calls when completing the kernel thread
  and removing the module.  These are corrected by calling the
  dmaengine_device_control wrapper and checking for a non-existant
  device_control function pointer there.
 
  Signed-off-by: Jon Mason jon.ma...@intel.com
  CC: Vinod Koul vinod.k...@intel.com
  CC: Dan Williams d...@fb.com
 
  Reviewed-by: Viresh Kumar viresh.ku...@linaro.org
Applied, Thanks

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 3.7] dma: sh: Don't use ENODEV for failing slave lookup

[Koul, Vinod]

 
 If dmaengine driver's .device_alloc_chan_resources() method returns -ENODEV,
 dma_request_channel() will decide, that the driver has been removed and will 
 remove
 the device from its list. To prevent this use ENXIO if a slave lookup fails.
 
 Reported-by: Kuninori Morimoto kuninori.morimoto...@renesas.com
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Applied thanks, CCed stable as well

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] ARM: ux500: Describe UART platform registering issues more accurately

[Koul, Vinod]

> > > is there anything you are waiting for still? Should Jon resend his
> > > latest patches to make sure we get them merged this time?
> > >
> > > I have multiple people that want to send me patches for 3.8 based on
> > > that work, so we are running out of time now.
> >
> > Vinod responded today saying it will be in for v3.8 [1].
> >
> 
> Ok, very good. Thanks everyone!
If you have any patches for this, please send me. Your work should not stall,
that is why I had the topic branch.

I plan to merge this to my next mid next week,
based on how early my travel permits :)

--
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH 1/1] ARM: ux500: Describe UART platform registering issues more accurately

[Koul, Vinod]

   is there anything you are waiting for still? Should Jon resend his
   latest patches to make sure we get them merged this time?
  
   I have multiple people that want to send me patches for 3.8 based on
   that work, so we are running out of time now.
 
  Vinod responded today saying it will be in for v3.8 [1].
 
 
 Ok, very good. Thanks everyone!
If you have any patches for this, please send me. Your work should not stall,
that is why I had the topic branch.

I plan to merge this to my next mid next week,
based on how early my travel permits :)

--
~Vinod
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

RE: [PATCH] dma: tegra: fix interrupt name issue with apb dma.

[Koul, Vinod]

> >
> > (Dropping stable Cc; Olof/Arnd or Vinod, is it possible you could add
> > that into the patch description when applying this?)
> >
> > Reported-by: Stephen Warren 
> > Acked-by: Stephen Warren 
> 
> Should be no problem. If Vinod wants to pick it up:
> 
> Acked-by: Arnd Bergmann 
Will do it later today... am travelling so slow on email :(

--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] dma: tegra: fix interrupt name issue with apb dma.

[Koul, Vinod]

 
  (Dropping stable Cc; Olof/Arnd or Vinod, is it possible you could add
  that into the patch description when applying this?)
 
  Reported-by: Stephen Warren swar...@nvidia.com
  Acked-by: Stephen Warren swar...@nvidia.com
 
 Should be no problem. If Vinod wants to pick it up:
 
 Acked-by: Arnd Bergmann a...@arndb.de
Will do it later today... am travelling so slow on email :(

--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/