Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-27 Thread Stanimir Varbanov
On 02/26/2015 04:33 AM, Mark Brown wrote: > On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: > >> yes, there is a potential race between atomic_inc and dma callback. I >> reordered these calls to save few checks, and now it returns to me. > >> I imagine few options here: > >>

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-27 Thread Stanimir Varbanov
On 02/26/2015 04:33 AM, Mark Brown wrote: On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: yes, there is a potential race between atomic_inc and dma callback. I reordered these calls to save few checks, and now it returns to me. I imagine few options here: - reorder

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-25 Thread Mark Brown
On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: > yes, there is a potential race between atomic_inc and dma callback. I > reordered these calls to save few checks, and now it returns to me. > I imagine few options here: > - reorder the dmaengine calls and atomic operations,

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-25 Thread Mark Brown
On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: yes, there is a potential race between atomic_inc and dma callback. I reordered these calls to save few checks, and now it returns to me. I imagine few options here: - reorder the dmaengine calls and atomic operations, i.e.

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Andy Gross
On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: > > yes, there is a potential race between atomic_inc and dma callback. I > reordered these calls to save few checks, and now it returns to me. > > I imagine few options here: > > - reorder the dmaengine calls and atomic

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Ivan T. Ivanov
Hi Stan, Sorry I didn't saw this first look. On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote: > > +static bool spi_qup_can_dma(struct spi_master *master, struct spi_device > *spi, > + struct spi_transfer > *xfer) > +{ > +

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Ivan T. Ivanov
Hi Stan, On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote: > > #define SPI_MAX_RATE 5000 > @@ -143,6 +147,11 @@ struct spi_qup { > int tx_bytes; > int rx_bytes; > int qup_v1; > + > + int dma_available; This is

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
On 02/24/2015 03:56 PM, Mark Brown wrote: > On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote: > >> +static void spi_qup_dma_done(void *data) >> +{ >> +struct spi_qup *qup = data; >> + >> +if (atomic_dec_and_test(>dma_outstanding)) >> +complete(>done); >> +} >

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Mark Brown
On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote: > +static void spi_qup_dma_done(void *data) > +{ > + struct spi_qup *qup = data; > + > + if (atomic_dec_and_test(>dma_outstanding)) > + complete(>done); > +} I'm finding it hard to be thrilled about the use of

[PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
From: Andy Gross This patch adds DMA capabilities to the spi-qup driver. If DMA channels are present, the QUP will use DMA instead of block mode for transfers to/from SPI peripherals for transactions larger than the length of a block. Signed-off-by: Andy Gross Signed-off-by: Stanimir Varbanov

[PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
From: Andy Gross agr...@codeaurora.org This patch adds DMA capabilities to the spi-qup driver. If DMA channels are present, the QUP will use DMA instead of block mode for transfers to/from SPI peripherals for transactions larger than the length of a block. Signed-off-by: Andy Gross

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Mark Brown
On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote: +static void spi_qup_dma_done(void *data) +{ + struct spi_qup *qup = data; + + if (atomic_dec_and_test(qup-dma_outstanding)) + complete(qup-done); +} I'm finding it hard to be thrilled about the use of

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Ivan T. Ivanov
Hi Stan, On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote: snip #define SPI_MAX_RATE 5000 @@ -143,6 +147,11 @@ struct spi_qup { int tx_bytes; int rx_bytes; int qup_v1; + + int dma_available; This is more

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Stanimir Varbanov
On 02/24/2015 03:56 PM, Mark Brown wrote: On Tue, Feb 24, 2015 at 03:00:03PM +0200, Stanimir Varbanov wrote: +static void spi_qup_dma_done(void *data) +{ +struct spi_qup *qup = data; + +if (atomic_dec_and_test(qup-dma_outstanding)) +complete(qup-done); +} I'm

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Ivan T. Ivanov
Hi Stan, Sorry I didn't saw this first look. On Tue, 2015-02-24 at 15:00 +0200, Stanimir Varbanov wrote: snip +static bool spi_qup_can_dma(struct spi_master *master, struct spi_device *spi, + struct spi_transfer *xfer) +{ +

Re: [PATCH v2] spi: qup: Add DMA capabilities

2015-02-24 Thread Andy Gross
On Tue, Feb 24, 2015 at 06:08:54PM +0200, Stanimir Varbanov wrote: snip yes, there is a potential race between atomic_inc and dma callback. I reordered these calls to save few checks, and now it returns to me. I imagine few options here: - reorder the dmaengine calls and atomic